Jamison Dance hit a home run at his React.js Conf 2016 keynote. Here’s the YouTube of his 30-minute presentation, talking about a new programming language called Elm. He’s exactly the sort of person I love working with: intelligent, humorous, experimental. His presentation wasn’t looking to teach us how to program in Elm, but rather why we should want to learn to program in Elm. At a high level, here were his reasons:
- Elm has a strongly typed system so that you don’t have to spend as much time worrying about the edge cases of your data flow. Functions have to return specific values, not just anything. Oh, and they don’t allow
nullas a return value.
- Elm only allows stateless or “pure” functions. In other words, the only things that the function can use are things that are passed to it. This means that no dependency injection or mocking is necessary to test the function, and it’s a lot harder to right buggy functions that have unexpected outcomes.
- Data is immutable. A function that takes in a user object, for example, can’t modify that user object directly. It can only return a copy of that object.
Underlying Jamison’s presentation was a quote he gave from Edsger W. Dijkstra:
The competent programmer is fully aware of the strictly limited size of his own skull.
Elm was built with this limitation in mind. It handles stuff that computers are good at so programmers can handle the stuff humans are good at: building user experiences that are unique to a given application’s domain.
This isn’t to mention the subtle memory gotchas you can inadvertently slip into.2 For instance, since arrays are referenced by memory, you can create two variables pointing to the same array. Modifying an item of that array will modify both variables. If you perform the
concat() on one of those variables, however, you’ll split the references, since that function returns a new array. Check it out:
var myArray = ['red', 'white', 'blue']; var copy1 = myArray; myArray = 'green'; console.log(myArray); // ["red", "green", "blue"] console.log(copy1); // ["red", "green", "blue"] myArray = myArray.concat('orange'); console.log(myArray); // ["red", "green", "blue", "orange"] console.log(copy1); // still ["red", "green", "blue"]
- Am I entering a rabbit trail here, just because I want to talk about a bug that took me an hour to figure out the other day? Absolutely. Would stuff like this not be possible with Elm? I’m honestly not sure since I haven’t worked with it yet, but for the purposes of this article and the sake of argument, let’s say it couldn’t. ↩︎