Spotlight customer reviews:
|
Customer Rating:  
Summary: Beauty is in the eye of the beholder
Comment: I found the book's concept intriguing. The ability to learn from 33 highly respected members of the programming community is invaluable. I've enjoyed my daily dose of Beautify Code... but one thing caught me by surprise:
Not all samples are beautiful... well in my eyes not all samples/chapters are beautiful.
I'll skip listing the ones I found beautiful, interesting, insightful and educational because I'm sure you will find others that "do it" for you.
All in all I think it's worth giving this book a shot.
PS - I recommend reading Dmitry Dvoinikov's review and the comments associated with it... you'll get a better sense of the book.
Customer Rating:
Summary: Beauty in the Eye of the Programmer
Comment: 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.
Customer Rating:
Summary: There are better books than this.
Comment: 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)
Customer Rating:
Summary: Nerd Heaven
Comment: Thirty-three chapters, by different authors, each covering what they consider to be beautiful code. The list of chapters on Amazon will give you an idea of what's inside. Everyone will have their quibbles with some of it -- things you don't care about, people who code better than they write, or think that using their favorite tools (Haskell, Scheme, OO Design) automatically makes it beautiful -- but overall there's a lot of good stuff here. I learned something from every chapter, even those I didn't really care about completely. A good book.
Customer Rating:
Summary: It's beautiful, see ? SEE ???
Comment: 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.
|
|
|
