5 ms·

For Dijkstra programming meant to think about a problem, then sit for a few minutes at your desk and write with pen on paper "in one go" the perfect algorithm/p

For Dijkstra programming meant to think about a problem, then sit for a few minutes at your desk and write with pen on paper "in one go" the perfect algorithm/program, no bugs, no errors, no corrections, from the first try, and also, in beautiful handwriting. Some kind of idealized way in which Mozart would allegedly write his compositions. Whereas "Beethoven was a doubter and a struggler who started writing before he finished the composition and then glued corrections on the paper. In one place he did this nine times. When they peeled them, the last version proved identical to the first one. This iterative method of programming is somehow a very Anglo-Saxon custom. British education is pervaded by it. People learn, when they write, not to try to get it right the first time. Just write what's on your mind and then rewrite repeatedly to get the product you want. That's partly why word processors are marketed so aggressively and partly why they have been so successful there." [1] [1] Edsger Dijkstra interview, https://youtu.be/mLEOZO1GwVc?t=282 https://youtu.be/mLEOZO1GwVc?t=282

microtherion 4y ago
> For Dijkstra programming meant to think about a problem, then sit for a few minutes at your desk and write with pen on paper "in one go" the perfect algorithm/program, no bugs, no errors, no corrections, from the first try, and also, in beautiful handwriting. An approach that works best if you get to pick your own, narrowly defined problems, and do not deal with externally imposed, let alone changing, requirements. It utterly does not scale. I'm not entirely sure when the last time was that Dijkstra actually typed a line of code into a computer (or punched it into a card, as the case may have been), but it appears to have been around the early 1970s. So, like the Pope's pronunciations on sex, Dijkstra's pronunciations on programming derive a lot of their clearcut purity by coming from a non-practitioner.
- ly3xqhl8g9 4y ago
  Well, don't tell me, tell Dijkstra. I commit after every few lines, just on that he would think I am an absolute moron, not to be allowed near keyboards.
- User23 4y ago
  Interestingly enough Dijkstra anticipated your response and for me at least adequately refuted it in some of his other EWDs. Are you aware that among the “narrowly defined problems, and do not deal with externally imposed, let alone changing, requirements” that Dijkstra solved are such doozies as distributed consensus, synchronization, and OS level hardware interrupt handling?
  - lmm 4y ago
    And so these are now no longer problems? Or do they remain thorny matters in practice, precisely because the versions that Djikstra solved are narrowly defined and without awkward external requirements?
    - User23 4y ago
      Good software engineering largely rests on taking whatever "awkward external requirements" you're dealing with and decomposing them by concerns until you have a set of "narrowly defined" problems that you can effectively reason about, formally or informally. Dijkstra was a master of that kind of decomposition and that's how he got the interesting "theoretical" problems he solved: they came up in the course of breaking down practical problems! The point then is that with the concerns having been adequately separated, rigorous, disciplined, and mathematical reasoning is a better approach to thorny "real-world" problems than spitballing and hoping it works.
      - lmm 4y ago
        > Good software engineering largely rests on taking whatever "awkward external requirements" you're dealing with and decomposing them by concerns until you have a set of "narrowly defined" problems that you can effectively reason about, formally or informally. Dijkstra was a master of that kind of decomposition and that's how he got the interesting "theoretical" problems he solved: they came up in the course of breaking down practical problems! Every good software engineer breaks down the problems they have to solve, and usually you find that they're, say, 20% interesting theoretical problem and 80% messy practical drudgery. Unfortunately most of us don't have the luxury of choosing to only solve the nice 20%. > The point then is that with the concerns having been adequately separated, rigorous, disciplined, and mathematical reasoning is a better approach to thorny "real-world" problems than spitballing and hoping it works. What's the evidence for this? Because if Djikstra published a paper "solving" the problem, but the problem was not actually solved in the real world, that to me suggests that his approach is decidedly ineffective.
- varjag 4y ago
  It takes certain optimistic outlook to imply one is assuredly better at computer programming than Dijkstra.
