10 ms·

Why developers never use state machines (2011)

93 points by greenie_beans 4y ago

ww520 4y ago
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.
emrah 4y ago
I've used state machines in the context of hardware design, particularly fpgas and asics. In hardware land, you use a state machine to implement something like software, where your circuit is able to remember what happened earlier so it can behave differently accordingly. It's very crude relative to their software counterparts. They are not as common in software because software is one giant state machine already. Variables hold state, there is state within state (classes, composition etc). Sometimes entities in game design have explicit state machines for their behavior but that's to minimize complexity rather than due to absolute necessity
- gaudat 4y ago
  Speaking of CompSci people who cannot into state machines there was one time a contractor wrote some HDL that is a huge number of processes linked to each other with handshaking signals. There are zero state machines in their design. It was a pain to debug it and needless to say it was quite buggy.
WantonQuantum 4y ago
Many moons ago I built a UI using a fairly basic UI toolkit (X/Motif) so I had to handle all the state of the UI menus and dialogs along with the status of the current file (new/saved/unsaved/etc). In the end when it was all working I thought to myself that I should have used a state machine.
mfateev 4y ago
State machines are useful when the same input/event requires different handling based on the current state. There are not that many applications when this is true. Most of the time only two handlers in each state are needed, success and failure, which are much better modeled through a normal code than an explicit state machine. At the framework level they might be pretty useful, but they rarely appear at the first version, but as a result of refactoring.
Joel_Mckay 4y ago
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 knowing when it should be avoided like in shared-state awareness problems... you know, the "lets pause the internet while I do this one op" guy we all work with sometimes... =)
- eyelidlessness 4y ago
  > 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?
  - Joel_Mckay 4y ago
    If you have under 40k users, than you can get away with a lot of bad choices. =)
    - eyelidlessness 4y ago
      Sure, I’m just trying to understand the thing you previously said.
      - Joel_Mckay 4y ago
        I would recommend David Schmitz's talk: https://www.youtube.com/watch?v=GWgRw5jiYy0 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 =)
RcouF1uZ4gsC 4y ago
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.
- bigDinosaur 4y ago
  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.
zombiemama 4y ago
I've used state machines twice, both times for GUIs. It took more time to program than a bunch of messy if-else logic would, but it was well worth it. The knowledge that your GUI can't find itself in an invalid state is realy reasuring, and also it's preety easy to add new states/logic after you get over the initial hump.
- 13of40 4y ago
  Two times I can recall using them in real life were for parsers to identify MIME and CSV files. I thought it was pretty elegant, but zoom forward a few years, and I got to listen to the new guy tell everyone in scrum how he had to fix a bug in there and it was all, ugh, *weird*.
AussieWog93 4y ago
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 of the best examples of where state machines shine. State-machine based ImGuis lower complexity by orders of magnitude, yet, people still resist.
- KRAKRISMOTT 4y ago
  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 the correctness of a button when they could be building features instead. SWEs (at least those with formal CS training) understand state-machines perfectly well. It is the kernel of regular expressions and parsing. Mapping it to a product UI just doesn't make sense all the time.
  - Multicomp 4y ago
    > 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?
    - hot_gril 4y ago
      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.
schneems 4y ago
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.
- vore 4y ago
  I think you are the first person I've seen call LabVIEW a joy ;-)
  - schneems 4y ago
    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.
    - mansoon 4y ago
      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.
