 This is something that, for whatever reason, intimidates quite a bit of developers that I've met, and it really shouldn't. Today we're talking about the state machine. Like with most of my little mini lectures, one of the first things we cover is the abstract theory. Except not this time. I am almost positive. Covering the theory first is why this is such an intimidating concept because I promise you see state machines on a regular basis. There's absolutely no way you've gone through your life not seeing a state machine. But the way they're described in class, the way they're described in books in computer science journals, is insane. So we're gonna get into a little bit of the practice first. And yeah, inevitably there's going to be a little bit of a theory minor amount. Like if you explain what a dog is, because a dog's a little bit of an abstract concept, it is a little bit of a theory, but we're gonna try to get to just much to the practice as possible. So some real examples of state machines. This is often real machinery. I will mention first that the idea of the state machine is something that cropped up in the 50s roughly as a way of modeling things with computers. However, it's really taken off into engineering. And even as far as computer science goes, it's really only something that you'll see in programming that has to do a lot with engineering anyways. It does have uses outside of that, but it's programmers outside of that area that tend to be very... I remember this from class, but I've never used it in my life and I don't intend to. But even though it originated with computer science, you can still see it a lot with machinery. So one great example of it because it's absolutely a state machine, but it's also pretty easy to describe is the turnstile. Now I know quite a few of my more serious viewers are not primarily English speakers. The turnstile is a type of one-way gate and meant to sort of restrict the flow of people through it. The idea is that it lets one person through and then stops. It locks again and then it will let another person through and then it locks again. It's to try to provide a sense of order, but it also a lot of these activate using very small denominations of currency. I see them often with just a quarter which is a pretty small amount of currency as far as this country goes. But it's essentially that. It's a one-way gate. Then you have vending machines. These are a bit more sophisticated of a state machine, especially when you get into modeling how all the currency adds up. But it's still a it's still a pretty basic state machine. And computer human interface devices you're really not going to be modeling, say, the way a mouse works based on, you know, like a functional paradigm. The state of, say, a mouse is which buttons are down? Which buttons are not down? The person just released this button so that stuff like that. And then also with simulated machinery, of course, because that's where the stuff originated. And something most of us have seen is the command line parser. Certain states that it'll go through. You get into things like sub-shells and stuff like that. But even even the command prompt itself, after a certain program is run, that program may then wait for a new input. And the parser for that is going to be different from the parser at the the command line itself. And so you have this state going on. And roughly how this works is that in the simplest most ideal sense, given one input, you enter one specific state. And for another input you're going to enter another state. This is essentially the mathematical concept of a map or if you're familiar with the data structures like a dictionary or an associated array. And in fact, if the state machine you're working with fits these, this type of behavior, you can implement literally with nothing more than a map, a dictionary, an associated array. Because for any input, it's guaranteed to be in a specific state, and you will have a specific output based on that state. But there are more complicated ones, given a certain set of inputs, even if a few of those inputs are different, or even if a few of those inputs are the same, just because one of them is different, it will enter an entirely new state. And sometimes that's not always the case, but basically just want to explain that it's not always a nice simple map. Oftentimes you can, and whenever possible, you want to work with as few states and a few things that decide state is possible. So if you can reduce it down to something that it can just be a map, ideally you want to do that. But just as a simple diagram, it's basically you just, whatever inputs you have, decide what state you get. That's a state machine. So then using the turnstile as a state machine, I'm just gonna do a really basic example of one. With any state machine, you have a default state. That's the state it's in, right from the get go. For this example, we're going to assume that it's locked. So that is, it's not freely moving. It's not going to let somebody in yet. If somebody were to try to walk through it, the bar would not move. It would not turn, so it would not let the person through. And because no input has happened, it's going to stay locked. You can think of this as kind of just looping through over and over again, although the code should never loop. But essentially that just, it will stay locked as long as the input doesn't change. Because if the input doesn't change, the state won't change. But if we go through and insert a coin into the machine, this is a change in input and creates a change in state. The turnstile is now unlocked. And similarly, it will remain unlocked until another change has occurred. In the case of the turnstile, that new change would be that somebody walks through. The way turnstiles work, after somebody walks through the first time, it locks again. And so this pull process will repeat. It will remain locked until somebody inserts another coin, in which case it will unlock until somebody walks through again. We can cover a slightly more advanced turnstile just to show how this would be a little bit different and also how state machines can handle adding complexity to them quite well. Although this isn't a hardcore example by any means, but I'm doing this because I want to get into a hardcore example, a layer in another video. In this case, we're going to start with an unlocked turnstile. So, just like before, it's going to remain unlocked until a change has happened. Now somebody walks through the turnstile. In this case, however, maybe you've seen certain venues. I got dragged to a lot of sporting events that I didn't necessarily want to go to as a kid. Well, I like certain sports, I didn't like everything, my father liked. But I remember seeing in quite a few of these large stadiums these turnstiles that didn't actually accept any coins because you paid for the ticket. Why would you also have to put a coin in to get through? So they had them free. So turnstiles also still are very effective at sort of restricting flow because they only let people through in one direction, but also sort of maintaining order because they slow down the rate at which people can go through. So you don't have this crazy mob situation where you get the human equivalent of a traffic jam. So they're still very useful for that. So you would want a turnstile that could possibly be free. Now, in the case of it being free, it should just go back to the unlocked state. It should stay in this loop where whenever somebody walks through, it just remains unlocked because it's free. But then if it's not free, just like before, after somebody walks through it, it should lock again and it should remain that way until somebody inserts a coin. Here we've added an entirely new layer to this. And it's not that much more complex. There's literally one box and two lines added. So the intent of a state machine is to control complexity when state is required and to make state easy to reason about. Unfortunately, especially when you get into complex interactions of different parts of state, the complexity spirals out of control. If you want to see a little example of where I calculated that, the video just before this one I did on how configuration settings is the root of all evil, you can see sort of how that can get absolutely crazy and especially if you've been trained in programming recently, you might be a little off put about that. I thought that the name of this in general, just the state machine, like, isn't state a bad thing and controlling state complexity when state is required, like, when would state ever be required? Isn't state this really bad evil thing that you need to avoid like the plague? That's what functional programming teaches. This whole idea is rooted in mathematics. A point I try to get across in quite a few of these videos and will continue to try to get across is that there is no silver bullet. Every single one of these paradigms actually has an immense amount of overlap and they each have a problem domain. And for whatever reason, a lot of the big proponents of them have a really hard time seeing outside of their own problem domain into the problem domain of others. See, we don't all work on the same thing and the solution for one thing is not going to be the solution for another thing. Mathematics is something that state is a really bad thing. And I'm hesitant to say that state should never exist in mathematics because I'm not completely versed in the entirety of all the different mathematics theories. But I'm at least in everything I know state introduced into any of those is absolutely terrible and should never exist. So I get why mathematics and functional programming, which is heavily, heavily inspired off of mathematics, would be really averse to state. But engineering especially is all about state and responding to state and to similar. Sometimes state is required. Sometimes state is required and you don't actually want to use a state machine, but that's a little bit more complicated. I'll later on have some examples, of course, of when you actually want to use a state machine. But we're not going to get into that today. But like any tool, it's essentially what this is. This is a tool. It has its purpose. And as long as that purpose lines up, as long as you are working within that problem domain, when you have to work with state, it's OK. These are part of life. Like I said, tons of machinery, just common machinery that we've always looked at in our life is a state machine. I actually have a great example coming up shortly. But we'll do the theory after. And I still want to cover it. So we'll do it after the practical stuff for once. There's different types of state machines. You have the finite state machine, which essentially everything is, because the other side of that is not really feasible. Sort of an academic curiosity, but the idea is that you have a finite amount of states. And this should make sense. What kind of machine exists with an infinite amount of states? But academics make that distinction for reasons that I don't really understand. But then we have a token driven state machine. And I'll get into how this differs from an event driven state machine. I think the slide right after this. And then there are also hierarchical state machines. And after this presentation is done, just forget all of these. And I cover them into some minor detail. But if you forget about them by the end of today, that's fine. Seriously, it's fine. There's tons of overlap in these, except of course finite and infinite, because those are dichotomy. But it's totally possible to have a state machine that is both token and event driven. Don't worry about the specifics of these, seriously. So it's for the modes of operation of a token driven state machine. Essentially this takes a list of tokens. This is for some reason the state machine that is most often described in academics. And I think it's because it's one of the best approaches towards developing a compiler. Although it's certainly not the only one. There's a really interesting approach to teaching Haskell that is done by writing a Scheme compiler. Was it interpreter? Both? You're writing your own Scheme thing in Haskell. And that was not done through a state machine. But generally, parsers especially are written using state machines. And in the case of this, we're talking about essentially a list of tokens for what decides the state. This is sort of why I hate the theory first approach in that you probably still have no idea what the heck I'm talking about. This is quite literally like a cooking recipe. The tokens are each of the individual instructions in the recipe. And as you go through, you read one instruction, you go perform that thing. You read the next instruction, you go perform that thing. The thing you're performing is the state. Each of the instructions is the token. You are in that instance, a state machine. And so like I've said, for every one of the tokens that goes through, the state changes. This is generally presented in contrast to, although like I said, these actually can overlap. It's possible to have a bit of both of these. But for summaries, and these are usually presented as contrasting. In an event-driven one, it takes various events. This is again, something that we do on a regular basis where based on a certain stimulus, you respond a certain way. And who hasn't gone through that? Most of the time when we're complimented, and it's a very obviously sincere compliment, we respond through a happy state. So like I said, the state changes in response to the event rather than a list of tokens, rather than a list of essentially operations. If you think this kind of sounds a little bit like procedural programming, you're more or less right. I know there's some purits out there who are not gonna like me saying that, but essentially these are the same thing just viewed through a different lens. They're a different abstraction upon the same thing. I forgot the transitions again, lovely. I'll just do that in the later slides. For the mealy and more machines, which are other things to consider when dealing with state machines, there's actually a great video done by MathWorks, the creators of MATLAB who cover these. They have a great example involving modeling a oven, how an oven works using state machines and show the difference in how the oven would be modeled using the mealy approach and the more approach. That does a great job and there's not really any point in me recreating that work, so I'm just gonna have a link to that video down in the video description. It's the third in their series. If you're interested, the first and the second will largely cover what I've already covered but may help build upon that. So if you go watch them, but I'll have the third linked. And so that's it. Hopefully this leaves you with a better understanding of state machines, especially since I'm intending on this to bring anybody who saw the video I did on configurations and how it caused complexity to spiral out of control up to date on what a state machine is, because it was actually a state machine that it was how I sort of reigned that in. So I'll do a follow-up video to that detailing quite a bit more how I did the how I actually used a state machine and why I used a state machine as opposed to say like a heavy object oriented approach or why I didn't use a heavy functional approach with monads so that there wasn't really a state. But this should get people up to date. At least familiar enough to recognize what I'm gonna say then. And of course, that's not why you're here if you're just stumbled upon this because you wanna look into state machines or finite state automata or anything like that. Hopefully this video has helped you out. State machines are not scary by any means. It's really just the approach that we take to describing them that quite frankly sucks ass. Just terrible, but yeah, hopefully this has helped you out quite a bit. And if you like what I do, if you liked this video, if you found it helpful, please consider giving a thumbs up. Also consider subscribing and maybe hitting that notification bell. I create videos quite often, but you still get notified when that happens. Then have a good one.