‘Iacta alea est’
Penned on 17th January 2016
In his talk “Let’s be mainstream”, Elm creator Evan Czaplicki outlines a history of computer programming from the point of view of JavaScript developers. He hearkens back to the difficulty of working in assembly language, naming the specific challenge of maintainability when working at such a low level and how when C came along it was a tide that raised all boats and we gradually gave ourselves different problems as we successively solved the problems generated by a previous solution.
His main argument is that we find ourselves back in a mess of maintainability with JavaScript. THe parallel is not a difficult one to draw when we have called—and are making—JavaScript, the assembly language of the web. One of the key features of assembly language is that you don’t work with it, and there have always been attempts to move in that direction, from the early behemoths GWT and Cappucino, to the ‘father’ of many transpiled languages, CoffeeScript, leading the current crop twoards more modern and opinionated flavours in TypeScript and Flow. I have written a little previously about this phenomenon, highlighting Elm’s uniqueness.
To my knowledge, Elm is the first real language, having a distinct syntax and semantics, that has been designed for the web ‘platform’. You could argue that it is ML in a different guise but it is much more Haskell to Miranda than CoffeeScript to JavaScript, that is, while it has many influences in prior art, it stands far enough apart to inhabit its own category and classification. In doing so it implicitly acknowledges the assembly nature of JavaScript as a build target, and explicitly seeks to be an improvement on JavaScript as a brain target.
It is the latter aspect that I believe is most noteworthy, the first has now been done many times before. The tendency has either been to improve the semantics of JavaScript or replace it with the existing semantics of an existing language. Elm’s stated goal of maintainability, of restoring a level of sanity to the programmer in his art, is reminiscent of the work of Yukihiro Matsumoto, who, with Ruby, sought to give developers joy. The key being, design a language for man and not the machine. Many of the affordances—or lack thereof—in Ruby can also be seen in Elm: lack of a var declaration; omission of parentheses except when necessary; let the compiler work out the type; a clear style optimized for readability; a helpful compiler; all contrinuting to a friendly and approachable face that continues to be so when you revisit it a few weeks or months down the line.
The major differences are that of programming paradigm. Ruby is dynamic, duck-typed, and object oriented while Elm is static, typed and functional. Nevertheless, the benefits to the programmer remain the same, and potentially more so on Elm’s side given the slow and steady preference toward typed, functional programming.
This last shift is an interesting one, because I believe Elm makes the case for typed functional programming better than most. First of all it doesn’t make a big deal of it, the argument is not “use Elm because it has types” but “Use Elm because its fun and gets the job done, oh, and by the way, that thing that just made it easier for you? That was types.” It has a clear focus on benefits over features.
Second of all it makes these things invisible, and only set to appear when you really need them. By inferring the types you only have to worry about them when you got something wrong. The compiler will remind you gently that you can’t put that there and that it might be better using something else, offering a list of valid alternatives. This is unobtrusive typing, much different to what you may have experienced in Java or similar. Of course you often end up writing out the type annotations after a while because of their usefulness in reasoning about your application at a higher level.
Thirdly, and this is the key in Elm’s inevitable success, the funcitonal (and reactive) aspect and the type aspect are the features that are going to drag us, kicking and screaming, out of the tar pit. We don’t know it yet because most of us are familiar with large, messy, brittle and hard to maintain test suites to ensure the maintainability of our code. If you’re a little more advanced you’ll have coupled that with the kind of programming and application design espoused by those with a history in object oriented design, that when compared with functional programming more closely resembles it than can be distinguished from it. Now, with Elm, that comes by default and is a particular default that you can’t change, you cannot mutate Elm’s immutability.
The type sytem also becomes a potent weapon in the face of constant change or refactoring. It’s like the safety net underneath the tight rope, and you’ll begin to love it and appreciate it so much when making that nervous change with global reprecussions that you’ll ditch the tight rope and jump full fling into the net, using it as a trampoline and cavorting around in a state of delirious excitement, so much so that when the boss asks you to come in on Saturday you reply that you’re not even going home tonight.
The compiler is the friend who is slightly smarter than you but doesn’t make you feel stupid, preferring to pull you up than to put you down.
And this sort of maintainability is not a pipedream; you only have to listen to Richard Feldman’s experiences with his open source project and then with NoRedInk to see what it can bring. Help, not just the first time round but a steady, incremental accrual of confidence in the lifetime of your software project. Where a change doesn’t induce fear but curiosity and where dread is replaced by the slightly disappointing air of normality that will allow us to find different problems to worry about and dream up new languages to fix them.
Elm protects you from the shifting tectonic plates of browser innovation and language experimentation by acting as that proxy, but does not hinder you from keeping up with the Joneses because were you ever to have to upgrade, the type system has got your back. While JavaScript keeps adding features in order to reach perfection, Elm regards perfection as that point at which there is nothing left to take away.
—Wednesday 13th January 2021.