4 ms·
> A lot of programming is about going from one state to another. We can do that using conditionals statements, but as the state changes those conditions can be
by PaulWaldman 4y ago
> A lot of programming is about going from one state to another. We can do that using conditionals statements, but as the state changes those conditions can be tricky to reason about and in turn refactor. Instead it's often more convenient to use state machines: singular objects which represent all possible states and their transitions.
State machines don't necessarily alleviate the need for conditional logic. They can still require conditional logic to determine which state to transition.
- jen729w 4y agoI mean almost by definition isn’t every exit from a state node a conditional logic test? If [something], take path A. If [the other thing], take path B. You (the machine) must always decide, given some condition. This applies even if there’s a default path. You only take the default if one of the non-default paths didn’t match (or if it’s the only path). So I don’t think that’s what the author really meant here. They implied conditionals that don’t transition you to another state. Because in that scenario, you might still need to consider that past conditional. Its values might still bite you. Whereas in the tranquility of state machine land, you can now disregard any* decisions that you’ve already made. *Obviously you might have stored state to consider, but y’know.
- User23 4y agoWe can go further and say that with a von Neumann machine, which is the kind of computer we actually build, all programming is about going from one state to another. Pragmatically speaking all the debates about OO, imperative, functional, and whatever else are all about what abstraction to use to characterize those states.