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. 🙁
      Cliff

  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: https://github.com/purescript/purescript-arrays
    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 https://github.com/purescript-contrib/purescript-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.
      Cliff

Leave a Reply

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