tl;dr Programming has been ignored because hardware has a much more visible payoff. The impact of computers and the innovation in hardware will "be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind." That is, the intellectual impact of programming is more significant than the impact made innovation on the hardware side. At least thats what I think what Dijkstra is saying.
Some gems:
Test driven development, 1972.
Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.
For loops have brain damaged us.
Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque. I have run a a little programming experiment with really experienced volunteers, but something quite unintended and quite unexpected turned up. None of my volunteers found the obvious and most elegant solution. Upon closer analysis this turned out to have a common source: their notion of repetition was so tightly connected to the idea of an associated controlled variable to be stepped up, that they were mentally blocked from seeing the obvious. Their solutions were less efficient, needlessly hard to understand, and it took them a very long time to find them.
I came away from that paper with notes to track down exactly the same information. Alas, there does not seem to be a definitive answer. Googling a unique phrase from the relevant text, this seems to be the main discussion:
The "answer" is the classic Dining Philosophers problem, which Dijkstra himself invented to illustrate the issues of concurrent programming. It isn't clear that this is actually what he meant, but it's probably the best we are going to get now that he is gone.
The thing that comes to mind is the C idiom for copying strings:
while(dest++ = src++);
"...their notion of repetition was so tightly connected to the idea of an associated controlled variable to be stepped up, that they were mentally blocked from seeing the obvious."
I'm not sure I agree; aren't dest and src still variables that are being stepped up? Maybe they are not "controlled variables", I don't know what that means. This is a task that is eminently suited to repetition, any loop makes sense. Plus, the article mentions FORTRAN's DO loop (not just for loops incrementing a counter).
I was expecting an example where a loop worked, but a simpler mathematical solution exists without a loop.
Is this example really relevant today? Who cares if you write while(dest++ = src++) or for (int i = 0; i < src.length; i++) { dest[i] = src[i] }; Was he just worried that the number of keywords and programming concepts were to many and made the language to complex? He would loath C++ then... Still, we seem to get by.
I think you're misinterpreting what Dijkstra said and getting it almost backward. His point is that testing is inadequate: only a convincing proof of correctness is sufficient to conclude that software works without error. In his words:
> program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence
But proofs are hard. Therefore he advised that the program and its proofs (he didn't say tests) be created together so that the program could be constructed in such a way as to make the proofs easier.
Some gems:
Test driven development, 1972.
Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.
For loops have brain damaged us.
Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque. I have run a a little programming experiment with really experienced volunteers, but something quite unintended and quite unexpected turned up. None of my volunteers found the obvious and most elegant solution. Upon closer analysis this turned out to have a common source: their notion of repetition was so tightly connected to the idea of an associated controlled variable to be stepped up, that they were mentally blocked from seeing the obvious. Their solutions were less efficient, needlessly hard to understand, and it took them a very long time to find them.