Question: which reminds me, is it true it will get harder to use native modules in 0.19?

Asked By
ktosiek
Asked At
2018-03-24 19:43:53

Found 15 possible answers.

User Answered At Possible Answer
reactormonk 2018-03-24 20:05:56 @ktosiek yeah, you'll have to build your own compiler
ktosiek 2018-03-24 20:06:43 is it really that bad? Can't I somehow convince the old one I'm Evan? :slightly_smiling_face:
daniel-kun 2018-03-24 20:45:29 I'd say interactivity, and being able to copy-paste working code from it. We live in a world of stackoverflow driven programming :wink:
janiczek 2018-03-24 20:47:23 0.19 is not there yet so no way to know, but that would probably defeat the purpose :slightly_smiling_face: it would just become a default compiler flag for the people that already use native modules
reactormonk 2018-03-24 21:04:04 @ktosiek you can, but that's a bit more involved. Building your own compiler is probably easier.
ktosiek 2018-03-24 21:06:55 only used native for experiments (aka fun hacks) so far but I could sometimes use some FFI for pure-ish JS functions, even if it wraps everything in Result
danabrams 2018-03-24 21:16:25 There definitely are very useful effect managers without native code. I believe Elm-Lang/mouse is one. [March 24th, 2018 2:33 PM] rupertlssmith: Most effects managers include kernel code, because they bridge pure Elm with the 'outside' world. It is possible to have effects managers with no native code, but I don't think there are many or many potential use cases for them. You can do something like Sub.map, as the excellent Style Animation library does. It’s much easier than writing an effect manager. Evan has written somewhere that he thinks there only need to be like 7 effects managers or something like that, hence the fact that it’s a private api.
bojan.matic 2018-03-26 09:08:20 > Evan has written somewhere that he thinks there only need to be like 7 effects managers or something like that "No one will need more than 637KB of memory for a personal computer."
ilias 2018-03-26 09:18:30 > "apples are not orange" - Ilias
supermario 2018-03-26 09:20:07 Yeah, not sure that’s an entirely fair comparison. Plenty of languages, use cases and experience out there to compare/consider for EMs. Not quite the same as facing the unknowns of future of computing in the dawning era of modern computing :sweat_smile:
ilias 2018-03-26 09:27:27 (that said, there are ~11 such modules already on package.elm-lang.org , though some of them are could be refactored to share a common base, like Keyboard and Mouse. Anyway, there are good reasons for not having EM's in regular code - they're rather error-prone, not many of them are _needed_, and they can be _very_ easily abused. So in the interest of making it harder to write bad code, that seems like a good call.
norpan 2018-03-26 09:38:07 Do we need them at all? I’m all for keeping the state explicit
pdamoc 2018-03-26 10:13:14 @norpan it’s a tradeoff. Some things become nicer when you have the accidental state managed automatically. For example, you can easily use a Random library without an Effects Manager but using an effects manager allows you to bypass managing the seeds.
norpan 2018-03-26 10:58:10 @pdamoc for sure, I’m just wondering if the tradeoff is needed.
supermario 2018-03-26 11:03:44 I’ve been working with the core EM code a bit recently. Some (like Random) I can definitely see how you could do without, though it does raise the bar for begginers. Other however, like Websockets, seems like it would be pretty nasty to have to implement all directly into your own TEA model. :man-shrugging:

Related Questions