"Reading this book has filled a gap in my education. I feel a sense of completion, understand that UNIX is really a style of community. Now I get it, at least I get it one level deeper than I ever did before. This book came at a perfect moment for me, a moment when I shifted from visualizing programs as things to programs as the shadows cast by communities. From this perspective, Eric makes UNIX make perfect sense."
--Kent Beck, author of Extreme Programming Explained, Test Driven Development, and Contributing to Eclipse

"A delightful, fascinating read, and the lessons in problem-solvng are essential to every programmer, on any OS."
--Bruce Eckel, author of Thinking in Java and Thinking in C++

Writing better software: 30 years of UNIX development wisdom

In this book, five years in the making, the author encapsulates three decades of unwritten, hard-won software engineering wisdom. Raymond brings together for the first time the philosophy, design patterns, tools, culture, and traditions that make UNIX home to the world's best and most innovative software, and shows how these are carried forward in Linux and today's open-source movement. Using examples from leading open-source projects, he shows UNIX and Linux programmers how to apply this wisdom in building software that's more elegant, more portable, more reusable, and longer-lived.

Raymond incorporates commentary from thirteen UNIX pioneers:

• Ken Thompson, the inventor of UNIX.

• Ken Arnold, part of the group that created the 4BSD UNIX releases and co-author of The Java Programming Language.

• Steven M. Bellovin, co-creator of Usenet and co-author of Firewalls and Internet Security.

• Stuart Feldman, a member of the Bell Labs UNIX development group and the author of make and f77.

• Jim Gettys and Keith Packard, principal architects of the X windowing system.

• Steve Johnson, author of yacc and of the Portable C Compiler.

• Brian Kernighan, co-author of The C Programming Language, The UNIX Programming Environment, The Practice of Programming, and of the awk programming language.

• David Korn, creator of the korn shell and author of The New Korn Shell Command and Programming Language.

• Mike Lesk, a member of the Bell Labs development group and author of the ms macro package, the tbl and refer tools,lex and UUCP.

• Doug McIlroy, Director of the Bell Labs research group where UNIX was born and inventor of the UNIX pipe.

• Marshall Kirk McKusick, developer of the 4.2BSD fast filesystem and a leader of the 4.3BSD and 4.4BSD teams.

• Henry Spencer, a leader among early UNIX developers, who created getopt, the first open-source string library, and a regular-expression engine used in 4.4BSD.

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 37 Ratings

I wish I had read this book back in college - 2009-02-16
Reviewer Rating:
The author does a great job explaining the Unix tradition and where it came from. This book is filled with design considerations and high level concepts related to programming techniques. It gives a clear insight into what went in one's mind when designing many of the programs that are so common to Unix.

I think you will enjoy this book if you have had basic exposure to Unix (even as just a regular user), and some basic exposure to programming.

Unix is dead - 2009-01-03
Reviewer Rating:
This at least is the overarching message conveyed both directly and incidentally throughout Raymond's book. Unix in the concrete, non-abstraced sense has died and been replaced in practice by Linux and with the former solidly displaced from the market we can apparently begin to take to the bold liberty of refering to Linux interchangably with Unix's name. From the title the book advertises itself to be about Unix but from the opening chapters documenting the history and progression of Unix there is a clear effort to re-cast the decades long history and family tree of Unix operating systems into a footnote to the modern re-implementation in Linux and even the overall open-source movement at large. All of which the various originating UNIX architects solicited for in-line commentary seem to be conspicuously silent about. This is impressively maintained through the rest of the book without any substantial mention of BSD-derived operating systems or OSX beyond the opening of the text. Sadly, for what praises can be offered for this book, it's notable and distracting that Raymond suffers from a stark habit of inserting a number of personal biases and pet causes into his prose, as this book actually does otherwise serve a novel and admirable use in the valuable documentation of history and culture in passing eras of computing and development.

The close-knit communal spirit of timesharing on minicomputers in Bell Labs is seized on as a faint archetype of modern distributed OSS development while Ritchie, Thompson and the rest are curiously painted as disheveled and counter-cultural "hippies" "flipping a finger at the system", never mind these were the same hippies who would stay along for the ride on the side of Ma Bell and SVRx against the Berkeley Academia as the Unix market cannibalized itself in the late 80's. While nonetheless engrossing in its own right, there's some degree of romanticism and embelishment laced in the presentation of Unix history here, and unsurprisingly it tends to err quite clearly on the side of presenting the the earliest days of Unix as a directed progression toward the wider quasi-social movement of collaborative development and open-source software. This kind of disquieting historical reinterpetation and editorialization continues throughout in places both trivial and not: Raymond, for instance, clearly has a low personal opinion of Richard Stallman's attempted infusion of moral context into the realm of Free software development and regrettably manifests this, rightly or wrongly, in the unsubstantiated assertion that Stallman has been popularly marginalized, thereby imposing his personally-held disdain for FSF priniples on OSS developers at large. He can do this, you see, because he is authoring history.

