| That might solve the cursor issue, but it's a bigger issue than cursor state. The real issue is that Elm doesn't treat its programmers like grown-ups. That sounds harsh, so let me explain . . . I've drank enough of the Haskell Kool-Aid to realize that, despite the surface discourse, Haskell is not about religious devotion to purity and lazy-evaluation. It's about managing side-effects, and being honest about them in your type signatures. Yes, Haskell allows functional purity but its real genius lies in how well it helps you manage state. (I did an imperative Algorithms course completely in Haskell, and the language really shines. Mutable unboxed arrays, mutable atomic references . . . it's all there when you really need it.) Unfortunately, the folks driving Elm development take a paternalistic tack. (If someone seeks to argue this point, it's not hard to come up with many, many examples from the Elm mailing lists.) Here's a few examples: - Elm shouldn't have type-classes because, allegedly, they are too hard for JS-folks to understand. (https://groups.google.com/forum/#!searchin/elm-discuss/type$...) - Elm doesn't publish how you are supposed to write native modules (you must discern it from the code and it's subject to change without notice), because Elm's author thinks you can't be trusted to use FFI wisely. (https://groups.google.com/forum/#!searchin/elm-discuss/nativ... and the can was kicked here: https://groups.google.com/forum/#!searchin/elm-dev/native/el...) And, no, Elm's ports are not the equivalent of FFI. - In the most recent release, operators were removed because synonyms for map (<~) and apply (~) are allegedly to hard understand. - Appartently, you shouldn't even mention Haskell as a resource for learning Elm. (https://groups.google.com/forum/#!topic/elm-discuss/OlzLOPix...) I think it's healthy for programming languages to have a point of view; that is, languages should lead you in a direction. (Clojure does a great job at this.) Yet, ultimately, a language shouldn't censor its programmers. Upshot: Component local state should be an option in Elm when you really need it. |
The <~ for Signal.map is a good example for a "clever" thing which makes languages hard to read for newbies. It looks like it's part of the syntax and not a function. It's not hard to understand, but it's another thing to learn. I am very happy that things are removed from Elm (or not added in the first place, like type classes) because design is not finished when there is nothing more to add but when there is nothing more to remove.