samsquire 4y ago
I recently designed a state machine serialization that is extremely powerful. My problem with most state machines is that they are tied to your implementation language. And they are ad hoc. An implementation programming language is itself a state machine - if you think of memory as being the states the machine can be in. My state machine serialization supports and defines behaviour between concurrent threads and collections. It defines a state machine between threads in async/await thread pool Here is the serialization: next_free_thread = 2 task(A) thread(1) assignment(A, 1) = running_on(A, 1) | paused(A, 1) running_on(A, 1) thread(1) assignment(A, 1) thread_free(next_free_thread) = fork(A, B) | send_task_to_thread(B, next_free_thread) | running_on(B, 2) paused(B, 1) running_on(A, 1) | { yield(B, returnvalue) | paused(B, 2) } { await(A, B, returnvalue) | paused(A, 1) } | send_returnvalue(B, A, returnvalue) This defined a progression of a task on a thread and that can fork to a background task and then synchronize with a yield later on
WheelsAtLarge 4y ago
I programed a State Machine app once in my career and it was much much more difficult to program than ordinary C# code development. It took a very long time to develop the app for MS sharepoint that required it many years ago. I remember calling MS support and even they could no really help me. I spoke to them for hours eventually and I got nothing done. I had to figure it out myself. I think it requires a different way of thinking than what developers are used to. It was not worth the time and effort.
geenat 4y ago
As someone who started in video game development... ...beyond trivial stuff like pong, the natural pattern is just a big collection of state machines (as entities) interacting with each other.
- city41 4y ago
  I always use state machines when writing a game. It's natural and simple. But I've never used a state machine for any other type of software.
stevebmark 4y ago
As a regular user of the state_machine Ruby gem, I wouldn't recommend it. If you don't believe me, just check out the "Class definition" section of the usage examples: https://github.com/state-machines/state_machines#usage https://github.com/state-machines/state_machines#usage The problems are obvious. It's built on magic and indirection. This leads to difficult to debug state machine problems. For anything beyond simple state machines you quickly lose any idea of what your object is doing.
- Arubis 4y ago
  I’d strongly recommend Statesman instead: https://gocardless.com/blog/statesman/ https://gocardless.com/blog/statesman/ I’m unaffiliated, just have used a lot of Ruby SM libraries.
  - stevebmark 4y ago
    Looks just as bad tbh, mixins and magic, I don't think you can really do this well in Ruby.
babblingfish 4y ago
State machines are commonly used in game development.
fleventynine 4y ago
Computers ARE state machines and the primary purpose of a programming language is to help humans manage all this state.
- e-dant 4y ago
  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
  - sweetjuly 4y ago
    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).
strken 4y ago
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.
- sgtnoodle 4y ago
  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.
FpUser 4y ago
Not sure what developers are they talking about. I was using state machines since the 90s. Even wrote business process middleware and management front end to it based on the concept.
_zephyr 4y ago
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 does wonders for system reliability. It's true that they have limitations and are not always the right tool, but it's often valuable to realize that you implicitly have a state machine already whether you wish you did or not.
- westoque 4y ago
  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.
bryanlarsen 4y ago
Language tooling makes a big difference on whether state machines work well in your code or not. Rust is awesome for state machine. The "enum" type can hold data, and modern Rust has a bunch of convenient ways for destructuring enum's.
Normal_gaussian 4y ago
login & signup flows, batch management, request retry/backoff/error, data compliance. State machines are ridiculously common - we just don't need to import a library to do it.
LarsDu88 4y ago
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!
Falkon1313 4y ago
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.
e-dant 4y ago
Better question: Why do we endlessly produce so much state?
- stefncb 4y ago
  Huh? Computation can't happen without state. Everything you make has a state, otherwise it won't really do anything interesting.
  - e-dant 4y ago
    Balance in all things Edit: eh, that comment didn’t really say much. What I meant was that there are classes of algorithms that are stateless. Maybe the most useful are proofs. Look, I’m a C++ dev. I live and breathe state. Weird, mostly-working gadgets are the real humans of the world. But that doesn’t mean I don’t use linear types and write unit tests for my function composition. Sure, I’ll let closures capture their context, and I’ll allow pass-by-reference in my APIs, but that doesn’t mean I encourage it.
    - stefncb 4y ago
      > What I meant was that there are classes of algorithms that are stateless. Can you give me an example?
      - e-dant 4y ago
        Practically speaking, any algorithm that does the same thing given the same input is said to be stateless. This property becomes more useful when you’re trying to prove something about a function’s behavior over a bunch of well-defined types. Languages like Haskell and Agda have these properties. Rust also has some of these properties by default. It has an affine type system (the borrow checker) enforces some guardrails on ad-hoc state manipulation. C++ has linear-esque types in its pointers and higher-kinded types in the concepts and constraints features.
        stefncb 4y ago
