To be honest, I find The Unix Programming Environment by Brian W. Kernighan and Rob Pike much, much better. The book truly captures the Unix philosophy and teaches you the idioms. It's unsurprisingly since it comes from the original Bell Labs Computing Sciences Research Center and the authors are extraordinary technical writers.
This is an excellent book and the one that made me truly "get" the philosophy of Unix (e.g. using multiple processes, data over code, OOP is not the end-all be-all of abstraction, etc.)
Apparently ESR pissed a lot of people off, but that doesn't make the book bad -- it is truly excellent, and contains material you won't find anywhere else (really). Yes I can see from his writing style why people are irritated, but it actually helps the clarity of the book, oddly.
Those recommending the Unix Programming Environment must not have read this book -- they're missing the fact it covers completely different subject matter. Neither substitutes for the other.
I'm just throwing out a quote to show why I enjoyed the book.
"""To do the Unix philosophy right, you have to be loyal to excellence. You have to believe that software design is a craft worth all the intelligence, creativity, and passion you can muster.
Otherwise you won't look past the easy, stereotyped ways of approaching design and implementation; you'll rush into coding when you should be thinking. You'll carelessly complicate when you should be relentlessly simplifying — and then you'll wonder why your code bloats and debugging is so hard."""
'Worse is better' means that simple and quick to market but flawed is better than complex and correct but slow to market. 'Complicated and flawed' has no place in that debate.
I love unix and composing operations. But I have a hard time thinking "excellence" when it comes to command line parameters of some of these tools. "inconsistent mish-mash" is what I think more often.
It's a relatively minor gripe, but I believe legitimate none the less.
It's interesting to see you say that, because the creators of Unix seem to feel the same way. See papers arguing against the addition of the '-v' option, the size and inelegance of the X window system, and so on.
That's not really a gripe with the book, so much as with the designers of Unix who did not always do the Unix philosophy right. Yes, find(1), I'm looking at you.
It's a long read ~520 pages, but worth it. I just finished it myself, I really like the final chapter where he ties the philosophy to real world political and social challenges that I think we are all trying to solve in one way or another with technology.
I'm surprised this hasn't been submitted before. It's been around for quite some time now.
Regardless of what you think of ESR's personality, politics or hacking skills, I found this to be a pretty good read.
There's lots of good things in here that apply - not just to software written for Unix systems - but for software in general (I guess it's not really a coincidence that a lot of the good practices on Unix are good practices in general).
Well, it's not so much that he can't write code (he can) but more that he markets his hacking skills to an extent greater than what his open source software indicates.
He compares himself to Stallman and Torvalds without having anything nearly as impressive as an OS kernel, C compiler or debugger.
I will say though, that he's good at introspecting on code and articulating points about programs better than most (hence the high quality of the book)
> He compares himself to Stallman and Torvalds without having anything nearly as impressive as an OS kernel, C compiler or debugger.
Does he compare his hacking abilities to Stallman and Torvalds?
My impression is that he considers himself a tribal elder, and compares himself to Stallman and Torvalds in that respect. But that's not quite the same.
I'm pretty sure he has worked on compilers and OS kernels. They just weren't as popular as GCC or Linux. I don't think judging one's programming skill based on the popularity of one's projects is rather fair.
People who can't build excellent software have written many good books.
Writing a good tech book requires deep understanding of a subject.
Writing good software takes discipline, creativity, and (interestingly) not necessarily a particularly deep analytical understanding of underlying concepts. People have written truly excellent software on poor CS foundations.
Edit: Yes, it was written by a guy named Carl Harris and ESR took it over when Harris no longer wished to maintain it: http://en.wikipedia.org/wiki/Fetchmail
His essay on enterprise vs. free approaches to development titled The Cathedral and the Bazaar is also an interesting read and provides some interesting insights behind the unix philosophy: http://catb.org/~esr/writings/homesteading/cathedral-bazaar/
Just realize that it's one guy's take on open source software. He's not more authoritative than anybody else.
The essay became important because it was written at the right time, and because ESR decided to take a role as an advocate to industry. Not really due to its quality.
It's a good book to read, but not in anyway essential or required reading and its badly mis-titled as it contains very little discussion on actual UNIX programming.
The main issue I had with the book was that ESR seem to conveniently decided that the only post 1995 UNIX worth talking about is Linux, largely ignoring the *BSDs and OS Xs of the world. The later sections on licences seems out of place and drift a little bit too far into Open Source dogma for my tastes.
In summary its a bit of a curates egg as it seems to be a bunch of separate essay's that ESR has tried to jam together under a single topic that don't quite fit together.
