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.
13. July 2008 at 08:15
Just heard about Erlang. Thanks for a good overview that explains the difference between Erlang and OO.
13. July 2008 at 12:02
OOP is the programming paradigm which took over the mainstream from Structured Programming.
As you noted Functional Programming is a different beast, although it is quite old (see LISP), it has never become mainstraim, although programmers with academic background will praise it. Maybe because it is more mathematical.
Another different programming paradigm is Declarative Programming (where you tell the system what you want and the system has the freedom to figure it). Prolog is an example and is also very mathematical, deeply rooted in Logics and formal proofing.
11. March 2009 at 20:15
I would argue that the most valuable contribution of the OO paradigm is its use of polymorphism, which in essence refers to the same thing as message passing. “Primitive” languages like Java and C++ implement message passing in the form of interfaces and abstract classes. The Smalltalk implementation of message-passing simply allows for more runtime flexibility at the cost of performance. As you say, polymorphism implies encapsulation because you don’t know how the interface is implemented, but that the object should adhere to the contract defined by the interface it publishes. Languages like Java can implement many ideas from the functional world, though the syntax needed to do so is sometimes unattractive.
12. March 2009 at 02:34
Joe Armstrong, the creator of Erlang, is fervently anti-OO. Here is an article called “Why OO sucks” that he wrote some time ago, which explains why Erlang is so devoid of any OO concepts (probably one of the main reasons why Erlang failed in the mainstream):
http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
12. March 2009 at 03:19
How well do you think an actor-based language like Erlang but with static typing would work? That way object protocols could be more formally established.
12. March 2009 at 12:38
I appreciate your precise formulation of a strategy that I feel has guided me throughout my work as a software developer: I also try to leverage the good sides of things, and avoid the bad ones.
My sincere gratitude for sharing your expertise!
12. March 2009 at 15:35
I’m overjoyed at the sudden abundance of erlang-related information. Hooray!!
12. March 2009 at 17:00
Erlang uses the Actor model, which is similar yet orthagonal to OOP:
http://en.wikipedia.org/wiki/Actor_model
13. March 2009 at 09:09
A more mainstream example of a Declarative Programming language is SQL.