3 ms·

What I don't like about state machines in code is that transitions become less obvious the bigger the state machine gets. Having each state as a function, with

What I don't like about state machines in code is that transitions become less obvious the bigger the state machine gets. Having each state as a function, with a descriptive name is nice, but you really have to dig through the whole code to see which transitions are possible and which are not.

xupybd 4y ago
Yeah I find they're best kept small. I find them useful in managing GUI state. Some business logic gets a bit too complicated to nicely represent in a state machine.
marmetio 4y ago
You could have the calling function do the state transitions all in one place. The individual state functions would still do most of the work and generate the information required to determine the next state. But they would be "unaware" that they're part of a state machine.
dopidopHN 4y ago
I tends to have a config part where all possible transition are listed in a type safe way. ( error transition as well. Basically what is not desribed there is a bug or a unknown error transition ) I also tends to have state machine calling other machine or being composed of 2-3 smaller ones. I save the state in some serialized form in DB if needed. It’s great for customer flow : like; tracking where they are in the KYC process or onboarding and deciding what to do next. Without having 50 nested switch statement.
davidrupp 4y ago
The part that specifies "which transitions are possible and which are not" (more precisely: which state results from a given state and input) -- known as the state-transition function [1] -- is a necessary component of the state machine definition. If you don't have that, you don't have a state machine in code; you just have a bunch of functions. [1] https://en.wikipedia.org/wiki/Finite-state_machine#Mathematical_model https://en.wikipedia.org/wiki/Finite-state_machine#Mathemati...
- w4rh4wk5 4y ago
  Maybe necessary to define one by the book, but not to put one into code. I've seen enough state machines in the wild that are just a dispatcher with a bunch of functions mutating a single state variable. Whether we call these contraptions state machines or not is just quibbling. As others have pointed out, there are better ways to implement them; yet, I rarely come across those.
simplotek 4y ago
> What I don't like about state machines in code is that transitions become less obvious the bigger the state machine gets. There are techniques to keep those large state machines manageable, such as structuring them with sub-state machines.

xupybd 4y ago

Yeah I find they're best kept small. I find them useful in managing GUI state. Some business logic gets a bit too complicated to nicely represent in a state machine.

marmetio 4y ago

You could have the calling function do the state transitions all in one place. The individual state functions would still do most of the work and generate the information required to determine the next state. But they would be "unaware" that they're part of a state machine.

dopidopHN 4y ago

I tends to have a config part where all possible transition are listed in a type safe way. ( error transition as well. Basically what is not desribed there is a bug or a unknown error transition ) I also tends to have state machine calling other machine or being composed of 2-3 smaller ones. I save the state in some serialized form in DB if needed. It’s great for customer flow : like; tracking where they are in the KYC process or onboarding and deciding what to do next. Without having 50 nested switch statement.

davidrupp 4y ago

The part that specifies "which transitions are possible and which are not" (more precisely: which state results from a given state and input) -- known as the state-transition function [1] -- is a necessary component of the state machine definition. If you don't have that, you don't have a state machine in code; you just have a bunch of functions. [1] https://en.wikipedia.org/wiki/Finite-state_machine#Mathematical_model https://en.wikipedia.org/wiki/Finite-state_machine#Mathemati...

w4rh4wk5 4y ago
Maybe necessary to define one by the book, but not to put one into code. I've seen enough state machines in the wild that are just a dispatcher with a bunch of functions mutating a single state variable. Whether we call these contraptions state machines or not is just quibbling. As others have pointed out, there are better ways to implement them; yet, I rarely come across those.

simplotek 4y ago

> What I don't like about state machines in code is that transitions become less obvious the bigger the state machine gets. There are techniques to keep those large state machines manageable, such as structuring them with sub-state machines.