I literally just finished writing a state machine before opening Hacker News.
Why Developers Never Use State Machines
71–80 of 96 posts
Re: Why Developers Never Use State Machines
#72[deleted]
Re: Why Developers Never Use State Machines
#73Mail servers are state machines. The SMTP protocol is all about state.
In a way any web app with a login is also a state machine - there's the logged in state, and the not logged in state.
erlang has a very effective state machine library(behavior). But the downside is that it's erlang. http://www.erlang.org/doc/design_principles/fsm.html
Re: Why Developers Never Use State Machines
#74Earlier quoted context omitted.
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.
The natural next step is a PDA. Perhaps you could use this type of system to model an AI that can get distracted or become faced with an intermediate task and then return later to the original objective?
For those of you who don't know what a PDA (Push Down Automaton) is, it is basically a standard finite automaton but with a stack that you can push things to and pop things of -- you can then react differently if you get input a in state B versus getting input a in state Q.
Many parsers make use of PDAs when they parse source code.
Re: Why Developers Never Use State Machines
#75Simple, 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…
Couldn't you just say: all developers use state machines, some just aren't sophisticated enough to know it? I'd even say that today, most developers use fairly explicitly defined state machines (like there is even a code entity called "state machine" somewhere.) Every time they fire up a regular expression.
No, he couldn't just say that, otherwise he wouldn't be able to list cool sounding intro to computation terms.
Re: Why Developers Never Use State Machines
#76I don't understand the problem. State machines always seemed like a reasonable choice to a stateful system making transitions between states.
It's possible to build some gorgeous state machine networks with lambda functions and dictionaries.
Re: Why Developers Never Use State Machines
#77They're used all the time. A workflow engine is basically a big state machine. They're used all the time in the Enterprise.
In object orientated software engineering the State pattern is a pattern for cleanly implementing a state machine* whilst avoiding horrible switch or massive nested if-then statements.
Re: Why Developers Never Use State Machines
#78Do you guys think a drawing program should be more easily modeled with a FSM?
Re: Why Developers Never Use State Machines
#79Can anyone recommend a good python library for state machines and example code of its use?
Re: Why Developers Never Use State Machines
#80I use them extensively for Appointment Reminder. In addition to modeling the business logic pretty intuitively (particular types of input can cause an appointment to go from :scheduled to :confirmed, :confirmed appointments should not generate additional reminder calls but :scheduled ones should, etc), they're virtually indispensable for doing Twilio applications. I'll have more to say about that at TwilioConf (and w…
I found it more useful to control my Twillio interaction via a Finite State Transducer (FST - http://en.wikipedia.org/wiki/Finite_state_transducer ) instead of a FSM. An FST allows you to accurately model 'outputs' on state transitions (where those outputs can be side-effects like 'make a call' or 'send an invoice.' This allows you to prove things about what sort of side-effects/outputs will necessarily have occurred…
FST's are used a lot in natural language processing, for example in speech recognition and dialogue systems. In these cases the state transitions are given probabilities (weights), which makes it a weighted FST.
Sometimes I used FSM's during the design phase of a project to model system behavior, but I'd end up implementing them pretty crudely with spaghetti code or case statements. Looking back, it would have made more sense to explicitly implement the FSM in the code.