neilv 4y ago
My early Swift UI app might not have worked as well as it did, had I not modeled the UI as hierarchical state machines. But I think that a lot of the dialogue I see around state machines in programming is effectively strawperson. Much like the dialogue around DSLs in programming. People end up debating over weak examples, and then dismissing valuable ideas.
HankB99 4y ago
I suppose applicability depends on the problem domain. In embedded systems that control some device I've found them very useful, particularly as the logic becomes complex. () Perhaps for other realms such as Web back ends that tend to be transactional, they are less useful. () Many years ago I was tasked with coding a replacement for a device that operated from discrete logic involving a number of inputs, timers, decisions and actions based on all of these. The first thing I did was to model it as a state machine and everything went well except for one part where it was not clear what the next state should be based on the inputs. I reviewed this with an engineer familiar with the existing logic and he shared with me that the actual behavior of the device was indeterminate in that particular situation. That was easily fixed with the state machine.
dustingetz 4y ago
2011 article is comparing against OOP, the FP perspective here is that we want to remove state from our systems
e-dant 4y ago
Woah — with all the declarative and functional languages, looks like someone has just discovered a (stateful) state machine. They’re trying to convince us that this is a useful thing in a hypothetical situation where people do ridiculous, unsafe things on an ad-hoc basis. Not sure I’m buying it. Oh, wrong universe. Edit: I use state, too. I get it. I just dislike it. It doesn’t usually compose and is rarely safe.
- kaba0 4y ago
  It is not hard to argue that several FP abstractions are basically state machines themselves, their transition function is simply recursively defined. For a trivial example, objects defining the Applicable trait.
  - e-dant 4y ago
    Which abstractions? I could see a monad being defined as a list of (typed) states with a functor. But they’re still stateless. I could also see immutable data structures being implemented in a stateful way (they usually are in non-FP languages).
    - deleted 4y ago
      [deleted]
robomartin 4y ago
Interesting. I use state machines all the time, mostly in FPGA's yet also in software, embedded and beyond. Yes, you do have to develop a sense of when and how to use them. One of my software techniques is to use a state machine to initially solve and understand a problem. Once done and working, you can start to chip away at the state machine, eliminate states and sometimes refactor the code into something faster or more efficient that completely eliminates the state machine. The other aspect of this is that state machines can, in some cases, add a layer of safety and failure mitigation. In the end, it really depends on the nature of the project.
rr808 4y ago
Nearly every app I've worked on has had some type of workflow, with an enumeration type and rules to go from one state to the next.
po 4y ago
My belief is that part of the reason state machines are not used often is: - State machine libraries are good at expressing an existing state machine but often the workflow for upgrading or modifying it in production is lacking. If you want to remove a state for instance, it's still very hard and the tooling just makes it more obtuse. - The reason class hierarchies as a way to model your problem are overused in most programming languages is not because it's good, but because it's a language feature that's taught by every book that covers that language. If state machines had language-level support/keywords, more people would use them. (Interestingly, I think part of why class hierarchies can be a trap is similar to the first issue above with state machines: they are hard to change down the road as you learn more about your problem space.)
- joshka 4y ago
  Yep, the teaching is the problem (and this generalizes). I just went and took a bit of a look at my alma mata's IT degree. It's still teaching a variety of data orientated approaches to system design. I.e. state without transitions.
zht 4y ago
Aasm works quite well in Rails land
pitched 4y ago
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.
- sweetjuly 4y ago
  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
  - Tangurena2 4y ago
    The last state machine I was involved with had to do with possible conditions when registering vehicles. What must be done if it was reported stolen (by NCIS) was coded in laws and regulations. What has to happen if the customer decides not to register it after all. Or they call up and go "hey! where's my title?" There were all sorts of edge cases that had to be unambiguously defined and documented. 99% of registrations followed the "happy path", but that last little bit caused all of the trouble. The printed version was an 11x17" flowchart with the "happy path" taking up less than 1/4 of it.
