Why a Lexus is Not An Acceptable Ferrari

Eric Kidd explains on his blog why he thinks 'Ruby is an Acceptable Lisp'.

His thesis is debunked very effectively in the comments section of his blog entry. What I find fascinating is the thinking behind this position.

Let us look at how Eric tries to assert his position that Ruby is as dense (or occasionally denser) than Lisp. He first creates an example of a lisp function , then writes a ruby equivalent which is marginally shorter, while brushing off the capabilties of lisp (reader macros in this case) because "it is not commonly done"!

First , this thinking is fallacious. The fallacy is called "Biased Generalization". From the Nizkor Project,

Description of Biased Sample

This fallacy is committed when a person draws a conclusion about a population based on a sample that is biased or prejudiced in some manner. It has the following form:

1. Sample S, which is biased, is taken from population P.
2. Conclusion C is drawn about Population P based on S.

And this is the error. Eric takes a lisp function that can be expressed concisely in Ruby and simultaneously dismisses Lisp's built in capability to match and exceed that brevity. He ignores lisp functions that can not be expressed as well (see the sentence "Yes, yield is a special-purpose hack, and yes, it only works for functions which take a single lambda but.." -- recreating "yield" in Lisp is trivial anyway-- ) making his conclusion suspect.

Blindly equating conciseness to "power" is also suspect( I used to think this way as well, not too long ago) as is the (unsupported) argument that Ruby is 'more powerful' than Python.

The deeper problem is that, when you say "X is an acceptable Y", what you are saying is "Y is superior and we all know that and we would like to use Y, but because of reasons a, b and c we make do with X".

As someone who uses Ruby and Lisp every day (the days of hacking "enterprise" code with Java and C# are gone! Praise the Lord!), I prefer to think of them as distinct tools in my tool kit. A screw driver can be used as a hammer in an emergency but that does not make it an "acceptable" hammer.

Now I'll stop dissecting Eric's arguments (he has a right to say whatever he wants to on his blog. My irritation stems from seeing some ruby zealots (here in Bangalore) make ridiculous claims about 'the power of Ruby' while having no clue about its limits or alternatives) and focus on my notions of what makes Lisp 'more powerful' than Ruby (and vice versa!).

I consider a language superior to another based on what is possible in one that is not easily possible in another.

From this perspective the power of Lisp stems from the "code is data" concept. Thanks to the s-expression notation (the regularity of the syntax is what powers macros), code is malleable to a degree not possible in Ruby. Yes, you can jump through hoops to get some of the same effect in Ruby (e.g the ParseTree module) but nothing Ruby can do can match the full power of Lisp to manipulate code and the environment just like any other piece of data.

Thus if you are working on domains or projects that need this kind of raw power, use Lisp. Also, contary to what most "enterprise" or "agile" people might tell you , "Object Oriented " is just one paradigm amongst many. In Lisp, one can seamlessly switch from one paradigm to another and can mix and match pardigms to precisely map the problem at hand. While one can approximate some of this in Ruby with enough effort, the language leans unashamedly towards OO with a pinch of functional programming.

The more interesting question, of course is how Ruby is more powerful than lisp. The answer has 3 parts - libraries, community and ease of installation and use. Yes, from a strict 'linguistic' view point things like ease of installation are not language features, but from a user's point of view a language that is theoretically powerful but in practice needs days of configuration and compiling to get a substandard version of what Ruby offers out of the box is unusable. (compare Ruby's Rails framework with the patchwork of CL-SQL, Uncommon Web, etc frameworks). I have little sympathy for "but it is better in theory" arguments. The Lisp community, as compared to Ruby's, is extremely arrogant and unhelpful and hypersensitive to any criticism of their language. Harping on "ANSI standards" doesn't help when an easy to use, open source (no I am not willing to spend big $$ to buy a closed source implementation) implementation with comprehensive, bug free libraries for networking, database access and other "low brow" tasks is non existent.

Thus I think Eric's conclusion ("In 2005, I’d think long and hard before choosing Lisp over Ruby.") matches my experience, though for different reasons. You could substitute "Python" for "Ruby" and it would still be valid.

I don't think "ease of hiring" is an issue unless you are writing crapola "enterprise" code, in body shopping (oops make that "consulting") mode where "plug compatible programming units" is the reigning concept, "agile" rhetoric notwithstanding. If the programmer you hire can't get upto speed in either Lisp or Ruby in a couple of weeks you are wasting your money anyway. But that is the topic of another entry.

Thus the sensible thing to do would be to learn Lisp and Ruby (and Python, and Forth, and smalltalk , and C )well.They are fascinating languages and will teach you different things. Alternatively you could study one and use that exclusively. The utility of a language (and thus, its "power") depends on what you the programmer can do with it, not on some abstract notion of "power".

In other words, learn to use Ruby to maximum effect. Learn to use Lisp to maximum effect. Learn to use --your favorite language-- to maximum effect. This will give you an awareness of what each is good for and where each falls down. Whether Ruby is an effective (whatever that means) Lisp or vice versa is irrelevant. A Lexus may suit your needs better than a Ferrari but it is not an "effective Ferrari" (though it may be better than that overhyped Ford (I did not say "Java/C#" :-P ).