- rramadass 4y ago
  While i am not one to condone Hagiography, your comment is pure Hubris. If you think solving problems by constant trial-and-error is the norm and Dijkstra's idealized mathematically disciplined systematic approach methods can well be ignored, then i fear you have not understood the difference between Science, Engineering and Craftsmanship/Tradesmanship (without formal training). >I'm not entirely sure when the last time was that Dijkstra actually typed a line of code into a computer ... coming from a non-practitioner. This is laughable. By this logic every code monkey today (including myself) is better than Dijkstra because we simply have written a larger volume of code and that too in many different languages! One needs to practice Humility when approaching the Words/Works of Masters and try to understand them instead of being dismissive. I keep the following quote by Arthur Conan Doyle from the novel The Valley of Fear in mind when studying the Greats; Mediocrity knows nothing higher than itself, but Talent instantly recognizes Genius. You might find the following two papers relevant : 1) This paper gives a retrospective on a earlier seminal paper by the author himself (what he got wrong and what he got right) : Retrospective: An Axiomatic Basis For Computer Programming by C.A.R. Hoare - https://cacm.acm.org/magazines/2009/10/42360-retrospective-an-axiomatic-basis-for-computer-programming/fulltext?mobile=false https://cacm.acm.org/magazines/2009/10/42360-retrospective-a... 2) A Rational Design Process: How and Why to Fake it by D. L. Parnas (pdf) - https://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
  - User23 4y ago
    > Dijkstra's idealized mathematically disciplined systematic approach This is what impresses me the most about Dijkstra's accomplishments. It's not that he was extremely smart, although he was. Or that he discovered many fundamentally important algorithms, although he did. It's that he chose to develop and share how he did what he did. It's that you can read through one of his papers and it makes you feel like you could have applied his methods and made the same discovery. Of course that's not necessarily true, but that it's even sometimes true is remarkable. And speaking of his papers, the EWD archive the submission is from is an absolute treasure-trove. While I'd recommend one of his books for someone interested in learning the methods he and his colleagues used, the more technical EWDs are very interesting. I personally enjoy the more polemical ones too, but I understand why many people are put off by them. Whenever someone gets around to writing the comprehensive multi-volume history of the development of Comput(er|ing) Science they will be an invaluable resource. Here's just one that I find notable[1]. [1] https://www.cs.utexas.edu/users/EWD/ewd06xx/EWD600.PDF https://www.cs.utexas.edu/users/EWD/ewd06xx/EWD600.PDF

microtherion 4y ago

> For Dijkstra programming meant to think about a problem, then sit for a few minutes at your desk and write with pen on paper "in one go" the perfect algorithm/program, no bugs, no errors, no corrections, from the first try, and also, in beautiful handwriting. An approach that works best if you get to pick your own, narrowly defined problems, and do not deal with externally imposed, let alone changing, requirements. It utterly does not scale. I'm not entirely sure when the last time was that Dijkstra actually typed a line of code into a computer (or punched it into a card, as the case may have been), but it appears to have been around the early 1970s. So, like the Pope's pronunciations on sex, Dijkstra's pronunciations on programming derive a lot of their clearcut purity by coming from a non-practitioner.

