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

81–90 of 121 posts

Re: Why developers never use state machines (2011)

#81

Post by sweetjuly »

e-dant wrote: post #72
fleventynine wrote: post #19

Computers ARE state machines and the primary purpose of a programming language is to help humans manage all this state.

I’d argue the best way to do that is to write stateless code and let the compiler figure out how to make it fast

I've thought about this a bit too after coming over from a digital logic background--it would be neat to have a language that let you specify multiple concurrent blocks that need to be run for each "clock" of the program and then just let the compiler interlace them as necessary for performance. In other words, just a high level verilog with a synthesis tool that generates high performance (possibly threaded) machine code. I do think though that most programmers would hate writing code in this way since it's a very foreign way of thinking for most SWEs, but it does have promise (especially in a post transistor scaling world).

Re: Why developers never use state machines (2011)

#82

Post by sweetjuly »

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

Re: Why developers never use state machines (2011)

#83

Post by ihatepython »

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.

There is no line. An instance of an object is a state machine. Everybody is arguing over nomenclature.

Re: Why developers never use state machines (2011)

#84

Post by ww520 »

I use state machines, plenty of time. Some examples. Animations are natural with state machines. Iterator over trees or network graphs is easier with SM. Cursor for db result is easier with SM. Parsing is natural with SM. Games are full of SM. Workflow is a SM itself.

Re: Why developers never use state machines (2011)

#86

Post by hot_gril »

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…

Usually your state is more complicated than just one enum. You'll have counters, buffers, etc.

The only time I've ever used a state machine in real code is when parsing text one token at a time or something like that. It's a useful skill to remember for those situations. And this kind of problem is very over-represented in SWE interviews.

Re: Why developers never use state machines (2011)

#87

Post by hot_gril »

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?

Hierarchical state machine = object-oriented programming in the SWE world. You'd have one state machine in each object. It's just rare to see that because even the individual objects tend to have practically non-finite states, like counters and stuff, and just be too complex in general for FSMs.

Maybe there's some math-ey way of saying everything we do is an FSM, but I don't think of it that way.

Re: Why developers never use state machines (2011)

#88

Post by BlueTemplar »

rhelz wrote: post #79
moloch-hai wrote: post #67

This is a strange take. Every last program ever written is a state machine. The number of possible states a program represents is normally very, very large, and the transition rules are very complicated and often mixed up with, e.g., multiplier circuits. So we use familiar programming languages instead, which help to organize it all. A program emulating another state machine tends to raise the question why the (or an…

Here is a kind of bridge from the articles POV to yours: As the OP points out, state machines are very hard to develop by stepwise refinement. A "general solution" to that problem is...the universal Turing machine--a state machine which can emulate any other state machine. However, its really hard to program a Turing machine, so we invented assembly language, which is really hard to program, so we invented higher-lev…

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 analogic computing come to mind.

P.S.: Also, seems like (because of that restriction ?) you cannot have multithreading inside a state machine ?

Re: Why developers never use state machines (2011)

#89

Post by BlueTemplar »

hot_gril wrote: post #86
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…

Usually your state is more complicated than just one enum. You'll have counters, buffers, etc. The only time I've ever used a state machine in real code is when parsing text one token at a time or something like that. It's a useful skill to remember for those situations. And this kind of problem is very over-represented in SWE interviews.

Well yes, because state machines are identical to regular expressions... though regular expressions tend to be used quite a lot ?

Re: Why developers never use state machines (2011)

#90

Post by hot_gril »

BlueTemplar wrote: post #89
hot_gril wrote: post #86

Earlier quoted context omitted.

Usually your state is more complicated than just one enum. You'll have counters, buffers, etc. The only time I've ever used a state machine in real code is when parsing text one token at a time or something like that. It's a useful skill to remember for those situations. And this kind of problem is very over-represented in SWE interviews.

Well yes, because state machines are identical to regular expressions... though regular expressions tend to be used quite a lot ?

Yeah, in most cases I won't even get into manual parsing and will use a regex instead. But sometimes I have to break out the FSM.
Post reply on HN