I read this post by Ramon Leon on why Smalltalk is a better environment for building DSLs than is Ruby (found via keith).
I generally agree with Ramon’s points, in that the C-based MRI prevents us from reaching into the guts of the platform and making modifications without having to drop down a layer and do it all in C. And, of course, that’s the point: if I want to make major modifications to the language I’m working in, I want to do it from that language. I don’t want to drop to C—it is the moral equivalent of reaching for a glass of milk, taking a sip, and finding out it is orange juice. The orange juice isn’t inherently evil, but in this context, it might as well be motor oil.
The problem I have with his post, and with most posts about X-vs.-Y language comparisons is that in conflates two ideas and reaches the wrong conclusion. Ramon is right: the MRI prevents Ruby programmers from being able to modify their own language to the extent that SmallTalkers can. However, there is nothing particular about Ruby the LANGUAGE that does.
For example, the Rubinius project will provide us a stack of turtles on which to perform linguistic gymnastics to our heart’s content. If you read the collected writings of the Rubinius team, you’ll see that they are in fact heavily influenced by the Smalltalk-80 architecture.
And I don’t think Ramon is ignorant of this fact, or that he is maliciously overlooking it, just that his prose doesn’t make the distinction explicit which might leave readers with less understanding of the Ruby ecosystem with the wrong idea. The same way that Ruby people often complain about Java and paint the language and the JVM with the same broad brush.
Comments
Lovely article – minor correction: It’s Smalltalk with a lower ‘t’.
Cheers, Mel
You know, in comparing Smalltalk to Ruby the question is less being turtles all the way down so much as being turtles all the way across. And that the turtles don’t suddenly tun into parakeets. Smalltalk uses blocks for flow of control not as a neat option, but as the default (not to mention mandatory) way of having anything but a fixed linear sequence of message sends in a method. Ruby has blocks, which is great, except that they have two very different syntaxes, and sometimes they get treated specially and sometimes not, and there are these other control structures that aren’t block based at all.
I love that Smalltalk lets me (in fact, requires me to) write new flow-of-control constructs of my own that look exactly like the ones that Alan Kay and Adele Goldberg and the others wrote back when I hadn’t even started secondary school. But I don’t have to worry about the Smalltalk implementation to do that (although I might if I really cared huge amount about my structure being super time efficient). That’s just what programming in Smalltalk is all about. And it has as much to do with the keyword syntax and a profound syntactic and semantic simplicity and uniformity as it has to do with having blocks, or having turtles very much far down at all.
Keith’s got it, it’s about having your own control structures be the same form as the built in language constructs. Rubinius will certainly let Ruby programmers extend Ruby’s library in Ruby, but any control structures they create in doing so (at least, those containing multiple blocks), won’t look like native ruby control structures, unless they modify the VM itself.
Ruby still embraces the divide between the compiler writer and the library writer, Smalltalk just puts everything into the library, and the compiler occasionally just optimizes particular forms for speed, but they don’t have a different syntax. Smalltalk’ers add new control structures all the time, Ruby programmers can as well, to a limited extent, using the yield hack, assuming their control structure only needs one block.
Ruby’s greatest strength, IMHO, is that it’s creating a whole new generation of Smalltalk’ers! ;)
“Ruby’s greatest strength, IMHO, is that it’s creating a whole new generation of Smalltalk’ers! ;)”
I could say the same thing for Lisp.
I’ve got nothing against that, another great language!
But there’s no inherent reason why Ruby can’t edit/create its own control structures. If a project such as Rubinius writes in ruby enough turtles down, there’s probably no reason they’d stop developers from rewriting the core parser/compiler – check out the repository, e.g. here: http://git.rubini.us/?p=code;a=tree;f=kernel/core
There’s already a fair number of turtles in there