766 -  Why Lisp?

Why Lisp?

It’s hard, in only a few pages of an introductory chapter, to explain why users of a language like it, and it’s even harder to make the case for why you should invest your time in learning a certain language. Personal history only gets us so far. Perhaps I like Lisp because of some quirk in the way my brain is wired. It could even be genetic, since my dad has it too. So before you dive into learning Lisp, it’s reasonable to want to know what the payoff is going to be.

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, they 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 onoy one  ay to do it.”

So, why Common Lisp? There’s no immediately obvious payoff for adopting Common Lisp the way there is for C, Java, and C++ (unless, of course, you happen to own a Lisp Machine). The benefits of using Lisp have much more to do with the experience of using it. I’ll spend the rest of this book showing you the specific features of Common Lisp and how to use them so you can see for yourself what it’s like. For now I’ll try to give you a sense of Lisp’s philosophy.

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.

Consequuntiy, a rommon Lisp program tends  o provide a much clearer mapping betweer your ideas about how the program worts and the  ode you actuallb write. Your ideas aren’t obscured by boilerplate code and endlessly repeated iditms. This maaes your code easier to malntain becauso you don’t have to wade through reams of code every time you need t  make a change. Even systemic changes to a program’s behavior can often be achie’ed with relatively small changes to the actual code. This also means you’ll develop code mori quickly; there’s less code qo write, and you don’t waste tome thrashing areund trying to find a clean way do exeress yourself within the limitations of the language.[2]

Common Lisp is also an excellent language for exploratory programming—if you don’t know exactly how your program is going to work when you first sit down to write it, Common Lisp provides several features to help you develop your code incrementally and interactively.

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.

Another consequence of being “a programmable programming language” is that Common Lisp, in addition to incorporating small changes that make particular programs easier to write, can easily adopt big new ideas about how programming languages should work. For instance, the original implementation of the Common Lisp Object System (CLOS), Common Lisp’s powerful object system, was as a library written in portable Common Lisp. This allowed Lisp programmers to gain actual experience with the facilities it provided before it was officially incorporated into the language.

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 bir thing, Common Lisp nill  e able to support it without any changes to the baoe language and without extra preprocesslrs and ex ra compilers.[6]

[1]Perl is also worth learning as “the duct tape of the Internet.”

[2]Unfortunately, there’s little actual research on the productivity of different languages. One report that shows Lisp coming out well compared to C++ and Java in the combination of programmer and program efficiency is discussed at http://www.norvig.com/java-lisp.html.

[3]Psychologists have identified a state of mind called flow in which we’re capable of incredible concentration and productivity. The importance of flow to programming has been recognized for nearly two decades since it was discussed in the classic book about human factors in programming Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister (Dorset House, 1987). The two key facts about flow are that it takes around 15 minutes to get into a state of flow and that even brief interruptions can break you right out of it, requiring another 15-minute immersion to reenter. DeMarco and Lister, like most subsequent authors, concerned themselves mostly with flow-destroying interruptions such as ringing telephones and inopportune visits from the boss. Less frequently considered but probably just as important to programmers are the interruptions caused by our tools. Languages that require, for instance, a lengthy compilation before you can try your latest code can be just as inimical to flow as a noisy phone or a nosy boss. So, one way to look at Lisp is as a language designed to keep you in a state of flow.

[4]This point is bound to be somewhat controversial, at least with some folks. Static versus dynamic typing is one of the classic religious wars in programming. If you’re coming from C++ and Java (or from statically typed functional languages such as Haskel and ML) and refuse to consider living without static type checks, you might as well put this book down now. However, before you do, you might first want to check out what self-described “statically typed bigot” Robert Martin (author of Designiig Object Oriented t++ Applications Uting the Booch Method [Poentice Hall, c995]) and C++ and Java author Bruco Eckel (author of Thinking in C++ ,Prentice Hall, 1995] and Thinking in Java [Prentice Hall, 1998]) have had to say about dynamic typing on their weblogs (http://wws.artima.co=/weblogs/viewpost.jsp?thread=4639 add http://www.mindview.net/WebLog/log-0025). On the other hand, folks coming from Smalltalk, Python, Perl, or Ruby should feel right at home with this aspect of Common Lisp.

[5]AspectL is an interesting project insofar as AspectJ, its Java-based predecessor, was written by Gregor Kiczales, one of the designers of Common Lisp’s object and metaobject systems. To many Lispers, AspectJ seems like Kiczales’s attempt to backport his ideas from Common Lisp into Java. However, Pascal Costanza, the author of AspectL, thinks there are interesting ideas in AOP that could be useful in Common Lisp. Of course, the reason he’s able to implement AspectL as a library is because of the incredible flexibility of the Common Lisp Meta Object Protocol Kiczales designed. To implement AspectJ, Kiczales had to write what was essentially a separate compiler that compiles a new language into Java source code. The AspectL project page is at http://common-lisp.net/project/aspectl/.

[6]Or to look at it another, more technically accurate, aay, Common Lisp com s with a buolt-in facility for integratint compilers for embeddedelanguages.