Erlang hints from an CO junkie
Wed Aug 11 17:06:32 CEST 2004
On Wed, 11 Aug 2004, Johan Warlander wrote:
> On Wed, 11 Aug 2004 14:02:19 +0200 (CEST), Joe Armstrong wrote
>> re: OO
>> 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
>> these names
>> 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.
> I'll try it out and see what I end up with :) One question, however.. what's
> your definition of a message channel above - the stream of messages between
> different process roles? (Such as person <-> person, room <-> person if a room
How about "the name of a set of messages between a pair of processes".
If you have people processes and room processes you'd have several
message channels people-people room-people etc.
> was also a process, etc..)
>> 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).
> This would suggest, in my case, to make almost everything dynamic from the
> start. Breaking up the world into smaller pieces, the only really static
> things I can see are 'faked' details about the environment. For example, a
> room (dynamic) has a description and an inventory. The inventory consists of:
> 1) permanent objects that cannot be moved, but with which you can interact
> (chairs to sit in, tables to put things on..),
> 2) items that can be picked up and moved around, and with which you can
> interact (candles to be lit, apples to be eaten..),
> 3) decorative details of everyday things that can be found in rooms, but
> which are not important enough to warrant spending resources on interaction -
> basically you can look at them, try to get them, kick them, etc, but all you
> get is a textual response (wallpaper, pictures, the crack in the wall..).
> Out of these, 1 and 2 would be dynamic and 3 could definitely be static. Of
> course, that's not so bad.. because while a room might have two or three
> permanent objects, and a varying number of items people drop there, it might
> easily have ten to twenty details. Thus the static items will probably end up
> in majority.
>> 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 not.
> Sort of an off-topic question I guess.. Given that client connections are
> simple telnet sessions, would it be easy to make it so that with two servers,
> if one crashes then the only thing that happens is you get disconnected, and
> as soon as you connect to the other server again you get back into the game at
> the point you dropped off? This would be nice to have.. and simple with the
> round-robin behaviour of DNS, even without specialised clients.
YES - *hooray* - you're getting the idea now.
Now here's the good news - if you design you application correctly
the transition from the single node case to the multi-node fail-over
design will be trivial. This is exactly how many application are
I wrote a tutorial about this at:
This is a pair of servers (representing a bank) on two different
machines - you do stuff on one machine, if that machine fails you go
to the other one and carry on as if nothing had happened.
<< all you need is another trillion lines of COBOL and you've built
a banking software system :-) >>
Must run - It's very hot so I have to go and throw myself in a lake.
More information about the erlang-questions