[HN Gopher] FSL: A programming language to make complex finite s...
___________________________________________________________________
FSL: A programming language to make complex finite state machines
easy to create
Author : nlte
Score : 94 points
Date : 2021-03-25 10:44 UTC (12 hours ago)
(HTM) web link (fsl.tools)
(TXT) w3m dump (fsl.tools)
| ModernMech wrote:
| 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.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.
| Folcon wrote:
| 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.h...
| datavirtue wrote:
| 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.
| bearjaws wrote:
| 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.
| JohnHaugeland wrote:
| 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
| Pfhreak wrote:
| 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.
| davidkpiano wrote:
| See here:
| https://twitter.com/DavidKPiano/status/1372549025753395207
|
| And here: https://github.com/davidkpiano/xstate/discussions/255
| Chris2048 wrote:
| A programming language pronounced the same as a relatively
| prominent VCS? That would certainly confuse things..
| ryanmarsh wrote:
| This looks very nice. Currently I'm learning how to use
| @davidkpiano's XState.
|
| How would you say this compares?
| JohnHaugeland wrote:
| 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.
| argvargc wrote:
| Why are the examples and learning resources crossed-out?
| phaer wrote:
| A link target of "#todo" suggests, that they are not finished
| yet.
| Tabular-Iceberg wrote:
| What's the significance of the history of Japan to this project?
| JohnHaugeland wrote:
| 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.
| tyingq wrote:
| 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.
| mattsouth wrote:
| This 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.
| fouc wrote:
| 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.
| mattsouth wrote:
| https://twitter.com/happyautomata explores this space quite
| nicely
| nabla9 wrote:
| 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 wrote:
| 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.
| gutino wrote:
| I have always hope for that, RegEx syntax is not human and
| terrible.
| Chris2048 wrote:
| 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.
| zokier wrote:
| How does this compare to Ragel?
|
| http://www.colm.net/open-source/ragel/
| tyingq wrote:
| 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.h...
| Try, for example, changing "flow: down" to "flow: right".
| Cloudef wrote:
| I think i still rely on ragel more. Its based on lots of
| research and the author knows the problem area very well.
| Cloudef wrote:
| I was about to ask the same question
| JohnHaugeland wrote:
| I tried Ragel before writing my own
|
| I'm not a fan
| tenderfault wrote:
| I too was about to ask the same question
| rdez6173 wrote:
| 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.
| JohnHaugeland wrote:
| 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 wrote:
| Where is the repo? Its not available at all from the website
| [deleted]
| JohnHaugeland wrote:
| 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
|
| It's under the github link under libraries
|
| I added some top material to the site to make what's
| happening clearer
| vbtemp wrote:
| Ok, thanks, I think there was some confusion that you
| submitted a non-functional webpage to HN.
| x86ARMsRace wrote:
| To clarify for anyone else, the poster and the author are
| not the same person! The poster looks like they
| discovered this, and posted it.
| high_byte wrote:
| 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.
| dragontamer wrote:
| 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).
| nojokes wrote:
| I found this
| https://stonecypher.github.io/fsl/draft%20tutorial.html tutorial
| remram wrote:
| 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/
| JohnHaugeland wrote:
| JSSM has 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.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
| derefr wrote:
| 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.
| JohnHaugeland wrote:
| > I feel like we don't need a novel language for this.
|
| Well, there's like 50 others, many of whom are in heavy use in
| industry, so, I guess I feel like a lot of people think this is
| useful.
|
| .
|
| > I feel like Erlang is already a great language -- almost a
| DSL -- for "making complex finite-state machines easy to
| create."
|
| Erlang is almost my favorite language.
|
| I've tried using both of its finite state machine libraries. I
| do not find them to be usable. The results are extremely
| verbose, and if one goes over around 30 states, I cease to be
| able to debug them.
|
| The natural implementation of the TCP/IP state machine in FSL
| is eight lines; 315 bytes. The TCP/IP Erlang state machine
| example floating around is like ten times that size.
|
| I find debugging that thing exhausting.
|
| .
|
| > 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"
|
| It's not clear to me why you would want this
|
| .
|
| > Honestly, ignoring all the stuff about concurrency, Erlang
| source code / BEAM bytecode is an almost perfect abstract
| machine for reifying various computational formalisms
|
| It can't implement anything without Okasaki juggling. You and I
| are in strong disagreement here.
|
| FSMs are a great example. You either need to reach outside the
| Beam VM with `hipe_bifs:array` or you need to copy the entire
| machine state every time you want to mutate it.
|
| .
|
| > And, if I were implementing something like Cloudflare's Edge
| Workers "but for FSMs", it'd be an extremely easy decision to
| standardize on (a restricted, static-analyzed at submit-time
| sub-ISA of) BEAM bytecode.
|
| At Cloudflare's scale, the inability to implement mutably would
| become a serious performance problem.
| derefr wrote:
| > I've tried using both of its finite state machine
| libraries.
|
| I'm not talking about gen_fsm or gen_statem -- note how I
| said "without OTP" above. I'm talking about writing Erlang
| the way it was originally conceived before proc_lib existed
| -- where each process has a module that's exclusively
| responsible for its own receive loop, rather than being a
| delegate module for a generic receive-loop manager framework
| (proc_lib).
|
| _That_ kind of Erlang code produces simple, easy-to-analyze
| bytecode. It doesn 't integrate well with supervisors or
| whatever, but interoperation with the rest of the Erlang/OTP
| ecosystem isn't the point. You don't call into arbitrary
| slap-dash non-formalized libraries within code that's
| supposed to represent a mathematical formalism. (E.g. you
| wouldn't call an arbitrary library from within a PEG grammar
| DSL. This is why e.g. Yecc's Erlang callbacks happen _after_
| parsing, rather than _instead of_ parsing. If they happened
| _instead of_ parsing, you 'd break the formalism of the
| parser, and wouldn't be able to trust that your grammar does
| in practice what it was proven to do in theory any more.)
|
| Instead, you create your own little world inside the
| formalism, that maybe imports a few reusable pre-proven
| abstractions compatible with the formalism, or that opaquely
| maps into pre-proven abstractions that exist within the
| prover (e.g. Z3's bit-vectors.) Abstractions are available in
| most-any other interpreter / prover / generator / whatever-er
| for the same formalism.
|
| > FSMs are a great example. You either need to reach outside
| the Beam VM with `hipe_bifs:array` or you need to copy the
| entire machine state every time you want to mutate it.
|
| Why are you mutating something outside the FSM from within
| the FSM? If the only state isn't "the state" (i.e. what box
| you're in on the FSM diagram), then what you have is not an
| FSM (in the computability-theory sense) any more.
|
| The point of an FSM is to _reduce_ the "power" of reasoning
| needed to prove things about the abstract machine -- and so
| to be able to _make guarantees_ that Turing machines _cannot_
| make, like being able to prove termination -- by constraining
| what side-effects an operation within the abstract machine
| can have. An FSM can only switch its state among one of a
| usefully-enumerable number of options, e.g. the set of
| functions in a module, or the possible values of a single
| machine-register. A pushdown automaton can only switch its
| state among the sets of all possible sequences of such
| usefully-enumerable options (i.e. stacks of FSM states.) Etc.
|
| (Note that Erlang/OTP's gen_fsm and gen_statem _aren 't_ FSMs
| in the computability-theory sense, since they pass along a
| state variable. They can be _used_ as such if you don 't put
| anything in that variable -- or even if you put a scalar in
| that variable and constrain its size -- but even if you don't
| use it, the resulting bytecode still passes that variable
| along in a way that makes it harder to translate the bytecode
| into prover lemmas. But all the remote-call stuff to proc_lib
| code that's not part of the proof _already_ makes that nigh-
| on impossible, so....)
|
| I think we might be talking about very different things here
| but both calling them "FSMs." I'm talking about how Erlang's
| native syntax is really good at expressing
| https://en.wikipedia.org/wiki/Deterministic_finite_automaton
| (like non-backtracking regexps) succinctly. What are _you_
| talking about?
| JohnHaugeland wrote:
| > note how I said "without OTP" above
|
| I apologize for overlooking this
|
| .
|
| > You don't call into arbitrary slap-dash non-formalized
| libraries
|
| Respectfully, no, it sounds like you write them yourself,
| instead
|
| .
|
| > > FSMs are a great example. You either need to reach
| outside the Beam VM with `hipe_bifs:array` or you need to
| copy the entire machine state every time you want to mutate
| it. > > Why are you mutating something outside the FSM from
| within the FSM?
|
| I'm not. I'm talking about the expense of the action of the
| FSM mutating itself.
|
| .
|
| > The point of an FSM is to reduce the "power" of reasoning
| needed to prove things about the abstract machine
|
| I apologize, but you and I have strongly contrasting
| opinions here.
|
| The rest of you trying to teach me what an FSM does is
| noted. Thank you for your time
|
| .
|
| > I think we might be talking about very different things
| here but both calling them "FSMs." I'm talking about how
| Erlang's native syntax is really good at expressing https:/
| /en.wikipedia.org/wiki/Deterministic_finite_automaton (like
| non-backtracking regexps) succinctly. What are you talking
| about?
|
| My library, and finite state machines, which are the
| superfamily containing DFA and a great many other things.
| DFA is not a common interpretation of the phrase FSM;
| usually that phrase means a Mealy machine or a Moore
| machine, or _maybe_ a Harel machine.
|
| I think you're spending more time attempting to force this
| library to implement some computer science term you're
| familiar with than is warranted. JSSM doesn't fit any of
| those labels well.
|
| DFAs are generally a small group of functions meant for
| parsing strings. JSSM isn't even superficially similar to a
| DFA, and most state machines in practice aren't implemented
| that way in my personal experience.
| odipar wrote:
| I agree with you. Especially breaking out of the abstraction
| when needed. I believe Akka also has a FSM abstraction on top
| of Actors.
| faeyanpiraat wrote:
| I do not know anything about erlang, but I'm intrigued about
| your proposal.
|
| Could you make a github repo with an example project
| implementing your solution?
| JohnHaugeland wrote:
| There are two FSM implementations in the standard library.
| Just use those.
| odipar wrote:
| I was very much in favour of (abstract) state machines,
| especially the Rebel DSL that was developed in Rascal.
|
| A _very_ nice thing about Rebel is that it can do (bounded)
| model checking using SMT solvers.
|
| Currently, I believe (Pure) Objects (with restrictions!) are
| a better approach because it doesn't require a paradigm
| switch. We already know them and they are also little state
| machines, right?
|
| If done right, we can also do explicit model checking etc,
| version control.
|
| Actors/Erlang/Akka is also a good choice, although they add
| some complexity compared to objects: it's hard to do
| synchronous calls with Actors for instance.
| jhvkjhk wrote:
| 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.
| x86ARMsRace wrote:
| 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 wrote:
| It's not a bug, and there exists no backend
|
| I just haven't written the site yet
| coryrc wrote:
| Lorem ipsum for next time you don't write a site :)
| JohnHaugeland wrote:
| > 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
| luguenth wrote:
| no, same for me
| 0xFFC wrote:
| Very interesting project. Sorry for my ignorance though, where in
| the industry something like this might be useful?
| JohnHaugeland wrote:
| 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.
| Datenstrom wrote:
| 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
| JohnHaugeland wrote:
| Behavior trees can be fully implemented in this language, and
| are a (fairly limited) subset of finite state machines
| Datenstrom wrote:
| 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
| ben7799 wrote:
| I feel like this could be more useful as a DSL library for
| various other popular languages.
| thinkloop wrote:
| It's trick site and it still made the front page?
___________________________________________________________________
(page generated 2021-03-25 23:02 UTC)