Meyer, OO and concurrency

[Peter-Henry Mander]

Hi Gurus,

Sorry but I've got to stick my oar in.

I've found that modelling a OO system in Erlang recovers the original
concept of objects as concurrent actors. A long time ago (circa early
1990's) I was taking baby steps in OO programming, and I naively
couldn't understand at the time why the 'method invocations' or
'messages' to objects were not asynchronous, and that objects couldn't
perform background tasks implicitly. I then found that the 'message'
concept was modeled using function calls, and was disappointed that I
was shackled to a single thread of execution in my programs due to this
lobotomised implementation. I even embarked on writing a basic
preemptive RTOS for the Atari ST (remember them?) to enable me to create
an environment that enabled me to use *real* Objects with asynchronous
message passing! I'm proud to say it worked, but it sadly didn't get
very far, at the time I wanted to be a cartoonist!... *cough*. (I never
claimed to be wise).

Fast forward to Erlang, and suddenly the shackles are gone. Server
processes with asynchronous messages are to me the distillation of what
Objects should have always been. Hurrah!

I ask myself *why* has it taken soooo long to recognise the need for
concurrency? But then again, the OO paradigm took a *very* long time to
become mainstream. I don't believe that OO ever meant the same thing to
all people, it's become a desperately twisted (polymorphic? overloaded?)
concept. To me the original Object concept _is_ concurrent.

And as for imperative vs. functional, if the shoes fit and you can wear
more than one at a time... :-)

Oh well. Rant over.

Pete.

On Mon, 2005-07-11 at 19:31 -0700, todd wrote:
> David Hopwood wrote:
> 
> > But were they *just* OO systems, or did they impose some additional
> > constraints, and use additional abstractions, not present in typical OO
> > languages?
> 
> Well, as I build abstractions in OO I don't feel making new abstractions 
> is unreasonable :-)
> You could make a usable system with an Actor and some sort of TCP/UDP 
> abstraction.
> I have made that portable across many different operating systems with 
> little difficulty.
> For generalized messaging use XML. Of course in a real system you need 
> timers, semaphores,
> ISRs, TSS, etc.
> 
> The problem I found is programmers can't help but access data structures 
> across
> threads, so I would like language support to prevent it or to at least 
> have it
> turned on by command. There are some cases in critical algorithms that I 
> wouldn't
> mind the ability to share data structures, but certainly not by default.
> 
> > 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.
> 
> As long as the underlying language support libraries and features are 
> thread safe there
> is nothing stopping you from building what you need.
> 
> >
> > No public editing?
> 
> After much public defacing I stopped allowing public editing.
> 
> 
> 
-- 
"The Tao of Programming
 flows far away 
 and returns 
 on the wind of morning."