51–60 of 164 posts
Fast forward 8 years and everyone on the front end is using state machines with the rise of react/redux et al.
A reducer store is not a state machine since both the transitions and states are loosely defined. That said, at this point I think it's actually better for UI, despite the verbosity and lack of formal correctness.
Earlier quoted context omitted.
> State machines are also intrinsically stateful, that should be obvious. So are lots of data types, but those are still useful in FP.
Yes, that should be obvious also. State machines have no strong relationship with FP. I'm not sure where this claim even comes from!
Earlier quoted context omitted.
Plenty of imperative domain spaces use state machines, gamedev and the like come to mind in particular.
Similarly with embedded development. We use them for just about everything from communications to scheduling. I think the subtext here is that state machines are just rarely used for web/mobile...
Traditional programming languages and imperative thinking don't lend themselves to writing state machines, so its not really that surprising that they're under utilized. Its kind of frustrating constantly reading posts where people shit on functional programm(ers|ing) for being too ivory tower-y or whatever, when its kind of hard not to be when a lot of the older FP guys have spent the last like 20-30 years going "yo…
Plenty of imperative domain spaces use state machines, gamedev and the like come to mind in particular.
Ads that auto pay audio on a developer blog, really?
Bonus: Pages written by developers who don't know/care about graceful degradation appear blank, so you don't have to waste time reading them.
Traditional programming languages and imperative thinking don't lend themselves to writing state machines, so its not really that surprising that they're under utilized. Its kind of frustrating constantly reading posts where people shit on functional programm(ers|ing) for being too ivory tower-y or whatever, when its kind of hard not to be when a lot of the older FP guys have spent the last like 20-30 years going "yo…
That's probably not the problem - imperative development can start off from a level of complexity where state machines don't look relevant.
Six weeks down the line, the whole codebase has overtaken the complexity of a state machine, though each of the development bugs were simple fixes to the original branching code.
The standard web-app wizard is where I've run into this again and again.
Every web-app is stateful enough to maintain DB state sync'd & ticking over from a user-click, which makes it really easy to work out whether all clicks go somewhere useful.
However this makes sense only when you have around 7+ states and transitions between them (particularly the "go back" one).
Until then, the regular if/else branch scenarios work out just fine ... but then when you're near the 20-30 state range, it all falls apart.
1 current version: https://github.com/pluginaweek/state_machine
1a original unmaintained version: https://github.com/pluginaweek/state_machine
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.
Is it pretty hard to pick it up for an average programmer?
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.
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.
Is it pretty hard to pick it up for an average programmer?
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.