Meyer, OO and concurrency
Mon Jul 11 23:42:41 CEST 2005
> David Hopwood wrote:
>> todd wrote:
>>> Thomas Lindgren wrote:
>>>> I found this on a blog
>>>> "Bertrand Meyer had eloquently proven at ICSOC 2003
>>>> that OO cannot deal with concurrency very well, in
>>>> other words the granularity and programming model of
>>>> an object don't let you create (autonomous) "peers"."
>>>> Does anyone know more about this? I haven't been able
>>>> to find what Meyer's actual argument was, but it
>>>> sounds like what Some People have been preaching for a
>>>> while :-)
>>> That's absurd. Send a message to an active object that runs in its
>>> own thread. Done.
>> There's a bit more to it than that:
> There's always more and there's always less. I have created many large
> scale distributed OO systems.
But were they *just* OO systems, or did they impose some additional
constraints, and use additional abstractions, not present in typical OO
The abstract and slides for Meyer's presentation are at
clear from the slides that he is referring *only* to typical OO languages
with either shared-state (threads and locks/monitors), or no concurrency
support. From what I know of SCOOP[LI] (see
<http://se.inf.ethz.ch/research/scoop.html>), I'm skeptical that it solves
the problem, but the argument that there is a problem with conventional OO
support for concurrency is not controversial.
The blog that was mentioned above seems to be at
# OO has gone in about 15 years from a mind opener to a mind bottleneck.
# Why is that?
# If we consider that the paradigm shift that OO introduced was not a new
# programming model, but rather the introduction of modeling concepts into
# traditional programming language we might understand why today we are
# hitting a wall. It might also help us break that wall. Actually, this
# wall is a double wall. Today we need to evolve both the modeling
# capabilities and the programming foundation. Cw from Microsoft Research
# is the best proof of this double evolution. I have written many times
# about making the message a first class citizen of the programming language
# and enabling peer-to-peer computing (aka connected systems). Bertrand Meyer
# had eloquently proven at ICSOC 2003 that OO cannot deal with concurrency
# very well, in other words the granularity and programming model of an
# object don't let you create (autonomous) "peers". So I won't write much
# more on that, I would like rather to focus on "modeling".
This argument suffers from a lack of knowledge of the history of OO.
The changes that the author suggests wouldn't be an evolution; they would
be a return to the roots of OO in actor systems. "Peer-to-peer computing
(aka connected systems)" are what Hewitt wrote of as "Open Systems". Actor
systems supported and emphasised the use of first-class messages from the
The Join calculus concurrency model of Comega is essentially a reinvention of
the actor model (search for JoinCalculus in <http://c2.com/cgi/wiki?ActorsModel>,
> Would it be simpler if a shared nothing
> system was enforceable in C++ or Java? Certainly. I think Java really
> screwed up. C++ is, well, C++. Saying OO doesn't let you create
> autonomous peers simply isn't so.
But that is not what Meyer actually says; it is the blog author's
(Jean-Jacques Dubray?) fairly inaccurate paraphrase.
> Some of my own thoughts are at
No public editing?
David Hopwood <>
More information about the erlang-questions