Erlang hints from an CO junkie

James Hague <>
Wed Aug 11 15:58:06 CEST 2004


Joe Armstrong wrote:

>   1) Identify  the concurrency in
> your problem.  Give the  processes
> names.

This can be tricky, in that there's faux concurrency in many problems.  That
is, things may appear dynamic, but in reality they're static.  For example,
in a video game, it is tempting to model each critter in the game as a
process.  In a single-player video game, though, there is no true
concurrency.  Each object moves in a lock-step fashion, once per frame.  You
could still use processes, but it's more a method of organization than a way
to handle concurrent activities.  Once you make this a multiplayer networked
game, then all of a sudden real concurrency jumps into the picture, in that
sending and receiving network packets can happen at the same time as other
processing.

> Erlang uses  a simple functional language
> inside the BBs  - this is not particularly
> interesting - *any*  language that does the
> job would do

I disagree here, but I'll go along for the ride :)  If the functional aspect
of Erlang is not interesting, then it seems an odd choice.  Wouldn't it have
been better to go with something that feels more comfortable to most
programmers?  Has replacing the functional part of Erlang ever been
considered?



More information about the erlang-questions mailing list