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

71–80 of 121 posts

Re: Why developers never use state machines (2011)

#71

Post by e-dant »

spc476 wrote: post #66
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…

Here's a real-world example from my previous job. A process makes two simultaneous requests (we're on a tight dead line here). Here is the enumerated states we have to code for: send 1,2 -> receive 1, receive 2, process send 1,2 -> receive 2, receive 1, process send 1,2 -> receive 1, timeout 2, process, receive 2 (which is ignored) send 1,2 -> receive 1, timeout 2, process (2 is lost) send 1,2 -> receive 2, timeout 1…

Wouldn’t be hard to make a combinator with function pointers in C.

I do it regularly. They compose well (and you can pass them state for context).

Re: Why developers never use state machines (2011)

#73

Post by Joel_Mckay »

eyelidlessness wrote: post #64
Joel_Mckay wrote: post #37

Earlier quoted context omitted.

If you have under 40k users, than you can get away with a lot of bad choices. =)

Sure, I’m just trying to understand the thing you previously said.

I would recommend David Schmitz's talk: https://www.youtube.com/watch?v=GWgRw5jiYy0

While I don't agree with many of his points (riffs on Erlang/Elixir are silly), there is still some good hints in the talk.

Hope it helps =)

Re: Why developers never use state machines (2011)

#74

Post by sgtnoodle »

strken wrote: post #20

I feel state machines might be better represented as validations happening behind the scenes, e.g. if my coffee machine's state would go from COFFEE_READY to CUP_PLACED then allow it, if it would go straight to COFFEE_POURING with no cup then throw an error. I'm not convinced you need explicit events, and think most of the value is in preventing nonsensical transitions between states.

That reminds me of traffic light controllers at intersections. There's often a main controller, and then also a safety monitor that simply watches for invalid combinations, such as original orthogonal traffic both getting greens.

Re: Why developers never use state machines (2011)

#75

Post by rcme »

_gabe_ wrote: post #56
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…

> 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…

> Annoying sure, but necessary right?

No, not necessary. The key insight here is that the transitions are the hard part. One way to solve this is to write your transitions as a series of asynchronous steps that feed into each other. The end result is an asynchronous chain of operations.

E.g. if you have a video app, playing a video might look like:

1) Read the user metadata from disk.

2) Use the user metadata to make a network request for the video metadata.

3) Deserialize the video metadata on a background thread.

4) Present the video player with the video metadata on the main thread.

You compose each step into a chain of operations. Each step in the chain contains async work as well as logic that “cleans up” the work. So when you want to play a video, your code says “start the complicated video chain.” When you want to stop the video, your code says “stop the video chain.” The chains are a generic sequence of steps, so they can be stopped in the middle. Each step contains its own cleanup logic, so the cleanup of any pending work can happen automatically upon stopping the chain.

tldr: “state” the user is in at any given time is so complex that it’s impossible model with a state machine. It’s easier to think of cascading asynchronous steps instead. A good library for writing this kind of code is called Rx.

Re: Why developers never use state machines (2011)

#76

Post by mansoon »

schneems wrote: post #38
vore wrote: post #16

Earlier quoted context omitted.

I think you are the first person I've seen call LabVIEW a joy ;-)

I worked at NI for two years out of college. Almost everyone in my cohort has never used it and after training most legit were convinced it was going to take over the world. Internally the juice is strong. I ended up working as an “applications engineer” which is a glorified way to say “support”. And I saw some really gnarly code. Just literally spaghetti. I think though the big problem with much of the bad code is t…

And yet they’re doing it.

This idea that modular code matters is bullshit.

Enterprise fizz buzz or spaghetti nightmare.

Learning things isn’t the point, talent is.

Speaking as someone who used to think this stuff mattered, then realized they’d just been wasting their life, instead of isomorphically rearranging thinking patterns on the deck of the trendtanic.

Re: Why developers never use state machines (2011)

#77

Post by taeric »

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…

Amusingly, I will push back that your take is equally strange. The point is clearly on a pattern of programming. Yes, programming is often creating tools that will have states. That is somewhat banal and doesn't help.

Now, I fully grant that there can easily be an explosion of states. I still find it odd to see so much pushback to trying to force a limit on the number of states that we want to support on a UI. We seem to want to allow any number of inner states to transition on a page at any time, and then we wonder at the complexity of the interfaces that we have built up.

Re: Why developers never use state machines (2011)

#78

Post by taeric »

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 is one that you can actually get a lot better mileage by introducing a new state machine, oddly. You have the states A and B, but you also have the state machine for the transition that is T1, T2, and T3. In this world, you have 5 things you need to be able to render/model. A, B, T1, T2, and T3. That the T things will be modeled/rendered inside either A or B can usually be irrelevant.

Even better, if you picked the right abstraction for the T state machine, that same set of modeling can be used elsewhere. (Note, no panacea. You can still pick the wrong abstractions here. Or one that just doesn't help you later, even if it isn't wrong.)

And this is exactly how it is in the physical world. The "payment acceptor" state machine of a vending machine is independent of the vending aspect of the vending machine. It is there solely to create the signal of "payment received" to the machine. Whether that comes from coins, credit cards, phone taps, whatever.

Re: Why developers never use state machines (2011)

#79

Post by rhelz »

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-level programming languages....

Basically, the programming languages we have are the best way we've figured out how to make state machines...

Re: Why developers never use state machines (2011)

#80

Post by sweetjuly »

bryanlarsen wrote: post #17
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 was trained as an EE and occasionally use a state machine in my code. Every other time I've encountered a state machine it was also written by someone trained as an electrical engineer or similar.

This was my experience as well. I could've gone my entire CS education without even needing to think about state machines outside of a short discussion in a formal methods class and regex, but taking a digital logic class really opened my eyes to the power of state machines. They clarify so much of software design by making implicit and adhoc parts of the design explicit. It really is a shame that most CS degrees don't seem to give state machines the credit they deserve.
Post reply on HN