News for hackers. Stuff that matters.
Re:Simpler UI Logic With Finite State Machines by fnordsensei on Monday December 23, 2019 @05:20AM (#21862684)
"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

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.

Re:Simpler UI Logic With Finite State Machines by jwr on Monday December 23, 2019 @07:25AM (#21863192)
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.
Re:Simpler UI Logic With Finite State Machines by AstralStorm on Monday December 23, 2019 @09:06AM (#21863640)
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.
Re:Simpler UI Logic With Finite State Machines by sansnomme on Monday December 23, 2019 @01:46PM (#21866001)
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.
Re:Simpler UI Logic With Finite State Machines by jwr on Monday December 23, 2019 @11:16AM (#21864611)
I'm not sure what you mean? Much of my core.async code deals with things like network requests.
Re:Simpler UI Logic With Finite State Machines by tpoindex on Monday December 23, 2019 @11:04AM (#21864509)
> "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/ and code at: https://sourceforge.net/p/smc/git-code/ci/master/tree/

Re:Simpler UI Logic With Finite State Machines by Jeff_Brown on Monday December 23, 2019 @11:00AM (#21864471)
> "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?

Re:Simpler UI Logic With Finite State Machines by IlGrigiore on Monday December 23, 2019 @02:38PM (#21866571)
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.

Re:Simpler UI Logic With Finite State Machines by coldtea on Monday December 23, 2019 @01:49PM (#21866027)
>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.

Re:Simpler UI Logic With Finite State Machines by slifin on Monday December 23, 2019 @07:33AM (#21863226)
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

Re:Simpler UI Logic With Finite State Machines by capableweb on Monday December 23, 2019 @04:13PM (#21867428)
> 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?