- ihatepython 4y ago
  There is no line. An instance of an object is a state machine. Everybody is arguing over nomenclature.
Viper512 4y ago
I worked at a company on the front end team while a foundation team senior developer coerced the management into this whole state machine thing. It was overly complex for what it produced. .... We needed an API.. everything got rewritten 3 times before it was actually released because it was too complex and served zero purpose.
wyldfire 4y ago
Any discussion of "state machines" is not complete without a mention of Statecharts (or Harel Statecharts) [1] [2] [3]. The hierarchy and triggered actions are a really excellent way of representing a state machine. [1] https://en.wikipedia.org/wiki/State_diagram#Harel_statechart https://en.wikipedia.org/wiki/State_diagram#Harel_statechart [2] https://statecharts.dev/ https://statecharts.dev/ [3] https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.pdf https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts....
moloch-hai 4y ago
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 anyway some) programming language is not being used to manage its complexity. So in practice we emulate only the simplest of state machines explicitly. A programmer writing such a program is sometimes said to be in a state of sin.
- taeric 4y ago
  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.
- rhelz 4y ago
  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...
  - BlueTemplar 4y ago
    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 ?
dang 4y ago
Related: Why Developers Never Use State Machines - https://news.ycombinator.com/item?id=20875583 https://news.ycombinator.com/item?id=20875583 - Sept 2019 (1 comment) Why Developers Never Use State Machines (2011) - https://news.ycombinator.com/item?id=16470262 https://news.ycombinator.com/item?id=16470262 - Feb 2018 (161 comments) Why Developers Never Use State Machines (2011) - https://news.ycombinator.com/item?id=12204038 https://news.ycombinator.com/item?id=12204038 - Aug 2016 (1 comment) Why Developers Never Use State Machines - https://news.ycombinator.com/item?id=2949543 https://news.ycombinator.com/item?id=2949543 - Sept 2011 (92 comments)
deleted 4y ago
[deleted]
not_the_fda 4y ago
I love hierarchical state machines. I've used them on so many projects, they simplify the design and make it easier to modify.
sorenjan 4y ago
Does anyone have a recommendation for an article or similar about implementing state machines? I've only used the simple "switch on an enum" variant (switch(stateVar) case STATE1: doWork(); stateVar = STATE2; break;). I think it's pretty elegant, but it's limited to small and simple problems.
- dogleash 4y ago
  Practical Statecharts in C/C++: https://www.amazon.com/Practical-Statecharts-Quantum-Programming-Embedded/dp/1578201101 https://www.amazon.com/Practical-Statecharts-Quantum-Program... Or more generically, look into Hierarchical State Machines. There's a few insights that you can apply to your state machines that will give you most of the power you'll ever need: 1. Rather than storing an enum in your state variable, store a function pointer to state-functions. 2. Rather than have the states check outward for data to operate on, pass in a generic event type. There will still be some amount of looking outward, perfection is the enemy of good (a simple enum that the state function switch()-es on is enough to experiment with the idea). 3. Have a single entry point that takes an event and dispatches it to the states. That way you can trigger an arbitrary number of events to the state machine for any one external event (like after a transition, sending in "state exited" and "state entered" events). 4. Hierarchy: Add a mechanism by which a state-function can ignore the event, and the dispatching code sends the event to the state's parent state instead. I think the rest that I gained from reading about and working with complex state machines is about creating good APIs for dealing with the ideas above, and to design the state diagram on paper before implementing. I rarely use the full complexity of the "QHsm" described in the book I linked, but the concepts aren't strangers and I'll often start with a switch(_state){} and sprinkle in features as needed.
throwaway5947 4y ago
Unrealscript has a notion of states built into the language. https://wiki.beyondunreal.com/States https://wiki.beyondunreal.com/States
scotty79 4y ago
Lack of first class support for them in the computer languages.
rozhok 4y ago
I love state machines since my CS classes. I've wrote chatbot engine using this pattern; it was big success for my customer.
deterministic 4y ago
I am a developer. I use state machines all the time. I have even written code generators that auto generate hierarchical state machines. Because they are really useful for managing complex logic.
deleted 4y ago
[deleted]

