3 ms·
On top of the requirements engineering that's left implicit here, there's still the matter of understanding the event trace that you're supposed to be modifying
by Twisol 7y ago
On top of the requirements engineering that's left implicit here, there's still the matter of understanding the event trace that you're supposed to be modifying. If every patch is a transformer from traces to traces, then it stands to reason that you must understand the event trace at least as well as the program you would otherwise be modifying. And program traces are an inherently dynamic thing -- how do you gain an understanding about the potentially very complicated, interwoven traces you're developing with if you can only see one trace per execution?
A great deal of the problem of concurrent programming is just coming to grips with these traces, and decomposing them in a comprehensible way within the structure of your codebase.
- coldtea 7y ago>And program traces are an inherently dynamic thing -- how do you gain an understanding about the potentially very complicated, interwoven traces you're developing with if you can only see one trace per execution? The example with the ATM makes this clearer: by designing the system so that a trace has one clear path for a given input. Which might not be workable for larger systems of course, but holds for certain categories of systems (like ATMs and industrial control systems).
- Twisol 7y agoWhile true, this still restricts you to learning one trace per input. With symbolic representations of a program, you can perform symbolic execution (whether in your head or using a formal tool) to understand whole classes of traces in one go. Determinism is important, but it’s also not enough. You want some analogue of continuity / smoothness to be able to generalize observations based on one input to others that you haven’t tried.