Coming from the .Net foie gras farm, I was very surprised to find this video on Microsoft’s marketing channel (aka Channel 9), where Charles interviews Joe Armstrong, across from Mads Torgersen, from the C# team.
Mads introduces himself as “…brought up in the true faith of Scandinavian object orientated tradition…all programming is about modelling…”. When Joe was asked to comment on that, he bluntly responds: “I don’t like object orientated programming…”
The interview just before that was with Dave Thomas (ala Eclipse), which had the same tone about modelling solutions, and how OOP is not always the best approach. In fact, I got the impression that OOP (at least the way we know it) is hardly ever the right approach.
I was compelled by these interviews to pick up a new language. But what? As I reflected on what I liked about my current tool set and what not, I realized that I was leaning more and more towards describing “what to do”, rather than “how to do it”. Take LINQ for example, since I think it succeeds in being very declarative: “from this collection of foos, group it by bar and project bas”, instead of “foreach loop, hash tables, enumerator yields.” It is not hard to figure out what is going on in the LINQ statement. So what enables this kind of programming? Where does it come from?
Cue the Star Wars intro: “A long time ago, in a programming galaxy far, far away…there were List Comprehensions and Functional Languages.” Come to think of it, languages that have become popular in recent years, all support functional programming, like Scala and Ruby. Then there is the uptake in pure functional languages like Haskell and Clojure. Erlang is a functional language with single-assignment, that felt dynamic (even though it’s not) and this was pretty much as opposite from C# as I could get.
At the same time, we (as in Firmex) where struggling with scale and reliability headaches, and no matter how many “Microso-buprofens” we took, we couldn’t kick the headaches. (This topic is worth many articles by itself, but worth noting as part of the context of what got me into Erlang.) Erlang’s native support for process distribution and monitoring seemed to address the distributed computing idioms we were struggling to implement.
In future articles I will share some insights using Erlang, like syntax (for some reason people get really scared when they see Erlang code), how spawned Erlang processes can be thought of as instances of objects, OTP and other Erlang conventions.