Friday, November 23, 2007

Why I Program In Ruby (And Maybe Why You Shouldn't)

Neal Ford recorded an interesting podcast recently, and it's definitely worth a listen, but there's one point I want to raise - it could be a point of actual disagreement, or "violent agreement", but whatever kind of point it is, I think it matters.

Neal brings up the fact that the same programs can be written in any language which is Turing-complete, so the choice then becomes not "which language can I write this program in?" - because you can write it in any language - but "which language gives me the best options in terms of power and efficiency?"

This question overlooks one of the fundamental design principles of Ruby. First and foremost, Ruby was designed to be enjoyable to program in. In one of many Web interviews, Matz said:

Because of the Turing completeness theory, everything one Turing-complete language can do can theoretically be done by another Turing-complete language, but at a different cost. You can do everything in assembler, but no one wants to program in assembler anymore. From the viewpoint of what you can do, therefore, languages do differ—but the differences are limited. For example, Python and Ruby provide almost the same power to the programmer.


The question of "which language gives me the best options in terms of power and efficiency?" is deemed less important in this set of design principles than the question of "which language gives me the best feeling while I program?"

In Japan, the distinction between craft and art is blurred at most, possibly nonexistent. Japanese theories of art (and craft) often involve principles of harmony and balance. We might debate in America whether programming is an art or a craft, but if you've got one word for the same thing, you're asking whether programming is an artcraft or an artcraft, and the answer, obviously, is "Yes, you idiot." So to say harmony and balance matter in programming might seem esoteric or self-indulgent in America, but it's as obvious in Japan as saying that the sky is blue.

Harmony and balance make you feel good. American Rubyists frequently take up all the points of Ruby's power, expressiveness, and efficiency, but they don't seem to register the point that Ruby was designed to make you feel good. Even Rubyists who want to explain why Ruby makes them feel good often fail to mention that it was expressly designed for that exact purpose. Neal does this in his podcast.

Neal's podcast is mainly about JRuby. JRuby is a first-generation American - a child born here of one foreign parent, Ruby itself. I'm a first-generation American too, and even though I have two human, English parents, rather than one Japanese parent made of code, I think I feel JRuby's pain here. So I'm just going to tell you - every first-generation American sees this happen all the time. Some idea from another country or culture disappears like mist scattered by winds unless Americans already have a synonym for it. If they don't have a word for it, they don't have a box to put it in, and the idea just falls through the cracks.

It's not even an American thing. Everyone who really learns a new spoken or written language - a regular human language - discovers new ideas they didn't previously have words for. Conversely, anyone who tries to tell somebody about an idea, when that person has no word for it, faces an uphill struggle at best.

The idea that a language should be designed from the ground up for the purpose of providing you with an experience of harmony, calm, and enjoyment is fundamentally alien to American programming culture, and when American programmers discuss why they prefer Ruby, the fact that it was designed for their enjoyment vanishes from their own vision even when it's right in front of their eyes. The closest equivalent we have in this country is an idea that the language was designed to be fun - which is similar, but not the same thing. It implies toys, rather than Zen gardens.

David Heinemeier Hansson is one programmer who understands this aspect of Ruby. Maybe it's a Danish thing. In Rails' early days, he made an effort to publicize it, although that's fast becoming obscured in history as Rails turns into the thing everybody uses.

The thing that everybody uses is always a hot topic in technology. People like arguing about "why you should program in Language X." But it's not really about why you should program in X. It's about why I'm going to program in X, and why I think you might enjoy it too. If the number one principle behind designing Ruby is enjoyment, then the number one principle behind using Ruby should be enjoyment too.

Don't program in Ruby because you want power or efficiency. Don't program in Ruby because you think you "should", either. Program in Ruby because you like it. And if you don't like it, don't program in it. Religious wars over programming languages are just silly. The messianic zeal of Christianity's shameful Crusades a thousand years ago still lingers on in Western culture, and one glaring example is the ludicrous idea that there should be one true language or one true editor, or one ring to rule them all. It's much better when programmers can work in multiple languages, multiple editors, and multiple environments. Diversity is healthy for ecologies. This is a point Neal makes in his podcast - he calls it polyglot programming, which is to say multilingual programming. He calls it a positive trend, and I agree.