21–30 of 164 posts
If you've ever do any game programming you'll be drowning in state machines.
network protocol as well, hell, any non-toy network application ends up containing a state machine either implicitly or explicitly
I've been using state machines for Javascript UI elements.. really simplifies things.
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…
What? No, that isn’t true at all. State machines come before the FP/IP divide even existed. State machines are also intrinsically stateful, that should be obvious.
So are lots of data types, but those are still useful in FP.
Earlier quoted context omitted.
What? No, that isn’t true at all. State machines come before the FP/IP divide even existed. State machines are also intrinsically stateful, that should be obvious.
> State machines are also intrinsically stateful, that should be obvious. So are lots of data types, but those are still useful in FP.
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…
What? No, that isn’t true at all. State machines come before the FP/IP divide even existed. State machines are also intrinsically stateful, that should be obvious.
Of course developers whose last experience with state machines was in a college course won’t use them. Just read some of the comments below the article on storks.com. Labview developers use state machines extensively, because the implementation is graphical, beautiful, and prevents loose ends.
Additionally, I find that I cannot understand how the program works without actually drawing out the state machine diagram if I come across it the first time, so there is a bit of a learning curve. It's also a nightmare to test because of all of the states that need to be tested.
So in summary, not a fan. Like recursion... if it feels natural then use it, but I don't go and try and turn stuff that isn't a SM into one or turn something that can be done as loops into recursive function for fun.
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.
Earlier quoted context omitted.
What? No, that isn’t true at all. State machines come before the FP/IP divide even existed. State machines are also intrinsically stateful, that should be obvious.
The argument is not that state machines are the child of FP, just that a common idiom in FP, Pattern Matching over ADTs, makes them easy to implement.