Erlang hints from an CO junkie
Wed Aug 11 16:52:27 CEST 2004
On Wed, 11 Aug 2004, James Hague wrote:
> Joe Armstrong wrote:
>> 1) Identify the concurrency in
>> your problem. Give the processes
> 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
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
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.
More information about the erlang-questions