Whenever somebody says something, one has to consider their Competency, Context and Time to read between the lines and try and get at the gist of what is being intended rather then the mere words themselves.
This is orders of magnitude more important when we try to understand "The Greats" (in any field) because they have a certain insight into things, a huge knowledge base to draw upon and are aware of myriads of nuances involved in their domain of expertise all of which we poor students have to struggle to grasp.
It is with the above points in mind that one should interpret Knuth's nuanced quote above. He had the highest of regards/respect for Dijkstra (see his detailed review (pdf) of Dijkstra's book "Structured Programming" at http://infolab.stanford.edu/pub/cstr/reports/cs/tr/73/371/CS...) Given that Donald Knuth is the "Patron Saint of Yak Shaves" (https://yakshav.es/the-patron-saint-of-yakshaves/) his perspective did not allow a fully mathematical abstraction without any reference to a machine (real or virtual). Note that he did not deny Dijkstra's approach but merely wasn't agreeing with Dijkstra's strident promotion of it. That is a viewpoint and not a value judgement.
Coming back to the points above;
[1-3] - One has to remember that when Dijkstra did these almost nothing that we take for granted today existed. Everything had to be built from ground-up. You can imagine the difficulty when you have nothing/nobody to learn from and are basically inventing stuff as you go along. You only had Mathematics as a stable bedrock.
[4] No, he pioneered it. Wikipedia actually credits him with coining the very term "Structured Programming" (https://en.wikipedia.org/wiki/Structured_programming#cite_no...) Regardless, he wrote EWD249 "Notes on Structured Programming" in 1969. Also see EWD1308 "What led to Notes on Structured Programming".
[5] Most people misunderstand what is meant by "Correctness" in a Computer Program. Perhaps Bertrand Meyer's synonym of a "Contract" is better suited to explain that what is meant is "Correctness w.r.t. Specification". Obviously this is fundamental to Programming itself. To get the benefit of this approach you don't have to go 100% rigour (rather difficult) but train yourself to think in these terms and using appropriate pre/post conditions. A good example can be seen in the use of Design-by-Contract syntax in Eiffel. Here is Dijkstra from EWD288 "Concern for Correctness as a Guiding Principle for Program Composition"
My thesis is, that a helpful programming methodology should be closely tied to correctness concerns. I am perfectly willing to admit that I myself may be the most complete victim of my own propaganda, but that will not prevent me from preaching my gospel, which is as follows. When correctness concerns come as an afterthought and correctness proofs have to be given once the program is already completed, the programmer can indeed expect severe troubles. If, however, he adheres to the discipline to produce the correctness proofs as he programs along, he will produce program and proof with less effort than programming alone would have taken.
Finally, a word or two about a wide-spread superstition, viz. that correctness proofs can only be given if you know exactly what your program has to do, that in real life it is often not completely known what the program has to do and that, therefore, in real life correctness proofs are impractical. The fallacy in this argument is to be found in the confusion between "exact" and "complete": although the program requirements may still be "incomplete", a certain number of broad characteristics will be "exactly" known. The abstract program can see to it that these broad specifications are exactly met, while more detailed aspects of the problem specification are catered for in the lower levels.
[6-7] Your comment "Notably, none of his accomplishments in 1-3 were attained according to the methodology he advocated later in life as the only possible one" is exactly the wrong inference to draw! It is precisely due to this formative experience that he was such a strident proponent of the use of Mathematics in Programming. As pointed out above, he had to invent a lot of this stuff as he went along and had nothing other than mathematical logic to aid him in his endeavour. Dijkstra actually said he was "slow" to understand the works of Floyd/Hoare/Others on Program Correctness techniques. But of course once he got involved, he took it to the next level.
In summary, read Dijkstra, try and get at what he intended to convey rather than the tone/words (which are irrelevant in the broader scheme of things) and put forth effort to understand what has been said/written down. The rewards are great.
> [...] using appropriate pre/post conditions. A good example can be seen in the use of Design-by-Contract syntax in Eiffel.
I agree that these have some promise, but there is a rather wide gap between those and correctness proofs, and I'm not convinced that's a gap generally worth bridging.
> One has to remember that when Dijkstra did these almost nothing that we take for granted today existed
And yet at that time, he was capable of writing an ALGOL 60 compiler in assembly language within a few months. Two decades later, armed with his complete arsenal of program correctness techniques, he spent weeks writing an toy expression parser in a high level language, abandoned his original objective along the way, and ended up with an absolute dog's breakfast of impenetrable prose and code: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/E...
You have now shifted goalposts and are arguing about things different from the ones you started with. There doesn't seem to be anymore to discuss about and so i will end this with the following notes.
Your original contention that Dijkstra had not written much code (thus insinuating that he was mostly "talk") i have proven false. Incidentally, he wrote about 1318 EWDs totaling over 7700 pages in addition to his other books and papers (most of them have some "program pseudo-code")! This is indeed some impressive output.
I had also pointed out that much of his work is at a "meta-level" trying to get at the nature of programming and trying to establish that discipline on a sound mathematical basis. Thus it cannot be compared directly to conventional programing but one has to understand the intent behind his writings and then try to practice them honestly in one's own work. He did not claim that his methods were "easy" only that they were a necessity to write "correct" programs. The degree to which they are necessary and applicable by "ordinary programmers" (i.e. w/o too much mathematical maturity) can be tuned (hence my example of DbC from Eiffel). From Mathematics we all know the difficulty of writing and reading proofs. So your expectation that Dijkstra's usage of it should be easy to grasp is fundamentally wrong. It is the nature of the subject itself that demands effort and there is no getting around it. Incidentally while i am somewhat familiar with Wirth's compiler book (written for students), i have not read EWD550(seems to be written as a challenge response and quite intricate/non-trivial). It seems that they have very different purposes and audiences in mind and so a comparison between them is not fair.
> Your original contention that Dijkstra had not written much code (thus insinuating that he was mostly "talk")
I could have been clearer about this, yes. I know that he was quite skilled at writing code in his younger years. However, he largely seemed to have given up on the practice by the 1970s, and the less he was coding, the more certain he seemed to become how it ought to be done and taught.
> From Mathematics we all know the difficulty of writing and reading proofs. So your expectation that Dijkstra's usage of it should be easy to grasp is fundamentally wrong.
So the supposedly superior methodology is neither easier to use, nor does it produce easier to maintain programs. It's almost like its superiority consists purely of gatekeeping the programming profession to those conversant with the methodology's shibboleths.
> I have not read EWD550
I should have led with that. As far as I know, it's the longest published program to which Dijkstra tried to apply his methodology, so, to me, the clearest evidence that it does not scale.
You now seem to be trying to argue the inarguable and also trying to play "gotcha" games.
To take the latter first, because EWD550 is intricate and unfinished, is it your contention that Dijkstra was wrong about his methodology which he had already demonstrated in other papers and books? This is not an argument but only calls into question one's own current competency and effort put forth to understand what has been written down. I am sure that if one sits down with it for concentrated study for some time that one can understand it. People lose interest in many things that they take up. This is even more true of geniuses since they have so much going on that once they have understood the gist of something they move on and leave the rest as "an exercise for the reader". They are not obligated to spell out everything for "the reader"; whether "The Reader" likes it or not is quite another matter. So to me it seems your inference on EWD550 is wrong.
>So the supposedly superior methodology is neither easier to use, nor does it produce easier to maintain programs. It's almost like its superiority consists purely of gatekeeping the programming profession to those conversant with the methodology's shibboleths.
Again your inference is wrong. The "superiority" lies in "proving correctness w.r.t. specification" and not in "ease of comprehension". There is no gatekeeping or any other malicious intent involved but merely insistence on a methodology. Mathematical Proofs are by definition intricate, tedious and require concentrated study. That is the nature of mathematical logic and there are no shortcuts (the famous example of Russel and Whitehead taking more than 300 pages to prove 1+1=2 comes to mind here). If one wants to follow Dijkstra's method to the letter, then one has to "up one's game". If one doesn't want to do that but get the same benefits (to a certain degree) then use a simpler approach like DbC based on the same principles but much more "user friendly".
To paraphrase a famous quote: "There is no Royal Road to understanding Dijkstra".
This is orders of magnitude more important when we try to understand "The Greats" (in any field) because they have a certain insight into things, a huge knowledge base to draw upon and are aware of myriads of nuances involved in their domain of expertise all of which we poor students have to struggle to grasp.
It is with the above points in mind that one should interpret Knuth's nuanced quote above. He had the highest of regards/respect for Dijkstra (see his detailed review (pdf) of Dijkstra's book "Structured Programming" at http://infolab.stanford.edu/pub/cstr/reports/cs/tr/73/371/CS...) Given that Donald Knuth is the "Patron Saint of Yak Shaves" (https://yakshav.es/the-patron-saint-of-yakshaves/) his perspective did not allow a fully mathematical abstraction without any reference to a machine (real or virtual). Note that he did not deny Dijkstra's approach but merely wasn't agreeing with Dijkstra's strident promotion of it. That is a viewpoint and not a value judgement.
Coming back to the points above;
[1-3] - One has to remember that when Dijkstra did these almost nothing that we take for granted today existed. Everything had to be built from ground-up. You can imagine the difficulty when you have nothing/nobody to learn from and are basically inventing stuff as you go along. You only had Mathematics as a stable bedrock.
[4] No, he pioneered it. Wikipedia actually credits him with coining the very term "Structured Programming" (https://en.wikipedia.org/wiki/Structured_programming#cite_no...) Regardless, he wrote EWD249 "Notes on Structured Programming" in 1969. Also see EWD1308 "What led to Notes on Structured Programming".
[5] Most people misunderstand what is meant by "Correctness" in a Computer Program. Perhaps Bertrand Meyer's synonym of a "Contract" is better suited to explain that what is meant is "Correctness w.r.t. Specification". Obviously this is fundamental to Programming itself. To get the benefit of this approach you don't have to go 100% rigour (rather difficult) but train yourself to think in these terms and using appropriate pre/post conditions. A good example can be seen in the use of Design-by-Contract syntax in Eiffel. Here is Dijkstra from EWD288 "Concern for Correctness as a Guiding Principle for Program Composition"
My thesis is, that a helpful programming methodology should be closely tied to correctness concerns. I am perfectly willing to admit that I myself may be the most complete victim of my own propaganda, but that will not prevent me from preaching my gospel, which is as follows. When correctness concerns come as an afterthought and correctness proofs have to be given once the program is already completed, the programmer can indeed expect severe troubles. If, however, he adheres to the discipline to produce the correctness proofs as he programs along, he will produce program and proof with less effort than programming alone would have taken.
Finally, a word or two about a wide-spread superstition, viz. that correctness proofs can only be given if you know exactly what your program has to do, that in real life it is often not completely known what the program has to do and that, therefore, in real life correctness proofs are impractical. The fallacy in this argument is to be found in the confusion between "exact" and "complete": although the program requirements may still be "incomplete", a certain number of broad characteristics will be "exactly" known. The abstract program can see to it that these broad specifications are exactly met, while more detailed aspects of the problem specification are catered for in the lower levels.
[6-7] Your comment "Notably, none of his accomplishments in 1-3 were attained according to the methodology he advocated later in life as the only possible one" is exactly the wrong inference to draw! It is precisely due to this formative experience that he was such a strident proponent of the use of Mathematics in Programming. As pointed out above, he had to invent a lot of this stuff as he went along and had nothing other than mathematical logic to aid him in his endeavour. Dijkstra actually said he was "slow" to understand the works of Floyd/Hoare/Others on Program Correctness techniques. But of course once he got involved, he took it to the next level.
In summary, read Dijkstra, try and get at what he intended to convey rather than the tone/words (which are irrelevant in the broader scheme of things) and put forth effort to understand what has been said/written down. The rewards are great.