I don't know, Alan; just like Java, probably some typing is currently the
only obvious way to make Ruby run even faster, but people are saying that
it is not the Ruby way.  If there is indeed a new technology that can make
Ruby run faster without some typing, that will indeed be the right way to
go.

In my dream language, the typing is optional, and then I will add 'struct'
(not the current Ruby Struct), so that member data "@data" is not accessed
through hash anymore, but through memory offset.  It will take me some
time to learn lex and yacc and the Ruby interpreter.  As already
commented, probably eventually I will have to take the task myself (if I
have the time).

Regards,

Bill
===========================================================================
Alan Chen <alan / digikata.com> wrote:
> Now if you can keep the human productivity the same while increasing
> run speed I'd be very interested (not to mention that more of the ruby
> community would be more supportive).  So many of the recent syntax
> extension discussions have assumed that Ruby as it is now would be
> difficult to optimize because of the dynamic language features, but
> that seems like a poorly examined supposition to me.  I would bet that
> run-time dynamic updates in ruby code happens in a small set of
> instances - and then primarily near startup.  There's no reason that a
> optimizing, ruby, run-time engine couldn't go ahead and emit optimized
> code with any number of type-based restrictions, but detect dynamic
> updates which may invalidate that particular optimized code
> block. Think of it as a ruby version of a Java HotSpot compiler.