3 ms·

Couldn't this be said about any alternative solution? I fail to see how this is specific to state machines. What do you suggest instead of a state machine?

by throwaway2037 2y ago

majormajor 2y ago
The "riddled with state machines" from the post I was replying to, while sounding negative, is at least better than the "single state machine" which is probably combinatorially huge and would be impossible to maintain. My rough rule of thumb based on experience is that if the state machine being a state machine is visible outside of it's internal implementation (compared to just an interface with operational methods that don't hint at how things are managed behind the scenes) it's probably too leaky and/or incomplete. I would trust code with extensive state-transition testing (regardless of internal implementation) - I wouldn't trust code that claimed to implement a state machine and didn't have that testing, or extensive documentation of edge cases and what was left out of the state machine. As a simple example of something that's often left out in a way that fucks up state machines: the passing of time.
bvrmn 2y ago
Like properly model a domain in domain terms?
- nottorp 2y ago
  And that won't be a state machine with the states having more fancy names?
  - InDubioProRubio 2y ago
    It will be, but the idea of having an overview over the states is gone then. There is just modules-> objects with the transitions being method calls. Nobody will have to know all the things about all the state transitions, resulting in another problem (dys)solved by architecture obscurity. If needs be the state-machine can be reconstructed on a whiteboard by a team of five.
    - grumpyprole 2y ago
      A state machine makes the actual program state first class and easy to reason about. One does not even need mutable state to model one. Whereas you appear to be advocating mutable objects. The state space then becomes a combinatorial explosion of all the hidden mutable state "encapsulated" inside the objects. Object oriented programming is not the only way and often leads to a poor domain model. Some OOP evangelists even model a bank account with a mutable balance field and methods for making deposits. This is a absolutely not a faithful model of the domain (ledgers have been used for hundreds/thousands of years). In summary, yes a state machine can absolutely be a good domain model.
      - bvrmn 2y ago
        It's interesting to know about what state machines you talk. From my experience most of the time it's an entity with state property with finger countable cardinality. And state is assumed to be changed directly. And it's not easy to reason because author only heard about state machines and state transitions are spread over all code base.
        grumpyprole 2y ago
        I was talking in the most general sense. I am sure there are state machine implementations that are terrible to reason about, especially any that emerge from a codegen tool. But hopefully they are the exception and not the rule.
        throwaway2037 2y ago
        Woah, this caught my eye: > especially any that emerge from a codegen tool Can you give an example?
      - majormajor 2y ago
        I don't follow the connection you're making. State machines often are implemented with mutable objects. And one does not need mutable objects to make "modules-> objects with the transitions being method calls". Every method call could return a fresh, immutable object, nothing requires mutation there. I'd see a method like: `TransitionTo(newState)` as a major smell compared to an explicit `TransistionToNewState` and I think OOO can be helpful (hardly required, of course) in that one neat way of streamlining usage of your code is that if you're implementing objects then the object for something in "State A" might not even have "TransitionToStateC" if that's not a valid operation. (No, you don't HAVE to write state machine code that allows you to ask for invalid operations, but it's a common pattern I've seen in real code and in online discussion/blogs/stack overflow.)

Couldn't this be said about any alternative solution? I fail to see how this is specific to state machines. What do you suggest instead of a state machine?

majormajor 2y ago

The "riddled with state machines" from the post I was replying to, while sounding negative, is at least better than the "single state machine" which is probably combinatorially huge and would be impossible to maintain. My rough rule of thumb based on experience is that if the state machine being a state machine is visible outside of it's internal implementation (compared to just an interface with operational methods that don't hint at how things are managed behind the scenes) it's probably too leaky and/or incomplete. I would trust code with extensive state-transition testing (regardless of internal implementation) - I wouldn't trust code that claimed to implement a state machine and didn't have that testing, or extensive documentation of edge cases and what was left out of the state machine. As a simple example of something that's often left out in a way that fucks up state machines: the passing of time.

bvrmn 2y ago

Like properly model a domain in domain terms?

nottorp 2y ago
And that won't be a state machine with the states having more fancy names?
- InDubioProRubio 2y ago
  It will be, but the idea of having an overview over the states is gone then. There is just modules-> objects with the transitions being method calls. Nobody will have to know all the things about all the state transitions, resulting in another problem (dys)solved by architecture obscurity. If needs be the state-machine can be reconstructed on a whiteboard by a team of five.
  - grumpyprole 2y ago
    A state machine makes the actual program state first class and easy to reason about. One does not even need mutable state to model one. Whereas you appear to be advocating mutable objects. The state space then becomes a combinatorial explosion of all the hidden mutable state "encapsulated" inside the objects. Object oriented programming is not the only way and often leads to a poor domain model. Some OOP evangelists even model a bank account with a mutable balance field and methods for making deposits. This is a absolutely not a faithful model of the domain (ledgers have been used for hundreds/thousands of years). In summary, yes a state machine can absolutely be a good domain model.
    - bvrmn 2y ago
      It's interesting to know about what state machines you talk. From my experience most of the time it's an entity with state property with finger countable cardinality. And state is assumed to be changed directly. And it's not easy to reason because author only heard about state machines and state transitions are spread over all code base.
      - grumpyprole 2y ago
        I was talking in the most general sense. I am sure there are state machine implementations that are terrible to reason about, especially any that emerge from a codegen tool. But hopefully they are the exception and not the rule.
        throwaway2037 2y ago
        Woah, this caught my eye: > especially any that emerge from a codegen tool Can you give an example?
    - majormajor 2y ago
      I don't follow the connection you're making. State machines often are implemented with mutable objects. And one does not need mutable objects to make "modules-> objects with the transitions being method calls". Every method call could return a fresh, immutable object, nothing requires mutation there. I'd see a method like: `TransitionTo(newState)` as a major smell compared to an explicit `TransistionToNewState` and I think OOO can be helpful (hardly required, of course) in that one neat way of streamlining usage of your code is that if you're implementing objects then the object for something in "State A" might not even have "TransitionToStateC" if that's not a valid operation. (No, you don't HAVE to write state machine code that allows you to ask for invalid operations, but it's a common pattern I've seen in real code and in online discussion/blogs/stack overflow.)