Erlang and OO
Erlang is a functional language, something that worries a long time OO programmer, especially when said programmer is starting a new project in it. My background is predominantly in OO languages that Alan Kay did not have in mind when he coined the phrase OO. I have used Smalltalk in an academic environment, never commercially.
OO is amongst the more subtle concepts used in programming. Besides silly interview questions involving OO modelling of living rooms and bathrooms, attempting to apply OO concepts in real life commercial programming is harder. However, once indoctrinated in the OO ways as currently practiced in the industry, a language like Erlang can look pretty weird, there are no classes, no objects in the Java sense. How does one ever model the nouns as objects and the verbs as methods ?
Look up OO in a textbook and you will find words like encapsulation, polymorphism and inheritance thrown about. Of these, encapsulation is probably the single greatest contribution OO has made to the discipline of thinking about organizing a software system. After having used Erlang over the last few months, Alan Kay is right (it does appear that Turing award winners usually are) message passing is what I need to achieve encapsulation. Far more important than the use of a narrowly defined construct like a class or even an object, the way Java or C++ define them.
Message passing implies encapsulation, the entities passing messages to each other do not have any knowledge of the each other’s innards. Their only contract is the message. Each side must understand the other side’s message or fail gracefully. It so happens that message passing is at the core of Erlang.
Once you break the shackles of narrow definitions of what an object is, turns out that a far more powerful abstraction of an object as a component emerges. A component constructed internally of many modules (files in the most general sense), exposing a contract, a contract composed entirely of messages. I can not only build these easily in Erlang, I can take the notion of encapsulation one step further.
Erlang comes with a built-in database called Mnesia. Mnesia is a standard library and can store any Erlang data structure. I can now encapsulate even the persistent state/representation of my component (complete with transactions). The component (or application as it is called in Erlang) is a completely independent entity with all it’s external dependencies and the services it offers specified in message oriented contracts.
Unfortunately, the contracts themselves cannot be formally specified in a language construct. Erlang is dynamically typed and so are the messages. In addition, many of the messages can be passed asynchronously, a recipient can fail “silently” if it cannot grok the message. Loose coupling can be good and bad, I prefer to leverage the good and work to avoid the bad. Erlang is the closest I have ever come to reusing software components which are not stateless lumps of code in the form of a library.