“Behavioral Programming” by Harel, Marron, and Wei...
# reading-together
c
“Behavioral Programming” by Harel, Marron, and Weiss (2012)
We describe an implementation-independent programming paradigm, behavioral programming, which allows programmers to build executable reactive systems from specifications of behavior that are aligned with the requirements. Behavioral programming simplifies the task of dealing with under- specification and conflicting requirements by enabling the addition of software modules that can not only add to but also modify existing behaviors. A behavioral program employs specialized programming idioms for expressing what must, may, or must not happen, and a novel method for the collective execution of the resulting scenarios. Behavioral programming grew out of the scenario-based language of live sequence charts (LSC), and is now implemented also in Java and in other environments. We illustrate the approach with detailed examples in Java and LSC, and also review recent work, including a visual trace-comprehension tool, model-checking assisted development, and extending behavioral programs to be adaptive.
https://www.wisdom.weizmann.ac.il/~amarron/BP%20-%20CACM%20-%20Author%20version.pdf
If you think about Harel’s research into statecharts as “executable models” of behavior, then bthreads are “executable requirements” of behavior.
For a practical example see @lmatteis’s essay on defining animations with bthreads https://observablehq.com/@lmatteis/sculpting-animations-using-bthreads
a
I psyched myself up for a hard slog, but section 2 pretty much explains it in a single page of plain English. Looks promising. That said I wasn't terribly convinced about their examples. Does the Interleave thing they use in the water example scale beyond multiplexing same-size processes? Does the drone example work at all? I don't see evidence that this approach has beaten reality in all its hairy details...
c
I think that its still early on for this type of programming paradigm, so I think more of the focus is on ironing out the conceptual framework and semantics of the paragdigm rather than determining if it “scales”. The premise of a truly additive approach to decomposing a software system into raw requirements is quite intruiging, even though, similar to you, Im not entirely bullish on it yet.