Author here: sorry if the "append-only" analogy went a bit upstream in the comments, it was certainly meant to be taken with a pinch of salt. All of regular pr

Author here: sorry if the "append-only" analogy went a bit upstream in the comments, it was certainly meant to be taken with a pinch of salt. All of regular programming methodologies apply with b-threads. And most of the time changing requirements would require one to change the b-threads involved in that requirement. The append-only analogy was really more to showcase the feature of incrementality. Technically one can develop a complicated system just via append-only but again you'll likely better off having clean b-threads that deal with specific behavior organized in specific and clean ways the same way we organize any other software. From the comments it seems I wasn't successful at highlighting the key insights of this paradigm. One read that I suggested in this article that does a much better job at explaining these concepts is "The quest for runware: on compositional, executable and intuitive models" [1] where the authors essentially describe the need for something like Behavioral Programming (authors are the creators of BP). Some quotes from the paper: > As mentioned earlier, it will be possible to represent new requirements, or changes thereof, in a new behavioral component or module, with minimal change to the previously specified parts of the model, and without sacrificing executability and manageability. Such modules will be simply added to the existing model, virtually ‘piled-atop’ it, with no component specific interface, connectivity, or ordering requirements. > In our vision, the units of the specification and models are not assembled in detail like resistors or chips on a computer board, or methods and fields in an OO-programming object class. The interweaving of behavioral modules will be facilitated by their reference to common aspects of system behavior described using shared vocabularies (for example, common events), and not via mutual awareness and direct communication between components. From the point of view of such a module, the other modules could be transparently replaced by new ones. In fact, the implementation of any part of the specification or a model should be replaceable by some kind of ‘invisible box’, whose implementation remains a mystery, and the effectiveness of the remaining modules and the integrity of the overall system behavior will be preserved. And from the conclusion: > What will happen if and when the human way of expressing requirements for systems will become almost indistinguishable from the way this is done with computer programs? And what will be the result of a level of compositionality that would allow humans to add capabilities to a system with much less dependence on that system than is possible today? > When a collection of specification units grows over time, accumulating an unmanageable collection of patches, exceptions, and enhancements, it is likely developers will call for merging or refactoring them into much more concise artifacts. The new modules will replace the existing collection in all its uses (final executing system, official record of the specification, and means for communication between humans) without changing other parts of the specification. Such refactoring will be acceptable, even if it ends up being done manually, as it will focus on capturing the human’s revised perception of the affected behavior. 1. http://www.wisdom.weizmann.ac.il/~harel/papers/Runware.pdf http://www.wisdom.weizmann.ac.il/~harel/papers/Runware.pdf