These are chat archives for jdubray/sam

5th
Jun 2016
Jean-Jacques Dubray
@jdubray
Jun 05 2016 01:07
Anyone played with hyperdev yet? https://hyperdev.com
Michael Terry
@formido
Jun 05 2016 01:45
what do you prefer about inferno vs react?
Jean-Jacques Dubray
@jdubray
Jun 05 2016 03:28
I like the "blueprint" concept over black-box vdom solutions
Jean-Jacques Dubray
@jdubray
Jun 05 2016 03:45
The animate example is pretty eloquent
Jean-Jacques Dubray
@jdubray
Jun 05 2016 08:27
Here is an inferno-based SAM implementation with blueprint
Jean-Jacques Dubray
@jdubray
Jun 05 2016 13:20
blob
Another great example of proper state management
Jean-Jacques Dubray
@jdubray
Jun 05 2016 14:07
The fundamentally flawed view of Actions at Facebook:
blob
Do they drive cars or drink water out of glasses?
Who decides whether a glass is empty? the action or the glass?
Structural sharing, another Facebook library that solves imaginary problems
blob
Jean-Jacques Dubray
@jdubray
Jun 05 2016 14:17
If you are not convinced, watch the memoization section
blob
It took exactly the same time to recompute the new array, as if there was no optimization.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 14:29
The concept of optimistic state is awesome, Facebook machine learning algorithms are so smart they can predict what the response from a server is going to be
blob
They can even chain "optimistic results" (specially when it comes to querying the server a second time with the results of the first query).
React's "new" immutable architecture (aka nirvana)
Jean-Jacques Dubray
@jdubray
Jun 05 2016 14:35
blob
Fred Daoud
@foxdonut
Jun 05 2016 14:57
@jdubray I cannot tell when you are being sarcastic and when you are not :smile:
Jean-Jacques Dubray
@jdubray
Jun 05 2016 14:58
:-D
Jean-Jacques Dubray
@jdubray
Jun 05 2016 15:04
As you can guess, after watching that presentation (from the author of immutable.js), I am even less in favor of immutability of the model.
Fred Daoud
@foxdonut
Jun 05 2016 16:15
@jdubray hehe, for sure :) With Meiosis I am not imposing either, it's perfectly fine to mutate the model. The receiveUpdate function acts as model.present when using Meiosis to implement SAM.
As for views, it's designed for you to use whatever you like, it would be very easy to plug Inferno into Meiosis.
devin ivy
@devinivy
Jun 05 2016 19:43
@foxdonut is nextUpdate like nap?
Fred Daoud
@foxdonut
Jun 05 2016 20:16
@devinivy that is correct :thumbsup:
@devinivy : I wrote this section in hopes to make the Meiosis/SAM parallels: https://foxdonut.gitbooks.io/meiosis-guide/content/sam.html
Fred Daoud
@foxdonut
Jun 05 2016 20:29
@jdubray have you seen snabbdom? You might like it: http://codepen.io/foxdonut/pen/rLVRPR?editors=1010
Jean-Jacques Dubray
@jdubray
Jun 05 2016 22:28
Yes, I have seen snabbdom, it's alright, what I like about Inferno is that it supports JSX as well.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 22:41

@foxdonut I am not sure I understand what you are trying to do with Meiosis. It looks a lot like SAM but with a different terminology. Messing up the concept of action with something called "Update" is not helpful. As I said back in February, we are not free to reinvent these concepts, even when you are wearing a bowtie. Programming languages don't have the concepts of Actions and Steps and you need to bring that kind of structure to the programming model.

I like this:

var Meiosis = meiosis.init(meiosisSnabbdom.renderer.intoId("app"));

var createComponent = Meiosis.createComponent;

var Main = createComponent({
  initialModel: initialModel,
  view: view,
  actions: actions,
  receiveUpdate: receiveUpdate,
  nextUpdate: nextUpdate
});

var renderRoot = Meiosis.run(Main);

meiosisTracer(createComponent, renderRoot, "#tracer");

That's very clean. I don't even mind you rename "present" as "receiveUpdate", but by calling nextUpdate you are damaging the semantics of the pattern. You don't know if an action will result in an update. Logically what's happening is, you are triggering the "next action" not the next update. That action may even "update" a different model altogether (Parent/Child)

