 How do I use this? Okay, so let's take a walk down memory lane about stake machines I think that an interesting place to start is with the allen Turing the Turing machine or the a machine While finnid state automata was a concept in mathematics since before then I am not a mathematician so I can't speak very well for that but for people who are brand new to this theory essentially you have a machine you have an alphabet so here we can see this alphabet in the example contains only one and zero so it's a two letter alphabet right here we have a two letter alphabet and here we have a stake machine so the Turing machine or the a machine essentially will have an infinite tape input it will read one symbol from the alphabet and that will cause the state machine to change state and as a result it will stamp a new symbol on the position on the tape and an interesting property of the Turing machine itself is that as a result it the depending on the current state that the state machine will be in it can also move the tape back and forward a certain number of slots right so that is essentially more or less what happens with the Turing machine later on we have the Moore machine so this is basically just a representation of a stake machine and in the Moore machine you can still consider this as in those days we were basically doing calculations on tape so we had a lot of tape and we're thinking about inputs here we have ones and zeros as inputs and we have states and the property of the Moore machine is that the output is determined by the current machine state and then the Mealy machine which was around the same time by George Mealy basically we can represent the same state machine however the difference is that the output is determined by the transition from one state to another right so that's basically they're basically the same thing you have states a finite number of states which which can exist in your state machine you have transitions and you have inputs and you have outputs just that the Mealy machine the outputs are determined by the transition right enter our favorite hero David Harrell and that was when we started when we started having this thing called state charts and these first two lines on the slide are two papers the original the first one a visual formalism for complex systems is essentially the definition by David Harrell of what are state charts and the second one is a recommended reading tells you about why and how state charts were created so an interesting thing is that Harrell was essentially hired to work in avionics company in israel and he was working on a fighter jet and he was trying to figure out what are the requirements for a very complex system so you had basically he was working with a 2000 page document of a line by line description of what should happen in which circumstance so he would come and he would ask so what happens when you press this button and then they would have to call somebody and somebody new and then by the time okay so what happens when you press this button and the targeting system is air to air or air to ground and then something different happens and there's all these different conditions under which this button actually does something different and in the end sometimes there was some low-level programmer who had to make the decision because nobody knew and it wasn't in the requirements right so from his perspective he ended up creating this chart system because it was an easier way to communicate between these experts in order to define how a system actually works right and a side effect of this is that we ended up with a visual formalism that could actually be compiled and execute code so let's move on and see what's on the slide right so i'm going to try to quickly go over what are the properties of herald state machines essentially now we're instead of talking about inputs and outputs we're talking about events and actions right so we have a reactive system a button is pressed and perhaps the wing flap has to move right and that is a that is a reaction that is an action that takes place because of an event depending on the current system state which is basically how we we created this work how they started to think about designing this right um yeah so essentially what's to take home here is that when an event occurs it's merely and a more combined because the action can occur because of a transition and the action can occur as well because you've entered a state right so that's essentially it and the action can also occur when you leave the state in the first in the first model up above we can see that we have a state one state two state three state one and state two both transition to state three in the case of the bee event but then we for herald started adding this hierarchy kind of a concept and said we can simplify a very complex system and how to describe it by placing two states in the hierarchy and say well if the bee event occurs then we transition to state three and in the other example we can say well perhaps we don't care whether we're entering state one or state two from the perspective of state three so we have a concept of abstraction and we can say when we enter this state well there's a default state which is s1 and that state by itself can determine what happens when you enter that state right so we can we can reduce the amount of arrows in in a huge complex system and similarly here we've he has introduced orthogonality right so in this case basically you have a light control color of the light whether the light is flashing there's constant and of course you would need to have nine different states if you didn't have orthogonality to represent the same number of machine states and he added history so I'm just going to try to quickly go over all of the different features right histories this this example basically says okay for example you have one of those old watches and you can like press one button to cycle through the different controls that you have then you have the other button to actually choose something so for example you press the a button and you get into the alarm time control state and then you press the b button and it will change the what is your alarm time and when you leave the the time control state because it is a history state it will remember where you were the next time in right so that's history states and we have different kinds of transitions so we can add conditions because now we're integrating with code so any kind of transition can have a function that says no if I return false then don't take this transition right and then we have implicit so the first one is of course event transitions which is what we've all been talking about so far and we have some automated kinds of events like timeout states say well the system stays for 1000 for one second in this state and then continues right or of course what's interesting in an event-based program is idle states because then when the system or when the event loop becomes idle then we can have an idle transition right and of course we have transients transient transitions right so that's also a bit different from previous state machines so even without any events occurring these transitions will be followed what is interesting also or what is what is interesting to consider is when you have orthogonality and you have transient transitions the state machine should synchronize should synchronize the transient transitions to ensure that in each active orthogonal state only one like one transition has been followed and then in the next step we can evaluate the next transitions and continue on right so um after the Harrell state machines of course uml became popular now I haven't I've heard before that uml was coming from this but then when I did my research I couldn't find a link I know that Harrell state Harrell had added the state charge semantic to uml I found relevance of that but essentially the big difference between unified modeling languages and uh state machines or or state charts is that while Harrell had conceived of this in order to analyze requirements um he had come up with something that was fully specified but uml in general is not used in such a way that is fully specified it's more used just to communicate um requirements in design phase and waterfall development models and so we we analyze the requirements using uml and we pass it down the chain and people write code right um so that is generally uml I'm sure that I'm missing some things so why should I use state machines because you know I like my indentation and I like my tabs instead of spaces and I really love emacs not bi and unlike you right um so why use state machines right so state machines give you a different way of thinking about code and I've really enjoyed using state machines but there are some actual good reasons so I'm going to come back to this example a couple of times during the talk this is just a basic example of how to code a clicked event when you're writing a button widget in any kind of user user interface toolkit you basically have to handle four callbacks so there is when the mouse comes into your button area and then there's the event of whether the mouse click has gone down or the mouse click has come up right now in this case we can see that you need to actually record these two states right and when the button is released that's when you're going to do your branching statement and you're going to decide to emit clicked right of course the more states that your code is keeping track of and the more events that you have to handle all of this state needs to be considered in almost every callback and you have a combinatorial explosion of very complex branching statements and right so that that is that is unfun of course in object oriented programming we've kind of tried to address that problem with abstract classes and specialization and then things like this but state charts are fun right so if you were to do it with the state chart this would be your your state chart and in this case you really only have one state so this is a single hierarchical state machine or a state chart now there's one two three four five but there's a bunch of pre-programmed you know possible states there's actually three possible states but you only have one state pointer and the machine is either in that state or or it is not so in fact it it can be less memory intensive if done that way so essentially there's static data which defines the model and then there's only one pointer which says this is the state right so in this case you just need to feed the events into the state machine and you have one callback that says okay when I go from down to up and I'm inside the button it's clicked right so this does one interesting thing that I found well I find that it's much more safe and deterministic to code this way because as your program evolves and state gets added you have this guarantee that such and such event cannot happen and cannot be handled in this state which gives you it reduces the amount of branching statements and and cause for error which can happen arguments to be had later on if you wish so why don't we see this how come we don't see we see so much code but we don't see these state machines so much I have some answers for that um of course the object-oriented push in the late 90s everybody loved c plus plus um but let's skip over that basically there's two brands of adaptations of state charts that I've seen and one of them is essentially the the famous rational rhapsody which essentially it does everything right so I think that the I think it was even doing controlling threading for orthogonal states and it has like renders to multiple programming languages and it does code generation for absolutely everything if I'm not mistaken it also does revision control and all of this which of course by the year 2000 we were growing out of CVS and we're saying well I want to use git right or I want to use you know bitkeeper and then git and then how come I'm stuck with this big monstrous thing that like okay it's it's actually really great and really magic but you have to have all of it or nothing right and then the other the other approach is we have libraries which cause you to to write ad state ad state ad state at program initialization time so you have many calls in c or c plus plus like in the cute implementation which I've seen a lot used in automotive so what I found is that the complaints in the automotive industry using the cute implementation was that you have some people writing the state charts in the qt designer tools and then using uml and then you have other people writing code adding states and then you have people three years down the line who've added variables in the same module dancing around the state transitions and it ends up being quite a spaghetti mess because you've not enforced that you've not enforced that the callbacks are actually triggered by the state machine and you've added state and it's all competed in the same code right which is also not fun how I wish I had water okay so let's switch the topic oh I have water it's not mine thank you so much hopefully you're not falling asleep okay so let's talk about another state machine implementation so this is the state chart designer theater um this is a picture of this very very simple ui which I just baked up recently of theater editing itself we'll get back to that if we have time so right so this is a spinoff of a larger project which I started with munir ken fear in 2009 he had the brilliant idea of marrying a finnett state machine editor and engine with a user face user interface designer tool and to bring it all into one which uh we started together and then it took like four years of my coding to make it actually do something and in the end I made the same huge monstrosity of code generation which I couldn't really cause anybody to use especially since I didn't have that IBM sales force which rhapsody had which could say use use this huge thing so so that kind of didn't work out for me so I revived it quite recently and essentially I'm I'm looking at it from a perspective of like like next step or glade or qt interface designer we should have code and state charts separate in the same way that we have code and user interface design xml files and such separately so essentially the way we would use theater is that you will design a state chart design the brain of your project or your object and save it as a jason file right right now um the code generators are coming but the code generator will not generate everything it will just generate a dot a definition of your state machine and with references to callbacks that you can provide and this comes down to different implementation layers that are need to be different for different environments right um but in this case I just created the the layer that I needed to bring up the to bootstrap the designer tool right um if we were to have some python for example if I had a python layer the code for that button example would essentially look something like this possibly possibly we could even get rid of the enter notify leave notify forwarding events depending on how much introspection the the loading engine can have with with the python like toolkit environment for example if well if it had derived from a widget class and then the event name were matched you could with python you can basically crawl the whole data structure of your of your object class and you can you can bind it quite like this but essentially you just have to load the cursor you find your callback forward the events and say clicked and then the state machine would do everything for you right it's out there okay it's the end oh well then I'll skip over this I was looking for the somebody writing the how many minutes I had left and you are all the way over there oh my okay so you can get the code and look at it and criticize it and if you have a linux laptop you can install the tool right now if you have flat pack and enjoy