‘Iacta alea est’
It has been almost a week since the meetup so conversations, who said what, etc., are largely relying on my memory of the event and may therefore not be completely accurate. I’ll be happy to update the post if anyone feels their words have been misrepresented.
Yesterday I wrote a summary of the talks from the Elm London meetup last week, but I didn’t get a chance to share an important part of the schedule, ‘talking about how great Elm is!’ One of the most enjoyable and fruitful parts of a meetup is often the opportunity to meet new people and geek out, in this case, about Elm.
There was a good crowd and between Plumbee’s kitchen and The Artillery Arms pub I managed to get talking to quite a few people. The question on everyone’s lips was first whether or not we had played with Elm and then whether or not we had made the step to using it in production. The first was always greeted with smiles and affirmative nods, most have tried it and to great success, which led to almost everyone either beginning to integrate it into their production stack or working out a way to convince the powers that be to allow them to do so.
That led to a conversation about adoption, and it provoked debate among the rather European crowd. My experience in the UK (and to a limited extent in the Netherlands) has been that technology choices are made much more conservatively in the US. (I suspect some of that has to do with the difference in developer-led vs manager-led decision making as well as the gung-ho attitude that failure is the first step to success vs the British reserve where failure is the end.) We had some French, Italian, and Germans who were at different points on the scale.
The French are laggards, and much more likely to adopt when the the technology reaches obsolesence (Seb’s words), the Germans on the other hand seem much quicker to adopt new technology for its merits and it was thought they have the largest Elm base in Western Europe to date. The fact that React and Angular have seen good adoption in the UK would seem to reinforce the supposition that people go for a safe (corporate backed) option, similar to the back-end staples of Java and .NET.
There are a few things that give me hope about Elm adoption, one is that Elm is not too far off React / Angular 2 conceptually speaking (it’s really the other way around), another is that Elm’s type safety and constrained, but productive, architectural style is much more team friendly (similar to convention over configuration) which lends itself well to startup and enterprise alike, and yet another is that Elm can be cautiously and slowly introduced to a pre-existing application or stack on a piecemeal basis making experimentation cheap. This topic possibly deserves a blog post of its own.
We also touched briefly on Elm’s learnability in several conversations. I think it was Simone (@simonewebdesign) who said that it took him no longer than a month to learn Elm and once it was learnt, that was pretty much it. Another said he had read through the whole of the Elm source code (I’m assuming that was the core libraries) in no time at all which he said was shorter, quicker and easier than doing the same for the Ember.js framework. (Seems like it would still hold up even if you factored in the compiler, and the popular packages on line count alone!)
Given my Ember.js experience it led on to some interesting points around simplicity, object-oriented vs functional approaches to front-end development and the feasibility of turning the framework juggernaut every time a new or more efficient paradigm presented itself.
I took my chance to speak to Noah Hall (@eeue56) with the intention of asking a couple of questions that I keep seeing come up at different points in the Elm communication channels (Mailing List, Slack, Twitter). Without the requisite experience it is impossible for me to form a considered opinion, so it would make sense to ask one of the people in the best position to judge. Best because I heard during or shortly after the presentation that Noah had some years of Haskell behind him and because he is working on the largest Elm application in production. One question concerned Elm, the language, and the other Elm, the architecture.
A common occurrence on the Elm mailing list and elsewhere is that someone with experience in Haskell will turn up, having looked at Elm, and ask, “Why doesn’t Elm have Haskell feature x?” where x is often typeclasses or some higher-order, higher-kinded type. Having a vague idea (well okay, no idea) what any of that means but enough to know it must be important I asked specifically whether there was cause for concern because Elm didn’t have what appear to be these powerful and flexible capabilities. I seem to recall my phrasing being something along the lines of, “Given your experience with Haskell, do you miss some of the higher order capabilities when you work in Elm, like type classes?”
The answer was pretty much what I expected, No, but it’s good to hear it coming from someone with experience. The gist (and these are my words) was that the power features in Haskell are akin to nuclear power, fantastic in the right hands and when things go well, but catastrophic in the wrong hands and when things go badly. Noah mentioned the tendency when using Haskell to put together code and libraries that are almost incomprehensible to the next developer (or even yourself a few weeks/months down the line), and that the limitations of Elm in this respect were a blessing rather than a curse. (After some research it appears that Elm may get some form of the features in question, but only if absolutely necessary, and only if the time is right to introduce them. Evan Czaplicki’s approach to language design deserves a treatment of its own.)
A complaint I have heard of Elm as it scales in a medium to large single page application is that the wiring up of deeply nested components results in a bit of tedium and a lot of boilerplate. Having not yet built a medium to large SPA in Elm I again don’t have the authority to make a judgement here so I asked Noah—with the caveat that NoRedInk is not an SPA—what his thoughts were about it. He said that the Elm Architecture was not conceived as having such a deeply nested structure but, while the complaint may be a valid one (although not of incapability but of inconvenience), there was nothing too much to worry about. NoRedInk hadn’t hit any big problems and it wasn’t something that couldn’t be dealt with at a later date if it became a much wider issue.
That’s good news on both counts and goes some way to assuaging any fears you might have lurking in the back of your mind about the feasibility of Elm at a larger scale. I find that these niggling doubts are often why people hesitate to commit even if the doubt is unfounded—there’s simply not enough time in the day to build a large-scale application as a proof of concept to prove or disprove your intuition. That’s why war-story tracks are often the most popular at conferences, concepts look good on a slide but people are concerned about when the rubber hits the road. It’s also why we owe Richard Feldman and the crew at NoRedInk a debt of gratitude for their fearless pioneering into unchartered territory and for their willingness to come back and tell the tale.
I got talking to Claudia Doppioslash (@doppioslash) and thanked her for her Road to Elm blog series from which I have learnt a lot. The resources available on the Elm site are great but I detected a lack in functional programming basics. I completely understand why the focus is elsewhere, so I have personally sought out a firmer foundation through posts like Claudia’s and more formal materials. I was excited to hear that she has some more posts in the works.
I had also listened to her appearance on the Functional Geekery podcast a few weeks ago so I shared with her my amazement at how many programming languages she has picked up. With Common List, Objective C, Clojure, Scheme, Ruby, Python, Java, JavaScript, Unity, Boo, C#, Elm, Erlang, Elixir and Haskell in her repertoire she is the most well-versed polyglot I have ever met. She is into games programming and first got into Elm because of the potential for doing professional game development in a functional programming language which is apparently quite rare in the industry.
I chatted for a while with Volker (@VolkerRabe) about his migration from Rails to Elixir and JavaScript to Elm. He mentioned a graph + document database I hadn’t heard of before called OrientDB and he has also, with the team at MyMeds&Me, developed an Elixir driver for it aptly called MarcoPolo.
Noah also had a few old university friends with him and they weren’t programmers but biomedical engineers. It was refreshing, amongst the hubris and self-aggrandisement that often comes out of the Silicon Valley industrial software complex, to hear about how some of the research they are doing is helping to save people’s lives. It certainly helps to keep things in perspective.
Thanks to everyone who I spoke to, I’m afraid many of the names have escaped me, but I hope to meet you again whether online or offline. It would be cool to put together an Elm one-day conference in London or another major European city to get more people together again.
—Tuesday 16th February 2016
Although I won’t technically be in London, I’ll be presenting a Webinar to introduce Elm to the LondonJS community on April 14th. Sign up here.