3 ms·

> If you think solving problems by constant trial-and-error is the norm News flash: It is. > Dijkstra's idealized mathematically disciplined systematic approa

> If you think solving problems by constant trial-and-error is the norm News flash: It is. > Dijkstra's idealized mathematically disciplined systematic approach methods can well be ignored I never said that. I think they have their place, and I use them myself in some situations. It's Dijkstra and his acolytes who think iterative approaches can be ignored. > One needs to practice Humility when approaching the Words/Works of Masters and try to understand them instead of being dismissive. I've read a lot of Dijkstra's writings. They are not without merit. But he himself could have done with practicing some humility when engaging with computing as it is actually practiced in the physical world, as opposed to in his mathematical models. Knuth is not any less theoretically sound than Dijkstra. But he engaged with practical computing issues and wrote software that is still in wide use. Wirth is not any less disdainful of commercial computing hype than Dijkstra. But he built actual hardware and software systems. Those are the masters I look up to.

rramadass 4y ago
I don't think you have understood the nature of Dijkstra's work nor the genius behind it. It is different from the genius of Niklaus Wirth (simplicity of OS, Programming Language implementations) or Donald Knuth (efficiency of Algorithm implementations) in that it is at a more "meta level" bringing together the fields of Computation, Languages and Mathematics. I have already pointed out the laughable ridiculousness of your measuring Dijkstra's contributions by the amount of code written. He pioneered, defined and established great many aspects of the Computing Science field when it was still in its infancy. Here is a non-exhaustive list (from https://en.wikipedia.org/wiki/Edsger_W._Dijkstra https://en.wikipedia.org/wiki/Edsger_W._Dijkstra and other sources) 1) He designed/described an ISA/Assembly Language to interface with one of the first Computers ever built (his PhD thesis named "Communication with an Automatic Computer"). 2) He designed/wrote/headed one of the first OS ever written "THE multiprogramming system" - https://en.wikipedia.org/wiki/THE_multiprogramming_system https://en.wikipedia.org/wiki/THE_multiprogramming_system 3) He designed/co-wrote one of the very first Algol 60 compilers named the "Dijkstra-Zonneveld Algol 60 compiler" - https://en.wikipedia.org/wiki/ALGOL_60 https://en.wikipedia.org/wiki/ALGOL_60 4) Instrumental in establishing "Structured Programming" constructs in language design itself which we all take for granted today. 5) Instrumental in establishing Mathematical Rigour to Computer Programming via Mathematical Logic/Predicate Calculus akin to the writing of Mathematical Proofs to show "Correctness by Design and Construction". The importance of this cannot be overstated. 6) Instrumental in establishing aspects of Concurrent Programming (eg. CSP), Synchronization (eg. Mutex, Semaphores) etc. 7) Instrumental in devising several non-trivial algorithms for both "normal" vs. Concurrent programs eg. Shortest-Path, Dining Philosophers etc. As you should now be able to appreciate, Dijkstra did write a lot many "Programs" (in addition to other writings) all of which were path-breaking which few can claim about their own life's work. PS: https://inference-review.com/article/the-man-who-carried-computer-science-on-his-shoulders https://inference-review.com/article/the-man-who-carried-com...
- microtherion 4y ago
  1-3 are from his time as a practitioner in the field. There was an exchange in Knuth's interview in Peter Seibel's "Coders at Work" that I thought really insightful: > Seibel: It seems a lot of the people I've talked to had direct access to a machine when they were starting out. Yet Dijkstra has a paper I'm sure you're familiar with, where he basically says we shouldn't let computer-science science students touch a machine for the first few years of their training; they should spend all their time manipulating symbols. > Knuth: But that's not the way he learned either. He said a lot of really great things and inspirational things, but he's not always right. Neither am I, but my take on it is this: Take a scientist in any field. The scientist gets older and says, "Oh, yes, some of the things that I've been doing have a really great payoff and other things, I'm not using anymore. I'm not going to have my students waste time on the stuff that doesn't make giant steps. I'm not going to talk about low-level stuff at all. These theoretical concepts are really so powerful-that's the whole story. Forget about how I got to this point." > I think that's a fundamental error made by scientists in every field. They don't realize that when you're learning something you've got to see something at all levels. You've got to see the floor before you build the ceiling. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it. (4) He certainly promoted them. I don't think he invented them; I believe the one he was most involved in was guard clauses which he promoted as an alternative to if statements. For better or worse, this never caught on. (5) I think it is, in fact, vastly overstated. Mathematical rigor has its uses in some areas (progress conditions in loops, e.g., and getting binary searches right is vastly easier by applying some mathematical thinking). The kind of "end to end" correctness reasoning he promoted has found only a few adopters (avionics, etc). If you disagree, how many of your last 10 projects have you proven correct? How many of them have found to be defect free so far? 6-7 yes, sure. I'm not denying that he made many important contributions to algorithmic thinking. But that does not translate into expertise into how programming ought to be done. Notably, none of his accomplishments in 1-3 were attained according to the methodology he advocated later in life as the only possible one, nor did he try to reproduce them using that methodology.
  - rramadass 4y ago
    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-TR-73-371.pdf 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/ 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_note-FOOTNOTEDijkstra1968147-3 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.

