- Series: Theory in Practice (O'Reilly)
- Paperback: 620 pages
- Publisher: O'Reilly Media; 1 edition (July 6, 2007)
- Language: English
- ISBN-10: 0596510047
- ISBN-13: 978-0596510046
- Product Dimensions: 7 x 1.4 x 9.2 inches
- Shipping Weight: 2 pounds (View shipping rates and policies)
- Average Customer Review: 52 customer reviews
- Amazon Best Sellers Rank: #142,006 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)) 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Fulfillment by Amazon (FBA) is a service we offer sellers that lets them store their products in Amazon's fulfillment centers, and we directly pack, ship, and provide customer service for these products. Something we hope you'll especially enjoy: FBA items qualify for FREE Shipping and Amazon Prime.
If you're a seller, Fulfillment by Amazon can help you increase your sales. We invite you to learn more about Fulfillment by Amazon .
See the Best Books of 2018 So Far
Looking for something great to read? Browse our editors' picks for the best books of the year so far in fiction, nonfiction, mysteries, children's books, and much more.
Frequently bought together
Customers who bought this item also bought
About the Author
Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in free software and open source technologies. His work for O'Reilly includes the first books ever published commercially in the United States on Linux, and the 2001 title Peer-to-Peer. His modest programming and system administration skills are mostly self-taught.
Greg Wilson holds a Ph.D. in Computer Science from the University of Edinburgh, and has worked on high-performance scientific computing, data visualization, and computer security. He is the author of Data Crunching and Practical Parallel Programming (MIT Press, 1995), and is a contributing editor at Doctor Dobb's Journal, and an adjunct professor in Computer Science at the University of Toronto.
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
And one chapter did it! Titled "Accelerated Population Count" by Henry S. Warren, Jr (which is about calculating bit counts in arrays) is truly breathtaking and inspiring. Now, is it worth buying this book just for one small but very good article? Maybe, since A) it's that good, and B) I can't find it mentioned anywhere else, including the truly magnificent "Hacker's Delight" by same Henry S. Warren Jr. (the "Hacker's Delight" describes cool tricks in the bit counting area, but doesn't mention CSA).
If you are interested in the premise of this book, here is my recommendation:
1. Buy the "Programming Pearls", and get to know the real beautiful code 101 by heart
2. Buy the "Hacker's Delight", and keep is as a reference on the bit twiddling algorithms
3. Stop at the library or bookstore for 15 minutes, and read the "Accelerated Population Count" from the "Beautiful Code"
You can trust my opinion because I bought the book to test reading textbooks on my first tablet and had very low expectations (the title is a bit of a facepalm :) - the book also donates to charity or something too.
The individual writers mostly fail to impress on us the beauty of the code - when and where they felt it, how it occurred to them and what followed. I feel an existing relationship with the beauty in code helped me appreciate the book.
It also feels unedited: what book are they assembling - something for experienced programmers to appreciate or are they seeking to inspire plebs to read code?
The former is sort of achieved but there's a lot of very skip-able faff.
As inspiration it covers a broad slew of problems (some of which are architectural rather than procedural) and the solutions are often fairly technical. If you happen to have at least considered most of the problems and have solid experience in 10 languages and 3 paradigms, that's fine but it ain't gonna work for the vast majority of devs.
Were I editing this book, I would call it "Code Stories" and insist that an attempt be made to use pseudo-code and diagrams; that the stories be English and the code be formal.
There is savage beauty in C and assembler which provides some of the best entertainment in book. These could be contrasted with modern standards to comic effect imho - that's definitely what I was doing when I read them :)
I want to fix this book which indicates I think it has a lot of value. In it's present form I think the reader has to do a lot of work from a perspective of skill and experience to appreciate it.
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.