These are chat archives for jdubray/sam

Jul 2017
Janne Siera
Jul 27 2017 07:45
It's spaghetti in the sense that proposal, mutation and state representation are not clearly delineated
That's your solution, not your problem. You try to contain mutations in one centralized place, ok, understood. But why is it such a problem to not do this, people have written very good code without doing this - - in other words code that is not spaghetti.
Janne Siera
Jul 27 2017 07:50
Don't get me wrong, intuitively I think you're on to something. But without years of wildely used industry experience with SAM I'll need a little bit more than intuition to sell it to myself. Let alone my team.
I am trying to understand the missing link that I'm not seeing right now.
Jean-Jacques Dubray
Jul 27 2017 11:11
@jannesiera I am happy to answer any question if I can, even the inconvenient ones!
why is it such a problem to not do this
The problem though is when you are working in a larger team and across time (when people leave/join the team or when you are working on the code you wrote 6 months ago), the question innevitably becomes (even when the code is really good), what does this code do?
SAM provides a simple, easy to reason, yet extremely precise answer to "where this code goes". API calls? no problem, validation, mutation, next-action? There is no "it depends" answer.
Jean-Jacques Dubray
Jul 27 2017 11:18
Without that delineation, you start seeing interferences: you are not done computing the proposal, yet you started the mutation, now you see something missing, so you add it near the mutation, and if it was a validation rule, it gets burried/lost in parts of the code where it should not be.
Without SAM you also get a lot of "reactive" bugs when you start computing the state representation while you are still mutating the state. And I am not even talking about the next actions that would otherwise be added directly to the view.
How hard is SAM to adopt? not hard at all, it's a very simple discipline, no library.
SAM makes no assumption on the wiring and the architecture, it's just a programming model.
Each time you have an event handler you can decompose it with SAM, you don't even have to go to a single-state-tree, I like SSTs better, but that's just a preference. It's really about factoring even handlers and there is nothing that says you must use a SST.
Jean-Jacques Dubray
Jul 27 2017 11:25
Perhaps the most important aspect of SAM is reuse. Reuse is a touchy subject because it often creates unwanted/hard to deal with dependencies. SAM's building blocks are reusable more easily.
  • a new even can trigger the same action
  • a new action can trigger the same acceptor(s)
  • the same model can work with different state function
the granularity of reuse minimizes dependencies
Recently I had made the mistake of not using the state function properly and moved the computation of the state representation to the view. As new requirements piled in, I found myself duplicating lots of code, until there was no other solution than moving all that code in the state function such that I could reuse the code and populate different view components with the results of the same computation on different data.
Jean-Jacques Dubray
Jul 27 2017 11:30
A good developer probably would have not started the route I took (based on how simple the requirements were initially), but SAM seems to always push you in a direction you won't regret.
And all that without a single library to rely on.
Jul 27 2017 13:20
I would expect that it's not a big problem that you started with the computation in the view. If you have SAM in place, you can move it to the state representation the moment you start noticing that you're duplicating code.
Maybe the problem was that you waited too long to move it to the state representation, no? :)
Jean-Jacques Dubray
Jul 27 2017 13:57
yes, I just thought that the additional requirements would stop coming, until it was too late
Jean-Jacques Dubray
Jul 27 2017 14:09
@antanas-arvasevicius I tried to read this article about ASM, but I just can't parse the math. The author does talk about a next-state function, but it seems to be just a different way to express a graph of actions and states (not involving a type/model where the mutations occur). If you have an article that's a bit more accessible happy to take a look.
Antanas A.
Jul 27 2017 19:38
What I found that +CAL can be used also for ASM verification:
Curiously, how exactly ASM is related to TLA+
is it derivative one from another