Why (it's Time to Take Another Run at) Elm

Maybe the title gives it away. I have a little history with the Elm language. Not a bad history per-se, just a history. A brief encounter fueled by strong initial enthusiam, then gradual disappointment brought on intense wheel-spinning: the inability to accomplish anything beyond a toy application. Finally, it was time to set it aside.

Sound familiar? Well, if so, remember that all is change. And this actually might be great time to revisit the language, its learning curve, and its community.

The Basics

The answer to What is Elm? is easily found here, here, and even here. But in case you're in a hurry, Elm is a programming language designed and optimized for developing apps using "web tech".

Compared to today's popular front-end tech, it presents an altogether different developer interface (DI) in that Elm embodies principles, concepts, features, restrictions, and techniques commonly found in functional programming languages. It has a relatively concise syntax, a strong type system, a distinct opinion about program structure, and a much-lauded compiler (very fast and very friendly) that coalesces an entire project into a single JS script that executes in the browser.

In short, Elm presents app developers an alternative to JS to accomplish front-end work. When I stumbled across it a few years ago, it struck me as something that was actually new.

Historical Details

Yeah - very new, indeed. This was September 2015. Netflix and AirBnb had announced their adoption of React in January. Relay and GraphQL were introduced in February, and Redux (which I believe was heavily influenced by a crucial Elm idea) made its splash in June. Hard as it might be to believe today, the mindset of web app development was very different then. Components were not king and precious few had bought into the idea of a single immutable store of app state mutated by pure functions. None of the above could be called mainstream. Elm was at version 0.15.1.

And then there was all the baggage I brought to the table: No CS degree (BA/Communications, MBA/Finance), no exposure to ML style langauges (instead traditional DOM mutation using JQuery and vanilla JS), and an imperative bent toward most everything. (Seriously, is there anything more aptly named in the imperative style than the DO loop?) Still, I knew about the end result: the DOM, markup, CSS, the browser event loop. Elm seemed to be all about my concerns and ambitions. It almost seemed like I was their target customer: a traditional front-ender not willing to settle for the $-induced madness of webdev.

But it did not go well. The conceptual gap was too far for me to make on my own and there were too few other voices willing and able to articulate guidance. The on-boarding experience was fine, perhaps great, and the introductory materials were well above the standards for the day. Things worked! I couldn't explain what I was doing or why, but following along with the tutorials led to the right outcome: a working example. The dev experience felt right.

And yet, going beyond the harbor of guided content - out into the open water, as it were - was a complete fail. I had some understanding but no technique, some knowledge, but little capability to create on my own. So I sought answers in the project forums, then on Google Groups. I posed a few queries, and read many, many discussions, and this helped but only marginally. People were very pleasant, mind you, but I could tell from their answers that they were coming from a very different perspective than I was. Their mental-model of Elm, functional programming, and app development seemed worlds apart from mine.

The most useful observations from frequenting the project forums were (i) although we seemed to be the minority, there were indeed others trying to master Elm to do average, everyday commerical work, (ii) they had similar questions to mine, and (iii) the concerns of the most dominant voices tended toward the nature, features, and implementation of the language. It's pretty obvious looking back on it. This was a clear case of being too early. The language itself was still changing (and please don't misunderstand, I am absolutely fine with that, Elm is a fascinating project to watch develop) and, to play along, community members would have to be able to keep up more or less on their own (also 100% fine with that).

So I stopped following the project. I wasn't angry, nor turned-off, nor even disappointed. Elm's promises still beckoned but I couldn't get there. I was like a beginning piano student: I could read music and understood notation, key signatures, tempo, and dynamics. But I couldn't play anything beyond simple scales. If anything, I was wistful.

That Was Then, This is Now

So maybe the question is how long is 38 months in internet JavaScript time?  In other words, what's happened in the Elm realm that would trigger a guy like me to write a post like this? In short, a great deal.

Clean tech

To begin, the Elm tech has gotten even better. Currently at release 0.19, it's cleaner and even more focused than ever before. Note that, in Elm lang, features can be, and are, removed when they turn out to be redundant, confusing or otherwise unneeded. (Here is one example and another.) Compare that to the necessarily dictated "append only" only nature of JavaScript. Yes, that can result in rework in the community code base and the eco-system, but instead of perma-bloat, developers receive a more effective, more usable feature set whose UX has been validated by the developers themselves.  This is A/B testing of the features of a programming language.

