3 ms·

> This makes no sense whatsoever. It's up to people to make up their minds about what they want. If they can't, then maybe they don't deserve to be written prog

> This makes no sense whatsoever. It's up to people to make up their minds about what they want. If they can't, then maybe they don't deserve to be written programs for? It makes perfect sense. To account for every edge or use case for a requirement you'd have to create many different interfaces/points of contact to suit every need. For example, if I want to create a dating app, the interface and underlying code for a mobile device will break consistency with the interface and underlying code of a web page. You could be consistent with a translation layer, but then the interface or code will be incomplete for that particular use case. > Formal analysis can be used to show the absence of bugs, but never to show the correctness of the specification. Working in a horizontally stratified organization where the programmer doesn't learn the business domain is ill advised. Often the programmer has the most context and understanding of both the business processes as they are being formalizaed into code. Additionally your understanding of the specification may be flawed or simply written incorrectly, and this can never be formally analyzed. > Programs can exhibit “faults in construction” that would be forbidden by a modernist approach. In other words, a program can have a bug as a feature, or something that is wonky, but tolerated.

catnaroek 9y ago
> the interface and underlying code for a mobile device will break consistency with the interface and underlying code of a web page. Are you talking about some notion of “consistency” that has nothing to do with logical consistency? > Additionally your understanding of the specification may be flawed or simply written incorrectly, and this can never be formally analyzed. The whole point to making a formal specification is reducing the potential for misunderstanding. In fact, the only way to misunderstand a formal specification is to be mathematically incompetent. --- Reply: > Yes, the section is called "On Requirements" and the paper is about building programs, not abstract or theoretical computer science/logic. Yet requirements are logical artifacts. > do[sic] to a level of randomness and misunderstanding of our natural world, There's nothing to understand about the natural world. You only need to know what you want the program to do. In other words, you need to consider every possibility, and make up your mind about how you want it to be handled. > we simply do not have a finite amount of variables to statically analyze against. wat
- giantsloth 9y ago
  > Are you talking about some notion of “consistency” that has nothing to do with logical consistency? Yes, the section is called "On Requirements" and the paper is about building programs, not abstract or theoretical computer science/logic. > The whole point to making a formal specification is reducing the potential for misunderstanding. In fact, the only way to misunderstand a formal specification is to be mathematically incompetent. I suppose we're talking about the semantics of the word formal, as well as the level of granularity one can hope to achieve over a specific problem domain. While I have no doubt that all processes can and will eventually be reduced into an algebraic function, currently, do to a level of randomness and misunderstanding of our natural world, we simply do not have a finite amount of variables to statically analyze against.

catnaroek 9y ago

> the interface and underlying code for a mobile device will break consistency with the interface and underlying code of a web page. Are you talking about some notion of “consistency” that has nothing to do with logical consistency? > Additionally your understanding of the specification may be flawed or simply written incorrectly, and this can never be formally analyzed. The whole point to making a formal specification is reducing the potential for misunderstanding. In fact, the only way to misunderstand a formal specification is to be mathematically incompetent. --- Reply: > Yes, the section is called "On Requirements" and the paper is about building programs, not abstract or theoretical computer science/logic. Yet requirements are logical artifacts. > do[sic] to a level of randomness and misunderstanding of our natural world, There's nothing to understand about the natural world. You only need to know what you want the program to do. In other words, you need to consider every possibility, and make up your mind about how you want it to be handled. > we simply do not have a finite amount of variables to statically analyze against. wat

giantsloth 9y ago
> Are you talking about some notion of “consistency” that has nothing to do with logical consistency? Yes, the section is called "On Requirements" and the paper is about building programs, not abstract or theoretical computer science/logic. > The whole point to making a formal specification is reducing the potential for misunderstanding. In fact, the only way to misunderstand a formal specification is to be mathematically incompetent. I suppose we're talking about the semantics of the word formal, as well as the level of granularity one can hope to achieve over a specific problem domain. While I have no doubt that all processes can and will eventually be reduced into an algebraic function, currently, do to a level of randomness and misunderstanding of our natural world, we simply do not have a finite amount of variables to statically analyze against.