12 ms·

FSL: A programming language to make complex finite state machines easy to create

96 points by nlte 6y ago

zokier 6y ago
How does this compare to Ragel? http://www.colm.net/open-source/ragel/ http://www.colm.net/open-source/ragel/
- Cloudef 6y ago
  I was about to ask the same question
- tenderfault 6y ago
  I too was about to ask the same question
- tyingq 6y ago
  From playing with it a bit, the differences I see... Ragel compiles its source into a separate file in the target language (C, Ruby, ASM, etc). FSL instead has a library that parses and runs the FSL source at run time. Ragel supports (or plans to support) C, C++, ASM, Objective C, D, Go, Ruby, and Java. FSL supports (or plans to support) Javascript, C and Erlang. The live editor does seem to be somewhat unique to FSL. It's at https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... Try, for example, changing "flow: down" to "flow: right".
  - Cloudef 6y ago
    I think i still rely on ragel more. Its based on lots of research and the author knows the problem area very well.
- JohnHaugeland 6y ago
  I tried Ragel before writing my own I'm not a fan
argvargc 6y ago
Why are the examples and learning resources crossed-out?
- phaer 6y ago
  A link target of "#todo" suggests, that they are not finished yet.
jhvkjhk 6y ago
Is my ad provider broken, or there’s something wrong about the video link? “Using the live editor” is a Chicken fighting ninja, “What are state machines?” is a black woman singing(the cover is a laughing Jesus, why?), “Why FSL?” is Video unavailable, “Publishing a machine” is The history of Japan.
- luguenth 6y ago
  no, same for me
- x86ARMsRace 6y ago
  This is an, albeit somewhat comical, bug. I've got the same thing. A lot of other things in the site are broken too, most of the links at the top default to the /# link. My guess is something is broken in their back-end, or this got found and posted before the creators were ready for it to get publicity. The sample code also links out to /#todo, so I think my "not quite ready" idea may be what's up. Shame, this looks like it'd be a cool project.
  - JohnHaugeland 6y ago
    It's not a bug, and there exists no backend I just haven't written the site yet
    - coryrc 6y ago
      Lorem ipsum for next time you don't write a site :)
- JohnHaugeland 6y ago
  > Using the live editor” is a Chicken fighting ninja, “What are state machines?” is a black woman singing(the cover is a laughing Jesus, why?), “Why FSL?” is Video unavailable, “Publishing a machine” is The history of Japan. Yeah, I haven't made any of the videos yet. I'm camera shy and it's scary to be on the internet, so I've been dragging my heels. I didn't expect anyone to find the website so I thought it wasn't a big deal
Tabular-Iceberg 6y ago
What's the significance of the history of Japan to this project?
- tyingq 6y ago
  Appears to be a placeholder. Lots of "#todo" and placeholders in this project. Appears to have been posted to HN very early in its life.
- JohnHaugeland 6y ago
  There isn't any. This site wasn't meant to be public yet. I just posted some youtube videos I enjoy to make sure the build toolchain was placing youtube videos correctly.
rdez6173 6y ago
I'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.
- high_byte 6y ago
  this. I've been looking for something exactly like this, but this website does absolutely no justice to the core concept. I'm intrigued to see how this turns out.
- JohnHaugeland 6y ago
  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
  - vbtemp 6y ago
    Where is the repo? Its not available at all from the website
    - deleted 6y ago
      [deleted]
    - JohnHaugeland 6y ago
      So the thing is, FSL isn't released or announced. You're actually meant to be looking for the main implementation, `jssm`, which has been out for seven years. FSL is the new re-bake I started a year ago, and haven't gone public with yet. https://github.com/StoneCypher/jssm https://github.com/StoneCypher/jssm It's under the github link under libraries I added some top material to the site to make what's happening clearer
      - vbtemp 6y ago
        Ok, thanks, I think there was some confusion that you submitted a non-functional webpage to HN.
ModernMech 6y ago
While most of the site seems broken, at least the online editor is working. There's an example of a traffic light that gives some insight as to the design of the language: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... One thing I've learned personally writing live editors is that while recompile on every key seems neat, in practice it is very jarring to have things jump around every keystroke. The problem with this is that mid-typing you may express an invalid program, so your rendered output jumps wildly from something coherent to something completely wrong, only to resolve itself when you're done typing. This is why I think it's best practice to explicitly recompile on ctrl+enter, even if you have the ability to do it every keystroke.
- JohnHaugeland 6y ago
  > While most of the site seems broken I didn't expect anyone to find it It's just not done Workin' on it now ™ . > This is why I think it's best practice to explicitly recompile on ctrl+enter, even if you have the ability to do it every keystroke. This is interesting, and I like it I'm gonna leave it in its current default behavior because I believe that it has a strong impact on ease of onboarding to just see what you did without explicitly requesting it. But, I think I'm going to make this a configurable option, so that you can have the thing you wanted, and I may even start working this way myself (gonna have to try it and see how it feels.) Thank you for the idea, and please keep them coming. I appreciate your help. I am most likely to notice them in the FSL issue tracker: https://github.com/StoneCypher/fsl/issues https://github.com/StoneCypher/fsl/issues
bearjaws 6y ago
Anyone 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.
- davidkpiano 6y ago
  See here: https://twitter.com/DavidKPiano/status/1372549025753395207 https://twitter.com/DavidKPiano/status/1372549025753395207 And here: https://github.com/davidkpiano/xstate/discussions/255 https://github.com/davidkpiano/xstate/discussions/255
- Pfhreak 6y ago
  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.
