Customer Reviews

Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly))

5 star:		(12)
4 star:		(12)
3 star:		(8)
2 star:		(13)
1 star:		(2)

 

 

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.

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 am always looking to for new ways to look at programming problems. I love studying new programming languages in order to bend my mind in new, uncomfortable ways. Both of these are reasons I enjoyed Beautiful Code.

Beautiful Code is a collection of essays from some well known software engineers. That said, I didn't immediately recognize many of their names (this is probably an indication of my lack of exposure in their fields of expertise). If you are like me, there is an alphabetical list of short biographical entries in the back of the book you can use to acquaint yourself with who wrote each chapter.

There are chapters from people in the Perl, Python, Ruby, Google, Scheme, and Haskell communities (among others).

I especially enjoyed reading about Google's MapReduce algorithm, Haskell's Software Transactional Memory, and Scheme's syntax-case macro system. These are subjects I have previously tried to tackle, but the explanations written in this book have helped me approach understanding far better than the academic papers on these subjects I have tried to read.

You'll have to put forth effort to follow the explanations in the chapters as the authors walk you through how they tackle a given problem. This leads eventually to the solution, but may involve many twists and turns along the way. These twists and turns show how the authors think and grants us as the readers insight into how they approach the problems at hand. It's the journey to the desination that sometimes matters more than the destination.

For example, I've long wondered abut the difference between hygenic and non-hygenic macros. Various descriptions on the web have given me some clue, but chapter 25 shows examples and explains the problem very clearly. It then goes about discussing various solutions that have been devised over the years before going into the details of the current solution that is in use today. I've seen the end result before, but knowing what motivated the solution gives me a much greater appreciation for and understanding of it.

The effort required for some chapters may be over your head as they are for me, but those are the chapters where I find the rewards to be the greatest as they force me to look at things in new ways. Once I do achieve understanding I'm able to apply the new found ways of thinking about problems to the situations I face at work and elsewhere which has led to unique and compelling solutions that I would not have thought of before.

I've long been on the search for beauty in the code I write. I have found that as I read and take the time to understand what others see as beautiful, even when I do not see beauty in it at first, I gain greater insights into my craft. I am glad that O'Reilly has taken the time to solicit responses from the authors in this book as it has given us a wealth of experience and expertise that we all can benefit from as we seek to gain greater insights into the various facets of beauty and elegance in code.

This book surveys the range of human invention and ingenuity in the development of computer systems. The elegance in each contributor's offering comes from the discovery of unique solutions, a discovery that comes from the authors' power to look beyond established boundaries, to see needs that have been overlooked by others, and to find innovative solutions to difficult problems.

Many of the authors have confronted limitations in the physical environment, in resources, or in requirements that made it hard to believe that there were workable solutions that confronted and solved all problems, and then came up with those solutions. Still others already had a solution that worked, but came up with something new and innovative that worked even better. All the authors in this book have drawn lessons from their projects, but you can learn some even broader lessons after reading the entire book.

1. There are times when rules really do work and you don't have to abandon good technique in order to meet your design requirements. Often you just need to get away from the problem and then approach it again anew in order to see the solution.
2. Some chapters confirm that you must know the rules before you can break them. Some of the authors in this book had years of experience being masters of the various rules of software design before deciding to take an unconventional route toward solving a difficult problem, and this experience gave them the confidence they needed to break the rules in a constructive way.
3. Cross-disciplinary studies are championed by the lessons in this book. Many authors came into new domains and had to find their way in relative darkness. A particularly pure form of creativity and intelligence triumphed in a situation that required pioneers and free thinkers.
4.Finally, this book reveals that beautiful solutions don't last for all time. New circumstances will always require a new look. So, if you read this book and think that the authors' ideas and contributions are not relevant to your current problems, the situation could change in a few months or a few years.

This is one of those books that should be useful to you for a long time to come since the lessons taught here don't go out of style as programming languages and technologies are born and eventually abandoned. Highly recommended.

This is a collection of 33 articles, all new and commissioned for this book, dealing with aspects of beauty in software design and implementation. Most are brief case studies of particular systems, with a few instead dealing with solutions to particular problems. They cover a impressive variety of applications, platforms, and programming languages. The book is worth reading just to see what people are up to today. The examples come mostly from the United States, but all parts of the world are represented.

All articles are well-written but not all will be interesting to a particular reader. My three favorites:

"The Most Beautiful Code I Never Wrote" by Jon Bentley (clever title, clever article, about instrumenting Quicksort)

"The Quest for an Accelerated Population Count" by Henry S. Warren, Jr. (a dozen different ways to count the one-bits in an array)

"When a Button is all That Connects you to the World" by Arun Mehta (Stephen Hawking's only way to control his environment and communicate is through pressing a single button - this system is a great user interface study and shows many clever ways to anticipate what he wants to accomplish and cuts down the time it takes him to do things)

As I was reading this book I was frequently reminded of the proverb "Beauty is in the eye of the beholder". In some cases it was a stretch to call the work beautiful, while others (notably Adam Kolawa's "The Long-Term Benefits of Beautiful Design") went to considerable trouble to identify and illustrate the types of beauty.

One conspicuous omission in the book was the (mostly European) tradition of program proving and developing a program so its correctness can be verified by a short and elegant proof. An earlier "beauty" book, Beauty Is Our Business: A Birthday Salute to Edsger W. Dijkstra (Monographs in Computer Science), in many ways similar to this one, emphasizes program proving and correctness. In some ways the earlier book focuses on "formal beauty" while the present book focuses on "pragmatic beauty".

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)

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.

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.

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.

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.