Hacker News Reader

Comment by renlo | Hacker News Reader

Can someone recommend a good primer on _implementing state machines_? I’ve only really encountered the theory and the diagrams, but have had a harder time finding examples of actual implementations in code.

View on HN

There're different ways to implement a state machine, table-driven, object-driven, function pointer driven, callback based, etc. If you just want a simple and hard coded sate machine, nothing beats switch statements. You can do something like the following.

    enum State { S1, S2, S3, S4, ... , END }
    
    State transition(State current_state, int input) {
        switch current_state
            case S1:
                switch input
                    case 100: new_state = S3
                              do_action1()
                    case 101: new_state = S4
                              do_action2()
                    default:  error()
            case S2:
                switch input
                    case 100: new_state = S3
                              do_action3()
                    case 206: new_state = S11
                              do_action4()
                    case 207: new_state = S12
                              do_action5()
                    case 208: new_state = S19
                              do_action6()
                    default:  error()
            case S3:
                switch input
                    ...
            ...
    
         return new_state
    }

    run_state_machine(int[] inputs) {
        State state = S1
        foreach input in inputs
            state = transition(state, input)

    }

That's it. It's simple to understand and it's clear what the legal transitions are from each state based on the input. You can attach actions and data update on each state transition to do something useful.

The primer is simple: if you notice that your code is using too many if statements, especially nested ones, and you are starting to wonder if you are covering all alternatives and cases, then using the rigor of a state machine may help.

You know, that kind of code:

  if(start) {
    if(!running) ...
  }
  
  if(stopped & !jumping) {
  } else if(running) ...

Stop and write a proper case statement (aka a state machine). You may discover that combinations of booleans (in my example, stopped & !jumping) deserve to be their own state. The insight is that the resulting code should be one clean case statement, with no nested ifs allowed. Then you know you cover all the states/cases.

“If” conditions and state machines are not mutually exclusive. You can implement a proper State machine with “If” conditions.

That switch-case alternative you’re suggesting? That’s just another manifestation of the same concept behind “If” conditions. So, really, with case statements, you’re still implementing nested conditions, just in mixed ways (a mix of case statements and “If” conditions)

The distinguishing characteristic between state machine and bad logic is that the top level conditions are the states, rather than the inputs.

EDIT: for clarity.

Programming is state machines all the way down, it's just the convenience of expression that makes a difference.

More than just convenience of expression, it guards against "impossible states." This article[1] does a good job of explaining it.

[1] https://dev.to/davidkpiano/you-don-t-need-a-library-for-stat...

I had a job interview question: "In Python, write a class to implement a state machine."

Me: So, each instance should represent a state, and include a list of states it could transition to, and methods to transition to them? Is that what you had in mind?

Them: Well, if that's what you think a state machine is, then sure.

Me: There are a million ways I could implement this. What context will this be used in? I can make sure I write something that meets those requirements.

Them: Do you not know what a state machine is?

Me: Of course. But how are you planning to use it?

Them: I can't believe you don't know what a state machine is.

So as far as I can tell, I have no idea how to implement one.

(I'm so glad I didn't get that job.)

You're overthinking it. The first reply was basically a "go ahead and do what you think is right".

They're probably glad they didn't hire you either.

Or they realized in that moment they didn't feel confident enough in their own understanding of state machines to critique anyone who might take the opportunity to cut them down to size. It is a stupid reaction to a sensible request for clarification, there are tons of equally valid ways to implement a state machine in an object oriented python script - especially when there are zero constraints on expected use. If I'd asked such a question, and got no sense of pushback, I'd be a little nervous about hiring that person and having them need close supervision - because they were to scared to point out ambiguity in direction.

there are tons of equally valid ways to implement a state machine in an object oriented python script

...and chances are that the interviewer would be fine with any of them, or ask questions after you've shown a solution.

If I'd asked such a question, and got no sense of pushback, I'd be a little nervous about hiring that person and having them need close supervision - because they were to scared to point out ambiguity in direction.

That's the exact opposite impression I have; someone who doesn't need to ask many questions, as long as they can justify their decisions well, is definitely more preferable to someone who constantly asks and needs to be lead every little step of the way.

> ...definitely more preferable to someone who constantly asks and needs to be lead every little step of the way.