- JohnHaugeland 6y ago
  It really depends on the quality of the underlying state machine library, and whether you're actually using them at a good time. Obviously, as the author of one of these things, I'm a pretty big fan of FSMs. And, y'know, even though the entire point of mine is to be easy and convenient to use, I still don't use it very often. Most jobs aren't for FSMs. Finite state machines aren't well applied everywhere. There are a lot of cases where you could use a finite state machine, but shouldn't. A chess board is an example: it is a well described state, there's clear right or wrongness to changes, there's no ambiguity or intermediate states, etc. However, managing a board that complicated, dealing with rules like en passant and castling, it'd be a hassle. You don't get enough value out of it, and so it doesn't matter what you're using. Yes, FSMs can handle chess; no, it's not a good choice IMO. But then, there are times when it's well applied. When it's something where an FSM is a good choice, and you've used a low-hassle library, my opinion is that they tend to make systems night-and-day simpler. Consider creating a finite state machine for the state of any single given payment. Now, when the external actor changes their process, the FSM wedges and you get notified, instead of switching to a state that used to be impossible and isn't anymore, in software that isn't ready for that. That's a huge level of immunity to large classes of bugs. My opinion is that FSMs are well applied when the cost of a state reaching a bad configuration is very high. You wouldn't use them to manage the image in a paint program. You would use them to control the airplane's jet being on or off. If you're in a situation where they're well applied? Now it's going to matter a lot which system you actually use. I have great respect for `xstate`, by example. It doesn't fit my preferences, but it's fast, robust, and largely bug-free. It's reliable, easy to work with, well documented, and has a good solid community. If you use `xstate` you'll have a good time, most likely. By contrast, at a previous ruby job, we used a gem I'm not going to name. It was ahem not my favorite. It was slow, it was pretty easy to get it wedged when it shouldn't be, it relied on side state things as storage that weren't fundamental to the language, it was cryptic when it failed, et cetera. Later, at that job, we switched to a different state machine gem. It was pretty hassle-ful; the datastructures needed to be manually converted because there was a slight difference in how the two gems saw the job which meant automatic conversion wasn't practical. But we were sure glad we did! Once the other FSM library was in place, things were a breeze, the system was much easier to understand, and to control. There's more to it than good or bad, though. If I couldn't use my own, what would I use? If it was business logic, I'd probably use `stent`. To me it's the easiest to debug, and seems the most robust. Their tracing tools are quite impressive. If it was a redistributable react control, I'd probably use `fsmx`, or embed a cut-for-case one. Stent is 288k. FSMx is 24k. If it's typescript, I'll probably use `fsmachine` instead, which is 28k. If I need transactionality, `edium` is my only real world choice. If I need something that's easy for junior programmers to understand, I'll probably use `javascript-state-machine`. If I need something to create documentation that's easy for non-programmers to use, it's very likely to be `state-machine-cat`. And of course, if I could use my own, I'd prioritize it when doing less labor or having a shorter representation of the machine is better. For me, that's pretty much always shrugs `xState`'s light switch is 13 lines; `jssm`'s is a one-liner that's shorter than `xstate`'s import. So. What I would recommend is that you pick one that graphs for you, like `stent` or `xState` or `jssm` or `state-machine-cat`, and just try drawing out a rough of your business logic. Maybe it's well implemented in a state machine. Maybe it isn't. But once you've tried, it's usually pretty obvious which one it is. And it can be fun to try, y'know? New languages are neat. If you have a bunch of little moving pieces that follow complicated rules and can't be wrong, there's a pretty solid chance that state machines are for you. They're one of those tools that the right time isn't common, but when it is the right time, holy WOW do you want them
fouc 6y ago
Any 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.
- gutino 6y ago
  I have always hope for that, RegEx syntax is not human and terrible.
- nabla9 6y ago
  Regular Expression in formal language theory sense can be represented as FSM's. Many real world string pattern matching engines (regexes) implement features that can't be expressed using regular languages. Backreferences or any context sensitive extensions are not really regal expressions in that sense.
- ben7799 6y ago
  For sure, and one of the best uses of theory out in the real world is showing someone when their design can't be handled by regular expressions because they designed a non-finite state machine. Just a weird thing that I have more than once had to do this in my career when someone dictated something had to be done with regular expressions when the requirements were for something that regular expressions were incapable of. Generally a fight every time.. the people dictating regular expressions as the solution are picking it as a solution because they fundamentally don't understand the difference between finite/non-finite automata, mostly because there are way too many CS degree programs that award Bachelor's degrees without teaching undergrads what the difference is between a DFA, NFA, and a turing machine.
- mattsouth 6y ago
  https://twitter.com/happyautomata https://twitter.com/happyautomata explores this space quite nicely
thinkloop 6y ago
It's trick site and it still made the front page?
ben7799 6y ago
I feel like this could be more useful as a DSL library for various other popular languages.
Datenstrom 6y ago
When 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 https://arxiv.org/pdf/1709.00084.pdf
- JohnHaugeland 6y ago
  Behavior trees can be fully implemented in this language, and are a (fairly limited) subset of finite state machines
  - Datenstrom 6y ago
    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. [1]: https://www.aaai.org/Papers/AIIDE/2008/AIIDE08-006.pdf https://www.aaai.org/Papers/AIIDE/2008/AIIDE08-006.pdf
