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

101–110 of 121 posts

Re: Why developers never use state machines (2011)

#101

Post by Tangurena2 »

sweetjuly wrote: post #82
pitched wrote: post #57

Where is the line between a state machines and object-oriented? One encapsulates some state and provides a set of messages to modify it. The other encapsulates some state and provides a set of transitions to change it.

The point of ""using a state machine"" is to make this explicit. Programs (and computers in general!) are already just ridiculously complex state machines. Issue is, however, that it is too complex to be reasoned about and so a simpler, explicit one on top is necessary

The last state machine I was involved with had to do with possible conditions when registering vehicles. What must be done if it was reported stolen (by NCIS) was coded in laws and regulations. What has to happen if the customer decides not to register it after all. Or they call up and go "hey! where's my title?" There were all sorts of edge cases that had to be unambiguously defined and documented. 99% of registrations followed the "happy path", but that last little bit caused all of the trouble. The printed version was an 11x17" flowchart with the "happy path" taking up less than 1/4 of it.

Re: Why developers never use state machines (2011)

#103

Post by rcme »

programmarchy wrote: post #44
rcme wrote: post #33

Earlier quoted context omitted.

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.

You should try Swift's Combine library. It works pretty nicely for modeling / cleaning up complex async flows.

Re: Why developers never use state machines (2011)

#105

Post by KMag »

jholman wrote: post #93
BlueTemplar wrote: post #88

Earlier quoted context omitted.

I was also confused then realized that Turing machines that are allowed to write on their tape are not (always equivalent to ?) state machines. So I guess that making a state machine involves clearly separating the write-protected parts that make it from the rest of the program, and forbidding tampering ? Also, all computing is not (directly) state machines or even Turing machines : quantum computing and generally an…

Here are some comments from the perspective of computing science (i.e. not from the perspective of software development). There is a conceptual thing called a "finite state machine", which has no memory except a set of finite states. It can, of course, "recognize" the elements of any finite set, but the question is, what infinite sets can it recognize? There is another conceptual thing called a "Turing machine". It h…

> Another machine, a push down automaton, has memory capability greater than the FSM, but lesser than the TM.

What you've written is correct, but someone who's not reading carefully might mistake "capability" for "capacity". Both pushdown automatons and Turing machines have infinite storage capacity, but the Turing machine can seek to any position in its infinite tape while the pushdown atomaton can only access the top of its infinite stack.

Re: Why developers never use state machines (2011)

#110

Post by KingMob »

Multicomp wrote: post #61
KRAKRISMOTT wrote: post #13

Earlier quoted context omitted.

They do not scale well. It is why Elm-style explicit message passing UIs are not popular. State machines work for state localised to a widget, but the moment you scale up to something moderately complex (spreadsheets, datagrids, forms etc.), your diagrams balloons in size. For non safety-critical applications, it is better to have implicit state and potential bugs than to have your engineering team waste time proving…

> but the moment you scale up to something moderately complex (spreadsheets, datagrids, forms etc.), your diagrams balloons in size I'm no CS major. But isn't that what Hierarchical state machines are supposed handle? Or was that all hat no cattle and/or a lost knowledge when UML style stuff got tossed away?

Having worked on a large hierarchical state machine implementation (using statecharts), I can say that nested FSMs help a bit, but are still nowhere close to capturing the necessary complexity. 80% hat, only 20% cattle.
Post reply on HN