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.

I like this book but it is a flawed thing.

Worth the read but not convinced it is worth the cost.

I started more than half the chapters and skipped on because either it was too obtuse or specific to a given language/problem or too general to be useful.

However there are also some great chapters.

If you are looking for a gift for the tech-head who has everything then this could be a good choice. If funds are tight and you are buying for yourself you probably have better ways to spend the cash.

I can't be too critical. The intent was noble and good. The authors are donating any profits to charity. I can't point to a better way of writing/structuring the book.

So yes it's good and I liked it but my praise is conditional and constrained. I feel churlish for saying these negative things because it is, as I said, well intentioned. I just wish it was better described as it was not what I thought I'd be getting. Not that I feel ripped off, just a little bemused.

I must say I was pretty disappointed with this book. I expected so much more. The lead off piece by Brian Kernighan is the best in the book. I hoped that the rest of the book would at least try to be as good, but other than Matz's essay and perhaps Bently's (I can't remember now) they were mostly drek. Several were agonizingly boring, long fluff pieces about something they worked on that read as histories of the work they did on a piece of software. Very little insight into the creative process or anything else interesting.

For a book with so much potential, it was a huge let down.

There's a critical need for a book on code aesthetics, elegance and comprehensibility that goes beyond simple style guidelines -- this isn't that book. The contributions are uneven, a few border on the incomprehensible, and most are simply not worth the time. There are no revelations or insights to be had.

i regret buying this book. i dont see the beauty of the code nor do i see how many of the contributors think. much of the material described here is accessible else where and probably in a more readable and enjoyable form.

the map reduce article is lame compared to its original version. the authors had to put something in there from google, i felt.

the beautiful concurrency in haskell is overstated.

This book is a mixed box of chocolates. Don't read it expecting a lot of useful ideas on how to improve your code: It's more of a book you read to widen your horizon a bit. Each chapter stands on its own and talks about a different project. Languages include C, Java, Perl, Python, Lisp and others.

Fortunately, most authors don't dwell too much on their definitions of "beautiful" code (a rough consensus appears to be that beautiful code is readable, concise, efficient, and, surprise, does something useful). The meat of this book are code fragments and explanations of the code and algorithms (and their context).

Despite the explanations, several of the chapters left me scratching my head. Understanding and appreciating all of the code (including that from unfamiliar languages and domains) requires a lot of effort.

Curious to see if they'll come up with an "Ugly Code" book next. Should be more fun ("Daily WTF", anyone?) and less pretentious. Plus, I dare say, they could even re-use some of the chapters from this book...

Two older books that you should buy instead:
Programming Pearls, by Jon Bentley.
Programmers at Work, by Susan Lammers.

Ask a number of developers what beautiful code looks like and you'll get different answers. Take those answers and compile them into a book and you'll get this text. I don't particularly find the code in this book beautiful at all, mostly because the code was written years ago when ideas like readability (read Refactoring) were not as important, and where better tools were not available. There are a few chapters where I agree with the author's ideas on beautiful code. However, I find that in these limited cases, the case study that the author presents and the ideas on beautiful code are disjoint. I find it too often that authors re-iterated how short code is beautiful (think Perl), which is not always the case and shouldn't be something that is emphasized too much over readability, maintainability, and extensibility.

My belief is that if you're a college student, this text might give you some ideas on what good code should do (though don't specifically use the code examples, use the ideas). If you work in the industry, your code should look better than the ones presented.

I'm willing to give this book at most three stars, mostly because I'd be ashamed to give it its first one star after the authors put so much work into this project, and I did enjoy some of the essays. I don't believe in hounding and harassing authors as was done to Herb Schildt (C author harassed for being a good mentor) and Kathy Sierra (Java authority harassed for being female).

The code in this book isn't Beautiful, and the book fosters an illusion about programming.

Rob Pike's 1998 example of a "regular expression" processor in Brian Kernighan's lead article isn't Beautiful. It doesn't process strings, properly understood; it processes arrays of bytes, and it does so with no apology from Kernighan.

It uses a value parameter as a work area without apology or explanation. Because C is a required language at Princeton for computer science majors, Kernighan feels no need to point this out, while pointing out the unusual, but correct, use of single-trip while.

It is correct in C to change a parameter passed by value ... but philosophically and from the standpoint of interlanguage readability, it's a C idiom used in a context not predeclared to be C.

We've come a long way, and a long way down, from the Algol vision of a publication language if programmers are expected to know a language, C, which has so many flaws, to learn computer science and Beauty itself.

Pike's code also repeats a test in two different functions. Brian's general apologia is that it's "efficient" but a roughly equivalent C Sharp version is only five times as slow...before you improve the latter by determining where possible the handle of the regex (the set of characters and/or strings that the regex MUST start with, which can be found using library facilities in C or C Sharp that execute for the most part fast assembler code).

The beauty in the code seems to be constituted for Kernighan in the fact that Pike wrote this flawed program in one hour with no back-talk.

The rest of the book adheres to this pattern; forced marches, vanity projects and the misuse of terminology (for example, structs are referred to as classes).

The illusion fostered by this book is that "programming" is the ideally single author writing in a flash of intuition some gnomically brief, uncommented, unHungarianized code which cleverly exploits idioms and implicitly defies a background of "dull" code written by clueless corporate drones...a sort of Star Wars urban legend in which the pure and good Beuatiful coders confront the Dark Side.

Writing about a manifestation of this urban legend in 1985, Theodore Roszak wrote (in From Satori to Silicon Valley) "how could they [the Apple kids] believe something so unlikely?"

The belief persists in technical circles that "we are Individuals who would write nothing but Beautiful code, and think naught but Beautiful thoughts, were it not first necessary to get Version 1.0 out the door and identify non-contributors and heretics, who in any way question our self-image as Luke Skywalker and Co." It persists because telling this story to yourself allows you to avoid confronting the objective subordination of the real programmer to essentially uncaring corporations with, in American law, the fiduciary responsibility to Screw U.

The fact is that "programming" is almost always collective, either in the sense of a group project, or in the creation of the first edition of an artifact which is then (even in the case of Linux and suchlike legendary products) taken from the author and transformed into a set, a series of editions which as a group solve a problem which is itself an ordered set.