Folcon 6y ago
Their live editor is here[0], for anyone interested in seeing a working example. I'm not affiliated with the project, just found the link among all the other stuff there. - [0]: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h...
derefr 6y ago
I feel like we don’t need a novel language for this. There’s already a pretty-well-known language that’s almost a DSL for “making complex finite-state machines easy to create”: Erlang. I know that sounds wacky, so let me pitch you on that idea :) In ‘primitive’ Erlang (i.e. Erlang without OTP), each FSM state is just a function, that can contain its own event loop (`receive` statement) to accept input, and then can transition to a new state based on that input by tail-calling another function. Such an Erlang module is a direct, 1:1 encoding of the FSM you’d draw on paper — and very readable as such — but is also plain-old executable Erlang code! In fact, this is basically the most idiomatic Erlang code you can write, syntactically. It’s when the language is at its best and most compact/expressive. (It’s also when all of Erlang’s weird syntax choices suddenly make perfect sense.) You can easily author+maintain an FSM with a large/complex tree of states and sub-states, by just putting each state function with its various sub-state functions into its own module, and then having each module only expose the valid entry states for each sub-state set. Because each independent FSM exists in its own actor (virtual thread of execution), you don’t need any more than this. You don’t need to worry about the data representation of the FSM — the FSM’s data representation is the actor’s process record + stack. And you don’t need to worry about how to “pump” the FSMs; they’re pumped by the runtime scheduler. (However, if you care about pinning down your concurrency model — e.g. if you’re trying to model a DSP — there are Erlang libraries for specific abstractions like CSP channels that you can use to do so.) It’s very easy to write a static analysis pass to verify that a primitive Erlang module like this constitutes an FSM “and no more” — i.e. that it could be transpiled into any other formalism that instantiates an FSM (e.g. a regex; a DSP; etc.) Erlang even breaks down its compiler into helpful separate reusable components (all available to any Erlang program) to help you do this. And these components make it just as easy to do the actual transpilation, turning this Erlang code into whatever other kind of encoded formalism you like. But, unlike most such formalism DSLs, it’s very easy to also break out of the FSM abstraction, and trade it for a more powerful one, if an FSM no longer works for your use-case. You’re working with regular Erlang code. So, if you just do a regular stack-frame-pushing call instead of a tail-call, now your FSM is a pushdown automaton. Or, if you pass a state variable on the stack along with each tail-call, now you’ve got a Turing machine. Honestly, ignoring all the stuff about concurrency, Erlang source code / BEAM bytecode is an almost perfect abstract machine for reifying various computational formalisms in an externally-verifiable way. If I was working on a computational proof for some CS conjecture, I’d heavily consider 1. writing the problem statement in (primitive, non-OTP) Erlang, and then 2. writing a small transpiler that would convert Erlang to lemmas in Z3 or Coq. (I’ve already done this once or twice, actually.) And, if I were implementing something like Cloudflare’s Edge Workers “but for FSMs” (e.g. some user-submitted pattern-matching automata for structured data, to filter user subscriptions to that structured data) then it’d be an extremely easy decision to standardize on (a restricted, static-analyzed at submit-time sub-ISA of) BEAM bytecode as the user-submitted program format. I would then just implement my worker server as a regular Erlang server that would load+run those checked BEAM modules.
mattsouth 6y ago
This library seems quite a lot quicker at runtime (20x) than https://thisrobot.life/ https://thisrobot.life/, at least for the red->green->yellow->red example in my very quick superficial test that follows the README.
Chris2048 6y ago
A programming language pronounced the same as a relatively prominent VCS? That would certainly confuse things..
Chris2048 6y ago
Seems 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.
ryanmarsh 6y ago
This looks very nice. Currently I’m learning how to use @davidkpiano’s XState. How would you say this compares?
- JohnHaugeland 6y ago
  If asked to choose which JS/TS FSM I respect most outside my own, I would have a hard time choosing between `xState` and `stent`. I think it's an excellent choice. David has done a better job of making a nice setup. His tooling is cleaner. `xState` is slightly faster than `jssm`. `xState` is much more widely used than `jssm` (several orders of magnitude,) meaning that it is more trustworthy. He has more tutorials. He has more community. His documentation is not literally on fire. I believe that my testing is significantly better. My library offers more features, including some fun exotic stuff like stochastic search. Whereas we both offer datastructure consumers (and they're similar,) I also offer a string DSL that is regularly 1/20 the byte count of the datastructure implementation. Terseness matters a lot to me. My typescript support is better. I have a live editor which I find has high value for understanding and debugging. I guess in my impression, my biggest thing is the string language (super dense, super easy) and his biggest thing is his community (you can ask people questions) Otherwise, in my impression we're quite similar. We both offer all the standard things; we both offer a visualizer; our visualizers look pretty similar because they're built on similar underpinnings. Being honest, I'd say he's winning. But, not by much, and there are clear reasons to choose one over the other according to preferences, so please try both.
0xFFC 6y ago
Very interesting project. Sorry for my ignorance though, where in the industry something like this might be useful?
- JohnHaugeland 6y ago
  State machines are a great way to control defects by producing states which are only able to mutate in certain specific pre-defined ways The defacto example is usually a traffic light. Green is permitted to transition to yellow, but never to red; a state machine makes a bug of that form impossible Obviously, it's nominally used for more complex stuff, but in general, all of your appliances are state machines. Your microwave especially.
remram 6y ago
Since I'm here, any tool recommendations for visualizing state machines, and state charts in particular? XState's [1] is ok but only works on the web and offers to export, and I found its layout algorithm a bit sub-par. Writing graphviz code by hand, or using google draw/draw.io/... gets painful very quickly. [1]: https://xstate.js.org/viz/ https://xstate.js.org/viz/
- JohnHaugeland 6y ago
  JSSM has JSSM-viz. https://github.com/StoneCypher/jssm-viz https://github.com/StoneCypher/jssm-viz If you just want one to use, rather than to embed in your own software, The thing everyone's calling a live editor is actually the JSSM-viz demo. You can use that https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... It's kept outside of the main repo because, like xstate's, it's built on a transcompile of graphviz called viz.js, which is made with emscripten It's several meg, and not many people want visualization, so I keep them in separate packages You can get the graphviz code by hitting "dot" at the top, if you want to customize in ways the language doesn't know
  - remram 6y ago
    The problem is that this uses your new custom language which is not yet documented. I had seen this, I asked for alternatives because it doesn't seem to be an option yet. The examples in your README also seem very limited, with no guards/actions/recursion/parallelism (correct me if I'm wrong). The last two I can do without but it seems overly simplistic as of now.
    - JohnHaugeland 6y ago
      > The examples in your README also seem very limited Agreed. . > with no guards It's not entirely clear what you mean by a guard. Isn't the entirety of a state machine a guard? If you mean transitions that are disallowed due to embedded mealy values, that's meant to be handled by the return value from hooks. That runs but isn't published yet because the test cases aren't yet adequate . > actions const yeah_huh = sm`has_actions 'tell_em' -> neat;`; or less glibly const matter = sm` solid 'melt' <-> 'freeze' liquid 'boil' <-> 'condense' gas 'ionize' <-> 'deionize' plasma; `; . > recursion State machines don't have control behavior and in general should not have direct expression of "recursion," unless I misunderstand what you mean If you mean machines self-embedding, that is planned, and I don't know of anyone else who does that . > parallelism Nothing stops you from putting a machine in each of a bunch of threads or web workers or whatever. By example, if you were making a Roller Coaster Tycoon style game, having one FSM to model each park visitor or each ride or each garbage pile or whatever would actually be fairly reasonable. Granted, I'd probably just make an array of them and process them serially in a single web worker, because you'd want the world synchronized and fast, but, it's doable. The core concept of a finite state machine has no direct association with process control and within a single finite state machine it's not actually clear to me what parallelism would mean within a single FSM. I've never seen this in any other state machine library. If this is what you mean, I'd like to hear more, possibly including an example API. It's possible that I misunderstand you. . > it seems overly simplistic as of now. If you can find a finite state machine with more features, please let me know where.
