Why developers never use state machines (2011)

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

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.

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'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.

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