On 12/31/06, cremes.devlist / mac.com <cremes.devlist / mac.com> wrote:
>
> On Dec 31, 2006, at 4:54 PM, M. Edward (Ed) Borasky wrote:
>
> > Francis Cianfrocca wrote:
> >> '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 ;-).
> > On the contrary -- I'll agree vehemently on some of this and
> > disagree less strenuously on the rest.
> >
> > Vehement agreement: Erlang-style lightweight processes are a
> > *proven* way to solve large complex problems on large collections
> > of hardware. However, Erlang does some other things that seem to
> > stick in the craw of a lot of folks here -- like a functional
> > programming style and compile-time type checking. :)
> >
> > Disagreement, but perhaps more a lack of acceptance of reality: I
> > think today's programmers are up to the task of highly parallel
> > programming, because there are many decades of theory and practical
> > experience in it already. I posted a rant about this already today,
> > so I'm not going to belabor the point. I'll just fall back on
> > Arthur C. Clarke's Law: When a distinguished but elderly scientist
> > says something is possible, he is usually proven right. :)
>
> At this year's C4 conference [1], Steve Dekorte gave a presentation
> [2] on programming using the Actor Model [3]. It was fascinating to
> me since I had never been exposed to anything like it before. His IO
> language [4] is rather pretty too.
>
> It would be wonderful to wrap something like this up in ruby so it
> was a first-class citizen in the language.

The language has some great ideas to steal. Not all of them are
original to Io but some are implemented in really nice ways. One of my
favorites has been transparent futures. These are a little hard to
implement in Ruby w/o Object#become of some form. Proxies work well
but give a large performance hit and rare gotchas (Ruby takes quite a
few shortcuts that makes this break in odd places).

It would be awesome to see some of this implemented as first class
concurrency mechanisms. I had a good portion of Ruby's object model
mirrored in Io to experiment with the combination. The project was
dropped after I had difficulties with some of less defined areas,
parsing ruby code, and Io's general instablility (much better these
days, but still very visible).

Brian.