Derek Sorensen

E. W. Djisktra Diskjtra Diskra Dijkstra

According to Dijkstra, he was the first professional Computer Programmer in Holland (PDF), although at the time of his marriage he wasn’t allowed to call himself a programmer, and hence his marriage certificate read “Theoretical Physicist”.

In programming circles - particularly among geeky, pretentious programmers like me - Dijkstra is almost - but not quite - as well quoted as Knuth. In this blog, I will share some of my favourite and not so favourite Dijkstra quotes, and offer my own interpretation of them. I don’t know if this will be boring for anyone who isn’t a programmer, or even for those who are, but hey - you run it up the flagpole in the hope that someone salutes, right?

On the off-chance that there are some people reading who aren’t turned off by it, I’d welcome any comments - positive and negative - of my interpretation of the Great Man’s words. Ok, here goes.

Separate Concerns

Yes, yes and thrice yes. I don’t want to be worrying about how I access the database in the middle of a calculation which works out the depreciation of an asset. I don’t want to worry about how I’ll display the data while I’m reading it. Always try to separate the fundamental parts of a system; it keeps things simpler (always good) and makes it easier to refactor later.

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

It took me a few years to learn this for myself. In some ways I wish I’d encountered Dijkstra earlier; in others I’m glad I didn’t - as I’d not have believed him anyway. When I first began programming, I believed that there was merit in writing code which was difficult to understand; that hard thinking was required and that it was ok to use side-effects - even program them in. I read pieces like The Story of Mel and thought to myself “I wish I could be like Mel” not realising that he had committed the cardinal sin of programming - despite the sentiments of the author of that piece - and made his code impossible to maintain. I suspect even Mel couldn’t have made the change and I wonder whether that was the real reason for his refusal to do it.

Always design your programs as a member of a whole family of programs, including those that are likely to succeed it.

I *think* I know what he’s getting at here. Every line of code you write is either part of a wider system, or might become one. So there’s no excuse to write hacky code which won’t fit in anywhere else. I’m not sure I agree with it though; the firt time I write a CSV export for - I dunno - a mailing list database - it’ll be hacky and nasty. But that’s because at the same time as I’m writing it I’m getting my head around the problem domain, and also I don’t know if I’ll ever need to write a second one. Once the day comes that a second one is needed, I’ll rewrite it (and unlike many programmers, I really will rewrite, using the original hacky code as a design spec rather than as a base).

Program testing can best show the presence of errors but never their absence.

It seems so obvious now, but this was new back then. We can never prove a program, only disprove it. In the same way that science can never prove a theory, but only disprove it. And this is why you occasionally - or with some software quite frequently - see error messagees pop up, sometimes meaningful, other times apparently written in martian. Because no matter how well you test or try to prove a program, there is always a potential for errors to exist, and the more complex the software becomes, the more difficult it is to test all possible conditions. So programmers test what we can, using sensible ranges of values and then throwing in plenty of unfair values for good measure, in the hope *we* can break it - and fix it - before the user gets his hands on it.

Ironically, though, when a program throws an error it’s working correctly. If it wasn’t it would just carry on and corrupt your data or do something else unexpected. So when you see an error message don’t curse the programmer. Thank him for protecting you from his or his peers shortcomings.

Don’t set a flag; set the data.

Whilst I agree in principle, in The Real World this is hard to live up to. I’m sure we can all think of examples where this is easy - for example instead of setting a “data exists” flag when data is read in a loop, and displaying a message like “no data was found” when the flag was not set, we set the mesage before the loop and clear it within the loop. But other cases are harder, and it’s not always easy to see what you should do which might be better. This quote in particular makes me wonder if I should go “back to school” for a while.

Object-oriented programming is an exceptionally bad idea which could only have originated in California.

Nuff said.

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, “Dijkstra would not have liked this”, well that would be enough immortality for me.

Ok, I’ll admit it - this has happened to me. And sometimes I’ve stopped what I was doing and rewritten it. Not always though - sometimes you just have to get the job done. I’m not prepared to let religion (with a small r) get in the way of getting paid. Not all the time, anyway.

Computer Science is no more about computers than astronomy is about telescopes.

This is so true that it brings tears to the eye. It requires no explanation, and would not benefit from it anyway. Like so much in programming, it’s a Zen thing: either you see it or you don’t.

Probably I am very naive, but I also think I prefer to remain so, at least for the time being and perhaps for the rest of my life.

This is the parting shot in this brief piece concerning Russel’s Paradox, and yes, I think this is naive - or possibly handwaving. Russel’s point - if I understand correctly - was that we have no way to model the paradox (which has been expressed in a variety of ways, many of which illustrate the real paradox far more explicitly than the Barber example) and so to say “that equation has no solution” is to admit the paradox.

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.
=and=
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

Dijkstra’s views on COBOL and BASIC are among the best known, seconded only by his opinions on GOTO (with which I concur) and that’s a shame as I’m sure that this was hyperbole. At least I hope it was. But whether he believed it or not, I believe that taken at face value it is completely wrong. COBOL was my third language - BASIC was the first, and FORTH the second (although *please* don’t ask me to write any FORTH - not even for fun). I don’t feel crippled - and in fact, I’d even go so far as to say the best programmers I have ever met are COBOL programmers. Yes, COBOL is a clumsy, clunky language, but the one thing it teaches is discipline; without discipline the COBOL programmer is completely and visibly lost - whereas without discipline the C programmer might only *seem* not to be lost. Sorry, E.W., but I have to disagree with you on this one.

And finally, a quote *about* Dijkstra:

Arrogance in computer science is measured in nano-Dijkstras
— Alan Kay

Oh, and if you want to know how to pronounce Dijkstra, there’s a really bad recording here (54k, WAV)

Derek