You'd think that...

I did both EE and CS undergrad (we didn't have Computer Engineering at the time). In EE we started talking about FSMs very early on, in quite a bit of depth. In CS though, we didn't really talk about them until the Computability course in 3rd or 4th year, and even then it was in the very theoretical Finite Automata sense; applying FSMs to software design wasn't really a thing that was ever covered.

From the EE material, I started loosely applying those concepts to software design, but it wasn't until my first job in industry where I was lucky enough to be exposed to a system that was very deliberately designed as a system of FSMs.

We based the design of ours off of a pretty famous paper, whose name is entirely escaping me at the moment. Damn.

Sadly, while many people learn about state machines in their first two years (to varying degrees of formality), they often don't learn how to design code using them.

I think the only course where I explicitly designed programs using state machines was compilers (other than writing things to simulate state machines in my theory courses).

  > Another in the series "Show HN what is it that people
  > actually learn in their first two years of undegrad CS"

This is my entire technical blogging output from 2004-2018. Combinatorial logic, surreal numbers, function-oriented programming, everything.

I learned about state machines, along with push-down automata and others but these were in a formal automata class where we learned things like the Church-Turing thesis and other similar theory.

So there's learning about state machines in that context and then there's learning about state machines by actually building them in complex pieces of software, or replacing spaghetti code with FSMs. That's when I personally realized how valuable they are.

That is something I never learned in school - and something I learned throughout a career of experimenting, making mistakes, reading from books like http://gameprogrammingpatterns.com, learning from peers, and reading articles like this.

There's learn and there's learn... The way state machines were described at my uni was from the highly theoretic side. It was there right next to context-free/sensitive languages. While it was a good description, I wouldn't expect anyone finishing it to know how to actually implement it in real software - and more importantly: why.

There's CS and there are coding jobs. And sometimes they don't overlap...

It's wonderful, isn't it? Can you imagine how useful this is to programmers that didn't have the opportunity to go to university or to programmers that are still in high school?

I learned about finite state automata in my first year of undergrad CS, but only in the context of recognizing regular grammars.

Finite state machines as used to accomplish practical computing tasks other than grammar recognition were something I didn't see at all in undergrad CS (with the very slight exception of networking where we did see a state diagram for TCP).

700 points, 200 comments. Clearly, you've been misinformed.

(Also, I did my CS undergrad at UC Berkeley and I don't recall ever studying state machines. All the useful engineering bits and design patterns I picked up after getting my first job.)

Which is totally OK and awesome. Simple ideas can be revisited and applied to solve complex problems.

I wish I'd learned about state machines... Most of the potentially interesting CS courses at my college were taught by terrible professors who were allergic to code.

Thankfully I enjoyed screwing around with game programming, and picked up Matt Buckland's Programming Game AI by Example[1]. I've used essentially the same FSM design described there over and over in my career.

[1] http://amzn.to/2FxZ54c