On 7/6/08, Peter William Lount <peter at smalltalk.org> wrote:
>
> And NO Smalltalk hasn't caught up yet. Just half a year ago in this very
> forum thread people were arguing against generic fully multi-threading of
> Smalltalk virtual machines. Cincom is against it. Instantiantions has been
> quite and likely won't do much.

People were against it because it's a lot of work to get into a
soon-to-be-obsolete way of concurrent programming.

> Only a few brave intrepid explorers get it and now we have experiments like
> HydraVM for croquet/squeak.

Which are also single-thread-per-VM systems.

> Most smalltalks and smalltalkers are deeply stuck in the past of one native
> thread. Most in fact are not good at multi-threading with smalltalk
> non-native threads!!!

I guess that's because they're just not very smart.  Just like all
those folks who couldn't understand malloc/free weren't very smart.
Oh, wait, actually it wasn't like that it all.  Actually malloc/free
was just an overly complicated model that made everything more complex
then it needed to be......

>It's difficult to learn and get right which is one
> motivator behind those wanting to take the easy road - one native thread per
> image, but that's the wrong route (in my view and obviously in others view
> as well) because it isn't general purpose enough. It involves hard work. No
> way around it.

I would say doing what Java, of all things, does is "taking the easy
road", i.e. "no thinking required".  The right road is to actually
look at the research being done and the discoveries being made and the
systems that scale easily now (Erlang being by far the best at the
moment in actual practice), and decide how to get extremely concurrent
from there.  Not a mindless "let's do it how C/C++/Java does it!"
response.