Erlang hints from an CO junkie
Wed Aug 11 14:02:19 CEST 2004
My ten cents:
I always tell people this:
1) Identify the concurrency in your problem. Give the processes
2) Identify the message channels - give these names.
3) Write down all the messages that are seen on a channel, give
In doing this you have to chose a "granularity of concurrency" that
is appropriate for your problem.
If you are modelling crowds then one process per person would be
appropriate, you would not model a person as 10^26 molecules with one
molecule per processes.
You can skip over some steps - miss out the names for example (if
the problem is small) - but if it is complex then name your processes
and messages - if things have got names you can talk about them
otherwise you can't (which make life, and the design, difficult).
Modelled objects should be either static or dynamic. Here you have
to make you mind up and not change your mind later. An object cannot
be static then later dynamic and back to static (in this case it
should have always been dynamic).
Modelling static objects is a matter of taste and programming style
and depends upon the nature of the problem.
I often use a single process to represent all the static data.
Suppose we have a town with a thousand houses - suppose we say this
is a static town (ie we decide that there will be no new houses, no
houses will be changed) - this I'd model using a single town process.
Now internally the town process might spawn off 1000 house process, it
might stick everything into a big ets table or use a dictionary - who
cares. 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.
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.
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.
<polemic mode on>
Most languages (ie virtually all languages except Erlang, and Oz (are
there more????) do not support concurrent programming in any
Java provides threads (for example) << threads are kind of
brain-dead processes, some bright-ideas guy got the idea that you
could clump together several different parallel computations in such a
way that the computations could share resources and thus crash each
other -- and thereafter and forever people have been trying to figure
out how to program with them >> - but not many. Can you make 100,000
threads in your latest Java system - try it << answer: no way>>
The last time I tried I could make a few (read small) thousand Java
threads before my machine slowed to a pathetic crawl and died.
Suppose I had invented a new OO language and said to people:
"Don't use more that 2500 objects, because if you do the system
Some might say "your language sucketh, and it is impossible to do
OO programming in your language".
So for Java and C++ and (all the rest ...) I'd "these languages
cannot be used for concurrent programming - Why? - because you can't
create tens of thousands of processes and program the concurrency you
So why would you want to program in a concurrent manner?
I'll give two reasons.
1) The world is concurrent
2) You might want to write reliable software
1) - Yes - the world really is concurrent - if you don't believe me
go and look - modelling real-world activities as a sequential stream
of events is difficult and error prone.
2) If you want to build reliable software (read fault-tolerant
software) you will need to use at least two computers (one won't work,
'cos if it crashes you're screwed) - If you use two or more computers
you're into distributed concurrent programming whether you like it or
</polemic mode off>
More information about the erlang-questions