If read in its proper context, instead of misinterpreting it by thinking it's talking about concerns people have today, wasn't Dijkstra in favour of a very aggressive use of <i>formal methods</i> in programming? This is something quite different to what modern programmers or "computer scientists" are used to. I have a feeling that people don't really understand what Dijkstra was advocating.<p>His advocacy could be considered quite extreme. He apparently suggested (I don't know whether jokingly or not) that programmers not <i>test</i> their code, and instead write it on paper with various kinds of mathematical correctness proofs, and only then type it on a computer. It's admittedly thought provoking but I have an uncomfortable feeling that some naive people might have followed his advice very literally, and off a cliff.<p>Generally, I think people should read writing from decades ago in its proper context.
<i>Not getting lost in the complexities of our own making and preferably reaching that goal by learning how to avoid the introduction of those complexities in the first place, that is the key challenge computing science has to meet.<p>Nowadays machines are so fast and stores are so huge that in a very true sense the computations we can evoke defy our imagination. Machine capacities now give us room galore for making a mess of it</i><p>If only Dijkstra was around today... those thoughts were extremely prescient. I've seen far more overly complex and abstracted code than "too simple" code.
E.W.Dijkstra was and will always be right;<p><i>Electronic engineering can contribute no more than the machinery, and that the general purpose computer is no more than a handy device for implementing any thinkable mechanism without changing a single wire. That being so, the key question is what mechanisms we can think of without getting lost in the complexities of our own making. Not getting lost in the complexities of our own making and preferably reaching that goal by learning how to avoid the introduction of those complexities in the first place, that is the key challenge computing science has to meet.</i> --- The important distinction between "Computing Science" and "Computer Science". The former is what we need to focus on.<p><i>Does this overestimation of the usefulness of the gadget hurt computing science? I fear it does. At the one end of the spectrum it discourages the computing scientist from conducting all sorts of notational experiments because "his word-processor won't allow them", at the other end of the spectrum the art-and-science of program design has been overshadowed by the problems of mechanizing program verification. The design of new formalisms, more effective because better geared to our manipulative needs, is neglected because the clumsiness of the current ones is the major motivation for the mechanization of their use.</i> --- The need to focus on better Formal Notations to design "Correctness" into Programs in the first place.
Inspired by EWD I have started translating all my (two) papers in my native language, Greek, and as hand-written manuscripts. It is slow going however because the illuminations take so much time and I keep running out of gold ink.<p>Btw, does anyone know of a good, cheap source of fresh parchment?<p>(:P)
"I recently read a series of articles on the Shuttle on-board software and, though President Reagan has generously offered a teacher a free ride, I tell you I am not available."<p>Well, that passage was painfully prescient, even thought the Challenger disaster was not the result of computer failure, but of rubber o-rings denatured by extreme cold. The poor shuttle software and the primitive hardware on which it ran was consistent with the Rogers Commission's criticism of the shortcomings NASA's organizational culture with its acceptance of poor quality control, planning, and inadequate equipment design.<p><a href="https://www.britannica.com/event/Challenger-disaster" rel="nofollow">https://www.britannica.com/event/Challenger-disaster</a>