I know processes are cheap in Squeak and that doesn't necessarily 
translate into 'processors' but how far is Squeak from such a scenario?

I also read the Erlang list and their basic philosophy seems to be to 
create a process for most any activity. Lots and lots of processes. 
Processes are cheap. Processes are how to model your solutions.
My apologies if I am not phrasing things correctly. I know there are 
some here who are familiar with Erlang.

Erlang is designed for massive parallelism. Their processes are not 
multi-processorable either. They run an new instance of the vm for each 
processsor and do interprocess/vm communication via messages. Is Squeak 
very far off from Erlang's massive parallelism? I have been considering 
Erlang for web development. But I would prefer to stay with Squeak, but 
I desire/need/want a very scalable solution.

This has been interesting.
But once again, I'll defer to those who know more than I on this. :)

Jimmie Houchin

Swan, Dean wrote:
[snip]
> 	3) Regarding distributed OOP:  I think an obvious solution
> 	   is one CPU per object, with one or more shared high speed
> 	   communication path(s) to send messages and return results.
> 
> 	   This could be reasonably explored on FPGA based hardware.
> 	   Using a *really* simple CPU design, you could fit a lot of
> 	   them on today's million gate FPGAs.
> 
> 	   I have often said that I would rather have a lot of slower
> 	   CPUs than one really fast one.  If the human brain can do
> 	   all the wonderful things it does with a peak signal
> 	   frequency of around 1 KHz, there must be something to this
> 	   massive parallelism concept.
> 
> 	   As Alan mentioned, Fuchs was really on to something with
> 	   his pixel processor idea.  Too bad it hasn't caught on.
> 
> 	   Sadly, computer science has paid terribly little attention
> 	   massive parallelism.  Rumelhart and McClelland made some
> 	   noise about this back in the mid-80's, but it's remained a
> 	   niche field.  Then there was the Transputer, Hillis's
> 	   Connection Machine and others, but we've never really
> 	   developed good tools to write parallel programs.  The
> 	   closest we have that is widely used is VHDL or Verilog.
> 
> 	   (This just caused an odd thought - How about a Smalltalk
> 	    to digital logic compiler?  Does that make any sense?
> 
> 	    After all, any CPU based architecture is always going to
> 	    be sub-optimal compared to equivalent random logic.)
> 
> 							-Dean
[snip]