Object Oriented Programming

Programming languages use different paradigms, nowadays the most used is the Object Oriented paradigm. Object Oriented Programming was an attempt to simplify the creation of softwares because they were more and more complex.

The idea was to model the software with objects (a car for example) with some attributes (it has wheels, a motor, etc.) and some methods (start, move forward, etc.). Objects alone are not enough, they need to be able to communicate with each other by sending messages.

I have worked for several years with Java, a well known OOP language, and I'm now working with Erlang, a functional language.

A functional language has functions as first class citizens. Functions should be stateless, they get some parameters and return a deterministic result. Seems not enough to design complex softwares.

An other feature of Erlang is the concurrent paradigm. It allows the language to do a lot of tasks in parallel. At first, most people think about this feature has a great tool to distribute calculation and/or use all the cores of a modern CPU with no burden. I thought the same thing. But this is not the aim of Erlang. Concurrent processes are used for software design. A process is a system, mostly representing a real life system, sending and receiving messages from other processes.

After using Erlang for a while (I'm not a very fast thinker, or maybe I just don't think too often 😉), I realized that Erlang is the most Object Oriented Language I have ever seen.

It matches the definition of OOP more than any other language. Objects are processes (with an internal state) talking to each others by sending messages.

Why? Because Erlang allows you to have several thousands threads (objects) running simultaneously, where other languages allows you to have several thousand objects running in few concurrent threads (so if you have X threads, only X objects are running simultaneously). In Erlang objects are really independent from each others, while in languages like C++, C# or Java, objects are executed sequentially.

Interestingly, if they share the same base idea, those languages need a completely different approach. One of the big differences is that talking between objects in Erlang is done by passing messages while it's done by methods calls in traditional OOP languages.

In those languages we do not deal very often with multiple threads and we tend to not have threads talking with each others because it needs locks and synchronization. Erlang deals with that very easily.

So in an OOP language like Java, when a thread dies, a lot of objects dies, maybe the whole software, that's may be not so bad (kind of fail fast approach). In Erlang, when a process dies, it's just an object, everything else is still running (when a car crash, the neighborhood does not disappear), but this can lead to some unknown state (imagine a firm where the boss dies and nobodies notice it (and are glad to not receive orders anymore ;-))). Erlang provides some tools to manage that. Processes can be linked together, when a process dies, it sends a death note (sorry 😉) to processes it was linked to. When a process receives such a message, if it does not know how to handle it, it dies too (my wife is dead, I'm lost, I must commit suicide), but of course it may know what to do with the message, like restarting a process like the dead one (let's find a new wife). In Erlang's libraries there are such modules, called supervisors, specialized in re-spawning a process when it dies. It may looks like overhead, but I think it's very useful to create robust and fault-tolerant applications.

Anyway, I have the feeling that in the Erlang's community, there is a strong opinion against OOP. I think I will have understood how to design softwares in Erlang faster if people told me first that Erlang is true OOP and why and how. Moreover, it may bring more people to Erlang to develop the language and reduce the number of people asking for such and such OOP feature that are already in Erlang but not the way they are thinking about it.

Ralph Johnson has an interesting (and short enough) article about Erlang being the next Java.

Same thing was discussed on PlanetErlang.