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.<br>
<br>Has anybody else watched Joe Armstrong describe Erlang, go on to talk about how he doesn't "get" OO programming and then just chuckle?<br><br>-david<br><br><div class="gmail_quote">On Sun, Jul 6, 2008 at 12:56 PM, Jason Johnson <<a href="mailto:jason.johnson.081@gmail.com">jason.johnson.081@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On 7/6/08, Peter William Lount <<a href="mailto:peter@smalltalk.org">peter@smalltalk.org</a>> wrote:<br>
><br>
> And NO Smalltalk hasn't caught up yet. Just half a year ago in this very<br>
> forum thread people were arguing against generic fully multi-threading of<br>
> Smalltalk virtual machines. Cincom is against it. Instantiantions has been<br>
> quite and likely won't do much.<br>
<br>
</div>People were against it because it's a lot of work to get into a<br>
soon-to-be-obsolete way of concurrent programming.<br>
<div class="Ih2E3d"><br>
> Only a few brave intrepid explorers get it and now we have experiments like<br>
> HydraVM for croquet/squeak.<br>
<br>
</div>Which are also single-thread-per-VM systems.<br>
<div class="Ih2E3d"><br>
> Most smalltalks and smalltalkers are deeply stuck in the past of one native<br>
> thread. Most in fact are not good at multi-threading with smalltalk<br>
> non-native threads!!!<br>
<br>
</div>I guess that's because they're just not very smart. Just like all<br>
those folks who couldn't understand malloc/free weren't very smart.<br>
Oh, wait, actually it wasn't like that it all. Actually malloc/free<br>
was just an overly complicated model that made everything more complex<br>
then it needed to be......<br>
<div class="Ih2E3d"><br>
>It's difficult to learn and get right which is one<br>
> motivator behind those wanting to take the easy road - one native thread per<br>
> image, but that's the wrong route (in my view and obviously in others view<br>
> as well) because it isn't general purpose enough. It involves hard work. No<br>
> way around it.<br>
<br>
</div>I would say doing what Java, of all things, does is "taking the easy<br>
road", i.e. "no thinking required". The right road is to actually<br>
look at the research being done and the discoveries being made and the<br>
systems that scale easily now (Erlang being by far the best at the<br>
moment in actual practice), and decide how to get extremely concurrent<br>
from there. Not a mindless "let's do it how C/C++/Java does it!"<br>
response.<br>
<br>
</blockquote></div><br>