got on my reading list by virtue of the misfortune of dealing with code written by programmers who adopted the book's approach.
The thesis was that state machines are a powerful formalism that can be fully verified because all the states and edges between them are known. That's half-right: they are powerful because state transitions are essentially "goto" by another name. In practice goto-based programming is brittle to requirement change. The damning part is that state machines don't live in isolation: they interact asynchronously with other state machines and the world at large. The dynamic behavior of these interactions is probably important! and not part of individual state machines. You'd need to co-simulate them.
I feel state machines have their place where no higher-level construct (usually I prefer coroutines) fits the job and it can be kept small and rewritten on requirement change.
From this, we get that accounts should certainly behave like state machines.
And from that, it’s reasonable that other pieces of code ought to be able to
dynamically inspect an account’s current state, as well as its complete graph
of states and transitions. That’s as much a part of its public interface as
any particular method.
I guess I'm fairly influenced by this book: