State machines, is this topic taught any more?

[Howardlong]

I had an unexpected experience today, I was handing over a project to half a dozen reasonably experienced developers which uses a state machine to orchestrate and synchronise its tasks. Only one of them knew what a state machine was, so I ended up spending half the meeting explaining the concept, not the easiest of tasks if you’re not prepared.

Admittedly this isn’t an embedded system, it’s a big server-side database manipulation task, but I’d still expect any software developer to have at least heard of state machines, or are state machines outside of embedded systems a bit too old school nowadays?

[KaneTW]

FSMs are taught in any (decent) introductory CS course, but not everyone has a formal CS education.

[JPortici]

I learned about state machines in high school, grafcet, to be more specific (Technical school) but the concept remained with me. I don't remember them ever being mentioned in the courses i attended in uni (EE) were they on programming or digital electronics (say 5 years ago)

[NorthGuy]

Only one of them knew what a state machine was ...

May be state machines aren't used much as most of the programming is done for pre-emptive OSes. Did they know about threads, mutexes etc.?

[tggzzz]

"State machines? Aren't they used in compilers? Something to do with reading the input".

Yes, I've heard that from a young softie. And that was after he had been modifying a telecom product whose "arcihitecture" consisted of a number of "nodes" and ways of "jumping from one node to another". Some people shouldn't be let near a keyboard.

[rstofer]

You would have thought that every grammar school kid knew about the state machine game "Simon Says".

[Howardlong]

Only one of them knew what a state machine was ...

May be state machines aren't used much as most of the programming is done for pre-emptive OSes. Did they know about threads, mutexes etc.?

For this project, given the technology there was no need to use those terms, but the underlying concept is the same. In the target environment, which is on big multi socket multi core iron, the whole point of the state machine was to synchronise and orchestrate concurrent isolated processes by using a couple of dozen instances of the same state machine. The state machine itself only has six states, and is not hierarchical thank God!

Edit: I think you may be onto something regarding the programming methodologies in use today, where in high level applications and systems we have moved away from explicit event driven models with super loops to method driven OO technologies.

[NivagSwerdna]

Only one of them knew what a state machine was

And it is on this basis I hope to keep employed for a few more years. 

[coppice]

Edit: I think you may be onto something regarding the programming methodologies in use today, where in high level applications and systems we have moved away from explicit event driven models with super loops to method driven OO technologies.

Many things have very persistent state. Frequently persisting far longer than any piece of software ever runs without a break. Whatever you call them, and however you look at them, FSMs won't go away. Remember that they even have their own religion. 

[djacobow]

Only one of them knew what a state machine was

And it is on this basis I hope to keep employed for a few more years. 

I'll drink to that.

[djacobow]

Many things have very persistent state. Frequently persisting far longer than any piece of software ever runs without a break. Whatever you call them, and however you look at them, FSMs won't go away. Remember that they even have their own religion. 

I'll try to keep this rant short, because I agree with you.

FSMs, of course, are everywhere, whether you understand that or not. It's much better, though, if your job is to create stateful machines that do useful things, is to have a conceptual model of what a stateful machine is. The formalism of how FSMs are (were?) taught in EE and CS programs is incredibly useful for reasoning about complex processes. It makes designing such machines something mechanical and straightforward, rather than a process of hacking until it seems to work.

You see this deficiency in a lot in software, where someone has written a function or group of functions that interact with shared state variables at various times under varying circumstances, and the result is software that usually kinda works, but sometimes does X or Y one call before or after it should, etc, because the programmer never just drew a state diagram and coded to that, but instead just sort of poked at the problem until it kinda mostly worked.

[kfnight]

Call them DFAs. They'll know what you're talking about.

[T3sl4co1l]

You see this deficiency in a lot in software, where someone has written a function or group of functions that interact with shared state variables at various times under varying circumstances, and the result is software that usually kinda works, but sometimes does X or Y one call before or after it should, etc, because the programmer never just drew a state diagram and coded to that, but instead just sort of poked at the problem until it kinda mostly worked.

I enjoy watching speedruns of games, where this principle applies in game development.  A huge fraction of tricks/exploits/glitches consist of entering some state, then doing a frame-perfect state change that clearly was not expected by the developers.

I feel that a lot of those, back in the day, were due to time crunch and hardware complexity: systems like the N64 were pushed to market, with as much dev support as they could manage to put together in that time.  Which, compared to today's biggest, most popular frameworks, was probably just embarrassing.  (Maybe it's not; it's easy to overstate the appeal of a framework I've never personally tried.  I should really assume it's just as hacked together as every other framework in existence!)  The standard graphics backend for the N64, for example, was at least pretty solid (basically a drop-in of the SGI tech they licensed), but tended to be slow.  If you wanted to stray from the standard path (say to squeeze as much geometry and framerate as possible), you had a tremendous amount of work to do.  Most famously, Rare's games: compare the gameplay and graphics of DK64 to Perfect Dark!

Mistakes continue to be made today, of course.  i would argue that it's more a matter of scale now, just because projects are so massive that there's no way they can design, structure or test every combination of every component.

Well, that needs a lot of qualifying, too.  Tools like Unity are available to literally everyone, from the single-dev indie to massive hundreds-of-devs "AAA" studios.  The smaller studios will still have the same early problems: learning the tools, programming challenges in general, and just managing to put out a complete product as such.  It's the larger studios to which I'm referring, of course.

Just in the last two months, Nintendo's Breath of the Wild has been broken open with wall clipping and superspeed techniques, some of which are fairly easy, and some of which have small frame and position windows to execute.

