Designing Logic Systems Using State Machines by Christopher R. Clare | Hacker News Reader

Designing Logic Systems Using State Machines by Christopher R. Clare

archive.org

63 pointstodsacerdoti23 comments

Direct link to the PDF at Archive.org, https://ia600803.us.archive.org/21/items/designinglogicsyste...

Because I hate the viewer, even though I understand why it exists.

Thank-you.

On mobile, if the Archive does not fetch more results, swipe up to return to desktop and then launch browser again. Then more results get fetched.

This changed the site from completely unusable to something browsable.

I wish the viewer would page files. So far, a single file just opens a larger version of itself, and the arrows don't work.

I have a better experience than that on mobile (iOS), but the PDF is still infinitely better for me.

If you're into web apps check out XState and https://stately.ai ...

and this real-world example of implementing a FSM with XState to great effect: https://swizec.com/blog/when-your-brain-is-breaking-try-xsta...

> If you're into web apps check out XState and https://stately.ai ...

For desktop applications, Qt has been offering for ages support for state machines driving GUI states, including using SCXML to generate it's state machine code.

https://doc.qt.io/qt-6/qtstatemachine-overview.html

https://doc.qt.io/qt-6/qtscxml-overview.html

https://doc.qt.io/qt-6/examples-qtscxml.html

Yeah this is one of the only vaguely decent state machine tools I found - the other one is Yakindu Statechart Tools which is an Eclipse plugin (but don't let that dissuade you - it is good despite forcing you to use Eclipse).

Ultimately though I found that like most graphical programming it wasn't especially worth the effort.

State machines are amazing at keeping things well defined and simple. I love using them in code.

What I don't like about state machines in code is that transitions become less obvious the bigger the state machine gets.

Having each state as a function, with a descriptive name is nice, but you really have to dig through the whole code to see which transitions are possible and which are not.

Yeah I find they're best kept small. I find them useful in managing GUI state. Some business logic gets a bit too complicated to nicely represent in a state machine.

You could have the calling function do the state transitions all in one place. The individual state functions would still do most of the work and generate the information required to determine the next state. But they would be "unaware" that they're part of a state machine.

I tends to have a config part where all possible transition are listed in a type safe way. ( error transition as well. Basically what is not desribed there is a bug or a unknown error transition )

I also tends to have state machine calling other machine or being composed of 2-3 smaller ones.

I save the state in some serialized form in DB if needed.

It’s great for customer flow : like; tracking where they are in the KYC process or onboarding and deciding what to do next.

Without having 50 nested switch statement.

The part that specifies "which transitions are possible and which are not" (more precisely: which state results from a given state and input) -- known as the state-transition function [1] -- is a necessary component of the state machine definition. If you don't have that, you don't have a state machine in code; you just have a bunch of functions.

[1] https://en.wikipedia.org/wiki/Finite-state_machine#Mathemati...

Maybe necessary to define one by the book, but not to put one into code.

I've seen enough state machines in the wild that are just a dispatcher with a bunch of functions mutating a single state variable. Whether we call these contraptions state machines or not is just quibbling.

As others have pointed out, there are better ways to implement them; yet, I rarely come across those.

> What I don't like about state machines in code is that transitions become less obvious the bigger the state machine gets.

There are techniques to keep those large state machines manageable, such as structuring them with sub-state machines.

Most UI frameworks, such as React, operate as if they are informal state machines. Each component is a state/nested state, they have their mount/unmount logic as onEnter/onExit transitions for the state, most of the event handlers the application cares about will be added or torn down within the context of that state, i.e. onClicks, onSubmit, onKeyPress, onChange, data loaded, etc.

I think this is an insistence. But yes, most processes can be mapped out as state machines.

I believe I have a textbook at home on this already. This particular text: is it noteworthy because it was highly influential? Or is it especially well written? Or because it takes an unusual perspective on the topic?

At first glance, I find the explicit modelling of these systems as state machines to be interesting. We used state machines when I learned about it as well, but didn’t call as much attention to it. The extra attention — I like that

It’s incredible how bad the reader works on mobile. It would be hard to design it that bad if one tried really hard.

"We'd be deeply grateful if you'd join the 1 in 1000 users that support us financially."

And not only that, they have a lot of source code on GitHub, so anyone with an annoyance and some free time can fix things up: https://github.com/internetarchive/bookreader

I wish they'd allow crowd sourcing of metadata updates, their metadata is really really bad and can't be fixed.

Try to adhere to the Hacker News Guidelines. I apologize for being annoying but we all benefit from trying to make better posts.

https://news.ycombinator.com/newsguidelines.html

"Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting."

If you scroll down a bit you get a option to download a nice epub for your reading pleasure.

I definitely agree with the others that the tone and content of this comment is a net negative and should be avoided.

Reply on news.ycombinator.com