Advantages of a large number of threads cf other approaches?

[Richard A. O'Keefe]

	> > * Simulations - why use an object per thread rather than a "classic" 
	> > OO approach?
	> 
	>   This depends  upon the  simulation - if  you are modeling  the real
	> world  then mapping  each concurrent  object  in the  real world  with
	> exactly one  concurrent processes bridges between the  gap between the
	> model and  the simulation code in a  very natural way -  the code will
	> almost "write itself".
	
	I've heard this said before (and have read code samples etc) but I 
	keep feeling I'm missing something. It's so easy to have all your 
	objects inherit from a Smalltalk/C++ base class with an update method 
	and loop through all of them.

No, it's not particularly easy.  The two "classic" object-oriented
programming languages that people tend to have heard of are Simula-67
and Smalltalk-72.  Now Simula-67 was developed precisely to support
object-oriented simulation.  But Simula had TWO key features.  OO was
one, and (simulated) concurrency was the other.  Simula simulations
basically used co-operative multithreading.  Bjarn Stroustrup, who
invented C++, was familiar with Simula 67, and invented it in order to
do the kind of simulations he was familiar with in a C-friendly/Algol-hostile
milieu.  Surprise surprise:  the Cfront implementation of C++ from AT&T
had TWO key features.  OO was one, and (simulated) concurrency was the
other (the Task Library, chapter 2 of the AT&T C++ library manual).
Did I mention that Smalltalk-80 has TWO key features?  OO is one, and
(simulated) concurrency is the other.

For what it's worth, there is a software development method called
Jackson Structured Programming, developed years ago and used for serious
EDP systems.  One of the ideas in JSP is that you design your program as
a collection of thousands of interacting concurrent processes/objects,
and then "invert" the design to get your COBOL, because you obviously
can't *really* have thousands of concurrent processes (:-).