Skip to content

Java and Lisp

Richard Cook’s recent blog post, provides an interesting contrast between the Java and Lisp worlds.

On the Java side Richard references Ed Burnette’s article Better, faster, stupider Java. Ed feels that the flurry of new Java language features “make Java less great”. A big part of Ed’s concern is that by taking advantage of these new features, programmers are effectively shutting out anyone who needs to support older versions of the language.

On the Lisp side Richard quotes Peter Seibel’s description of Common Lisp macros in which he notes:

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.

So Java programmers have to convince Sun that a new feature is needed and then wait for them to add it (and then complain about it!) while Lisp programmers just go add it themselves.

Lisp macros makes the language incredibly malleable. Adding a new block construct such as foreach is trivial. This makes Lisp more powerful but with power comes substantial responsibility. Does this approach scale? Does this approach promote reuse and common libraries? I’ve worked on projects with hundreds of Java programmers but the largest Lisp project I ever was involved with had only five developers. Since Lisp is so malleable, how would a large project avoid lots of little local dialects?

Maybe I’m just looking at this in the wrong way. Perhaps, as Richard Gabriel has written, Java and Lisp are intended for different purposes:

The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs.

Viewed in this way, it’s unlikely that you’d find more than a handful of Lisp developers working together.

Posted in Uncategorized.

0 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

Some HTML is OK

or, reply to this post via trackback.