3 ms·

How do you know when adding a new requirement that the forbidding of something won't cause a cascading of other requirements to conflict with each other? In es

How do you know when adding a new requirement that the forbidding of something won't cause a cascading of other requirements to conflict with each other? In essence we are used to restricting our understanding of a piece of software through the structure and the code (and maybe some documentation). Instead this approach aims at a much more dynamic and feedback oriented view on debugging: if blocking an event causes other things to break one should be able to run tests with the new blocking module in place and figure out why things break; just like you do in normal code. I would argue that also a small change to a strictly-structured program might cause the wreckage of other use cases.

mannykannot 7y ago
When doing things properly, we are not restricting our understanding of a piece of software through the structure and the code, we are restricting what we need to take into consideration in order to achieve a necessary understanding our code, and confidence in its correctness. In badly-designed conventional code, changes can have far-reaching consequences, which makes it hard to understand, but under this proposal, it would seem to be the default. Reasoning about asynchronous behavior is hard. (These points are demonstrated by how much had to be written to explain the example.) The author says that merging is the problem, and that this approach obviates it. With conventional programming, the pain of merging can be mitigated with the careful separation of concerns, while this approach seems to turn every aspect of programming into merging. Everything I have said here about conventional programming depends on doing it well, but at least you have the option to do so, and simplify things through the separation of concerns, while I suspect the approach here makes combinatorial explosions of complexity almost unavoidable. The goal is not to make complex software, but to solve complex problems with software that is as simple as possible to produce and verify.

mannykannot 7y ago

When doing things properly, we are not restricting our understanding of a piece of software through the structure and the code, we are restricting what we need to take into consideration in order to achieve a necessary understanding our code, and confidence in its correctness. In badly-designed conventional code, changes can have far-reaching consequences, which makes it hard to understand, but under this proposal, it would seem to be the default. Reasoning about asynchronous behavior is hard. (These points are demonstrated by how much had to be written to explain the example.) The author says that merging is the problem, and that this approach obviates it. With conventional programming, the pain of merging can be mitigated with the careful separation of concerns, while this approach seems to turn every aspect of programming into merging. Everything I have said here about conventional programming depends on doing it well, but at least you have the option to do so, and simplify things through the separation of concerns, while I suspect the approach here makes combinatorial explosions of complexity almost unavoidable. The goal is not to make complex software, but to solve complex problems with software that is as simple as possible to produce and verify.