21–30 of 96 posts
I don't follow this? The core of whichever state machines I write seem to be DFAs, with the alphabet being events causing transitions.
Then again, I think they're far more common in the embedded world than elsewhere.
SM have a key quality: they are a compact and unambiguous way for specifying a behavior. If your system's behavior is set in stone, it's worth specifying it as a SM and implementing it as one. This SM is also great to include in a spec, standard, RFC etc. But if the system evolves, small changes can require dramatic reshaping of the machine.
Also, they can lead to very efficient implementations, especially if you don't have the benefits of a serious OS with a fancy scheduler underneath.
most state machines you're likely to need in your day-to-day development have nothing in common with their computing theory counterparts I don't follow this? The core of whichever state machines I write seem to be DFAs, with the alphabet being events causing transitions.
FSM are very common in video games. I've also worked with one in a (very very) big engineering/CAD software when FSM was managing the whole approval/review/audit flow .
It seems there just less common with web dev in general.
If you are a C developer, try Ragel [ http://www.complang.org/ragel ]. I use it lot, also can be easily pared with the Lemon parser generator.
http://zedshaw.com/essays/ragel_state_charts.html
What I really like there is the idea of a DSL that generates your state machine code for a protocol.
This man has never heard of video game A.I. programming :)
I had the same reaction. Almost nothing but FSMs in game AI. Makes me wonder if we need to look beyond FSMs for the next level of intelligence.
From my experience a state machine is more of a pattern then a real object. Implementing it on the fly is what worked best so far, for me. Of course there is a point where it gets nasty because of complexity. But first that is always the case (complexity IS nasty) and second overcommiting to structure and architecture increases the complexity already in the beginning and might hurt more then it helps. At least fully coding all possible state machine behaviour as the first default task ifor every new project doesn't seem to be a smart thing to do.
Simple, because most developers are not computer scientists i.e. no formal training in finite automata, computability, complexity, nondeterminism, regular expressions, non regular languages, context free grammars and languages, Turing machines, halting problem and underlying math in general. If they did, trust me they would use state machines without too much reservation where appropriate. But as it is, the concept i…
That said, I managed to get through my BSCS without taking the "Finite State Automata" class. I had to pick up table driven methods later, first just fetching values out of a "table", then later generalizing to code-blocks/functions.
At least one way of conceptualizing and implementing a state machine can be simply summed up for the newb:
* Where am I?
* What just happened?
* What do I do next because of it?
Generate an enum for each of the first 2, and put code references into some kind of "sparsely populated" 2-D array, and you're off to the races. TMTOWTDI, but this approach goes a long way towards demystifying the topic.