My appreciation of Beautiful Code is like the one I have for the Justice League or the X-Men-- a band of exceptional individuals moving towards a common, altruistic end. (Proceeds of the the book will go to Amnesty International. ) This compendium of insightful essays and articles is edited by Andy Oram and Greg Wilson.

The talent of the contributors is undeniable and the text reminds me of the Algorithms class I took in college. The book relates how various software design architects and experts attack and solve problems while maintaining the elegance of the implementation. The range of topics include Perl, Haskell, Python and Ruby. This should give the enthusiastic developer a fresh and broad perspective on software. I have to mention that the book is developer oriented, so expect a lot of code and text intertwined.

They say beauty is in the eye of the beholder. The book hopefully will be able to give you a new way to look at software.

Like others, I found the concept for this book intriguing, but in implementation, turned out to be a pretty significant borefest with little to no meaningful value that could be extracted from its contents. Disappointed - but I think I was doomed to be with my expectations of the book from its title and the plethora of respectable folks contributing.

I liked the idea of the book (real code, solving non-obvious problems), but it turned out to be a mixed bag in practice. 33 chapters, in different languages and at different levels. Some were pretty good and well worth reading; others not so much.

Unfortunately, I feel like I didn't learn all that much from this book - I'd already been exposed to just about all of the ideas presented therein. I think the problem most people are going to have with this book is: if you can read it without it being a hard slog, then you are experienced enough that you won't get that much out of it.

As another commenter has already said, a better plan might have been to have had a roundtable of programmers from different backgrounds to critique the designs and discuss how they might have looked using different languages. Now that could have been really interesting.

As it was, some of the presentations seemed distinctly un-beautiful, and the approaches taken raised serious questions in my mind. For example: a CGI program written in C - and a good part of the discussion was the effort to make the program look more polymorphic ... why then choose C? Why would one do such a thing? I assume there were good reasons, it would be enlightening to know what they are.

Or the chapter discussing how beautiful the Fortran routine SGBSV(N, KL, KU, NRHS, AB, LDAB, IPIV, B, LDB, INFO) is. Where is the beauty in unintelligible names - was that absolutely necessary (that's a real question - not being a Fortran expert, I don't know)?

Or the chapter where the author wanted to use a Java switch statement with over 10,000 cases but was stymied by JVM limitations. I might call that "unfortunate, but necessary" code, but never "beautiful".

Or the J2EE application which uses two levels of EJBs to stream files. The architecture sounded like overkill; it would have been useful to have had more discussion as to why that wasn't the case. This example also quoted code with boilerplate J2EE snippets like

Context context = MiddlewareUtility.getInitialContext();
Object queryRef = context.lookup("FileReaderLocal");
FileReaderLocalHome = (FileReaderLocalHome) PortableRemoteObject.narrow(queryRef, FileReaderLocalHome.class);
FileReaderLocal reader = home.create();

I've written too much tedious code like that in my life, and none of it goes into my book on beautiful code.

On the plus side, I enjoyed a number of chapters - the debugging and testing essays were well-done. Ditto for MapReduce, and the Python chapters (design of the dictionary, and an implementation of multi-dimensional iterators). I also liked the chapter on designing an accessibility-limited UI that had exactly a single button for user input. My favorite might have been the chapter on image-processing (emitting an algorithm tuned for a given data set). Those were well worth reading.

The editors of this uneven book give us 33 chapters from various, often well-known developers, in which these developers describe some code and explain why they think that it is beautiful. There are some gems, but it's not light reading and quite a bit of it is a real slog. If you are a professional programmer, it's probably worth the effort, but otherwise I'd steer clear.

And, in fact, all too much of the code is downright ugly. This starts, sadly enough, with the first example, by Brian Kernighan, describing a limited-capacity regular expression matcher.

Yes, THAT Brian Kernighan, a software god among men. But the example he describes as beautiful would be the last thing I would ever want in any software that I had to maintain. I am sure it is efficient, and it probably works, but the only beauty that I can see is that, if you convince yourself you understand why it works, you've also proven to yourself that your mental abilities put you in an elite category of coder. God help you if you need to modify the method's functionality or (shudder) debug it.

Another dubious entry in the book is by Adam Kolawa, who describes the CERN mathematical library. He claims that no library routine can be beautiful if it uses dynamic memory allocation. The software architecture he deems beautiful passes working memory, in the form of an array to the library routines, which in turn pass it on to their subroutines. In fact, the space used by the input parameters is reused to hold the solution. I am sure that CERN math library is an excellent package, but I would hate to have the job of tracking down bugs in a system in which all the subroutines in the stack were writing back into the same array.

Software ugliness can take many forms, as, for example, in the chapter by Ronald Mak, describing NASA software used for the Mars Rover mission. The solution for a highly reliable, long running, independent system? SOA, using Java 2 and J2EE EJBs. I am a big fan of Java and J2EE, but why on earth (or Mars!) would the Mars Rover system need EJBs? The SOA and EJB technology is at its best when coupling diverse databases and interacting with legacy systems. It brings with it a significant complexity and overhead. Why would anyone think this was appropriate for the Mars Rover?

For my taste, the worst of the worst was an article by R. Kent Dybvig, describing a program for analyzing code and detecting parameter name clashes. The code to be analyzed is in Scheme, a Lisp dialect. It's been awhile since I've fooled with LISP, but I was ready to give it a try. So here is an example of a macro that has potential scope issues, if there is a bound variable t elsewhere in the code:

(or e1 e2) -> (let ([t e1]) (if t t e2))

...and here is the refactored code, in which the problem is fixed:

(or e1 e2) -> (let [g e1] (if g g e2))

I stared dumbly at this for all too long a time until I read the next phrase, "in which 'g' is a generated (fresh) identifier". Here I'd fault the author for a really rotten presentation, and also for begging the question, since the whole problem he is purporting to solve is avoiding name clashes.

In fairness, the book also has many descriptions of genuinely beautiful code. I especially enjoyed the article by Charles Petzold on efficient image processing through code generated on-the-fly. Also, Henry Warren essay on devising efficient algorithms for counting the number of enabled bits in a bit string is fascinating. Yet another stimulating article is by Brian Hayes, who describes an efficient approach for determining if three points are co-linear. This article also uses LISP as the example language, but unlike Dybvig's piece, it's clear, and "porting" the approach to Java or C++ would be straight-forward.

In summary, "Beautiful Code" is a very mixed bag. On balance, it is probably worth reading, but without doubt it is a disappointment.

I guess that my main problem is that the 'beauty is in the eye of the beholder'. I returned the book after reading the first two chapters. So, I cannot claim to review the whole book, but the first to chapters were very far from what I can call 'beautiful code'.

The first chapter in the book presents a recursive C implementation of a greatly simplified regular expression parser. I would agree that this parser implementation is 'clever', but I cannot see the beauty of recursive C with pointer arithmetics.

The second chapter presents an interesting solution to keeping track of changes in the SVN client/server architecture. But again, while the algorithm is interesting the code is anything but beautiful. For one thing, the solution to this clearly object oriented problem is done in C (again), which makes the code harder to understand.