Asking for clarification before starting isn't anywhere close to "needs to be lead every little step". If you are hiring a work crew for roadside ditch digging than your interview method might be a good idea, but for a job where implementation details matter - bad idea. One of my more difficult professional experiences was fighting the urge to displace blame for a wasted week of work, which would have been avoided had I asked for the tasking to be described back to me - or had he spoken up and said "Do you mean this or that?"

the question was about a state machine. could there be a more general task to give a programmer? certainly no task would ever be assigned to them on the job that would be anywhere near that general.

questions like that don't show you how they'll be on the job, they're an opportunity to see their thought process, but you won't get that without talking to them.

The first reply is passive-aggressive and is inappropriate in the context of an interview (assuming that's word for word what has been said).

A better answer would be either "Yep sounds good to me" or something along the lines of "Let's step back and first define what a state machine should do".

Even if GP was not getting the job it is the responsibility of a good interviewer that GP leaves the room having learned something. If GP left this interview still not knowing what a state machine is (or what the interviewer thinks a state machine is) or no closer to an implementation of a state machine then the interviewer has failed as much as the candidate.

it is the responsibility of a good interviewer that GP leaves the room having learned something. If GP left this interview still not knowing what a state machine is (or what the interviewer thinks a state machine is) or no closer to an implementation of a state machine then the interviewer has failed as much as the candidate.

I strongly disagree. An interview is an assessment, not a tutorial.

I’m a staff-level engineer with thousands of LoC on GitHub, and many times that inside my employers’ repos. I know how to program. I wasn’t asking them to teach me what a state machine is or how to write one. Instead, I was trying to narrow down a thousand possibilities to the ones that would meet their requirements. You know, like I’d be doing on the job if they’d hired me.

When the CTO says “we need a thing”, I don’t sit down and start writing. I try to learn what we’ll need so I can build something that satisfies my stakeholders’ needs.

If I were interviewing you, and said “hey userbinator, make a paragraph”, and you did that without asking WTF I was talking about, the rest of the session may not go well.

i'm not so sure the first reply was, "go ahead and do what you think is right", it could've just as easily been, "guess what i'm thinking." actually, their refusal to talk about what they were asking for makes it more probable that it was the second one.

they may be glad they didn't hire them, it's hard to say how they feel, but i bet they're one of those companies out their complaining they can't seem to hire anyone at any price.

That sounds to me as if the interviewer had said "write a program". It seems rather natural to ask "OK. What do you want the program to do? Shall I write a program that takes some input, and outputs it reversed? Would that do?", and they said "If that's what you think a program is, then sure."

At that point, it's probably best to stop arguing, and code. They probably want to argue with you about your code, not their spec.

But when I got the reply "Do you not know what a state machine is?", I think I might have thanked them for their time, and left. I would have been sorely tempted to come back with "Yes, a state machine is an abstraction, and you seem to want a concrete implementation, but you don't seem to want to fill in the details of your requirement. Is it a good use of our time together for me to complete your spec, so there's something for me to code up?"

It sounds like they didn't want you; perhaps your face didn't fit. They say most interviews are decided in the first couple of minutes.

I recently did an interview that went something like this too. The questions weren’t state machines. But like your experience, they boiled down to “I have some interesting experiences that feel kind of unique to me, is it possible you’ve had them too?” It was a mid level relatively seasoned person, but they admitted interviewing was kinda new. So it really came back to that “do you think we could experience a sort of cohort chemistry here” vetted by a pretty arbitrary set of “let’s find some geeky things to get connect about.” And like you, I’m not disappointed they chose to keep looking.

How to implement a state machine in Python:

    def next_state(state):
      if state == 90000:
        return 0
      return state + 1

But more seriously; once I was asked to implement offsetof in an interview for an entry level C++ position. I didn't quite remember that this was impossible during the heat of the interview, but I did remember enough to not produce an incorrect solution that relies on undefined behavior. I didn't get that job.

Expected them to hand you over a formal specification so you could develop their systems as well? Dear God...

I talk about a couple of implementation styles for state machines in "Game Programming Patterns" here:

https://gameprogrammingpatterns.com/state.html

Thank you for writing this book and crafting interpreters and making them freely available. They were genuinely enlightening books.

You're welcome! :D

JavaScript has libraries for this (xstate) but I usually just do it something like this in typescript:

    enum State { A, B, C };
    enum Action { A, B };
    
    type StateData = 
      | { state: State.A, data: whatever }
      | { state: State.B, data: whatever }
      | { state: State.C, data: whatever };
    
    type ActionData = 
      | { type: Action.A, data: whatever }
      | { type: Action.B, data: whatever };

    function transition(prev: StateData, action: ActionData): StateData {
      switch(action.type) {
        case Action.A:
          return { type: State.B, data: whatever };
        case Action.B:
          return { type: State.C, data: whatever };
      }
    }

Then you can for example if you were using this in react do something like

    function MyComponent() {
        const [state, setState] = useState<StateData>({ state: State.A, data: whatever });

        return <button onClick={() => setState(transition(state, { action: Action.A, data: whatever }))}>Go!</button>;
    }

For one possibility, look up the State design pattern.

Basically, you have a variable that holds an (immutable) object representing the current state. All states that can be assigned to that variable (all abstract states the system can be in) implement a common interface (the static type of the variable), which in particular includes a method (or methods) for asking the state what the next state is given a particular event. The method then returns the new state. Whenever an event occurs, you ask the current state stored in the variable (call its respective method) to compute the next state given the current event, and then you assign that new state returned by the method to your state variable.

The common interface usually comprises further methods that define/implement the behavior of the system in the given state. For example, if the states correspond to the different modes of an editor, there could be a method that implements what happens when a key is pressed in the specific state.

A key thing I've seen people miss is that actions should be triggered by specific transitions, rather than by the States.

For example:

If a pull request goes from Draft->In Review the FSM might perform an "assign reviewer" action.

If a PR goes from Changes Requested->In Review, there is already a reviewer assigned, so it just performs "notify reviewer".

There are two different types of state machines that behave differently. Moore machines have actions (or outputs) determined by the state while Mealy machines have actions determined by the specific transitions (or state + inputs).

Depending on the system and implementation constraints one type works better than the other (e.g. Mealy machines can implement Moore machine behavior with one less state, which may save hardware).

My states have entry() and exit() functions that do things like you describe.

Lets say a PR can go from:

Draft->Closed/Abandoned

Draft->In Review

Changes Requested->In Review

I'm not sure "assign reviewer" would fit either in Draft.exit() or InReview.entry(). I guess you'd implement something like "ensure reviewer assigned" in InReview.entry() instead. Which would work, but would itself contain the sort of state-dependent logic that a state machine is meant to surface.

Putting it in the entry is probably what I’d do, or I’d split the “InReview” state into its own sub state machine. It’s hard to reason exactly with imaginary scenarios though.

I would call them two states.

Or, perhaps an additional transitional state.

I think two states is probably a bad idea. Obviously the use case is hypothetical, but I'm assuming the set of transitions available from the In Review state does not depend on the path you took to get there.

Krishnamurthi's "Swine before Perl" and "Automata via macros" papers are particularly enlightening.

https://cs.brown.edu/~sk/Publications/Talks/SwineBeforePerl/

https://cs.brown.edu/~sk/Publications/Papers/Published/sk-au...

The XState (JS framework) docs and community are great. Spend a bit of time hanging out there and you'll get the idea. I'm a big fan.

https://xstate.js.org

It really depends on your programming language. In C it's not much more then a switch case over an enum where every enum value is a concrete state. It languages with pattern matching and ADTs it's much more ergonomic since a state machine then is just a function from a state and an input to a new state and an output.

    typedef struct State State, *StateMachine;
    typedef void (*Event)(StateMachine *sm);

    struct State {
        Event TurnOn;
        Event TurnOff;
        Event MakeStuck;
    };

    void IdleTransition(StateMachine *sm);
    void BecomeOn(StateMachine *sm);
    void BecomeOff(StateMachine *sm);
    void BecomeStuck(StateMachine *sm);

    const State StateOn = {
        .TurnOn    = IdleTransition,
        .TurnOff   = BecomeOff,
        .MakeStuck = BecomeStuck
    };

    const State StateOff = {
        .TurnOn    = BecomeOn,
        .TurnOff   = IdleTransition,
        .MakeStuck = BecomeStuck
    };

    const State StateStuck = {
        .TurnOn    = IdleTransition,
        .TurnOff   = IdleTransition,
        .MakeStuck = IdleTransition
    };

    void IdleTransition(StateMachine *sm)  { }
    void BecomeOn(StateMachine *sm)        { *sm = &StateOn; }
    void BecomeOff(StateMachine *sm)       { *sm = &StateOff; }
    void BecomeStuck(StateMachine *sm)     { *sm = &StateStuck; }

    StateMachine sm = &StateOff;

It's still C but arguably much more concise than a switch, wouldn't you agree?

For large state machines sure. For smaller ones no. My point wasn't that enum is the only way to do it in C. Just a simple representation that is used in practice that I could explain in a single sentence.

>"In C it's not much more then a switch case over an enum where every enum value is a concrete state."

This is but stupidly primitive representation / implementation of SM (yes it is useful in very simple cases). You can do way better in C. Somebody else already presented more advanced design.

There are some good state chart compilers like http://www.colm.net/open-source/ragel/ (disclaimer - haven't used it in years) that you can look at the output of.

It really depends on what you want in terms of implementation. On one hand, a big chunk of digital logic is about implementing large, high-speed state machines using circuits.

On the other hand, regular expressions and things like lexers are largely based on finite-state machines so there is a ton of information related to those, but they often implement things more complex than finite-state machines in order to be more expressive.

In terms of manually implementing them yourself, I think the naive implementation based on the mathematical definition of a deterministic finite automata is pretty good for a small number of states for things like tracking program state. In particular, explicitly listing the total set of expected inputs/transition criteria, explicitly listing the states, and having a single function that takes the current state and current transition-relevant data and produces a new state.

This representation is nice because it makes the behavior inspectable in one location. This makes it easier to notice the edge cases and prevent the state representation and possible transitions from getting spread all over code. The transition function can be a switch statement or a table. Really any way of writing a two-input function with a finite number of inputs and outputs will work. Many people have also explored strongly-typed versions of this, which are worth a look as well.

There really isn't that much to it. E.g. in Python you can just use a dict.

    # (state, event) => (next state, action)
    FSM = {}

Add transitions (using enums):

    # Simple left down-[move*]-up sequences.
    FSM[STATE.clear,     EVENT.left_down  ] = STATE.set_caret, 'set_insertion_point'
    FSM[STATE.set_caret, EVENT.left_motion] = STATE.set_caret, 'set_insertion_point'
    FSM[STATE.set_caret, EVENT.left_up    ] = STATE.clear, 'nothing'

Then when an event happens you drive the FSM like so:

    new_state, action = FSM[state, event]

Check out https://git.sr.ht/~sforman/Xerblin/tree/trunk/item/xerblin/g... for an example.

There is also a DOT file (and SVG image) of the resulting state graph (the code to generate the DOT file directly from the FSM dict is at the bottom of the mousebindings.py file.)

Game Programming Patterns by Robert Nystrom has a chapter on state machines. It’s both freely available online or for purchase if you really like it and want to support him.

http://gameprogrammingpatterns.com/state.html

https://barrgroup.com/embedded-systems/how-to/state-machines...

I’ve always been fond of this pattern.

   state = state.next(context, data);

Context just holds the global stuff of the process, data is the new input into the machine and state is the current state.

A simple example is an SMTP server. State is the current command (or idle), context is email message being built, and data is the line read from the socket.

  Context context = new Context();
  sendSMTPBanner();
  State state = new IdleState();
  while (!state.isFinished) {
    String data = readLine();
    state = state.next(context, data);
  }

Conceptually pretty simple.

Of all the other replies, it's interesting that no one has mentioned the simplest and probably most efficient implementation, the one based on gotos:

    state_x:
        ... do some stuff ...
        if(some_condition)
            goto state_y;
        else if(some_other_condition)
            goto state_z;
        else
            goto state_n;
        ...
    state_y:
        ...

Basically an enum containing the possible states.

A long series of ifs/match/dictonary/whatever to match (current state + input → next state).

That's it.

I am also in search for a elegant way to teach such implementations in Python. I do not want students to confuse this with OO, not sure if they see the value in functional programming so soon. My best idea so far is to teach the concept of state and state machines with Python generators…

At our company, we rely a lot on https://github.com/boost-ext/sml

Reply on news.ycombinator.com