I am a constant reader. I travel quite a lot for business, and I find that a good programming book can either keep me from getting bored or put me to sleep on a long flight. Either one is better than staring at my tray table, folded up against the seat in front of me.
This page lists a variety of books that I have read over the years that I thought you might be interested in. Given the focus of this site on Lisp, I have mostly covered Lisp-related books here, but in some cases there are larger classics that transcend a particular programming language, and sometimes transcend programming entirely.
These reviews reflect my own personal experience in reading these books. As with any critic, it's quite likely that you'll disagree with me on some of these reviews. Don't let it get to you. We all start from different places. Where I strongly like or dislike a particular title, I have tried to give you some commentary as to what I found that drove my reaction. Hopefully, you can determine whether you would react the same way I would when given the same title, or not.
All ratings use a one through five scale.
I have tried to categorize things a bit:
- General Interest
Hackers and Painters: Big Ideas from the Computer Age
Rating: 5 lambdas
I have a strong affinity for Paul Graham. I first got interested in learning Lisp in late 2003 after reading some of the Lisp writings on his web site. He's one of those people that just makes sense to me. I think that's because we're both very similar. I convinced my wife that she'd enjoy the first few chapters of Hackers and Painters and so she read them after I had finished it. Her first response was, "This guy is so similar to you, it's freaky." That about sums it up. I think Graham is a couple years older than I am, but we seem to have very similar personality traits and many shared experiences. If you have a copy of Hackers and Painters, look on the picture of the chess club on page 4. In 1981, I was the spitting image of the guy in front, on the right (we all had our hair parted down the middle and feathered in 1981). And yes, I was in the chess club, too.
In any case, Hackers and Painters is a collection of essays that Graham has written over the years. Many of the essays are posted on his web site. You may be saying, "Why pay for a book when I can read them all for free?" While the material may not be completely original, the collection certainly is. Most of the essays have been re-edited, with some changes, and there are some completely new essays, too, available only in the book.
- Why Nerds Are Unpopular -- Their minds are not on the game.
- Hackers and Painters -- Hackers are makers, like painters or architects or writers.
- What You Can't Say -- How to think heretical thoughts and what to do with them.
- Good Bad Attitude -- Like Americans, hackers win by breaking rules.
- The Other Road Ahead -- Web-based software offers the biggest opportunity since the arrival of the microcomputer.
- How to Make Wealth -- The best way to get rich is to create wealth. And startups are the best way to do that.
- Mind the Gap -- Could "unequal income distribution" be less of a problem than we think?
- A Plan for Spam -- Till recently most experts thought spam filtering wouldn't work. This proposal changed their minds.
- Taste for Makers -- How do you make great things?
- Programming Languages Explained -- What a programming language is and why they are a hot topic now.
- The Hundred-Year Language -- How will we program in a hundred years? Why not start now?
- Beating the Averages -- For web-based applications you can use whatever language you want. So can your competitors.
- Revenge of the Nerds -- In technology, "industry best practice" is a recipe for losing.
- The Dream Language -- A good programming language is one that lets hackers have their way with it.
- Design and Research -- Research has to be original. Design has to be good.
- Image Credits
This book covers a wide ranging set of subjects and doesn't confine itself to a single topic. The overall theme of the book is about gaining an understanding of the digital age, the people who are involved with creating this age, their motivations, and the tools they use to do their work. The book's subjects range from an explaination of nerds and their fit within the American educational system, to how to get wealthy, to how to combat spam, to programming language design.
The chapters are loosely tied together, but each is a standalone essay and so, at times, the book is more choppy than it could have been. Still, this provides a lot of variation and each essay has a depth to it that leaves the subject relatively well addressed by the end.
The "Why Nerds are Unpopular" chapter struck a definite chord in me. This chapter describes the US educational system and how generally messed up it is, being a combination of baby sitting and prison, with little to no purpose to much of the activities from the view of the young participants. I have a four year old daughter who is just about ready to start kindergarten, and my wife and I are having to make that hard choice between the California school system (of which I am a product) and home-schooling. After reading this chapter, I was more convinced than ever that we should home-school. Interestingly, this was not Graham's conclusion, as he says in an endnote:
Home-schooling offers an immediate solution, but it probably isn't the optimal one. Why don't parents home-school their kids all the way through college? Because college offers opportunities home-schooling can't duplicate? So could high school if it were done right.
Other chapters struck chords with me for Graham's examination of how great things are built. I guess I'm a bit of a romantic. I like and appreciate good design. Bad design makes me downright cranky. Over the years, I have learned that most engineers are just hopeless when it comes to design. This partially goes along with most engineers being, well, hopeless in general. We seem to have churned out a whole generation of people who got into high technology because it offered a good salary and seemed like the thing to do, whether or not they had any aptitude for it. You know the type of engineer. You have all worked with one or more of them. If they were surgeons, people wouldn't be bleeding but everybody would look like Frankenstein after being worked on by one of those guys.
The chapters Hackers and Painters, Taste for Makers, and Design and Research tackle the topic of good design, both what it looks like as well as the types of personalities that are capable of producing it. Taste for Makers begins with a great quote:
I was talking recently to a friend who teaches at MIT. His field is hot now and every year he is inundated by applications from would-be graduate students. "A lot of them seem smart," he said. "What I can't tell is whether they have any kind of taste."
Indeed. Skills are easy. Taste is difficult.
If I have one complaint about this book, it is that it tries to appeal to a wide audience and in the end misses the mark. Starting the Preface, Graham writes,
This book is an attempt to explain to the world at large what goes on in the world of computers. So it's not just for programmers. For example, Chapter 6 is about how to get rich. I believe this is a topic of general interest.
While it is true that there are sections that are of interest to a wide audience, the last half of the book is about programming and these sections are definitely going be seen as esoteric to those that are not programmers. It seems like Graham tries to carry the broad audience along through these sections by delivering a quick-study course on the workings of programming languages (chapter 10, Programming Languages Explained) and a fairly comprehensive Glossary. The problem is that the issues are just too deep for anybody to absorb rapidly and still be able to understand the material. If you weren't a programmer before you started reading this book, you simply won't understand some of the later chapters.
For instance, in the Programming Languages Explained chapter, Graham gives basic instruction such as
Any machine has a list of things you can tell it to do. Sometimes the list is short. There are only two things I can do to my electronic kettle: turn it on and turn it off. My CD player is more complicated. As well as turning it on and off, I can turn the volume up and down, tell it to play or pause, move back or forward one song, and ask it to play songs in random order.
Then, in the The Dream Language, a couple of chapters later, he writes about efficiency.
A good language, as everyone knows, should generate fast code. But in practice I don't think fast code comes primarily from things you do in the design of the language. As Knuth pointed out long ago, speed only matters in certain critical bottlenecks. And as many programmers have observed since, one is often mistaken about where these bottlenecks are.
So, in practice, the way to get fast code is to have a good profiler, rather than by, say, making the language statically typed. You don't need to know the type of every argument in every call in the program. You do need to be able to declare the types of arguments in the bottlenecks. And even more, you need to be able to find out where the bottlenecks are.
Now, that's all good advice, but it's directed straight to programmers, not to anybody who just learned what a programming language was four chapters previously, using analogies to electronic kettles and CD players. Knuth? Profilers? Static typing? What are you talking about??
In all, I give this book very high marks. It is well written and covers a broad range of interesting subjects. Rest assured, if you are a programmer, you will find lots of good material in this book. Even the Programming Languages Explained chapter is well written, if a bit tutorial.
ANSI Common Lisp
Rating: 5 lambdas
Review updated: 17-July-2004
Paul Graham has been one of people most responsible for the current uptick in Lisp programming. Graham's writings on his own web site and on various forums like Slashdot.org have raised the awareness of Lisp in a new generation of programmers that are too young to remember the AI Winter and are looking for something better than Java and C. ANSI Common Lisp is a great introduction to Lisp programming designed for those already familiar with programming but not yet familiar with Lisp. ANSI Common Lisp will not teach you how to program for the first time, but it will teach you how to program in Common Lisp.
Graham is a great writer. Like the essays on his web site, ANSI Common Lisp shows the same thoughtful presentation. Rather than just presenting the language, however, Graham introduces the reader to a larger philosophy of Lisp programming. Graham goes beyond Lisp syntax and describes why the reader should care about programming in Lisp and the advantages the reader is likely to see. He then goes on to demonstrate some of these advantages in code.
- Welcome to Lisp
- Specialized Data Structures
- Input and Output
- Advanced Topics
- Example: Inference
- Example: Generating HTML
- Example: Objects
- Lisp in Lisp
- Changes to Common Lisp
- Language Reference
While the book excels at giving the reader an introduction to Common Lisp, it is not exhaustive. There are many important pieces of Lisp that are not covered in great detail. The level of coverage for certain topics reflects Graham's own philosophy of Lisp and what pieces of it are most important. In some ways, Graham is quite controversial. ANSI Common Lisp, for instance, spends only a quick chapter on the Common Lisp Object System (CLOS). This reflects Graham's overall dislike for object-oriented programming. Instead, Graham prefers a generally functional programming style. Other important Lisp topics that receive minimal coverage include the condition system, the LOOP macro, the FORMAT function, and I/O streams. There is enough material to whet your appetite, but you'll have to go elsewhere for enough satisfaction to put these important concepts to good use in your own programs.
Now, the Language Reference section is quite valuable for reference and does include fairly exhaustive coverage of things like CLOS, conditions, the LOOP macro, and FORMAT syntax. The coverage is at the level of a reference manual, however--just the facts with no examples or discussion. This is to be expected, but presumably, you're reading the book because the CL Hyperspec is too terse.
For a broader perspective on Graham's philosophy and style as described in ANSI Common Lisp, you might check out Chris Riesbeck's chapter annotations and notes on the exercises. Riesbeck teaches a class on AI programming at Northwestern University and has provided a good counterbalance for Graham particular programming style. (Thanks to Bill Clementson for these references from his blog entry on ANSI Common Lisp.)
All in all, this is a great book, well worthy of space on your bookshelf. If you have not also checked out Graham's website, it makes a great introduction to Lisp and will tell you in fairly good detail why you should care about it.
Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS
Sonja E. Keene
Rating: 3 lambdas
From my blog on April 18, 2004:
I just finished Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS, by Sonja E. Keene. Here are my thoughts:
- The book is pretty expensive. It's fairly thin at just 266 pages, including the index, but the price is $39.99 USD. The amount of information you get for your money is pretty small. This may or may not bother you.
- The book covers CLOS in good detail, showing how to use various features like generic methods, generic dispatch, class inheritance, and initialization.
- The examples used in the book are fairly simplistic. They lack some of the meat that you'd expect in a book like this. There are two fundamental examples used throughout the book: a set of mutex locks, and a set of streams classes. I found the mutex locks to be particularly humorous since Common Lisp doesn't standardize threads. This isn't to say that the classes aren't useful as a learning tool, but they can't effectively be used in a standard CL implementation like SBCL, CMUCL, or CLISP without some amount of modification.
- The book has a nice reference section toward the end that details all the CLOS syntax for various forms. I think that this is the most useful part of the book, long term. The book is thin enough to be kept at the ready on a shelf close to your keyboard and pulled out for this section alone.
- The book is fairly old. The copyright date is 1989. No updates have taken place since that time. I don't think that CLOS has changed much, but I think the book is a bit dated. Some of the examples show a bit of history associated with the author's employer at the time, Symbolics.
In short, I found the book underwhelming. On a scale of 1 to 5, I'd give it a 3. There are other introductions to CLOS that seem to give you a reasonable introduction without the high price. If you want to understand some of the more advanced CLOS programming techniques, like :before, :after, or :around, or method combination types, then this book has something good to offer. If you just need a short introduction to the basics, I think you could check out resources on the web and save your money.
There are other books on CLOS that are highly rated on Amazon. I have not yet had a chance to read Object-Oriented Common Lisp, by Stephen Slade, but the folks on Amazon give it a half a star better rating than Object-Oriented Programming in Common Lisp.