Context from the previous post in the series:<p><i>> Behavioral Programming is a relatively new programming paradigm that excels at isolating and composing behaviors in event driven system.</i><p><i>> Behavioral programming was invented by David Harel[0], who also invented statecharts in 1987. It uses independent units of behavior, called bthreads, which are coordinated in a pub-sub protocol.</i><p>[0] <a href="https://cacm.acm.org/research/behavioral-programming/" rel="nofollow">https://cacm.acm.org/research/behavioral-programming/</a> (2012)
It's an interesting paradigm. I would be very intrigued to see this implemented at scale, with all sorts of cross cutting concerns (logging, persistence, multiplayer and auth, displaying an error message when you try an illegal move or confirming when you win etc). Feels like a lot of COMEFROM-style code if you're not careful. That said, I am fascinated by the idea of append-only codebases - what would it look like if we performed less surgery inside our codebases, and instead merely added to them or overrode bits of them as time passed? I think most people would recoil in horror at the thought, but in a way a lot of long-term architectural decisions are made to support that kind of change in a system. How could we make that more natural? The behavioural programming approach certainly lends itself to more agility via extension rather than rewriting.
This seems like it could be promising for embedded and real time event handling. I dislike async programming.<p>Though it seems possibly similar to ECS systems? Can anyone comment on that aspect?