The Art of Unix Programming

The Art of Unix Programming is certainly not a beginner's programming manual. It assumes, instead, that the reader is already a competent hacker and is looking to learn more about the Unix way of doing things. So there is a lot of talk about philosophy and history, and a wealth of case studies. There is a lot of language like:

Eric would, seemingly, like his book to be seen as a successor to the Kernighan and Plauger classics The Elements of Programming Style and Software Tools. This book shows some of the classic Raymond traits: no less than six case studies feature fetchmail (which he wrote), and the examples demonstrating the fortune file format are all about the evils of gun control. But there is some good stuff in there which has not necessarily been written down before. Eric is a good writer, and he has experience in the realm he is writing about. The Art of Unix Programming is worth a look.

We asked Eric a few questions about the draft release; here are his answers.

LWN: If you could characterize the art of programming in/for Unix as described in your book, in a single paragraph, how would you do it?

ESR: I'll do better, I'll boil it down to a single phrase. Keep it simple, stupid!

The true art of programming -- and this is something Unix guys were arguably the first to figure out and the most consistent at applying -- is minimizing global complexity. Most of the rest of the Unix philosophy pretty much falls out of that.

LWN: The draft as posted does not include any sort of licensing; will the final version be available under a free license?

ESR: Yes, but I haven't decided which one. There will be some restrictions on print reproduction, but none on electronic.

LWN: When you first announced the book project, it seemed you were planning to put the chapters out gradually and make use of a lot of community input. After chapter four, however (released almost exactly two years ago), things went quiet, and the rest of the book, seemingly, was done in a "cathedral" mode. Why is that? Did the more open approach not work out?

ESR: No, it's just that I stalled out for a long time and then gave it six weeks of intense work. This happened after an acquisitions editor at Addison-Wesley called me and said "Uh. Apparently you had an agreement to do a book with my predecessor, but I can't find a contract." There wasn't one; I have a twitch that way, I don't sign a contract until the book is essentially complete. He successfully nudged me into working on it again.

LWN: The book talks little about the programming of complex graphical applications, and avoids the GNOME/KDE issue altogether. Yet one could argue that complex applications are a big part of the future of Unix-like systems. There is often, however, a sort of impedance mismatch between fancy applications (think StarOffice 5) and the Unix way of doing things. What suggestions do you have for authors of graphical applications to help them carry forward the Unix tradition in the graphical world?

ESR: Separate policy from mechanism, because policy ages much faster than mechanism. Separate engines from interfaces, because tangling the two together tends to lead to unmaintainable messes. Don't give it a GUI if it doesn't need one.

Policy-mechanism separation is a major theme in the book. It's usually thought of in connection with X, but it can be applied a lot more widely -- and, in fact, Unix programmers *do* apply it a lot more widely without being really aware of the principle consciously.

(Yes, that's right, I'm doing another yet another book that's basically about conscious expression of unconscious folk practices. This would be #3. Is there anybody left who still finds this surprising? No? I thought not... :-))

One of the insights I got, one that's especially applicable to big gnarly GUI applications, is that Unix programmers divide all Gaul into three parts -- policy, mechanism, and glue. Mechanism is code that tells how to do things, policy is code that tells what to do -- and glue is the stuff that binds policy and mechanism together.

The punch line: glue is evil and must be destroyed, or at least minimized. Your typical huge honkin' C++ application with classes stacked twelve deep is an unmaintainable mess because the top two layers are policy, the bottom two are mechanism, and the middle eight are glue. And the trouble with glue is that it's opaque -- it impedes your ability to see clear down through the system from the top, or clear up from the bottom. You can't debug what you can't see through, because you can't form an adequate mental model of its behavior.

So my advice to GUI programmers is this: Decide what's policy and what's mechanism. Separate them cleanly -- ideally, have the GUI and engine running in separate processes, like gv and ghostscript or xcdroast and cdrecord. Then *ruthlessly eliminate all glue*. Or as much of it as you can, anyway.

LWN: There is very little treatment of security in the book. Why is that? Is, in your mind, security peripheral to the main art of Unix programming, or is something else going on?

ESR: It's peripheral. This is not a book about system administration, it's about how to design well. There's an aspect of that that has to do with secirity of course, but most of the things that make for good security (like minimizing code that has to be trusted) are just good engineering practice. That I *do* talk about a lot.

LWN: Unix has had a long run in the computing world, and, by all indications, it has a while to go yet. All good things come to an end eventually, however. What do you think might bring about the end of the Unix era, and what might replace Unix in the future?

ESR: My money is on capability-based persistent-object systems like EROS. But prophecy is difficult, especially about the future.