threads - use them as much as you can

[James Hague]

Samuel Tardieu wrote:

>At the beginning of OO programming, programmers were
>told "Look, it is so nice, you do not call subprograms,
>you send messages to objects which will then react to
>those messages". This view was flawed, as the object
>was not reacting at all (it had no thread of control
>on its own), it just provided the caller with what to
>do (the method's code).

That is an excellent point.  The message passing terminology always
bothered me, as it seemed to be an elaborate way of saying "subroutine call."

How has Erlang worked for applications in which processes are used to model
static objects, rather than parallel processes?  Erlang is one of the
nicest languages I have ever used, but I'm not using the language in it's
intended domain.  I use it as a general purpose alternative to Python and
such, where processes provided an elaborate way of catching errors (for
example, spawning off a compiler task and putting the error reporting in
the controlling process).  I can see interesting some applications of
Erlang that use processes heavily, but not in a truly concurrent way (e.g.
a video game with a process per onscreen object).  The potential overhead
of message passing in such situations has put me off.  I should run some
experiments.

James