Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    brucou
    @brucou
    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.
    Bruno, there is only one factoring to computing, it's called TLA+, everything else that was built prior to that is an approximation
    brucou
    @brucou
    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, 2232^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ć
    @sladiri
    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ć
    @sladiri
    Thank you for your response!
    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:
    https://github.com/jdubray/sam-samples/blob/master/vanilla-es6-boilerplate-project/html/components/menu.component.js
    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ć
    @sladiri
    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ć
    @sladiri
    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"

    @jdubray could you please confirm this, or write your definition down?

    in these 3 examples it referrs to 3 different things: business logic, code, and computing. for the first two i have an idea what they could mean, but how to you factor computing?
    Milan Simonovic
    @mbsimonovic
    technically speaking, @brucou was right, SAM is not TLA+; SAM is a pattern, TLA+ is a language for writing formal specifications. If they were they same, you could write PAXOS spec in SAM
    but the PAL analogy I found very useful and illuminating, perhaps it should even go before TLA+ gets mentioned in the docs
    Milan Simonovic
    @mbsimonovic
    regarding the "S, vm, A and nap being pure functions with respect to the model", i take that means what is commonly understood as being pure - output is solely defined by inputs, there're no (visible) side-effects