Hey Now Jeff,
I like the cover, it reminds me of lessons from geese you tube vid. Worse is better right? http://www.codinghorror.com/blog/archives/001046.html All code is beautiful, just some may be better that others. Eye of the beholder right? I really like your comments about seeing past the language.
Coding Horror Fan,
Catto
Here is some pretty code for you to do fancy math. I’d rather read books about life in the IT business world like “NetSlaves” by Bill Lessard and Steve Baldwin. Or “dot.bomb: My Days and Nights at an Internet Goliath” by J. David Kuo.
000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. FancyMath.
000030 ENVIRONMENT DIVISION.
000040 DATA DIVISION.
000050 WORKING-STORAGE SECTION.
000060 01 Quantity PICTURE 999 COMPUTATIONAL.
000070 PROCEDURE DIVISION.
000080 ArithmeticDoneHere.
000090 MOVE 6 TO Quantity.
000100 ADD 4 TO Quantity.
000110 DIVIDE 2 INTO Quantity.
000120 DISPLAY Quantity.
000130 STOP RUN.
*dst++ = *src++…
while(*dst++ = *src++);
is much more useful.
certainly not beautiful… just a major fag to read. Certainly not efficient either… post increment is evil. 
*dst = *src;
while(++*dst = ++*src);
and its still ugly…
I really agree that algorithms are the truly beautiful part.
I enjoyed a number of the essays, but the quality overall was pretty uneven. Some of the projects seemed pretty banal (eg the ‘mars rover’ and ERP system) and there were even a few that I considered examples of ‘anti-beautiful’ code. Some of the essays were also quite specialized or domain specific. Overall I would agree that I was somewhat disappointed with the book.
I agree with you. In contemporary art, no artist will ever explain why his work is beautiful, this is the job of art critics, it could have been a better idea to do it this way for this book.
Yet art somehow is framing and displaying beauty in a quite playful and evident way, something you will never find with software and code, since it is mostly hidden/compiled. It is like a modern car, nobody fancy to look at the engine these days, even if it is probably and endless resource of wonders and ingenuity.
My code is ugly at first glance, full of outdated comments, bad indentations, redundant conditions and long forgot unused variables but I like to think the structure is quite polished and inventive. Too bad none of the authors had the patience of introducing what are his methods to design the structure.
Novelist Thomas Wolfe once wrote of an editor whose great talent was his innate sense of “rightness”, the ability to know when then exact right words had been set to the page. When I see beauty in code, it is something akin to that; a realization that the prgrammer has done exactly what is needed, and anything more or less would somehow detract from the whole. I do not find any programming language inherently beautiful. None can be said to be particularly ugly either, so long as it allows the developer to effectively communicate with the compiler and other developers, while solving the broader problems that prompt us to create software in the first place.
I can’t get over the cover photo. The formation of the bird should indicate leading, but somehow I havt to think of a arrowhead all the time (which wouldn’t be beautiful at all):
if () {
if () {
while () {
if () {
goose.IsLeader = true;
}
}
}
else {
}
}
It’s too bad the authors didn’t discuss their aesthetics, commonalities and differences.
Lisp and Ruby are as different as Futurism and Impressionism.
I remember reading this book a while back and had no problem at all understanding the included code, even when it was a language like Ruby that I’ve never used before. Programming languages are a lot a like and my years of Java experience was plenty to understand everything in the book.
Maybe this reviewer who compared the code examples to an incomprehensible foreign language simply isn’t a programmer. People who can’t speak Russian don’t try to read Russian books, so why is this guy who can’t read code trying to read a coding book?
Nice post, reminds me of one of my favourite ever quotes;br/br/
i
When I am working on a problem, I never think about beauty but when I have finished, if the solution is not beautiful, I know it is wrong.
br/span style="font-size: 0.8em"R. Buckminster Fuller/span
/i
I wouldn’t mind it if you posted VB, Jeff.
I’ve programmed in VB. I’ve programmed in C++. If there’s a beauty difference between End if and a curly brace, I guess I’m “tone deaf” to that sort of thing. I actually prefer the verbose syntax of VB. Curly braces seem to be the last refuge of the lazy. It’s the “If I add another curly brace, my code compiles” mentality. Explicit begins and ends of if-then’s, loops, etc. forces you to see and think about what you’re doing a wee bit more, and frankly I’m no longer arrogant enough to think I can keep 4 or 5 levels of curly braces straight.
FYI, from my experience as a software tester, I can tell you that C++ code is inevitably a lot buggier than VB code of any dialect. Admittedly, some of this is how VB used to hide errors. I know, however, that by handling a great many things automatically, and protecting the programmer from themselves, that it prevents a great many errors too.
In technical subjects, it takes a pretty thorough understanding of the subject to see the beauty. You can’t expect to be able to see it after a single chapter of light reading. The essence of what makes it beautiful is much more subtle than that. And I suspect that you honestly cannot explain to someone else what makes a technical subject beautiful unless they already believe it. Otherwise, you can allude to the reasons for it being beautiful. You cannot demonstrate it.
One case of this I’ve seen over and over again is the beauty of mathematics. I have taken a number of classes where the professor gives a few classic proofs to show the elegance of mathematics. They are almost always: sqrt(2) is irrational, there is no largest prime integer, and there exist irrationals a and b such that a^b is rational. The point is supposed to be that such obscure, hard to reason about questions in math can be proved with absolute certainty in about 5 minutes. But in a few of my classes (the C.S. ones ;-), many of the students’ eyes simply glazed over. They could perhaps follow each step of the logic individually, but even after giving into the fact that these theorems are true, they certainly must not have seemed at all beautiful.
Beauty is to a large extent an acquired taste. Part of the acquisition of that taste is learning the language the example is given in. Lisp looks like total garbage until you see a bootstrapping interpreter for it, and your audience needs to understand what an equivalent interpreter for C would look like. Haskell is overly abstract and seems to complicate the simplest tasks, but once you see how monads unify some of the most difficult concepts in programming: backtracking, continuations, error propogation, state management, and parsing, among many others, you can begin to appreciate how elegant monads really are. But to people not familiar with those topics and their difficulty and who have never seen monadic code, monads are just weird math crap.
I was also disappointed with (the majority of) this book:
The “RESTful” chapter with all that really clunky Java?
The FORTRAN, fer cryin’ out loud? All in all a wonderful
idea for a book, but too many bum entries to bring that
idea to fruition.
I must admit that i didn’t read the book. But i saw a presentation by Andreas Zeller, who did the part on Beautiful Debugging.
If this man wrote the chapter as well as he did the presenation at JAOO 2007 about it, it must have been an awesome-wicked chapter.
Jeff,
‘Beauty is in the eye of the beholder’.
Code is art driven by purpose. If the purpose is speed, sometimes code will get obfuscated as shown by your example. It is kind of Machiavellian.
There there are the folks who want to cram as much on the screen as possible:
if ( a == b )
{
printf( “Yo!” );
}
else
{
printf( “No!” );
}
versus
printf("%s",((a==b)?“Yo!”:“No!”));
I’d be a liar not to say I’ve written the latter in instances with knowledge that the former would make it easier to follow.
Some people look at spaces, blank lines, and indentions as wasted space: ugliness, if you will. However, many coders ‘hide’ their laziness behind a ‘pursuit of speed’ justification. There is no excuse not to comment, and make easy-to-follow code.
Consistant rules is my personal issue. I really don’t care, as long as the rules are logical and consistant. As an aside, many of my coleages laugh at one of my idiosynchracies: I add a semicolon to the end of my bracketed if-statements in c??. I just think it should be there. The optimizer removed the nop, so I really don’t care about it. I will say it has saved me with mis-placed else statements, but it is really just a style thing to me.
Short of ratcheting back to the days of fixed-format FORTRAN, we are stuck with these free-flowing formats. I guess the best advice is for us to stick to our guns and work on making our code clear and concise.
-Doug
Jeff,
You can post all the VB code you want to, I would rather you speak to me in my native language than Russian after all.
I am struggling through a OO class using Java and frankly dealing with the curly braces makes my head hurt. I grok the OO part, and Inheritance and Classes and even Polymorphism isn’t that hard to grasp, struggling through layers of curly braces and remembering NOT to type “end if” is frustrating beyond belief.
Thanks for a good post…
Student
"…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. "
You’re contradicting yourself. You’re saying that it’s not the language that makes the poem beautiful, but then saying that if you DON’T look at it in its original language then it effects the beauty of the poem. You’re right on the latter account.
You’re conflating two ideas. There can be beautiful algorithms expressed purely mathematically, but then there are beautiful algorithms that are beautiful because of the code used to express them. If you repaint Monet’s in a Pre-Raphaelite style, would they still be beautiful? Maybe, but certainly not in the same way. The style is PART of what makes a Monet beautiful. In the same way, using different tricks with Ruby or LISP is often what makes the code beautiful.
Well, I enjoyed the book! Nothing is perfect, but I took it as a well-edited collection of essays from experienced programmers about code that they enjoyed writing and, in their opinion, they found “beautiful”.
With that assumption, I benefited from reading the book and recommend it to others.
Defining beauty is like trying to define intelligence, a slippery task at best.
~Matt