Erlang hints from an CO junkie

[Joe Armstrong]

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

   I wrote a tutorial about this at:

http://www.sics.se/~joe/tutorials/robust_server/robust_server.html

   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.

   Cheers

   /Joe

> Johan
>