On Sunday 29 November 2009 03:25:17 pm Ryan D. wrote:
On Nov 29, 2009, at 10:29 , Marc H. 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.