Common Lisp

Why Common Lisp

Lisp is an odd family of languages. Despite relatively sparse industrial use they have a lot of cultural cachet among programmers. The three most well-known members of the lisp family are probably Clojure, Scheme, and Common Lisp.

How I came to Common Lisp has a lot more to do with the mentors I encountered as I was learning to program than about the language itself. I'm grateful to both Will Halliburton and Leslie Polzer for the time they spent letting me into their worlds and showing me the ropes. But I've stayed with the language for my own reasons.

A lot of the advocates for lisps speak reverently of homoiconicity, macros, and metaprogramming. These are nice qualities but they are not what keep me writing it. I'm more compelled by three things:

1. Interactivity
2. Durability
3. Flexibility

Interactivity

It is very hard to convey just how different it feels to me to work on a Lisp application compared to one written in more typical dynamic languages like Ruby or Python. Mikel Evins has written a few posts that do a better job explaining it than I can muster.

In short, when I program in Lisp, my editor (emacs) connects to the program while it runs and lets me query the runtime for call sites, redefine functions, classes, and instances on the fly, add type hints, disassemble compiled code for my functions, and do all manner of other magic that "just works". Michael Malis wrote a good series back in the day covering some of these conveniences.

This is also why it's critical to use Slime or an equivalent for your editor (Slimv, etc) when programming common lisp. Your closest point of comparison might be an LSP server but I have yet to encounter an LSP server that is as powerful and thoroughly integrated with its host language as SLIME.

Common Lisp and Smalltalk are some of the last vestiges of a lost culture of programming that was intensely focused on feedback and live systems. I wouldn't claim that those cultures are superior to engineering cultures of today but I would say they prioritized a different set of values and they have much to learn from as a result.

Most of the languages in wide use today don't prioritize the sort of live feedback and redefinition that Common Lisp and Smalltalk made possible. I suspect Erlang may be the closest to retaining some of those values. There are some interesting pieces of academic research in recent years that do a good job showing how much of a monoculture we are in from that perspective.

Tomas Petricek's Dimensions of Programming Systems is a very valuable map of the territory. Josh Horowitz' Dimensions of Feedback is also relevant.

Feenk and the Glamorous Toolkit are continuing to push the envelope on what liveness as a cultural value looks like.

Durability

This point is a lot simpler than the last one. Common Lisp code keeps working. I have applications I wrote 10 years ago that run just as well today as they did in 2015. No major language changes or massive API breakage to address. They just work.

As someone embroiled in the cauldron of SaaS development, steeped in ecosystems like Ruby and Javascript where there is lots of active churn in tooling, standard libraries, and so on, the appeal of something that was ANSI standardized in 1994 and just keeps working is hard to overstate.

Flexibility

Common Lisp is an unopinionated language. It can do Functional Programming, it can do Object Oriented Programming. You want to feel bits between your toes, sure, here are the bits. I would say it isn't very accomodating if you want the Strong, Statically Typed flavor of functional programming but then there's Coalton.

I'm sympathetic to the view that language paradigms are not a great way to think about and categorize languages. But the crucial point remains that I have been able to evolve my style and experiment with many ways of attempting to write programs because rather than telling me "The Right Way" to build software, Common Lisp tries to let me approach problems in whatever way feels sensible to me.

No language is perfect. There are lots of things that aren't great about Common Lisp. The standard library is a work of deep compromise. The library ecosystem has some gems but only covers so much ground. But at the end of the day, it is a great tool for thinking.

Where to Start

I'll share three resources here. First, it's hard to beat Steve Losh's Road to Common Lisp as an informal tour to serve both as motivation and a beautiful distillation of one person's experience. That should serve as a nice big picture overview.

Once you've got your editor setup and a compiler installed, you'll need a good guide to the language and despite the many years since it was written there still isn't a better demonstration of how to approach problems with Lisp than Practical Common Lisp by Peter Seibel. It's available free online to boot! The one thing it doesn't cover that you should make sure to setup for modern package management conveniences is quicklisp.

Finally, you'll probably want a project template at some point that has niceties for unit testing and generating documentation. I wrote one myself and while it caters a bit to my personal biases in terms of libraries, it is easy to modify and should be a good starting point for devs new to the ecosystem. Happy Hacking!