Common Lisp: First Impressions

Close Subscribe Menu 07 February 2016 on lisp, programming

I’ve been hacking around in Clojure for a few years now, and while I like the language very much there are a few quirks of the implementation which I still find irritating, namely the glacial startup time and general un-suitability to writing small programs.

So this week I’ve been looking at Common Lisp, in search of another nice lisp dialect to add to my tool-box.

Some general impressions:

roswell is pretty nice, making it easy to get sbcl, quicklisp and asdf installed
Practical Common Lisp is a good book, very easy to read and gets right to the point without trying to explain what programming is from the ground up
SBCL seems fine, I’ve not had any trouble with it yet
The ecosystem seems to be plenty diverse, with robust implementations of all the things I’d care about
The language can be a bit weird:
- To a beginner it’s not clear why getf, setq and co are named the way they are
- Using higher-order functions can feel a bit clunky, using #'foo and (funcall foo x y z) feels much less clean than the equivalent code in Clojure. More than once I’ve stumbled on what to do when returning a lambda from a function, binding it to a var and then passing it along to another function
- Common Lisp doesn’t seem to have a fundamental sequence abstraction like Clojure, so it’s a lottery trying to figure out which functions will work on whichever data-type you’ve got in hand.
- Verbosity seems like it’s going to be a problem, function names are usually pretty long and there are no data-literals in the style of Clojures {}, [] and #{}
- The Common Lisp Wiki looks like a nice source of up-to-date information on Common Lisp
- Common Lisp makes uses the empty list ((), or nil) to denote boolean false, which I could see causing all sorts of problems when parsing formats like JSON. Actually, now that I think about it, this makes working with any external data basically untenable, the language simply doesn’t have a concept of empty-list, null and false being different things.

I think I’ll keep going with this one, despite some flaws Common Lisp does look like a promising language and a good candidate for small, compiled programs and little network services.

Shane Kilkelly’s Picture