Bethesda's games are notorious for glitches.  At this point, I've got to think it's at least somewhat intentional, as an endearing feature of their games/engines.  Like how the physics engine in later GTAs improved considerably, but left in the glitchy playground equipment that launches actors/vehicles.

Meh.  I could go on, and on and on.  Suffice it to say, if there's a reason something can fail, it will.  Structural, design, management, technical, "blame the tools", you name it, some combination will be relevant.

Tim

[SiliconWizard]

You can try and have them ramble on aspect-oriented programming instead.
 

[richnormand]

A few years ago I took an EDX course from UT 6.02x Embedded Systems.
One of the labs was indeed to design a finite state machine for a traffic lights and pedestrian lights at a major intersection. Major pain!
While a good tutorial, the argument was that using no "if"  or other type statements and being able to prove (to a judge and such) that there was no way it could have misbehaved.

So, yes, it is still being thought as a basic concept, albeit not that efficient as a programming method.

[tggzzz]

A few years ago I took an EDX course from UT 6.02x Embedded Systems.
One of the labs was indeed to design a finite state machine for a traffic lights and pedestrian lights at a major intersection. Major pain!
While a good tutorial, the argument was that using no "if"  or other type statements and being able to prove (to a judge and such) that there was no way it could have misbehaved.

So, yes, it is still being thought as a basic concept, albeit not that efficient as a programming method.

If you aren't worried about correctness, then "it" can be arbitrarily "efficient" for any value of "it" and "efficient".

[hans]

I think state machines are common in academia, hence people with education probably know about them. However "state machine" is a common design pattern, so you would think computer science people (even self taught) will know about it.

Hardware designers will come across FSM at some point, Moore and Mealy machines.. basics of any VHDL course.
Theoretical computer scientists use automata to describe state machines. There are many modelling languages and paradigms to describe automata, and prove certain properties of a system. You could use temporal logic, like LTL or CTL, to reason about the temporal behavior of systems. Or PCTL to reason with probabilities in mind as well.

For example, the probability of a system failing and not recovering within a certain timespan.

Unfortunately, these tools are mostly academic because modelling any real large system requires at least a PhD in the field plus access to sufficiently powerful simulators and machines to do any meaningful experiments.

[Mechatrommer]

reasonably experienced developers

well there are experienced developers that dont know how to use #define properly nor know what reusable codes are. their qualification maybe was only hands on experience, no proper education line.

[Howardlong]

nor know what reusable codes are.

As an aside, there's reusable code, and then there's reusable code.

Reusable code is in general to be applauded, but as with most things it can be taken to the extreme, such as there being only one externally called function,  method or interface which does everything, including fitting a square peg into a round hole. This is where a blind religious dogma can take over from pragmatism.

[Howardlong]

So, yes, it is still being thought as a basic concept, albeit not that efficient as a programming method.

If, for example, one uses function pointers to maintain state, efficiency is rarely a problem.

More likely, though, is that without a state machine you risk ending up with a complex decision tree with plenty of duplicated code that's difficult to maintain.

I'm pretty sure that many programmers use state machines without knowing it, for example in event driven programming, the state machine is performed by the framework.

[tggzzz]

So, yes, it is still being thought as a basic concept, albeit not that efficient as a programming method.

If, for example, one uses function pointers to maintain state, efficiency is rarely a problem.

More likely, though, is that without a state machine you risk ending up with a complex decision tree with plenty of duplicated code that's difficult to maintain.

I've seen if-then-elses nested 10 deep.

Since it was so difficult to maintain (after all code is difficult to maintain), it was under version control - but the versioning looked like spaghetti in a saucepan. To make it easier, there were many site-specific config variables. Since config isn't code, they weren't under version control. And the pièce de résistance was that many of the config variables directly mapped to the if-the-else clause!

I'm pretty sure that many programmers use state machines without knowing it, for example in event driven programming, the state machine is performed by the framework.

I wish many of those frameworks directly acknowledged that they were intended to be used for event-driven FSM applications. Instead the FSM nature of the application code can indeed be thoroughly hidden by the framework, and hence the application code grows in an unmaintainable ad-hoc fashion. Doubly so with inappropriate use of agile or XP practices.

[BBBbbb]

If you worked with lower level embedded (meaning NOT RPi embedded linux and similar stuff) and had to handle precise timings and edge cases, I rally can't believe you are unfamiliar with SMs or doubt their efficiency.

Java and such stuff, I understand people not being familiar with SMs

[tggzzz]

If you worked with lower level embedded (meaning NOT RPi embedded linux and similar stuff) and had to handle precise timings and edge cases, I rally can't believe you are unfamiliar with SMs or doubt their efficiency.

Java and such stuff, I understand people not being familiar with SMs

They are just as valuable at a high level. Consider telecom control software, or flight control.

I conjecture they ought be used for some event-driven smartphone apps as well.

[BBBbbb]

If you worked with lower level embedded (meaning NOT RPi embedded linux and similar stuff) and had to handle precise timings and edge cases, I rally can't believe you are unfamiliar with SMs or doubt their efficiency.

Java and such stuff, I understand people not being familiar with SMs

They are just as valuable at a high level. Consider telecom control software, or flight control.

I conjecture they ought be used for some event-driven smartphone apps as well.

Yup, basically whenever you have important timings and coverage of edge cases (critical systems) SMs seem like a must.

I was more thinking about the common programmer doing IoT stuff on embedded linux using higher lvl language, and still considered as embedded sw engineer.

[rrinker]

 Common saying around here is "if everyone knew what they were doing, we would all be flipping burgers".

Formal education on state machines? I had ONE course (EE) where it was touched on, in terms of digital logic. I would assume a more CS oriented track would cover this in far more detail, but I was more interested in hardware design so I went EE.