461 of 500 people found the following review helpful
It's beautiful, see ? SEE ???,
This review is from: Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)) (Paperback)
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.
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.
Tracked by 1 customer
Sort: Oldest first | Newest first
Showing 1-10 of 18 posts in this discussion
Initial post: Nov 8, 2007 2:27:27 AM PST
How can you criticize a book called "Beautiful Code" for including real code that the authors think is beautiful? This part of your cour critique seems somewhat off point. The part that complains of the miscellaneous organization is more to the point, or so it seems to me. Your example of the NASA chapter was quite amusing.
In reply to an earlier post on Nov 9, 2007 12:14:26 AM PST
Dmitry Dvoinikov says:
But that's exactly my point - many authors don't explain what exactly they find beautiful and why. Instead they assert "it's beautiful" at best. They sort of assume that I share the same sense of beauty as they do.
In reply to an earlier post on Nov 9, 2007 8:59:34 PM PST
Most computer science people I've met do share a somewhat similar sense of beauty, but "de gustibus non est disputandum."
Your complaint that "[o]nly a few authors were wise enough to use a pseudocode" is what seems to me off point. My disagreement is that using pseudo-code is better, I would prefer a real working example (although not for CLRS). Perhaps it is the word "wise" that bothers me. Programmers ought to be able to read code in various common languages, especially well-made (beautiful) code. Did you find the code hard to understand through ignorance of common languages, or were you able to read them? If the former then your lack of code reading skills is no strike against the book. If the latter then it is unclear due to the phrasing you have used.
Comparing programming languages to human languages also seems to me an unfair comparison. I know a couple dozen programming languages well enough to read code in (not all of them very common), but I know only 2 human languages. I had to spend much more effort learning the latter (neither of which is Russian, alas). My point here is that the comparison is unfair.
Am I wrong? Did you spent less effort learning enough to read English than you had to get to a reading level in any programming language you know?
In reply to an earlier post on Nov 9, 2007 10:31:45 PM PST
Dmitry Dvoinikov says:
I agree to some of your points here. The authors (now being artists) could use any language they like and it's indeed unfair to criticise for that or call it unwise. And yes, most of the computer people do share a similar sense of beauty. And I wouldn't argue my lack of skills in Perl or LISP for instance. And I indeed spent much more time learning English than any of the programming languages that I know.
But, then, for me being able to read (programming) language and being able to see beauty in written, when the author doesn't clearly point out what is beautiful here are also different things. The beauty of the introduced systems is not always in the code, it's also in architectures, in some ideas, in something elusive beyond comprehension, therefore the language doesn't matter and using pseudocode could have been *cough* easier on the reader, because otherwise we have the poetry metaphor again - even though I'm able (to a degree) to read the language, it's not the words which are beautiful.
You are right in that most of the time the authors did present clear and readable snippets of code in whatever language. But then it's not about the language, the beauty.
For example, take even the first chapter, which introduced a regular expression matching code in C. It presents its code in perfectly readable C. But it's not C which is beautiful, at least this is how I understood, and it's been a long time since I found *dst++ = *src++ beautiful. In some abstract kind of way, perhaps, but not when you have to read it on a daily basis.
Anyhow, I guess the bottom line here is - my appreciation of the book has largely been biased with its title and its goal - to present something beautiful. It presented instructive, sometimes interesting, sometimes readable material, but beauty is something bigger.
Posted on Feb 6, 2008 12:58:41 PM PST
Doug Stone says:
Without reading the book, Dmitry's review seems excellent. I agree that pseudocode would be preferable to actual code. For one, I would like the idea of the code expressed in a higher level language: English and/or pseudocode are preferable. I want to read what is so beautiful about the code in English... What were the challenges, how were they met? The book might include a CD with the actual code. Thanks Dmitry for saving me the time and expense. "Programmers at Work" is my best book in this genre.
Posted on Feb 8, 2008 3:47:27 PM PST
Jose Brito says:
Excellent review, Dmitry. Thanks for saving me the time and the money.
Posted on May 19, 2008 1:08:40 AM PDT
Posted on Jun 6, 2008 8:54:35 AM PDT
Roman Gonzalez says:
It seems kinda difficult for me adding pseudo-code to all the implementations in the book, I said particularly for the Simon Peyton Jones Chapter (About concurrency with functional programming languages using STM). Pseudo-code wouldn't give me the expressiveness that Haskell does when using Functional Programming, Pseudo-Code would work great when we are talking about sequential programming languages. All in all, I take some words from you... the half of the chapters doesn't seem interesting at first sight, and beauty is appreciated when you have a knowledge of the programming language used in the example (Haskell in my case).
Posted on Jun 20, 2008 1:49:13 PM PDT
Posted on Jun 26, 2008 8:30:45 AM PDT
J.J. Langr says:
I'd have to agree with this reviewer's comments (although they could have been edited a bit). I looked forward to this book as a great set of short reads--sit and eat some popcorn, digest a chapter, pick up some great insights about what makes code "beautiful." I only found that in a few chapters. I think this book had the potential for being great, but I ended up being disappointed with a good portion of it.