Hacker News Reader

Comment by Const-me | Hacker News Reader

I’ve implemented finite state machines multiple times (network protocols, format parsing, CNC controls, videogame AI, etc.) in different languages.

Found it surprisingly difficult to code well, regardless on the language, esp. when there're many states.

View on HN

When some one complains about how async nodejs and callback are hells. I smile. FSM are notoriously hard to write, manage and debug. Because they are async by design.

In one of my prev workplaces we worked on state machines. Few good takeaways was to design state transition functions in a large array laid out with all possible hooks in order. And document the hell out ofit. Another approach was to generate boiler plate out of fsm given its grammar.

For asynchronous IO, we now have async-await in many modern languages. The feature pretty much solves IO related callback hell; the compiler builds these state machines automatically, and keeps them abstracted behind a nice API making code easy to read, write and debug.

I wish someone would invent an approach suitable for generic FSMs, not just for async IO. External code generators work when you have grammar or protocol state UML, but aren’t without their problems.

How about esterel? It seems to be a nice language based on FSM. https://en.wikipedia.org/wiki/Esterel

Hey, I have really tried to give "state machine type tracking" a go in my current project [1] and try to expose JSON apis for them. Checkout the specific doc here:

http://docs.dapt.in/state_tracking/

Would love feedback.

[1] https://github.com/daptin/daptin

I have coded a number of FSMs. I think the challenge is always in how much performance you want verse flexibility.

I think the challenge is quadratic growth of complexity with state size.

Here’s an example of FSM with relatively complex state, 1000-lines gc_execute_line function, it’s for CNC: https://github.com/grbl/grbl/blob/master/grbl/gcode.c

That’s not my code, but I’m not sure I would be able to do much better than that.

That code actually has me a bit confused. I don't understand how this part is working:

  switch(letter) {
    case 'G':
      switch(int_value) {
        case 4:
          switch(int_value) { // int_value hasn't changed
            case 10: ...      // so how do we get to this case?

That second switch on int_value is at line 151. Have I missed something in the code where int_value is changing?

It’s not changing.

However, above that “case 4:” there’re another cases, “case 10: case 28: case 30: case 92: ” without break at the end of the code. Unlike some other languages, in C and C++ this means execution continues to the next case. The behavior is called "switch statement fallthrough".

That source code has the comment saying “No break. Continues to next line.”

Ah, I missed that they didn't break above it. Thanks.

Reply on news.ycombinator.com