Mmmm original, yeah thats a very different
approach. Hard to say which one is best. But for your comments, maybe the
primitives way is a path *better* for the human beigns that program
the system in terms of easing that pain.
Question: that would be a path that
prioritizes usability at samlltalk developer level? if so, for me is more
interesting even if it is less efficient than the other in terms of a couple of
more or less [whatever measure unit] per second that in one year will be
duplicated with a cpu with 2 more cores for a few u$s.
Not prioritizing
usability and intelectual ergonomy is equal to not geting the point of all this
smalltalk thing, perhaps even more.. all TI thing. Just a
thought.
I'm quite sure that multicore this
is the begining of a new crisis for the industry. But is a good
one!
cheers,
I don't know if mapping Smalltalk processes to native threads is
the way to go, given the pain I've seen in the Java and C# space.
What
might be interesting is to develop low-level primitives (along the lines of
the famed map/reduce operations) that provide parallel processing versions of
commonly used collection functions.
No idea how easy this would be to
do, but on the surface seems more promising than trying to do process/thread
jiggery pokery.
Steve