Hacker News new | ask | show | jobs
by datavirtue 1910 days 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.

1 comments

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?q=is%3Aissue+is%3A...

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

One dollar on PayPal says they'll come around fast