4 ms·
When some one complains about how async nodejs and callback are hells. I smile. FSM are notoriously hard to write, manage and debug. Because they are async by d
by samblr 9y ago
When some one complains about how async nodejs and callback are hells. I smile. FSM are notoriously hard to write, manage and debug. Because they are async by design.
In one of my prev workplaces we worked on state machines. Few good takeaways was to design state transition functions in a large array laid out with all possible hooks in order. And document the hell out ofit. Another approach was to generate boiler plate out of fsm given its grammar.
- Const-me 9y agoFor asynchronous IO, we now have async-await in many modern languages. The feature pretty much solves IO related callback hell; the compiler builds these state machines automatically, and keeps them abstracted behind a nice API making code easy to read, write and debug. I wish someone would invent an approach suitable for generic FSMs, not just for async IO. External code generators work when you have grammar or protocol state UML, but aren’t without their problems.
- ablaba 9y agoHow about esterel? It seems to be a nice language based on FSM. https://en.wikipedia.org/wiki/Esterel https://en.wikipedia.org/wiki/Esterel