on November 27, 2003
Raymond does a good job of explaining the philosophy driving the Unix-style of programming. Coming from a background programming Windows, I always thought of the Unix approach (lots of abbreviated command-line utilities, mini-languages, pipes, semi-unstructured text-based process integration) as down-right primitive. However, after reading this book, I've started to understand the philosophy (and the practical reasons) for adopting this approach. I'd definitely recommend this book especially to newbie programmers from the Windows or Mac (pre-OS X) worlds. That said, I do have some criticisms:
One of the problems with this book is the overly partisan tone it takes - one gets the impression that absolutely nothing Microsoft has ever done is of value, but the other major desktop PC OSes (Apple, Linux) represent different forms of perfection. (At home, I run Mac OSX, RedHat Linux and Windows, and have a reasonable sense of their relative strengths and weaknesses.)
So, be warned: Art of Unix Programming paints a one sided picture. The author is a well-known figure in the open source community, one of its fiercest advocates, and one of Microsoft's most vocal critics, so it might seem to strange to wish for less anti-Microsoft spin from this source. After all, the Raymond brand certainly carries with it an obligatory expectation of Windows-bashing, doesn't it?
One of the only Windows design decision which Raymond doesn't condemn is the (now discontinued) .ini file format. Even the thorough-going support for object-orientation in Windows is given short-shrift: after explaining the many horrors of object-oriented programming (according to Raymond), Unix-programmers are praised as "tend[ing] to share an instinctive sense of these problems." This section ([...]) is particularly illustrative of the one-sided approach that Raymond takes.
Art of Unix Programming is really an excellent and informative book which could have been substantially better with a little balanced discussion. I found myself constantly second-guessing the author: Is he arguing such-and-such a point on the merits or because he simply loves UNIX & hates Microsoft so much? While the book does a great job of articulating and illustrating the UNIX idiom, it's a shame that the reading experience is marred by mistrust. If he hadn't been so blindly anti-Microsoft, we'd be able to more confidently rely on his conclusions, and the text would be not merely highly informative (as it is), but definitive (as it is not). Four stars, therefore, instead of five.
PS: You can find this book on-line with Google - no charge.
Even for a primarily Windows programmer, this is a great book to read. He provides a great overview of the Unix design philosophy, its evolution over time, and the things that it still doesn't handle well (user-centered design). He also digs deeper into a lot of the patterns in program organization and coordination to help you choose what to build into a utility, what to expose as a library, and what to package as a set of binaries. There's even a small bit of programming advice from place to place. I'd highly recommend reading the book to at least get a sense of perspective when you're designing your next system. He's right on the mark that the Windows and UNIX worlds have a completely different philosophy on program construction, each with their own merits.
His comments about the Windows registry were a bit distressing, though -- not because they're negative, which I consider fine. Rather, it was obvious he'd never used it (comments like "there's no API for it") and it was also clear that he hadn't even bothered to research why it existed and what problems it was intended to solve. The comments were typical of what I'd expect of a Slashdot troll, but not of a bright, respectable person like ESR. I've programmed on both platforms extensively and only comment on what I have first-hand experience and knowledge of; I'd expect him to do the no less, especially as an author.
It was also curious that several times he implied unit testing == XP == agile software development. For as tuned in as he seems to be to methodolgy work, missing the forest for a single leaf is a bit embarrassing.
on December 24, 2003
The writing style of this book tends to hurt the reading experience, as Raymond trumpets his own minor achievments in the free software community. The work feels like it needed one more rewrite before being released to the public: some related sources Raymond hadn't yet read at the time of writing, and some of his advice gets repetitive.
The exposition itself is not up to par with The Elements of Programming Style. Raymond tries to give a list of programming rules or principles to follow, but it reads more like a list of slogans that should be taken as axioms. While The Elements of Programming Style itself had a list of rules, the rules were well woven with each other, well defended, and they were used as a means of conveying a larger story. In Raymond's case, he relies upon the slogans in absence of such a story.
Thus, the book ends up more like a list of random unrelated tips. Some very profound, like his writings on threads (which he acknowleges Mark M. Miller for his help). Others are very shallow and pointless in a book that supposes to call itself about "Art." Some of the pieces appear only to function to attack Windows, and sometimes the information about Windows is embarassingly inaccurate.
One final criticism is that Raymond does not understand object-oriented programming very well and misses the point in several cases. You just need to see the popularity of Python, Java, C# (Mono), OO Perl and C++ in the Linux world to see that Raymond is off base calling OO a failed experiment. In fact, with almost any matter of opinion in the book you can feel Raymond's bias and be hit in the face with misinformation or dull false dilemmas.
However, given this book's many flaws, I rate this 3 stars instead of 2 stars because it also has valuable information from the many contributors, some of them Gods in the Unix world. These contributors often even disagree with Raymond, or point out other interesting tidbits. For these tips alone, it is worth checking out this book, though I would not recommend you buy it.
To get the true Unix programming philosophy, I recommend Software Tools, by Kernighan and Plauger. It's somewhat dated, and I recommend the Ratfor version of it, but that single book has became very influencial as I grow as a Unix programmer.
on July 23, 2005
When I first started reading this book, I expected to hear a considerable amount of Microsoft trashing and everything else that follows from fanatical Microsoft haters. However, what I found was an easy to follow book that illustrates many aspects of Unix programming, explains why they work, and shows examples of all of them.
The organization of the chapters is logical and the emphasis on the Unix philosophy helps with the flow of the book. Raymond starts out by enumerating the philosophy and writing a bit about each one. Many are universal, as "The Rule of Separation", "The Rule of Diversity" or "The Rule of Least Surprise" in user interfaces. However, many others are specific to Unix and its descendants such as "The Rule of Silence" and others. From there on, Raymond takes off to talk about how Unix is designed and implemented guided by the items of the Unix philosophy.
The book also includes a nice history of Unix section, which is pretty much the history of modern computing. Reading it made me all warm and fuzzy inside; it was both entertaining and informative. A must-read.
Where this book falls shortly is in some criticisms of non-Unix related topics. Object oriented programming is apparently not appreciated by Raymond. I don't agree with a lot of his claims about how object oriented programming over-complicates things. In my opinion, writing in procedural languages is messy stuff. Also, this man seems to think everything in Unix is simply perfect. Although a bit annoying at times, in many instances the result is positive becase his passion for the topic is clear.
Even though there is no code, it didn't take anything away from reading. The knowledge gained from it is HUGE because of the amount of material covered, and it WILL make you a better programmer, independent of whatever OS background you are from.
on February 19, 2004
This is a really great book, 30 pages into it I had already begun raving about it to my peers. It takes the reader through years of Unix history, philosophy, application, and wisdom. It starts out slowly, explaining how an operating system can create and sustain any sort of culture. It admits the flaws in Unix and highlights it's strengths and successes. It then gets into the "Rules" of Unix Philosophy, which was something that was greatly beneficial to me in my coding life. It teaches the reader to make things modular and simple, not try to redo things that have been done before, not to be overly clever, etc.
Throughout this book the reader is given examples of some of the most basic things in the unix world, why text is so important, what "transparency" is when referring to coding, and it even includes a non-bias section reviewing some standard unix text editors. The book also gets into evaluating various languages in unix, including which is most appropriate for certain projects, which can be very helpful to someone looking to learn a programming language but who is unsure of which direction to take. A whole huge section of this book gets into the community of unix, standards, documentation, licensing, and the actual personal community.
The most thrilling part of this book for me was the History of Unix, hackers and the open srouce movement. As a history buff I always tend to be drawn to such things, and I believe he did a very good job and kept me enthralled. I also enjoyed Appendix D: Rootless Root: The Unix Koans of Master Foo, it was quite witty and amusing, as well as full of great lessons.
A wonderful computer book suitable for any sort of computer buff, even if they aren't currently working directly with Unix. It's easy to skip around this book by scanning the contents to just see what you're interested in, I really believe there is something for every computer enthusist, I am surprised a book like this hadn't been written sooner.
on May 13, 2004
I was able to spend a couple of months finishing this book. As soon as I finished the first chapter, I know the book would be an excellent one, and it does not disappoint me from the beginning to the end.
I have been using Unix (and its variants) for a decade amd have quite some knowledge about "how-to", but probably like most other Unix programmers, have never systematically thought about the underlying "why". This book is going to tell you both in details.
The book contains topics in software engineering / design / implementation / interface / documentation areas. They are all supported by solid examples, both success and failure stories. This makes it stand out among numerous books on similar topics. The author's concise and clear writting style is among the best I have seen in computer books (similar to Richard Stevens's famous series, if you have to make a comparison). The author apparently does not fail on me to make me a better Unix programmer.
The book is an good complementary to your library if you are a Unix programmer (it is also refreshing even if you do not program under Unix). And I'd recommend this book to everyone who starts to program under Unix or have programmed under Unix even for a long time.
on June 1, 2004
I suppose any book containing so many interesting quotes from so many UNIX luminaries cannot be overlooked. (I wonder if any of them would have co-authored this) It also happens to contain a great many topics that are well-worth writing about; My only wish is that someone less in awe with the contents of his own field of vision, and with greater depth and objectivity (not to mention humility) had the opportunity to write this book.
Quality of discussion is varied as expected; Raymond is not quite the UNIX expert he thinks he is. In places, Raymond's tone encourages one to throw the book at the nearest wall and go out just to get some fresh air; He is condescending, hectoring, lecturing, and sometimes just misleading. Alas, I will still recommend it as worth reading (check your local library) with a nice grain of salt; just enough friction for thought is provided in this edition.
on October 2, 2004
I purchased this book as soon as it was avalible is September 2003. Mr. Raymond gives good sound advice that this Computer Science student has taken to heart is his studies. The advice is so simple, obvious, and logical that you will find yourself wondering why you didn't think of these things in the first place.
Along with good advice this book also gives an insightful history of UN*X and some suggestions as why it is not "King" of the desktop today, as it should be.
Further into the book there numerious examples of good programming practices; featuring programs that follow the traditional UN*X philosophy of coding. This book also explains the many pitfalls that seem so prevenent programming practices. I say this as an experenced computer user not as programmer. With these observations I hope to become a quality UN*X programmer.
It has been noted in an other review that Mr. Raymond is big into the Linux community. Yes this is true. He is one of Linus Torvalds's right hand men and spokesmen. Mr. Raymond, to his credit, touches very little on the subject of Linux of his known dis-liking of M$ in this book.
This book will forever be in my library of programming books. You will never catch my copy of this book here on Amazon as a used book. (Unless of course I am starving to death or I am already dead and my family is selling off my stuff.) I would like to thank Mr. Raymond for sharing his many years of UN*X expertise. (I would actually like to meet him some day.)
on April 3, 2004
This book is written by Eric S. Raymond, who wrote ncurses and a large part of GNU Emacs, and thus one should expect a large amount of Unix and GNU bias. I don't think either are inappropriately placed, especially in a book like this. Raymond covers just about every topic that applies to the "tranditional" Unix programmer, from a historical as well as contemporary perspective, and offers a large amount of insight into each topic.
For someone new to Unix, wishing to understand its origins and design philisophy, or for anyone developing on Unix (especially traditional development in C or C++) this book is highly applicable. The book is very readable; it's less of a technical book and more of an open discussion of past and current development practices.
If you the have the opportunity, I highly recommend you have a look at the "Origins of Unix" chapter; Raymond was there for most of Unix's history, and he recounts it vividly. This was the most entertaining and informative chapter of the book, especially for someone who is new to the Unix community. His discussions of transparency and modularity were also very practical and useful.
on March 27, 2005
I've been using, administering, and teaching UNIX since 1991 without the benefit of any formal instruction. That means I rely on books. I just got a desk copy of The Art of UNIX Programming and found it to be one of the very best UNIX books I've ever seen. Although it's not a text I'll strongly recommend it to students in all of my classes.
ESR's writing style is excellent. The information density is very high but the book is an easy and engaging read, in fact the first time through it was hard to put down. The inclusion of historical anecdotes, caustic comments, and even koans keep it lively. Technically it's rather high level with very little fine detail. For details consult UNIX for the Impatient.
The book is as much about using UNIX as it is about programming with UNIX. I suppose these points of view are inseparable, after all why bother to use UNIX if you don't want to tell your computer what to do? The point is this book is useful to non programmers and occasional programmers. ESR fills far more space discussing things like file formats, XML, shells, editors, and documentation than he does explaining C. Understanding how these pieces work and fit together is essential to using UNIX productively.
This is not a high school history book edited to be free of all content which might possibly offend someone. If you're a Windows partisan you'll have to get past more than a few uncomplimentary references. Even if you disagree, you can take the knocks as enlightening you on the considerable philosophical differences between UNIX and Windows. ESR also doesn't hesitate to point out areas of difficulty within UNIX, now I understand exactly why I have problems with vi and sendmail.cf.
This book is old school, but then so is UNIX itself. This book will help you understand the history of what went right, what went wrong, and why; and that will help you make better use of UNIX today and tomorrow.