3 ms·

One of my go-to interview questions is "Can you tell me about a time when you've used an explicitly-modeled state machine in your programming?" Our work, heavy

by housel 9y ago

One of my go-to interview questions is "Can you tell me about a time when you've used an explicitly-modeled state machine in your programming?" Our work, heavy in embedded devices, network protocols, and parsing, is so full of state machines that I wouldn't want to hire someone who wasn't comfortable using them.

ssoft 9y ago
For equipment automation i am using end-state player which accelerate our development at least in 3 times. Why? There are three levels of hierarchy: conception level, detail, gui. All of these levels are independant to earch others, for example, arhitector can invented new conception with some fake elements which will be substituted in some future stages. Software developers who are making new elements (with parsers, new libraries and so on), regarding to conception above, are not intersected with conception and gui levels. In its turn gui developers use only state schema with all defined properties or data which are belong to every state.
jimmaswell 9y ago
Compilers and games are two areas I've used them a few times in.
- kchoudhu 9y ago
  Order/bid management in markets is also a case where they shine.
  - AstralStorm 9y ago
    Is that why orders tend to get stuck in "Delivery" state all the time?
    - kchoudhu 9y ago
      Not sure what you're referring to?
dominotw 9y ago
Is it pretty hard to pick it up for an average programmer?
- Sylos 9y ago
  Nah, not at all. It basically just means that you define states for your program to be in and you define from what state to what other state your program can go to under what conditions. For example, let's say you have a program that takes user input and once everything is entered correctly, then you move on to the next thing. That would mean you have a state "user_input" (or whatever you want to call it). Then you'd have a event "User clicks OK-button", with which you'd do a state transition. And then there's two possible state transitions, one which loops back onto user_input, for when the user enters something that's not correct, and one that points to the state of that next thing, with a condition of the user input being correct. You could also directly specify here what "correct" user input looks like. That's your choice. It's a design tool, use it to whatever depth you need it. There's a relatively intuitive notation standard, which you'll want to learn, as writing it all down is what gets you to actually think through all the states, events and conditions that there are. Implementation-wise, you'll usually have a variable that holds your state and then methods to do state transitions. You can also implement a check into those methods to ensure you're in a state that's allowed to transition to the state that this method transitions to.
- Sylos 9y ago
  Nah, not at all. It basically just means that you define states for your program to be in and you define from what state to what other state your program can go to under what conditions. For example, let's say you have a program that takes user input and once everything is entered correctly, then you move on to the next thing. That would mean you have a state "user_input" (or whatever you want to call it). Then you'd have a event "User clicks OK-button", with which you'd do a state transition. And then there's two possible state transitions, one which loops back onto user_input, for when the user enters something that's not correct, and one that points to the state of that next thing, with a condition of the user input being correct. You could also directly specify here what "correct" user input looks like. That's your choice. It's a design tool, use it to whatever depth you need it. There's a relatively intuitive notation standard, which you'll want to learn, as writing it all down is what gets you to actually think through all the states, events and conditions that there are. Implementation-wise, you'll usually have a variable that holds your state and then methods to do state transitions. You can also implement a check into those methods to ensure you're in a state that's allowed to transition to the state that this method transitions to. And even if you never end up using it, it is a nice mindset to get yourself into.
jschwartzi 9y ago
I had to do it to implement a 16-instruction loop for the TI RM4's High-End Timers, which are programmable timers that you can offload arbitrary pulse-train generation to, among other things. http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spna217 http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?li... Every instruction was a state and I had to model each of the transitions between instructions to understand the program flow.

by housel 9y ago

ssoft 9y ago

For equipment automation i am using end-state player which accelerate our development at least in 3 times. Why? There are three levels of hierarchy: conception level, detail, gui. All of these levels are independant to earch others, for example, arhitector can invented new conception with some fake elements which will be substituted in some future stages. Software developers who are making new elements (with parsers, new libraries and so on), regarding to conception above, are not intersected with conception and gui levels. In its turn gui developers use only state schema with all defined properties or data which are belong to every state.

jimmaswell 9y ago

Compilers and games are two areas I've used them a few times in.

kchoudhu 9y ago
Order/bid management in markets is also a case where they shine.
- AstralStorm 9y ago
  Is that why orders tend to get stuck in "Delivery" state all the time?
  - kchoudhu 9y ago
    Not sure what you're referring to?

dominotw 9y ago

Is it pretty hard to pick it up for an average programmer?

Sylos 9y ago
Nah, not at all. It basically just means that you define states for your program to be in and you define from what state to what other state your program can go to under what conditions. For example, let's say you have a program that takes user input and once everything is entered correctly, then you move on to the next thing. That would mean you have a state "user_input" (or whatever you want to call it). Then you'd have a event "User clicks OK-button", with which you'd do a state transition. And then there's two possible state transitions, one which loops back onto user_input, for when the user enters something that's not correct, and one that points to the state of that next thing, with a condition of the user input being correct. You could also directly specify here what "correct" user input looks like. That's your choice. It's a design tool, use it to whatever depth you need it. There's a relatively intuitive notation standard, which you'll want to learn, as writing it all down is what gets you to actually think through all the states, events and conditions that there are. Implementation-wise, you'll usually have a variable that holds your state and then methods to do state transitions. You can also implement a check into those methods to ensure you're in a state that's allowed to transition to the state that this method transitions to.
Sylos 9y ago
Nah, not at all. It basically just means that you define states for your program to be in and you define from what state to what other state your program can go to under what conditions. For example, let's say you have a program that takes user input and once everything is entered correctly, then you move on to the next thing. That would mean you have a state "user_input" (or whatever you want to call it). Then you'd have a event "User clicks OK-button", with which you'd do a state transition. And then there's two possible state transitions, one which loops back onto user_input, for when the user enters something that's not correct, and one that points to the state of that next thing, with a condition of the user input being correct. You could also directly specify here what "correct" user input looks like. That's your choice. It's a design tool, use it to whatever depth you need it. There's a relatively intuitive notation standard, which you'll want to learn, as writing it all down is what gets you to actually think through all the states, events and conditions that there are. Implementation-wise, you'll usually have a variable that holds your state and then methods to do state transitions. You can also implement a check into those methods to ensure you're in a state that's allowed to transition to the state that this method transitions to. And even if you never end up using it, it is a nice mindset to get yourself into.

jschwartzi 9y ago

I had to do it to implement a 16-instruction loop for the TI RM4's High-End Timers, which are programmable timers that you can offload arbitrary pulse-train generation to, among other things. http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spna217 http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?li... Every instruction was a state and I had to model each of the transitions between instructions to understand the program flow.