4 ms·

After more than 50 years, programmers of all skill levels still make the same mistakes. I wouldn't bet any of this stuff will become mainstream in 10 years. The

After more than 50 years, programmers of all skill levels still make the same mistakes. I wouldn't bet any of this stuff will become mainstream in 10 years. The tech has to mature to a level where it's as easy to create an ironclad function as it is to make something in Scratch.

082349872349872 4y ago
People who think we've made serious qualitative advances in debugging would do well to reread H.H. Goldstine's and J. von Neumann's thoughts on the topic from 1947. What we have done well is to quantitatively scale so that we're applying the classical debugging techniques to Big Balls of Mud, and not just a few lines of assembly. (the record among my colleagues was writing, then fixing, 3 bugs in a single line of assembly)
- ben_w 4y ago
  > reread H.H. Goldstine's and J. von Neumann's thoughts on the topic from 1947. Do you have a link? Searching only gave me irrelevant results.
  - 082349872349872 4y ago
    IIRC it was https://www.sothebys.com/en/auctions/ecatalogue/2018/the-library-of-erwin-tomash-l18409/lot.937.html https://www.sothebys.com/en/auctions/ecatalogue/2018/the-lib... (or at least in that series) and finding a samizdat'ed scan took a good deal of work (and maybe even some поиск'ing). Best I can do at the moment is to recommend searching from http://www.cs.tau.ac.il/~nachumd/term/EarlyProof.pdf http://www.cs.tau.ac.il/~nachumd/term/EarlyProof.pdf which was one of the papers I passed on the way... (IIRC Goldstine and von Neumann has diagrams resembling Figure 2; I don't recall if Figure A had been anticipated or not — remember all these people had been attending the same conferences, so it's very likely) Basically, back in the rosy-fingered dawn of electronic computation, they already had in mind "know what your state should look like at all points, so you can binary chop to find what control flow first made it go wonky". (a question I have not investigated: how well developed were debugging techniques in the card computing era? I've read horror stories of Los Alamos computations being corrected on-the-fly, with "new code" cards on a different coloured stock being run at the same time through machines that were still busy processing "old code" cards on normal coloured stock. And in terms of "know what your state should look like", card machines did have facilities to abort jobs if the input card deck should fail simple sanity check logic, implying that's been a thing since, probably, Hollerith ca. 1890.) [Edit: I'll have to dig it out of my library, but an old book my spouse got me on Naval computation, from back when "computer" was a job title, not an object, talks about how to organise jobs that would take a week or two to run. I'm sure they had plenty of double-checking going on to make sure a slipup on Wednesday wouldn't result in complete garbage by the following Monday.]
    - ben_w 4y ago
      Thanks, interesting link and also interesting commentary on your part.
  - ngneer 4y ago
    https://ieeexplore.ieee.org/document/194051 https://ieeexplore.ieee.org/document/194051
ben_w 4y ago
50 years ago some of the mistakes was "I forgot to label my punched cards and now they're in the wrong order", or "we have a new computer and we now have to rewrite everything from scratch, because C has only just been invented 6 months ago and the book about it hasn't reached our physical library yet so of course we didn't use that for the previous version". Conversely, one of the problems I had in a previous place was the code being unclear because another developer kept all the obsolete code in the code base "for reference", and also put 1000 lines inside a single if clause, and duplicated class files because he didn't want to change some private: access modifiers to public:. Those kinds of problems weren't possible on such limited hardware and languages.
- pwinnski 4y ago
  Putting functions in the wrong place is still a thing. Having to refactor or rewrite things because of decisions made at an executive level is still a thing. Over-complicating code has always been a thing, too. Admittedly, "Information Hiding" has only really been a thing since Parnas, but I think it's more true than not that most developers are making the same categories of mistakes developers have always made, and when new programming languages and paradigms are created specifically to avoid those errors, they bring with them new categories of errors. Syntactically, the majority of code today looks completely different from 50-year-old code, of course. But I'm not sure things have really changed all that much on the human side.

082349872349872 4y ago

People who think we've made serious qualitative advances in debugging would do well to reread H.H. Goldstine's and J. von Neumann's thoughts on the topic from 1947. What we have done well is to quantitatively scale so that we're applying the classical debugging techniques to Big Balls of Mud, and not just a few lines of assembly. (the record among my colleagues was writing, then fixing, 3 bugs in a single line of assembly)

ben_w 4y ago
> reread H.H. Goldstine's and J. von Neumann's thoughts on the topic from 1947. Do you have a link? Searching only gave me irrelevant results.
- 082349872349872 4y ago
  IIRC it was https://www.sothebys.com/en/auctions/ecatalogue/2018/the-library-of-erwin-tomash-l18409/lot.937.html https://www.sothebys.com/en/auctions/ecatalogue/2018/the-lib... (or at least in that series) and finding a samizdat'ed scan took a good deal of work (and maybe even some поиск'ing). Best I can do at the moment is to recommend searching from http://www.cs.tau.ac.il/~nachumd/term/EarlyProof.pdf http://www.cs.tau.ac.il/~nachumd/term/EarlyProof.pdf which was one of the papers I passed on the way... (IIRC Goldstine and von Neumann has diagrams resembling Figure 2; I don't recall if Figure A had been anticipated or not — remember all these people had been attending the same conferences, so it's very likely) Basically, back in the rosy-fingered dawn of electronic computation, they already had in mind "know what your state should look like at all points, so you can binary chop to find what control flow first made it go wonky". (a question I have not investigated: how well developed were debugging techniques in the card computing era? I've read horror stories of Los Alamos computations being corrected on-the-fly, with "new code" cards on a different coloured stock being run at the same time through machines that were still busy processing "old code" cards on normal coloured stock. And in terms of "know what your state should look like", card machines did have facilities to abort jobs if the input card deck should fail simple sanity check logic, implying that's been a thing since, probably, Hollerith ca. 1890.) [Edit: I'll have to dig it out of my library, but an old book my spouse got me on Naval computation, from back when "computer" was a job title, not an object, talks about how to organise jobs that would take a week or two to run. I'm sure they had plenty of double-checking going on to make sure a slipup on Wednesday wouldn't result in complete garbage by the following Monday.]
  - ben_w 4y ago
    Thanks, interesting link and also interesting commentary on your part.
- ngneer 4y ago
  https://ieeexplore.ieee.org/document/194051 https://ieeexplore.ieee.org/document/194051

ben_w 4y ago

50 years ago some of the mistakes was "I forgot to label my punched cards and now they're in the wrong order", or "we have a new computer and we now have to rewrite everything from scratch, because C has only just been invented 6 months ago and the book about it hasn't reached our physical library yet so of course we didn't use that for the previous version". Conversely, one of the problems I had in a previous place was the code being unclear because another developer kept all the obsolete code in the code base "for reference", and also put 1000 lines inside a single if clause, and duplicated class files because he didn't want to change some private: access modifiers to public:. Those kinds of problems weren't possible on such limited hardware and languages.

pwinnski 4y ago
Putting functions in the wrong place is still a thing. Having to refactor or rewrite things because of decisions made at an executive level is still a thing. Over-complicating code has always been a thing, too. Admittedly, "Information Hiding" has only really been a thing since Parnas, but I think it's more true than not that most developers are making the same categories of mistakes developers have always made, and when new programming languages and paradigms are created specifically to avoid those errors, they bring with them new categories of errors. Syntactically, the majority of code today looks completely different from 50-year-old code, of course. But I'm not sure things have really changed all that much on the human side.