Elm has long made a claim that, in it's eco-system, things will just work. This remains largely true even while recent refactoring of the core modules have brought compile times and package sizes down drastically. And of course, Elm's much acclaimed friendly compiler error messages seem to get better and better. (One wonders why they aren't touting AI or IoT as the magic sauce for those.)

More to the point, what we are seeing is organic growth and maturation of the project, based in large part, I suspect, on listening to and acting on real-world feedback. The focus and improvements in the Elm tech seem to me to be just the sort of things real-world devs attempting to use Elm on ordinary commercial projects would require and request. This is a great sign for the project (if my guess is anywhere close to being right.)

Help!

The most notable change in the Elm community is the amount, availability and nature of support materials; a veritable Cambrian explosion seems to have occurred.  Gone from the wonky forums of Google Groups the Elm buzz has moved to:

• Elm Discourse
• Elm Slack
• the Elm sub-reddit

Not to mention the hundreds of blog posts, YouTube videos, and tweets. There are free and for-pay books, a multitude of video courses, a podcast or two, a weekly newsletter, as well as a healthy Meetup scene in most regions if live, human contact is what drives you. 

Elm devs are encouraged to use Ellie, a free, hosted, Elm-development in the cloud, as the platform for posting examples, issues, and questions rendered as a Short, Self Contained, Correct (Compilable), Example (SSCCCE). It's an awesome piece of work by the community and a great way to experiment.

And all this is accompanied by explicit guidance from the Elm projects leaders to emphasize inclusion and welcome to newcomers over release tempo, number of downloads, starts, forks or other dev-stat metric. So there are many, many more voices to interpret Elm tech and technique, and on the surface of it, more diverse voices as well.

Acceptability First, then Traction

Compared to Q4 2015, there much more awareness and acceptance of the principal design bets which Elm has taken. For example, in regard to app state management, Redux is now seemingly passing into its Yeah, So What phase, with projects like Flux, Mobx, Vuex, and others following closely. For typing, it isn't unusual to encounter Flow or Typescript when dealing with a significant code base. Considering languages, names like CycleJS, PureScript, Scala, Clojure and Erlang - all of which bring at least some level of functional programming to the forefront - no longer elicit blank stares from devs and their managers.

Maybe because of Elm, or more likely just by happy coincidence, the general, commercial computing environment is better conditioned to accept a functional alternative for the front-end and for that project to thrive.  While the collection of logos on the Elm site is still quite small, based on informal community surveys and informal assessments of discussion traffic, more organizations are evaluating and using Elm than it might appear. Or so goes the most current thinking.

All in, it's a great time to engage with Elm; it's tech, though still not fully-baked, is solid and there's a healthy support network for those us would need a nudge or more so to make it over the hump.

Packing for the Trip

Getting started with Elm is very easy. The hands-down best entry point is the official Elm guide authored by the principal designer/developer of Elm. From there, you can pursue almost any path to learning that suits you.  That said, there are few facets to be aware of.

Elm is evolving

As a newcomer to Elm, it is all too easy to underestimate the impact of this: Elm isn't done, yet. That, I think, is very good for the language and community but can be especially rough on beginners. Here's why:

• Being a member of a community for awhile provides vital context/perspective that helps manage the cognitive effort it takes to accept changes. It's easier to understand the Why of any alteration to practice or syntax. By definition, beginners lack that context so any change can seem arbitrary and random.
• Because Elm isn't JavaScript, and as such, has no "legacy" code to protect, some improvements require significant (at least significant to beginners) changes. Again, this is all good, but such changes almost immediately invalidate large swaths of educational content posted to the web, including videos, examples, articles, forum threads and examples.

Suggestion: keep an open, curious, understanding, but somewhat wary mindset when consuming free internet content. Value recent content more than content even 1-2 years old (unless you're especially interested in how the process of Elm's evolution itself.) Be understanding when examples don't compile, packages are out of date, or tips don't do what the author claims they will do.  Remember it is unlikely that any author of Elm related content set out to deceive us; more that likely, Elm has evolved in a way as to deprecate the content.  Treat specific technical problems as a reminder to focus on the functional programming pattern at hand, as we can probably suss out the syntax changes later.

This is not an open source JS project

Again, this is a subtle, if not subjective, aspect.  Anyone working in any section of the broader JS community will feel the impacts of the community, which I will generalize to include a competitive atmosphere, a bias toward a rapid release tempo, an implied freedom/need to shout to be heard, and a fork-at-will mentality when disagreements come up.  I may be off-base here by large measure, but t hese attributes come to mind when I hear the JS scene characterized as The Wild West (with apologies to any non-US readers.) As I said, I may be over-generalizing, but it will become obvious to any newcomer that the Elm realm does not adhere to nor reward those behaviors.

Suggestion: Dial back any existing expectations based on JS work.  Embrace Elm for its differences, its different objectives as compared to JS, its much more deliberate release tempo that favors getting it right rather than getting it shipped, and its opinionated approach (sometimes described as the one singe way) to problem solving.

Elm is a singular vision

The Elm project operates under the BDFL model, and I would go so far as to call it the Strong Variant of that model. By that I mean is that it's principal leader does far more than retain the final say in disputes or arguments within the community. Rather he is the project's driving source of vision - features, implementation, tone, and even at times terms & language. Yes, there is a foundation implemented for the safekeeping of the project, but for all intents and purposes Elm is the realization of one primary resource and his brilliance. 

Note that I am in no way suggesting this is a problem; far from it. I think Elm is fascinating and valuable on several levels. 

Suggestion: trust in the project governance enough to invest some time into learning Elm.  It's not important to convince your team or you employer to use Elm, first focus first on convincing yourself. Becoming competent in Elm will pay future dividends no matter what technologies we adapt in the future.

Deliberate Practice

The key to mastering a skill - be it physical, mental, emotional, or some unique combination - is practice. Reps. Doing the skill in the context of a performance/assessment/adjustment/performance cycle. We've all heard of the 10,000 hour idea popularized by Malcolm Gladwell's work.  And it's easy to find plenty of contrarian perspective to that as well.  But the gist makes intuitive sense: it's unlikely that we are born-and-bred Elm devs. It's probable that we'll need reps to get better, and that with the right kind of reps, we will get better.

But what are the right kind of reps?

My bet is on deliberate practice, the notion that what separates great performers from others is not the time spent practicing, but how they practice. Now what could this mean in regard to learning a new programming language? Here's an example.

The official guide to Elm is a fantastic, carefully structured introduction to the language and its key concepts.  If you're like me, you're in a hurry to learn, you want to start accomplishing something with this fun new thing, Elm. So maybe you skim through the code examples, nodding your head, and telling yourself, Yeah I get that. But do you? Is that actually a deliberate approach?  This guys doesn't think so.

He recommends actually typing out each and every bit of Elm code in the guide into your own editor. Too far-fetched? For production, certainly (And he says so plainly.) But to learn?  It's not bad advice.  Here's a different story that makes the same point. 

Long ago, I studied French in university. In the Intro classes I did OK, but when reaching the next level I foundered badly.  I approached the instructor for help. "Tell me how to study", he asked. "Do you practice one hour a day?" "Sure", I replied, "I do five hours in the lab on Fridays." "No, no, no", he cried, "You must do one hour each day. And I want you to write out each exercise, question and answer, in full." I protested, but he was adamant as only a French man can be.  I left quite pissed off and literally said to myself, What a moron! OK, I'll do as he says and show him that it won't make a bit of difference. So I did as he directed - deliberately - and showed who the real moron was. And he was quite subtle about my progress, once remarking quietly to me as I retrieved a nicely graded assignment (Yes, this was back in the analog world.) "You are improving, Monsieur".  

Suggestion: All this is to say that learning Elm will come easier and more quickly through deliberate practice - diligent intentional reps wherein the point of a practice session is to first explore, and then engrain, a pattern.  Which pattern? Doesn't really matter. Pick a small pattern of interest and code it deliberately. Step back and assess. Refactor and code it again.

---

Way back in 2015 I had my dobuts. Doubts as to how closely aligned my objectives as a web developer were to those of the Elm project. I frankly wondered how much real world, in-the-trenches, web app experience was available to inform the project's principals. Today, those doubts are way gone. The Elm project has improved markedly in every way. It's time - more than time - to give it another go.

Let's get to it!