These are chat archives for jdubray/sam

3rd
Mar 2016
Michael Terry
@formido
Mar 03 2016 01:11
@jdubray There's also confusion around 'model'
you call state model but we think of model as schema
state being the momentary values of an instantiation of that schema
Jean-Jacques Dubray
@jdubray
Mar 03 2016 01:17
well, that's truly what it is, it is all the property values and the rules to accept (and persist) these values. It's not "state" as in a json document.
It is the (static) model of your system at the current time.
The State object represent and owns the "Temporal" logic (what happens next)
Algorithms for instance would have nap() actions until the algorithm finds the solution
The factorial algorithm has the following TLA+ representation:
the next-action predicate will run until pc=done
Jean-Jacques Dubray
@jdubray
Mar 03 2016 01:22
compare that to redux where the reducer is separate from state and store
Michael Terry
@formido
Mar 03 2016 01:23
This is all high level though
in a real system, your range of values that equals a state
your program will flow through that range
and it has to be managed by real code
so the distinction between schema and an instantiation of that schema that we call 'state' is useful
Michael Terry
@formido
Mar 03 2016 01:31
perhaps that's fine, humans are good at context switching
but it makes it tricky to on board people
you need a big yellow sign saying, this is not the state and model you're thinking of
gotta go for now
Jean-Jacques Dubray
@jdubray
Mar 03 2016 01:55
If you have a better combination of words, let me know. In Redux it is: Intent(not Action) - Reducer/State - Store

so the distinction between schema and an instantiation of that schema that we call 'state' is useful

I am not an OO guy, I don't believe in classes / schemas (anymore). Actually that was the argument I had with the inventor of the MVC pattern at OOPSLA, I was presenting a paper called "extensible object models"

and Prof. Reenskaug (http://jeffsutherland.org/oopsla99/) had some big issue with it.
Jean-Jacques Dubray
@jdubray
Mar 03 2016 02:02
His paper was right there on 4 layer business object structure
Jean-Jacques Dubray
@jdubray
Mar 03 2016 02:40
I have added the the warning in that section: http://sam.js.org/#bl
Milan Simonovic
@mbsimonovic
Mar 03 2016 09:09
few typos: how does sam WORK (not works); Praxos -> Paxos
Milan Simonovic
@mbsimonovic
Mar 03 2016 09:28
ok, i see, you call model property values: "the application state", so it is some kind of a state, and further down: 'The State may compute actually an actual "control state" ', so we have
  1. application state
  2. State
  3. control state
Milan Simonovic
@mbsimonovic
Mar 03 2016 09:53
typo: "Reducers are pure fonctions" -> "Reducers are pure functions"
Milan Simonovic
@mbsimonovic
Mar 03 2016 10:06
ah, here's the confusing part (from infoq article): "Incidentally, and unintuitively, the state object does not hold any “state”, it is again a pure function which renders the view and computes the next-action predicate, both from the model property values."
so it's called state but it's stateless :)
Jean-Jacques Dubray
@jdubray
Mar 03 2016 11:22

thank you. all corrected.

it's called state but it's stateless

:-D

Gunar Gessner
@gunar
Mar 03 2016 12:48
I agree that can be quite confusing for newcomers.
I personally like Model (Business Logic Container), Store (storage inside the model) and State (as in SAM)
Gunar Gessner
@gunar
Mar 03 2016 12:54
It's not interesting to have to calculateS(M) for every view. That's why I "cache" it in a variable inside the model.
So effectively, it is S = f(M) and then I pass this State forward. Is that "okay"?
Jean-Jacques Dubray
@jdubray
Mar 03 2016 12:54
The irony, and this is true, is that I find it confusing the other way around, when people tell me they have the state of the system, I feel they just have values, they have no knowledge of the "state" (started/stopped...)
In the end SAM is just a pattern. I know that its reactive/functional nature makes it implementable as is, but I would prefer people do what makes sense rather than follow the SAM expression literally.
I don't dispute the fact that sometimes it's easier for the Model to know the control state and pass it forward.
Jean-Jacques Dubray
@jdubray
Mar 03 2016 12:59
What's important though is for the State to remain stateless :-)
(not a joke)
Gunar Gessner
@gunar
Mar 03 2016 13:02
yes! a single source of truth: the model.
Jean-Jacques Dubray
@jdubray
Mar 03 2016 13:31
+1
Milan Simonovic
@mbsimonovic
Mar 03 2016 21:37

Dan Abramov talks about how and why he wrote redux: https://devchat.tv/js-jabber/179-jsj-redux-and-react-with-dan-abramov
high points:

  • wanted to go to paris, needed something to submit a talk proposal, decided to go with hot reloading with time travel;
  • so he proposed first and when they accepted he realised something had to be done (TDD: talk-driven-development), and had about a month
  • the idea was to create a flux-like framework, and to implement actions/events as objects which can be saved and replayed
  • sounds like he had make the store(s) stateless, so the reload/replay wouldn't mess it up?
  • only later found out it's just like the elm architecture
  • reducers should be stateless (pure functions); actions fire them, bring data, they compute new data (hm sounds like in SAM?)
  • there are so many better things out there but he feels like he's stuck with redux, coz its popular..

so sounds like a quick hack that turned out to be popular, and by chance (and/or brilliance) he did more than one thing right, and at the time guess he was just out of college, so not that experienced. but can't tell whether he's just humble or never really did some major research before settling down with the final design.

Jean-Jacques Dubray
@jdubray
Mar 03 2016 21:44

Yes. he is a bright kid no question about it. From what I have seen he tried to fix flux, so redux was designed as a better flux, he didn't start from scratch. You can't hack that space, you have to be a lot more deliberate in your analysis. TLA+ took 20 years to mature.

I do believe that React is brilliant, but they are reaching a point of insanity, who in their right mind would start building something on top of React.js+React.native+JSX+ Flux/Redux + Thunks + Saga + GraphQL + Relay? This is not engineering.

Brian Haak
@avesus
Mar 03 2016 22:34
What do you think about Cycle.js? By which ways it is bad, by your opinion? I think it is even better than Elm...
Jean-Jacques Dubray
@jdubray
Mar 03 2016 22:45
I actually like cycle.js, the example that was provided by Fred looks very promising. We certainly share the goals of separating the business logic from the effects, but IMHO, Cycle.js would benefit from SAM factoring of the business logic. At the moment, it's relying too much on the source/dataflow/sink model. There is nothing inherently good about streams in a Front-End architecture. As we have seen processing a new event/action from the stream would depend on the current (control) state. You can't just arbitrarily process events.