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

51–60 of 121 posts

Re: Why developers never use state machines (2011)

#51

Post by jjtheblunt »

rcme wrote: post #18
AussieWog93 wrote: post #8

I'm an EEE, and one of the strange things I've noticed is that, for whatever reason, people from a CompSci background is really, really have trouble building and understanding even simple state machines. I suspect this unintuitiveness is the main reason why we don't see more state machines, as even in the case where they're an optimal solution many SWEs will shy away from them. Locally-rendered UIs are probably one o…

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…

Those regexes that are ubiquitous are called regular expressions because they describe “regular languages” (qv), which are recognized by nondeterministic finite automata, which are converted to deterministic finite automata by fun with powersets, which are compiled into software state machines behind the abstraction of the regex libraries.

So they are not at all rare but not exposed to programmers explicitly.

Re: Why developers never use state machines (2011)

#53

Post by po »

My belief is that part of the reason state machines are not used often is:

- State machine libraries are good at expressing an existing state machine but often the workflow for upgrading or modifying it in production is lacking. If you want to remove a state for instance, it's still very hard and the tooling just makes it more obtuse.

- The reason class hierarchies as a way to model your problem are overused in most programming languages is not because it's good, but because it's a language feature that's taught by every book that covers that language. If state machines had language-level support/keywords, more people would use them.

(Interestingly, I think part of why class hierarchies can be a trap is similar to the first issue above with state machines: they are hard to change down the road as you learn more about your problem space.)

Re: Why developers never use state machines (2011)

#54

Post by lmm »

jjtheblunt wrote: post #51
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…

Those regexes that are ubiquitous are called regular expressions because they describe “regular languages” (qv), which are recognized by nondeterministic finite automata, which are converted to deterministic finite automata by fun with powersets, which are compiled into software state machines behind the abstraction of the regex libraries. So they are not at all rare but not exposed to programmers explicitly.

Almost all "regexes" in programming languages are not actually regular expressions and do not have the properties you describe. (I'd argue that this is one of the clearest demonstrations that programmers do not put a lot of value of state machines)

Re: Why developers never use state machines (2011)

#56

Post by _gabe_ »

rcme wrote: post #18
AussieWog93 wrote: post #8

I'm an EEE, and one of the strange things I've noticed is that, for whatever reason, people from a CompSci background is really, really have trouble building and understanding even simple state machines. I suspect this unintuitiveness is the main reason why we don't see more state machines, as even in the case where they're an optimal solution many SWEs will shy away from them. Locally-rendered UIs are probably one o…

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…

> This makes it annoying to design a state machine.

Annoying sure, but necessary right? With or without a state machine you have to handle all the states, and if you don't bother quantifying all possible states of your model and just winging it, it's not like those extra transition states magically disappear. Instead you just run into weird multithreading bugs and after banging your head against the wall for 5 hours you realize you forgot about a transitory state

And just to clarify, I don't mean handling every single state possible, because that's most likely infinite. But if you specify a finite number of states your app can be in, and then mark the invalid transitions to take you to an invalid state, then you can figure out when your app is in an invalid state immediately instead of having the weird bugs crop up randomly.

Re: Why developers never use state machines (2011)

#58

Post by syntheweave »

AussieWog93 wrote: post #8

I'm an EEE, and one of the strange things I've noticed is that, for whatever reason, people from a CompSci background is really, really have trouble building and understanding even simple state machines. I suspect this unintuitiveness is the main reason why we don't see more state machines, as even in the case where they're an optimal solution many SWEs will shy away from them. Locally-rendered UIs are probably one o…

I believe the intuition of most programmers tends to stem from the development environments being designed around ease of mutable state. If you want to "add state" you just grab some variable and branch on it, done.

Thus all the instances where you want to enumerate your state come off as seeming unnecessarily formal, so the code just drives straight towards a ball of mud and the programmers, looking for a way out, look for abstract techniques to eliminate the state(pure functions, dataflow, constraints, etc.) or sweep it under the rug(objects and configuration mechanisms) instead of "cleaning their room" by drawing up a giant decision table that enumerates all possible transitions.

I've made the transition table. It works. It produces a painful "rip off the bandaid" moment in that it forces out more of the specification all at once instead of allowing to accumulate iteratively. I'm pretty sure this makes it politically undesirable in many orgs.

Re: Why developers never use state machines (2011)

#59

Post by osigurdson »

rcme wrote: post #18
AussieWog93 wrote: post #8

I'm an EEE, and one of the strange things I've noticed is that, for whatever reason, people from a CompSci background is really, really have trouble building and understanding even simple state machines. I suspect this unintuitiveness is the main reason why we don't see more state machines, as even in the case where they're an optimal solution many SWEs will shy away from them. Locally-rendered UIs are probably one o…

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…

>> transition between A and B requires 3 async operations

Couldn't you do the equivalent of a join to transition to B?

Re: Why developers never use state machines (2011)

#60

Post by Viper512 »

I worked at a company on the front end team while a foundation team senior developer coerced the management into this whole state machine thing.

It was overly complex for what it produced.

.... We needed an API.. everything got rewritten 3 times before it was actually released because it was too complex and served zero purpose.

Post reply on HN