Preparing to LISP

Greenspun’s Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.
Philip Greenspun

Including Common Lisp.
Robert Morris

I’ve been working on a top-secret, ultra-hush-hush project for my company for several years now — so secret that I can say nothing else about it at this point, not even the working name, so don’t ask. 🙂 I was discussing it with a security-cleared associate last week, and mentioned a feature that (so far as I know) exists only in the LISP programming language. He had never used the language, so I pointed him at a few ‘net resources on it (including Paul Graham’s Lisp pages) to get him started with it.

While digging up those resources, I realized that I hadn’t really learned what LISP was all about myself. I knew the features that are supposed to set it apart from all other programming languages, and I knew that several of the most respected professional programmers have said that programming languages are evolving toward it, but I’d never had the time to dig into into it enough to really understand it. So, being the geek that I am, I decided that it was time to do so.

One of the resources I found (too late to mention to my associate, unfortunately, but he’ll learn of it next week) was a book that wasn’t around the last time that I tried to dig into LISP around four years ago: Peter Seibel’s Practical Common Lisp. Even better, the book is available in it’s entirety on the author’s website — the link provided in the previous sentence takes you directly to it — so I could start on it over the weekend instead of waiting until at least Tuesday for Amazon to deliver a dead-tree copy. 🙂

I dived into it as soon as I could this weekend, but quickly hit a snag: the Lisp in a Box project is apparently no longer maintained, and wouldn’t compile under my Ubuntu system. Mr. Seibel’s LispBox derivative is more recent, but demanded a library called, which is a later version than I was able to find. I finally got impatient and decided to create my own Linux Lisp environment.

Nearly everyone who mentions Lisp suggests that you use Emacs as the editor for it, with a package called SLIME for proper Lisp formatting, so that was my first stop. The emacs21 and slime packages were available through Ubuntu’s apt-get system, so I installed them and started up Emacs. Following the instructions that I’d found, I confidently hit meta-x (the alt key is the default meta key under x86 Ubuntu) and typed slime, then hit Enter… only to find it claiming that I didn’t have a Lisp compiler/interpreter installed.

After a little research, I decided that I wanted to use the SBCL package for my Lisp compiler/interpreter, and it was easily available through apt-get too. But apparently the SLIME package wanted a file called lisp, not sbcl. After a little fumbling, I was able to create a soft-link from /usr/bin/lisp to /usr/bin/sbcl, then it started up just fine.

The preparations are now complete. 🙂 Next time I mention it here, I hope to have something more substantial to say.


  1. Usually you put something like this in ~/.emacs:

    (setq inferior-lisp-program “/usr/bin/sbcl”)

    instead of making a symlink from /usr/bin/lisp. “lisp” is the name of cmucl’s lisp runtime.

  2. If I ever work on a top-secret project, I’ll make them call it “Project X”. I always wanted to work on something called “Project X”.

  3. I’m closing the comments on this entry, it’s getting nothing but comment spam now.

Comments are closed.