Customer Rating:  
Summary: Interesting Code
Comment: This book is a mixed box of chocolates. Don't read it expecting a lot of useful ideas on how to improve your code: It's more of a book you read to widen your horizon a bit. Each chapter stands on its own and talks about a different project. Languages include C, Java, Perl, Python, Lisp and others.
Fortunately, most authors don't dwell too much on their definitions of "beautiful" code (a rough consensus appears to be that beautiful code is readable, concise, efficient, and, surprise, does something useful). The meat of this book are code fragments and explanations of the code and algorithms (and their context).
Despite the explanations, several of the chapters left me scratching my head. Understanding and appreciating all of the code (including that from unfamiliar languages and domains) requires a lot of effort.
Curious to see if they'll come up with an "Ugly Code" book next. Should be more fun ("Daily WTF", anyone?) and less pretentious. Plus, I dare say, they could even re-use some of the chapters from this book...
Customer Rating:
Summary: Much of this book will be inaccessible due to the choices of languages
Comment: Two older books that you should buy instead:
Programming Pearls, by Jon Bentley.
Programmers at Work, by Susan Lammers.
Customer Rating:
Summary: A Book With An Ambitious Title
Comment: Ask a number of developers what beautiful code looks like and you'll get different answers. Take those answers and compile them into a book and you'll get this text. I don't particularly find the code in this book beautiful at all, mostly because the code was written years ago when ideas like readability (read Refactoring) were not as important, and where better tools were not available. There are a few chapters where I agree with the author's ideas on beautiful code. However, I find that in these limited cases, the case study that the author presents and the ideas on beautiful code are disjoint. I find it too often that authors re-iterated how short code is beautiful (think Perl), which is not always the case and shouldn't be something that is emphasized too much over readability, maintainability, and extensibility.
My belief is that if you're a college student, this text might give you some ideas on what good code should do (though don't specifically use the code examples, use the ideas). If you work in the industry, your code should look better than the ones presented.
Customer Rating:
Summary: The delusion of programming authorship
Comment: I'm willing to give this book at most three stars, mostly because I'd be ashamed to give it its first one star after the authors put so much work into this project, and I did enjoy some of the essays. I don't believe in hounding and harassing authors as was done to Herb Schildt (C author harassed for being a good mentor) and Kathy Sierra (Java authority harassed for being female).
The code in this book isn't Beautiful, and the book fosters an illusion about programming.
Rob Pike's 1998 example of a "regular expression" processor in Brian Kernighan's lead article isn't Beautiful. It doesn't process strings, properly understood; it processes arrays of bytes, and it does so with no apology from Kernighan.
It uses a value parameter as a work area without apology or explanation. Because C is a required language at Princeton for computer science majors, Kernighan feels no need to point this out, while pointing out the unusual, but correct, use of single-trip while.
It is correct in C to change a parameter passed by value ... but philosophically and from the standpoint of interlanguage readability, it's a C idiom used in a context not predeclared to be C.
We've come a long way, and a long way down, from the Algol vision of a publication language if programmers are expected to know a language, C, which has so many flaws, to learn computer science and Beauty itself.
Pike's code also repeats a test in two different functions. Brian's general apologia is that it's "efficient" but a roughly equivalent C Sharp version is only five times as slow...before you improve the latter by determining where possible the handle of the regex (the set of characters and/or strings that the regex MUST start with, which can be found using library facilities in C or C Sharp that execute for the most part fast assembler code).
The beauty in the code seems to be constituted for Kernighan in the fact that Pike wrote this flawed program in one hour with no back-talk.
The rest of the book adheres to this pattern; forced marches, vanity projects and the misuse of terminology (for example, structs are referred to as classes).
The illusion fostered by this book is that "programming" is the ideally single author writing in a flash of intuition some gnomically brief, uncommented, unHungarianized code which cleverly exploits idioms and implicitly defies a background of "dull" code written by clueless corporate drones...a sort of Star Wars urban legend in which the pure and good Beuatiful coders confront the Dark Side.
Writing about a manifestation of this urban legend in 1985, Theodore Roszak wrote (in From Satori to Silicon Valley) "how could they [the Apple kids] believe something so unlikely?"
The belief persists in technical circles that "we are Individuals who would write nothing but Beautiful code, and think naught but Beautiful thoughts, were it not first necessary to get Version 1.0 out the door and identify non-contributors and heretics, who in any way question our self-image as Luke Skywalker and Co." It persists because telling this story to yourself allows you to avoid confronting the objective subordination of the real programmer to essentially uncaring corporations with, in American law, the fiduciary responsibility to Screw U.
The fact is that "programming" is almost always collective, either in the sense of a group project, or in the creation of the first edition of an artifact which is then (even in the case of Linux and suchlike legendary products) taken from the author and transformed into a set, a series of editions which as a group solve a problem which is itself an ordered set.
Programmers rage for the fantasy of being a single author of unchanging deathless code and because they work in industry (sometimes as virtual slaves to Open Source projects, willing slavery being different in no fundamental respect from slavery, period) they never get this. The result?
Actual coding is fetishized and mystified in the real world to the point of a cargo cult, where at one and the same time, everybody wants to be the Author, but any moves, in the real world, towards this position, are considered to be disruptive, and the result is the grand fantasy of the enterprise system in which "coding", having become the nightmare inverse of the creative dream/fantasy, and the work of evilduuers, is supposed to disappear, but returns in the "mere" setting of parameters...using a Turing complete programming language which is normally pretty much of a mess.
Romanticising this process as having anything to do at all with artistic Beauty (the beauty of a Poussin, of the Ninth Symphony, of Death of a Salesman) breaks the connection with truth which is Beauty's mainstay. Nearly all code is poorly written in parallel or serial-over-time groups in which the members have been forced by management to compete with each other to the point, in some shops, of insanity, and most code unfairly structures the lives of countless employees and consumers in a way that systematically deprives them of meaningful control over their lives as employees, customers, investors, patients, or stiffs in the morgue.
An alternative way was shown early on in Algol, the product of a genuine partnership between universities, corporations and government. This effort was destroyed by IBM in favor of the infantile disorder (Fortran) and a few years on, most of the good ideas in C came from Algol, and were taken without acknowledgement.
I was somewhat saddened to see Kernighan involved with this vanity project because in his early work he sketched out a true alternative to the insanity, this being just slowing down and writing code, in whatever language (even Fortran) in a literate way. I met Brian when working at Princeton in 1987, and I felt like Garth and Wayne (Wayne's World) when they meet Alice Cooper: "we're not worthy". But it's clear to me from his essay and others that this beauty is too much in the minds of an American-centric programming culture to inspire.
Beauty is the Beast: in this book it means only doing it as fast as possible using in-jokes and idioms. There is no suffering here; suffering is prohibited as is asking questions such as "what is a string" when all you have are bytes; internationalisation is unmentionable in the Kernighan essay for this reason, as is the fact that both Java and C Sharp are international in their treatment of strings despite their *de minimis* "inefficiency" without any nonsense whatsoever. Dijkstra, the only real authority as far as I can tell on the type of elegance you need in programming, isn't even in the index.
Three stars, and that's because I'm a nice guy. I gave my own book only four stars because I didn't have enough time to do a perfect job and was perfectly willing to admit this. I despise Amazon numbers games, as well. So, Greg and Andy, consider yourself to have gotten a lucky break.
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.
|
|
