Erlang hints from an CO junkie
Wed Aug 11 17:33:10 CEST 2004
> The important bit is that the user only sees the protocol (ie
> the messages) between the application and the town process and not any
> internal details of *how* the town process is implemented.
> Note we are not doing OO programming here we are doing CO programming.
Well, from the design point of view, you're describing OO approach in terms
of Alan Key.
"Objects are the base building blocks, objects has the state, objects
with each other using messages." See citate below.
> In Concurrency Oriented (CO) programming you concentrate on the
> concurrency and the messages between the processes. There is no
> sharing of data.
> An Erlang should be thought of thousands of little black boxes all
> doing things in parallel - these black boxes can send and receive
> messages. Black boxes can detect errors in other black boxes - that's
> At the design level of abstraction how things work internally
> *inside* a black box is irrelevant - the programming language used
> inside a BB be it a functional or imperative or OO or relational
> language is irrelevant.
The first Smalltalks were in the middle of the progression of
designs. The objects in Smalltalk-72, for example, implemented a kind
of top down recognizer that parsed the messages and responded. There
were no separate methods, and each object was essentially a looping
process (like a machine on the internet) waiting for a message to
This is very similar to where several Prolog derivatives got to later
on (including Erlang). Hewitt's Actors used this idea in many
interesting and important ways.
- Alan Key
> Erlang uses a simple functional language inside the BBs - this is
> not particularly interesting - *any* language that does the job would
> do - the important bit is the concurrency.
Not only the functional language, but very _slow_ functional language,
with boxed computations and dynamic typing. Also, it should be unsafe
since it's not easy to check types at compile stage.
If language is _really_ irrelevant, why should you recommend anyone to use
slow and unsafe Erlang? This simple functional language has a number
of obvious disadvantages. Why not Smalltalk, for example? :))
More information about the erlang-questions