nojokes 6y ago
I found this https://stonecypher.github.io/fsl/draft%20tutorial.html https://stonecypher.github.io/fsl/draft%20tutorial.html tutorial
datavirtue 6y ago
Very cool. I looked through jssm but get the sense that fsl or jssm might be adapted so that it can be used to declaratively generate an FSM for any language? I wish my colleagues knew what an FSM was and how to create one. Getting tired of seeing 400 nested IF statements sprinkled across 10 classes. Something that makes it easy to create an FSM declaratively for any language might help raise awareness and spur adoption.
- JohnHaugeland 6y ago
  Yes. ♥ Target compilers for languages and other FSM libraries are a core goal, and I believe this is probably the single most important thing my language needs (comparables in portable external hooks and user-defined state datatypes.) I want the frontend and backend (and the database and the PaaS and the orbital weapons platform and the barbeque) to run the same machine, even when they aren't the same language. A bunch of these, and some I haven't listed yet due to sloth, are already implemented and just not published yet because they're not satisfactorily tested, and because I still don't know what I'm doing about portable hooks https://github.com/StoneCypher/fsl/issues/418 https://github.com/StoneCypher/fsl/issues/418 https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3Aopen+label%3A%22Transcompile+targets%22 https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3A... https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3Aopen+label%3A%22Compile+targets%22 https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3A... There are, actually, things like what you describe already - SMC, Canopy, and Ragel, by example, and depending on how you look at it, there's sort of an argument for Drakon and some others. I'm making mine because they don't fit my needs, but if you need something right now, they're options. SMC is probably the best of those in my opinion. It reaches 14 languages including most of the stuff you'll actually want, is durable, near-zero-bug once you learn what it means by its phrasings, reasonably fast, and does mostly everything you're likely to want in practice. It is entirely adequate from basically every angle, something very few state machines can say (mine cannot.) But also I'm hungry for users, so please try mine and let me know how you think I could improve. I believe that my ease of use characteristics are pretty nice, and my opinion is that ease of use is probably the Genuinely Big Barrier to fsm usage. My opinion is that mine is simple enough that people who don't know these things can often see the value. To me, that seems important. import { sm } from 'jssm'; const coworker = sm` not_convinced -> [whats_a_fsm dont_like_fsm js_has_no_lib]; whats_a_fsm -> this -> try_it -> ok; dont_like_fsm -> why -> [complicated boring intimidating]; complicated -> compare_machine_to_code -> oh; boring -> are_case_blocks_a_party -> oh; intimidating -> but_you_can_read_this -> and_you_dont_speak_this -> oh; js_has_no_lib -> tons_of_them -> jssm_is_an_easy_one -> oh; oh -> ok -> ill_try_jssm; `; Try giving them this and the resulting graph, and when they look at you funny, afterwards, give them some beefy awful thing with a bunch of control logic from your existing product, rewritten in a state machine, also with the resulting graph The resulting graph: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html?s=ATB2HsBcH0GN1ANwJalgUwCYhyAtAHzADaA7gBYCGkAztJaNAGY0C2wmCMANsgNbpmbYACs6VOhGi8ARgF0A3ACgQFanQZD2uHIWCRyyGsD2QATgE9oySCaLg+ykJ1A9+gltp16KFuyXhWAAdeWGosYBlwM1QAc2BUSGRWZExqOMUVHECQ5DDICJ18IhzKM0FWSlhDUEFIcDhwTHR-cHInHCiY0Hiior0ywTCaQRlucFg+DWggssg-PTaOkETk1PSevr0ZAFcYC3AduE1yykxoAyN-BnODo5cYGiD0Sj4Lw2NF9qyxaAloKSyPr+eqgOjgJjvdDsPRiNjWDSMF40KwIFpfDptYHY1p8fzIbjcC6WaBw1jKJRKMpmBixFrEHKhcLYLpxBKuNZpJI9TJKGiQcJgKCNJCoDDYABcwAA3pEqnxYmZDqBMHh4OMzFKAMRMWAyBTAAC+yn5goJRPMVjJIClspk8sVytV6ui2pkuoNxqUQA https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... If they're still on the fence, ask them how TCP works and give them a machine to read TCP machine to read: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html?s=FAWwhgxgFglgdgUwPpzCBACLGBcGBEAKgMIAKA9AJKkYDOALmPZuNPAvgNyiSyJIAbGBARxamPAFlKhbsAgCA9uIAmGALwA+DEIajOGeUtUYAtNoDaC5QjW0AnnCTi49ALpzdzOBu0OnAE4QAG4q3F6iZn6OzqL0cv6xrlEYFolBoRgIDGAARrpQthjWqh7AwOkhalpZOfkwtIVhFTEZauapET4AZvBIAO5gMPRIAIxlwNmM9Y1FNSXIg8O+OmAMSJAA1isLzVN5BUUdvU5LI6NyJwND5ykl8ADmKfQw6CrXyx273FdnYykWX43JAAJgwLzeH3clz6fzBHQhtih3CAA https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... One dollar on PayPal says they'll come around fast
dragontamer 6y ago
I've been dreaming of (ab)using C's "goto" statement to make easy to read finite state machines. An actual, proper language, for making FSMs probably makes more sense. Lol. But still, the conceptual similarity between a thread-of-execution and FSMs must remain in the back of most programmer's minds. All turing machines are FSMs, and your code determines the state. (When executing "foo" function, you're in the "foo" state. And the "foo" function easily tells you either to return to the previous state, or which states to move forward in).