Other varying idiosyncracies crop up: anywhere Perl is mentioned, Python (Eric's personal favorite scripting language) will appear by it's side. Emacs Lisp is inexplicably offered alongside established systems programming and RAD languages as a choice for a general-purpose programming language. And on the topic of Emacs, a partisan argument for rationalizing Emacs's notorious feature creep is presented in the form of describing it as a general extensible scripting framework in harmony with the Unix philosophy of modularity, rather than a conspicuously bloated but still useful text editor. This of course, is accompanied by apparently obligatory potshots taken at vi and Vim. It's less alarming that he'd reasonably arrive at a spirited opinion of this sort of thing than that minor personal convictions and editor war ammunation essays such as these would find their way into a text purporting to immortalize and document the Unix culture for all to refer to.

The less inflammatory parts of the book can laregly be summarized as case studies of the Unix spirit of design, effectively all of which can be distilled at some level as interpretations of the general KISS philosophy, which for the uninitiated basically translate to explicit warnings against overengineering. I'm suspicious of how much of this is simultaneously revelatory and actionable, but I suppose it's easy for ideas like these to be lost in the modern age of professional software development. Moreover, as this book explicitly aims to convey unquantifiable ideas and culture it's difficult to rate the book in terms of the knowledge imparted; it's a sometimes disjointed accumulation of essays on a wide range of topics spanning Unix history, various shell tools, predictable FOSS cheerleading, licenses and languages. And despite the above criticisms, much of the book actually makes for interesting reading despite the author's clear self-insertion into much of the book; it all actually makes for decent light reading even if the overall value is indeterminate.

But to end in the same manner as I believe other reviewers have, it is overall something to be taken with a grain of salt.

Good Book, Good Principles - 2009-11-04
Reviewer Rating:
Eric S. Raymond is a controversial open source developer and evangelist.

The true is that he has a good points and ideias of how to develop using the unix pratices (eg. the practice of separation and program specialization).

I love unix (any flavor), it is by far the best operating system for a wise developers. The advice of Eric really makes sense for someone used to work with unix, and I put a lot of his advice to good use.

I recommend this book to an intermediate/advance unix programmer/analyst.

Unix triumph at its best - 2008-10-09
Reviewer Rating:
First of all this book is also available online and is thus very accessible to many more people. It is a delight to read and I would call it a classic.It is really better appreciated by experienced Unix/Linux users, but would be useful to other audiences. The style is easy to read and very philosophic, mixing the lessons from Zen with the pragmatism of Unix design and culture. The principles and examples it teaches are really applicable to different areas of software engineering, not only Unix and not only operating systems. I can say that the book is unique in the sense that it does not teach what other excellent books have already done, it rather tells the higher level story in a ready to absorb manner. If you spend the time reading this book in printed form or online you would be glad you did and you would have a good time doing it.

Extremely enjoyable, but at times a bit overly biased. - 2008-08-21
Reviewer Rating:
I just finished reading The Art of UNIX Programming. In short, I liked it a lot.

Here are a few fun quotes:

Controlling complexity is the essence of computer programming -- Brian Kernighan [p. 14]

Software design and implementation should be a joyous art, a kind of high-level play...To do Unix philosophy right, you need to have (or recover) that attitude. [p. 27]

Microsoft actually admitted publicly that NT security is impossible in March 2003. [p. 69, Unfortunately, the URL he provided no longer works.]

One good test for whether an API is well designed is this one: if you try to write a description of it in purely human language (with no source-code extracts allowed), does it make sense? It is a very good idea to get into the habit of writing informal descriptions of your APIs before you code them. [p. 85, this is a good explanation for why I write docstrings before I write code.]

C++ is anticompact--the language's designer has admitted that he doesn't expect any one programmer to ever understand it all. [p. 89]

One thing Raymond does very well is document things that the rest of us implicitly assume. For instance, he described the various cultures revolving around UNIX. Now I know why I'm so mixed up! I sympathize with several different cultures such as:

* Old-school UNIX hackers
* The Open Source movement
* The Free Software movement
* BSD hackers
* MIT Lisp hackers
* The IETF

My copy of the book is from 2004, and as timeless as this book is, I still wish I could get a "post-modern" opinion on several topics. For instance:

* Linux is so commonplace these days, what should we do now that everyone takes it for granted?
* OS X has really won the hearts of a lot of developers. Is there any hope that the rest of the world will move closer to the Free Software ideal? (Please see my post A Hybrid World of Open and Closed Source Software http://jjinux.blogspot.com/2008/02/hybrid-world-of-open-and-closed-source.html.)
* I'd love to get his take on Eclipse, TextMate, and modern-day Emacs and Vim.
* I'd also love to get his opinions on Ruby and Rails.

In general, I think it's a fair critique that there weren't enough critiques of Unix. He mostly saved them until the last chapter. I would have enjoyed more critiques throughout. As much as I love Unix, one of my favorite books is The UNIX-HATERS Handbook.

Similarly, all of his discussion on Emacs vs. Vi seemed a bit biased. I know it's hard not to be biased on this topic, but I was a bit frustrated when he called all of Emacs' complexity "optional complexity" and all of Vi's complexity "accidental and ad-hoc complexity." Because of his statements I even gave Emacs another shot. However, as usual, I was reminded that in theory Emacs is my favorite editor, but in practice I'm a Vim user http://jjinux.blogspot.com/2008/03/vim-why-i-like-vim.html.

Nonetheless, I do have high praise for this book. When I was totally burnt out and couldn't code for two months, I found this book refreshing and relaxing. I owe Raymond my thanks :)

Browse Similar Topics

Top Level Categories:
Programming

Sub-Categories:
Programming > UNIX