I'm studying CS (in switzerland) and we've learned about state machines during a mathetmatics lecture in the second semester. that's it. since I didn't take the compiler class, this was the only lecture in which state machines were covered.

I personally think it's important to know about state machines. at least once in a lifetime you are going to write a DSL or parse specific input, and these are use cases were the application of state machines is pretty useful.

oh and by the way: Zed has written a nice tutorial about finite state machines, called "A Painless Introduction To Finite State Machines" and located at http://lamsonproject.org/docs/introduction_to_finite_state_m... . it's worth reading it if you're interested in the subject!

I would think that anyone who gets a degree from a reputable CS program would have to take a class in compiler design, so I wouldn't call such classes "obscure". Of course

(a) just because you covered it in a class doesn't mean you remember it five years later

(b) lots of people rise through the ranks of IT without formal CS training

(c) some CS programs are not so reputable

(d) a lot of people buy into the "school is worthless" line so hard that even when something as practical as state machines are paraded in front of them they don't notice

(Granted, the education system might have some responsibility there, but personally I recall examples being made. There's only so hard the profs can make the point that this stuff actually matters.)

Mine as well. State machines early on. However, immediately went into computer programming but that stuck with me.

If a person reads GoF carefully, they talk about it there. Also, UML has a whole state machine concept segment and Uncle Bob wrote a package years ago to handle state machines.

I wonder if programmers rely too much on RE for problems that would be best handled by FSM.

Excellent article, excellent software.

RE and FSM are equivalent. There are no problems handled better by regular expression than by FSM. Of course, this is for a very narrow definition of problem. And, by most accounts, a narrow definition of FSM. SCM calls its systems FSMs even though they have stacks. Sure, the number of programmer defined states is finite, but the number of system states is infinite. Also, what do you mean by better? :)

So, for an un-specious response: FSMs are well suited to stream processing, while REs do well with block processing. (And are generally implemented by compilation into FSMs, anyway.) FSMs also do well as program logic/control structures, often clarifying the underlying system.

Well, equivalent in there is a direct transformation from one to the other, but in the sense of a programmer's approach, not really equivalent.

Yes, REs are transformed to FSM, but the problem-solving approach provided by skills in writing FSM is different, and according to the article, often better.

Funny you should say that, my background is also as an EE and I also can't imagine not knowing about state machine design. Yet just this week I had a junior guy tell me he's never seen the concept in software, outside of a testing harness for a hardware fsm.

My CS experience was that it was something that everyone studied, but only in a fairly abstract context, and I don't remember coming away with the notion that you'd ever actually use it for except parsing.

Your professors/program didn't serve you well, then. State machines are heavily used in computer games and for programming simple devices.

Also, compiler design classes are not obscure. Mine helped me land a job... working on a compiler.

Additionally, I find state machines in many business domains. Everything that some kind of "ticket" object (be it customer support or defect tracking) will (or should!) have state machines, with rules of varying complexity, to escalate the status of these tickets.