ly3xqhl8g9 4y ago
Well, don't tell me, tell Dijkstra. I commit after every few lines, just on that he would think I am an absolute moron, not to be allowed near keyboards.
User23 4y ago
Interestingly enough Dijkstra anticipated your response and for me at least adequately refuted it in some of his other EWDs. Are you aware that among the “narrowly defined problems, and do not deal with externally imposed, let alone changing, requirements” that Dijkstra solved are such doozies as distributed consensus, synchronization, and OS level hardware interrupt handling?
- lmm 4y ago
  And so these are now no longer problems? Or do they remain thorny matters in practice, precisely because the versions that Djikstra solved are narrowly defined and without awkward external requirements?
  - User23 4y ago
    Good software engineering largely rests on taking whatever "awkward external requirements" you're dealing with and decomposing them by concerns until you have a set of "narrowly defined" problems that you can effectively reason about, formally or informally. Dijkstra was a master of that kind of decomposition and that's how he got the interesting "theoretical" problems he solved: they came up in the course of breaking down practical problems! The point then is that with the concerns having been adequately separated, rigorous, disciplined, and mathematical reasoning is a better approach to thorny "real-world" problems than spitballing and hoping it works.
    - lmm 4y ago
      > Good software engineering largely rests on taking whatever "awkward external requirements" you're dealing with and decomposing them by concerns until you have a set of "narrowly defined" problems that you can effectively reason about, formally or informally. Dijkstra was a master of that kind of decomposition and that's how he got the interesting "theoretical" problems he solved: they came up in the course of breaking down practical problems! Every good software engineer breaks down the problems they have to solve, and usually you find that they're, say, 20% interesting theoretical problem and 80% messy practical drudgery. Unfortunately most of us don't have the luxury of choosing to only solve the nice 20%. > The point then is that with the concerns having been adequately separated, rigorous, disciplined, and mathematical reasoning is a better approach to thorny "real-world" problems than spitballing and hoping it works. What's the evidence for this? Because if Djikstra published a paper "solving" the problem, but the problem was not actually solved in the real world, that to me suggests that his approach is decidedly ineffective.
varjag 4y ago
It takes certain optimistic outlook to imply one is assuredly better at computer programming than Dijkstra.
rramadass 4y ago
While i am not one to condone Hagiography, your comment is pure Hubris. If you think solving problems by constant trial-and-error is the norm and Dijkstra's idealized mathematically disciplined systematic approach methods can well be ignored, then i fear you have not understood the difference between Science, Engineering and Craftsmanship/Tradesmanship (without formal training). >I'm not entirely sure when the last time was that Dijkstra actually typed a line of code into a computer ... coming from a non-practitioner. This is laughable. By this logic every code monkey today (including myself) is better than Dijkstra because we simply have written a larger volume of code and that too in many different languages! One needs to practice Humility when approaching the Words/Works of Masters and try to understand them instead of being dismissive. I keep the following quote by Arthur Conan Doyle from the novel The Valley of Fear in mind when studying the Greats; Mediocrity knows nothing higher than itself, but Talent instantly recognizes Genius. You might find the following two papers relevant : 1) This paper gives a retrospective on a earlier seminal paper by the author himself (what he got wrong and what he got right) : Retrospective: An Axiomatic Basis For Computer Programming by C.A.R. Hoare - https://cacm.acm.org/magazines/2009/10/42360-retrospective-an-axiomatic-basis-for-computer-programming/fulltext?mobile=false https://cacm.acm.org/magazines/2009/10/42360-retrospective-a... 2) A Rational Design Process: How and Why to Fake it by D. L. Parnas (pdf) - https://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
- User23 4y ago
  > Dijkstra's idealized mathematically disciplined systematic approach This is what impresses me the most about Dijkstra's accomplishments. It's not that he was extremely smart, although he was. Or that he discovered many fundamentally important algorithms, although he did. It's that he chose to develop and share how he did what he did. It's that you can read through one of his papers and it makes you feel like you could have applied his methods and made the same discovery. Of course that's not necessarily true, but that it's even sometimes true is remarkable. And speaking of his papers, the EWD archive the submission is from is an absolute treasure-trove. While I'd recommend one of his books for someone interested in learning the methods he and his colleagues used, the more technical EWDs are very interesting. I personally enjoy the more polemical ones too, but I understand why many people are put off by them. Whenever someone gets around to writing the comprehensive multi-volume history of the development of Comput(er|ing) Science they will be an invaluable resource. Here's just one that I find notable[1]. [1] https://www.cs.utexas.edu/users/EWD/ewd06xx/EWD600.PDF https://www.cs.utexas.edu/users/EWD/ewd06xx/EWD600.PDF