First, a single test cannot possibly suffice to demonstrate the correctness of a method intended to add complex numbers. For example (with apologies for the formatting; apparently WordPress kills leading whitespace):

public class Complex {
public final int real;
public final int imag;
public Complex (int r, int i) {
real = r;
imag = i;
}
public Complex add(Complex c) {
return new Complex(this.real + c.real, 0);
}
}

This implementation is broken, yet it can survive an enormous number of tests (those which use only pure-real values, as well as those which add complex conjugates). A subtler form of breakage is illustrated by:

public Complex add(Complex c) {
short r = (short)(this.real + c.real);
short i = (short)(this.imag + c.imag);
return new Complex(r, i);
}

which works nicely for small enough values, but breaks as soon as sufficiently-large values are introduced.

I think we’d both agree that the flaws above are obvious as soon as one looks at the code (assuming one knows Java, of course ;-). I hope we’d also agree that if one takes a black-box, try-and-see-what-happens approach, it could take a while to find that a problem exists, and even more time to describe the circumstances in which the problem manifests itself.

It is important to remember that Dijkstra was writing in a time where (as one of my collegues put it) “code your brains out and then debug it until it works” was all too common an approach. I believe that reading a representative sample of his work (not just the one or two highly-publicized and controversial pieces) supports the view that Dijkstra was focusing almost entirely on the problems of correct DESIGN. I don’t believe he was oblivious to the rest of the software development process, but I believe that he was working to make demonstrably-correct design the foundation of the rest of the process.

As to black boxes, Dijkstra didn’t advocate of formal mathematical examination of completed designs. Instead, he argued forcefully (perhaps even stridently) in favor of letting the requirements of the proof drive the design decisions. From where I sit, there’s a strong connection to the contemporary practice of test-driven development. While I am aware that there are still significant differences between formal proofs and operational tests, I see a common theme of “let the obligation to verify the end product guide the way it is designed and built”.

Although some of the challenges of computing in the 60s and 70s are not at the top of our list of concerns in 2006, I freely admit that I am inspired and motivated every time I go back and re-consider the visions many of the computing pioneers articulated. In some aspects we’ve come a long way since those days, but in some others we have learned very little.

The extent to which these objects clearly separate the FACT/what from the MEANS/how (AKA interface from implementation, in some OOP approaches) is the extent to which we can replace a flawed component with a correct one, or replace a working component with another that is optimized differently (speed-vs-memory tradeoffs, etc.)

The extent to which these imaginary machines offer more general services, rather than special-cased ones, is the extent to which they are likely to be reusable in solving future problems.

Unfortunaly, most of his paper reflected on the complexity that control statements bring. Even with his “input; manipulation; output;” program model, he could not get away from control statements. He was on the verge of a great discovery 37 years ago. He was going in the right direction all those years ago, but could not see the truth.

Had he used his “input; manipulation; output;” program model and left behind the notion of control statements, we would have quite a different world today. The answers were available back then and this paper proves it. Unfortunately, I believe that Dijkstra could not conceive of the “manipulation” part being anything other than using control statements. This is a serious blow to the computing field.

I say now that this is the turning point in history that “should have been”. Instead, we went down the wrong path. I can say conclusively that we are at least 37 years behind the times as it relates to software development. It is sad to see that he had the answers right before his eyes, but could not see it. However, it is unfair to put responsability on one man. No one else has been able to see the truth since… until now. But it’ll take another 30 years to become accepted even when it is finally revealed.

I think the reason proofs have largely failed is that few customers or managers understand them. The point is not to convince ourselves but rather to convince a boss or a customer, and a working demo is far more convincing. It reminds me of a famous Knuth quote: “”Beware of bugs in the above code; I have only proved it correct, not tried it.”

On the other hand, I am pretty sympathetic towards making a language easy to prove things in; one of the reasons I like Java is that it seems easy to (informally) prove things to myself about some unfamiliar code I’m reading. But the “hip” programmers aren’t into that – the cool thing to do seems to be to come up with increasingly obscure magic incantations in Ruby.