3 ms·
Except state machines aren't that good at handling complexity. This generally boils down to: - The number of possible transitions scales quadratically with the
by torginus 6y ago
Except state machines aren't that good at handling complexity. This generally boils down to:
- The number of possible transitions scales quadratically with the number of nodes
- They're not very composable
Plus, there are many things that compile down to state machines, such as Regex or async/await, because they're a pain to write directly.
- davidkpiano 6y agoThat's why statecharts exist.
- rkangel 6y agoState machines do compose, but usually in a message passing environment. That might be a message passing programming environment like Erlang, or it might be a message passing system such as a protocol stack. Every layer in your stack be it bluetooth, IP, or whatever is a state machine communicating with messages to the layers above and below (whether or not it is written using an explicit state machine, most protocol layers implicitly are a state machine). The number of possible transitions thing isn't really an issue. For embedded applications I usually use a (home grown) Python tool that generates C code from a CSV file. The CSV file is 4 columns - start state, event, end state, action function (optional). That list of transitions can get to hundreds of lines, but grouped by starting state it is fairly easy to manage and understand - e.g. you're looking at the list of things that can happen when the device is 'CHARGING' (such as charger disconnect, power on).