3 ms·

This is why I laugh at talk of "bug free" software. The best you can do is zero reported bugs. Temporarily.

by quickthrower2 4y ago

girvo 4y ago
If there are bugs in software but no one ever runs it, does it really have bugs? - George Berkley (apocryphal)
- taneq 4y ago
  Of course! If nobody ever runs software then that is, of course, a bug. ;)
tempodox 4y ago
I don't disagree but a philosophy that I find practical says that a bug that exists in software and is never encountered in actual use counts as a non-bug. Of course it would be nicer if the bug-in-software didn't exist, but what really counts are actual use cases.
- MereInterest 4y ago
  By that reasoning, the software that ran the Therac-25 wasn't buggy when used for earlier models. Those earlier models had hardware interlocks, so the incorrect requests made by software didn't have the same fatal consequences as it did for the Therac-25.
  - tempodox 4y ago
    Indeed, it doesn't account for changing conditions in the software's environment. Doing everything within reason to avoid bugs in the first place is clearly preferable.
- quickthrower2 4y ago
  True. Not all encountered bugs are reported and not all reported bugs are even bugs!
verisimilitudes 4y ago
To the article: It's fine to handle an explicit subset of a problem. What's not fine is not making this clear. Real software can generally have a well-defined domain and range, which this article muddies with its example. > This works but is quitter talk. It's a valid solution. Expressing weird recipes as lists of normal recipes is perfectly fine. > If we want to include recipe expansion as a feature of our model, we need to make the algorithm more complicated to handle the single edge case of fondant. Yes, it turns out writing correct software sometimes requires this, even for a small amount of overall cases. That's no argument against not handling all cases. To the parent poster: I expect someone incapable of writing perfect software to claim it to be impossible, yes. I'd upload an article I've written proving my point, but it's about correct software, so it would just get ignored here. Software is mathematics, and mathematics can be perfect. > This is why I laugh at talk of "bug free" software. The best you can do is zero reported bugs. Temporarily. No, this is the best the incompetent can do, but I won't let them drag me down to their level.

This is why I laugh at talk of "bug free" software. The best you can do is zero reported bugs. Temporarily.

girvo 4y ago

If there are bugs in software but no one ever runs it, does it really have bugs? - George Berkley (apocryphal)

taneq 4y ago
Of course! If nobody ever runs software then that is, of course, a bug. ;)

tempodox 4y ago

I don't disagree but a philosophy that I find practical says that a bug that exists in software and is never encountered in actual use counts as a non-bug. Of course it would be nicer if the bug-in-software didn't exist, but what really counts are actual use cases.

MereInterest 4y ago
By that reasoning, the software that ran the Therac-25 wasn't buggy when used for earlier models. Those earlier models had hardware interlocks, so the incorrect requests made by software didn't have the same fatal consequences as it did for the Therac-25.
- tempodox 4y ago
  Indeed, it doesn't account for changing conditions in the software's environment. Doing everything within reason to avoid bugs in the first place is clearly preferable.
quickthrower2 4y ago
True. Not all encountered bugs are reported and not all reported bugs are even bugs!

verisimilitudes 4y ago

To the article: It's fine to handle an explicit subset of a problem. What's not fine is not making this clear. Real software can generally have a well-defined domain and range, which this article muddies with its example. > This works but is quitter talk. It's a valid solution. Expressing weird recipes as lists of normal recipes is perfectly fine. > If we want to include recipe expansion as a feature of our model, we need to make the algorithm more complicated to handle the single edge case of fondant. Yes, it turns out writing correct software sometimes requires this, even for a small amount of overall cases. That's no argument against not handling all cases. To the parent poster: I expect someone incapable of writing perfect software to claim it to be impossible, yes. I'd upload an article I've written proving my point, but it's about correct software, so it would just get ignored here. Software is mathematics, and mathematics can be perfect. > This is why I laugh at talk of "bug free" software. The best you can do is zero reported bugs. Temporarily. No, this is the best the incompetent can do, but I won't let them drag me down to their level.