Quoting Sebastian Sastre <ssastre at seaswork.com>:


> ... 
> Take a minute to think in it's consequences. This suposition, same concept
> in more explicit words, this assumption of anObject being an indissociable
> thing with aProcess, objects being 1:1 with processes, makes all the
> difference and dramatically simplifies all. An we do know that
> simplification improves scalability.
> 
> I'm, of course, being extremely speculative in the exploration of this idea
> in group with you all. But think is cheap :). In fact I don't even buy it
> myself yet. The problem is that I'm honestrly unable to refute myself about
> the convenience of this path :) so it becomes stronger. 
> 
> I hope you and others understand why I'm starting to think that this is a
> powerful idea.
> 
> 	all the best,
> 
> Sebastian Sastre
> PS: Sorry for the size. I've tried to express this in my previous post. I'm
> trying to be didactic and illustrative.

I was always impressed  in Self by an idea of the implementers.  They chose a
structure that is implicitly inefficient in terms of implementation, namely that
every object has its own named slots.  

However, the smart idea was that, behind the scenes they used implementation
'tricks' to mitigate the efficiency hit, while maintaining the model at the top
level.  For example, they defined "maps to transparently group objects cloned
from the same prototype, providing data type information and eliminating the
apparent space overhead for prototype-based systems." 

Similarly, we could accept the object-process model, and then explore ways to
make this efficient behind the scenes.  It seems to me that on a uniprocessor,
the 'behind the scenes' would look much like Smalltalk today. But as multi-core
and distributed computing becomes more prevalent we would gain the benefit. 
Certainly we could explore the realities and consequences of this model.  

David