From: Joel VanderWerf <vjoel@...>
Date: 2006-05-25T06:52:32+09:00
Subject: Re: Zed and Luis drop the bomb on Ruby's poor performance

Christian Neukirchen wrote:
> "Douglas Livingstone" <rampant@gmail.com> writes:
> 
>>> How about we rewrite the ruby runtime as a combination of macros and
>>> functions in Lisp, use ParseTree to get the S-Exp representation of a
>>> ruby program and then feed that into our Lisp compiler? Instant
>>> speedy ruby! ;)
> 
>> ((defn
>>  sum
>>  (scope
>>   (block
>>    (args a b)
>>    (return (call (lvar a) + (array (lvar b)))))))
>> (lasgn a (lit 3))
>> (lasgn b (lit 4))
>> (lasgn c (fcall pythag (array (lvar a) (lvar b))))
>> (fcall puts (array (lvar c))))
>>
>> So, it looks like Lisp to me! Now, some macros?
> 
> Now try to port the Ruby object system to CL so it will have
> reasonable runtime performance.
> 
> Good luck.

Yup. I'm afraid all this lovely syntactical work is not going to get
past the basic facts that (a) method calls are pervasive in ruby and (b)
we depend on (a) for all of our favorite tricks. It's hard to optimize a
language in which so much meaning is deferred until the moment of execution.

What's special about ruby (and languages that share the smalltalk
heritage) is that this deferment of meaning (aka late binding) is
enforced so pervasively that it becomes possible to reuse libraries in
ways that were not originally intended (duck typing). Duck typing in CL
is probably much harder, because library writers may make more type
decisions in the interest of "efficiency" (but that's just a wild guess
from someone who hasn't used Lisp seriously in 10 years, so I'll pipe
down about that now). A good example in ruby is the #to_s method invoked
by the #{ } construct. Another example is #each.

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407