For some languages, the payoff is relatively obvious. For instance, if you want to write low-level code on Unix, you should learn C. Or if you want to write certain kinds of cross-platform applications, you should learn Java. And any of a number companies still use a lot of C++, so if you want to get a job at one of them, you should learn C++.

For most languages, however, the payoff isn’t so easily categorized; it has to do with subjective criteria such as how it feels to use the language. Perl advocates like to say that Perl “makes easy things easy and hard things possible” and revel in the fact that, as the Perl motto has it, “There’s more than one way to do it.”1 Python’s fans, on the other hand, think Python is clean and simple and think Python code is easier to understand because, as their motto says, “There’s only one way to do it.”

The nearest thing Common Lisp has to a motto is the koan-like description, “the programmable programming language.” While cryptic, that description gets at the root of the biggest advantage Common Lisp still has over other languages. More than any other language, Common Lisp follows the philosophy that what’s good for the language’s designer is good for the language’s users. Thus, when you’re programming in Common Lisp, you almost never find yourself wishing the language supported some feature that would make your program easier to write, because, as you’ll see throughout this book, you can just add the feature yourself.

Consequently, a Common Lisp program tends to provide a much clearer mapping between your ideas about how the program works and the code you actually write. Your ideas aren’t obscured by boilerplate code and endlessly repeated idioms. This makes your code easier to maintain because you don’t have to wade through reams of code every time you need to make a change. Even systemic changes to a program’s behavior can often be achieved with relatively small changes to the actual code. This also means you’ll develop code more quickly; there’s less code to write, and you don’t waste time thrashing around trying to find a clean way to express yourself within the limitations of the language.2

For starters, the interactive read-eval-print loop, which I’ll introduce in the next chapter, lets you continually interact with your program as you develop it. Write a new function. Test it. Change it. Try a different approach. You never have to stop for a lengthy compilation cycle.3

Other features that support a flowing, interactive programming style are Lisp’s dynamic typing and the Common Lisp condition system. Because of the former, you spend less time convincing the compiler you should be allowed to run your code and more time actually running it and working on it,4 and the latter lets you develop even your error handling code interactively.

Whatever new paradigm comes down the pike next, it’s extremely likely that Common Lisp will be able to absorb it without requiring any changes to the core language. For example, a Lisper has recently written a library, AspectL, that adds support for aspect-oriented programming (AOP) to Common Lisp.5 If AOP turns out to be the next big thing, Common Lisp will be able to support it without any changes to the base language and without extra preprocessors and extra compilers.6