Read Again: The Art of UNIX Programming by Eric S. Raymond

In a moment of nostalgia, I picked up my copy of “The Art of UNIX Programming” by Eric S. Raymond (esr) and flipped through it again. The book is a review of Unix, its history, design, and “culture”. The term “culture” here is less intended to describe the community, but more a set of skills, mentalities, and expectations that are associated with the Unix environments and its users.

It’s a book I’ve had since when it came out in 2004, and that I’ve always been quite fond of. I liked its distinctly “long view”, and the way it discusses, compares, and evaluates design principles and options. Picking it up again, I was therefore looking forward to a review of “the way the future was”, as viewed from the early 2000s. So, it came as a bit of a surprise to me to find that the book seems to have aged rather poorly.

The book was written at the height of the struggle against Microsoft’s (apparent) march towards world domination, and was very much intended as a partisan contribution to that effort. It not only wanted to show what Unix was like, but also provide arguments why it was better than the competition.

Not surprisingly, this aspect no longer seems relevant. Microsoft is no longer regarded as the “evil empire” as it used to be. In fact, the whole topic has lost its poignancy. Partially, this is a sign of success: Unix (in the form of Linux) and open-source software more generally are not only established, but indispensable. The nature of the tech industry has also changed: battles are fought less over technologies and more over market-share. Not all of this is goodness: the world is (again) facing a near-monopoly in web-browsers (among other things), but this fact does not seem to evoke the same amount of emotion and concern that it used to.

But, reading it again, and with the benefit of 20-year hindsight, I found that the book’s strictly technical sections were not as prescient as I had remembered. In fact, the book misses a number of trends that were taking off at precisely the moment that it was written.

Java, for example, was at that time just about to begin its ascendancy in server-programming, but the book is rather lukewarm on it. The importance that concurrency would attain is not really appreciated; all we get is a brief, unfavorable section on threads. As a matter of fact, Java, with its early inclusion of threads, had a clearer vision of the future in this regard (although not necessarily with respect to the technical realization).

But most interesting is the book’s failure to anticipate the rise of what might be called “lightweight design paradigms”. They have become a recurrent theme in software design and meta-design in recent years, from lightweight file formats (JSON), over minimal configuration languages (YAML and TOML) and document formats (Markdown), all the way to REST APIs, microservices, and (in a way) containers. Several of them (JSON, YAML, Markdown, REST) were already on the horizon when the book was written, but the author does not mention them, is possibly not even aware. This is remarkable, because he provides an extensive review of existing protocol and file formats. All this is a pity, because with their minimalistic, “do-one-thing-and-do-it-well” characteristic, lightweight formats are actually very much in the Unix spirit and tradition.

By contrast, the author’s recommendation to converge on DocBook as uniform documentation format going forward seems to betray a remarkable lack of technical taste and vision: the baroque inconvenience of both the DocBook format and its toolchain was already clearly visible back then. (Having written two books in DocBook XML, I know what I am saying!)

And this is what I mean when I say that the book has not aged well: looking back, the book does not seem to have envisioned the future insightfully, even though bits and pieces of the future that was-about-to-be were already present and should have been recognisable at the time of writing. I am still fond of the book, but at this point mostly as a period piece, for some of its historical sections, and for pointers into the rest of the universe. The brief section on Plan 9 (the one from Bell Labs), for example, was what first alerted me to this topic.