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!