> while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).
So almost every program is "wrong" then. This is pretty pessimistic. Every glass is empty unless it is 100% full.
I think the better approach is just to not fool ourselves. If a large application works, but has a few bugs, then it's OK to say that it's 90% working (or 10% broken--have your pick).
If you can say that an application is 90% working, then you can probably divide it into at least two cleanly separated parts: one that works, and one that is erroneous. So, the more correct way to state this would be that x% of your program works. (Unfortunately for you, x may be much lower than 90. Think edge cases.)
This is related to Dijkstra's suggested style of programming. He suggested, or in fact insisted that the proper way to program is to create along with each program mathematical proofs that the program will behave as expected under each possible combination of inputs. This is something that might conceivably result in bug free programs.
Needless to say this style was not adopted, and in fact a very very different style that practically guarantees a lot of bugs was used.
So the expectation that programs be perfect seems impossible now, but it was not for Dijkstra considering the style of coding he had in mind.
Comments
> while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).
So almost every program is "wrong" then. This is pretty pessimistic. Every glass is empty unless it is 100% full.
I think the better approach is just to not fool ourselves. If a large application works, but has a few bugs, then it's OK to say that it's 90% working (or 10% broken--have your pick).
Thats the difference between maths and engineering.
A proof that has a single exception is wrong, a brige that stays up with a broken rivet is correct
A bridge that depends on all rivets being perfect is a bad thing. A proof that no longer holds outside of its domain of application is still useful.
The trick is to recognize when you need one and when you'd rather use the other.
Same in software - an application that fills a business purpose but has bugs or "errors" is correct.
An error free perfect piece of software hat doesn't is useless
> A proof that has a single exception is wrong, a brige that stays up with a broken rivet is correct
I really like how the mathematical part of that phrase is literal, and the programming part is metaphorical.
If you can say that an application is 90% working, then you can probably divide it into at least two cleanly separated parts: one that works, and one that is erroneous. So, the more correct way to state this would be that x% of your program works. (Unfortunately for you, x may be much lower than 90. Think edge cases.)
This is related to Dijkstra's suggested style of programming. He suggested, or in fact insisted that the proper way to program is to create along with each program mathematical proofs that the program will behave as expected under each possible combination of inputs. This is something that might conceivably result in bug free programs.
Needless to say this style was not adopted, and in fact a very very different style that practically guarantees a lot of bugs was used.
So the expectation that programs be perfect seems impossible now, but it was not for Dijkstra considering the style of coding he had in mind.
although you are right but i think you are out of context..
It feels like he was looking for a reason to disagree with Dijkstra instead of trying to understand what he wrote.