Avi talks about this on his blog this week.
[link|http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3284695382|http://www.cincomsma...&entry=3284695382]
The Ruby distribution comes with a large amount of C code implementing the underlying language and library semantics: a parser, an interpreter, regular expressions, arrays, hash tables, a numeric tower, and so on. In some cases, like the parser, this code is kept hidden from the Ruby layer: there's no way with a stock Ruby interpreter to get at a Ruby parse tree from Ruby code. This makes certain tools much harder to write - the RDoc documentation generator, for example, has to include its own lexer because it can't access the one that comes with Ruby. It also makes the language much harder to extend, since any change to the way the parser works has to be done in C, and any code that relied on these changes wouldn't run on anybody else's Ruby installation.
...
This may sound like an academic quibble, like a desire for purity for its own sake, but the fact is that the tools available on a Smalltalk system, like the Refactoring Browser, the Debugger (which takes "edit-and-continue" farther than many people can imagine), the various inspectors and explorers and profilers are much, much better than those available for the "scripting" languages like Ruby. I would argue that a large part of the reason for this is the open, accessible, and extensible nature of the system: nobody wants to write those tools in C, and in Smalltalk, you don't have to.
Note that I'm necessarily talking about implementations here, not language specs: clearly in JRuby, the implementation is in Java instead of C, and clearly you could implement the Ruby language with a Smalltalk-style VM (hopefully one with a Smalltalk-style JIT as well, which would bring a 20x or so speed increase to the current Ruby interpreter). But really what I'm talking about is a philosophical difference, not a technical one: to Smalltalkers, it's essential that as much of a system as possible be implemented in Smalltalk, whereas this simply isn't a priority for the scripting language community, and it's the priorities rather than the individual implementations that draw me to Smalltalk.