Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Developers Never Use State Machines

skorks.com

Post reply on HN
Print view View original

81–90 of 96 posts

Re: Why Developers Never Use State Machines

#81

Post by slowpoke »

xtracto wrote: post #33
pagekalisedown wrote: post #15

Earlier 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.

About 10 years ago when I was reading a lot about AI game dev I remember reading about Fuzzy State Machines ( http://www.coniserver.net/wiki/index.php/FuSM ) which were seen as an improvement from classical FSM. I think I read it in one of the "AI programming Gems" books.

Going by the name, those are based on Fuzzy Logic, I assume - which makes sense. Some people say that the first nation to develop a true AI will be Japan, because they've been studying Fuzzy Logic theory as a field of science since decades.

Re: Why Developers Never Use State Machines

#82

Post by pointyhat »

In my experience, why "developers" never use state machines:

a) Most I speak to had a Z-rate CS education which scraped a bit of OO design in Java and don't know they really exist.

b) Most languages they cut their first code in are about puking data around from SQL to the web which rarely if ever requires an FSM.

c) Someone thumped them over the head with "Windows Workflow for dummies" which is then assumed to be the answer to all stateful problems.

d) It looks hard so they don't bother.

e) "developers" should not be confused with "computer scientists". It's "builders" versus "engineers".

Re: Why Developers Never Use State Machines

#85

Post by cbs »

Nelson69 wrote: post #34
super_mario wrote: post #12

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…

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.

>most developers use fairly explicitly defined state machines [...] Every time they fire up a regular expression

They're not using state machines, in that case it just happens to be an implementation detail of the regular expression library they're using.

Re: Why Developers Never Use State Machines

#86

Post by cbs »

pointyhat wrote: post #82

In my experience, why "developers" never use state machines: a) Most I speak to had a Z-rate CS education which scraped a bit of OO design in Java and don't know they really exist. b) Most languages they cut their first code in are about puking data around from SQL to the web which rarely if ever requires an FSM. c) Someone thumped them over the head with "Windows Workflow for dummies" which is then assumed to be the…

Unfortunately for our industry, a lot of your post is right, and it doesn't just apply to state machines, but a lot of solid programming practices.

Re: Why Developers Never Use State Machines

#87

Post by relix »

IProgrammer wrote: post #65
relix wrote: post #46

I discovered how state machines can be practical when checking the source code of Spree, the rails e-commerce engine. The checkout-process is a state machine. I'd highly recommend using state machines for multi-step forms. It feels very natural and keeps you sane, I believe it should be a best practice.

>I'd highly recommend using state machines for multi-step forms. It feels very natural and keeps you sane, I believe it should be a best practice. That's interesting. Can you elaborate on it, maybe with an example?

Basically each step in your form is a state in the state machine. When a user submits one step, you move the state machine to the next state. You can add conditionals for when to skip a step, and you can specify validations for each step that need to be run before a state-change (e.g. credit card needs to check out before moving from the credit card step to the confirm step).

You can check out Spree's state machine for the checkout process here: https://github.com/spree/spree/blob/master/core/app/models/o... (starts at line 83). Notice that the Order model is the state machine.

Re: Why Developers Never Use State Machines

#88

Post by deepinit_a »

marshray wrote: post #50
albertzeyer wrote: post #40

This is a stupid statement. Pretty much every code depends on a state (i.e. the content of the heap memory) and is thus a state machine (by its most generic definition). I think he is referring mostly to a finite state machine, though. But even then, you have that quite often somehow in your code (think of global boolean variables).

Well the memory available to the processor for state is finite, too. Thus, every classical computer is a finite state machine. That said, some programs have state that is more finite than others. :-) Deep down, a "state machine-based design" is a mindset of the designer.

Well said!

Re: Why Developers Never Use State Machines

#89

Post by cbs »

fab13n wrote: post #23

Having used state machines a lot for embedded development, I find that they have one huge drawback: the resulting C code is unreadable, which turns maintenance into a nightmare. 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, stand…

the resulting C code is unreadable, which turns maintenance into a nightmare.

I've been doing embedded development for a few years and I love our state machines, they're a pleasure to work with. Maybe yours just sucked.

Post reply on HN