Thanks again for responding. You gave me a lot to think about. It seems like there isn’t much daylight between our positions, and in any case I’m sure nobody else is reading, so I’ll wrap it up here for any future spelunkers.
I think I’m on solid ground asserting that it’s common knowledge that most proofs have errors. The reason is that professional mathematicians tell us so. Here’s Terry Tao: https://terrytao.wordpress.com/advice-on-writing-papers/proo.... Notice how Tao acknowledges that papers “full of errors” are sometimes not corrected before publication. What does that mean for proofs which have only one minor error, and referees less exacting than Terry Tao?
Chapter 7 of Simon Singh’s book on Fermat’s Last Theorem is also illustrative (Singh liberally quotes from his sources directly so there is no question about what the mathematicians thought). After Wiles submitted his manuscript to Inventiones Mathematicae, the referees began finding mistakes almost immediately and were in constant communication with Wiles to get them corrected. Wiles worked on his proof for seven years; nobody thought there was anything wrong with his manuscript having a lot of errors. How probable is it that we found every error in the Wiles proof?
Here’s a good MathOverflow question on the topic: https://mathoverflow.net/questions/338607/why-doesnt-mathema.... Lots of good responses, and links. What stands out to me is that none of the top answers say “that’s just not true.” Instead those answers about why math proofs “work” even though they’re not completely, rigorously, “correct.”
My big point is that in math, some mistakes are trivial, and others are serious. The job of determining which is which is a job for humans — as you point out! — because it’s a topic for conference talks. But in programming, humans don’t decide how serious a mistake is — the computer does, by what it does. Typo in a code comment? No worries. Typo in a variable name? Broken program. If you abbreviate Norway to NOR in your YAML file, that’s cool. Abbreviate it to NO, and there goes your afternoon (because YAML translates NO to false). It’s the capriciousness, not the difficulty, that separates how people learn the two fields.
Debuggers, code review, and testing environments are primarily professional tools — they aren’t used by learners. By the time a learner of programming gets those tools, the damage is already done; they’re already weirdos, conditioned to accept the output of the computer no matter how capricious, and rewrite their code however it takes to get their programs to work, even if it doesn’t “make sense.”
> I'm sure if you even have an example of such not-fixed-error, you have absolutely no idea how it was treated later by the scientific community.
I don’t know what you’re trying to assert. I’m part of the scientific community. Yes, I’ve written code based on proofs that turned out to have flaws, and then I went and updated the code. The most fun one to talk about would be this one from 2006: https://research.google/blog/extra-extra-read-all-about-it-n...
Anyway thanks again for reading. I had a lot of fun writing up these comments & reading what folks and had to say.