Hacker News new | past | comments | ask | show | jobs | submit login
The Art of Unix Programming (catb.org)
178 points by aycangulez on Jan 7, 2012 | hide | past | web | favorite | 40 comments

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.

Kernigan and Pike are stars. Esr can't cose his way out of a paper bag.

downvote me all you like, but read this, first:


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.

Compare the TOC:



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."""

(from the end of Chapter 1)

This seems hard to reconcile with the commonly accepted notion that unix is an example of 'worse is better'.

'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.


Imperfection has better survival characteristics than perfection. The essay below describes how Unix won and LISP Machines faded away.


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).

Edit: Joel Spolsky's take on it: http://www.joelonsoftware.com/articles/Biculturalism.html

Regardless of what you think of ESR's personality, politics or hacking skills, I found this to be a pretty good read.

If ESR can write a really good software development book, why do some people thinks ESR can't code a damn?

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 think that's a big part of it right there: people tend to resent self-proclaimed tribal leaders.

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.

I haven't found a single mention about him not being a good developer. Do we have any references?

Well, there's this: http://news.ycombinator.com/item?id=923775

But my point was not so much that he's a bad developer but that his software resume is not as impressive as those he compares himself to.

Have you ever seen the fetchmail source code?

My brain is still trying to recover from that particular experience.

Didn't he take that over from someone else?

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

Why, what's wrong with it?

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.

Such an amazing read

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.

...its badly mis-titled as it contains very little discussion on actual UNIX programming.

A minor edit would fix it: The Art around Unix Programming

Anyone have a link to better PDFs where the images fit on the pages? E.g. Fig 6.2 on page 170.

I referenced the above article in a blog post not too terribly long ago.


"How to be unix-y in eleventy billion steps"

esr is a complete idiot fyi

why would you read a book about unix programming from someone who never wrote a unix program that was worth a crap?

read the unix programming environment instead.

FYI, people would upvote you if your tone was a little less harsh.

Why isn't this free?

Hm? The first line on that page links to the book, posted online for free. The whole book is under a Creative Commons license.

But the source to it is not available

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact