These are chat archives for jdubray/sam-examples

16th
Sep 2017
Jean-Jacques Dubray
@jdubray
Sep 16 2017 06:06
@ddavis914 I am not sure about what syntax library they use. "h.js" (hyperscript) is a popular library in that space but this looks different. It would be best to ask the question on the Inferno forum. (https://github.com/Matt-Esch/virtual-dom/blob/master/virtual-hyperscript/README.md)
Jean-Jacques Dubray
@jdubray
Sep 16 2017 06:11
the purpose of having an optional "present" argument is to allow for a functional composition of actions (not a logical composition, because logically actions cannot be composed). You can technically call action1(data,action2) the proposal of action1 will be presented to action2 which should add its own proposal which will then be presented to the model. This is not used in that example, but I try to use a consistent "wiring" of the pattern across all the examples.
In general actions will validate, enrich and transform an event into a proposal. In that example, the actions are very basic but in a real application that would be very common. IMHO, this is also a very good place to call APIs, and present the result to the model.
Dennis Davis
@ddavis914
Sep 16 2017 06:18
Thanks Jj.
Jean-Jacques Dubray
@jdubray
Sep 16 2017 06:19

btw i'm convinced this is THE way to manage the complexity of multiple actors attempting to modify the model - action - present - accept - model update - view update - very clean with a mathematical proof of correctness to boot - sweet.

I know that Feynman said "The first principle is that you must not fool yourself – and you are the easiest person to fool.", but after actively building large scales projects with the SAM pattern, I also believe the same thing. There is no increase in complexity of the lifespan of a project. You can always reason in simple and local terms, regardless of the size of the application. I wish I could articulate that better, and people would give it a try, and understand that the structure of their code is important and Dr. Lamport may have well found a universal structure.

It seems that the industry is not paying enough attention to that question: "how code should be factored", lots of people come up with a factoring (say MVC) but they are not really looking at connecting it to a formalism to make sure it's correct. One could see, for instance, how naive it is to use a pure function to manage state, even though Lambda-calculus is behind it.
Dennis Davis
@ddavis914
Sep 16 2017 08:36
The 'Industry', what can we say about that? Money. I was thinking versions of (enter your framework or library here) that break code = money - that is 'good' for the industry if bad for the customers. It seems that the industry can use tools that slice away the clutter as Mr. Crockford presented and I submit a JavaScript front and back achieves/promises. To this breakthrough, along comes the studied - correct - mathematically based programming pattern (STAR) (You were the first to introduce me to a pattern that has its roots in a mathematical proof - even if that proof needs a CS degree to comprehend - thank goodness for V = f(M)!! ). For that I am thankful - another thing I am thankful for is your review of the industry tool-set v. SAM - Thank you for sharing that wealth of knowledge. It is really important for non-cs degree - yet - folks to rest on something we can prove is correct! I had a prj that I would have used the SAM pattern to help reason about - and build a solution - (multiple warehouse forklift drivers loading a container - off the same model (bill of lading) - mid stream - meaning container half - full - bill of lading could change - prompting the a new model to be broadcast to the active BOL drivers and old model/new model comparison for off-loading) (drowning in state, actions, models and pipes).
Jean-Jacques Dubray
@jdubray
Sep 16 2017 21:23
thanks @ddavis914 There is certainly a revenu factor, but really there is a pure lack of "first principle" thinking. After all these years, we could admit that there are four irreducible concepts in Software Engineering: State, Type, Action, Relationship (STAR). Please note there are no "function" here. "Events' are not included in that list because an event is "an occurence of a state". These are the building blocks of any software. Yet we focus a lot of energy in the on the concept du jour (streams, resources, ...). STAR is timeless, as much as Matter, Light, Force and Energy are to physics.
TLA+ (the temporal logic of actions) provides an essential/fundamental/unbreakable relationship between Types, Actions and States (Relationships are orthogonal here). Compare that to functional programming which, in principle provides a much simpler (perhaps naive) relationship between "states":
Sj = fij( Si)
Jean-Jacques Dubray
@jdubray
Sep 16 2017 21:29
Sure, you can architect your software as a series of states and functions, but the relationship between them becomes conceptual, compare that to SAM (based on TLA+ semantics):
Sj = State( Model.present( A(Si) )).then( Model => NAP(Model))
Jean-Jacques Dubray
@jdubray
Sep 16 2017 21:35
This structure is a lot easier to reason about, because of the temporal foundation (unlike Si, fij which has no temporal semantics).
Your project, like so many, would gain a lot using STAR/SAM. Any business process involves a strong temporal component, that is poorly represented by any other formalism. That has been a very long quest, and I feel I finally cracked it.
Jean-Jacques Dubray
@jdubray
Sep 16 2017 21:41
What I mean by that is that I found a formalism that gives me the structure that I had been loocking for. I didn't do much, to be honest, just translated the incredible work of Dr. Lamport into something I can use every day.