3 ms·
> 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 a
by 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 agoAnyway, 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 ..."
- catnaroek 11y ago> If we had just one artifact: a specification that executes, then there would be no concept of proof any more. It is possible for an executable functional specification to have unbearably bad performance for production use. In that case, the programmer has to reimplement the program in a more efficient (but perhaps less obvious) way and supply a proof that the reimplementation is functionally equivalent to the original executable specification. Proofs aren't going away anytime soon. > There is only the question whether the specification that was expressed is the one that was intended in the mind. If other people can't bother communicating what they really want, that is absolutely Not My Problem (tm). > Plus, there is the external question of whether a specification has unintended consequences. If other people can't analyze the logical consequences of what they wish for, that is absolutely Not My Problem (tm). The most I can do is point at contradictions in the requirements.
- spdionis 11y agoDepending on where you go that Caesar salad can be wildly different and it probably is different from what you had in your mind... just saying...
- catnaroek 11y agoIt is only legitimate if you change the specification first.
- dllthomas 11y agoI actually think this depends quite a bit on context, unless you have a carefully particular definition of some of those words in mind.
- kazinator 11y agoSpecifications can have bugs. The root cause of a software defect can sometimes be traced to a bad specification (which was followed).