Maybe Erlang is OO after all?

[Joachim Durchholz]

Kurt at DBC wrote:
> This, ISTM, is also why in OO (admittedly Object Pascal, Java and 
> guessing at C++) threads are so difficult to manage, as they are 
> implicitly time-based, so the thread object can only _simulate_ being
> in a distinct state (either by polling or blocking) when it is
> actually in a different state during any time interval - and in no
> particular state at a given point in time.

I think this is more a problem of the way that OO is typically implemented.
C++ is particularly bad here: during construction, all calls are 
"nonvirtual", i.e. you can't use virtual functions to "do the right 
thing" during object initialization. Since there's a very common need 
for that, you end up using two-phase object construction: first 
construct the object, then initialize it. Which means you already have 
two object states, one of them quite unusable. Which, in turn, means 
that you have to manage a state for each and every C++ object. It's a 
pure mess.

It's also a problem of the way that OO classes are typically written. 
Programmers who design a class usually use stateful objects: the 
interaction with a caller is based on a series of microtransactions 
during which the serving object undergoes a series of state 
transformations. Usually, the object is in a state of "ready for 
requests", "executing request", "holding diagnostic data about the last 
request". The last and first state are usually the same.
With that design, again there's a lot of state involved. If a language 
makes it easy to package out-of-band data such as error diagnostics into 
results, and where it's likewise easy to disassemble that data on the 
caller side, then it's not necessary to have this. In other words: 
traditional programming languages are missing both tuples that can be 
defined and constructed with minimal syntactic overhead, and they are 
missing pattern matching on tuples.

I think these difference contribute more to the difficulties in OO 
design than any difference between time modelling. Actually, I don't 
understand the difference: you get exactly the same type of 
synchronicity problems if an object calls itself with virtual calls. Or 
if it passes itself to another object and gets called back.
This is exactly equivalent to an Erlang process sending a message to 
itself, or sending its id to another process with the intention of being 
sent back a message, with the exactly same uses and potential pitfalls.

A highly concurrent environment will, of course, exhibit more race 
conditions than a sequential one, but that's unrelated to the 
differences between OO and processess, it's the difference between 
parallel and sequential.

Just my 2c.
Jo