96 points by nlte 6y ago

zokier 6y ago

How does this compare to Ragel? http://www.colm.net/open-source/ragel/ http://www.colm.net/open-source/ragel/

Cloudef 6y ago
I was about to ask the same question
tenderfault 6y ago
I too was about to ask the same question
tyingq 6y ago
From playing with it a bit, the differences I see... Ragel compiles its source into a separate file in the target language (C, Ruby, ASM, etc). FSL instead has a library that parses and runs the FSL source at run time. Ragel supports (or plans to support) C, C++, ASM, Objective C, D, Go, Ruby, and Java. FSL supports (or plans to support) Javascript, C and Erlang. The live editor does seem to be somewhat unique to FSL. It's at https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... Try, for example, changing "flow: down" to "flow: right".
- Cloudef 6y ago
  I think i still rely on ragel more. Its based on lots of research and the author knows the problem area very well.
JohnHaugeland 6y ago
I tried Ragel before writing my own I'm not a fan

argvargc 6y ago

Why are the examples and learning resources crossed-out?

phaer 6y ago
A link target of "#todo" suggests, that they are not finished yet.

jhvkjhk 6y ago

Is my ad provider broken, or there’s something wrong about the video link? “Using the live editor” is a Chicken fighting ninja, “What are state machines?” is a black woman singing(the cover is a laughing Jesus, why?), “Why FSL?” is Video unavailable, “Publishing a machine” is The history of Japan.

luguenth 6y ago
no, same for me
x86ARMsRace 6y ago
This is an, albeit somewhat comical, bug. I've got the same thing. A lot of other things in the site are broken too, most of the links at the top default to the /# link. My guess is something is broken in their back-end, or this got found and posted before the creators were ready for it to get publicity. The sample code also links out to /#todo, so I think my "not quite ready" idea may be what's up. Shame, this looks like it'd be a cool project.
- JohnHaugeland 6y ago
  It's not a bug, and there exists no backend I just haven't written the site yet
  - coryrc 6y ago
    Lorem ipsum for next time you don't write a site :)
JohnHaugeland 6y ago
> Using the live editor” is a Chicken fighting ninja, “What are state machines?” is a black woman singing(the cover is a laughing Jesus, why?), “Why FSL?” is Video unavailable, “Publishing a machine” is The history of Japan. Yeah, I haven't made any of the videos yet. I'm camera shy and it's scary to be on the internet, so I've been dragging my heels. I didn't expect anyone to find the website so I thought it wasn't a big deal

Tabular-Iceberg 6y ago

What's the significance of the history of Japan to this project?

tyingq 6y ago
Appears to be a placeholder. Lots of "#todo" and placeholders in this project. Appears to have been posted to HN very early in its life.
JohnHaugeland 6y ago
There isn't any. This site wasn't meant to be public yet. I just posted some youtube videos I enjoy to make sure the build toolchain was placing youtube videos correctly.

rdez6173 6y ago

I'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.

high_byte 6y ago
this. I've been looking for something exactly like this, but this website does absolutely no justice to the core concept. I'm intrigued to see how this turns out.
JohnHaugeland 6y ago
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
- vbtemp 6y ago
  Where is the repo? Its not available at all from the website
  - deleted 6y ago
    [deleted]
  - JohnHaugeland 6y ago
    So the thing is, FSL isn't released or announced. You're actually meant to be looking for the main implementation, `jssm`, which has been out for seven years. FSL is the new re-bake I started a year ago, and haven't gone public with yet. https://github.com/StoneCypher/jssm https://github.com/StoneCypher/jssm It's under the github link under libraries I added some top material to the site to make what's happening clearer
    - vbtemp 6y ago
      Ok, thanks, I think there was some confusion that you submitted a non-functional webpage to HN.

ModernMech 6y ago

While most of the site seems broken, at least the online editor is working. There's an example of a traffic light that gives some insight as to the design of the language: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... One thing I've learned personally writing live editors is that while recompile on every key seems neat, in practice it is very jarring to have things jump around every keystroke. The problem with this is that mid-typing you may express an invalid program, so your rendered output jumps wildly from something coherent to something completely wrong, only to resolve itself when you're done typing. This is why I think it's best practice to explicitly recompile on ctrl+enter, even if you have the ability to do it every keystroke.

JohnHaugeland 6y ago
> While most of the site seems broken I didn't expect anyone to find it It's just not done Workin' on it now ™ . > This is why I think it's best practice to explicitly recompile on ctrl+enter, even if you have the ability to do it every keystroke. This is interesting, and I like it I'm gonna leave it in its current default behavior because I believe that it has a strong impact on ease of onboarding to just see what you did without explicitly requesting it. But, I think I'm going to make this a configurable option, so that you can have the thing you wanted, and I may even start working this way myself (gonna have to try it and see how it feels.) Thank you for the idea, and please keep them coming. I appreciate your help. I am most likely to notice them in the FSL issue tracker: https://github.com/StoneCypher/fsl/issues https://github.com/StoneCypher/fsl/issues

bearjaws 6y ago

Anyone 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.

