Book review: “Beautiful Code”, edited by Andy Oram & Greg Wilson
September 28th, 2007 at 10:54 amThis book came to being from a very good idea. The editors decided to go around and ask renown programmers and designers about snippets of code, software architecture, design or anything related they found beautiful and see as an example of good design.
Indeed, the idea is terrific. After all, besides books describing specific technologies we read on a per-need basis, what books do programmers have to read for inspiration ? Consider artists and architects, for example. They have peer art and work to study and be inspired by. Sure, code reading is highly recommended, but wouldn’t it be great if someone had already collected all the good bits ? Wouldn’t it be sweet for Brian Kernighan and Yuhikiro Matsumoto to tell you what they’ve found beautiful ?
Unfortunately, this books doesn’t fulfill the high expectations I had from it. It’s not bad, no, but it isn’t as good as I hoped it to be. There are two main reasons for this:
- Many of the authors forgot that they’re writing for a paper book, and not an online article / blog entry. When reading a paper book, you can’t just click on links to find out more information. Therefore, I’d expect many chapters to be more complete. The authors could have spent a few extra lines to explain a concept instead of referencing it to some online resource or (worse) a paid-subscription-access paper at ACM. This is a paper book - I want to read it on the bus to work. Had I wanted to read an online article jumping around links, I would just do that.
- A few of the chapters in the book are just way too specific. How many people would understand a chapter about LINPAK - a Fortran library for linear algebra manipulation, especially when the author is very parsimonious in explaining the concepts and sends you to linear algebra tomes instead (see complaint #1).
In general, I think that to better execute the idea of such a book, a panel of experts has to be assembled and scrutinize each and every article. I would be much happier to read a book of 10 great articles than a book of 33, of which 10 are great. Who said that each and every programming book should be more than 600 pages long ?
However, I want to finish on a positive note, since as I stated in the beginning, the book is not bad. Here’s a list of articles I found really good and interesting. I guess that just for them it was worth to read:
- Chapter 1, A Regular Expression Matcher, by Brian Kernighan
- Chapter 2, Subversion’s Delta Editor: Interface as Ontology, by Karl Fogel
- Chapter 3, The Most Beautiful Code I Never Wrote, by Jon Bentley
- Chapter 8, On-the-Fly Code Generation for Image Processing, by Charles Petzold
- Chapter 10, The Quest for an Accelerated Population Count, by Henry S. Warren, Jr.
- Chapter 16, The Linux Kernel Driver Model: The Benefits of Working Together, by Greg Kroah-Hartman
- Chapter 18, Python’s Dictionary Implementation: Being All Things to All People, by Andrew Kuchling
- Chapter 23, Distributed Programming with MapReduce, by Jeff Dean and Sanjay Ghemawat
- Chapter 28, Beautiful Debugging, by Andreas Zeller
- Chapter 33, Writing Programs for “The Book,” by Brian Hayes
Related posts:
September 28th, 2007 at 4:26 pm
I have not read this book, though it is on my reading list. However, I am having trouble understanding your first criticism. Are you complaining that it cites outside sources? That is actually standard for “paper books”, in fact it is often seen as a necessity. And often the cited resources are not freely available on the Internet (though like ACM articles, they can usually be found at a library). Yes, that all makes it more difficult to follow up on a source, but I’m worried that our generation has become spoiled by online resources like the Wikipedia and blogs and have forgotten (if we ever knew) how to do real research.
And I know you are just looking for a book to read while waiting for the bus and not writing a thesis, but doesn’t the complaint that they cited sources instead of going in depth contradict your next complaint that some of the articles were too specific?
September 28th, 2007 at 5:24 pm
There’s citing sources and there’s citing sources. When these sources are absolutely essential to understand the contents of the chapter, I don’t see it as a particularly good way to implement the idea of this book. Otherwise, one could easily add a chapter:
“The amazing A* algorithm”. Go read paper XXX by Dijkstra for more information.
And that’s it.
While sources can be used in order to add extra information in such a book, they can’t be made essential. Some chapters in the book actually get this quite right - you can understand the chapter easily just by reading it, but if you want some more in-depth information there are sources to turn to.
And I don’t think the comparison to a scientific paper is relevant. This is not what the book was written for. It’s always important to keep the initial goal in sight when implementing something.