When you reach a (control) state, the next thing to do is to check if there are automatic actions.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 22:48
Incidentally, you also removed the concept of "State" vs "Model". I had not caught that in the sample code since you are using state. Again, the whole point of the pattern is to fully decouple the view from the business logic (SAM). I feel there is a lot of value in doing so and you are breaking that concept as well. So overall, I don't feel too happy about it. You have in effect eliminated the concept of "State" (and next-action), which I had tried very hard to bring in the programming model.
State Machines are the solution to Front-End architectures, not Functional programming.
In essence you have have created an MVU pattern (U for update)
Fred Daoud
@foxdonut
Jun 05 2016 23:02
@jdubray I'm catching up...
Yes, I have seen snabbdom, it's alright, what I like about Inferno is that it supports JSX as well.
fwiw snabbdom also supports jsx: https://www.npmjs.com/package/snabbdom-jsx
Messing up the concept of action with something called "Update" is not helpful.
Well, naming is hard, I agree. I could have called it an "action". My only problem with "action" is that it implies that it "does" something. But, and this is one of the ideas in SAM that I really like, model.present decides whether to accept or refuse what the action is presenting. So to me sendUpdate was clearer in my head that the action is actually sending something which may or may not result in a change.
by calling nextUpdate you are damaging the semantics of the pattern.
I am not clear on what this means. nextUpdate is the same is nap(), that is, to decide whether to trigger another action/update based on the current state.
Incidentally, you also removed the concept of "State" vs "Model".
Not at all. As you said, I am using state in the sample code. It is still there.
So overall, I don't feel too happy about it.
Fred Daoud
@foxdonut
Jun 05 2016 23:07
I understand. But please know that I did not break or eliminate as much as you may have perceived, all the pieces of SAM are there.
@jdubray thank you for your feedback, I appreciate it! I hope we can continue the discussion.
As I said earlier, naming is hard, and I am just beginning with Meiosis. I need to finish some docs and then I will release a first version in hopes on getting some feedback, then decide on whether any name changes are in order.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:19
I would prefer seing something like this:
var Main = createComponent({
  initialModel: initialModel,
  view: view,
  state:state,
  actions: actions,
  receiveUpdate: receiveUpdate,
  nextAction: nexAction
});
where state is explicit. As I mentioned, I don't mind if we say actions "update" the model. I prefer something "softer" like present, but that's just a preference, there is no difference.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:24
From my experience, you need to provide a minimal structure for developers to do the right thing, otherwise everyone will land the pieces in difference places. State is possibly the most unfamiliar concept of the pattern, but I would argue that it is because it is not there that bugs tend to accumulate in "handlers". We are all building state machines (which are very hard to reason about) without the minimal structure of a state machine. An intuitively, that was the first thing you removed. You felt, I don't need that.
Fred Daoud
@foxdonut
Jun 05 2016 23:30
Very good point. I will think about it some more and see if I can rework the flow so that the state fits in more explicitly.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:30
When I discovered TLA+ and connected the dots back a year ago, http://www.ebpml.org/blog15/2015/06/sam-the-state-action-model-pattern/, I felt wow, it all fits, I just could not believe such simple semantics could be so powerful. I am actually surprised/appalled to see presentations like the one of Lee Byron. "Functions" are not first level semantics. State/Actions are. Then, the genius behind TLA+ is that you split the State into "State" and "Model" (or Type/Class). Then you realize that "View" is something else, that's why "SAM" is not called "SAMV". SAM is truly a pattern, a way to factor your business logic that brings tons of benefits. Unlike "Functions" functions don't really help you structure your business logic other than bringing a composition mechanism. It's does not even provide a proper encapsulation mechanism, because the first thing you need to do is to wrestle that "immutability".
I can speak of SAM as not being "mine" since it is all coming from TLA+, at a maximum it is my interpretation of TLA+. I am happy if people find a better one. By no means I would suggest that I found "The" interpretation.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:40

Here is the fundamental problem of ignoring State:

programming languages were designed to work on a conceptual view of “state” which we can refer as an “assignment of variables”, which in turn gave the super power to any program to potentially (CRUD) change the assignment of any variable at any step

That is the problem, when you hear most of React, Cycle, Elm presentations, there is no notion of "step" and everything is possible at any time. We know that's not true. We all know that, and yet we ignore it. Not sure why. Actually, I do.
You need a place to gather the "State" logic, if you remove it, it will sprawl everywhere, and that's not good.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:45

Functional programming said, ok that's bad:

gave the super power to any program to potentially (CRUD) change the assignment of any variable at any step

so they took that super power away, then had to give it back a bit since at some point you do need to change the assignment of variables... but then they had no structured way to do so.

State Machines (Petri Nets) never appeared to be a solution because, well their semantics were incomplete. That's what TLA+ is changing. That's why I am disappointed that you dropped State!
But again I know why.
devin ivy
@devinivy
Jun 05 2016 23:53
@jdubray this actually reminds me of a common problem in react. it's confusing to explain in this case, as it was a problem with the "state" of a component affecting whether you can call setState(). but basically, you'd see people checking to see if they were allowed to call setState() everywhere setState() appeared!
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:54
of course, there is no other way. That's why I don't like the React programming model at all
They in essence started with the view and went backwards, sprinkling stuff right and left. Their programming model makes no sense at all.
When you watch the Lee Byron presentation, it's insane. The guy write immutable.js and all the sudden everything becomes immutable.
devin ivy
@devinivy
Jun 05 2016 23:56
it seems like the whole reason for that is the view layer, really.
the virtual dom needs an easy way to diff.
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:56
It's also why I prefer to use "state" for what I call "State" and "Model/Type" for what people call "State".
Yes, I totally agree with you
devin ivy
@devinivy
Jun 05 2016 23:56
immutable provides that, at the cost of some complexity. clearly these things aren't immutable to help deal with multi-threading, etc...
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:56
that's why I dissociate myself from Diff algorithms
Yes we agree, immutability will kill you.
devin ivy
@devinivy
Jun 05 2016 23:57
i see its value in other environments
Jean-Jacques Dubray
@jdubray
Jun 05 2016 23:57
The overall problem is even ordering
you need to reason very precisely as to what to do with an event
It is very rare that an event can do something without checking whether that is possible or not
that's what we lost/lose when we hide "State"
I know it's a bit annoying, but the reality is that the alternative of sprawling (control) state everywhere is worse
Need to jump on a call.
devin ivy
@devinivy
Jun 05 2016 23:59
:thumbsup: