Well said.  I think the principles embodied in Erlang may be the best way of
dealing with lots of cores (and grids of lots of machines) for a large class
of applications.  Perhaps I'm prejudiced -  we've been using many of these
principles in our VW based solution for the last 7 years.  We have
deployments running 100's of cores and are confident that it will continue
to scale.  I'd love to see better support for Erlang architectural
priniciples in Smalltalk.  If think that  Newspeak + Hydra + Cog would make
a very interesting foundation.

Has anybody else watched Joe Armstrong describe Erlang, go on to talk about
how he doesn't "get" OO programming and then just chuckle?

-david

On Sun, Jul 6, 2008 at 12:56 PM, Jason Johnson <jason.johnson.081 at gmail.com>
wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080706/1e2dee12/attachment.htm