Doug McIlroy vs Donald Knuth
I stumbled on this account of Doug McIlroy displaying his “old Unix hands” (you may need to refresh a few times to load), and I’m left in awe. Follow along on this tale.
It’s a story about Donald Knuth, Professor Emeritus at “Stanford” (sounds made up), you may know him as the computer scientist that made the Kessel run in under 12 parsecs. In the tale, Knuth writes a beautiful yet simple program in (something like) Pascal. The source code of this program is absolutely breathtaking. Seriously: it’s like reading bad Shakespeare (which is pretty dang good for (something like) Pascal). Anyway, Doug McIlroy is asked to review Knuth’s code and, after giving a few nice remarks, he unloads on Knuth and presents a six-line Unix shell script to replace all 10+ pages of Knuth’s (something like) Pascal. Brilliant.
The article ends in excellent style:
I can’t help but include one more excerpt. It’s the last paragraph of [McIlroy’s] review:
‘Knuth has shown us here how to program intelligibly, but not wisely. I buy the discipline. I do not buy the result. He has fashioned a sort of industrial-strength Fabergé egg — intricate, wonderfully worked, refined beyond all ordinary desires, a museum piece from the start.’
Just remember, he’s saying this about Donald Knuth.
No Fabergé eggs for McIlroy. Just brass balls.
We need to stop for a moment to appreciate good — nay! great writing. Reminds me of a certain someone.
Now, in reality, it occurs to me that McIlroy and Knuth were speaking two different languages here. Knuth was demonstrating literate programming, an ideology that never really caught on, whereas McIlroy was quoting the Unix manifesto: an ideology that caught like wildfire. I don’t think these two philosophies are necessarily at odds — McIlroy’s comments make that clear — and Knuth probably could have written a program that adhered to both ideologies. McIlroy was talking instead about an aspect of programming that’s a bit more difficult to nail down: wise work.
The discussion is very similar to the Worse is Better philosophy which, among other things, we can summarize by the adage “simplicity over correctness”.
From McIlroy:
The simple pipeline given above will suffice to get answers right now, not next week or next month. It could well be enough to finish the job. But even for a production project, say for the Library of Congress, it would make a handsome down payment, useful for testing the value of the answers and for smoking out follow-on questions.
Simple? Yes. Correct? Well, his code did actually prove to be correct, but it doesn’t appear as if McIlroy even cared. The word “correct” has such a sneaky set of assumptions that usually come with it, but it’s in reality an extremely elastic term. Correct when? Correct for what purpose? Correct right now may mean a random number function that always returns the number 5. Correct for an unknown purpose ten years from now would require writing code by throwing darts at your keyboard.
That last remark of McIlroy is the razor by which us pragmatic philosophizers should judge correctness: is it useful for testing the value of the answers?
This is what separates McIlroy’s philosophy from the standard Unix philosophy or Worse is Better or any other number of other things. This is the Wise Lesson of McIlroy: that the value of the answer is more important than the value of the implementation.
How often I fail in that aspect of problem-solving! I am generally more interested in the intrigue of a solution than the actual value of the answer. Is what I have just delivered useful? In-game programming: is this feature fun? Does it look truly sick-nasty? Yes, I see that your solution was completely modular, you’ve made a very fast and interesting data structure, and I can’t believe it’s all on the GPU (for some reason) — but what is the value of the result?
Thank you. McIlroy, for a helpful reminder, that the brilliance of implementation is multiplied by the value of the answer.
