Maybe Erlang is OO after all?
Mon Aug 25 11:22:05 CEST 2003
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
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.
More information about the erlang-questions