Object-oriented processes
In his dissertation (PDF), Joe Armstrong argues that object-oriented approaches to concurrent programming are difficult to make work. This struck an odd chord with me, because I think it stems from a C++/Java-centric view of object-oriented, but if we go back to the source we have the following bits of definition of the nature of object-orientation:
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.
So, messaging is a core of both OOP and what Armstrong calls Concurrency Oriented Programming. In both cases, the concept of messages are used as a strong isolation mechanism to keep one piece from peering into another and fiddling with the internals. In the case of Smalltalk, for example, that “piece” is an Object. In Erlang, it’s a Process.
For local retention and protection, one can easily compare the nature of the hard crunchy protection around a Smalltalk Object, which requires a message to retrieve anything from it1, and an Erlang Process, which is a totally isolated virtual machine. I believe Erlang takes this technique even further than Smalltalk does by effectively creating a virtual machine for each Process. There is nothing, however, that prohibits Smalltalk from doing the same, other than historical artifacts of implementation.
Next, we have the extreme late-binding, which allows for polymorphism and other things in the Smalltalk world. It’s difficult to actually compare these on a strict technical basis, as Erlang generally uses immutable variables and pattern matching, and Smalltalk uses mutable variables as handles to potentially immutable Objects. What I think is in common between the two is the desire to leave flexibility to the programmer and not attempt any form of premature hand-typing.
Honestly, I think that there’s a lot more in common than Joe gives credit for, and the nature of decomposition in Erlang into collaborating processes are similar in spirit to the nature of decomposition in Smalltalk that is done. For example, in implementing a IRC-like server in Erlang in his book Programming Erlang, Joe identifies 5 process types needed to implement it, and while 2 are artifacts of the specific implementation (UI and the Middlemen), 3 aren’t:
- Chat client
- Group controller
- Chat server
Those are ordered from bottom to top, effectively, and are not strongly different than how one might implement it in Smalltalk, potentially even using light-weight processes in Smalltalk to get there. If I get time soon, I’ll probably transliterate some of his implementation in Erlang into Smalltalk just to compare the two models.
1 Yes, you can do it other ways, but they are painful, and obviously “for emergency use only”.
This entry was posted at 2:21 pm on 16 August 2007 and is filed under Erlang. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
I don’t want to speak to intent, only my interpretation, but here’s a few excerpts from the dissertation:
Note that COPLs must provide true concurrency, thus objects represented as processes are truly concurrent, and messages between processes are true asynchronous messages, unlike the disguised remote procedure calls found in many object-oriented languages. (p. 22)
I think here Armstrong over-reaches a bit, as RPC is more like a disguised function call in most languages. Messages in Smalltalk are synchronous, and that does potentially make creation of the type of fault tolerant systems that Erlang is designed for more difficult, but I do not think it necessarily makes concurrency itself harder.
Bryce’s argument, while true, does not argue the same thing that Armstrong states, which is that aliasing is difficult to detect in practice. This might be true with Java, but it is certainly not true with Smalltalk. Simply examine the nature of
Object>>become:which swaps out objects from under everyone, and is commonly used in Smalltalk systems. Other than Objective-C, which is strongly influenced by Smalltalk, I’m not aware of any other system that has a similar capability. Some languages have some hacks to try and do this, but they often fail in practice as he mentions.As such, I think that the difference is between message-oriented languages (such as Smalltalk and Erlang) and other more traditional approaches to solving the problem. This is not to say Erlang might not make some of these things easier than in most any other system, but I believe he paints with a slightly soiled brush when he makes the generalization about object-oriented systems.
In fact you can see the similarity/overlap by looking at simple “OO” classes implemented in Erlang in http://www.angelfire.com/tx4/cus/shapes/erlang.html
Those examples kindof miss the point since there’s no need to make erlang look like common OO implementations (with a new() function and so forth), but it’s a useful example for the discussion here.
petrilli wrote “only my interpretation”
Maybe your interpretation misses out the bits that Joe Armstrong regarded as essential – he listed the characteristics for his notion of “true concurrency” and it seems you are talking about some other idea of “concurrency”.
petrilli wrote “Bryce’s argument, while true, does not argue the same thing that Armstrong states, which is that aliasing is difficult to detect in practice.”
Bryce wrote “Aliasing is difficult to detect …” p107
petrilli wrote “This might be true with Java, but it is certainly not true with Smalltalk.”
I’m interested in how you think continual need to detect references to method arguments would play out in practice – wouldn’t we be spending an awful lot of time trying to detect references at run time?
The Bryce quote is from “An Approach to Safe Object Sharing”
http://asg.unige.ch/index.php?cat=bibliography&type=details&id=245&typepublication=Unpublished
What’s the markup for these comments? HTML was stripped.
Why should I use Erlang, and not Scala for example?
No idea, I’d recommend making your own decisions, I generally am not an advocate.
You can leave a response, or trackback from your own site.
”... Joe Armstrong argues that object-oriented approaches to concurrent programming are difficult to make work.”
I see where he writes
“Bryce goes on to say that object aliasing is difficult if not impossible to detect in practice, and recommends the use of protection domains (akin to OS processes) to solve this problem.”
and
“Bryce and Razafimahefa argue that is is essential to isolate programs from one another, and from the programs which run in the host operating system. This, they consider, is the essential characteristic that any object system must have. As they point out in their paper, this is a difficult problem in an object-oriented context.”
is that what you’re referring to?
afaik Smalltalk messages happily share object references – how is that like “the level of isolation that Erlang exhibits”?