Erlang hints from an CO junkie
Wed Aug 11 15:47:01 CEST 2004
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
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
> 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.
More information about the erlang-questions