Programmers rage for the fantasy of being a single author of unchanging deathless code and because they work in industry (sometimes as virtual slaves to Open Source projects, willing slavery being different in no fundamental respect from slavery, period) they never get this. The result?

Actual coding is fetishized and mystified in the real world to the point of a cargo cult, where at one and the same time, everybody wants to be the Author, but any moves, in the real world, towards this position, are considered to be disruptive, and the result is the grand fantasy of the enterprise system in which "coding", having become the nightmare inverse of the creative dream/fantasy, and the work of evilduuers, is supposed to disappear, but returns in the "mere" setting of parameters...using a Turing complete programming language which is normally pretty much of a mess.

Romanticising this process as having anything to do at all with artistic Beauty (the beauty of a Poussin, of the Ninth Symphony, of Death of a Salesman) breaks the connection with truth which is Beauty's mainstay. Nearly all code is poorly written in parallel or serial-over-time groups in which the members have been forced by management to compete with each other to the point, in some shops, of insanity, and most code unfairly structures the lives of countless employees and consumers in a way that systematically deprives them of meaningful control over their lives as employees, customers, investors, patients, or stiffs in the morgue.

An alternative way was shown early on in Algol, the product of a genuine partnership between universities, corporations and government. This effort was destroyed by IBM in favor of the infantile disorder (Fortran) and a few years on, most of the good ideas in C came from Algol, and were taken without acknowledgement.

