On LISP: Advanced Techniques for Common LISP (Perfect Paperback)

Looking at Graham's code felt like reading my own code masterfully translated, say, from Danish to Swedish. A lot of the ideas are the same, some of the old friends had new names, and there were some new friends that I had never bothered to abstract and name, but recognized instantly once Graham did so (e.g. mapcars, fn).

Along with the ideas, I admire the many handy turns of phrase that make the book a real page-turner:

"It used to be thought that you could judge someone's character by looking at the shape of his head. Whether or not this is true for people, it is generally true of Lisp programs."

"The classic Common Lisp defmacro is like a cook's knife: an elegant idea which seems dangerous, but which experts use with confidence."

"Lisp is not inherently about processing lists any more than Polo shirts are for Polo" (Note that the sentence would have been a little confusing if Graham had written "list processing" rather than "processing lists". In Graham's prose, like his code, every word counts. Time and again I can only say "I wish I had thought of that.")

Paul Graham has commented on his web site ..., "It seems to me that there have been two really clean, consistent models of programming so far: the C model and the Lisp model. These two seem points of high ground, with swampy lowlands between them. As computers have grown more powerful, the new languages being developed have been moving steadily toward the Lisp model." I read that comment before I read On Lisp. It was fresh in my mind at the time, and I saw some of the features of Lisp in C++ and Java. Graham cites runtime type checking and garbage collection, but there are subtler features that appear in the C++ STL. When he described using macros to create functions as needed, his examples immediately brought to mind some of the templates for various "helper" classes; pair, for example. But he could equally well be talking about some of the classes in the Java runtime that are designed to be derived from. The bottom line is that this book is an excellent tutorial on good library design. It teaches by example the philosophy behind creating libraries that extend your language, either in general ways or specifically for the problem domain.

Paul Graham handles Lisp lovingly as an expert craftsman. An observant reader can learn a great deal about craftsmanship from his book. Eric Raymond stated in his essay How To Become A Hacker, "LISP is worth learning for a different reason - the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot." Mr. Graham has commented about this specific quote wondering why anyone would learn about a great tool and then not use it. Lisp in general and this book specifically are an answer to that question. Lisp is not a single language. It is a family of languages that share a common philosophy and a core. Once you learn what gives Lisp its power, you can choose to enhance any tools you use with some measure of that power.