Why Learning Elm Has Become My New Year Resolution
Over the past holidays, with all the projects slowing down and my wife spending more time at home to help with the baby, I finally had the time to sit down to learn a functional language, which had been my goal for a few months of late 2016. Having attempted several ones such as Haskell, Scala, Erlang, and Elixir, I wanted a language that …
is simple
or does not introduce a whole lot of new concepts and constructs.
is practical
it should only have one clear way to do something.
is productive
it should be usable on the get-go while I am learning.
isn’t general-purpose
I am already programming in Python and Go, and I’d like to learn a language that specializes in something.
I chose Elm, a new drop-in replacement to JavaScript for building web apps. After a few accumulated hours of sittings learning and hacking on example codes, I have decided to make learning it as part of my New Year Resolution of new things to learn, build, and improve on. Here my reasons that made Elm a pleasant language worth spending time on.
This is not a code tutorial. If it ever get to much like a pamphlet, feel free to dial me down a notch.
It lets me play with my kid
I wanted to learn a new language, but as a father with an infant, my time at home is pretty fragmented (It’s impossible to do anything longer than 30 minutes in one sitting without upsetting my baby girl). Most functional languages, or any type of language for that matter, require an enormous amount of time to learn and grasp its idea before I can start building something with it.
Elm impressed me at first sight by not throwing a huge chunk of shiny functional dogma at me but rather lead me into the syntax guide and examples right away like it’s confident the language itself will sell just fine (and it did).
Gotcha: You might have to be at least familiar with functional programming to learn Elm quickly, since its guide barely explains the idea.
It’s boring
I may not have a lot of mileages as a programmer, but I have had my days getting high on Ruby. I was already coding in Python, but as a young pada-one I was looking for the next holy grail and got into Ruby. I swore I was done with Python and spent three months hacking in Ruby with nothing out of it. Ruby has a way of making other language boring, especially if you are a literature person. However, it did not stick. As I soon started to learn Rails, I was not into its magic and quickly transitioned back to Python.
When you use a boring language, as nicely put by Wesley Walser, you tend to build things with it much quicker than with an interesting one because the tool you use to program does not try to be something shiny between you and your goal. However, it must be enjoyable for you enough to want to take it out from the shed. And believe it or not, the joy of seeing what you can build with a language trumps knowing you have mastered monads.
Its docs are beautiful
The language guide is really simple and beautiful. Readability and accessibility of documentation and the learning material play a huge role in my decision to adopt a language or framework. In the back of my mind, I would always think, “I am evaluating this tool, and if I like it then I will keep using it. I’m going to run into a lot of issues and I need to know I can always go back to a good resource.”
Gotcha: The guide and doc are still pretty young though and could use more contributions.
It has a REPL and Playground
This is very, very important to me. I run and debug Go snippets in its playground up to a hundred times a day. Having a REPL and playground meaning you can try code and quickly run to see what breaks and keep iterating that until it works.
It makes me ❤ front-end again
Ahem, not anyone will admit it, but I’m doing it anyway. I do not always enjoy working with HTML and JavaScript. I don’t hate them, but I do hate myself working with them. HTML is too declarative and the massive amount of ‘<’ and ‘>’ quickly fill up my cognitive stack. I had jokingly said to others that I think W3C should just scrap HTML and announce Jade or extends Markdown as the new de facto for the DOM (Obviously they can’t do that).
I don’t think I can mention why I dislike working with JavaScript without potentially starting a language war, which I often find totally moot. However, since Elm is targeted at writing reactive web apps, I’ll talk about my experience with React and Angular instead.
When I first poked into React and Angular, I felt a little disappointed. I am not an expert in either one, and I am not someone to dare criticize these built by Google and Facebook. But to someone who’s already holding something against HTML/Javascript, they feel like hacks. React’s JSX approach to composable DOM components does not invent a new way of describing the DOM structure more than just an extension to make it possible to write HTML right alongside Javascript without making it a string. And well, Angular’s approach to a jacked-up HTML components looks like my annoying pet in a mysterious creature skin.
Elm is functional, clean and simple. Here is an Elm code that writes “hello world” to the browser:
import Html exposing (text)main =
text “Hello, World!”
Elm runtime handles the dirty business of rendering the DOM, and leave us to declare HTML expressively as composable functions:
import Html exposing (ul, text)
import Html.Attributes exposing (class)ul [class "grocery-list"]
[ li [] [text "Pamplemousse"]
, li [] [text "Ananas"]
, li [] [text "Jus d'orange"]
]
The ul function takes two Lists as its arguments, the first contains the HTML attributes and the second all the elements within it. And they are again funtions. The code above results in the following HTML:
<ul class="grocery-list">
<li>Pamplemousse</li>
<li>Ananas</li>
<li>Jus d'orange</li>
</ul>To iterate over a list and render the li element for each member, the common way to do it in React is something along the line of …
{this.props.menu.map((dish) =>
<li>{dish}</li>
)}In Elm, it goes like …
List.map ( \dish -> li [][text dish] ) menuNote that in Elm, map operator is not a method of the list type. It belongs to the List module. This is because Elm does not have class, and surprisingly so does Go.
It teaches functional
By coding in Elm, I was already learning how to think in a functional way. The error messages were indeed very helpful and quite precise too (as is quite common in typed languages).
It talks to Javascript
Elm can be compiled to an HTML file or it can be compiled and embed into another HTML file as a Javascript code. You can just simply insert it into a DOM of your choice and have a neighboring DOM owned by React. This interopability is really interesting considering Javascript is more mature and have much more useful libraries to your disposal.
Productive, productive, productive
As a web engineer, I pride myself for being language- and tool-agnostic. One of the first questions I ask myself when picking up something new is how soon will I be able to be productive with it. This is never just about the thing itself, but also its ecosystem. A good amount of tiny repeated wins are also very important; a slight disruption to early learning process can become demotivating at best.
At last, I’ve not only found a functional language I can finally stick to in the new year 2017, but also a language to make thinking in HTML fun again. to Javascribut to React, Angular, Ember, and all the Javascript frameworks. These all built into a simple language that does make learning in parallel with using it a smooth, frustration-free ride. Shifting your mind set to functional programming can be really overwhelming, and I dare say Elm gives me a soft transition I need.
