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

> 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.
      - User23 4y ago
        > 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. Another possibility is that the field is dominated by coders who are mathematically illiterate and unwilling to remedy that deficiency while hiding behind rhetorical hand waving about the “real world.” You yourself appear to stand as evidence for that explanation. Fortunately we are seeing some real progress in the field. For example tools like TLA+ are slowly but surely getting wider and wider usage. Lamport is very much in the same school of thought as Dijkstra by the way. Even TDD represents a major step toward a more disciplined approach to programming.
- microtherion 4y ago
  Yes, Dijkstra invented the semaphore, but that "solved" synchronization about to the extent that John McCarthy inventing the linked list "solved" data structures (or FAANG hiring, for that matter).
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

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.
    - User23 4y ago
      > 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. Another possibility is that the field is dominated by coders who are mathematically illiterate and unwilling to remedy that deficiency while hiding behind rhetorical hand waving about the “real world.” You yourself appear to stand as evidence for that explanation. Fortunately we are seeing some real progress in the field. For example tools like TLA+ are slowly but surely getting wider and wider usage. Lamport is very much in the same school of thought as Dijkstra by the way. Even TDD represents a major step toward a more disciplined approach to programming.
microtherion 4y ago
Yes, Dijkstra invented the semaphore, but that "solved" synchronization about to the extent that John McCarthy inventing the linked list "solved" data structures (or FAANG hiring, for that matter).

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