davidkpiano 6y ago
See here: https://twitter.com/DavidKPiano/status/1372549025753395207 https://twitter.com/DavidKPiano/status/1372549025753395207 And here: https://github.com/davidkpiano/xstate/discussions/255 https://github.com/davidkpiano/xstate/discussions/255
Pfhreak 6y ago
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.
JohnHaugeland 6y ago
It really depends on the quality of the underlying state machine library, and whether you're actually using them at a good time. Obviously, as the author of one of these things, I'm a pretty big fan of FSMs. And, y'know, even though the entire point of mine is to be easy and convenient to use, I still don't use it very often. Most jobs aren't for FSMs. Finite state machines aren't well applied everywhere. There are a lot of cases where you could use a finite state machine, but shouldn't. A chess board is an example: it is a well described state, there's clear right or wrongness to changes, there's no ambiguity or intermediate states, etc. However, managing a board that complicated, dealing with rules like en passant and castling, it'd be a hassle. You don't get enough value out of it, and so it doesn't matter what you're using. Yes, FSMs can handle chess; no, it's not a good choice IMO. But then, there are times when it's well applied. When it's something where an FSM is a good choice, and you've used a low-hassle library, my opinion is that they tend to make systems night-and-day simpler. Consider creating a finite state machine for the state of any single given payment. Now, when the external actor changes their process, the FSM wedges and you get notified, instead of switching to a state that used to be impossible and isn't anymore, in software that isn't ready for that. That's a huge level of immunity to large classes of bugs. My opinion is that FSMs are well applied when the cost of a state reaching a bad configuration is very high. You wouldn't use them to manage the image in a paint program. You would use them to control the airplane's jet being on or off. If you're in a situation where they're well applied? Now it's going to matter a lot which system you actually use. I have great respect for `xstate`, by example. It doesn't fit my preferences, but it's fast, robust, and largely bug-free. It's reliable, easy to work with, well documented, and has a good solid community. If you use `xstate` you'll have a good time, most likely. By contrast, at a previous ruby job, we used a gem I'm not going to name. It was ahem not my favorite. It was slow, it was pretty easy to get it wedged when it shouldn't be, it relied on side state things as storage that weren't fundamental to the language, it was cryptic when it failed, et cetera. Later, at that job, we switched to a different state machine gem. It was pretty hassle-ful; the datastructures needed to be manually converted because there was a slight difference in how the two gems saw the job which meant automatic conversion wasn't practical. But we were sure glad we did! Once the other FSM library was in place, things were a breeze, the system was much easier to understand, and to control. There's more to it than good or bad, though. If I couldn't use my own, what would I use? If it was business logic, I'd probably use `stent`. To me it's the easiest to debug, and seems the most robust. Their tracing tools are quite impressive. If it was a redistributable react control, I'd probably use `fsmx`, or embed a cut-for-case one. Stent is 288k. FSMx is 24k. If it's typescript, I'll probably use `fsmachine` instead, which is 28k. If I need transactionality, `edium` is my only real world choice. If I need something that's easy for junior programmers to understand, I'll probably use `javascript-state-machine`. If I need something to create documentation that's easy for non-programmers to use, it's very likely to be `state-machine-cat`. And of course, if I could use my own, I'd prioritize it when doing less labor or having a shorter representation of the machine is better. For me, that's pretty much always shrugs `xState`'s light switch is 13 lines; `jssm`'s is a one-liner that's shorter than `xstate`'s import. So. What I would recommend is that you pick one that graphs for you, like `stent` or `xState` or `jssm` or `state-machine-cat`, and just try drawing out a rough of your business logic. Maybe it's well implemented in a state machine. Maybe it isn't. But once you've tried, it's usually pretty obvious which one it is. And it can be fun to try, y'know? New languages are neat. If you have a bunch of little moving pieces that follow complicated rules and can't be wrong, there's a pretty solid chance that state machines are for you. They're one of those tools that the right time isn't common, but when it is the right time, holy WOW do you want them

fouc 6y ago

Any 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.

gutino 6y ago
I have always hope for that, RegEx syntax is not human and terrible.
nabla9 6y ago
Regular Expression in formal language theory sense can be represented as FSM's. Many real world string pattern matching engines (regexes) implement features that can't be expressed using regular languages. Backreferences or any context sensitive extensions are not really regal expressions in that sense.
ben7799 6y ago
For sure, and one of the best uses of theory out in the real world is showing someone when their design can't be handled by regular expressions because they designed a non-finite state machine. Just a weird thing that I have more than once had to do this in my career when someone dictated something had to be done with regular expressions when the requirements were for something that regular expressions were incapable of. Generally a fight every time.. the people dictating regular expressions as the solution are picking it as a solution because they fundamentally don't understand the difference between finite/non-finite automata, mostly because there are way too many CS degree programs that award Bachelor's degrees without teaching undergrads what the difference is between a DFA, NFA, and a turing machine.
mattsouth 6y ago
https://twitter.com/happyautomata https://twitter.com/happyautomata explores this space quite nicely

thinkloop 6y ago

It's trick site and it still made the front page?

ben7799 6y ago

I feel like this could be more useful as a DSL library for various other popular languages.

Datenstrom 6y ago

When 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 https://arxiv.org/pdf/1709.00084.pdf

JohnHaugeland 6y ago
Behavior trees can be fully implemented in this language, and are a (fairly limited) subset of finite state machines
- Datenstrom 6y ago
  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. [1]: https://www.aaai.org/Papers/AIIDE/2008/AIIDE08-006.pdf https://www.aaai.org/Papers/AIIDE/2008/AIIDE08-006.pdf

Folcon 6y ago

Their live editor is here[0], for anyone interested in seeing a working example. I'm not affiliated with the project, just found the link among all the other stuff there. - [0]: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h...

derefr 6y ago

