In Defense of Lisp

Update: Be sure to also see the post The Perils of Lisp in Production, a complementary post.

I believed, and many others as well, that while Lisp is a flexible and expressive language, it would not be good in production environments. The principle reason I believed this was that Lisp is far too flexible and far too powerful to be simultaneously worked on by a team or several teams of people. With everyone creating their own macros and everyone writing code in their own style (perhaps some in an imperative style, or — in my case — largely functional style), how could everyone possibly understand code or be on the same page? The semantics and flow of the code would just not be uniform enough.

Well, it turns out, this preconception of Lisp in “production environments” is wrong.

I recently moved to Colorado (hence the stagnating blog) for a job. To my luck, it is a job which exclusively uses Common Lisp. The code base is several hundred thousand lines, which is a lot of Lisp.

My first semi-long-term project was to replace the system which generates printer commands to format and print fingerprint cards. This included a way to specify fingerprint cards which could be interpreted by the system and pull the necessary “fingerprintee” information out of the main database, format the card, fill it out, and send it to the printer.

I was luckily able to essentially begin this project from scratch, as the current code in there was not sufficient and abstract enough to deal with all of the possible cards.

However, while I did this project, I had to jump in and do tangentially related things with the code base. Anything from minor fixes to changing how the entire build process works.

Did I find myself gimped by the fact it was all written in Lisp — and that many of the developers who worked on the code no longer were a part of the company?

No!

The code isn’t necessarily trivial, as there is some macro-generating-macros about, some reader macros, etc. None of which could be delightfully explained by the author who no longer exists. But was it harder to understand than, say, Java? No.

The big difference between working on production code in Lisp over Java is that because Lisp doesn’t impose some rigid language structure, you can’t just mindlessly be a code monkey and wield the refactoring excavator (usually cut-and-paste in Java’s case) in the same way. Doing that will likely lead to unintended consequences. Dare I say that sometimes you have to think when you refactor or change code in Lisp. Is this a bad thing? Perhaps. Until you realize Lisp’s refactoring excavator is a lot more powerful than cut-and-paste. The entire language itself is a refactoring machine. Often times fixing code is as easy as writing a simple macro to just remold the code into the way it should be. If a macro would be too hacky, then #+#:ignore will comment out the entire S-expression ahead where you can test a replacement.

One especially nice thing about learning a new code base in Lisp is that you don’t really need any special tools to help you out. Emacs and SLIME help, but there are built-in features — built-in features located in the ANSI Common Lisp language standard — that help you out. Anything from inspect to describe to documentation. Class introspection at the REPL is a breeze, as is object introspection. If you have the privilege of using SLIME, then looking up definitions of symbols is priceless.

All in all, I think the idea that Lisp is a terrible language in production environments is absolute rubbish. With this new acquired experience, I think quite the opposite. I think Lisp is actually much better than other languages in production environments because of its flexibility. That is unless you want mindless monkeys writing your software.

5 comments to In Defense of Lisp

  • Satvik

    It’s really nice to have this testimonial. Lisp suffers from a lot of misconceptions, so thank you for clearing this one.

  • Great that someone with real Lisp experience is helping with the myth-busting !

  • Lisp has its own issues (like _all_ other environments), but if you understand them then the advantages in stability and productivity are appreciable. We have had long uptimes with lisp systems handling large loads. Very small teams made these systems. But above everything else you get enormous flexibility to adapt your system to needs. This combined with the interactive environment allows you to deploy changes faster than any other system. Nothing even comes close to this.

  • Jugesh Sundram

    Hi, I am a LISP noob. Your post on the power of LISP was a great read. I would like to know which IDE you use for Common LISP. I am not comfortable working on SLIME or EMACS. It is often confusing working with variants and I would like to stick to Common LISP.

    • Unless I am on a Lisp machine, I use Emacs and SLIME.

      For better or for worse, it is all I’ve ever used. I heard there are other IDEs like ABLE, but I am not sure how well they work.

      Sorry this is all I could help with.

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you post, please prove you are sentient.

What has leaves, a trunk, and branches, and grows in forests?