Book Review: The Philosophical Programmer by Daniel Kohanski

Kohanski, Daniel. The Philosophical Programmer: Reflections on the Moth in the Machine. New York: St. Martin's Press, 1998. Amazon here.

I just finished reading the above book, and wanted to write out some thoughts about it while it was still fresh in my head. I've been working on an article for Free Software Magazine about the art of computer programming, and this was one of the books I encountered in my research. The book seems to be trying to accomplish three goals: Provide an introduction to computer science, offer some enlightening history of programming, and describe programming aesthetics. It's actually a very interesting and well-written book; I got "hooked" and ended up sitting up late into the night to finish it.

I especially liked Chapter 2, where Kohanski delves into his "aesthetics." Kohanski seems to be struggling here with his notion that anything gets better when attention is paid to aesthetics. However, the weakness of his argument seems to me that he trumps everything with efficiency. A straight ditch is more aesthetically pleasing than a random one; it also happens to be the most efficient means of carrying water. Hmm...He also talks about the aesthetics of a house the same way; the locations of bathrooms and the like should be carefully thought out.

Why is this a weakness? Well, Kohanski says that "programs are not written solely to be understood by computers, but by people as well," and then goes into descriptions of how best to comment a program and how to lay everything out so that others can follow it easily (12). However, I keep balking because no one seems willing to consider that perhaps an "aesthetics of programming" can dispense with efficiency. After all, if source code is meant to be read by humans as well as machines, then why can't a programmer add some flourishes that may fly in the face of efficiency, but nevertheless be appreciated and admired by readers? Must a novel always choose the most terse, direct language? Must a drawer always strive to use the least number of lines? A painter the fewest possible colors? Of course not. I think all this emphasis on conciseness and efficiency is quite dull and standing in the way of a true "art of programming."

Kohanski always seems to get close to this thesis but then plays the efficiency trump card. For instance, he talks about how early programmers had to deal with severely limited machinery. He writes: "Space and tmie were at a premium, computers were slow, and any trick that programmers could squeeze out of the data, was a savings well earned" (15). I've listened to lots of interviews with 8-bit and even 16-bit game programmers who say the same thing; programmers really got a buzz out of concision. Any lines of code they could eliminate or shorten spared precious memory. Kohanski points out that this problem is no longer with us; space and memory are cheap and plentiful--what is costly is the programmer's time. What matters now is making programs more readable and re-usable.

Kohanski nexts tackles ethics. He argues that programmers inadvertently make ethical decisions when they develop code. He talks about how the medium "alienates" programmers: "Instead of seeing the program as a real instrument affecting the lives of real people, programmers somtimes see it as a game, a challenge to their ingenuity" (22). He also describes users who are insulting online but who would never insult the same people to their face.

Finally, Kohanski gets around to the ethical dilemma of source code. Closed source "makes it almost impossible to know if the software was deliberately designed to act to the disadvantage of the user for the benefit of the programmer or supplier" (27). This is the key argument I made for free software in an upcoming article in FSM. If you can't see the code, you shouldn't trust the executable.

What else does this book have to offer? Well, the history of programming sections are full of interesting tidbits. For instance, I didn't know that COBOL was a hit because the Pentagon announced that it wouldn't buy any computers that didn't come with a COBOL compiler. Earlier, the DoD had teamed up with various manufacturers to create the language--"Customers very much wanted to have a single standard language instead of the multitude of incompatible languages then being offered" (92). At that time, it was the computer manufacturers who were trying to lock-in users with proprietary software to guarantee their loyalty. Now, of course, it's software manufacturers (basically the tail wagging the dog).

Kohanski then goes into great detail about why languages like FORTRAN and COBOL are ugly and inelegant, whereas more modern languages pay more attention to the aesthetic element. They also pay more attention to coding in discrete blocks which can be shared among programs.

Those who wrote the first computer programs quickly discovered that it did not pay to reinvent the wheel each time. If someone had already written and tested a block of code to calculate a square root, it was easier to ask for a copy of the procedure than to work it out all over again. Informal code sharing soon developed into formal libraries of reliable routines, and by 1951, David Wheeler of the Cambridge group had worked out an efficient mechanism for loading such routines anywhere in memory so that another program could use them. (125)

Thus, we clearly see the origins of FS. That's pretty old hat, but what's interesting here is the insight that the languages lent themselves to this kind of borrowing, recycling, and sharing. Functions, for instance, were a critical step towards modern development. Whole programs can be used as sub-routines in larger ones. "In this fashion programmers build on previous work to craft new solutions to ever more complex problems," writes Kohanski. "The modularity of structured programming goes a long way toward making this incredibly complex accumulation of code a working reality" (139).

I'd highly recommend this book for anyone teaching a rhetoric of technology style course. True, it's full of technical stuff that some people may not like, but I think is absolutely essential for anyone studying C&W.


"I think all this emphasis on conciseness and efficiency is quite dull and standing in the way of a true 'art of programming.'" Without having read the text, let me make one point. Computers science is *all about* efficiency. The most elegant solutions to problems are almost always the most efficient. In fact, an algorithm is nothing but a proof (see David Gries, The Science of Programming). Proofs are elegant when they provide clear, efficient solutions.

So the problem here is that you are applying a set of lingustic aesthetics to programming that are based on prose. Think like a computer scientist, or even a mathematician, and you'll see the difference.

That's precisely what most people hold to be the Way It Is Done, Charlie--or the "Right Thing." I'm writing an article now for FSM that opposes this belief. My argument is essentially that while most programs are written for computers, others, especially FS, is written for other programmers--even for non-programmers to enjoy. I think that what we will eventually see emerging is a sort of "coding art" that may not even be compilable, yet it immensely pleasurable for folks to read. Or we may see a continuation of Knuth's WEB or CWEB (literate programming), in which the documentation (and enlightening and entertaining documentation it is!!) is contained within the source code. I don't want to spoil my article here, but I'll talk about all these ideas in greater detail.

well, I wish you luck and will have to wait for the article. but i don't think i'll be able to agree that this is about "the way it is done." there's something more here, something related to what coders, hackers enjoy. perl golf for example.