01 December 2007

Erlang, the functional Smalltalk?

Let’s start with a confession. I’m not a Erlang weenie, I’m not even a decent part-time Erlang hacker. But for some reason, I keep coming back to it, even through I don’t normally work in the problem domain I think Erlang is best suited for, like servers of various kinds (from MMORPG games to Jabber), or large scale, distributed applications. But in this case, it works differently - I keep coming up with problems that could be nicely solved in Erlang, instead of matching the language to the problem.

I wrote about the great fun factor of programming in Erlang before, but I didn’t quite get the reason this is the case. Now, after thinking about for a while, I think I know what Erlang does so well, that it makes programming a joy.

You see, Erlang creators criticize OOP eagerly, distancing from it as much as possible, which is a bit misleading. I believe Erlang is the quintessentional cross between object orientation and functional programming. Even through Erlang doesn’t have implict support for “objects” of any kind, it does have processes. Contrary to what the Erlang crowd says, they seem to share all the common properties of object/classes in traditional object oriented languages - they capture state, express behaviour and you can even (sort of) inherit a process from another process or compose them, if you think this is necessary to call something object-oriented, and/or if you think this has use in Erlang. You can also build reusable components with them, as you can see for example in the OTP behaviours.

This is a simple observation, but it has some strong consequences - this programming model seems to has some unique advantages. I observed that while using traditional OOP, I tend to think much more about classes, one piece at a time, thinking in terms of fields/methods. Erlang shifts the focus from classes/methods/state towards interactions, or messages crossing, between objects/processes in time. Also, you think about the whole thing at once, about all the components involved and cooperating in solving a subproblem/problem of your program. To put it in another way, you don’t think only about the internal construction of the entities involved, but you also think about how they’re playing together to solve the problem. It feels like the concurrent language was promoting more “concurrent”, cooperative, big-picture thinking. Than, when you get the picture, you can compose the the bigger things (processes) from little, stateless functions doing the things you want.

As a result of this paradigm change, it seems that it’s easier to write more modular and coherent applications. It doesn’t even have anything to do with so-called “concurrent” programs, think of it for a while. Aren’t objects in your traditional language exchanging messages all the time? Aren’t they independent “beings” exisiting concurrently in some “space”? That’s where the title reference to Smalltalk came from. Erlang only removes the limitation that only two object can talk to each other at a time (when your traditional program isn’t threaded, and I’m talking concept-wise, not implementation-wise). At the same time, the functional nature forces you to use as small amounts of state as possible, which in consequence rewards writting very small modules.

Obviously, they are also strong differencies ie. you have many things in Erlang that aren’t at all realized using processes, whereas in “true” OO languages everything is an object. Processes aren’t also used as a data type, as you have records and tuples for this. Still, through, the essential modelling is done using processes. I believe that what Erlang does with them is the best way you currently can cross a variant of object orientation with functional programming, even if concurrency isn’t a priority. It certainly seems much more reasonable than trying to fit the traditional model with classes to the functional world.

Joe Armstrong certainly knows all this, and talks about it between the lines sometimes, but I didn’t seen it discussed in depth anywhere. For some more insight into the language, you may want to see this great talk with Joe: part1, part2, and also this article on oop.

Comment