in the next iteration people using this pattern will understand that using separate classes to switch between states is a much better approach that can be checked by static type checkers like `mypy` in Python or a compiler in any of OO compiled languages
You must be joking... did I miss the sarcasm? Why in the world would you ever smear a state machine over several classes???? That makes it almost impossible to follow your program logic. The very beauty of a state machine with e.g. a switch statement is that it's all in one place... so you (and the people who have to maintain your legacy code!) can see immediately where things are going wrong. This also makes extending the state machine is nearly trivial. You are a good example of what's wrong with the OOP crowd.
Perhaps it's easier to make unavailable functions unavailable in the user interface, rather than generate an error when the user selects an unavailable function.
The better way is to give an explanation why the function is not available and what pre-requisites the user has to provide to make it available. Yes, there is the crowd that thinks that the user is a toddler who needs to be put into a tiny cage... that crowd tends to write highly unintuitive and frustrating software that leaves no room for growth, neither for the user nor the software designer. If you want to treat your user like an adult, tell him what the program needs to be able to do more for him. If you can't do that, then you don't understand either your user nor your own software.
But how does state machine library works? It checks the state (true or false) for every condition. He only abstract the code using an external library.
Go read the source code of the pytransitions library. It's a 20 minutes talk. What do expect? I think the speaker did a fantastic job in explaining the problem and pointing the audience in the right direction.
@@rednafi I agree. Even if I'm currently struggling to implement a state machine, I watched this to understand the use cases and design, not the implementation.
umh, yeah, but abstraction is good. It's reusable, it's maintainable, it's flexible. it's less error prone. so, even if it's abstracted, it still fits the aim of the talk. by the way, thanks for the comment (:
@@yash1152 Abstraction for abstraction sake is a bad idea. Everybody who can touch your code understands if-then-else and switch... and almost nobody wants to read the documentation for your choice of state machine library. Moreover, you may be running into some serious performance problems with libraries that are too general for your particular use case.
That is very useful and exactly what I needed. A project I'm working on right now is polluted with flags, and this is going to help so much.
Surprise of how small are the commentary count on this video.
This video is amazing !
I've watched tons and tons of tech talks in the past few years and this one was one of the best I've seen. Thanks for sharing
The clearest explanation about the state machine, Thanks.
Genius! Stumbled on this when I was almost giving up
Exactly what I needed!! Thank you so much!
Freaking useful!
Finally a real application of my formal language and automata course
Excellent talk. State Machines very well explained. Well done Harrington Joseph.
Excellent video
great talk
Highlighted the use case of state machine really well, I needed that. Shame the implementation used a library though
Marvelous.
Great presentation, thanks!
Nice explanation and use case.
It's pretty helpful, thanks
in the next iteration people using this pattern will understand that using separate classes to switch between states is a much better approach that can be checked by static type checkers like `mypy` in Python or a compiler in any of OO compiled languages
You must be joking... did I miss the sarcasm? Why in the world would you ever smear a state machine over several classes???? That makes it almost impossible to follow your program logic. The very beauty of a state machine with e.g. a switch statement is that it's all in one place... so you (and the people who have to maintain your legacy code!) can see immediately where things are going wrong. This also makes extending the state machine is nearly trivial. You are a good example of what's wrong with the OOP crowd.
Ok, this is useful. Thanks
Thanks
great one
1) Say what you're going to say. 2) Say it. 3) Say what you said. This is the way.
Love it thanks a lot!
no rewinding if tape stopped? So unlike any tape machine ever made..
Perhaps it's easier to make unavailable functions unavailable in the user interface, rather than generate an error when the user selects an unavailable function.
The better way is to give an explanation why the function is not available and what pre-requisites the user has to provide to make it available. Yes, there is the crowd that thinks that the user is a toddler who needs to be put into a tiny cage... that crowd tends to write highly unintuitive and frustrating software that leaves no room for growth, neither for the user nor the software designer. If you want to treat your user like an adult, tell him what the program needs to be able to do more for him. If you can't do that, then you don't understand either your user nor your own software.
NFA is probably the easiest way to express a state machine, but there are other kind of automata which may be used to model the state machine.
A state machine can be written easily with if-then-else or switch statements. No need to complicate things.
👏
Very great presentation👍🏿
amazing
But how does state machine library works? It checks the state (true or false) for every condition.
He only abstract the code using an external library.
Go read the source code of the pytransitions library. It's a 20 minutes talk. What do expect? I think the speaker did a fantastic job in explaining the problem and pointing the audience in the right direction.
@@rednafi I agree. Even if I'm currently struggling to implement a state machine, I watched this to understand the use cases and design, not the implementation.
umh, yeah, but abstraction is good. It's reusable, it's maintainable, it's flexible. it's less error prone.
so, even if it's abstracted, it still fits the aim of the talk.
by the way, thanks for the comment (:
@@yash1152 Abstraction for abstraction sake is a bad idea. Everybody who can touch your code understands if-then-else and switch... and almost nobody wants to read the documentation for your choice of state machine library. Moreover, you may be running into some serious performance problems with libraries that are too general for your particular use case.
neat im going to make garbage
amazing