Why Ruby is not my favorite programming language

[topaz]

khedron asked me after my last Ruby post what I thought of the language, and whether I agreed with the sentiment that Ruby can be a pretty decent substitute for Lisp in a lot of cases.

Ruby is a nifty little language that's had a small but devoted following for about 15 years.  It's gotten a lot of attention recently with Ruby on Rails, a Web development framework that implements the model-view-controller design pattern for Ruby applications.  Some things it does very nicely: its syntax is more highly reflective than any other language I can think of offhand since Smalltalk.  At some point I should write something about the cooler parts of Ruby, but right now it's annoying me and so I'm afraid that today you get the bile.

There is always the risk, when writing an article like this one, of criticizing something simply because it is different from something that you happen to like more.  I am sure this is no exception.  I will try not to criticize Ruby for not being Lisp, or C, or heaven help me, Perl, but on the basis of its own merits.

First-class functions

Many methods in Ruby are accompanied by code "blocks" where other languages might use a closure or a reference to a subroutine, e.g.:

values.sort_by { |x| x.abs }
palindromes = words.find_all { |w| w == w.reverse }

The confusing and maddening thing here is that you can't pass a function or a reference to one.  Why not?  Well, because it's not a block, and these methods will only accept a block.  What's a block?  A block is a chunk of executable code.  You mean... like a function?  Right.  I mean, actually no, not really.  What?

Trying to resolve this issue can reduce even the bravest warrior-hackers to a gibbering, cowering mess.  zsquirrelboy found me a very good analysis of Ruby's handling of first-class function objects by Eli Bendersky, who does an excellent job of describing the differences between Ruby's methods, Procs and blocks.  Anyone else who has struggled with this issue should go read his commentary right away.

Matz confirmed in a Ruby article in InformIT that this "block" construction is a syntactical oddity. It comes into play only when the interpreter sees an open brace (or the do keyword) supplied on the same line as an iterator method. Although it looks as though you are creating an anonymous procedure object and passing it as an argument to the iterator, the block isn't really any kind of first-class object and is not delivered to the iterator via standard argument-passing mechanisms.  According to Bendersky, the interpreter quietly transforms the block into a closure and attaches it to a special slot on the iterator method, which the iterator can invoke with the yield statement.

This technique of invoking iterator methods with blocks is convenient but I find it unsatisfying and unsettling when examined more deeply.  One of the commenters on Bendersky's essay asked, quite reasonably, why it's necessary to do this:

func = lambda { |x| x + 5 }
func.call(2)

rather than the conceptually simpler

func = lambda { |x| x + 5 }
func(2)

The answer is apparently that, because Ruby puts methods and local variables in separate namespaces, and permits methods to be called without parentheses, an expression like "func 2" would have an ambiguous parse tree.  So you're not allowed to do it.

Alan Perlis once famously said that "syntactic sugar causes cancer of the semicolon."  At long, long last, I think I finally understand what he meant.

Inconsistent variable scoping

Ruby variables are declared only in the arguments to Procs or methods. When a new free variable is instantiated, it is assigned to the innermost closure active at run time.  Example:

def foo
  result = 0
  (0..5).each do |n|
    result = n
  end
end

Here exactly one result variable is instantiated across the entire method, and after the each loop terminates, its value is 5. However, in this example:

def foo
  (0..5).each do |n|
    result = n
  end
end

the scope of the result variable is limited to the each block, because --- and this is important --- Ruby converts this block to a closure when the each method is invoked (see above). That is important because it explains why this other, semantically equivalent, code behaves differently:

def foo
  n = 0
  while n < 5 do
    n = n + 1
    result = n
  end
end

See the difference?  Because the block in the while loop isn't a closure, the result variable here belongs to the scope of the foo method. It is like the first example, except that in that case we had to force the variable's scope by deliberately instantiating it at the method level. That's not necessary here because the while block isn't a closure; only the each block is.

If you are anything like me, at this point you have already begun drinking heavily.  Byzantine scoping rules like these are just a recipe for disaster.

Matz deserves a lot of credit for recognizing how bad this is.  I have not had a chance to review what's happening with Ruby2, but the changes Matz describes in these slides look like a considerable improvement from the current state of affairs.

Anyway

Despite all this I can't really say that I dislike Ruby.  I've been working in Ruby on Rails for only a few months, and have not really delved deeply into what the language has to offer, but I find a lot of its self-redefinition features really encouraging and intriguing.  I can see that Matz has tried hard to strike a good balance between conceptual elegance and programming expressiveness, and that's a difficult line to walk.  What makes me unhappy is where the language appears to violate the principle of least surprise; if issues like these can be remedied effectively, it will make Ruby substantially more appealing to hackers like me.

Comments

[dbang.livejournal.com]

I don't know Ruby even a tiny bit, so I can't comment on most of your post, but this criticism caught my eye.

The confusing and maddening thing here is that you can't pass a function or a reference to one. Why not?

Is the ability to pass a function/reference to a function a desirable trait?

I always thought of that as one of those arcane things that C and C-like languages let you do to shoot yourself in the foot and several other body parts...and/or to ensure you have a job forever because that critical piece of code you wrote is completely unintelligible to anyone but you, and if they fire you the entire company will go up in flames of spaghetti.

Highly structured languages like Pascal certainly don't let you pass function references. Nor highly OO languages like Java. (Although of course they do let you pass an object and therefore refer to the object's methods.)

Amen

[faulkner.myopenid.com (from livejournal.com)]

You have the exact same set of gripes that I have. I had forgotten about the scoping issue until you mentioned it. Ugh. So much hope pinned to Ruby 2.

And dbang: C is not a functional language, it's a procedural language. When qwrrty says "functional" he means this (http://en.wikipedia.org/wiki/Functional_language).

[dbang.livejournal.com]

Tangentially, have you looked into Groovy (http://en.wikipedia.org/wiki/Groovy_(programming_language))?
I know nothing about it personally, but I met a guy recently who was waxing evangelistic about it rather vehemently, saying that he had been a big Ruby on Rails fan, but had totally converted to Groovy, saying it solved all Ruby's flaws. I had nothing to add to the conversation, of course, knowing neither Ruby nor Groovy, but it did sound, um, groovy.

[quigleydoor.livejournal.com]

Thanks for your insights. I played around with Ruby on Rails enough to be dangerous, in John Norman's class at Harvard Extension (http://e168f07.7fff.com/about/) last semester. It is fun—my scripting tool of choice for one-off tasks like parsing a text data file. I wish the class got into issues like you are describing, instead of focusing on the Rails bag o' tricks. If it had, it would have been a great class on language design.

One thing that bugs me is that there is no convenient way to iterate through two or more collections at once. I had a problem where I had two lists of numbers, one in a file and one in a database table. I had to generate a pairs from one number from each list. This was just test data, so I didn't need to care what order it worked in or how they were paired, and randomly would have been the best way. Given how easy it is to iterate through one collection, I was bummed when this task actually slowed me down. I ended up with a SQL hack to do the pairing in the database.

[feoh.livejournal.com]

This is one of the most cogent and well written critiques of the Ruby language I have ever seen. I'm an unabashed fan and I think I just learned something important about the language, as well as gaining a new understanding of the criticisms some of the programming purists have been too lazy to fully articulate.

Thank you!