In recent years, I’ve written a series of 1k (that is, exactly 1024 character) reviews on here. This ruse has helped me compose succinct (and possibly useful) notes about many things that I wouldn’t have otherwise written about. But some things that are worth reviewing, such as a documentary about interactive fiction, are really better treated in a bit more depth. Given my interest in the aesthetics of code, and in code that produces aesthetic output, a book entitled Beautiful Code: Leading Programmers Explain How They Think is certainly one of those things.
Beautiful Code is an edited collection of 33 articles by a well-known publisher of technical books. The articles deal with how programmers solved a variety of problems, some of them very general computational problems, others quite specific to particular systems and applications. Several of the authors discuss their own code. The book is part of the Theory in Practice series with Beautiful Data, Beautiful Architecture, and Beautiful Security.
Beautiful Code is a success in several ways. It widens the conversation about code and the innovative development of it beyond particular programming languages, which have often been silos for such discussion has taken place in the past. At least, book-length discussion of programming – in textbooks, in introductory and reference books, and in “tips and tricks” books – has often been language-specific. While encompassing many systems and code in many languages, the book doesn’t take the position that the programming language can be abstracted away, that knowing about data structures, algorithms and an arbitrary programming language allows on to say all that can be said about how to program.
The first article is a particularly excellent one. In it, Brian Kernighan discusses 30 lines of regular expression matching C code which Rob Pike wrote as an example in an hour or two. This concise article deals with how to solve the core of the regular expression problem elegantly and correctly, but it also touches on many other important aspects of code and programming. By suggesting a series of modifications, Kernighan shows that code is an element of future programs rather than simply a fixed solution. Kernighan mentions how the code takes advantage of C pointers and suggests converting it to Java to see how the result would be slower and would require a lengthier program. If you can only read one essay in Beautiful Code, be glad that the editors have placed this one in the front, allowing you to retrieve it in a constant-time operation.
I was also interested in how several of the essays dealt with the need to consider hardware specifics, something one might expect pure, beautiful code to avoid touching. There’s some hint of this specter in chapter 7, which discusses how Jon Bently’s official, “proven” algorithm for binary search has a bug when it’s implemented on most real systems. When the code finds a midpoint within the array by computing (low + high) / 2, the sum of low and high can, in very extreme cases, exceed the maximum integer value, giving a negative (and obviously wrong) result. Later chapters deal with more productive connections between hardware and code. In chapter 10, Henry S. Warren, Jr. delves into the amazing intricacies involved in efficiently computing the population count or sideways sum: the number of bits in a word, or an array of words, that are 1. The current best way of doing this for an array involves using a special circuit called a carry-save adder. Chapter 14, “How Elegant Code Evolves with Hardware: The Case of Gaussian Elimination,” explores the relationship of leading matrix algorithms to changing hardware architectures.
Several other articles interested me; I suspect that programming language researchers, professional programmers, and others will find that a good number of the selections are worthwhile.
But despite the title and some compelling discussion inside, this is really isn’t a book about “beautiful code.” There is almost nothing in it about beauty or what that concept means when applied to code. “Aesthetics” isn’t in the index. When beauty is mentioned, it seems obligatory and stands for whatever the author of a particular chapter values. This, for instance, by Travis E. Oliphant:
>”Iterators are a beautiful abstraction because they save valuable programmer attention in the implementation of a complicated algorithm.” (p. 318)
Could one say anything similar about paintings? Sunsets? Or even something that has an important functional aspect, like a building? “Frank Ghery’s Stata Center is a beautiful building because the layout of its hallways saves valuable programmer time.” That doesn’t sound quite right, does it? There are more reasonable-sounding, if not very elaborated, statements about code and beauty in the book, but some of those seem to express a very narrow perspective. For instance, Adam Kolawa writes:
>”In sum, I believe that beautiful code must be short, explicit, frugal, and written with consideration for reality.” (p. 266)
Michael Mateas and I have written about obfuscated code, a topic that isn’t mentioned at all in this book. While obfuscated programs are usually short, they are also the opposite of explicit, gratuitous rather than frugal, and written without any concern for “realities” like re-use, practicality, and legibility. An obfuscated program isn’t good programming practice – that’s part of the point. For reasons that Michael and I have written about, we consider the best examples of obfuscated code to be beautiful, and I suspect we’re not the only ones. They simply display a different kind of beauty, an aesthetic of complexity and extravagance that shows us things about programming and about the language in which the obfuscated code is written – things that technical essays don’t reveal. You may share this aesthetic and be willing to consider obfuscated code beautiful, if, for instance, you saw beauty in the exorbitant Ok Go video “This Too Shall Pass.”
A final disappointment: There are no articles on the creative, artistic use of code, on programming projects that are meant to create beautiful output – no music, poetry, story, or terrain generators, lightsynths, demos, intros, or Processing sketches. Certainly a book about beautiful code, even if it is targeted at the professional programmer, would benefit from investigating a program or two of this sort?
This isn’t to say that valuing conciseness and clarity is a bad idea, or that having a book about utilitarian programming practice, particularly a wide-ranging one with many interesting articles of great technical depth, is a problem. It just means that much work remains to be done on matters of beauty and code. Perhaps we’ll soon see a book that brings together the diversity and depth of technical discussion that’s displayed here with consideration of the nature of beauty, of what it means for code to be beautiful, and of how the workings, conception, code expression, and wider contexts of a program are all involved in its beauty.
Thanks for the heads up on this. I agree there is a great book to be written or perhaps game to be made, that explores the beauty of programming, ideas, logic and language.
I am guessing that by “beauty” they meant “elegance”, which seems to more strongly imply economy and functionality (but also style and transcendence). It sounds like they also meant beautiful algorithms, not beautiful code; even if you talk about the specifics of a C implementation vs. a Java implementation, this is still different from talking about syntax, or indentation, or other characteristics of the textual artifact representing the underlying program. But even then– your point about obfuscated code being beautiful is probably largely dependent on syntax and formatting, but you may (yes, I still haven’t read “A Box Darkly”) also be considering an obfuscated (or baroque) algorithm as beautiful, independent of its text. Part of me rebels at calling a Rube Goldberg machine “elegant” (though I’d certainly call a good one “beautiful”), but one can’t help but call many naturally-evolved mechanisms (e.g. RNA replication) “elegant”, despite their somewhat ridiculous-seeming roundabout ways of doing things.
Well, that comment was 1024 characters when I submitted it, but it got longer in the retelling.
I liked this review until it went off the rails at “But despite the title and some compelling discussion inside, this is really isn’t a book about ‘beautiful code.'”
The book is about code, not output. The back half of the review confuses the means (code) from the ends (output). Comparing code (means) to a painting (output) or a finished building (output) is apples-to-oranges. Furthermore, making your point using Mr. Oliphant’s bad writing style ignores 1) that he is not a writer, and 2) his message about avoiding needless distractions.
“When beauty is mentioned, it seems obligatory and stands for whatever the author of a particular chapter values.”
I wasn’t aware there was one true definition of beauty. Since code is means, I’d suggest its beauty has a lot to do with achieving the ends. Even when the ends are obfuscation of the source code itself.
“A final disappointment: There are no articles on the creative, artistic use of code, on programming projects that are meant to create beautiful output”
Again, the book isn’t about output, it’s about code, about the means. Hence the title. You might as well blast Strunk & White for having a weak plot in Elements Of Style — it misses the point. The ends of writing may have plot & characters, but a book on the means of writing does not.
It’s a decent enough book, but you mis-characterize it so badly in the last half or so of your review, it makes you look like you don’t know what you’re talking about.
Rod, Doug, thanks for these comments.
Ron, I’m sorry that you didn’t get much out of my review. I never thought the book was about output or wrote that it was. I make the distinction between code and output in the sentence that you quote, and there’s a long discussion of obfuscated code in the second half of the review that doesn’t even mention output. I also certainly didn’t put Dr. Oliphant’s sentence forward as an example of poor writing style – it isn’t. I included it because it was an offhand reference to beauty (one of several) in a book that considers code in much more depth and detail.
I’m not as keen on the means/ends distinction as you, as least as applying in all cases, but I can get behind this idea of yours for code which is “purposeful”: “Since code is means, I’d suggest its beauty has a lot to do with achieving the ends.” A building has a purpose, too, though: It’s supposed to house people, provide them with fresh air and light, allow them to move from place to place, and so on. So I don’t think comparing buildings and code is improper. Both of them are “means” in plenty of ways. I think people discuss the “architecture” of software projects because making this comparison is useful. And yet we have a much more developed idea of what it means for a building to be beautiful. If the building works and is elegant, that’s great, and that contributes to the building’s beauty. But that’s not all we can say about beauty in this area.
I’m sure that, with work, we can develop our ideas of beautiful code as well.