93 points by greenie_beans 4y ago

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.

emrah 4y ago

I've used state machines in the context of hardware design, particularly fpgas and asics. In hardware land, you use a state machine to implement something like software, where your circuit is able to remember what happened earlier so it can behave differently accordingly. It's very crude relative to their software counterparts. They are not as common in software because software is one giant state machine already. Variables hold state, there is state within state (classes, composition etc). Sometimes entities in game design have explicit state machines for their behavior but that's to minimize complexity rather than due to absolute necessity

gaudat 4y ago
Speaking of CompSci people who cannot into state machines there was one time a contractor wrote some HDL that is a huge number of processes linked to each other with handshaking signals. There are zero state machines in their design. It was a pain to debug it and needless to say it was quite buggy.

WantonQuantum 4y ago

Many moons ago I built a UI using a fairly basic UI toolkit (X/Motif) so I had to handle all the state of the UI menus and dialogs along with the status of the current file (new/saved/unsaved/etc). In the end when it was all working I thought to myself that I should have used a state machine.

mfateev 4y ago

State machines are useful when the same input/event requires different handling based on the current state. There are not that many applications when this is true. Most of the time only two handlers in each state are needed, success and failure, which are much better modeled through a normal code than an explicit state machine. At the framework level they might be pretty useful, but they rarely appear at the first version, but as a result of refactoring.

Joel_Mckay 4y ago

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 knowing when it should be avoided like in shared-state awareness problems... you know, the "lets pause the internet while I do this one op" guy we all work with sometimes... =)

eyelidlessness 4y ago
> 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?
- Joel_Mckay 4y ago
  If you have under 40k users, than you can get away with a lot of bad choices. =)
  - eyelidlessness 4y ago
    Sure, I’m just trying to understand the thing you previously said.
    - Joel_Mckay 4y ago
      I would recommend David Schmitz's talk: https://www.youtube.com/watch?v=GWgRw5jiYy0 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 =)

RcouF1uZ4gsC 4y ago

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.

bigDinosaur 4y ago
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.

zombiemama 4y ago

I've used state machines twice, both times for GUIs. It took more time to program than a bunch of messy if-else logic would, but it was well worth it. The knowledge that your GUI can't find itself in an invalid state is realy reasuring, and also it's preety easy to add new states/logic after you get over the initial hump.

13of40 4y ago
Two times I can recall using them in real life were for parsers to identify MIME and CSV files. I thought it was pretty elegant, but zoom forward a few years, and I got to listen to the new guy tell everyone in scrum how he had to fix a bug in there and it was all, ugh, *weird*.

AussieWog93 4y ago

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 of the best examples of where state machines shine. State-machine based ImGuis lower complexity by orders of magnitude, yet, people still resist.

KRAKRISMOTT 4y ago
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 the correctness of a button when they could be building features instead. SWEs (at least those with formal CS training) understand state-machines perfectly well. It is the kernel of regular expressions and parsing. Mapping it to a product UI just doesn't make sense all the time.
- Multicomp 4y ago
  > 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?
  - hot_gril 4y ago
    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.

schneems 4y ago

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.

vore 4y ago
I think you are the first person I've seen call LabVIEW a joy ;-)
- schneems 4y ago
  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.
  - mansoon 4y ago
    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.

samsquire 4y ago

I recently designed a state machine serialization that is extremely powerful. My problem with most state machines is that they are tied to your implementation language. And they are ad hoc. An implementation programming language is itself a state machine - if you think of memory as being the states the machine can be in. My state machine serialization supports and defines behaviour between concurrent threads and collections. It defines a state machine between threads in async/await thread pool Here is the serialization: next_free_thread = 2 task(A) thread(1) assignment(A, 1) = running_on(A, 1) | paused(A, 1) running_on(A, 1) thread(1) assignment(A, 1) thread_free(next_free_thread) = fork(A, B) | send_task_to_thread(B, next_free_thread) | running_on(B, 2) paused(B, 1) running_on(A, 1) | { yield(B, returnvalue) | paused(B, 2) } { await(A, B, returnvalue) | paused(A, 1) } | send_returnvalue(B, A, returnvalue) This defined a progression of a task on a thread and that can fork to a background task and then synchronize with a yield later on

