Donald Knuth Eats Sacred Cows

Ovid on 2008-05-02T15:51:25

In an interesting interview, Donald Knuth disses unit tests.

[The] idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up."

He's also not fond of XP:

Let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.

Oh, and reusable code is also something he takes a swipe at:

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.

So, let's see. He doesn't like unit tests, XP, or reusable code. These are three things that I suspect many reading this might be in favor of. In fact, if it were just about anyone else saying this, the dogs would be unleashed. To be fair, there's not a lot of context in the interview, so it's not really clear why he has these viewpoints, but he has them nonetheless.

Here's my take: for Knuth, these ideas may be counter-productive. With literate programming (a nifty idea), specialist needs, a deep knowledge of computer science and a life in academia, not business, he has unique needs. All of those things suggest, to me, that even many of the best-known and respected people in our field are unlikely to be in a similar position, and thus have similar needs. But the situation is even worse with the masses.

I'll clarify the last point. A couple of times I've been to conferences I've sat around with core Perl developers, people who do extensive testing work and others in similarly "high skilled" positions and sometimes we complain about the sad state of programming. But I point out to that group that they are far from being the norm. When they complain about others "not getting it", the reality is that it's not fair to expect your typical 9-to-5 programmer to all of a sudden understand OO programming, the importance of loose coupling, or even basic organization of software. And those are simple things. Head over the Perl 6 language list and you can join in our fun discussions about type theory (I'm rather in over my head there). As those conference groups tends to be to the '9-to-5' programmers, so Donald Knuth is to those groups.

I've worked in shops where I'm one of the better programmers (not saying that much, to be fair), but I've found I can't convince others to "step up" when they quite reasonably prefer hanging out at a pub, spending time with their partner, looking after their kids or just enjoying their "non-computer" hobbies. Why shouldn't they enjoy their lives and find more pleasure in the real world? There's nothing wrong with that. We can't just get rid of them because that would pretty much shut down the world's information processing capabilities. So the reality is, we need to accept that different skills sets have different needs.

I guess what I'm saying is that Knuth may be right, but I'm not convinced he's right for the programming masses. Compared to Knuth, I clearly am one of the masses. My math isn't there and my needs aren't there. For example, I can only recall once where I needed to do something as trivial as finding the least common multiples of two numbers. It was in a job interview. I also cannot recall a single time, in my entire programming career, where I've been told a project must be bug free. Nope. Not once. We have deadlines. We have piles of work. We have vague and flexible specs and we're often exploring problem spaces that even our customers don't fully understand and we have to change them quickly, not perfectly.

Far be it from me to take Donald Knuth to task, but it almost sounds like he's generalizing his needs to those of others.

Update: I've been sufficiently impressed with the idea of literate programming that I've been thinking about write a literate programming engine. If I start it, it reads the current project and whenever a file is saved or updated, it would automatically run tangle and weave and also store the index in a database. Go to a literate tag and you can see instantly if it's been implemented, automatically jump back to it, automatically see all of the places which use that tag, etc. It's an idle thought and perhaps not a good one, but who knows?

---

step up?

markjugg on 2008-05-02T17:04:08

It's refreshing to highlight another perspective on program.

I'm curious what you mean by "step up", though. You describe it like it's the same as working overtime, but also the key to be being a better programmer.

Or...

lbr on 2008-05-02T18:11:51

...even geniuses become old koots, set in their way.

Maybe that should be especially geniuses.

Re: Donald Knuth Eats Sacred Cows

jmcnamara on 2008-05-02T19:15:23

The book Elements of Programming with Perl uses a literate programming approach.

There is a short paper about the tangler in the source code tarball at that link.

John.
--

Really good points and well written

Lecar_red on 2008-05-02T21:28:55

I think this was really well written and thought out, thanks for taking the time.

I think your point about the layers (like the Perl onion) of skill, interest, time, experience and commitments of programmers are especially on the mark. Many folks do have life (gasp!) outside of coding and technology. It doesn't make them too bad ;)

Re: Donald Knuth Eats Sacred Cows

jdporter on 2008-05-07T13:24:19

Leading Computer Scientists Agree... You're Doing It Completely Wrong.

Re: Donald Knuth Eats Sacred Cows

pudge on 2008-05-08T06:47:15

I am no leading computer scientist, but I mostly agree with Knuth. Unit tests, mostly a waste of time. Reusable code is good, depending on the context. XP? Kill me now.

Re: Donald Knuth Eats Sacred Cows

jdavidb on 2008-05-08T14:45:49

Yeah, but you eat sacred cows every day, so it's not exactly newsworthy when you say it. :)

Re: Donald Knuth Eats Sacred Cows

pudge on 2008-05-08T15:36:38

Yeah, but you eat sacred cows every day, so it's not exactly newsworthy when you say it. :)

Well, so does Knuth. The real difference is that he is Knuth, and I am not. :-)

Re: Donald Knuth Eats Sacred Cows

jdavidb on 2008-05-08T16:45:41

It's also usually more entertaining when you do it.

test surprise

mr_bean on 2008-05-09T05:18:00

He also said Beware of bugs in the above code; I have only proved it correct, not tried it.



So I would have thought he would be sympathetic to testing. Either the reason is as you say, he is a high-flying academic, or perhaps I didn't understand what he was trying to say in the saying.



Perhaps he is like the haskellers who feel getting it to compile is the evidence they need that it works. And that any uncertainty you have you have to live with.



Perhaps the way he understands bugs is different.



This quote from him from Nikolai Bezroukov. Portraits of Open Source Pioneers titled, Ch.2 Donald Knuth: Leonard Euler of Computer Science/Literate programming:

"Without wanting to be elitist, the thing that will prevent literate programming from becoming a mainstream method is that it requires thought and discipline. The mainstream is established by people who want fast results while using roughly the same methods that everyone else seems to be using, and literate programming is never going to have that kind of appeal. This doesn't take away from its usefulness as an approach."



suggests an ivory-tower disinterest in practice as opposed to theory, at the same time as the idea of literate programming does seem software-engineering-oriented.