In an earlier posting I commented on the similarity between Alan Kay’s definition of “object oriented programming” and Joe Armstrong’s “concurrency oriented programming”, especially as instantiated by Erlang. Julian Doherty took exception with my perspective, and in a most amusing way. I think what we have is a failure to communicate.
What I was attempting to say is that COP and OOP shared a large overlap of concepts, not that OOP and COP were the same thing, or that one was a subset/superset of the other. All approaches encapsulate metaphor and support it through language design. While Alan Turing is right, that once you reach a certain point, anything is possible, different designs encourage and discourage different approaches. Edsger Dijkstra once said that “you can write FORTRAN in any language,” and he could not have been more true.
My attempt, conversely, was to find the intersection in metaphor between two languages, and their approach. They are substantially different, and yet, underneath, there are some similar metaphors: encapsulation, message passing, etc. As Alan Kay observed, it takes multiple metaphors to compose OOP, and Joe Armstrong used another set. The fact that they intersect does not mean they are the same.
Hopefully, this clarified it a bit. The Venn diagram tries to explain:
There. Clear as mud.
No thoughts
Seriously, check this out:
You want to know what I really think of Erlang? Erlang is crap. That’s what I think. Now don’t feel bad if you are an Erlang fanatic. And please don’t get mad. I always tell it like I see it. That’s my style.
Now, seriously, what? Read his agenda then come back. Yowza. Someone call the people in the padded white van. Seriously. I’d respond, but it’s loaded with so much BS. This is priceless:
My question to Erlang supporters is this. If functional programming was all that it’s cracked up to be, why did Joe Armstrong (et al) felt it necessary to provide a method for failure localization? No need to answer. Joe alreeady [sic] did. He assumed that “large systems [written in a functional language or not] will probably always be delivered containing a number of errors in the software.” By contrast, the COSA philosophy is that software should never fail, period.
Oh, I’m glad he’s got a philosophy that can make people infallible. I certainly know my perspective has been all that’s been keeping me from total and complete perfection in all that I do. Yes, that’s exactly the problem. Or, maybe, just maybe, Joe, along with most rational people, believes that mistakes happen and that it’s necessary to adapt to them and react to them. Crazy talk.
1 thought
One of the things about Erlang that is most interesting is the rather unique perspective on how to handle errors: you don’t. You die. You crash, and you let someone else pick up the pieces. In the case of Erlang, there’s a well formed framework for Supervisors, which are responsible for the maintenance of the system. Not planning for bad input (or return values/messages) is an interesting approach, but one that permeats the Erlang system.
Come to think of it, in some ways it reminds me of Common Lisp’s conditions and restarts. Different infrastructure, somewhat similar idea. Let someone else deal with it.
No thoughts
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”.
7 thoughts
With all the light on Erlang of late, I thought it’d be worth taking a second look at it. I had looked at it briefly several years ago, but not found any mental traction at the time. So, in order to manage to learn enough to be dangerous, I bought the latest book and started reading it. And here’s a few thoughts:
- If someone had said “this was originally just a Prolog derivative” then I would have gotten things faster. It should be obvious, and it is in retrospect, but it wasn’t at the time.
- The value of Erlang is not as much in its specific linguistic strategies, but in the infrastructure that the language and OTP library provide for writing bullet-proof software.
- Concurrent programming is hard. If you look at the use of behavior strategies in Erlang, you can see the understanding that “flawless” concurrent code can not be written by just anyone, but instead, give the average programmer a place to plug their sequential code into and gain the concurrency.
One thing that does bug me, as it seems to occur both in Joe’s dissertation and in much of the community, is some mistaken perception that object-oriented designs are not capable of the level of isolation that Erlang exhibits. This might be true of the implementations that are popular, but it is not, in my view, a result of the model. Smalltalk, for example, is a strict message-passing language, as is Erlang, and a different implementation could exhibit the level of isolation that Erlang does.
No thoughts