If we’re thinking about programming as a way of deeply understanding a problem—or at least as a process which leads to understanding a problem as a necessary step—then we have these errors that don’t reflect a misunderstanding of the problem. They may reflect a misunderstanding of the language, or a typo, which I realize are still map-territory discrepancies (isn’t any mistake?) but have nothing to do with the problem you’re trying to solve.
In a way, I suppose I’m nitpicking. But it also needs to be said because when debugging, you need to be aware of two levels of differences: differences between what the correct solution is and what you think it is, and differences between what the program does and what you think it does.
This comes up a lot when I’m grading mathematical proofs. Sometimes the mistake is a faulty step: for instance, an assumption of something that shouldn’t be assumed, or maybe only a partial solution is found. Sometimes, the mistake is in the presentation: the idea of the proof matches the correct idea, but a key step is unexplained, or a final answer is wrong due to an error in arithmetic. I think it definitely matters which kind of error the students are making.
The big difference between a typo in writing and a typo in code is that in the first case the hardware that does the interpretation transparently covers up the mistake (which is why editing is a hard job, btw). In the second case the consequences can be more severe, are likely to crop up later and inconvenience more people. Code is unforgiving.
As a case study we could consider the latest “bug” to have a noticeable effect on LW. Someone released this code into production believing that it worked, which turned out to be very different from the reality.
If we’re thinking about programming as a way of deeply understanding a problem—or at least as a process which leads to understanding a problem as a necessary step—then we have these errors that don’t reflect a misunderstanding of the problem. They may reflect a misunderstanding of the language, or a typo, which I realize are still map-territory discrepancies (isn’t any mistake?) but have nothing to do with the problem you’re trying to solve.
In a way, I suppose I’m nitpicking. But it also needs to be said because when debugging, you need to be aware of two levels of differences: differences between what the correct solution is and what you think it is, and differences between what the program does and what you think it does.
This comes up a lot when I’m grading mathematical proofs. Sometimes the mistake is a faulty step: for instance, an assumption of something that shouldn’t be assumed, or maybe only a partial solution is found. Sometimes, the mistake is in the presentation: the idea of the proof matches the correct idea, but a key step is unexplained, or a final answer is wrong due to an error in arithmetic. I think it definitely matters which kind of error the students are making.
The big difference between a typo in writing and a typo in code is that in the first case the hardware that does the interpretation transparently covers up the mistake (which is why editing is a hard job, btw). In the second case the consequences can be more severe, are likely to crop up later and inconvenience more people. Code is unforgiving.
As a case study we could consider the latest “bug” to have a noticeable effect on LW. Someone released this code into production believing that it worked, which turned out to be very different from the reality.