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.

   You can  skip over some steps -  miss out the names  for example (if
the problem is small) - but  if it is complex then name your processes
and  messages -  if things  have  got names  you can  talk about  them
otherwise you can't (which make life, and the design, difficult).

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

   Modelling static objects is a  matter of taste and programming style
and depends upon the nature of the problem.

   I often use a single process to represent all the static data.

   Suppose we have a town with  a thousand houses - suppose we say this
is a static  town (ie we decide  that there will be no  new houses, no
houses will be changed) - this  I'd model using a single town process.
Now internally the town process might spawn off 1000 house process, it
might stick everything into a big  ets table or use a dictionary - who
cares.  The important bit is that  the user only sees the protocol (ie
the messages) between the application and the town process and not any
internal details of *how* the town process is implemented.

   Note we are not doing OO programming here we are doing CO programming.

   In  Concurrency Oriented  (CO)  programming you  concentrate on  the
concurrency  and  the messages  between  the  processes.  There is  no
sharing of data.

   An Erlang should  be thought of thousands of  little black boxes all
doing things  in parallel  - these black  boxes can send  and receive
messages.  Black boxes can detect errors in other black boxes - that's
all.

   At  the  design level  of  abstraction  how  things work  internally
*inside* a  black box  is irrelevant -  the programming  language used
inside  a BB  be it  a functional  or imperative  or OO  or relational
language is irrelevant.

   Erlang uses  a simple functional language  inside the BBs  - this is
not particularly interesting - *any*  language that does the job would
do - the important bit is the concurrency.

   <polemic mode on>

   Most languages (ie virtually all languages except Erlang, and Oz (are
there  more????)   do  not  support  concurrent  programming  in  any
meaningful way.

   Java  provides  threads  (for   example)  <<  threads  are  kind  of
brain-dead  processes, some  bright-ideas guy  got the  idea  that you
could clump  together several different parallel computations  in such a
way that  the computations could  share resources and thus  crash each
other -- and thereafter and forever people have been trying to figure
out how to program  with them >> - but not many.  Can you make 100,000
threads in your latest Java system - try it << answer: no way>>

   The last time I tried I  could make a few (read small) thousand Java
threads before my machine slowed to a pathetic crawl and died.

   Suppose I had invented a new OO language and said to people:

   "Don't  use more that  2500 objects,  because if  you do  the system
won't work"

   Some might say "your language sucketh, and it is impossible to do
OO programming in your language".

   So for  Java and  C++ and  (all the rest  ...) I'd  "these languages
cannot be used for concurrent  programming - Why?  - because you can't
create tens of thousands of  processes and program the concurrency you
want.

   So why would you want to program in a concurrent manner?

   I'll give two reasons.

 	1) The world is concurrent
 	2) You might want to write reliable software

   1) - Yes - the world really is  concurrent - if you don't believe me
go and look  - modelling real-world activities as  a sequential stream
of events is difficult and error prone.

   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.

</polemic mode off>

/Joe