## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
brucou
@brucou
This factoring is "unique", you just can't make it up (IMHO)
You can define formalisms on top of it, but you cannot decide arbitrarily what the foundation is, it is foundational.
Computer science is not based on opinion.
As I mentioned before, there is not only one factoring to computing, and that is just as known as the fact that the earth is round.
maybe you have to do a little bit more research.
you can't throw up any formalism in the air and say that one works too,
That's exactly what you are doing with SAM
My point is that TLA+ is a formalism which can be used to describe any state machine as we know it, therefore I claim it is foundational.
brucou
@brucou
Bruno, there is only one factoring to computing, it's called TLA+, everything else that was built prior to that is an approximation
Except that there is a very, very fundamental difference here
SAM state machines are not of the kind (S1,A,S2)
If that was the case, you would be correct
As I mentioned the structure of (S1,A,S2) is an approximation
An approximation to what? of what? What does that even mean?
brucou
@brucou
Every program written with a turing-complete language can be written in another turing-complete language including the turing original machine itself . That is all turing-complete languages allow to write the same programs.
So writing a program as a sequence of commands is not an approximation (whatever you meant by that), it is just as valid as any other way.
It is about semantics, 1/1 and 16-15, $2^2 - 3$ are different expressions, but they denote the same number. You can't say one expression is an approximation and the other one is the real thing.
brucou
@brucou
Back to state machines, the notation you use to describe them does not change their semantics, so (S1, A, S2) and the other one you wrote (I think it was (S1, A1, ..., NAP or something) are syntactic constructions. The behaviour of the state machines or its semantics is entirely decided based on the tuple which defines it (set of input symbols, set of output symbols, set of states, etc.)
You have the tendency to present things which are just your unsubstantiated vision of things as being science backed by important theoretical construction, but I had a close look and I did not get to that conclusion.
brucou
@brucou
Last thing, even if all of the previously quoted statements were all true, TLA+ is irrelevant to SAM. There is no need to go read any mathematical papers on anything. To determine a judgement on some properties of a theory/architecture, you need clear semantics which I haven't seen here. On the contrary, I see mathematics formulas where the functions are not really functions.
The SAM pattern can be described as a Mathematical expression (formula):
V = S( vm(M.present(A(data))), nap(Model) )
and then later
However, that expression is only a logical expression that describes the sequence in which the elements of the pattern are invoked.
We have pure functions, but... wait,
Where S(), vm(), A() and nap() are pure functions with respect to the model.
That has me wondering what would be an impure function with respect to the model. Actually that had me wondering what the hell is a pure function, and how that can be with respect to anything.
brucou
@brucou
I could go on for a long time but I lack the interest to do so.
Jean-Jacques Dubray
@jdubray

Thank you for your insights. This has been the starting point of SAM

Much of computer science is about state machines. This is as obvious a
remark as saying that much of physics is about equations.
State machines provide a framework for much of computer science. They
can be described and manipulated with ordinary, everyday mathematics—
that is, with sets, functions, and simple logic. State machines therefore
provide a uniform way to describe computation with simple mathematics.

To describe a program as a state machine, we must decide what constitutes
a step. How many steps are performed in executing the statement
f = i ∗ f of the programs in Figure 1? Does a single step change the value
of f to the product of the current values of i and f ? Are the evaluation of
i ∗ f and the assignment to f two steps? Are there three steps—the reading
of i, the reading of f , and the assignment to f ?

That has been exactly the path I took when designing SAM, what are "steps" involved in processing an event and rendering the effects, with the understanding that you cannot ignore the semantics of the State Machine behind, actually, I would argue that any formalism that is derived without consideration of the underlying state machine is most likely flawed.

As Dr. Lamport states (pun intended):

The obsession with language is a strong obstacle to any attempt at unifying
different parts of computer science. When one thinks only in terms
of language, linguistic differences obscure fundamental similarities. Simple
ideas can become complicated when they must be expressed in a particular
language. A recurring theme is the difficulty that arises when necessary
concepts cannot be introduced either because the language has no way of
expressing them or because they are considered to be politically incorrect.

Jean-Jacques Dubray
@jdubray
Of course we must then first agree on the definition of a state machine... that's why I clearly stated the definition I used.
Slađan Ristić
Hi, I am reading the "no-more-mvc-frameworks" article and Jean posted an example about an "increment" action and a model. I am trying to map this to CQRS, (but I am unsure if it even makes sense). Since the model checks the validity of the data, the action is not even a command in the CQRS sense but a mapping of user input?
So if you used CQRS for this system, the model would would split its mutation in two steps:
1. validate data + apply "increment" command
2. mutate + generate "incremented" event
Jean-Jacques Dubray
@jdubray
Hi, there is a reasonable alignment with Event Sourcing, it may even well be a missing link in the CQRS architecture. SAM decouples the invocation of back-end APIs from the view, therefore, there is no need/urge to map the view events to the commands. It may be more logical to map the action proposals to commands. You could as you mention in option two pick the event in the model, but I believe the proposal is more natural.
@sladiri I would argue that we have been missing that clear distinction between model and everything else (CQRS being completely on the model side) and SAM (via TLA+ semantics) provide a much clearer isolation of the model business logic. All other approaches tend to mix action and state code with the model.
Slađan Ristić
Marcus Feitoza
@mfeitoza
Hey guys I have one question in the above code:
const model = {}

// cat name space
model.Cat = {}
model.Cat.list = []

// dog
model.Dog = {}
model.Dog.list = []

model.present = (data) => {
// only one present for both Cat and Dog
}
///
// OR I can have present for Cat and Dog?
///
model.Cat.present = (data) => {
}
model.Dog.present = (data) => {
}
Jean-Jacques Dubray
@jdubray
There is no general rule, it's really about the "protocol" and the roles and responsibilities of Actions, Model and State. There is no problem modularizing the model as needed as long as Actions "present" proposals to the model and these proposals are serialized, unless you know what you are doing (there could still be parts of the model that could be updated concurrently, but IMHO, that's not a good thing.
Marcus Feitoza
@mfeitoza
Thank you again JJ.
Jean-Jacques Dubray
@jdubray
@mfeitoza What I meant by protocol was calling Actions->Model->State->View/Next Action in sequence. As long as you follow that "protocol" then everything should be fine.
Marcus Feitoza
@mfeitoza
Fine, thank you.
In this week I will develop little more complex app to dive into SAM
Jean-Jacques Dubray
@jdubray
great! thank you for your interest.
Marcus Feitoza
@mfeitoza

Modularizing the model is not clear for me, when you say

There is no problem modularizing the model as needed as long as Actions "present" proposals to the model and these proposals are serialized

because in SAM site says:

The model contains all the application state and (logically) exposes a single method: present(data)

I could do this?

const model = {}
model.present = (data) => {}

// I could do, instead of having if's in present?
model.presentNewtItem = (data) => {}
model.presentEditItem = (data) => {}

action.addNewItem = (data, present) => {
present = present || model.presentNewItem;
// all actions need
present(data)
}
Jean-Jacques Dubray
@jdubray
You could, but personally I prefer a data interface to the model. It is important to decouple the actions from the model. The general idea behind TLA+ is that the actions propose the property values the model should take (imagine like a SQL UPDATE statement). Then the model decides if it's possible or not (accept or not, partially accept...). This decoupling is very important but not always possible to achieve. Sometimes the action needs to give a hint like when you need to perform an additive operation, you have to pass a proposal {incrementBy:1} since the action doesn't know the current value. The protocol forbids the action to query the model.
Jean-Jacques Dubray
@jdubray
You can modularize the model by mounting some methods that will be called within present() Here is an example:
For each component registered with the model, we iterate to call the update method(s):
https://github.com/jdubray/sam-samples/blob/master/vanilla-es6-boilerplate-project/html/sam/model.js
Marcus Feitoza
@mfeitoza
Thanks again JJ, I will learn about TLA+.
Slađan Ristić
It seems that the model could use the state function to tell if some particular action data is valid to accept, doesn't it? I never saw an example doing this. The state function could have its second value as as hint for a user, which they might ignore.
Jean-Jacques Dubray
@jdubray
sorry, I am not sure I understand your question. The model is solely responsible for mutating the application state.
Slađan Ristić
No problem, I now saw the answer in one of your examples.
I asked if the model can use the control state to decide how it mutates itself.
Jean-Jacques Dubray
@jdubray
I would say in general no, again, that's the idea of separation of concern, it's better to make the control state evaluation redundant in that case. What I prefer doing is preventing the action to present its value based on the control state. When you look at SAFE, the state function returns the list of actions allowed in the current control state such that the model does not have to worry about that. The model assumes the action is allowed and simply makes the decision to accept or reject (or partially accept) the proposal.
Milan Simonovic
@mbsimonovic
the discussion with @brucou seemed very important, too bad it ended on a bad note without reaching an understanding.

One thing that comes up frequently is this concept called factoring, and sounds like it refers to code structure. Here're some examples:

• "SAM recommends factoring the business logic underlying a graphical user interface along three building blocks: actions, model and state"
• "The question is what is the proper factoring of code, you are not free to decide that, there are constrains."
• "Bruno, there is only one factoring to computing, it's called TLA+, everything else that was built prior to that is an approximation"