4 ms·
> And not using state machines explicitly always results in conflating these. Not true - (pure) functional programming also enforces that you do exactly that.
by valenterry 6y ago
> And not using state machines explicitly always results in conflating these.
Not true - (pure) functional programming also enforces that you do exactly that. Even more, its rule-set also enforces that time must be an input.
- marcosdumay 6y agoMost pure functional idioms for handling a protocol are state machines, some of them in disguises, others plain ones. The ones that aren't state machines are very limited and often enough way too verbose. In particular, FRP is worth noticing as being exactly a set of states that change by means of events. It's a nice idiom for composing very complex state machines, but isn't even disguised.
- valenterry 6y agoI think it is the other way around. FRP goes further than state machines, in that it forbids any side effects. E.g. you could build a state machine that, when in a certain state and getting a certain event, responds or acts by printing the current time. A classical state machine will thus behave different, depending when it receives the event. However, in FRP you _must_ either parametrize the event with the current time, or you need to have something _outside_ of the statemachine (such as an effect interpreter) which handles effects such as printing the current time. A classic state machine does not have these restrictions.
- lmm 6y agoGeneral state machines are useless as an abstraction: they're fundamentally noncompositional, which makes them impossible to reason about as soon as they get big enough. Many things can be represented as state machines, just as any program can be represented as a sequence of machine instructions; that doesn't mean that's a useful representation for working with.