The article linked spends a lot of time looking at an event-based calculator in VBScript that evidently has a lot of bugs. This is used as a justification for doing what they do (whatever that is? I don't really get it).
My problem with this is the calculator program is very poorly written. One could probably get rid of most of the bugs by using a "single source of truth" state object that includes all state data necessary for all events to act correctly.
The calculator program is buggy because the programmer is apparently not thinking holistically, and is patching bugs as they are found by adding another little state variable here and there. The result is just what you'd expect.
But this is largely a solved problem. The React folks developed Flux[0] to get away from these kinds of situations.
I guess my point is I can't be bothered to go study what a bitwrap is all about given the problem it solves is moot when using good design techniques.
But if someone can explain the problem better, I'm all ears.
Assuming you mean it...
Here's a youtube video about the benefits and attributes of event-sourcing. https://www.youtube.com/watch?v=8JKjvY4etTY
Though the demo project is presented in the browser, I'm trying to demonstrate that I can model the game of Tic-Tac-Toe using a much smaller and comprehensible (I hope) graph.
Additionally - because these are mathematical graphs I'm speaking of - it means the 'program' that the graph represents - can be expressed as pure math ( which is nifty to say the least )
A classic DFA would have to represent all the permutations of the board like so: https://upload.wikimedia.org/wikipedia/commons/1/1f/Tic-tac-...
Just a few comments in response:
> event-based calculator in VBScript
It's mostly coffeescript
> My problem with this is the calculator program is very poorly written.
It's a demo - also the coffeescript is only there to show how the python server works. ( I'll update the docs to explain this better )
> One could probably get rid of most of the bugs by using a "single source of truth" state object that includes all state data necessary for all events to act correctly.
This is in fact what exists -- the "single source of truth" in his case is the python event store - My pooly written UI is only there to forward events server-side.
> But this is largely a solved problem. The React folks developed Flux[0] to get away from these kinds of situations.
Front end UI isn't my focus - building a quality event store is.
I'd love to find other state machine implementations that have similar properties.
Thanks for your post - I know everything is poorly documented - I'll take your criticism as a guide to fixing that.
https://barrgroup.com/Embedded-Systems/How-To/State-Machines...
That VB calculator is shown as an example of "The Problem" with event driven programming, but I just see it as an example of why poorly designed programs are hard to reason about and buggy.
I did not see the coffeescript / Python calculator.
I believe "Dining Philosophers" is the usual problem used to introduce the need and concept of Petri-Nets - googled for some examples I found:
http://www.cs.cmu.edu/afs/cs/academic/class/15671-f97/www/le...
Also here's the link to the PNML source used for tic-tac-toe: https://github.com/bitwrap/bitwrap-io/blob/master/bitwrap_io...