rramadass 4y ago

I don't think you have understood the nature of Dijkstra's work nor the genius behind it. It is different from the genius of Niklaus Wirth (simplicity of OS, Programming Language implementations) or Donald Knuth (efficiency of Algorithm implementations) in that it is at a more "meta level" bringing together the fields of Computation, Languages and Mathematics. I have already pointed out the laughable ridiculousness of your measuring Dijkstra's contributions by the amount of code written. He pioneered, defined and established great many aspects of the Computing Science field when it was still in its infancy. Here is a non-exhaustive list (from https://en.wikipedia.org/wiki/Edsger_W._Dijkstra https://en.wikipedia.org/wiki/Edsger_W._Dijkstra and other sources) 1) He designed/described an ISA/Assembly Language to interface with one of the first Computers ever built (his PhD thesis named "Communication with an Automatic Computer"). 2) He designed/wrote/headed one of the first OS ever written "THE multiprogramming system" - https://en.wikipedia.org/wiki/THE_multiprogramming_system https://en.wikipedia.org/wiki/THE_multiprogramming_system 3) He designed/co-wrote one of the very first Algol 60 compilers named the "Dijkstra-Zonneveld Algol 60 compiler" - https://en.wikipedia.org/wiki/ALGOL_60 https://en.wikipedia.org/wiki/ALGOL_60 4) Instrumental in establishing "Structured Programming" constructs in language design itself which we all take for granted today. 5) Instrumental in establishing Mathematical Rigour to Computer Programming via Mathematical Logic/Predicate Calculus akin to the writing of Mathematical Proofs to show "Correctness by Design and Construction". The importance of this cannot be overstated. 6) Instrumental in establishing aspects of Concurrent Programming (eg. CSP), Synchronization (eg. Mutex, Semaphores) etc. 7) Instrumental in devising several non-trivial algorithms for both "normal" vs. Concurrent programs eg. Shortest-Path, Dining Philosophers etc. As you should now be able to appreciate, Dijkstra did write a lot many "Programs" (in addition to other writings) all of which were path-breaking which few can claim about their own life's work. PS: https://inference-review.com/article/the-man-who-carried-computer-science-on-his-shoulders https://inference-review.com/article/the-man-who-carried-com...

microtherion 4y ago
1-3 are from his time as a practitioner in the field. There was an exchange in Knuth's interview in Peter Seibel's "Coders at Work" that I thought really insightful: > Seibel: It seems a lot of the people I've talked to had direct access to a machine when they were starting out. Yet Dijkstra has a paper I'm sure you're familiar with, where he basically says we shouldn't let computer-science science students touch a machine for the first few years of their training; they should spend all their time manipulating symbols. > Knuth: But that's not the way he learned either. He said a lot of really great things and inspirational things, but he's not always right. Neither am I, but my take on it is this: Take a scientist in any field. The scientist gets older and says, "Oh, yes, some of the things that I've been doing have a really great payoff and other things, I'm not using anymore. I'm not going to have my students waste time on the stuff that doesn't make giant steps. I'm not going to talk about low-level stuff at all. These theoretical concepts are really so powerful-that's the whole story. Forget about how I got to this point." > I think that's a fundamental error made by scientists in every field. They don't realize that when you're learning something you've got to see something at all levels. You've got to see the floor before you build the ceiling. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it. (4) He certainly promoted them. I don't think he invented them; I believe the one he was most involved in was guard clauses which he promoted as an alternative to if statements. For better or worse, this never caught on. (5) I think it is, in fact, vastly overstated. Mathematical rigor has its uses in some areas (progress conditions in loops, e.g., and getting binary searches right is vastly easier by applying some mathematical thinking). The kind of "end to end" correctness reasoning he promoted has found only a few adopters (avionics, etc). If you disagree, how many of your last 10 projects have you proven correct? How many of them have found to be defect free so far? 6-7 yes, sure. I'm not denying that he made many important contributions to algorithmic thinking. But that does not translate into expertise into how programming ought to be done. Notably, none of his accomplishments in 1-3 were attained according to the methodology he advocated later in life as the only possible one, nor did he try to reproduce them using that methodology.
- rramadass 4y ago
  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-TR-73-371.pdf 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/ 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_note-FOOTNOTEDijkstra1968147-3 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.