Meyer, OO and concurrency

[David Hopwood]

todd wrote:
> 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"."
>>>>
>>>> http://www.ebpml.org/site_updates.htm
>>>>
>>>> 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:
>> <http://www.erights.org/talks/promises/paper/tgc05.pdf>
>>
> 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
languages?

The abstract and slides for Meyer's presentation are at
<http://www.unitn.it/convegni/icsoc03_keynote_speakers.htm#2>. It's
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
<http://www.ebpml.org/site_updates.htm>:

# 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
start.

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>,
and <http://cliki.tunes.org/Actor>).

> 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 
> http://www.possibility.com/epowiki/Wiki.jsp?page=ArchitectureDiscussion

No public editing?

-- 
David Hopwood <david.nospam.hopwood@REDACTED>