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

Re: Why developers never use state machines (2011)

#31

Post by eyelidlessness »

Joel_Mckay wrote: post #5

Most people attempt to achieve Idempotence whenever possible, and there are several reasons this is desirable in HA systems. Fundamentally, the REST paradigm broke peoples brains, and set many projects on a doomed trajectory into the sun. That being said, for some types of problems a high-latency finite state machine greatly simplifies the complexity of handling data stream consolidation efficiently. The trick is kno…

> Most people attempt to achieve Idempotence whenever possible, and there are several reasons this is desirable in HA systems. Fundamentally, the REST paradigm broke peoples brains, and set many projects on a doomed trajectory into the sun.

Respectfully… wha?

Re: Why developers never use state machines (2011)

#32

Post by bigDinosaur »

RcouF1uZ4gsC wrote: post #6

State machines sounds great in theory, but, and maybe I am unlucky, but often code that starts out as a nice state machine ends up degenerating into spaghetti code.

I agree, my experience is that state machines are great except the ergonomics of using them in programming languages tend to suck. In my experience you really want a great type system with really good inference to help you out as well. Otherwise I find they often descend into stringly typed messes despite the best intentions.

Re: Why developers never use state machines (2011)

#33

Post by rcme »

ratorx wrote: post #29
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…

Surely only if you need to name each state and define every transition. However a sparse representation would be useful here right? If there are fundamentally transitions that are impossible (or errors) then just only define the transitions that make sense and have the rest map to a error condition if they ever come up. Also, if the state space is factorisable (like in your example) then it is easy to represent. You…

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 by states A and B.

Re: Why developers never use state machines (2011)

#34

Post by westoque »

_zephyr wrote: post #27

I'm a big proponent of state machines. They are an excellent tool for unambiguously communicating how a certain critical part of a system should work - to that end, they are not only a coding tool but also a social one to get everyone on the same page. I've wandered several times into a situation where the state is not being well-handled and while it's not often loved, getting the team to hammer out a state machine d…

Same here. I am a big proponent of state machines. I have found that state machines bring sanity to an otherwise complex situation. For example, most inexperienced developers will check presence of certain fields to imply where someone is in the process whereas it would be better written using a state machine.

Re: Why developers never use state machines (2011)

#36

Post by LarsDu88 »

Bader-Meinhoff phenomena for me here, as I read this post while hacking away at refactoring my spaghetti code in Unity into a FiniteStateMachine.

One thing I've found is that the end result can still be spaghetti with an FSM, but if you have tools to edit these things graphically, it becomes very manageable spaghetti!

Re: Why developers never use state machines (2011)

#37

Post by Joel_Mckay »

eyelidlessness wrote: post #31
Joel_Mckay wrote: post #5

Most people attempt to achieve Idempotence whenever possible, and there are several reasons this is desirable in HA systems. Fundamentally, the REST paradigm broke peoples brains, and set many projects on a doomed trajectory into the sun. That being said, for some types of problems a high-latency finite state machine greatly simplifies the complexity of handling data stream consolidation efficiently. The trick is kno…

> Most people attempt to achieve Idempotence whenever possible, and there are several reasons this is desirable in HA systems. Fundamentally, the REST paradigm broke peoples brains, and set many projects on a doomed trajectory into the sun. Respectfully… wha?

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

Re: Why developers never use state machines (2011)

#38

Post by schneems »

vore wrote: post #16
schneems wrote: post #9

The answer is LabVIEW. State machines in a graphical language are a joy and very easy to work with. It’s clear what state you’re looking. At and how to trace the execution. Most text language based state machines are a mess and difficult to reason about. FWIW I maintain a state machine library for Ruby called wicked that (IMHO) isn’t too bad, but can still get gnarly if you’re not careful.

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 that it wasn’t architected and modularized (at all). As the tool is sold as “it’s so intuitively obvious anyone can use it”

I don’t think many people train to use it the same way we were trained. That’s a big bit of the problem.

Hell is always someone else’s code, but if I every had to refactor some labview today, one of the first tools I would reach for would be state machines.

Re: Why developers never use state machines (2011)

#39

Post by Falkon1313 »

I definitely use state machines and quite like them. The benefits are real. And they're mostly quite simple.

However, there can also be complexity. Different customers inevitably want different sets of states and different behaviors on transitions. The pre-transition and post-transition logic can get complex. And it can sometimes be difficult in retrospect to figure out what happened if you didn't log and directly relate the transition event to other things (common if you're using a separate generic state machine library). And sometimes you can end up needing overrides to allow a transition from one state to another that isn't normally allowed, in order to fix bad data or mistakes.

But you can control some of that, and the state machine makes a lot of things easier to reason about.

Re: Why developers never use state machines (2011)

#40

Post by dustingetz »

rcme wrote: post #33
ratorx wrote: post #29

Earlier quoted context omitted.

Surely only if you need to name each state and define every transition. However a sparse representation would be useful here right? If there are fundamentally transitions that are impossible (or errors) then just only define the transitions that make sense and have the rest map to a error condition if they ever come up. Also, if the state space is factorisable (like in your example) then it is easy to represent. You…

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…

now add concurrency, the system state is a superposition of concurrent transitions
Post reply on HN