Quicklisp - The upcoming solution to Common Lisp's "library problem"

We're all tired of hearing that Common Lisp is all nice, but it has a library problem. True, many of the open source libraries written in Common Lisp are half-baked, incomplete, unmaintained and tasteless. But this is true with libraries in all languages, so that can't be the real problem. The real problem, as I see it, is that until now, there was no universally good way of installing a library and all of its dependencies.

The existing, widely deployed solutions (asdf-install and clbuild) require external tools to work, depend on the availability of diverse servers in the internet, and do not have something like a central maintainer who ensures that things are always in basically working order. Also, these solutions are rather unportable, as they depend on external tools and a Unixish environment which is not available everywhere.

My personal solution to this problem, until now, was to have a Subversion repository that contains all the libraries that any of my projects need. Some of these came from release tarballs, some from other revision control repositories, and maintenance was manual. Whenever I started a new project, I brought some of those libraries up to date, coped with any (new) dependencies, lost backwards compatibility with my older projects etc. This kind of sucked, but it had the beauty that both development and deployment ended up being relatively easy. All that was required was a svn checkout from my repository, and I was all set on a new machine.

Recently, Zach Beane was fed up enough to do something about this: He created Quicklisp, a self-contained, centrally managed, cloud hosted Lisp library system which aims to run everywhere and provide users with a one-stop solution for the "library problem". Quicklisp is in an early alpha stage, but having tried it, I must say that I am pleased and impressed. Finally, Common Lisp can also become a glue language like Python and Perl.

I tried Quicklisp today because Twitter has notified me that basic http authentication for applications will no longer be supported. Instead, one is now supposed to use OAuth to authenticate requests sent to Twitter. This required my reaction.

About two years ago, I have written a small gateway program that forwards new postings to Planet Lisp to Twitter. At the time, I was rather frustrated with Common Lisp and thus took the gateway as an opportunity to try Clojure. Today, I looked at the source of the gateway again to find out what it would take to make it use OAuth instead of basic http authentication. As the gateway was the only program I have written in Clojure so far, and I was not really that eager to extend it to OAuth. I tried for a few minutes, but found that my old program did not run with the current Clojure version right away, so I would have to basically start setting up a Clojure development environment from scratch in order to be able to use an existing, open source OAuth library.

Instead, I thought I'd give Quicklisp a spin. After all, parsing some XML and sending HTTP requests are no big deal in Common Lisp either, and an OAuth library is available, too. With Quicklisp, all it should take was write some glue code to connect DRAKMA, CXML, cl-ppcre and cl-oauth. Installing the bunch should be a matter of loading quicklisp.lisp, then typing (ql:quickload `("drakma" "cxml" "cl-ppcre" "cl-oauth")) and watching the show scroll by.

And hey, it worked right away. I even embedded a web server in the gateway application so that it can be monitored by the system status monitors provided by my hosting provider. All in all, rewriting the thing in Common Lisp and deploying it took no longer than two hours, and the source is not significantly longer than the Clojure version either. Furthermore, the new gateway properly deals with non-ASCII characters. Embarrassingly, the Clojure gateway was buggy in that respect and never properly twittered the titles of my own blog posts. Thanks, Zach!