Lisp has a mystic aura as the “programming language to rule them all,” so most hard-core geeks nurture a fascination with it. Paul Graham has written several essays extolling the virtues of Lisp, and indeed he’s got reason to talk: he built what is now Yahoo! Shopping with Lisp. His famous Beating the Averages essay describes the experience.

I was curious how Ruby stacked up with the power-user features of Lisp, so I went digging for the inevitable “Ruby vs. Lisp” debate. I use Ruby these days (thanks to Rails) and I’ve used Lisp before (thanks to Emacs), but I haven’t used either extensively enough to call myself an expert. Thus, I was curious to see the experts weigh in.

I must say upfront that my focus is narrow: I’m looking at each for the purpose of building web-based applications. Thus the discussion is not language vs. language, but language + frameworks vs. language + frameworks suited for my purpose.

Following is partly a summary of my research, but mostly a commentary on the debate itself. There’s an interesting rift between the two camps, “interesting” not just for their opinions but for their perspectives.

[Update 2006-01-21] Please note this disclaimer I posted in the comments below.

The Lisp Camp

The core argument for Lisp is best expressed by Graham himself: “Lisp is so great not because of some magic quality visible only to devotees, but because it is simply the most powerful language available.” Arguments about specifics inevitably dive into discussion over macros, continuations, and other language features. For reference, see the excellent debate in the comments of this article, complete with lots of code illustrations.

The Ruby Camp

Ruby, when combined with Rails to develop web-based applications, is widely considered the best thing since sliced bread. Their message, in big letters on their home page: “Ruby on Rails is an open-source web framework that’s optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.”

The Difference

Put the camps near each other, and of course they clash. But here’s where they miss each other: the Lisp camp is talking about powerful language features – “Ruby will never be as powerful as Lisp.” The Ruby on Rails camp is talking about getting things done today – “I can build a cool web app in days instead of weeks or months.”

The Lisp camp is good at demonstrating the superiority of Lisp as a core language. They then mention that the language is inherently extensible (via macros, for example) by the developer to meet their problem domain.

The Ruby camp, on the other hand, is starting from a Ruby already extended to meet the problem domain of web applications. Rails isn’t just a set of helper classes for web stuff, it’s a domain-specific language for models, controllers, and views. They’ve stolen one of Lisp’s most prize weapons – seamless extension of the language to match the problem – and whacked them with it.

The professional developer simply must consider the language and its available frameworks. Much like Paul Graham’s arguments above, I want to maximize the end result while minimizing my effort. The problem with most of the debate is that when people boil examples down to code, they’re not solving real problems. How many times, in your professional career, have you written a function to generate a Fibonacci sequence?

I did some poking around for tutorials on building a simple, but halfway real, web application in each language. CLiki points me to this tutorial by Pieter Breed. Paul Graham also offers more technical details on how he built his applications, but his framework isn’t publicly available. For Ruby on Rails there are several demonstration screencasts to watch.

Breed’s Lisp-based tutorial takes me back to writing web applications circa 1998 – writing all the SQL by hand, generating HTML in your code, etc.. Ick. Does this imply that Lisp is a bad language for web apps? No, but it implies that the frameworks (or libraries, in Lisp terms) are nowhere near as high-level as Rails. Watch the Rails “create a blog in 15 minutes” video for comparison.

[Update 2006-01-21] Frank points out in the comments that there’s an excellent screencast to watch demonstrating the Lisp library Uncommon Web. This looks like a better starting point than Breed’s tutorial. Also, Zak points out this HTML template library, this SQL object/relational mapping system, and other libraries in his comments. Thanks, guys!

Now I don’t mean to bash Lisp here, I’m just commenting on the debate as I see it. Or, more specifically, the part of the debate I’m interested in: the best combination of freely-available language and tools for building web applications. And I define “best” in terms of “will it help me build stuff quick, and not get nasty as the application gets complex?”

Conclusion

It appears from the outside that Lisp, as a language, has the power to equal or better Ruby. But Ruby, when combined with Rails, puts you so far ahead of the game that it doesn’t matter. That balance may change if the Lisp community builds their own Rails-style library, and for the sake of competition challenging everyone to get better, I hope they do.

For my own edification I plan to learn Lisp better. It’ll serve me well in the short term – I’m still an Emacs geek – and in the long term for how it changes my thinking. Graham again: “…programming languages are not just technology, but what programmers think in. They’re half technology and half religion.”

But the core language is only half the picture. It turns out Ruby is a pretty darn good language. Good enough to create Rails with, and good enough to get things done, right now. As others in the debate have noted, “batteries are included.” That’s a winning combination.

[Update 2006-01-21] Lisp’s problem is a lack of message. It’s hard to tell what the Lisp community considers the best libraries and best practices for building web apps. At best, cliki.net provides an unranked laundry list of of libraries. At worst, it actively misleads potential developers by putting Pieter Breed’s tutorial at the top of its “Web” section.

There are best practices common to nearly all web apps, e.g. separation of presentation and logic, and there are best practices for languages to get maximum leverage from that language’s features. As such, the Lisp community needs their version of David Heinemeier Hansson to bring things together. This figure needs to provide a “happy path” which uses the power of Lisp and the best collection of its libraries to address common web application needs. (Paul Graham, you up for it?)