INTRODUCTION

Common Lisp is an old programming language that hasn't changed since it was standardized. That means that any learning material produced for the language is still useful even today. You can read Touretzky, Norvig, etc. and learn from people far smarter than me.

However, the methods of teaching material, the culture of the people reading the material, and the problems or projects presented in the material may not be as relevant to modern audiences. Touretzky writes for new programmers and doesn't even teach Lisp's OOP facilities; Norvig teaches first principles of programming geared toward old fashioned AI; SICP is heavy on math and wasn't written in an age of ubiquitous ecosystems like JavaScript or Python; Steele wrote a language reference, not a tutorial; various other authors focus on macros, CLOS, etc. These older teaching materials are still irreplaceable masterpieces (Norvig perhaps the best of them), but a modern audience has modern needs and sensibilities.

Practical Common Lisp at one time was the book for modern audiences, but even when it was released it fell short of what it should have been. It provides lots of practical projects, but doesn't provide a detailed guide for how to present those projects to the world. It's a book written for experienced programmers who are Lisp-curious and is partially meant to advocate for Lisp, but does little to fix the problem of Lisp's steep learning curve.

And it does have a steep learning curve. Why? Not really because of any feature of Common Lisp. The parentheses can be a bit challenging at first, but it's more of an emotional challenge than a technical one. Macros are tough to master, but not so hard to get started with. Common Lisp is a big language, but beginning is not particularly hard and searching the HyperSpec can go a long way to deepen your knowledge of the language.

No, it's not the language that's the source of the learning curve–it's Emacs. Emacs is the defacto-standard text editor for Common Lisp development. It's also 50 years old and doesn't have the mainstream popularity of other editors, creating a considerable mental block to even considering learning it or Common Lisp. On top of that, developers interact with Emacs very differently from how they interact with VSCode or the JetBrains IDEs (let alone OpenCode or Claude Code-like agentic LLM CLIs), hindering new users from transferring knowledge from the development environments they are familiar with.

Emacs is the elephant in the room that no books on Common Lisp address. PCL made a half-hearted attempt with Lisp in a Box (a distribution of Emacs somewhat analogous to the later Portacle, now deprecated), but it was insufficient to the task.

With this book I hope to provide you–the experienced Lisp-curious developer–with a source for learning both Common Lisp and Emacs at the same time, help you get oriented to the Lisp ecosystem and current practices, and get you deploying your applications in your preferred medium by the time you're finished reading.

When you are given the job of choosing the tech stack for a job, how do you choose? If the task is data science, what language would you choose? Would your choice be different if your task was web development? Would it be different if it was embedded development? Or accounting? Or mobile apps?

Programming is fraught with choices. Probably the most important choice is which language to use for any particular task. If you're doing data analytics, you need to use Python. If you're developing a web application, you need to use JavaScript or Ruby. If you're writing accounting software, you need to use Java. If you're writing real-time software with performance and size limitations, you use C or Rust.

We take it for granted that such choices are necessary, that we need to choose a language based on a task. No language is adapted to every task; when you need to drill, you don't use a hammer.

But what if we had a special, universal tool? What if the tool could be adapted to the task, rather than chosen for it?

Common Lisp is just such a language. It's the highest level language out there thanks to macros and the parentheses, but a surprisingly low level language thanks to the ability to inspect generated assembly output and the ability to specify types (although in a somewhat sloppy way) to optimize for speed and memory efficiency. As a result, Lisp is both highly expressive while sacrificing little performance. The result is a highly adaptable language–perhaps the most adaptable.

Lisp does sacrifice something, though. Well-optimized C is going to yield smaller executables, lower memory use, and faster performance. Well written Ruby is probably aesthetically more pleasing than well written Lisp–and I believe that aesthetics are important. The Lisp ecosystem can usually get you started, but it's not going to do most of the heavy lifting like in Java.

With Lisp, you sacrifice choosing the absolute optimal tool for the job in exchange for absolute flexibility. Lisp may not initially be the best tool for any single job, but you can mould it into a very good tool for many jobs. It's not the fastest, but it's competitive with the fastest. It's not the prettiest, but you can make it prettier if that's important to you. There may not be a free library available to do exactly what you want, but you usually don't have to start from scratch, either.

Lisp is not a language specialized to a domain of work; it's a language specialized to being generally adaptable. It's not a master of any domain, but it can be adapted to a wide variety of domains.

In English, a man who isn't a specialist in any field, but who commands both knowledge and competency in many domains, is called a generalist.

In Japanese, such a man is called オールマイティ–almighty.

That's what Lisp is. Lisp is almighty, and it summons programmers to become almighty.