From: David Masover <ninja@...>
Date: 2009-11-30T18:17:02+09:00
Subject: Re: ruby language parser in ruby

On Sunday 29 November 2009 03:25:17 pm Ryan Davis wrote:
> On Nov 29, 2009, at 10:29 , Marc Heiler wrote:
> >> Was using ruby_parser, but now is also C... you know... ruby in ruby. :/
> >
> > Awww...
> >
> > I still thought rubinius was going with the pure ruby approach. :(
> 
> yeah. well. They left that idea FAR behind a long time ago.

I'm not sure they wanted to do that for everything, from the parsing to the 
VM, though that would've been cool.

Probably the thing I love most about Rubinius, as it was when I last looked, 
is that it fulfills some of the original promise of Ruby. When I first started 
looking at Ruby, people said "Most of Ruby is written in Ruby." I took this to 
mean a very lightweight language with a huge standard library. Well, much of 
the standard library, and most of the core libraries, are written in C, for 
performance reasons, significantly limiting what I can do in Ruby.

For example, back when I was writing autoloader, I can't remember why, but I 
really wanted Kernel#autoload to actually use Kernel#require when the module 
is accessed. Ideally, I wanted something like this:

autoload :FooBar do |name|
  require 'foo_bar'
end

Unfortunately, Kernel#autoload doesn't do that. Last I checked, it directly 
calls the C code that Kernel#require maps onto -- at the time, this 
effectively bypassed Rubygems as a whole.

It was to the point where to create an alternate way to autoload stuff, I was 
going to have to hack the Ruby source, in C.

...really?

Contrast this to Rubinius. The source was clean and readable, and I was easily 
able to figure out how to accomplish what I wanted, in pure Ruby, without 
modifying any of the source.

By the way: It doesn't have to be slower. Remember Google's Javascript engine, 
v8? It implements the Javascript standard library in Javascript, yet v8 
_still_ wins in the benchmarks against other, more conservative Javascript 
implementations.