Erlang hints from an CO junkie

[Joe Armstrong]

On Wed, 11 Aug 2004, James Hague wrote:

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

I never said identifying the concurrency patterns were easy :-) - they
have to be "appropriate" for the problem.

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

   Well the first  ever Erlang was a prolog  meta-interpretor to extend
Prolog with concurrent processes.

   This  approach   became  problematic  since  you   needed  to  avoid
backtracking after you had sent a message.

   We didn't really want backtracking  to "unsend messages" etc. and so
we arrived  at a  Prolog without backtracking  and things  drifted off
towards a more functional view of the world.

/Joe




>