These are chat archives for jdubray/sam
When you conflate proposal (the new values of the application state), the mutation and the state representation you create spaghetti code (not to forget NAP). That code is hard to debug and maintain. There is no reason it should be that way.
Why does this necessarily result in spaghetti code? I understand that the premise of SAM is "assignment is not mutation" and that it tries to solve this by containing mutation in a centralized place. But it is still not clear why it is such a sin to equate assignment and mutation.
In other words, Functions are good at creating proposals (an Action is a pure function)
Objects are good at encapsulating (application state), the Model is an Object, with a single method (closure ok)
Reactive programming is good at computing new values in reaction to changes in other values (dependencies between properties)
This is actually a great soundbite. I'm surprised I haven't seen this in any of your articles / online conversations yet. The model as an Object encapsulating application (!) state really resonates with me as I can relate it to 'classic' OOP. In this sense the chosen terms of State, Action, Model really prove to be a bit unintuitive to me, as I now think of the Model as the Application State (Object).
Could you remind me again where TLA+'s Control State (as opposed to Application State) fits into the SAM pattern?
Lambda calculus provides a theoretical framework for describing functions and their evaluation. Although it is a mathematical abstraction rather than a programming language, it forms the basis of almost all functional programming languages today. An equivalent theoretical formulation, combinatory logic, is commonly perceived as more abstract than lambda calculus and preceded it in invention. Combinatory logic and lambda calculus were both originally developed to achieve a clearer approach to the foundations of mathematics
update()essentially takes a mutation an an argument :)