February 20, 2008
I was thrilled to see the book Beautiful Code: Leading Programmers Explain How They Think show up in my Amazon recommendations. It seems like exactly the type of book I would enjoy. So of course I bought a copy.
Unfortunately, Beautiful Code wasn't nearly as enjoyable of a read as I had hoped it would be. It is by no means a bad book, but there's something about it that's not quite right.
Part of the problem is that it's a compilation of disconnected essays, much like The Best Software Writing I. Because there are thirty-three different authors, there's naturally going to be a lot of variance in tone, content, and quality. How you feel about the book is largely dicated by how much you like the individual essays. There's certainly no lack of quality in the authors. There are plenty of famous, highly regarded programmers represented here: Brian Kernighan, Yukihiro Matsumoto, Jon Bentley, Charles Petzold, and many others.
Despite all that, I loved The Best Software Writing; why can't I love Beautiful Code? I wasn't able to put my finger on exactly what the deeper problem was with Beautiful Code until I read this eloquent reader review from Dmitry Dvoinikov. I suddenly realized what ultimately trips up Beautiful Code. It was right there in front of me, all along. It's even in the title: Code.
With rare exception, the authors don't even mention the word "beautiful" in their essays. They allude with "There, we have this system, it works like this." What exactly the author finds beautiful about it, and why, remains a secret.
The chapter written by Yukihiro Matsumoto, the creator of Ruby, was the most impressive standout. It is three pages in which he simply writes about what he believes beautiful code is. He explains his understanding of beautiful code to you. This is what the book should be!
Instead, many chapters just reprint a few pages of code and conclude - see, it is beautiful!
Many times I was 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 presume I do. Any possible appreciation of beauty requires deep understanding. What if I show you a magnified fragment of Mona Lisa's background, an area of 3x3 blackish pixels? No doubt Leonardo had to paint them too. But where is the beauty?
Only a few authors were wise enough to use pseudocode, something that anyone can read, no matter from which camp. It's just weird when the authors present their beatiful code in Ruby or Perl or Lisp. Look, I haven't touched 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 do you see how beautiful it is?" They literally show you a piece of poetry in a 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 this is good or bad and why? What if I told you it's beautiful? Would you believe? Does it appeal to your sense of beauty?
Ideas are beautiful. Algorithms are beautiful. Well executed ideas and algorithms are even more beautiful. But the code itself is not beautiful. The beauty of code lies in the architecture, the ideas, the grander algorithms and strategies that code represents. The code samples presented are indeed clear, readable, and well written. But they are weak evidence of beauty; it's not the language that is inherently beautiful. Barroom doggerel expressed in French or Russian is never automatically elevated to the level of poetry.
So when the Beautiful Code authors proffer pages of code-- real live production code-- and ask us to see the beauty, the code doesn't help. It gets in the way.
It's been a long time since I found *dst++ = *src++ beautiful.
Focusing on the code is exactly the wrong approach. It's like a detailed technical description of the paints, brushes, and techniques used to paint the Mona Lisa, without any of the historical or artistic context that makes it such an important painting.
Can't we expect readers to see past the language? I'd ask the very same question of the authors. So many of them got mired in the minute details of the code and language that they never got around to the "why" underneath -- the beautiful ideas and concepts that code represents. I'd also ask the same question of every working programmer today. I can scarcely post any code snippets in Visual Basic today without a slew of comments complaining about how awfully horrible Basic syntax is, how their eyes are bleeding, it's unreadable, the horrors of End If versus curly brackets, etcetera, etcetera, ad nauseam. Never mind the language-- what about the underlying algorithmic concept I am trying to represent in code? How does that look?
Apparently, for many of us, beauty really is skin deep.
Posted by Jeff Atwood
I tend to disagree with your observation on a number of levels.
1) From a clarity point of view. The initial example it clear that the condition dictates what will be printed, while the latterm you must sepparate the conditions from the actual statement. If/then/else is clearly easier to follow.
2) From a debugging standpoin. You will commonly add a breakpoint inside the brackets so that it only stops when the problematic branch is executed. In the latter, this isn't even an option.
3) In the former there is room for additional functionality... in the latter you will end up adding an in/then/else structure to do this.
All this to say, it still comes down to preference. Based on your comment alone, I think the example was pretty good. You looked at one aspect and said... that's a bad example.
I tend to want to make my code somewhat modular, where others prefer to 'brute-force' it in. I look at the latter example as a brute-force approach. Though some would argue that latter is more elegant. From the modern optimizing compiler, they will both will result in about the same code.
Now... if only I could type.... rofl.... sorry about the typos.
I was very close a few time to buy Beautiful Code.
However based on your recomendation and that of a few developers on their blogs, last week I ordered Steve McConnell's book Code Complete.
Looking forward to a good read.
Code is code. It is neither beautiful nor ugly. It simply is.
Now, the application of code can result in beauty or ugliness.
Case in point:
The code that guides an ICBM to its target is neither beautiful nor is it ugly however; its purpose is decidedly very ugly.
The code that makes up Adobe Illustrator is neither beautiful nor ugly but in the hands of a skilled artist, great beauty can be created with it.
Don't you people get it? It's not about the code and it's not about us; it's about the applications and our users...
While I agree that this book is uneven and, on the whole, disappointing, your comment that "Ideas are beautiful. Algorithms are beautiful. ... But the code itself is not beautiful" is an example of an old, indeed an ancient, fallacy - that somehow thought is independent of expression.
Yes, we all know what a struggle it is to express ourselves, in code, or in a natural language, we all know the feeling of thinking something we can't do justice to. (After all, "ineffable" is an adjective, as in "What was it like?" "I can't describe it, it was completely ineffable." "I know exactly what you mean.") But this inadequacy, this difficulty, presumes and is founded upon particular language.
There are no ideas, and there certainly are no algorithms, without language, and languages are always specific. Pseudo code may sound like the answer - and certainly may avoid unilluminating details in an example, but would that be pseudo Lisp or pseudo Basic? They might both be Turing complete, but they sure are different.
Your example of the patch of canvas actually works against your argument. If I'm really studying the painting them that's exactly what I want to see, because it's the execution of the work that makes everything else possible. If I'm reading about Beethoven symphonies I expect to see diagrams about the broad structures in the works, but I also expect to see musical notation.
Musicians need to read scores, programmers need to read code. That's how the big, beautiful ideas are expressed.
There was a very long discussion about Beautiful Code on Jonathan Edwards' Alarming Development blog when the book first came out.
My basic opinion was this: Code not only isn't beautiful, code is ugly. All code is ugly.
Programmers love slipping a champagne gown on their code and then applying lipstick. Ask a programmer what he does for a living, and he will invariably romanticize it. Now, I don't blame programmers for their pride, but I basically have a very complementary point of view: All code is ugly.
I just don't see the point in romanticizing what I do for a living. IT is the only profession where you can be on call 24/7 and nobody's life is in danger. It's that way because we take our jobs very seriously and love what we do. But we don't need to romanticize it.
The Mona Lisa isn't really that beautiful anyway[...]
Typical irrelevant Coding Horror comment that should never make it to the page.
Jeff, if the code itself is not a good medium to express the "beauty" of ideas or algorithms, what else would you suggest as a means of expression? Pseudo code? UML?
Point is, there is a big semantic gap between any intermediate medium existing today and a particular programming language and therefore a lot of beauty, ugliness, and creativity can be filled in-between. I believe you should have seen the same ideas or algorithms coded beautiful by one programmer but ugly by another.
"Beautiful Code" doesn't completely suck. I particularly liked the chapters on MapReduce and Delta Debugging.
Our Wing Ding study group always needs new meat. We've exhausted the design pattern and concurrency topics. But we all love regular opportunities to meetups, for pizza and engaging debates.
In that way, Beautiful Code fully served its purpose.
Cheers, Jason Osgood / Seattle WA
I did not read this book, but I have read another book "Code Complete". I think "Beautiful Code" should be readable, with brilliant error checking and running smoothly.
O’Reilly just published Beautiful Code. I was invited to contribute, but I just could not go along with the premise. I disagree that beauty is a guiding principle of programming. Here is how I responded.
Readability of code is important, as it directly affects its understandability, and that depends on the language used to write the code, regardless of which language that may be. Some people can read code equally well regardless of whether it's written in VB or Java or Lisp.
What is even more important here is that the code is merely a transformation of a design, which itself in turn is a transformation of a concept, an algorithm, an idea. If there's something wrong with the underlying concept, the very foundation upon which a program is constructed, then no matter how well-written, concise, efficient or well-structured the code is, it's ugly. Because it's still something ugly in a different guise. You see, code does not lie.
"Beauty is in the eye of the beholder": the definition of beauty in code is not necessarily the same for me as it is for you. It is my humble opinion that software engineers should always look at the underlying concept; code is easy to write once you have a firm understanding of what it's supposed to do.
That said, it is perhaps too easy to turn a really "beautiful" algorithm into "ugly" code, just as it is very easy for me to paint a really ugly picture of a really beautiful woman :P
I suppose code is like music, you can use pen and paper, Finale Notepad or Lilypond (in which you have to write code to make the music! It's like TeX and it has scheme built in too if you want to use it). The music can be represented in a few different styles, from the notes we all love and hate, to the imprenetrable ancient forms. You can lay it out differently, give different instruments different parts and some musicians may appreciate the differences, but in the end it's all in the hearing.
Perl poetry is interesting, but most authors are happy for it just to compile. Only the zen masters of the Perl monastery can make it do anything useful when it runs.
@jackhatedance: I'd rather spend my holidays learning a new human language than programming language :)
If code doesn't have a good architecture, the plain nice looks don't help. But still code needs to be also beautiful, because its easier to maintain and doesn't cause headache that way.
Of course one should not adjust the code to be pretty for the sake of prettyness itself, but the beauty comes from what you like. A lion is beautiful, because it is strong, fierless, efficient, fast, and so on. Beautiful code is robust, modern, maintainable, functional, etc.
For example its good to use code templates for various things. That way you don't need to worry about every programmer doing the same thing differently all over the software code. Then you just need to create the template. And people like more a template that is in line with their thoughts about beautiful code: robust, modern, maintainable, functional...
Ugly code can be more efficient, but then it should be encapsulated somehow, like people have skins.
I have a fundamental problem with the idea that code should be beautiful; the idea that beauty is something we should strive towards when writing code.
It's very easy to write a "beautiful" routine that doesn't work.
A lot of code looks ugly because it's fixing a bug, trying to be fast, or implementing a new feature by cleverly re-using existing code.
The primary objective of writing software is to do "stuff" accurately and quickly. You also want your code to be easy to maintain.
Code should be more like a power-station than a Mona Lisa. A power-station isn't pretty but it is essential, it has to work all the time, it has to be easy to maintain and it needs to be cheap to run.
I'll take ugly code that works over beauty any time.