I feel like we don’t need a novel language for this. There’s already a pretty-well-known language that’s almost a DSL for “making complex finite-state machines easy to create”: Erlang. I know that sounds wacky, so let me pitch you on that idea :) In ‘primitive’ Erlang (i.e. Erlang without OTP), each FSM state is just a function, that can contain its own event loop (`receive` statement) to accept input, and then can transition to a new state based on that input by tail-calling another function. Such an Erlang module is a direct, 1:1 encoding of the FSM you’d draw on paper — and very readable as such — but is also plain-old executable Erlang code! In fact, this is basically the most idiomatic Erlang code you can write, syntactically. It’s when the language is at its best and most compact/expressive. (It’s also when all of Erlang’s weird syntax choices suddenly make perfect sense.) You can easily author+maintain an FSM with a large/complex tree of states and sub-states, by just putting each state function with its various sub-state functions into its own module, and then having each module only expose the valid entry states for each sub-state set. Because each independent FSM exists in its own actor (virtual thread of execution), you don’t need any more than this. You don’t need to worry about the data representation of the FSM — the FSM’s data representation is the actor’s process record + stack. And you don’t need to worry about how to “pump” the FSMs; they’re pumped by the runtime scheduler. (However, if you care about pinning down your concurrency model — e.g. if you’re trying to model a DSP — there are Erlang libraries for specific abstractions like CSP channels that you can use to do so.) It’s very easy to write a static analysis pass to verify that a primitive Erlang module like this constitutes an FSM “and no more” — i.e. that it could be transpiled into any other formalism that instantiates an FSM (e.g. a regex; a DSP; etc.) Erlang even breaks down its compiler into helpful separate reusable components (all available to any Erlang program) to help you do this. And these components make it just as easy to do the actual transpilation, turning this Erlang code into whatever other kind of encoded formalism you like. But, unlike most such formalism DSLs, it’s very easy to also break out of the FSM abstraction, and trade it for a more powerful one, if an FSM no longer works for your use-case. You’re working with regular Erlang code. So, if you just do a regular stack-frame-pushing call instead of a tail-call, now your FSM is a pushdown automaton. Or, if you pass a state variable on the stack along with each tail-call, now you’ve got a Turing machine. Honestly, ignoring all the stuff about concurrency, Erlang source code / BEAM bytecode is an almost perfect abstract machine for reifying various computational formalisms in an externally-verifiable way. If I was working on a computational proof for some CS conjecture, I’d heavily consider 1. writing the problem statement in (primitive, non-OTP) Erlang, and then 2. writing a small transpiler that would convert Erlang to lemmas in Z3 or Coq. (I’ve already done this once or twice, actually.) And, if I were implementing something like Cloudflare’s Edge Workers “but for FSMs” (e.g. some user-submitted pattern-matching automata for structured data, to filter user subscriptions to that structured data) then it’d be an extremely easy decision to standardize on (a restricted, static-analyzed at submit-time sub-ISA of) BEAM bytecode as the user-submitted program format. I would then just implement my worker server as a regular Erlang server that would load+run those checked BEAM modules.

mattsouth 6y ago

This library seems quite a lot quicker at runtime (20x) than https://thisrobot.life/ https://thisrobot.life/, at least for the red->green->yellow->red example in my very quick superficial test that follows the README.

Chris2048 6y ago

A programming language pronounced the same as a relatively prominent VCS? That would certainly confuse things..

Chris2048 6y ago

Seems 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.

ryanmarsh 6y ago

This looks very nice. Currently I’m learning how to use @davidkpiano’s XState. How would you say this compares?

JohnHaugeland 6y ago
If asked to choose which JS/TS FSM I respect most outside my own, I would have a hard time choosing between `xState` and `stent`. I think it's an excellent choice. David has done a better job of making a nice setup. His tooling is cleaner. `xState` is slightly faster than `jssm`. `xState` is much more widely used than `jssm` (several orders of magnitude,) meaning that it is more trustworthy. He has more tutorials. He has more community. His documentation is not literally on fire. I believe that my testing is significantly better. My library offers more features, including some fun exotic stuff like stochastic search. Whereas we both offer datastructure consumers (and they're similar,) I also offer a string DSL that is regularly 1/20 the byte count of the datastructure implementation. Terseness matters a lot to me. My typescript support is better. I have a live editor which I find has high value for understanding and debugging. I guess in my impression, my biggest thing is the string language (super dense, super easy) and his biggest thing is his community (you can ask people questions) Otherwise, in my impression we're quite similar. We both offer all the standard things; we both offer a visualizer; our visualizers look pretty similar because they're built on similar underpinnings. Being honest, I'd say he's winning. But, not by much, and there are clear reasons to choose one over the other according to preferences, so please try both.

0xFFC 6y ago

Very interesting project. Sorry for my ignorance though, where in the industry something like this might be useful?

JohnHaugeland 6y ago
State machines are a great way to control defects by producing states which are only able to mutate in certain specific pre-defined ways The defacto example is usually a traffic light. Green is permitted to transition to yellow, but never to red; a state machine makes a bug of that form impossible Obviously, it's nominally used for more complex stuff, but in general, all of your appliances are state machines. Your microwave especially.

remram 6y ago

Since I'm here, any tool recommendations for visualizing state machines, and state charts in particular? XState's [1] is ok but only works on the web and offers to export, and I found its layout algorithm a bit sub-par. Writing graphviz code by hand, or using google draw/draw.io/... gets painful very quickly. [1]: https://xstate.js.org/viz/ https://xstate.js.org/viz/

JohnHaugeland 6y ago
JSSM has JSSM-viz. https://github.com/StoneCypher/jssm-viz https://github.com/StoneCypher/jssm-viz If you just want one to use, rather than to embed in your own software, The thing everyone's calling a live editor is actually the JSSM-viz demo. You can use that https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... It's kept outside of the main repo because, like xstate's, it's built on a transcompile of graphviz called viz.js, which is made with emscripten It's several meg, and not many people want visualization, so I keep them in separate packages You can get the graphviz code by hitting "dot" at the top, if you want to customize in ways the language doesn't know
- remram 6y ago
  The problem is that this uses your new custom language which is not yet documented. I had seen this, I asked for alternatives because it doesn't seem to be an option yet. The examples in your README also seem very limited, with no guards/actions/recursion/parallelism (correct me if I'm wrong). The last two I can do without but it seems overly simplistic as of now.
  - JohnHaugeland 6y ago
    > The examples in your README also seem very limited Agreed. . > with no guards It's not entirely clear what you mean by a guard. Isn't the entirety of a state machine a guard? If you mean transitions that are disallowed due to embedded mealy values, that's meant to be handled by the return value from hooks. That runs but isn't published yet because the test cases aren't yet adequate . > actions const yeah_huh = sm`has_actions 'tell_em' -> neat;`; or less glibly const matter = sm` solid 'melt' <-> 'freeze' liquid 'boil' <-> 'condense' gas 'ionize' <-> 'deionize' plasma; `; . > recursion State machines don't have control behavior and in general should not have direct expression of "recursion," unless I misunderstand what you mean If you mean machines self-embedding, that is planned, and I don't know of anyone else who does that . > parallelism Nothing stops you from putting a machine in each of a bunch of threads or web workers or whatever. By example, if you were making a Roller Coaster Tycoon style game, having one FSM to model each park visitor or each ride or each garbage pile or whatever would actually be fairly reasonable. Granted, I'd probably just make an array of them and process them serially in a single web worker, because you'd want the world synchronized and fast, but, it's doable. The core concept of a finite state machine has no direct association with process control and within a single finite state machine it's not actually clear to me what parallelism would mean within a single FSM. I've never seen this in any other state machine library. If this is what you mean, I'd like to hear more, possibly including an example API. It's possible that I misunderstand you. . > it seems overly simplistic as of now. If you can find a finite state machine with more features, please let me know where.

