5 ms·

> I have taken extensive experiments with CS faculty members from all over the world, and the vast majority of them —I mean about 95 % of them— cannot program a

by User23 4y ago

> I have taken extensive experiments with CS faculty members from all over the world, and the vast majority of them —I mean about 95 % of them— cannot program a Binary Search. Knuth’s the Art of Computer Programming volume 3 has some more on this. Off the top of my head he writes that it took something like a decade from the first published binary search to the first correct for all inputs version. This is a bar that you would expect a professor to be able to jump over, but it goes to show that sometimes a simple sounding algorithm can be exceedingly tricky to get right. In my experience some kind of Hoare triple derived methodology with invariants is the only reliable way to code a correct binary search from scratch, as opposed to simply having memorized a solution. Here[1] is what at a glance appears to be a readable and correct example of how one might do that. [1] https://zhu45.org/posts/2018/Jan/12/how-to-write-binary-search-correctly/ https://zhu45.org/posts/2018/Jan/12/how-to-write-binary-sear...

ly3xqhl8g9 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. 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.

by User23 4y ago

ly3xqhl8g9 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. 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.