Some Fun With Elm, and Some Suggestions

A weekly podcast with Cliff Click talking about all things to do with programming, programmers and computer performance.

This is a short talk on my experiences using Elm for a Big Data visualization app.  It’s been a lot fun, and also some frustration on language choices that I find puzzling.

5 thoughts on “Some Fun With Elm, and Some Suggestions

    • Have not used Clojure in earnest! I like the concurrency model, and in theory the way side-effects re handled but never used it for-realsies. 🙁

  1. I enjoyed your report on your experience in using Elm. I have a couple of comments:

    1. Curried functions have been a known UX problem in this class of languages (including ML, Haskell, PureScript) for three decades now and I still confuse myself when accidentally leaving out an intended argument in an application. I agree it would be nice, in all of these languages, to be able to annotate “expected usage” in order to generate more helpful error messages.
    2. Elm’s design makes linear-time mutable arrays impossible (unless you use a port). Haskell doesn’t have this problem because it uses a state monad to manage mutable arrays. PureScript also does that:
    3. Nested updates are a real pain without lenses. The Haskell community has embraced a particular style of lenses. PureScript has adopted an arguably better style, “profunctor” lenses but the main point is that lenses are really necessary in order to cleanly program in an immutable way with nested data.

    Therefore, PureScript has a lot of nice properties as a language over Elm. However, it is also a much more complex language and smaller community.

    • Glad I’m not alone here! On the “lenses” thing, I mostly would like the Elm folks to settle on some kind of a standard for this.
      On the case of arrays, I find there are perhaps 3 obvious use cases to think about:
      (1) “small data”. Lists are fine (as long as all ops are “do all” or “do head” but not “seek”)
      (2) “Big Data read-only”: Use JS-backed arrays with a nice Elm type-safe wrapper. I’m using this for all sorts of graphic visualizations.
      (3) “Big Data read-mostly write-rarely” – Pay the price, and Go Slow on the write and do the horrible copy-all. But make the user type something nasty so they know they are writing “slow code”.
      (3a) “Big Data read-mostly write-ALL” – Support an efficient update-in-place with no ability to see the pre-update version after the update. Nice if you’re double-buffering a big fast moving display. But maybe this is just time to call out to JS and bail on the Elm model.

Leave a Reply

Your email address will not be published. Required fields are marked *