Behavioral Programming (2018)(lmatteis.github.io)
lmatteis.github.io
Behavioral Programming (2018)
https://lmatteis.github.io/react-behavioral/
5 comments
The example in the EnforcePlayerTurns section is kind of buggy. Make an attempt to place two Xs in a row in different cells, then place an O in a third cell - the second X you attempted to place will magically show up at the same time as that O.
I'm not convinced. The main selling point is that developers don't have to know the previous code to make changes... complete with a precedence system.
Apart from seeing very little explanation why this would work, I can't help but think of a Website, where instead of replacing existing classes, we add more and more with higher specificity.
Apart from seeing very little explanation why this would work, I can't help but think of a Website, where instead of replacing existing classes, we add more and more with higher specificity.
This seems to be like state machines, aside from
> As new ideas and requirements are discovered, we can forbid certain things from happening by simply adding new b-threads; without having to dig and figure out how earlier-written code works!
Which I'm not really sure is a step up from state machines?
> As new ideas and requirements are discovered, we can forbid certain things from happening by simply adding new b-threads; without having to dig and figure out how earlier-written code works!
Which I'm not really sure is a step up from state machines?
Behavioral programming is just creating a specific type of rules engine which is very close to a state machine.
This example is also really complex in reality because it inherently requries muxing of temporal events, which is really difficult for most average industry programmers.
With event driven systems what I've seen is that your average programmer is comfortable and likes 1:1 maps but cannot handle any kind of reduce functionality esp over a temporal range.
Typically adoption of something like this would be easier if the event represented a change in the state of the whole board rather than a change in the state of a cell.
TBH this is somewhat reinventing Observables for React.
This example is also really complex in reality because it inherently requries muxing of temporal events, which is really difficult for most average industry programmers.
With event driven systems what I've seen is that your average programmer is comfortable and likes 1:1 maps but cannot handle any kind of reduce functionality esp over a temporal range.
Typically adoption of something like this would be easier if the event represented a change in the state of the whole board rather than a change in the state of a cell.
TBH this is somewhat reinventing Observables for React.
Isn’t GitHub copilot a behavioral programming tool?