WheelsAtLarge 4y ago

I programed a State Machine app once in my career and it was much much more difficult to program than ordinary C# code development. It took a very long time to develop the app for MS sharepoint that required it many years ago. I remember calling MS support and even they could no really help me. I spoke to them for hours eventually and I got nothing done. I had to figure it out myself. I think it requires a different way of thinking than what developers are used to. It was not worth the time and effort.

geenat 4y ago

As someone who started in video game development... ...beyond trivial stuff like pong, the natural pattern is just a big collection of state machines (as entities) interacting with each other.

city41 4y ago
I always use state machines when writing a game. It's natural and simple. But I've never used a state machine for any other type of software.

stevebmark 4y ago

As a regular user of the state_machine Ruby gem, I wouldn't recommend it. If you don't believe me, just check out the "Class definition" section of the usage examples: https://github.com/state-machines/state_machines#usage https://github.com/state-machines/state_machines#usage The problems are obvious. It's built on magic and indirection. This leads to difficult to debug state machine problems. For anything beyond simple state machines you quickly lose any idea of what your object is doing.

Arubis 4y ago
I’d strongly recommend Statesman instead: https://gocardless.com/blog/statesman/ https://gocardless.com/blog/statesman/ I’m unaffiliated, just have used a lot of Ruby SM libraries.
- stevebmark 4y ago
  Looks just as bad tbh, mixins and magic, I don't think you can really do this well in Ruby.

babblingfish 4y ago

State machines are commonly used in game development.

fleventynine 4y ago

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

e-dant 4y ago
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
- sweetjuly 4y ago
  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).

strken 4y ago

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.

sgtnoodle 4y ago
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.

FpUser 4y ago

Not sure what developers are they talking about. I was using state machines since the 90s. Even wrote business process middleware and management front end to it based on the concept.

_zephyr 4y ago

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 does wonders for system reliability. It's true that they have limitations and are not always the right tool, but it's often valuable to realize that you implicitly have a state machine already whether you wish you did or not.

westoque 4y ago
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.

bryanlarsen 4y ago

Language tooling makes a big difference on whether state machines work well in your code or not. Rust is awesome for state machine. The "enum" type can hold data, and modern Rust has a bunch of convenient ways for destructuring enum's.

Normal_gaussian 4y ago

login & signup flows, batch management, request retry/backoff/error, data compliance. State machines are ridiculously common - we just don't need to import a library to do it.

LarsDu88 4y ago

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!

Falkon1313 4y ago

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.

e-dant 4y ago

Better question: Why do we endlessly produce so much state?

stefncb 4y ago
Huh? Computation can't happen without state. Everything you make has a state, otherwise it won't really do anything interesting.
- e-dant 4y ago
  Balance in all things Edit: eh, that comment didn’t really say much. What I meant was that there are classes of algorithms that are stateless. Maybe the most useful are proofs. Look, I’m a C++ dev. I live and breathe state. Weird, mostly-working gadgets are the real humans of the world. But that doesn’t mean I don’t use linear types and write unit tests for my function composition. Sure, I’ll let closures capture their context, and I’ll allow pass-by-reference in my APIs, but that doesn’t mean I encourage it.
  - stefncb 4y ago
    > What I meant was that there are classes of algorithms that are stateless. Can you give me an example?
    - e-dant 4y ago
      Practically speaking, any algorithm that does the same thing given the same input is said to be stateless. This property becomes more useful when you’re trying to prove something about a function’s behavior over a bunch of well-defined types. Languages like Haskell and Agda have these properties. Rust also has some of these properties by default. It has an affine type system (the borrow checker) enforces some guardrails on ad-hoc state manipulation. C++ has linear-esque types in its pointers and higher-kinded types in the concepts and constraints features.
      - stefncb 4y ago

