Hewlett-Packard, in their glory days, had an internal policy to apply the term "defect" to both hardware and software. If it has defects, it may not be shipped.
Also, I don't understand the reasoning for why we shouldn't anthropomorphize programs. I read the digression about two and a half times, but I can't connect the chessboard/domino tiling problem to a reason we shouldn't consider software's behavior.
> A programming language, with its formal syntax and with the proof rules that define its semantics, is a formal system for which program execution provides only a model. It is well-known that formal systems should be dealt with in their own right, and not in terms of a specific model. And, again, the corollary is that we should reason about programs without even mentioning their possible "behaviours".
Perhaps this is another aspect of the "SWE vs. CS" debate but I've come to the conclusion that in SWE, it makes more sense to reason about entities and how they behave (deliberate use of the word) rather than in terms of every single line of code. Said another way, anthropomorphizing programs is another means of abstraction and SWEs and CSs alike should be comfortable going up and down the abstraction ladder as needed. Even in academia, outside your first two programming classes or so, outside algorithms, it is rare to spend time in the realm of "formal syntax and proof rules". (Or maybe this is simply a difference of the needs of CS education today and during Djikstra's time.)
But why should we encourage reasoning in this manner? I have many reasons but the bluntest (yet holds no less water) one is because I think Djikstra's statement assumes you have access to the readable source code. That's simply not true. So it's more useful to reason about computing units as entities with "behaviors".
I have no idea whether story is true. But, at Dijkstra time, he probably associated "bug" with above story - the error was not human mistake, humans were innocent, it was just bad luck that rarely happens. We are now 40 years later and associations are completely different.
But in this case, none of these are design or implementation mistakes. We just call those bugs, though maybe there is an official term like defect for them.
Basically the metaphor is an opiate. It feels good to think about, because turns an intractable problem into one that is intuitive. But it doesn’t actually solve the problem - only considering the logic does.
> [..] way too big to test every possible code path
He disregards tests. Most are futile. Maybe automated testing could make some sense (fuzzing, quickcheck, etc), but still, most are stupidly weak and offer no guarantee whatsoever (even quantitatively).
> I'd rather have an OS with a few bugs than no OS at all.
He specifically argues for error instead of bug so that we can't say it's "almost correct" but only that it is "wrong". "a few bugs" is just "wrong".
Yes, but if there is a known defect in your software, do you release or not?
To me, there is a difference between knowingly releasing faulty software or only after release discovering faults in the software. Unless there is no reasonable quality check in the software development and release procedures, because then you are not doing much better than knowingly releasing faulty software.
The original point was that bug is euphemism for error. In 99.99% of cases, errors are not caused by insects.
Dijsktra basically wanted to take step back on that treadmill and use proper word.
"Defects" are a deficiency in the project. They come about through a failure of process. We have to fix them, and fix the failure of process that resulted in them.
"Bugs" are anomalous behavior that get in from outside. A defect in a dependency or external service can cause a bug in my project. We have to fix them, which may require fixing the dependency, working around the bug, or ejecting the dependency completely (I like to call this "deprecated due to infestation").
"Glitches" are anomalous behavior outside of the specification of the system. Example: a user whose cable splitter outside is dangling from a single strand of wire, preventing them from having a reliable enough network connection to use our telecomms system. We might not be able to do anything about glitches other than improve user training.
And finally, "User Error" is a myth.
I find being able to evaluate and define issues by this criteria is really helpful in figuring out the best course of action to take with them. For example, when I realized I was spending the majority of my time working around Bugs caused by Defects in Unity3D, I knew it was time to eject Unity3D. It's kinda like Unity3D had bedbugs, and those bedbugs gave us unsightly sores. It was better to burn the bed completely than be constantly applying bandaids to the sores.