Erlang hints from an CO junkie

[Johan Warlander]

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

Johan