Lisp vs. Java

May 05, 2005 4 comments

I picked up my copy of Practical Common Lisp again after being distracted by a couple of other books. Having just finished the macros chapter, I’m floored by the capabilities of the language. I do have some reservations about making a webapp with it, but that’s for another post when I don’t have a calc test to study for. Nevertheless, I figured anybody from javablogs would get a kick out of this quote from the book:

DOLIST is similar to Perl’s foreach or Python’s for. Java added a similar kind of loop construct with the “enhanced” for loop in Java 1.5, as part of JSR-201. Notice what a difference macros make. A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern. A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language. Then Sun has to publish a JSR and convene an industry-wide “expert group” to hash everything out. That process-according to Sun-takes an average of 18 months. After that, the compiler writers all have to go upgrade their compilers to support the new feature. And even once the Java programmer’s favorite compiler supports the new version of Java, they probably still can’t use the new feature until they’re allowed to break source compatibility with older versions of Java. So an annoyance that Common Lisp programmers can resolve for themselves within five minutes plagues Java programmers for years.
-Peter Seibel

I could continue with an example of when my co-developer and I were really digging into Java to use in our J2EE project and were wondering why basic things like enumerations were only being introduced in 1.5, but the above quote is so spot on I’ll just leave it at that.

4 comments


Eric said about 6 hours later:

“So an annoyance that Common Lisp programmers can resolve for themselves within five minutes plagues Java programmers for years.”

...which is great, until someone else has to use your code.

Have you ever tried using someone’s highly customized EMACS setup? Maybe they’ve made it more like Wordstar, or changed the exit key. Maybe their meta is their control key, and their control key is their caps lock key.

The result is that you not only have to be used to reading someone’s algorithms, you have to be used to reading their dialect.

As such, I have the same rules on LISP programming that I do with perl – I hate it unless I wrote it.

PJ Hyett said about 11 hours later:

Why would I use someone else’s Emacs setup? I agree with you on the Perl stance, it can be very criptic and that’s why I don’t particularly like it, but your argument can apply to sloppy code written in any language in my opinion.

Christopher said about 14 hours later:

Macros are of course not to be used lightly. The freedom they give is the freedom of the language designer, and most programmers are quite happy not to design their own languages – except that they’d like to see feature foo from language bar in their favourite language. While this can easily be done in Common Lisp (the whole object system is just a bunch of macros really), many programmers are either not good enough or lack the experience to create these kinds of well-thought-through high level abstractions. Suboptimal macros can easily make code quite unreadable – however, the Lisp way of exploratory programming and a bit of experience should suffice for good quality macros. As IBM had it: Think!

Chris Thiessen said about 19 hours later:

A little while ago, I released an GPL/commercial macro extension of Java which has many of the same features as Lisp (all but compiler macros). http://www.kataba.com/dynamics/Macro-ByExample.asp .

Sorry, comments have been closed for this post.