‘Iacta alea est’
Penned on 17th January 2016
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.
—Wednesday 13th January 2021.