neilv 4y ago

My early Swift UI app might not have worked as well as it did, had I not modeled the UI as hierarchical state machines. But I think that a lot of the dialogue I see around state machines in programming is effectively strawperson. Much like the dialogue around DSLs in programming. People end up debating over weak examples, and then dismissing valuable ideas.

HankB99 4y ago

I suppose applicability depends on the problem domain. In embedded systems that control some device I've found them very useful, particularly as the logic becomes complex. () Perhaps for other realms such as Web back ends that tend to be transactional, they are less useful. () Many years ago I was tasked with coding a replacement for a device that operated from discrete logic involving a number of inputs, timers, decisions and actions based on all of these. The first thing I did was to model it as a state machine and everything went well except for one part where it was not clear what the next state should be based on the inputs. I reviewed this with an engineer familiar with the existing logic and he shared with me that the actual behavior of the device was indeterminate in that particular situation. That was easily fixed with the state machine.

dustingetz 4y ago

2011 article is comparing against OOP, the FP perspective here is that we want to remove state from our systems

e-dant 4y ago

Woah — with all the declarative and functional languages, looks like someone has just discovered a (stateful) state machine. They’re trying to convince us that this is a useful thing in a hypothetical situation where people do ridiculous, unsafe things on an ad-hoc basis. Not sure I’m buying it. Oh, wrong universe. Edit: I use state, too. I get it. I just dislike it. It doesn’t usually compose and is rarely safe.

kaba0 4y ago
It is not hard to argue that several FP abstractions are basically state machines themselves, their transition function is simply recursively defined. For a trivial example, objects defining the Applicable trait.
- e-dant 4y ago
  Which abstractions? I could see a monad being defined as a list of (typed) states with a functor. But they’re still stateless. I could also see immutable data structures being implemented in a stateful way (they usually are in non-FP languages).
  - deleted 4y ago
    [deleted]

robomartin 4y ago

Interesting. I use state machines all the time, mostly in FPGA's yet also in software, embedded and beyond. Yes, you do have to develop a sense of when and how to use them. One of my software techniques is to use a state machine to initially solve and understand a problem. Once done and working, you can start to chip away at the state machine, eliminate states and sometimes refactor the code into something faster or more efficient that completely eliminates the state machine. The other aspect of this is that state machines can, in some cases, add a layer of safety and failure mitigation. In the end, it really depends on the nature of the project.

rr808 4y ago

Nearly every app I've worked on has had some type of workflow, with an enumeration type and rules to go from one state to the next.

po 4y ago

My belief is that part of the reason state machines are not used often is: - State machine libraries are good at expressing an existing state machine but often the workflow for upgrading or modifying it in production is lacking. If you want to remove a state for instance, it's still very hard and the tooling just makes it more obtuse. - The reason class hierarchies as a way to model your problem are overused in most programming languages is not because it's good, but because it's a language feature that's taught by every book that covers that language. If state machines had language-level support/keywords, more people would use them. (Interestingly, I think part of why class hierarchies can be a trap is similar to the first issue above with state machines: they are hard to change down the road as you learn more about your problem space.)

joshka 4y ago
Yep, the teaching is the problem (and this generalizes). I just went and took a bit of a look at my alma mata's IT degree. It's still teaching a variety of data orientated approaches to system design. I.e. state without transitions.

zht 4y ago

Aasm works quite well in Rails land

pitched 4y ago

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.

sweetjuly 4y ago
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
- Tangurena2 4y ago
  The last state machine I was involved with had to do with possible conditions when registering vehicles. What must be done if it was reported stolen (by NCIS) was coded in laws and regulations. What has to happen if the customer decides not to register it after all. Or they call up and go "hey! where's my title?" There were all sorts of edge cases that had to be unambiguously defined and documented. 99% of registrations followed the "happy path", but that last little bit caused all of the trouble. The printed version was an 11x17" flowchart with the "happy path" taking up less than 1/4 of it.
ihatepython 4y ago
There is no line. An instance of an object is a state machine. Everybody is arguing over nomenclature.

