How does this compare to Ragel? http://www.colm.net/open-source/ragel/
I tried Ragel before writing my own
I'm not a fan
FSL: A programming language to make complex finite state machines easy to create
31–40 of 74 posts
Re: FSL: A programming language to make complex finite state machines easy to create
#32This library seems quite a lot quicker at runtime (20x) than https://thisrobot.life/, at least for the red->green->yellow->red example in my very quick superficial test that follows the README.
Re: FSL: A programming language to make complex finite state machines easy to create
#33I'm not sure why this is being shared if the site is wholly incomplete. Outside of the TODO links and bogus videos, two of the listed libraries point to invalid or archived repos in GitHub.
Hi, I'm the author. I just haven't made the site because the repo is complete I'll go change the site. It had never been released, announced, or indicated. This is being shared because there's a complete programming language in active use by many people
Where is the repo? Its not available at all from the website
Re: FSL: A programming language to make complex finite state machines easy to create
#34Anyone with experience using finite state machines in production apps want to share their experience? I love the concept, but not sure how to implement a POC so my teams can see the value. We have a few areas that have a ton of dense business logic, and I think something like xState could be beneficial.
Re: FSL: A programming language to make complex finite state machines easy to create
#35When I worked on robotics I often found myself reaching for behavior trees for anything complex over a FSM. See section 2 of "Behavior Trees in Robotics and AI"[1] for an example of how much simpler they are. I think they are popular in game dev too but I've never worked in that field. [1]: https://arxiv.org/pdf/1709.00084.pdf
Behavior trees can be fully implemented in this language, and are a (fairly limited) subset of finite state machines
I do not believe that is true. Pure FSMs are not Turing complete[1] while behavior trees can be made trivially so. BTs are not isomorphic to FSMs. I am not aware of any system that can be modeled in an FSM and not in a behavior tree.
Re: FSL: A programming language to make complex finite state machines easy to create
#36A programming language pronounced the same as a relatively prominent VCS? That would certainly confuse things..
Re: FSL: A programming language to make complex finite state machines easy to create
#37Seems like the site wasn't ready yet (see author comments), maybe HN should have criteria for whether certain links should be posted? Or perhaps a convention where-by website author can indicate they do not want to be posted on social aggregators.
Aside: I actually think HN might be better if no karma was given for link submissions.
Re: FSL: A programming language to make complex finite state machines easy to create
#38Any Regular Expression can be represented as a Finite State Machine. Knowing this, I usually look at things like this because I'm hoping that someday someone will come up with a new concise & readable way of writing both regular expressions and finite state machines.
https://twitter.com/happyautomata explores this space quite nicely
Re: FSL: A programming language to make complex finite state machines easy to create
#39This looks very nice. Currently I’m learning how to use @davidkpiano’s XState.
How would you say this compares?
Re: FSL: A programming language to make complex finite state machines easy to create
#40Anyone with experience using finite state machines in production apps want to share their experience? I love the concept, but not sure how to implement a POC so my teams can see the value. We have a few areas that have a ton of dense business logic, and I think something like xState could be beneficial.
XState is incredible when combined with something like Svelte. I've seen it used to power videogame UIs (huds, health bars, menus, etc.) for a AAA shooter.
The really nice thing about working with it is that all your components get much simpler about understanding when and how they should render. No longer are you trying to track state through some combination of variables or await statements, you are just asking, "Am I in this state? Great, I'll render." Double if you are managing animations or something else that takes wall clock time.
You also get an amazing visualizer and debug toolset where you can both see your app transition states, and inject the events to watch it transition states easily.
Would highly recommend checking out xstate in front end dev.