------art_124075_31396098.1167604323918
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 12/31/06, M. Edward (Ed) Borasky <znmeb / cesmail.net> wrote:
>
>  Well, given that Ruby already has threads, monitors, drb, Rinda,
> starfish and NArray, you'd have to de-implement those if it doesn't make
> sense to implement them. :) And yes, a language designer does need to be
> able to say "No". But I think what I really want to see is, given the
> visibility of concurrency and multi-core processors and energy
> efficiency right now, for Ruby to have some compelling "killer language
> features" for exploiting this trend.



I'm not going to speak for the folks who are implementing or adapting VMs
for Ruby. But on first thought, I'd implement threads, mutexes and condvars
primitively and add monitors (and all the other derivatives like RW locks)
on top of those. The other stuff you mentioned is cross-process. Are the new
VMs actually planning to implement stuff like drb and Rinda primitively?

Multicore architectures: many people will probably disagree vehemently with
this, but I think that taking advantage of the new architectures will best
be achieved by breaking computations up into multiple processes. I think the
style that is broadly represented by Erlang will be the most effective
approach, so a new "paradigm shift" (sorry) in programming is coming.
(That's why I've worked so hard on event-driven programming support for
Ruby.) But teaching programmers to be better at multithreading, etc. will be
fruitless because this approach is really difficult now, and will be far
more difficult on highly parallel or multicore hardware. That's my two cents
on the subject, and it's worth every penny ;-).

------art_124075_31396098.1167604323918--