These are chat archives for jdubray/sam

13th
May 2016
Stardrive Engineering
@HighOnDrive
May 13 2016 03:56

Have you seen this new middleware courtesy of Netflix? Pretty sweet from a first read :sparkles:

https://medium.com/@benlesh/redux-observable-ec0b00d2eb52#.d2ru1ikmu

Roman NL
@rnique
May 13 2016 04:08
@jdubray would you consider an acceptable design for SAM where the state is fetched from different sources (like stateful connections, or BRMS like Drools), but managed by a single central class, per user?
Jean-Jacques Dubray
@jdubray
May 13 2016 14:19
@rnique just to be clear:
  • yes, "the application state" is per user though there might also be occasionally a more global application state on the server, but it is unlikely to be changed by user actions (I am not counting "architecture state" like statistics, that's irrelevant to the pattern)
  • anything "connection" is what I call "wiring" and should not interfere with the pattern's programming model
  • What SAM says is that you have to organize your business logic in three buckets (Proposers/Action, Acceptor(s)/Model, Learner(s)/State). Only acceptor(s) are allowed to mutate the application state
When the present method of the acceptor/model starts, you enter a "critical section" and the system, for that user, and only for that user, cannot process another action until the application state is known again.
The "Reactive" guys (Redux, Cycle, ELM) see that "critical section" as being implemented:
  • as a pure function of the application state (which is by definition duplicated)
  • they mutate the entire state for each action, they don't keep track of the "diff" of the application state before the Reducer is called and once the request to mutate the store (again 100% of the application state) is issued
Jean-Jacques Dubray
@jdubray
May 13 2016 14:27
In SAM APIs can be called both from an Action and the Model, without limitations. An action could take 5 days to get to the point where it presents its data to the model, as long as it makes sense to do so, SAM does not make any assumption about it, but you could run the risk that another action is triggered. Now, logically (and that's a fundamental departure from traditional state machine semantics) you could continue executing actions, as long as you are in the "State" of being able to accept values from the Action that took 5 days to execute, it should be able to present it.
So just to be clear, Actions are not allowed at any point to mutate the application state, they have an internal state, IMHO, they should not be able to even ask more details like model.getState().
In general you want the critical section to execute as fast as you can because logically you cannot present new data until it has completed. But again, it could take 5 days to accept some values.
To circle back on the discussion we had on architecture, let's say for the sake of argument some data may take 5 days to accept, you may want to design an architecture where a user can "view" the current state without having to trigger a rendering of the model. What I mean by that is that the "current" application is not available it is being mutated. So, architecturally, you may have to cache the "last view" or if it easier you may have to cache the latest known stable snapshot of the model.
Jean-Jacques Dubray
@jdubray
May 13 2016 14:33
So to answer your question, I would say, yet it is safe to call BRMS both in the actions (to propose values) or in the model (to accept values). The fact that the connection is persistent is an architecture detail, it just means that the action and the model need to be provided with that connection when required. That's outside the programming model
@HighOnDrive I am not quite sure why people are so fascinated by "wiring" over programming model.... Wiring is the least of the problems in any kind of architecture.
Jean-Jacques Dubray
@jdubray
May 13 2016 14:40
I hope that you recognize that the issue here is that none of the code that decides whether an action is allowed or not is derived from the application state. You have to be explicit about when you don't want an action to be dispatched. That is deeply and totally flawed.
Code like:
const startTicking = (actions, store) => 
  Observable.interval(1000)
    .map((i) => ({ type: 'TICK', i }))
    .takeUntil(actions.ofType('STOP_TICK'));
makes no sense at all, the truth and the matter is that the decision to present data to the model cannot be decided a priori, in isolation, from the original action's perspective.
That is a programming model that will lead to a massive spaghetti.
The observable approach is not better:
// later you can cancel the dispatched async action
sub.unsubscribe();
Can you imagine, in Redux once you started the course of an action, you have to keep track of all that could happen and kill it before it happens?
Don't you think it would be easier to control which action can be presented?
Jean-Jacques Dubray
@jdubray
May 13 2016 14:46
React/Redux will collapse, mark my work.
Roman NL
@rnique
May 13 2016 14:53
Oh great, and when I was reading about 5 day long actions, I thought that this design resembles somehow the way git works, where actions may branch and later send pull requests, to merge into master model, but if conflict occurs, most of the time humans (users) need to decide how to solve it. I see as difficult the task of automating action rejection in case of conflicts like run conditions.
Jean-Jacques Dubray
@jdubray
May 13 2016 15:00
Conceptually, it's a bit the same idea, but in theory the model is coded to be able accept changes, unlike git. The conflict is resolved differently because we know, for a given application state, which actions can present data to the model or not.
Roman NL
@rnique
May 13 2016 15:05
...we know, for a given application state, which actions can present data to the model or not.
That is the part difficult to understand for me, what if the data provided by allowed actions is conflicting?
Jean-Jacques Dubray
@jdubray
May 13 2016 15:08
If you use SAFE you can enforced the allowed actions for a given snapshot of the application state/model
Roman NL
@rnique
May 13 2016 15:08
Or in cases where we send functions as parameters
Jean-Jacques Dubray
@jdubray
May 13 2016 15:08
What happens is that in the State() function you can compute the allowed actions which can present data to the model
Roman NL
@rnique
May 13 2016 15:08
where application mutates itself?
Jean-Jacques Dubray
@jdubray
May 13 2016 15:08
You have nothing to "unsubscribe"
The model (acceptor) is where all the mutation is centralized
Roman NL
@rnique
May 13 2016 15:09
ah ok
Jean-Jacques Dubray
@jdubray
May 13 2016 15:09
Then there is a processing step after the mutation before another action is allowed to present data to the model
SAFE helps you to enforce that flow.
Again all this is per user
Sometimes the architecture is such that the view naturally allows only one action at a time (page flow)
so you don't have to worry, the State will update the allowed actions (or only the allowed actions will be displayed in the view)
But this is old UX
Roman NL
@rnique
May 13 2016 15:27
Thank you, I think I need to "reread" the SAFE implementation, I understand some parts of the paradigm, but still didn't have the "aha!" moment
Jean-Jacques Dubray
@jdubray
May 13 2016 15:31
Sure, let me know if you have any question. The State() functions computes the allowed actions for any given application state (just like a state machine, when you are in a state only X,Y,Z actions are allowed). SAFE keeps track of it and only allows these actions to present data to the model
SAFE even keeps track of the "step" if you want, you can have something I allow a new action X to present data, but not an old one.
It's really interesting semantics, you never have to think about subscribing and unsubscribing
Stardrive Engineering
@HighOnDrive
May 13 2016 17:06

@jdubray You said "I am not quite sure why people are so fascinated by "wiring" over programming model.... Wiring is the least of the problems in any kind of architecture."

Well, the right wiring makes things reactive and allows things to be scalable and also leads to wonderful concurrent architectures. Reactive wiring has an increased role in today's dynamic apps.

Then you said "If you use SAFE you can enforced the allowed actions for a given snapshot of the application state/model".

This can be done by anyone if they just think about what their app does. It's just that thinking about a "SAFE" flow for all the fun things in an app is not the most exciting thing to do. This is why so many embrace frameworks in the first place.

You also said "It's really interesting semantics, you never have to think about subscribing and unsubscribing".

Thought you liked the ability to cancel operations a while back?

Jean-Jacques Dubray
@jdubray
May 13 2016 17:09

leads to wonderful concurrent architectures

No it doesn't

Well, the right wiring makes things reactive

No it doesn't, define "reactive". Being reactive requires control over the critical section of the application state, Reactive does not mean something snaps here and I have some random code executed in response to it

This can be done by anyone if they just think about what their app does.

Yes, agreed, that would only require that you pay more attention to the programming model over the wiring

I am not recommending people to use SAFE, but SAFE illustrates well the possibilities of SAM's programming model

Thought you liked the ability to cancel operations a while back?

Yes, but in SAM/SAFE, this is a consequence of the programming model, the "reactive" wiring that you recommend using warps the programming model to the point that now you have to keep track of what could potentially happen and "unsubscribe" to it before it's too late... good luck with that

Jean-Jacques Dubray
@jdubray
May 13 2016 17:15
Again, what you call reactive works well when the critical section can be represented as a pure function. That is an approximation. I don't dispute that many problems can fit that constraints, but not Front-End architectures.
The proof and the mater is that as soon as you have to deal with "time" you break, perhaps that's a hint that there is something fundamentally flawed with that kind of wiring?
blob
See, that's the kind of code you recommend writing:
you recommend wiring an event to an effect with no "step/isolation" in between
That cannot work, that is the problem, there is nothing "beautiful" or even "concurrent" about this
That is the root of all problems since MVC and there is amount of observers or promises that will fix that.
Jean-Jacques Dubray
@jdubray
May 13 2016 17:21
What you are talking about is "wiring", get a programming model first, then find the best wiring. You'll see that you hardly need these cool shiny toys
I don't know if you ever traveled to Thailand, but across the entire country you see the "pattern", even in the most modern parts of Bangkok
Jean-Jacques Dubray
@jdubray
May 13 2016 17:29
blob
Each time I see an "observable" or a "promise" that picture pops in my mind. You just created a "wire" to a piece of code on the other side, and that makes no sense at all.
And that's my picture of a "reactive" developer
blob
Jean-Jacques Dubray
@jdubray
May 13 2016 17:37
blob
And before you know, you start using that "wonderful concurrent architecture" for something else...
what you see between the two red arrows is a wonderful example of "reuse" where all these beautiful wires can be repurposed for something completely different ... with true business value!!
we're good?
I have created a "sam-wiring" room so that we don't have to discuss that topic in this room.
https://gitter.im/jdubray/sam-wiring
Stardrive Engineering
@HighOnDrive
May 13 2016 17:47
I have nothing more to discuss right now, have productive work to do with ReactiveX (RxJS). These tools are the best thing to land in a long while and your contending with that fact. It is quite mindless of you to equate the pictures above with ReactiveX. In a vote on whats cool, you would lose big time.
Jean-Jacques Dubray
@jdubray
May 13 2016 17:47
I don't care to "win"
this is not a beauty pagent
Stardrive Engineering
@HighOnDrive
May 13 2016 17:59
"I don't care to "win"", right your just wasting the the time regurgitating over a fairly simple topic. For an added bonus you are not familiar with the technologies that actually make the world go round. This is definitely the place to go if you want or enjoy confusion.
Jean-Jacques Dubray
@jdubray
May 13 2016 18:00

you are not familiar with the technologies that actually make the world go round

I hope you appreciate the irony of your statement in the context of TLA+...

Look, there are massive emotional and financial interests behind all the cool shiny toys and I am not surprised that a lot of people will fight to the end to prevail, and drag anyone they can with them. Just look at the feedback you get on average from people who have tried to do something real with React/Redux/GraphQL. I don't think there is much else to add.
Stardrive Engineering
@HighOnDrive
May 13 2016 19:14
Yes, it was easy to see that coming, it's why I do not look to any of the options you mention. I've taken sweet time to checkout many options and came out with my own solution. At the end of the day I'm a happy camper without the need for any more regression and dogma :smile:
Jean-Jacques Dubray
@jdubray
May 13 2016 19:25
Sorry, I just realized that gitter strips out the timestamp at which you want to start watching the presentation, please watch the last 2 min of the talk
Jean-Jacques Dubray
@jdubray
May 13 2016 19:35
@HighOnDrive several people, including myself, have asked you to detail your programming model, but you keep throwing plain vanilla Reactive stuff at us. Please, if you want to have a serious discussion about it, give us some details, I am 100% open. If all you want is to add a bunch of noise, be it reactive or cyclic, we already heard it, it does not fly. As for me I am just a hacker.
Stardrive Engineering
@HighOnDrive
May 13 2016 20:29

Sorry if that was noise, just thought the link I posted was relevant. Thanks for the invite to discuss patterns, right now I'm quite busy with numerous aspects of my app and likely any discussion would end up in endless debate and suck away the time. At least for now I'm going to try to shutdown gitter and focus on work, then only open rooms if I can help it on weekends. I'm just so damn busy, time to take Zappa's advise and just shut up and play guitar :smile:

https://www.youtube.com/watch?v=G8EZpcRow-s

Fred Daoud
@foxdonut
May 13 2016 21:26
by the way, @jdubray
Sorry, I just realized that gitter strips out the timestamp at which you want to start watching the presentation, please watch the last 2 min of the talk
When you click on the video itself in gitter, it doesn't work; BUT, clicking on the link to open in a new window does work and preserves the time that you put in the link.
(I just say this so that you keep putting the time in the link, it is useful.)
Jean-Jacques Dubray
@jdubray
May 13 2016 21:31
yes, otherwise the presentation itself is almost unbearable.