3 ms·

> ... and then someone finds a bug in the specification which is provably correctly implemented. As a programmer, if the specification is wrong, it's Not My Fa

> ... and then someone finds a bug in the specification which is provably correctly implemented. As a programmer, if the specification is wrong, it's Not My Fault (tm). If you want me to write specifications, well, pay me to do it! I guarantee dramatically better results than the usual crap. > The machine as a whole isn't provably correct. As a programmer, defects in the machine are Not My Problem (tm). In any case, hardware vendors have a much better track record than software developers at delivering products that meet strict quality standards.

kazinator 11y ago
Unfortunately, even if it's not your fault or problem, there is a fault or problem. We're no longer discussing correctness, but assignment of blame.
- catnaroek 11y ago
  Assignment of blame is important, because it determines what component needs to be fixed to solve the problem. It's all about correctness in the end. As an aside, I want to clarify that I'm not advocating being a bad team player. The point to assigning blame isn't demonizing the developer of the faulty component, or reducing cooperation between developers of different components to the bare minimum. The point is just reducing the cost of fixing the problem.
  - kazinator 11y ago
    Assignment of blame is important, but it is often an opinion. If one program misuses another, usually the fix can be an alteration in either one or both. The used program can be expanded to accept the "misuse" which is actually legitimate but not in the requirements. Or the using program can be altered not to generate the misuse. Sometimes what is fixed is chosen for non-technical reasons, like: the best place to fix it it is in such and such code, but ... it's too widely used to touch / not controlled by our group and we need a fix now / closed source and not getting fixed by the vendor {until next year|EVER} / ...
    - catnaroek 11y ago
      > Assignment of blame is important, but it is often an opinion. When in doubt, ask the specification. If there was no specification, why was any code written at all? > If one program misuses another, usually the fix can be an alteration in either one or both. Actually, there are three possibilities: (0) The used program doesn't comply with its specification. (1) The using program doesn't comply with its specification. (2) The specifications of both programs are mutually inconsistent. In which case, it's a programming mistake to connect both programs. > The used program can be expanded to accept the "misuse" which is actually legitimate but not in the requirements. If it isn't in the specification, it isn't legitimate, period. > Or the using program can be altered not to generate the misuse. Sure.
      - dllthomas 11y ago
        "If it isn't in the specification, it isn't legitimate, period." You have some goal you're trying to achieve, or why was a specification written at all? If you find that the existing specification is not the optimal path to that goal, you may very well want to change the specification. In which case, it's entirely legitimate.
        kazinator 11y ago
        Anyway, requirements, specifications and programs are just multiple representations of the same thing. Ideally, we would just state some requirements and they would execute. So the requirements/specification/program complex exists Just Because. Humans decided they want that: for their amusement, for the sake of supporting some enterprise or solving a problem, or to try to sell to other humans. The complex contains several different representations because that's what it takes to bridge the gap between stating the requirements and making the machine carry them out. A proof is something internal to that complex: that the specification corresponds to the requirements, and that the program implements the specification. If we had just one artifact: a specification that executes, then there would be no concept of proof any more. There is only the question whether the specification that was expressed is the one that was intended in the mind. That equivalence is no more susceptible to proof than, say, the correspondence between the Ceasar salad that the waiter just put on your table (and which you clearly specified) and the idea of whether you actually wanted one, or did you mistakenly say "Ceasar salad" in spite of having wanted a soup. Plus, there is the external question of whether a specification has unintended consequences. That basically amounts to "you say you want that, but maybe you should revise what you want because of these bad things". "You say you want plaintext passwords to be stored for easier recovery, and that can certainly be implemented (provably correctly, too) but consider the following ramifications ..."

kazinator 11y ago

Unfortunately, even if it's not your fault or problem, there is a fault or problem. We're no longer discussing correctness, but assignment of blame.

catnaroek 11y ago
Assignment of blame is important, because it determines what component needs to be fixed to solve the problem. It's all about correctness in the end. As an aside, I want to clarify that I'm not advocating being a bad team player. The point to assigning blame isn't demonizing the developer of the faulty component, or reducing cooperation between developers of different components to the bare minimum. The point is just reducing the cost of fixing the problem.
- kazinator 11y ago
  Assignment of blame is important, but it is often an opinion. If one program misuses another, usually the fix can be an alteration in either one or both. The used program can be expanded to accept the "misuse" which is actually legitimate but not in the requirements. Or the using program can be altered not to generate the misuse. Sometimes what is fixed is chosen for non-technical reasons, like: the best place to fix it it is in such and such code, but ... it's too widely used to touch / not controlled by our group and we need a fix now / closed source and not getting fixed by the vendor {until next year|EVER} / ...
  - catnaroek 11y ago
    > Assignment of blame is important, but it is often an opinion. When in doubt, ask the specification. If there was no specification, why was any code written at all? > If one program misuses another, usually the fix can be an alteration in either one or both. Actually, there are three possibilities: (0) The used program doesn't comply with its specification. (1) The using program doesn't comply with its specification. (2) The specifications of both programs are mutually inconsistent. In which case, it's a programming mistake to connect both programs. > The used program can be expanded to accept the "misuse" which is actually legitimate but not in the requirements. If it isn't in the specification, it isn't legitimate, period. > Or the using program can be altered not to generate the misuse. Sure.
    - dllthomas 11y ago
      "If it isn't in the specification, it isn't legitimate, period." You have some goal you're trying to achieve, or why was a specification written at all? If you find that the existing specification is not the optimal path to that goal, you may very well want to change the specification. In which case, it's entirely legitimate.
      - kazinator 11y ago
        Anyway, requirements, specifications and programs are just multiple representations of the same thing. Ideally, we would just state some requirements and they would execute. So the requirements/specification/program complex exists Just Because. Humans decided they want that: for their amusement, for the sake of supporting some enterprise or solving a problem, or to try to sell to other humans. The complex contains several different representations because that's what it takes to bridge the gap between stating the requirements and making the machine carry them out. A proof is something internal to that complex: that the specification corresponds to the requirements, and that the program implements the specification. If we had just one artifact: a specification that executes, then there would be no concept of proof any more. There is only the question whether the specification that was expressed is the one that was intended in the mind. That equivalence is no more susceptible to proof than, say, the correspondence between the Ceasar salad that the waiter just put on your table (and which you clearly specified) and the idea of whether you actually wanted one, or did you mistakenly say "Ceasar salad" in spite of having wanted a soup. Plus, there is the external question of whether a specification has unintended consequences. That basically amounts to "you say you want that, but maybe you should revise what you want because of these bad things". "You say you want plaintext passwords to be stored for easier recovery, and that can certainly be implemented (provably correctly, too) but consider the following ramifications ..."