4 ms·

"If you haven't built a finite state machine, you've built a bad finite state machine." I've recently started using Fulcro (framework in ClojureScript), where

"If you haven't built a finite state machine, you've built a bad finite state machine." I've recently started using Fulcro (framework in ClojureScript), where they are first class citizens in the form of "UI state machines." http://book.fulcrologic.com/#_ui_state_machines http://book.fulcrologic.com/#_ui_state_machines In retrospect it's obvious how much better it is to contain, for example, the logic of logging in and signing up within an FSM.

jwr 7y ago
I am not convinced that explicit state machines are a good way to write code. Using core.async you get an implicit state machine, while preserving the illusion of sequential code, which is much simpler from the developer point of view.
- AstralStorm 7y ago
  As long as you don't want to interact from said "sequential" code with the world. Then you get to deal with all the fun of asynchronous programming. Including but not limited to race conditions, data corruption and so on.
  - jwr 7y ago
    I'm not sure what you mean? Much of my core.async code deals with things like network requests.
  - sansnomme 7y ago
    Core.async supports Go-style channels so you are trading off speed (it has a runtime) for concurrency-correctness. It's a good fit for network requests since the bottleneck is elsewhere.
slifin 7y ago
I hope more community docs start springing up around Fulcro 3 soon Fulcro is doing so much innovation in the front end space that goes completely ignored by the wider community because lisp is hard to read and types are the be all end all of programming
- capableweb 7y ago
  > Fulcro is doing so much innovation in the front end space For someone who is versed in Clojure, what is Fulcro doing in the frontend space that is so innovative?
Jeff_Brown 7y ago
> "If you haven't built a finite state machine, you've built a bad finite state machine." Thank you! I read the article, and then beyond, and I still don't know what in tarnation distinguishes an FSM from a simple state. Every program has a set of states and transitions. Is the difference simply that in an FSM the programmer has modeled both sets explicitly? And if so, what is the model -- a map from states to available transitions?
- coldtea 7y ago
  >I read the article, and then beyond, and I still don't know what in tarnation distinguishes an FSM from a simple state. Well, FSM is a basic CS concept. >Every program has a set of states and transitions. Is the difference simply that in an FSM the programmer has modeled both sets explicitly? And if so, what is the model -- a map from states to available transitions? Yes, and actions on each transition.
- IlGrigiore 7y ago
  The main difference between a FSM and a statechart is the compositionality aspect of the two formalisms. The FSM can be combined using the OR and the AND operators: the AND operator produces a number of states that is equal to the cartesian product of the original states of the two FSMs that are conjuncted. This means that you are limited in the usefulness of the FSM by the number of interactions between systems, because the number of states increases exponentially. The statechart solves this problem by using a representation that allows both OR and AND avoiding the state explosion. Multiple states can be combined in a super-state, which allows to model common properties of the enclosed states, provided that the internal substates are XOR-ed, i.e. only one of them can be active in a given time. The advantage of the super-states is that they allow the specifier of the system to proceed in a top-down manner by specifying iteratevily the complete behaviour of the system. These super-states can also conjuncted, to model the interactions between the systems and to represent their parallelism. This conjunction creates implicit interactions between the two subsystems, which substitute the need to create the product FSM. Both FSM and statecharts can represent the same behaviour of a system, but they differ in how easily understandable their representation can be for complex systems.
tpoindex 7y ago
> "If you haven't built a finite state machine, you've built a bad finite state machine." SMC (State Machine Compiler) is worth bringing up here, which uses a formal language to define a state machine and produces code in one of a dozen+ languages to run it. Makes it impossible to build a bad state machine. I remember using this on some small projects last decade, I'm happily surprised to see it's still maintained. http://smc.sourceforge.net/ http://smc.sourceforge.net/ and code at: https://sourceforge.net/p/smc/git-code/ci/master/tree/ https://sourceforge.net/p/smc/git-code/ci/master/tree/

jwr 7y ago

I am not convinced that explicit state machines are a good way to write code. Using core.async you get an implicit state machine, while preserving the illusion of sequential code, which is much simpler from the developer point of view.

AstralStorm 7y ago
As long as you don't want to interact from said "sequential" code with the world. Then you get to deal with all the fun of asynchronous programming. Including but not limited to race conditions, data corruption and so on.
- jwr 7y ago
  I'm not sure what you mean? Much of my core.async code deals with things like network requests.
- sansnomme 7y ago
  Core.async supports Go-style channels so you are trading off speed (it has a runtime) for concurrency-correctness. It's a good fit for network requests since the bottleneck is elsewhere.

slifin 7y ago

I hope more community docs start springing up around Fulcro 3 soon Fulcro is doing so much innovation in the front end space that goes completely ignored by the wider community because lisp is hard to read and types are the be all end all of programming

capableweb 7y ago
> Fulcro is doing so much innovation in the front end space For someone who is versed in Clojure, what is Fulcro doing in the frontend space that is so innovative?

Jeff_Brown 7y ago

> "If you haven't built a finite state machine, you've built a bad finite state machine." Thank you! I read the article, and then beyond, and I still don't know what in tarnation distinguishes an FSM from a simple state. Every program has a set of states and transitions. Is the difference simply that in an FSM the programmer has modeled both sets explicitly? And if so, what is the model -- a map from states to available transitions?

coldtea 7y ago
>I read the article, and then beyond, and I still don't know what in tarnation distinguishes an FSM from a simple state. Well, FSM is a basic CS concept. >Every program has a set of states and transitions. Is the difference simply that in an FSM the programmer has modeled both sets explicitly? And if so, what is the model -- a map from states to available transitions? Yes, and actions on each transition.
IlGrigiore 7y ago
The main difference between a FSM and a statechart is the compositionality aspect of the two formalisms. The FSM can be combined using the OR and the AND operators: the AND operator produces a number of states that is equal to the cartesian product of the original states of the two FSMs that are conjuncted. This means that you are limited in the usefulness of the FSM by the number of interactions between systems, because the number of states increases exponentially. The statechart solves this problem by using a representation that allows both OR and AND avoiding the state explosion. Multiple states can be combined in a super-state, which allows to model common properties of the enclosed states, provided that the internal substates are XOR-ed, i.e. only one of them can be active in a given time. The advantage of the super-states is that they allow the specifier of the system to proceed in a top-down manner by specifying iteratevily the complete behaviour of the system. These super-states can also conjuncted, to model the interactions between the systems and to represent their parallelism. This conjunction creates implicit interactions between the two subsystems, which substitute the need to create the product FSM. Both FSM and statecharts can represent the same behaviour of a system, but they differ in how easily understandable their representation can be for complex systems.

tpoindex 7y ago

> "If you haven't built a finite state machine, you've built a bad finite state machine." SMC (State Machine Compiler) is worth bringing up here, which uses a formal language to define a state machine and produces code in one of a dozen+ languages to run it. Makes it impossible to build a bad state machine. I remember using this on some small projects last decade, I'm happily surprised to see it's still maintained. http://smc.sourceforge.net/ http://smc.sourceforge.net/ and code at: https://sourceforge.net/p/smc/git-code/ci/master/tree/ https://sourceforge.net/p/smc/git-code/ci/master/tree/