On Ruby’s Lisp heritage

If you are a Ruby programmer, you probably know that some methods in Ruby’s Enumarable module are available under multiple different names. For example:

Why is that?

The answer is simple. Names like map and reduce were traditional in Lisp circles. And all the names ending with “-ect” described the same concepts in various Smalltalk environments. Since Ruby philosophy is to try to please everyone (as opposed to forcing one officially blessed way), it incorporated names from both worlds.

Usage in the wild

It’s interesting to see which names are more often used in the real world. In most codebases I’ve seen, Lisp won. Pretty much everyone uses map, find, and find_all rather than collect, detect, and select. The only exception is inject, which seems to be used more often than reduce.

I’m not sure why this is the case. Is it because the Lisp names are shorter? Is it because the Smalltalk names are all alike? I don’t know, but I suspect the main factor is familiarity. More programmers knew the Lisp names rather than the Smalltalk ones when they started writing Ruby code, so they used them, and this convention spread.

Is Ruby Lisp?

Widespread use of Lisp names for common operations supports a notion that Ruby has a Lisp heritage. This notion is repeated by many, but I actually think it is superficial. If you look closely at the language, you’ll find no trace of Lisp at all. The core or Ruby is actually a dynamic flavor of Smalltalk with Perl features added on top.

So is Ruby’s Lisp heritage a myth? I’d call it so, if it weren’t for one thing — Matz once said he started with Lisp when he designed the language. With this in mind, I can only say that the Lisp core was all but wiped out by his later design steps.

Thanks to Martin Vidner for inspiring me to write this post.