I was somewhat saddened to see Kernighan involved with this vanity project because in his early work he sketched out a true alternative to the insanity, this being just slowing down and writing code, in whatever language (even Fortran) in a literate way. I met Brian when working at Princeton in 1987, and I felt like Garth and Wayne (Wayne's World) when they meet Alice Cooper: "we're not worthy". But it's clear to me from his essay and others that this beauty is too much in the minds of an American-centric programming culture to inspire.

Beauty is the Beast: in this book it means only doing it as fast as possible using in-jokes and idioms. There is no suffering here; suffering is prohibited as is asking questions such as "what is a string" when all you have are bytes; internationalisation is unmentionable in the Kernighan essay for this reason, as is the fact that both Java and C Sharp are international in their treatment of strings despite their *de minimis* "inefficiency" without any nonsense whatsoever. Dijkstra, the only real authority as far as I can tell on the type of elegance you need in programming, isn't even in the index.

Three stars, and that's because I'm a nice guy. I gave my own book only four stars because I didn't have enough time to do a perfect job and was perfectly willing to admit this. I despise Amazon numbers games, as well. So, Greg and Andy, consider yourself to have gotten a lucky break.

I'm willing to give this book at most three stars, mostly because I'd be ashamed to give it its first one star after the authors put so much work into this project, and I did enjoy some of the essays. I don't believe in hounding and harassing authors as was done to Herb Schildt (C author harassed for being a good mentor) and Kathy Sierra (Java authority harassed for being female).

This is because the code in this book isn't Beautiful, and the book fosters an illusion about programming.

Rob Pike's 1998 example of a "regular expression" processor in Brian Kernighan's lead article isn't Beautiful. It doesn't process strings, properly understood; it processes arrays of bytes, and it does so with no apology from Kernighan.

It uses a value parameter as a work area without apology or explanation. Because C is a required language at Princeton for computer science majors, Kernighan feels no need to point this out, while pointing out the unusual, but correct, use of single-trip while.

It is correct in C to change a parameter passed by value ... but philosophically and from the standpoint of interlanguage readability, it's a C idiom used in a context not predeclared to be C.

We've come a long way, and a long way down, from the Algol vision of a publication language if programmers are expected to know a language, C, which has so many flaws, to learn computer science and Beauty itself.

Pike's code also repeats a test in two different functions. Brian's general apologia is that it's "efficient" but a roughly equivalent C Sharp version is only five times as slow...before you improve the latter by determining where possible the handle of the regex (the set of characters and/or strings that the regex MUST start with, which can be found using library facilities in C or C Sharp that execute for the most part fast assembler code).

The beauty in the code seems to be constituted for Kernighan in the fact that Pike wrote this flawed program in one hour with no back-talk.

The rest of the book adheres to this pattern; forced marches, vanity projects and the misuse of terminology (for example, structs are referred to as classes).

The illusion fostered by this book is that "programming" is the ideally single author writing in a flash of intuition some gnomically brief, uncommented, unHungarianized code which cleverly exploits idioms and implicitly defies a background of "dull" code written by clueless corporate drones...a sort of Star Wars urban legend in which the pure and good Beuatiful coders confront the Dark Side.

Writing about a manifestation of this urban legend in 1985, Theodore Roszak wrote (in From Satori to Silicon Valley) "how could they [the Apple kids] believe something so unlikely?"

The belief persists in technical circles that "we are Individuals who would write nothing but Beautiful code, and think naught but Beautiful thoughts, were it not first necessary to get Version 1.0 out the door and identify non-contributors and heretics, who in any way question our self-image as Luke Skywalker and Co." It persists because telling this story to yourself allows you to avoid confronting the objective subordination of the real programmer to essentially uncaring corporations with, in American law, the fiduciary responsibility to Screw U.

The fact is that "programming" is almost always collective, either in the sense of a group project, or in the creation of the first edition of an artifact which is then (even in the case of Linux and suchlike legendary products) taken from the author and transformed into a set, a series of editions which as a group solve a problem which is itself an ordered set.

Programmers rage for the fantasy of being a single author of unchanging deathless code and because they work in industry (sometimes as virtual slaves to Open Source projects, willing slavery being different in no fundamental respect from slavery, period) they never get this. The result?

Actual coding is fetishized and mystified in the real world to the point of a cargo cult, where at one and the same time, everybody wants to be the Author, but any moves, in the real world, towards this position, are considered to be disruptive, and the result is the grand fantasy of the enterprise system in which "coding", having become the nightmare inverse of the creative dream/fantasy, and the work of evilduuers, is supposed to disappear, but returns in the "mere" setting of parameters...using a Turing complete programming language which is normally pretty much of a mess.

Romanticising this process as having anything to do at all with artistic Beauty (the beauty of a Poussin, of the Ninth Symphony, of Death of a Salesman) breaks the connection with truth which is Beauty's mainstay. Nearly all code is poorly written in parallel or serial-over-time groups in which the members have been forced by management to compete with each other to the point, in some shops, of insanity, and most code unfairly structures the lives of countless employees and consumers in a way that systematically deprives them of meaningful control over their lives as employees, customers, investors, patients, or stiffs in the morgue.

An alternative way was shown early on in Algol, the product of a genuine partnership between universities, corporations and government. This effort was destroyed by IBM in favor of the infantile disorder (Fortran) and a few years on, most of the good ideas in C came from Algol, and were taken without acknowledgement.

I was somewhat saddened to see Kernighan involved with this vanity project because in his early work he sketched out a true alternative to the insanity, this being just slowing down and writing code, in whatever language (even Fortran) in a literate way. I met Brian when working at Princeton in 1987, and I felt like Garth and Wayne (Wayne's World) when they meet Alice Cooper: "we're not worthy". But it's clear to me from his essay and others that this beauty is too much in the minds of an American-centric programming culture to inspire.

Beauty is the Beast: in this book it means only doing it as fast as possible using in-jokes and idioms. There is no suffering here; suffering is prohibited as is asking questions such as "what is a string" when all you have are bytes; internationalisation is unmentionable in the Kernighan essay for this reason, as is the fact that both Java and C Sharp are international in their treatment of strings despite their *de minimis* "inefficiency" without any nonsense whatsoever. Dijkstra, the only real authority as far as I can tell on the type of elegance you need in programming, isn't even in the index.

Three stars, and that's because I'm a nice guy. I gave my own book only four stars because I didn't have enough time to do a perfect job and was perfectly willing to admit this. I despise Amazon numbers games, as well. So, Greg and Andy, consider yourself to have gotten a lucky break.

I found the book's concept intriguing. The ability to learn from 33 highly respected members of the programming community is invaluable. I've enjoyed my daily dose of Beautify Code... but one thing caught me by surprise:

Not all samples are beautiful... well in my eyes not all samples/chapters are beautiful.

I'll skip listing the ones I found beautiful, interesting, insightful and educational because I'm sure you will find others that "do it" for you.

All in all I think it's worth giving this book a shot.

PS - I recommend reading Dmitry Dvoinikov's review and the comments associated with it... you'll get a better sense of the book.

Beautiful Code is a unique book. It is not bound by a particular system, or programming language, or methodology. Instead, it tries to straddle the entire field of programming with the ostensible aim of exploring beauty in computer code.

What we get is a smorgasborg of essays that posits competing definitions of technical beauty in very different pieces of code. As such, the book becomes a dialectical argument between different conceptions of technical beauty. It may even serve as a rorsarch test to your sensibilities as a programmer. In the process, you may discover algorithms that are startling in their beauty and ingenuity.

Given the broad sweep of the book, the quality of the essays is somewhat of a crap-shoot. What I found more interesting was working out why I found some of the essays elegantly persuasive, whilst others, I found to be a turgid sludge to wade through. In the end, it becomes almost impossible to separate the quality of the writing from the definition of beauty defined in the essay.

Technical beauty is a very strange beast. It is different from the kind of beauty that resides in the curve of Scarlet Johanssen's lips. In physics and maths, there is a tradition of invoking beauty in certain equations. Einstein's equations for general relativity surely merits that description, as does Euler's formula. For me, technical beauty refers to that rare fusion of concision, efficiency and surprisingly deep connections between seemingly unrelated phenomena.

I found that the essays that I liked were the ones that focused on very specific pieces of code. These essays would carefully explain the problem that the programmer was trying to solve, articulate the constraints, and show the straightforward (and usually less elegant) alternatives. They would then go through all the blind-alleys before unveiling the final solution, which would be as surprising as it was elegant. After all, the father of the essay, Montaigne, coined the term "essai", which means attempt in french.

The essays that didn't work would try to describe how the software worked, and skip over the details. But these are technical essays, after all, and without a careful consideration of technique, all that is left is flabby writing. Surprisingly, there were quite a number of essays devoted to scientific programming, with contributions from the writers of BioPerl, Numpy, LAPACK, and the NASA Mars module. Most of these I found rather unsatisfactory, the kind of flabby essays that skipped over interesting technical details. They offered no fundamental insight to how the code was implemented other than the fact that these packages have stood the test of time. The exception was Trevor Oliphant's essay on Numpy, which showed how a powerful iterator implementation can dramatically simplify the organization of a linear algebra library.

How detailed were the techniques? In Henry S. Warren Jr's essay, he describes how one might count bits in C. It's a marvelous essay because through the description of such an elementary operation, Warren illuminates just how close to the metal one can go in a low-level language like C. At the other end of the scale, Jeffre Dean and Sanjay Ghemawat, engineers at Google, describe the MapReduce algorithm, part of the secret sauce that squeezes out information from Google's gigantic parallel arrays of hard-disks and processors.

There is a the famous dictum attributed to Fred Brooks that if you know the data structure of a program, you will know how the program works. The design of the key data structure reveals the inner workings of a piece of software better than any flow-chart ever could. Greg Kroah-Hartman describes an object-oriented design right in the heart of the Linux kernel driver, written in nothing less than C. Here is found one of the scariest looking C macros that I have ever seen. In one of the most twisted pieces of logic, Kroah-Hartman argues that by not simplifying the macro (including such hand-holding as run-type checking), it keeps away people who don't know what they are doing from touching the code. That, for Kroah-Hartman, is beautiful code. Andrew Kuchling's essay explained how dictionaries are implemented in Python. In the process, I finally understood how dictionaries underpin virtually everything in Python, from objects to locally scoped variables. That's why dictionaries in Python need to be as fast as they are.

Two essays introduced me to some radically different programming techniques. Charles Petzold's essay on writing fast image filters shows how you can do custom compilation on very small pieces of code for incredible speed gains. The essay by Andreas Zeller described perhaps the strangest algorithm in the book. He was working a GNU debugger GUI front-end that got broken after the back-end debugger was upgraded to a newer version. Rather that go through each of the 10000 different patches individually by hand, Zeller came up with a perversely beautiful technique to systematically identify which patch broke the GUI front-end.

Some of the essays flew straight over my head, but such is the nature of such an eclectic collection as this. Beauty, some might argue, is the ability to see hidden patterns in the world, so it seems appropriate to mention Brian Kernighan's essay on a terse 35 line C-program that implements a regular expression matcher. It makes extensive use of recursion, of course.

If you take the title of this book as its premise, then there are 2 other books that are better both in commentary, thought and detail. Go deeper.

The Practice of Programming (Addison-Wesley Professional Computing Series)
Programming Pearls (2nd Edition) (ACM Press)

Thirty-three chapters, by different authors, each covering what they consider to be beautiful code. The list of chapters on Amazon will give you an idea of what's inside. Everyone will have their quibbles with some of it -- things you don't care about, people who code better than they write, or think that using their favorite tools (Haskell, Scheme, OO Design) automatically makes it beautiful -- but overall there's a lot of good stuff here. I learned something from every chapter, even those I didn't really care about completely. A good book.

The idea of this book is that thirty software developers and/or researchers (respectable ones, no doubt there), had to find the most beautiful piece of code and present its study. Each of them then writes a chapter and there you have it - a volume of "beautiful code" ! Simple as that.

If there was somebody to fully support the idea of such book, it would be me - I believe that the software industry already spent too much time and effort neglecting the art-and-craft in programming, pretending that it all can be reduced to hard math. Didn't work so far, did it ? Then I very welcome books like this one. But not exactly the one.

Let me put it this way - I couldn't say anything good about this book except that I adore the concept and found may be ten of thirty three chapters interesting (not necessarily beautiful). Beauty is in the eye of the beholder they say, but this lame excuse is the last good thing I could say for this book.

It was supposed to be pedagogical. Did not happen. Rather than making it timeless reference for the readers, the book made a tribune for the authors to talk about, uhm, just about anything. We know how programmers love to talk about what they do, and it's ok. But we also know that they often mumble instead of talking and it's very difficult for us to understand one another, no matter friendly or hostile. This is not to mention that there are no commonality in topics or style or language (programming or English) or anything. The editor had simply glued it together.

Not so bad you say, a good assortment is fine you say ? Let me tell you more, and it's all downhill.

It's as though you expected an album of paintings but instead got a book of random excerpts from chemical specifications for producing paints.

Exemplary conventional antimicrobial, antimildew, or antialgae agent includes 3-iodo-2-propynyl butylcarbamate, diiodomethyl-p-tolylsulfone, 1,2-benzoisothiazolin-3-one, 2-methylthio-4-tert-butylamino-6-cyclopropylamino-s-triazine, 2-(4-thiocyanomethylthio) benzothiazole and the mixtures thereof.

See how beautiful it is that can be painted with that ?

If you ask me, a book like this ought to have structure. Remember the classic one by Gamma et al - they also presented abstract things from different areas or levels, but they kept the information stylistically uniform and structured against a clear taxonomy. Not the case here.

Each chapter is about different matter, presented in a different way. One author presents a performance hack in which he compiles code on the fly. The chapter will then contain several pages of dynamic assembly. The other will show an interesting approach to syntax parsing. This one will have 50 short snippets of something JavaScript-like. Yet another will tell you how to automate debugging by automatically mutating the application. This one won't have code at all. Yet another will show a slick algorithm for counting bits in a word. This one will have a lot of bitwise arithmetic.

And I just loved the one that has NASA in it's title. There - "A Highly Reliable Enterprise System For NASA's Mars Rover Mission". Wow ! How promising ! Want to know what it says ? It says - "In NASA they love their software reliable, even a web-based file server, and so we present you a web-based file server built with JavaBeans in three-tier architecture". Ahem, Mars Rover anyone ?

Don't get me wrong, some of the chapters are reasonably interesting. Interesting ! Not beautiful !

With a little exception, the authors don't even mention the word "beautiful" in their texts. They allure with "There, we have this system, it works like this..." . What exactly the author finds beatiful about it and why - remains secret.

The most impressive standout was the chapter written by Yukihiro Matsumoto, the creator of Ruby. Three pages in which he simply speaks about what he believes a beautiful code is. He explains to you his understanding of a beautiful code. This is what the book is all about !

Instead, many chapters just demonstrate a few pages (!) of code and conclude - it is beautiful, see !

Many times I wasn't unable to grasp the problem - what was it that required that so called beauty to emerge ? I couldn't see the whole picture, but the authors sort of presume I do and so my possible appreciation of beauty requires deep understanding. What if I show you a magnified fragment of Mona Lisa's background, some 3x3 blackish pixels ? No doubt, Leonardo had to paint them too. But what was that beauty again ?

Only a few authors were wise enough to use a pseudocode. Something that anyone can read, no matter from which camp. Otherwise it's just weird when the authors present their beatiful code in Ruby or Perl or LISP. Look, I didn't touch Ruby yet, I hate Perl and I can't imagine using LISP in practice. Nevertheless the authors repeatedly say something like "It's easy, I'll show you, this bracket does this and that character does something else. Now you see how beautiful it is ?". They literally show you a piece of poetry in foreign language and ask you to appreciate it.

A classical example of awful poetry in Russian is (transliterated)

Ya poet, zovus' Neznajka,
ot menya vam balalajka.

Can you tell whether it's good or bad and why ? What if I told you it's beatiful ? Would you believe ? Does it appeal to your sense of beauty ? Same thing about this entire book.

Awful implementation of an idea that I fully adore. In fact, implementations like this undermine the idea, that's why I rate this book so low and put it away with disgust.

I am a software engineer of about 5 years of professional experience. The book is attractive to me because it describes proven best-practices for existing software. There are a large variety of software descriptions in this book. If you are looking for a programming-language-specific book, this book might not be for you, because it contains a wide variety of projects from different programming languages (from Fortran to Python and perl).

For the intermediate or beginning programmer, I'd say this is an excellent read as long as you are able to comprehend the material. Some of the text demands more than a cursory knowledge of programming. I will probably need to reread a few chapters later in my career in order to understand them in the manner they were intended.

The book reads like a book about software pattern implementations, but without the emphasis on the patterns. It is left to the reader to draw generalizations from the examples that they can apply to their own code.

Personally, I'd like to see more books like this. It provides a good frame of reference for the construction of good software.

This book is a great compilation of software design problems and solutions. Each chapter is an essay from one author which covers a particular problem in computer science and/or software engineering.

The chapters are complete discussions within themselves and they offer different insights into how to solve problems. The solutions are geared to issues found in both the natural world and the business world.

Of particular interest (for me) were the chapters on seraching and debugging.

One aspect of the book that will be either a plus or a minus depending on the reader is that because each chapter is by a different author, there are many distinct writting styles used. Since I was looking towards the book to gain insight into how others solve these problems, I found this useful. Since some of the context of the thought process came through in the writting, it was more like talking to the authors rather than just reading a textbook.

The chapter vary considerably in both topic and the thought process that went into the solution so inevitably there will be chapters that interest any programmer.

The books chapters can be read in any order and the editor indexes the chapters well. Information is easy to find.

Programming Pearls is of similar composition but with shorter chapters and explanations. This book goes a step further in both scope and length of explanation.

This 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:

1. 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.
2. 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:

1. Chapter 1, A Regular Expression Matcher, by Brian Kernighan
2. Chapter 2, Subversion's Delta Editor: Interface as Ontology, by Karl Fogel
3. Chapter 3, The Most Beautiful Code I Never Wrote, by Jon Bentley
4. Chapter 8, On-the-Fly Code Generation for Image Processing, by Charles Petzold
5. Chapter 10, The Quest for an Accelerated Population Count, by Henry S. Warren, Jr.
6. Chapter 16, The Linux Kernel Driver Model: The Benefits of Working Together, by Greg Kroah-Hartman
7. Chapter 18, Python's Dictionary Implementation: Being All Things to All People, by Andrew Kuchling
8. Chapter 23, Distributed Programming with MapReduce, by Jeff Dean and Sanjay Ghemawat
9. Chapter 28, Beautiful Debugging, by Andreas Zeller
10. Chapter 33, Writing Programs for "The Book," by Brian Hayes

I bought this book because it was mentioned in a Google Tech Talk about a beautiful Quicksort algorithm.

I was just looking for an interesting book that I could skim through and see some really neat, SHORT examples... but a lot of it requires that you read an entire chapter before you can understand the two pages of C that implements some part of a driver. It personally wasn't what I was looking for.

So it sits on my shelf, barely read and in near mint condition if anyone wants to take it off my hands. It is probably a better book than I think, but I don't really have the time or interest to study other people's supposedly good code.

A frequent topic of discussion among those in any technical field is for a short list of essential books that anyone worth their salt has read. With regards to software engineering, two classics quickly come to mind: Code Complete, and Design Patterns, as well as a recent publication joining the ranks of these epics, Beautiful Code by O'Reilly Media.

What makes Beautiful Code stand apart from the rest, is that it's format is so unconventional when compared to most other programming texts. The book is comprised of 33 Chapters, each written by a different author about a particular bit of code they had written and thought to be particularly eloquent. The best way to explain why this book is so wonderful is to make an analogy about the differences between learning something via a lecture as opposed to a private lesson. Most instructional books will take the lecture approach, where the author shows you one correct way to solve a problem, or complete a certain task and the reader must then digest that as best as possible. Beautiful Code is more like a private lesson in which the author of each chapter is giving the reader personalized attention by explaining their thought processes, how they arrived at each step, and occasionally showing some dead ends that didn't work out. Now consider that these private lessons are being given by such legendary names as Brian Kernighan, Charles Petzold, and Yukihiro Matsumoto - and it becomes obvious why this is a must-have addition to any serious software engineer's bookshelf. Some particularly memorable sections include Karl Fogel's discussion on the origins and implementation of the Subversion Delta Editor and the look inside Google's MapReduce technology by Jeffrey Dean and Sanjay Ghemawat.

As stated earlier, one of the best strengths of this book is that it is language neutral. In each chapter, as the author is speaking from experience on a particular project, rather than writing a chapter for a hypothetical "Better Programming in Language XYZ", you will see code snippets in C#, MSIL, Python, Ruby, and several other languages (There's even one chapter with Emacs Lisp!). This is important because the insight gained from this book will not be diluted from one language falling out of favor or into obsolescence, and allows for the possibility of this title being just as valuable ten years from now.

Many books will teach you how to solve a problem, but rare are those to teach you how to think. Beautiful Code is one of those select few, and will keep you coming back from project to project to consult its veteran sages of computer science. A worthy edition to any serious programmer's library, and hopefully a second volume is not far off.

I have never been more excited about ordering a computer book than when I saw "Beautiful Code" advertised on Amazon's home page. Finally the book I've been wanting to write myself is here, with contributions from over 30 top professionals. Sadly, the book contains little code of beauty, in my opinion, and some of it is downright ugly. I would have given the book only one star, but I enjoyed the chapter on how Stephen Hawking interacts with a computer using only a single button.

Rather than criticize specific articles, I will teach you my own secret to writing beautiful code which is not in the book: Impedance Matching. I studied electrical engineering in college, and one of the concepts they teach is impedance. Exactly what it is is not important, but when you connect two electrical devices together, you want the impedance of both devices to be the same. For example, if you have an audio amplifier with an impedance of 8 ohms, you want to connect it to a speaker with an impedance of 8 ohms for the best sound quality. If the impedance of the speaker is more or less, the amplifier will have to work harder, causing distortion and maybe even damaging the amplifier. To fix this problem, you can insert an impedance matching circuit between the amplifier and the speaker so that the perceived impedance of the speaker is 8 ohms, and the amplifier performs at its best.

Software is similar in that it also has impedance. I define software's impedance as the complexity of the programming interface to the software. Programmers also have an impedance, which is their ability to grasp how the software works. If the programmer's concept of how the software works doesn't match reality, bugs are the inevitable result. The great thing about the human brain is that over time, as they become more familiar with the software, the programmer's impedance aligns with that of the software and they produce better programs with fewer bugs.

The problem with this impedance mismatch is that any new programmer that comes along will suffer from it, causing them frustration and delaying their ability to contribute meaningfully to a project. Often this is called the learning curve, but that term makes the problem sound like an inevitable reality of programming. Just like with the amplifier, we can place an impedance matching layer between the programmer and the software with which they have to work. This layer needs to have a programming interface that matches as closely as possible what a moderately skilled programmer would understand in (ideally) just a few minutes of explanation.

As an example of what I'm talking about, think about the ubiquitous Berkeley sockets interface for network programming. If you have already become accustomed to it, you know what a socket is, how to create one, bind it to a port, etc. But think about when you first decided to learn how to write networking code. You may have had the idea that you could establish a connection from your computer to another one, and that a remote computer could connect to you. Once established, you could send and receive data over the connection, and close it when you were finished. That is probably as far as it went.

With just a few minutes of explanation, an experienced network programmer could teach you about domain names, addresses and ports, timeouts, the difference between TCP and UDP, and how a listening socket is used to accept new incoming connections. That should be all the programmer needs to know to get started, so the impedance matching layer should present these concepts.

Internally, there are many more things the impedance matcher needs to worry about: looking up domain names and attempting to connect to one of possibly several IP addresses, blocking versus non-blocking operations, setting socket options, buffering of data sent and received, avoiding deadlock, and much more.

I came up with a design in C++ for such a layer, and although you may not consider the code -inside- the layer to be beautiful, the code written using it can be. This is because the code is easily understood without the need for comments. Here is a simple example (without error checking):


Network network;

TcpSocket* amazon = network.TcpConnect ("www.amazon.com:80");

amazon->SendLine ("GET / HTTP/1.0\r\n");
amazon->SendLine ("Host: www.amazon.com\r\n");
amazon->SendLine ("Connection: close\r\n");
amazon->SendLine ("\r\n");

String line;

while (amazon->ReadLine (line))
{
// process line
}

amazon->Close();

delete amazon;


The code implementing the Socket classes is about 4,000 lines of C++ and the Network class is right around 400 lines. This is a very small addition to a project, yet the resulting increase in beauty is substantial.

Mike

I found this to be a fun, thought provoking book. It is a large collection of essays by various leading software developers each providing examples of their ideas of what makes code beautiful. Examples cover a wide variety of languages from c to ruby, and a variety of perspectives on what makes code 'beautiful.' The essays cover a good mix of old and new, ranging from regular expression matchers to the FIT testing framework. With such a wide variety of perspectives I doubt anyone can say they agree with everything in this book, but each author's view is worthy of thought and consideration.

Everybody in my office is reading this book, so I borrowed a copy. It's mediocre. Most of the articles conflate performance and beauty. So far I have read about eight of the articles and only two have been beautiful at all. The first is "Correct, Beautiful, Fast (In That Order): Lessons From Designing XML Verifiers". The code in that article is readable, well designed, and fast. The second decent article is "Subversion's Delta Editor: Interface as Ontology". Again its code is readable and performant. This article still isn't very interesting. It describes an application of the Visitor pattern to implement a variety of operations on tree structures that need to be efficiently transmitted over the network. Anyone who has read "Design Patterns" by Gamma et al will be familiar with this technique. Some of the other code presented in the book is very ugly. "The Quest for an Accelerated Population Count" takes a simple for loop and turns it into a handful of opaque bit-by-bit operators. Yes, it is very fast. Yes, I can understand the code if I examine it closely. No, it is not beautiful at all. I also suspect that Jon Bentley's article is essentially a re-print of a "Programming Pearls" column. In summary this book doesn't contain much beautiful code, and if you want to write better code go read Gamma, Fowler, or Goetz.

Any experienced programmer can tell you that there is a huge difference between code, good code, and beautiful code. The ability to find the simple, elegant, clever, and most of the time, non-obvious solutions to daunting problems is what separates expert programmers from their peers. This book is really a collection of essays by famous names in the programming world, all describing how they solved a particular problem with a little bit of 'beautiful code'. With over thirty contributers, there is quite a bit of material here - and with names like Brian Kernighan and Karl Fogel, you know the material is worth reading.

Firstly, I want to mention how impressed I am with the design of the book. This is the first O'Reilly publication, and really, first programming book, that I would describe as having a beautiful design. A lot of thought went into the book design, and it shows. Typeface, whitespace, layout, diagrams, organization - it all comes together to form a text as beautiful as the topic that it covers. This text has raised the bar regarding style, and I hope O'Reilly takes some of the successes of this style and includes them in future works.

Because there are over thirty authors in the text, it is hard to talk about the writing itself. However, I will say that there wasn't a single essay that I found poorly written. Unlike most other programming texts, the authors in this book know both their material and how to communicate it effectively. The editors, Oram and Wilson, did a fantastic job putting the essays together and making sure they flow.

Each essay is presented as a personal work of that particular author. Each one has a unique tone, writing style, and approach. The result is that each essay feels more like a one-on-one discussion with the programmer about how a certain problem was solved instead of a textbook chapter covering an particular programming lesson. Within each chapter, you will get little bits of insight into the author through the writing, and I found this almost as interesting as the topic itself. The pieces of humor and side notes that the authors spread through their writing add a fun flavor to the book, and you really get a sense that the authors enjoy what they are doing and are passionate about sharing it with others.

I was also very happy with the liberal use of diagrams and code examples. Not including diagrams and images in textbooks is a pet-peeve of mine, and I was elated to find that nearly every essay in the text uses them extensively.

The final topic that I want to talk about is the code itself. Unsurprisingly, the text is fantastic in this regard. The authors do an excellent job of only showing you the code that you need to see to follow what they are saying, and they try to keep it clean and simple. This isn't to say that there isn't a lot of code in the book - in fact, it is quite the opposite. There is a huge amount of code in the text, but it is presented and discussed in small bits to keep it from becoming overwhelming. Larger chunks of code are well commented, and the code is always stylistically sound and easy to read.

For the most part, the code steers clear of discussions that require knowledge of advanced programming topics. Obviously, someone who is just learning to program will have a lot of trouble following the code, but anyone with a firm grip on fundamental programming strategies and topics shouldn't feel like the code is over his/her head. The book is about thinking like the experts, not learning raw programming topics from them.

The only difficult aspect of the code is the sheer number of languages. The authors all come from different backgrounds, working in different environments, with different platforms - so of course most of them are using different tools to get the job done. If the programming language that the author is using has a syntax and notation that might be confusing to people unfamiliar with the language, the author generally tries to provide a quick run-down on how to read it. However, I found that some of the examples, when I didn't know the language involved, were very hard to
follow, and I had to follow the discussion more than the code itself. This was rare, however, and since the discussion of what thought-process enabled the author to write the code is really the meat of the essays, wasn't too big of a deal when it did happen.

Some of the authors used a bold typeface for important lines of code, and I found this to be extraordinarily helpful in some situations. In future editions, I would recommend that every author use this strategy to make the larger code blocks easier to sift through for important information.

This text is a fantastic piece, and is really a work of art. With so many high-quality authors coming from so many different fields, backgrounds, and cultures, it isn't surprising that this book is a joy to read. There is great insight in the writing, and great lessons to be gleaned from each chapter. I heartily recommend this book to anyone who wants to learn how to bea more clever programmer, or to anyone who simply appreciates intelligent and beautiful solutions to extraordinarily challenging problems.

Any experienced programmer can tell you that there is a huge difference between code, good code, and beautiful code. The ability to find the simple, elegant, clever, and most of the time, non-obvious solutions to daunting problems is what separates expert programmers from their peers. This book is really a collection of essays by famous names in the programming world, all describing how they solved a particular problem with a little bit of 'beautiful code'. With over thirty contributers, there is quite a bit of material here - and with names like Brian Kernighan and Karl Fogel, you know the material is worth reading.

Firstly, I want to mention how impressed I am with the design of the book. This is the first O'Reilly publication, and really, first programming book, that I would describe as having a beautiful design. A lot of thought went into the book design, and it shows. Typeface, whitespace, layout, diagrams, organization - it all comes together to form a text as beautiful as the topic that it covers. This text has raised the bar regarding style, and I hope O'Reilly takes some of the successes of this style and includes them in future works.

Because there are over thirty authors in the text, it is hard to talk about the writing itself. However, I will say that there wasn't a single essay that I found poorly written. Unlike most other programming texts, the authors in this book know both their material and how to communicate it effectively. The editors, Oram and Wilson, did a fantastic job putting the essays together and making sure they flow.

Each essay is presented as a personal work of that particular author. Each one has a unique tone, writing style, and approach. The result is that each essay feels more like a one-on-one discussion with the programmer about how a certain problem was solved instead of a textbook chapter covering an particular programming lesson. Within each chapter, you will get little bits of insight into the author through the writing, and I found this almost as interesting as the topic itself. The pieces of humor and side notes that the authors spread through their writing add a fun flavor to the book, and you really get a sense that the authors enjoy what they are doing and are passionate about sharing it with others.

I was also very happy with the liberal use of diagrams and code examples. Not including diagrams and images in textbooks is a pet-peeve of mine, and I was elated to find that nearly every essay in the text uses them extensively.

The final topic that I want to talk about is the code itself. Unsurprisingly, the text is fantastic in this regard. The authors do an excellent job of only showing you the code that you need to see to follow what they are saying, and they try to keep it clean and simple. This isn't to say that there isn't a lot of code in the book - in fact, it is quite the opposite. There is a huge amount of code in the text, but it is presented and discussed in small bits to keep it from becoming overwhelming. Larger chunks of code are well commented, and the code is always stylistically sound and easy to read.

For the most part, the code steers clear of discussions that require knowledge of advanced programming topics. Obviously, someone who is just learning to program will have a lot of trouble following the code, but anyone with a firm grip on fundamental programming strategies and topics shouldn't feel like the code is over his/her head. The book is about thinking like the experts, not learning raw programming topics from them.

The only difficult aspect of the code is the sheer number of languages. The authors all come from different backgrounds, working in different environments, with different platforms - so of course most of them are using different tools to get the job done. If the programming language that the author is using has a syntax and notation that might be confusing to people unfamiliar with the language, the author generally tries to provide a quick run-down on how to read it. However, I found that some of the examples, when I didn't know the language involved, were very hard to
follow, and I had to follow the discussion more than the code itself. This was rare, however, and since the discussion of what thought-process enabled the author to write the code is really the meat of the essays, wasn't too big of a deal when it did happen.

Some of the authors used a bold typeface for important lines of code, and I found this to be extraordinarily helpful in some situations. In future editions, I would recommend that every author use this strategy to make the larger code blocks easier to sift through for important information.

This text is a fantastic piece, and is really a work of art. With so many high-quality authors coming from so many different fields, backgrounds, and cultures, it isn't surprising that this book is a joy to read. There is great insight in the writing, and great lessons to be gleaned from each chapter. I heartily recommend this book to anyone who wants to learn how to bea more clever programmer, or to anyone who simply appreciates intelligent and beautiful solutions to extraordinarily challenging problems.

Some code is over my head, or from languages I don't use. Even so, every article I've read had at least one gem that helped me "think different" about how I code. Don't look to this book for specific examples, or as a reference, but for a brain massage that will let you break away from old standby solutions. Lots of my computer books end up on the shelf, forgotten, after just a few days, but this one's been out on my desk for weeks. I dip in when I need change of direction.

Andy Oram and Greg Wilson edit BEAUTIFUL CODE: LEADING PROGRAMMERS EXPLAIN HOW THEY THINK, a unique collection of master classes in software design which will prove perfect not just for computer libraries, but for classroom assignment and independent study. Nearly forty master coders reconstruct project creation and coding challenges, considering basic best practices and times when rules must be bent or broken to achieve results. Any programmer involved in software engineering or design will welcome this survey of how the best coders think.

Some of the chapters in this book are very interesting (population count, analysis of quicksort). Others less so (puffing opensource projects or their authors, or both in the case of the article on crypto). There are some fairly hardline options (e.g., in the article on LINPACK, from my perspective of a C and C++ developer). Some is quite esoteric (e.g., Haskell concurrency - it woiuld be nice to be able to use it, but in my world, it's a struggle to get to use anything but C).

This book was designed as a way for modern programmers to show how they think: why should a system be designed one way and not another? What makes code beautiful? This book is organized into 33 different chapters, where leading programmers pick a software topic that is beautiful to them, then proceed to describe what makes it so. This book is a fascinating insight into the minds of some leading programmers.

The authors cover many different topics: from Subversion's Delta Editor to Python's Dictionary implementation; from the enterprise system behind the Mars rover to some design decisions behind Ruby. Again, these are all fascinating to look at, but the breadth of material is so varied that it might be difficult for a lot of individuals to really get into. Lead programmers or software architects will likely eat this stuff up, but it'll probably be too much for the average working software developer.

If you are able to get past the fact that each chapter comes from an entirely new author with an entirely new project, this is an interesting book and a great peek into some truly brilliant minds.

This book is a great read as it covers many domains and languages. The good range of problems means that you will probably be familiar with at least one of the examples from previous experience (even if you are inexperienced).

It is easy to pick up the book and read any of the chapters independant of the others so it allows you to skip back and forth as you find topics that interest you.

The book teaches a lot of lessons that I wish all programmers had read before they wrote the code that I then have to maintain.

This book is a good general IT read for anyone interested in programming or problem solving in general.

For those of us slogging out code on a day-to-day basis in the trenches, it may be a bit of a stretch to think of programming code as "beautiful". But there really is a special beauty to code that's been well-crafted and designed to stand the test of time and use. Beautiful Code: Leading Programmers Explain How They Think by Andy Oram and Greg Wilson is a look into the minds of a number of developers who have very definite ideas of what makes a "beautiful" program or routine. While some chapters are a bit more esoteric than what I could follow, the general flow and idea work well...

Contents:
A Regular Expression Matcher; Subversion's Delta Editor - Interface as Ontology; The Most Beautiful Code I Never Wrote; Finding Things; Correct, Beautiful, Fast (In That Order) - Lessons From Designing XML Verifiers; Framework For Integrated Test - Beauty Through Fragility; Beautiful Tests; On-The-Fly Code Generation For Image Processing; Top Down Operator Precedence; The Quest For An Accelerated Population Count; Secure Communication - The Technology of Freedom; Growing Beautiful Code in Bioperl; The Design of the Gene Sorter; How Elegant Code Evolves With Hardware - The Case of Gaussian Elimination; The Long-Term Benefits of Beautiful Design; The Linux Kernel Driver Model - The Benefits of Working Together; Another Level of Indirection; Python's Dictionary Implementation - Being All Things To All People; Multidimensional Iterators in Numpy; A Highly Reliable Enterprise System for NASA's Mars Rover Mission; ERP5 - Designing for Maximum Adaptability; A Spoonful of Sewage; Distributed Programming With Mapreduce; Beautiful Concurrency; Syntactic Abstraction - The Syntax-Case Expander; Labor-Saving Architecture - An Object-Oriented Framework for Networked Software; Integrating Business Partners The RESTful Way; Beautiful Debugging; Treating Code As An Essay; When A Button Is All That Connects You To The World; Emacspeak - The Complete Audio Desktop; Code In Motion; Writing Programs For "The Book"; Afterword; Contributors; Index

I think by reading the table of contents, you quickly see this isn't a light "For Dummies" read. The contributors on each chapter are some of the most intelligent and influential software designers in the industry today. And the topics aren't light-weight, either. In more than one case, there is a great deal of mathematical and logical theory to prove certain designs. Unless you have a serious background in computer science, it's safe to say that you won't get nearly as much out of those chapters as the authors are trying to convey. I know I definitely fell into that category a number of times...

Having said that, I *did* get value out of many other chapters. For instance, "A Spoonful of Sewage" shows what happens when a beautiful design ("wine") is compromised with a minor flaw or hack ("sewage"). Regardless of how fine the wine is, the net result is a spoiled, ruined vat of sewage. I was reminded that it's important to not make those design compromises for the sake of expediency. Another good example is the "When A Button..." chapter. How do you design a system when the sole means of input for someone is a single button? The developers here faced that issue when they were asked to design some software for use by Stephen Hawkings, a brilliant scientist who is severely physically disabled. The sense of what's "beautiful" is tested by constraints that most of us have never considered or imagined...

I don't imagine that most people would read this book cover-to-cover with the idea that every chapter would be applicable and personal. Writing styles vary, and the technical level of some chapters is *very* deep. But nearly any software developer should be able to read the book and extract a number of ideas that will improve their mindset and approach to what they do on a daily basis... writing beautiful code.

If you are thinking about buying this book to read many beautiful code samples that will help you lift your game, it doesn't fulfill that purpose very well. Many of the examples are from relatively eclectic and obscure domains in different programming languages. Some of it was stuff that I'm already doing.

Might be fun to skim what interests you in a coffee shop, but unless you're prepared to invest a lot of time in studying this tome for comparatively little value, just pass on it.

This book is fun. It brings a number of interesting challenges to full view and sheds light on them in exciting presentations by its numerous contributors. It crosses quite a few programming languages and specialization areas within the ever-broadening scope of computer science. I found it to be refreshing and delightful. I particularly like a number of the "historical artifacts" found throughout the book. It lends greater balance to the evolving nature of this particular corner of the world. I'd like to see more citations in a book that offers such things as "73 percent of the world's largest supercomputers" (in a context of what is running Linux) as fact. Perhaps it is, but how can anyone refute or even prove it? At a minimum, a citation is helpful in providing greater credability, though it may have detracted somewhat from the readability of this otherwise fine book. I'd probably also like to see a bit more editing by editors Oram and Wilson. For example, page 484 has: "Needless to say, the software needed to be efficient..." If it is needless to say, why is it said? How is that efficient? The sentence, if rewritten, could easily lose the needless to say and not encounter any dehumanization. I think that an argument can be made that the editors perhaps chose to focus on content more than style and, since the text flows well enough, why change it? Some may consider writing about efficiency in an inefficient style to be a bit of a contradiction at some level. Others may never consider it to be anything more than the comfortable "speaking voice" of a friend or colleague. These are most certainly not complaints nor do they detract from the book in any substantive manner. I found useful and interesting content in every section. The individual writing styles of each of the contributors was a refreshing element not found in single-author books. The back cover says: "This is not simply another design patterns book, or another software engineering treatise on the right and wrong ways of doing things. Instead, it gives you the chance to look over the shoulder of some superb software designers and see the world through their eyes." ...this is the best reason to purchase the book, for sure! One of the things that I liked most about the various contributors was that they were, well, varied! If you get 15 experts on C++, everything in the world sounds like it has a corresponding C++ answer. These experts represent a bountiful cross-section of the relevancy of computer science in our world today. My favorite section was Andreas Zeller's musings on debugging. The sentence: "...I was pretty fed up with running debuggers, debugging our own debugger, and in particular debugging because of third-party changes." It's classic! The organization of the words express in a nutshe