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 164 posts

Re: Why Developers Never Use State Machines (2011)

#41

Post by jpitz »

seanmcdirmid wrote: post #30
jpitz wrote: post #25

Earlier quoted context omitted.

The argument is not that state machines are the child of FP, just that a common idiom in FP, Pattern Matching over ADTs, makes them easy to implement.

This might be, but state machines are so common in imperative code, you could say they are common idiom there also. Pattern matching over ADTs only drives transitions; different representation of transitions can lead to different constructs being more convenient (e.g. if your transitions are just based on a finite set of values, you can use just dictionaries).

That could very well be. My brain tends to map problems to ADTs with very low friction.

Re: Why Developers Never Use State Machines (2011)

#42

Post by nathanyo »

theatrus2 wrote: post #3

Developers use state machines a lot more than they would admit to. Often code would be more readable if the state machine was succinctly defined.

There's a lot of truth to this statement in my experience. I just finished rewriting my homework for my operating systems course and the first version looks awful compared to when I rewrote a chunk of it as a state machine

Re: Why Developers Never Use State Machines (2011)

#43

Post by dominotw »

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.

Is it pretty hard to pick it up for an average programmer?

Re: Why Developers Never Use State Machines (2011)

#44

Post by viraptor »

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…

I don't understand the issue very well... If you have a new event, you either have to handle it in the state machine or some other way. Any place where the event doesn't apply should cause an appropriate failure. Same with new states - you have to write those transitions in some way. You can use macros/abstractions/whatever for simplifying many cases. But none of that code really disappears when you don't use SM.

Re: Why Developers Never Use State Machines (2011)

#45

Post by colanderman »

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…

> if you need to add a new event, each of the states need to be updated to handle that event

Depends on your formalism. I never use state machines of that form for exactly the reason you say. Rather, each state defines the conditions which cause a transition from it. Receiving an event in a state in which it is not expected (say, an I/O completion in a state which should not have outstanding I/O) is a straight-up hard error.

Re: Why Developers Never Use State Machines (2011)

#46

Post by jschwartzi »

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.

I had to do it to implement a 16-instruction loop for the TI RM4's High-End Timers, which are programmable timers that you can offload arbitrary pulse-train generation to, among other things.

http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?li...

Every instruction was a state and I had to model each of the transitions between instructions to understand the program flow.

Re: Why Developers Never Use State Machines (2011)

#47

Post by pdelbarba »

vvanders wrote: post #15
s4vi0r wrote: post #12

Traditional programming languages and imperative thinking don't lend themselves to writing state machines, so its not really that surprising that they're under utilized. Its kind of frustrating constantly reading posts where people shit on functional programm(ers|ing) for being too ivory tower-y or whatever, when its kind of hard not to be when a lot of the older FP guys have spent the last like 20-30 years going "yo…

Plenty of imperative domain spaces use state machines, gamedev and the like come to mind in particular.

Similarly with embedded development. We use them for just about everything from communications to scheduling. I think the subtext here is that state machines are just rarely used for web/mobile...

Re: Why Developers Never Use State Machines (2011)

#48

Post by niftich »

State machines are not a first-class concept in most currently popular high-level programming languages, so when you implement one, you're merely adhering to a design pattern.

While a design pattern is a perfectly legitimate strategy to organize code, it's a manual exercise with no help from the compiler: it's a workaround for the language of choice not being high-level enough for the concepts you're coding.

This is why frameworks useful: they intentionally constrain the problem space, so one can focus on just unique behavior. When one reaches for a framework, they're often using someone else's state machine. Game loops, GUI event loops, or network protocol states are applications of this same pattern.

In some greenfield development, frameworks have a poor reputation for removing developer control. This stems from a misunderstanding: that having a large amount of choices in organizing code is a desirable goal. It very rarely is.

Re: Why Developers Never Use State Machines (2011)

#49

Post by DCoder »

pdelbarba wrote: post #47
vvanders wrote: post #15

Earlier quoted context omitted.

Plenty of imperative domain spaces use state machines, gamedev and the like come to mind in particular.

Similarly with embedded development. We use them for just about everything from communications to scheduling. I think the subtext here is that state machines are just rarely used for web/mobile...

One simplistic state machine in web/mobile is mouse/swipe motion handling – mousedown transitions into "in motion" state, mousemove tracks that state, mouseup transitions into "finished motion" state, runs event handlers, and transitions again into "idle" state.
Post reply on HN