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

31–40 of 164 posts

Re: Why Developers Never Use State Machines (2011)

#31

Post by ricardobeat »

IamNotAtWork wrote: post #28

I really don't like state machines because if you need to add a new event, each of the states need to be updated to handle that event. If you add a new state, you have to figure out how to handle each of the transitions from other states. So as your states grow, the maintenance on the developer's side grows faster than linear. Additionally, I find that I cannot understand how the program works without actually drawin…

Both of your concerns seem to be nicely addressed by statecharts (nesting to constrain relations + visualization): https://medium.freecodecamp.org/how-to-model-the-behavior-of...

(haven't used this yet)

Re: Why Developers Never Use State Machines (2011)

#32

Post by ricardobeat »

thinkloop wrote: post #18

Fast forward 8 years and everyone on the front end is using state machines with the rise of react/redux et al.

A reducer store is not a state machine since both the transitions and states are loosely defined. That said, at this point I think it's actually better for UI, despite the verbosity and lack of formal correctness.

Re: Why Developers Never Use State Machines (2011)

#34

Post by kchoudhu »

jimmaswell wrote: post #29
housel wrote: post #27

One of my go-to interview questions is "Can you tell me about a time when you've used an explicitly-modeled state machine in your programming?" Our work, heavy in embedded devices, network protocols, and parsing, is so full of state machines that I wouldn't want to hire someone who wasn't comfortable using them.

Compilers and games are two areas I've used them a few times in.

Order/bid management in markets is also a case where they shine.

Re: Why Developers Never Use State Machines (2011)

#36

Post by userbinator »

I would hazard a guess that there are decent state machine libraries for most languages that you can use

I think this is already part of the problem of complexity --- when I think "state machine", what comes to mind is a loop and a switch with some gotos in the cases. Definitely not a library. If you think "I need to use a state machine" and your next thought is "I need to find a library for that", then IMHO you're definitely doing it wrong.

Re: Why Developers Never Use State Machines (2011)

#37

Post by taneq »

RobLach wrote: post #5

If you've ever do any game programming you'll be drowning in state machines.

Or control systems (which is remarkably similar to game programming, really). Basically anything that needs to model on control a system which changes state over time. Sometimes it gets a bit too much, though, and people start seeing every task as a nail for a state-machine hammer.

Re: Why Developers Never Use State Machines (2011)

#39

Post by planteen »

aj7 wrote: post #23

Of course developers whose last experience with state machines was in a college course won’t use them. Just read some of the comments below the article on storks.com. Labview developers use state machines extensively, because the implementation is graphical, beautiful, and prevents loose ends.

I used to do VHDL for FPGAs, where you basically have to use state machines. LabView is that way too, being a dataflow language. But I don't know how much LabView I've seen that I would call beautiful. Maybe if one considers spaghetti beautiful. ;)
Post reply on HN