These are chat archives for jdubray/sam

5th
Nov 2016
Edward Mulraney
@edmulraney
Nov 05 2016 09:20
i'm trying to refine some SAM concepts. is there an issue with model data being isolated to a single property on the model, i.e. model.data,.* rather than model.*? the reason i'd want to do this is for safety and clarity
Edward Mulraney
@edmulraney
Nov 05 2016 09:45
also, can i have clarification on this flow:
-> onclick is an event (term=event) -> transform event data into an intent (term=intent) -> present an intention (term=action) -> model accept/reject the intention -> execute unit-of-work/mutation -> recalc model.data + state (term=app state) -> notify listeners (eg. render) -> next actions (nap) ->
if that's correct, where does the term proposal fit in? can you replace intent with proposal and if so, does that confirm that a proposal is simply a formulaton of an intent
e.g. canvas.onclick=drawRectangle
Edward Mulraney
@edmulraney
Nov 05 2016 09:51
drawRectangle is an intention, which transforms mouseposition into a proposal: {type:"DRAW_RECTANGLE", payload: {x1, x2, y1, y2} and at the time when present() is called on this proposal, it becomes an action?
so in a modular/wired system, you may have 0 hand-coded actions because present() would be called behind the scenes (via wiring) on your intents?
Edward Mulraney
@edmulraney
Nov 05 2016 10:40
in SAM, is it correct to say an action should never cause a side-effect/async ? i.e. async in the mutation/unit-of-work
Edward Mulraney
@edmulraney
Nov 05 2016 11:52
what defines the start of a new step?
is it a new present? if so, that means actions can contain multiple steps
Edward Mulraney
@edmulraney
Nov 05 2016 12:55
there's a comment on sam.js.org that says this:
// Actions are pure functions /////////////////////////////////////////////
that must be out of date
Slađan Ristić
@sladiri
Nov 05 2016 14:54
@edmulraney I think that actions are pure "just" regarding the model.
Jean-Jacques Dubray
@jdubray
Nov 05 2016 15:08
@edmulraney model.data.* is much better, I missed it originally due to my lack of knowledge of JavaScript
Jean-Jacques Dubray
@jdubray
Nov 05 2016 15:19
The flow is correct, intents are somewhat optional and conceptual, just a way to decouple the component from the actions. I would replace recalc model.data + state with recalc state from model
Edward Mulraney
@edmulraney
Nov 05 2016 15:20
@sladiry - actions are not pure - they can contain any IO/async/side-effect
Jean-Jacques Dubray
@jdubray
Nov 05 2016 15:28

it correct to say an action should never cause a side-effect/async

no it is not, it is only with respect to the model. So yes, in the functional sense actions are not pure functions but they are pure with respect to the model, they do not access or mutate the model.

Edward Mulraney
@edmulraney
Nov 05 2016 15:31
ah right i see thanks for clarifying
Jean-Jacques Dubray
@jdubray
Nov 05 2016 15:32
In theory you cannot start a new present method until the state function has completed. The whole point of the pattern is to make sure that the new "state" (not as in model) is computed to decided whether an action can be triggered.
In SAM the definition of action is that it is a function that translates an event/intent into a proposal to the model. In the case of "DRAW_RECTANGLE" it really depends on the nature of the even, is it a mouseMoved event? in which case you just have the new coordinates of the mouse, the action would not know about x1,x2.
When computing the proposal, the action should not access the model, nor attempt to assign property values to the model.
Jean-Jacques Dubray
@jdubray
Nov 05 2016 15:38

so in a modular/wired system, you may have 0 hand-coded actions because present() would be called behind the scenes (via wiring) on your intents?

I would say that's more an exception than the norm. Actions validate/authorize and enrich intents. The model validates the mutation (proposal).

Jean-Jacques Dubray
@jdubray
Nov 05 2016 15:43
I don't have a good way to express "actions are pure with respect to the model". In the end, there are state that you care about and state that you don't. SAM allows you to manipulate the state you care about in the model. If an action is "stateful", in the sense that it has side effects, that's not important as long as it has no impact of the model property values. That's the discussion we had earlier with @schtauffen , an action can present twice, if it makes sense. That's not a strict violation of the pattern.
Jean-Jacques Dubray
@jdubray
Nov 05 2016 15:50
Don't you think that Elm/Redux have a very odd way to handle application state mutation? Don't you have to start with the concept of a "step"? Why would you think that any arbitrary assignment of a property value would put the application state in a consistent state? That is ludicrous. You cannot write programs where that is true.
So what are you options? you let the developer decide arbitrarily what a step is (say by putting a function wrapper around some code)? or you start with a step structure and you define rules to write your code within that structure?
Stated like this, I am not sure why people would think functional programming to be something other than a curious construction of the mind, an oddity. I know that there is something elegant about it, almost fascinating, but when you look at the problem at face value, achieve consistent application state, is that the best way to solve that problem? I'd argue it's not.
Jean-Jacques Dubray
@jdubray
Nov 05 2016 15:56
And please let's not bring the argument like "my code is easier to test". First, since when software engineering defines its programming models with this as the primary constraint? Second, unit testing is nearly pointless, as one could have 100% code coverage and less than 1% path coverage. It is path coverage that is important, not code coverage.
Rick Medina
@rickmed
Nov 05 2016 18:01
so the main argument is that the state transition (whether it is mutable or immutable) must be centralized to guarantee state consistency across the system?
@jdubray
Slađan Ristić
@sladiri
Nov 05 2016 18:58
This is just anecdotical and my gut feeling:
I liked how Alan Kay showed in his presentation "Power of simplicity" how the absolutely simplest models often do not accommodate real world complexities. His example was how the "slightly" more complex ellipse gave a much simpler overall model for planetary orbits than what the circle allowed before.
I see a similar difference between the SAM pattern and Reducers or Streams.
Jean-Jacques Dubray
@jdubray
Nov 05 2016 19:17
I would not say "centralized", it's more like "deliberate", the step during which you mutate state must be delineated. You can't arbitrarily/liberally assign property values. That is (IMHO) what's wrong with the way we write code.
SAM supports parent/child relationship, so "centralized" would not qualify properly to describe how SAM works.
@sladiri I agree, SAM makes some very subtle changes to the way we code, but they are profound, just like the introduction of elliptic orbits.
The whole notion of immutability is nonsense to me, it's like you'd need to create a new copy of the entire Universe before you make changes (just to be safe). Really? you can't find smarter ways?
Charles Rector
@chuckrector
Nov 05 2016 23:00
i can see how functional programming has an appeal, and why it would be appealing to try to apply it "all the way". in general, the more constraints anything has, the less freedom it has, and therefore the more predictable its outcomes. if a function has free reign to "touch the universe", it has the power of ultimate expressivity. but, it is also truly chaotic in terms of reasoning. that is, when you can touch the universe, you must also know the universe in order to reason about your actions. so, FP puts the constraint of "horse blinders" on your functions, and they cannot see anything but what is in front of them (your inputs). from one viewpoint, it is perhaps a way of solving problems by "increasing ignorance". that is, reducing chances to "cross the streams" (ghostbusters...)
when i think about what SAM is like, i think of a sort of "deep etiquette". the constraint is more in your "motion" rather than your "vision"