Also, I'm trying to learn this because I'm interested in seeing if I can apply this to Dart/Flutter. I think there's potential there.
An action would look like this:
const action1 = (a,b,c) => {
// create / compute / fetch the proposal
return { a, b, c }
}
then you wrap actions into something like this:
const intentFactory = (model, action) => (...args) => {
model.present(actions(...args) )
}
const intent1 = intentFactory(model, action1)
then you can call
intent1(a,b,c)
From my experience, it's a very logical way to decompose your business logic and in particular, decouple it from the view.
It's not too different from other paradigm say like Redux or Elm, but the main difference is on the emphasis on giving more responsibilities to actions (computing/preparing the proposal) while Redux and Elm tend to have anemic actions that are just a data object.
Then there is also the many-to-many relationship between actions and acceptors (an action's proposal can trigger mutiple acceptors and multiple actions can trigger the same acceptor).
Lastly, there are reactors that "react" to mutations. All these concepts are in redux, but the emphasis on how to use them is very different.
What I don't like about Redux and Elm is that the logic is concentrated in a single reducer and actions are just data object.
IMHO, that's why people complain about Redux, for real world application, that's just not the right thing to do. But again, that's just a style, you could choose a style that's closer to SAM. It would be harder with Elm, as I understand it.
An acceptor would mutate the state, the reactor would react to the mutation calculating computed values (technically a mutation, but automatic mutation). For instance, you could have an action that changes the settings of a thermostat. The inner workings of the system are using Celcius, but the user has chosen to display the temperatures (setting, measured value...) in Farenheight. A reactor would compute the resulting Farenheight values, while the reactor will do all the checks to see if the new setting is valid and decide to accept it or reject it.
The idea behind SAM is to isolate mutations to their lowest form, unencumbered by the pre-calculations of the proposal and the post-calculations of computed results (while putting the mutations in a critical section).
In Meiosis this is slightly different, in that mutation happens automatically, BUT acceptors look at the state and make any further changes to produce the accepted state. So, nothing else sees the state until the acceptors have done their work. There is no formal distinction between an acceptor that alters the state (equivalent of rejecting or altering a proposal) and an acceptor that produces computed values.
Again, the idea is to keep the mutation code to a minimum to be able to reason clearly about it. Nothing magical about it. Just making mutations a first-class citizen of the programming model, as
acceptors.
A client of mine is pushing flutter for a mobile app project.. if it wins over my recommendations, I’d like to try porting the Sam library to dart, and see how it fits in flutter. I don’t like the state management in flutter, but maybe there’s some hope with SAM (plus I’ll need to explain it to my client)
that's one big plus if you prefer wiring it up via observables/streams
I don’t like such binding approaches anymore, they’re just cumbersome to deal with
PS: despite some weird choices in its grammar, golang proves to be a perfect fit in many situations. I don't know how it scales when used for web or API development, but it's super useful in devops and systems programming, and I use it for backup scripts, notification scripts, daemons/services and so on
being able to cross-compile everything with a single command, it's a real time saver (when you have a mixed farm of linux and windows servers, plus macos clients)
I was purely talking about the language, oh my... not sure where to start, my eyes are still flashing at all the error handling and my mind is still cramped to understand what's inferred from what's declared in the language. I love the json annotations though, just kidding.
Million dollar question: how much boilerplate can be avoided when a language adopts a JSON like construct (with destructuring and optional-chaining)?
SAM seems to work best with UI frameworks that very selectively update. React is good, lit-html is even better. But for instance, Dart/Flutter (and SwiftUI and Jetpack Compose) doesn’t have anything similar to dom-diffing which can determine what in the tree has changed and only update the changes. Which requires more fine-grained listeners for changes for performance.
Is this other people’s experience?
Flutter says it does optimizations but everything seems to recommend against forcing a top-level UI rebuild using setState on the top widget.
What is true is that the greater the area rendered by a functional approach the more it will flicker. Hence to apply that kind of approach you need to be selective as to how much you render, hence these diffing approaches (react, lit...). That is not inherent to SAM. I have implemented SAM with vanilla.js and dividing the area in "sections" (3 sections: header, page, footer) and it looks just as good as React (of course not for arbitrary complex UIs). I am just trying to make the point that very simple approaches makes is possible.
Algebraic effects: you don't like my proposal? you get a second chance, try another one! https://overreacted.io/algebraic-effects-for-the-rest-of-us/
As you can imagine, I find this suggestion as ludicrous as it could be. Not surprisingly it comes from FP... (face palm). I much prefer a programming model where mutations are first class citizen and proposals are partially accepted or rejected which lead to clear next-actions that may be triggered to generate a new proposal. Sprinkling your code with random next actions and on the spot acceptors without a clear step is a recipe for disaster.
As you can imagine, I find this suggestion as ludicrous as it could be. Not surprisingly it comes from FP... (face palm). I much prefer a programming model where mutations are first class citizen and proposals are partially accepted or rejected which lead to clear next-actions that may be triggered to generate a new proposal. Sprinkling your code with random next actions and on the spot acceptors without a clear step is a recipe for disaster.