Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why developers never use state machines (2011)

skorks.com

Post reply on HN
Print view View original

41–50 of 121 posts

Re: Why developers never use state machines (2011)

#41

Post by 13of40 »

zombiemama wrote: post #7

I've used state machines twice, both times for GUIs. It took more time to program than a bunch of messy if-else logic would, but it was well worth it. The knowledge that your GUI can't find itself in an invalid state is realy reasuring, and also it's preety easy to add new states/logic after you get over the initial hump.

Two times I can recall using them in real life were for parsers to identify MIME and CSV files. I thought it was pretty elegant, but zoom forward a few years, and I got to listen to the new guy tell everyone in scrum how he had to fix a bug in there and it was all, ugh, *weird*.

Re: Why developers never use state machines (2011)

#43

Post by neilv »

My early Swift UI app might not have worked as well as it did, had I not modeled the UI as hierarchical state machines.

But I think that a lot of the dialogue I see around state machines in programming is effectively strawperson. Much like the dialogue around DSLs in programming. People end up debating over weak examples, and then dismissing valuable ideas.

Re: Why developers never use state machines (2011)

#44

Post by programmarchy »

rcme wrote: post #33
ratorx wrote: post #29

Earlier quoted context omitted.

Surely only if you need to name each state and define every transition. However a sparse representation would be useful here right? If there are fundamentally transitions that are impossible (or errors) then just only define the transitions that make sense and have the rest map to a error condition if they ever come up. Also, if the state space is factorisable (like in your example) then it is easy to represent. You…

No, you need to represent every state. Like let’s say there are two async operations: a disk read, then a network request. When you transition, you need to know: did I start the disk read? If yes, cancel the disk read if it’s pending. Did the network request start? If it started but didn’t finish, then cancel it. So you can see that there is a huge amount of state you need to operate on that’s not directly captured b…

Yeah, I’ve wrestled with this, too. Usually I’ve compromised on having sub-states (Swift enums with associated types alleviate some of the pain), but still doesn’t feel quite right.

Re: Why developers never use state machines (2011)

#45

Post by HankB99 »

I suppose applicability depends on the problem domain. In embedded systems that control some device I've found them very useful, particularly as the logic becomes complex. () Perhaps for other realms such as Web back ends that tend to be transactional, they are less useful.

() Many years ago I was tasked with coding a replacement for a device that operated from discrete logic involving a number of inputs, timers, decisions and actions based on all of these. The first thing I did was to model it as a state machine and everything went well except for one part where it was not clear what the next state should be based on the inputs. I reviewed this with an engineer familiar with the existing logic and he shared with me that the actual behavior of the device was indeterminate in that particular situation. That was easily fixed with the state machine.

Re: Why developers never use state machines (2011)

#46

Post by ratorx »

rcme wrote: post #33
ratorx wrote: post #29

Earlier quoted context omitted.

Surely only if you need to name each state and define every transition. However a sparse representation would be useful here right? If there are fundamentally transitions that are impossible (or errors) then just only define the transitions that make sense and have the rest map to a error condition if they ever come up. Also, if the state space is factorisable (like in your example) then it is easy to represent. You…

No, you need to represent every state. Like let’s say there are two async operations: a disk read, then a network request. When you transition, you need to know: did I start the disk read? If yes, cancel the disk read if it’s pending. Did the network request start? If it started but didn’t finish, then cancel it. So you can see that there is a huge amount of state you need to operate on that’s not directly captured b…

If you need recoverability from every state to A or B, then it’s not a 2-state (with intermediates) problem and you do need to go through the complexity of modelling all 6 states.

Also, the full state representation is not the problem, that’s easy enough to do with a reasonable type system. The problem is defining the transitions. But if you need the full transition matrix (or even any substantial subset), then you have a lot of things to do. But it’s things you’d have to do with a non-state machine based approach.

Realistically the only overhead with a sparse state machine representation is adding is the “catch-all” error branch you need to deal with any forbidden transitions. Everything else, you’d need to deal with anyway for normal operation. And you probably want the catch-all branch anyway, for debuggability when it breaks.

Re: Why developers never use state machines (2011)

#48

Post by e-dant »

Woah — with all the declarative and functional languages, looks like someone has just discovered a (stateful) state machine. They’re trying to convince us that this is a useful thing in a hypothetical situation where people do ridiculous, unsafe things on an ad-hoc basis. Not sure I’m buying it.

Oh, wrong universe.

Edit:

I use state, too. I get it. I just dislike it. It doesn’t usually compose and is rarely safe.

Re: Why developers never use state machines (2011)

#49

Post by robomartin »

Interesting.

I use state machines all the time, mostly in FPGA's yet also in software, embedded and beyond. Yes, you do have to develop a sense of when and how to use them.

One of my software techniques is to use a state machine to initially solve and understand a problem. Once done and working, you can start to chip away at the state machine, eliminate states and sometimes refactor the code into something faster or more efficient that completely eliminates the state machine.

The other aspect of this is that state machines can, in some cases, add a layer of safety and failure mitigation.

In the end, it really depends on the nature of the project.

Re: Why developers never use state machines (2011)

#50

Post by jayd16 »

ericmcer wrote: post #25
rcme wrote: post #18

Earlier quoted context omitted.

In software, it’s rare that two states can be transitioned between synchronously. Or at least, modeling a problem in terms of states that have synchronous transitions is hard. Waiting for user input, making a network request, disk IO, etc. are all asynchronous. This makes it annoying to design a state machine. Just as an example, imagine you have two states you want to model, A and B. Let’s say the transition between…

I would just consider all those intermediary states as one “loading” state. It is pretty simple to have a “loading” and “error” state in addition to your other ones.

If you do that then you can't pipeline the response handling and you can't show loaded data until you fully transition to B. Any error would equate to every error.

You could have your loading state handle every little detail but then what was the point of the state machine anyway?

Post reply on HN