I think actions vs calculations is a better framing here. It's not just about avoiding imperative code or nondeterminism. It's about being extra careful with actions because the order and number of times they run matter.
Here is an example of a calculation written imperatively. It remains easy to reason about because the actions don't leak out of the function:
function add(ns) {
let total = 0
for (const n of ns) {
total += n
}
return total
}
On the other hand, a deterministic state machine like `a = AddMachine` is harder to reason about because it still matters how many times the action `a.transition(1)` is called. (Note it is possible to implement the state machine as calculations.)
Leftium · · focus · HN ↗
Here is an example of a calculation written imperatively. It remains easy to reason about because the actions don't leak out of the function:
On the other hand, a deterministic state machine like `a = AddMachine` is harder to reason about because it still matters how many times the action `a.transition(1)` is called. (Note it is possible to implement the state machine as calculations.)<a href="https://ericnormand.me/podcast/what-is-an-action" rel="nofollow">https://ericnormand.me/podcast/what-is-an-action
<a href="https://livebook.manning.com/book/grokking-simplicity/chapter-3/page_52" rel="nofollow">https://livebook.manning.com/book/grokking-simplicity/chapte...