nojokes 6y ago

I found this https://stonecypher.github.io/fsl/draft%20tutorial.html https://stonecypher.github.io/fsl/draft%20tutorial.html tutorial

datavirtue 6y ago

Very cool. I looked through jssm but get the sense that fsl or jssm might be adapted so that it can be used to declaratively generate an FSM for any language? I wish my colleagues knew what an FSM was and how to create one. Getting tired of seeing 400 nested IF statements sprinkled across 10 classes. Something that makes it easy to create an FSM declaratively for any language might help raise awareness and spur adoption.

JohnHaugeland 6y ago
Yes. ♥ Target compilers for languages and other FSM libraries are a core goal, and I believe this is probably the single most important thing my language needs (comparables in portable external hooks and user-defined state datatypes.) I want the frontend and backend (and the database and the PaaS and the orbital weapons platform and the barbeque) to run the same machine, even when they aren't the same language. A bunch of these, and some I haven't listed yet due to sloth, are already implemented and just not published yet because they're not satisfactorily tested, and because I still don't know what I'm doing about portable hooks https://github.com/StoneCypher/fsl/issues/418 https://github.com/StoneCypher/fsl/issues/418 https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3Aopen+label%3A%22Transcompile+targets%22 https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3A... https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3Aopen+label%3A%22Compile+targets%22 https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3A... There are, actually, things like what you describe already - SMC, Canopy, and Ragel, by example, and depending on how you look at it, there's sort of an argument for Drakon and some others. I'm making mine because they don't fit my needs, but if you need something right now, they're options. SMC is probably the best of those in my opinion. It reaches 14 languages including most of the stuff you'll actually want, is durable, near-zero-bug once you learn what it means by its phrasings, reasonably fast, and does mostly everything you're likely to want in practice. It is entirely adequate from basically every angle, something very few state machines can say (mine cannot.) But also I'm hungry for users, so please try mine and let me know how you think I could improve. I believe that my ease of use characteristics are pretty nice, and my opinion is that ease of use is probably the Genuinely Big Barrier to fsm usage. My opinion is that mine is simple enough that people who don't know these things can often see the value. To me, that seems important. import { sm } from 'jssm'; const coworker = sm` not_convinced -> [whats_a_fsm dont_like_fsm js_has_no_lib]; whats_a_fsm -> this -> try_it -> ok; dont_like_fsm -> why -> [complicated boring intimidating]; complicated -> compare_machine_to_code -> oh; boring -> are_case_blocks_a_party -> oh; intimidating -> but_you_can_read_this -> and_you_dont_speak_this -> oh; js_has_no_lib -> tons_of_them -> jssm_is_an_easy_one -> oh; oh -> ok -> ill_try_jssm; `; Try giving them this and the resulting graph, and when they look at you funny, afterwards, give them some beefy awful thing with a bunch of control logic from your existing product, rewritten in a state machine, also with the resulting graph The resulting graph: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html?s=ATB2HsBcH0GN1ANwJalgUwCYhyAtAHzADaA7gBYCGkAztJaNAGY0C2wmCMANsgNbpmbYACs6VOhGi8ARgF0A3ACgQFanQZD2uHIWCRyyGsD2QATgE9oySCaLg+ykJ1A9+gltp16KFuyXhWAAdeWGosYBlwM1QAc2BUSGRWZExqOMUVHECQ5DDICJ18IhzKM0FWSlhDUEFIcDhwTHR-cHInHCiY0Hiior0ywTCaQRlucFg+DWggssg-PTaOkETk1PSevr0ZAFcYC3AduE1yykxoAyN-BnODo5cYGiD0Sj4Lw2NF9qyxaAloKSyPr+eqgOjgJjvdDsPRiNjWDSMF40KwIFpfDptYHY1p8fzIbjcC6WaBw1jKJRKMpmBixFrEHKhcLYLpxBKuNZpJI9TJKGiQcJgKCNJCoDDYABcwAA3pEqnxYmZDqBMHh4OMzFKAMRMWAyBTAAC+yn5goJRPMVjJIClspk8sVytV6ui2pkuoNxqUQA https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... If they're still on the fence, ask them how TCP works and give them a machine to read TCP machine to read: https://stonecypher.github.io/jssm-viz-demo/graph_explorer.html?s=FAWwhgxgFglgdgUwPpzCBACLGBcGBEAKgMIAKA9AJKkYDOALmPZuNPAvgNyiSyJIAbGBARxamPAFlKhbsAgCA9uIAmGALwA+DEIajOGeUtUYAtNoDaC5QjW0AnnCTi49ALpzdzOBu0OnAE4QAG4q3F6iZn6OzqL0cv6xrlEYFolBoRgIDGAARrpQthjWqh7AwOkhalpZOfkwtIVhFTEZauapET4AZvBIAO5gMPRIAIxlwNmM9Y1FNSXIg8O+OmAMSJAA1isLzVN5BUUdvU5LI6NyJwND5ykl8ADmKfQw6CrXyx273FdnYykWX43JAAJgwLzeH3clz6fzBHQhtih3CAA https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h... One dollar on PayPal says they'll come around fast

dragontamer 6y ago

I've been dreaming of (ab)using C's "goto" statement to make easy to read finite state machines. An actual, proper language, for making FSMs probably makes more sense. Lol. But still, the conceptual similarity between a thread-of-execution and FSMs must remain in the back of most programmer's minds. All turing machines are FSMs, and your code determines the state. (When executing "foo" function, you're in the "foo" state. And the "foo" function easily tells you either to return to the previous state, or which states to move forward in).