| Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)) | 
| Creators: Andy Oram, Greg Wilson
Publisher: O'Reilly Media, Inc.
Category: Book
List Price: $44.99
Buy New: $33.85
You Save: $11.14 (25%)
Buy New/Used from $15.99
Avg. Customer Rating:   (34 reviews)
Sales Rank: 18769
Format: Illustrated
Languages: English (Original Language), English (Unknown), English (Published)
Media: Paperback
Number Of Items: 1
Pages: 618
Shipping Weight (lbs): 2
Dimensions (in): 9.1 x 7.1 x 1.2
ISBN: 0596510047
Dewey Decimal Number: 005.1
EAN: 9780596510046
ASIN: 0596510047
Publication Date: June 26, 2007
Availability: Usually ships in 1-2 business days
|
| Similar Items:
|
| Editorial Reviews:
Product Description
How do the experts solve difficult problems in software development? In this unique and insightful book, leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts to see problems through their eyes. This is not simply another design patterns book, or another software engineering treatise on the right and wrong way to do things. The authors think aloud as they work through their project's architecture, the tradeoffs made in its construction, and when it was important to break rules. Beautiful Code is an opportunity for master coders to tell their story. All author royalties will be donated to Amnesty International. tion.
|
| Customer Reviews: Read 29 more reviews...
 It ain't all that beautiful... November 10, 2008
The editors of this uneven book give us 33 chapters from various, often well-known developers, in which these developers describe some code and explain why they think that it is beautiful. There are some gems, but it's not light reading and quite a bit of it is a real slog. If you are a professional programmer, it's probably worth the effort, but otherwise I'd steer clear.
And, in fact, all too much of the code is downright ugly. This starts, sadly enough, with the first example, by Brian Kernighan, describing a limited-capacity regular expression matcher.
Yes, THAT Brian Kernighan, a software god among men. But the example he describes as beautiful would be the last thing I would ever want in any software that I had to maintain. I am sure it is efficient, and it probably works, but the only beauty that I can see is that, if you convince yourself you understand why it works, you've also proven to yourself that your mental abilities put you in an elite category of coder. God help you if you need to modify the method's functionality or (shudder) debug it.
Another dubious entry in the book is by Adam Kolawa, who describes the CERN mathematical library. He claims that no library routine can be beautiful if it uses dynamic memory allocation. The software architecture he deems beautiful passes working memory, in the form of an array to the library routines, which in turn pass it on to their subroutines. In fact, the space used by the input parameters is reused to hold the solution. I am sure that CERN math library is an excellent package, but I would hate to have the job of tracking down bugs in a system in which all the subroutines in the stack were writing back into the same array.
Software ugliness can take many forms, as, for example, in the chapter by Ronald Mak, describing NASA software used for the Mars Rover mission. The solution for a highly reliable, long running, independent system? SOA, using Java 2 and J2EE EJBs. I am a big fan of Java and J2EE, but why on earth (or Mars!) would the Mars Rover system need EJBs? The SOA and EJB technology is at its best when coupling diverse databases and interacting with legacy systems. It brings with it a significant complexity and overhead. Why would anyone think this was appropriate for the Mars Rover?
For my taste, the worst of the worst was an article by R. Kent Dybvig, describing a program for analyzing code and detecting parameter name clashes. The code to be analyzed is in Scheme, a Lisp dialect. It's been awhile since I've fooled with LISP, but I was ready to give it a try. So here is an example of a macro that has potential scope issues, if there is a bound variable t elsewhere in the code:
(or e1 e2) -> (let ([t e1]) (if t t e2))
...and here is the refactored code, in which the problem is fixed:
(or e1 e2) -> (let [g e1] (if g g e2))
I stared dumbly at this for all too long a time until I read the next phrase, "in which 'g' is a generated (fresh) identifier". Here I'd fault the author for a really rotten presentation, and also for begging the question, since the whole problem he is purporting to solve is avoiding name clashes.
In fairness, the book also has many descriptions of genuinely beautiful code. I especially enjoyed the article by Charles Petzold on efficient image processing through code generated on-the-fly. Also, Henry Warren essay on devising efficient algorithms for counting the number of enabled bits in a bit string is fascinating. Yet another stimulating article is by Brian Hayes, who describes an efficient approach for determining if three points are co-linear. This article also uses LISP as the example language, but unlike Dybvig's piece, it's clear, and "porting" the approach to Java or C++ would be straight-forward.
In summary, "Beautiful Code" is a very mixed bag. On balance, it is probably worth reading, but without doubt it is a disappointment.
Disappointing. October 27, 2008
I guess that my main problem is that the 'beauty is in the eye of the beholder'. I returned the book after reading the first two chapters. So, I cannot claim to review the whole book, but the first to chapters were very far from what I can call 'beautiful code'.
The first chapter in the book presents a recursive C implementation of a greatly simplified regular expression parser. I would agree that this parser implementation is 'clever', but I cannot see the beauty of recursive C with pointer arithmetics.
The second chapter presents an interesting solution to keeping track of changes in the SVN client/server architecture. But again, while the algorithm is interesting the code is anything but beautiful. For one thing, the solution to this clearly object oriented problem is done in C (again), which makes the code harder to understand.
 Not for the faint hearted October 21, 2008
I like this book but it is a flawed thing.
Worth the read but not convinced it is worth the cost.
I started more than half the chapters and skipped on because either it was too obtuse or specific to a given language/problem or too general to be useful.
However there are also some great chapters.
If you are looking for a gift for the tech-head who has everything then this could be a good choice. If funds are tight and you are buying for yourself you probably have better ways to spend the cash.
I can't be too critical. The intent was noble and good. The authors are donating any profits to charity. I can't point to a better way of writing/structuring the book.
So yes it's good and I liked it but my praise is conditional and constrained. I feel churlish for saying these negative things because it is, as I said, well intentioned. I just wish it was better described as it was not what I thought I'd be getting. Not that I feel ripped off, just a little bemused.
A couple of great essays, a bunch of so so ones. September 4, 2008
1 out of 1 found this review helpful
I must say I was pretty disappointed with this book. I expected so much more. The lead off piece by Brian Kernighan is the best in the book. I hoped that the rest of the book would at least try to be as good, but other than Matz's essay and perhaps Bently's (I can't remember now) they were mostly drek. Several were agonizingly boring, long fluff pieces about something they worked on that read as histories of the work they did on a piece of software. Very little insight into the creative process or anything else interesting.
For a book with so much potential, it was a huge let down.
 Uneven, Uninteresting August 18, 2008
5 out of 5 found this review helpful
There's a critical need for a book on code aesthetics, elegance and comprehensibility that goes beyond simple style guidelines -- this isn't that book. The contributions are uneven, a few border on the incomprehensible, and most are simply not worth the time. There are no revelations or insights to be had.
|
|
|
