4 ms·

Worth reading just to receive the wisdom of this change of perspective - I'm going to stop calling my errors "bugs": We could, for instance, begin with cleanin

by limist 16y ago

Worth reading just to receive the wisdom of this change of perspective - I'm going to stop calling my errors "bugs": We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: 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).

yafujifide 16y ago
> 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).
- loup-vaillant 16y ago
  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.)
- kiujygtyujik 16y ago
  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
  - sqrt17 16y ago
    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.
    - kiujygtyujik 16y ago
      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
  - Twisol 16y ago
    > 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.
- imran 16y ago
  although you are right but i think you are out of context..
  - awakeasleep 16y ago
    It feels like he was looking for a reason to disagree with Dijkstra instead of trying to understand what he wrote.
- hristov 16y ago
  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.
tomjen3 16y ago
You are kidding me right? If we change this, then each time there is a bug in your program your manager gets to blame you, your clients won't pay you until fix what you have done wrong, you might be open to lawsuits, etc, etc. Yeah it might be a lot more honest - but it would be very impractical.
- limist 16y ago
  "I am serious. And don't call me Shirley." :) Firstly, errors can stem from the "client side." Few software specifications are so precise that solutions can be proven complete and correct. So I don't think an honest programmer has to lie about errors; but one would need to regularly educate the "client" that most development is an iterative process of discovery, with everyone learning and saying "Oh but what I really want it to do is x..." Secondly, I've never met a good/great programmer who wasn't honest with himself first. Coding always involves fixing errors (heh, I was about to say "debugging") and by some studies (e.g. as cited in Code Complete), > 99% of code errors are programmer errors (not the OS, not the compiler/interpreter, etc.). I think the transition of internal dialog from "WTF, why is SELECT broken?" to "Hummm, what assumption of mine is wrong?" is vital. Changing one's terminology, even if it's just in the space between your own ears, will help us as programmers improve sooner.

by limist 16y ago

yafujifide 16y ago

> 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).

loup-vaillant 16y ago
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.)
kiujygtyujik 16y ago
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
- sqrt17 16y ago
  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.
  - kiujygtyujik 16y ago
    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
- Twisol 16y ago
  > 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.
imran 16y ago
although you are right but i think you are out of context..
- awakeasleep 16y ago
  It feels like he was looking for a reason to disagree with Dijkstra instead of trying to understand what he wrote.
hristov 16y ago
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.

tomjen3 16y ago

You are kidding me right? If we change this, then each time there is a bug in your program your manager gets to blame you, your clients won't pay you until fix what you have done wrong, you might be open to lawsuits, etc, etc. Yeah it might be a lot more honest - but it would be very impractical.

limist 16y ago
"I am serious. And don't call me Shirley." :) Firstly, errors can stem from the "client side." Few software specifications are so precise that solutions can be proven complete and correct. So I don't think an honest programmer has to lie about errors; but one would need to regularly educate the "client" that most development is an iterative process of discovery, with everyone learning and saying "Oh but what I really want it to do is x..." Secondly, I've never met a good/great programmer who wasn't honest with himself first. Coding always involves fixing errors (heh, I was about to say "debugging") and by some studies (e.g. as cited in Code Complete), > 99% of code errors are programmer errors (not the OS, not the compiler/interpreter, etc.). I think the transition of internal dialog from "WTF, why is SELECT broken?" to "Hummm, what assumption of mine is wrong?" is vital. Changing one's terminology, even if it's just in the space between your own ears, will help us as programmers improve sooner.