Erlang hints from an CO junkie

[Vlad Balin]

> 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
communicate
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
> all.

>   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
parse.

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? :))