Viper512 4y ago

I worked at a company on the front end team while a foundation team senior developer coerced the management into this whole state machine thing. It was overly complex for what it produced. .... We needed an API.. everything got rewritten 3 times before it was actually released because it was too complex and served zero purpose.

wyldfire 4y ago

Any discussion of "state machines" is not complete without a mention of Statecharts (or Harel Statecharts) [1] [2] [3]. The hierarchy and triggered actions are a really excellent way of representing a state machine. [1] https://en.wikipedia.org/wiki/State_diagram#Harel_statechart https://en.wikipedia.org/wiki/State_diagram#Harel_statechart [2] https://statecharts.dev/ https://statecharts.dev/ [3] https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.pdf https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts....

moloch-hai 4y ago

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 anyway some) programming language is not being used to manage its complexity. So in practice we emulate only the simplest of state machines explicitly. A programmer writing such a program is sometimes said to be in a state of sin.

taeric 4y ago
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.
rhelz 4y ago
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...
- BlueTemplar 4y ago
  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 ?

dang 4y ago

Related: Why Developers Never Use State Machines - https://news.ycombinator.com/item?id=20875583 https://news.ycombinator.com/item?id=20875583 - Sept 2019 (1 comment) Why Developers Never Use State Machines (2011) - https://news.ycombinator.com/item?id=16470262 https://news.ycombinator.com/item?id=16470262 - Feb 2018 (161 comments) Why Developers Never Use State Machines (2011) - https://news.ycombinator.com/item?id=12204038 https://news.ycombinator.com/item?id=12204038 - Aug 2016 (1 comment) Why Developers Never Use State Machines - https://news.ycombinator.com/item?id=2949543 https://news.ycombinator.com/item?id=2949543 - Sept 2011 (92 comments)

deleted 4y ago

[deleted]

not_the_fda 4y ago

I love hierarchical state machines. I've used them on so many projects, they simplify the design and make it easier to modify.

sorenjan 4y ago

Does anyone have a recommendation for an article or similar about implementing state machines? I've only used the simple "switch on an enum" variant (switch(stateVar) case STATE1: doWork(); stateVar = STATE2; break;). I think it's pretty elegant, but it's limited to small and simple problems.

dogleash 4y ago
Practical Statecharts in C/C++: https://www.amazon.com/Practical-Statecharts-Quantum-Programming-Embedded/dp/1578201101 https://www.amazon.com/Practical-Statecharts-Quantum-Program... Or more generically, look into Hierarchical State Machines. There's a few insights that you can apply to your state machines that will give you most of the power you'll ever need: 1. Rather than storing an enum in your state variable, store a function pointer to state-functions. 2. Rather than have the states check outward for data to operate on, pass in a generic event type. There will still be some amount of looking outward, perfection is the enemy of good (a simple enum that the state function switch()-es on is enough to experiment with the idea). 3. Have a single entry point that takes an event and dispatches it to the states. That way you can trigger an arbitrary number of events to the state machine for any one external event (like after a transition, sending in "state exited" and "state entered" events). 4. Hierarchy: Add a mechanism by which a state-function can ignore the event, and the dispatching code sends the event to the state's parent state instead. I think the rest that I gained from reading about and working with complex state machines is about creating good APIs for dealing with the ideas above, and to design the state diagram on paper before implementing. I rarely use the full complexity of the "QHsm" described in the book I linked, but the concepts aren't strangers and I'll often start with a switch(_state){} and sprinkle in features as needed.

throwaway5947 4y ago

Unrealscript has a notion of states built into the language. https://wiki.beyondunreal.com/States https://wiki.beyondunreal.com/States

scotty79 4y ago

Lack of first class support for them in the computer languages.

rozhok 4y ago

I love state machines since my CS classes. I've wrote chatbot engine using this pattern; it was big success for my customer.

deterministic 4y ago

I am a developer. I use state machines all the time. I have even written code generators that auto generate hierarchical state machines. Because they are really useful for managing complex logic.

deleted 4y ago

[deleted]