Digital Digressions by Stuart Sierra

From programming to everything else

It’s About the Libraries

Posted on by Stuart

There’s a big ‘ol thread going on down at comp.lang.lisp about Clojure vs. Common Lisp. I’m biased, of course, but I have to say that Clojure and Rich Hickey are holding their own against some of the top c.l.l. flamers.

But all the arguments about functional programming, software transactional memory, and reader macros miss what was, for me, the biggest reason to switch to Clojure. It’s about the libraries, stupid. Building on the JVM and providing direct access to Java classes/methods was the best decision in Clojure’s design. ‘Cause if it’s ever been done, anywhere, by anyone, someone’s done it in Java. Twice.

A few years ago, I tried to solve the Common Lisp library problem by writing a bridge from CL to Perl 5, and was laughed out of town. Rich Hickey, I’m told, spent years trying to bridge CL to Java, and never got very far. But Clojure works, and it works great. It’s a Lisp with a squintillion libraries. Who else can claim that?

So, if I wanted Lisp with Java libraries, why not use Kawa or ABCL … or heck, JRuby? Those are all fine projects, but they all suffer from mismatches between the “source” language (Scheme, CL, Ruby) and the “host” language (Java). There is never a one-to-one mapping between types in the source language and types in the host language. So you end up needing conversions like jclass/jmethod/jcall (ABCL) or primitive-static-method (Kawa). (JRuby is slightly better, but only because Ruby is closer to Java than CL/Scheme.)

Clojure doesn’t have this problem because it was designed from the ground up for the JVM. Clojure strings are java.lang.String, Clojure maps are java.util.Map, even Clojure functions are java.lang.Runnable (and java.lang.Callable). This makes it supremely easy to mix-n-match Clojure code with Java libraries and vice-versa. I know, because every day I use Clojure with complex Java libraries like Hadoop, Restlet, Lucene, and Solr. Everything just works. I don’t have to write any foreign-function interfaces or bridge code. In fact, using Java libraries in Clojure is often easier than using them in Java!

Clojure may not be a programming language for the next hundred years, as Arc aspires to be. But it’s a great language if you want to get stuff done right now.

11 Replies to “It’s About the Libraries”

  1. Clojure also has no 1:1-Mapping into Java, as far as I saw. I think the problem ABCL suffers from is simply that it is comparably slow and didnt spread across the CL-Programmers, and isnt well-developed right now.

  3. Fortunately Lispers, as a group, are most definitely not against the idea of embedding other languages; sure there are the purists but I can assure you that they are not they only group in the Common Lisp community.

    Rich Hickeys JFLI, which you allude to in your post, has been picked up by Nick Levine and is being used in production systems as well as being recently ported to CCL (previously it was only usable on Lispworks which hindered its adoption) so I would not go as far as saying that Rich didn’t get very far in providing an interface to java libraries.

    Personally, I would like to thank you, on behalf of Common Lispers who are interested in getting things done for working on providing an interface to a wealth of Perl libraries.

    Sean.

  4. Clojure most definitely does not use Java primitives, heck, all the Clojure data structures are immutable by default.

  5. Speaking as one of the original “Gang of Five” authors of “Common Lisp: The Language”, I am at this point convinced that Clojure is the future of Lisp (for production applications; Scheme will still have its place). I think all of those things (libraries, mostly-functional, transactions, maybe not reader macros) are very important. So is the general cleanup and the use of protocols throughout. These are all things I had been advocating for the last several years, including running on the JVM, so you can imagine how delighted I was the first time I heard Rich’s talk on Clojure.

    And I’m not surprised that Rich is holding his own. The guy is totally awesome.

  6. There are many reasons why I like Clojure, but the key feature that got me in the beginning is what Rich said in one of its presentations about Clojure on Java being the canonical implementation of Clojure.

    Clojure is my nth attempt to learn Lisp, and though the past failures are due to lack of commitment on my part, it really annoyed me when I was reading the excellent Practical Common Lisp book and read stuff like “The exact behavior depends on your implementation.” (I was not annoyed at the book, obviously, but annoyed at the fact the you get different behaviors on different implementations.)

  7. ABCL was a great effort by its original creator Peter Graves – he was the first one getting a nearly complete CL implementation that works on the JVM. Like many projects which are mainly driven by one person ABCL fell into a snow white sleep when – my guess – its creator didn’t find enough time and energy to get it any further. The same could happen to Clojure when its master mind may shift his priorities. The good thing with Clojure is, that it hopefully has got enough contributors to recover from such a thing reasonably fast. Another good thing is, that ABCL is far from being dead – several contributors, particularily Erik Huelsmann work since months enhance and optimize it. I’ve written an article (not yet published) in which I compared (an older version of) ABCL in speed to several other CL implementations. The only thing that could be called slow was CLOS – all other parts were surprisingly fast. To me Clojure was a nice thing, because it shows many nice language ideas; but a solid ABCL is actually more stunning to me because it brings the rich world of CL to the JVM as a plattform. Many of Clojures nice ideas can get adapted to CL.

    Regarding the implementation dependencies of CL:
    Every language standard that isn’t defined through one particular implementation needs to define limits to create some freedom for implementors to do the right thing for their platform. I think it is really some kind of art to get this freedom declared in a way that doesn’t hinder implementation and at the same time doesn’t spoil the standard. CL is a particularily good example here. IMHO defining a programming language by just declaring your own implementation as the standard neither a good idea nor a great design decision.

  9. […] развития своего любимого инструмента. Он считает, что в будущем диалект Clojure вытеснит Common Lisp.   Прочитав […]

  11. Absolutely agree with this blog article’s premise. I think most people *want* their libraries AND favorite language.

    Hearing Rich Hickey talk about Clojure’s integration with Java/JVM gave me the same excitement that hearing Jim Hugunin talking about how IronPython was such a good fit for the CLR and .NET Framework did.

    I learned Scheme a long time ago and never got too far precisely because there weren’t that many libraries for it. Now Clojure is whetting my appetite for learning a Lisp all over again.

Comments are closed.