Sure, I'll take any appropriate terminology, but again, I don't see how the wiring would influence the fact that the implementation of the action is truly a pure function. You can actually write all your actions the way I wrote them, so you can have a pure function to test. I just don't see the difference personally, the wiring code does not change the characteristics of the inner function.
For the purpose of unit tests, I can substitute the present function of the model with a unit test harness.
It will yield the exact same results and properties than if I test the inner function
nothing less, nothing more
SAM provides a clear delineation between programming model, wiring and architecture.
so for a component i will want parts of the model + control state (state function without implicit render). do you agree that the parts of the model i am intersted in should just be included in the state function output?
function state(model) {return {isCounting: ..., blah: model.blah}
well, you just don't know how much of the model would be used to compute the properties of the component.
so i give it the whole model
You can test the component in isolation!
the state computes he required properties for the component
each component has its own state function
you pass properties and you look at the output
great
again, I would not go as far as decomposing the model and state representation along components.
it provides a clean separation, modular components, general good practices?
and scales
The state representation computes the overall state (as in status) of the application which will decide a number of things, the components should be as isolated from it as possible. We talked about not having the requirement of the model/state to be centralized, but it's generally easier when they are
ah
yes and know, I think what you are talking about is more parent/child instances
the whole point of SAM is precisely to avoid that coupling component/model
Since they are not coupled, they can't really go together, say like a traditional ng2 component or even React
im trying to isolate component, and bridge component and model via state function
Yes, the state function is the bridge.
What you truly want to achieve, IMHO, is to have components to be as dumb as possible
yes
exactly
they have just the component business logic and they know nothing, absolutely nothing about the app
so you cannot put the component and the model/state logic together
that's why SAM is called SAM, not VSAM
The view is ancillary to the pattern.
I can even use the pattern without any view at all
Clearly you will need to decompose the model in "units of work", but I am not even sure they will map well to slices of state representation
All these concerns components, actions, model (units of work), state representation need to be decoupled
yes the mutations decompose naturally with just model and action - no need for state i thought?
trying to fit them in a single logical entity and then compose these entities like objects is a mistake IMHO
yes, no need for state.
are ther instances where your unit-of-work/mutatons needs access to state?
you can do a bunch of clean testing with just action/model
No, I would say that you are probably doing something wrong (though I have done it :-)
okay good - that would have changed my architecture probably drastically
when that's the case, it means that what you see as state representation is really part of the model
ah yes
nice
The reactive loop is unidirectional and when something does not fit, it means you are doing it wrong.
That's also why nap is so important, otherwise you'd break a lot of rules if there was no nap()
it seems this disconnected nature of nap can be fixed
nap computes next action
unless we think there is no next action, and it returns nothing
yes, exactly
but doesnt no action actually mean - just render the app
action=render
sure
in a way that's a next action...
that way it truly would be
view=nap(state(present(action(model)))
ah ah
sure
I like is separate, but granted
i think this is significant
it gives the wrong impression IMHO
I present the view to come from the state representation
I don't like the association next-action / view
nap hides the fact that one of its actions is
represent
I understand your point, I don't dispute it
@jdubray well, I was just trying to provide feedback/contribute to sam which I think provides a bunch of cool ideas, but if you insist to call something a "dog" when it is a car (and that makes the whole difference, it is in fact the cornerstone of a whole field of programming ie functional programming) then there is nowhere we can go from there...
it's just I believe it breaks a little bit the philosophy of the pattern, though strictly speaking you are correct
as long as I force you adopt my point of view, I don't see much of a problem.
thanks for taking time to discuss this @jdubray. i only intend to refine my understanding of SAM and eventually encourage its use in work i do
I understand where you are coming from.
any time!
It refines mine too!
I am happy to take any critic.
I come from a very different perspective. You have to understand that I spent most of my career trying to understand how state machines fit in programming, so SAM is really big for me.
For the first time I have found (not me personally since this is coming from TLA+) a way to align programming with the structure of a state machine.
im glad youve shared it with us
If there is anything wrong with what I am doing, I'd be the first one that wants to know
Even the fact that I can create an API orchestration capability is big, imagine, before SAM we had to use something like BPEL or proprietary orchestration engines. I can code orchestration in JavaScript. That's huge.
is there an obvious example of properties that should exist in state function, and not in
model.data?
take a simple app
N canvases, that let you draw rectangles on them
anything that's a "status" would probably mostly live in the state function
isDrawing
could go in state
sorry I don't example your example.
like your fishing game but not a game of catching fish. just a canvas that lets you draw shapes (real simple)
state is a "function" so isDrawing would have to be computed
state(model) { return {isDrawing: true}}
yes
the model would store a list of canvases and shapes drawn on them.
yes, that would be in the model
so state probably looks like
state(model) { return {isDrawing: true, canvasId: 1}}
for which canvas is currently being drawn on
so we can highlight it in the UI for example
yes, that would work
but then, as soon as any mutation needs to know if we're drawing or not (is actionX allowed while drawing?) - we have to move this state into the model
Anything that is computed from a range of values generally fits well in the State function
I suspect that a "status" is actually a condition value in [a,b]
that's generally what you will find in the state function, that will assist in computing the state representation
or we need anchillery model properties, onmousedown => model.canvases[i].started=true onmouseup=> model.canvases[i].finished=true
see here you are talking about state alignment, the mouse has a state and the application need to be aligned with it
that's a little bit different use case
state(model) {
canvasIdsDrawing = model.data.canvases.any(started=true)
return {isDrawing: canvasIdsDrawing.length, canvasIds: canvasIdsDrawing}
}
that's why in the fishing game I have tried to convert the mouse events into something completely different
@jdubray i've seen many people jump in here now and argue your use of "pure function" yet mostly by saying "you are wrong" and reciting some definitions in your face, rather than ask your definition. now it's making me very curious -- from your perspective, what are the defining characteristics of "pure" versus "impure" functions?
i think the missing part in my mental model was anchillery model properties
It's no different than everyone else's, I just factor the "wiring" out of the definition. I really don't see why people see that's an issue.
I understand that you might say uh? but I don't see what I am breaking by factoring the wiring separately.
by "wiring" you just mean a different concrete way of expressing the same thing, right
@edmulraney you lost me
o = f(i) is one way to wire the function call
f(i, function(r) { o = r; }) is another
I don't see any difference what so ever from an outside observer, I passed i and I got o with the same result
this is strictly equivalent, so mathematically, there is no difference??
@edmulraney it hard to have a general rule to delineate mode/state, in essence they are very close, unlike actions/model
However, I can see in practice how it helps decouple the model from the view because the "statues" will influence the state representation and the model does not need to know anything about that.
@jdubray that equivalence does make sense to me. one thing that a few people have seemed to want to drive home is that pure functions "must return a value". and in your State function example on sam.js.org, for example,
state.representation does not return a value. it makes me wonder if they are hung up on that detail. technically speaking, it actualy does always return a value -- undefined. :^) at any rate, i wonder what your opinion is of that return value part, and its importance in the definition of a "pure function"
Sorry, we must not have learned the same math:
A function is a relation for which each value from the set the first components of the ordered pairs is associated with exactly one value from the set of second components of the ordered pair. there is nothing in the definition of a function that specifies how it is used. The "function" is the "relation".
I don't need to convince you. Just don't call it a function, it's is not essential for SAM.
agreed there -- i am a high school dropout! so your definition of a function is coming more from the mathematics side
i'd actually never read up on "pure functions" before, though i had a rough idea
@chuckrector I'm not "reciting" anything or trying to put fingers trying to put myself right for the sake of it. If you've read all my comments you see that I'm just trying to understand and contribute. But in order to strengthen and allow people to adopt a project, you must be opened to contributions/criticism.
@rickmed agreed
@jdubray i was reading this here: https://en.wikipedia.org/wiki/Pure_function and i'm curious if you think that definition is bogus. i also found this one interesting: "printf() is impure because it causes output to an I/O device as a side effect"
i was just doing some searching. in mathematics, seems like there is no such thing as a "pure" or "impure" function. something is either a function or it isn't (?)
that definition of a function is slow going on my mind. gonna take me a while to grok it @_@
(the online math notes one)
In programming, pure functions may not have any side effects. To say SAM requires pure functions is incorrect, but "pure with respect to model" I think is correct-enough if a bit confusing. The idea is nothing but .present should mutate model
@jdubray that is correct. But the implementation of a (mathematical) function in programming needs to be a "function" (as in a programming language -which is just an abstraction to encapsulate a bunch of steps in a calculation/procedure) that returns some value and has no observable side effects. That is precisely how to maintain the relation between two sets.
Mathematical definition is actually closer to pure functions: given input a you must always get the same exact output, f(a). With side effects this isn't true, since it may rely on data stored somewhere which isn't a parameter of the function.
that has huge implications and is the corner stone of functional programming. Redux is in part hugely popular bc it -probably the first mainstream fp paradigm in the front end.
@schtauffen yes. Since the concept of a function in math and in most programming languages is note the same. That is why there is not such thing as a "pure function" in math. Just function.
sorry, I was in a call, jumping into another one now, will respond later
looking forward to it. tbh, my brain is a pretty sore now! while the pureness of a function is irrelevant to me in terms of my interest in SAM, as i mentioned, the repeated "resistance" to the terminology has made me very curious. it makes this entire dialogue very interesting to me
So yes, I agree with the "pure function" definition, but you have to accept that
o = f(i) is just a syntactic way to express the relation that the function represents.
The function always evaluates the same result value given the same argument value(s). is not logically equivalent to o = f(i)o = f(i) is just a syntactic way to express the relation that the function represents.
In SAM I do introduce a slightly different definition for the actions where the purity is define with respect to the model. It's perhaps not the best choice of word and I'd be happy to learn the proper way to say that, that function does not have the ability to assign property values of the model, it can only submit a proposal.
@rickmed it's probably best that we agree to disagree. You have a point, I don't disagree with it per se.
@rickmed just to be clear, SAM is not trying to align with Redux and/or FP, but with TLA+. I do believe that FP/Redux are flawed because they focus on the wrong problem. Same focused on isolating mutation from all the other aspects of the program, FP and Redux tend to pretend that mutation does not exist, you can do whatever you want and then you mutate everything in one step (update the store). Redux is a bit like submiting a proposal that is equal to the entire and that is always accepted. Stated that way you realize how innefficient that can be.
FP is a cargo cult like OO, it works well so solve certain types of problems, of which State Machines are not. I have invited a couple times Erik Meyer to explain the implications of TLA+ on FP and he has consistenly declined.
Let's not say because something is "popular" it is necessarily "correct".
That is why there is not such thing as a "pure function" in math. Just function.
uh? that's kind of the opposite, I'd say 100% of the functions in Maths are pure, it happens that in programming we can write "things" that look syntactically like functions (o = f(i)) but they are not functions in the mathematical sense.
@jdubray I don't get why you get so defensive. 1) I'm not trying to make a point specifically about a judgement of sam's paradigm. 2) I'm not saying redux is perfect (although it is hugely better than the previous alternatives) which is precisely what drove my interest into sam.
I'm not a fp fanatic, There are no silver bullets, only good tools for a specific problem
Well, everyone in the FP community is very defensive when I present SAM, so I'd rather be upfront that there is a big difference between the two.
Also, I have read Dr. Lamports papers
For people I talked to in the Redux community, including Dan, SAM is just a steal from Redux, though the semantics don't align well. I appreciate that Redux has a lots of bells and whistles and you can find a good intersection between SAM and Redux, but then it might not look like FP anymore.
@rickmed happy to have your feedback on TLA+, it's very important for me to come as close as possible to TLA+
"uh? that's kind of the opposite, I'd say 100% of the functions in Maths are pure, it happens that in programming we can write "things" that look syntactically like functions (o = f(i)) but they are not functions in the mathematical sense."
That is exactly what I'm saying
I see, sorry
I agree that Redux is better than Flux or React alone.
No question about it. I was really hopeful when I saw it and tried to contact Dan about a year ago, but I missjudged that he was trying to align with FP/Elm, he was not interested in solving the problem.
I was hoping for instance that Dan would see how terrible Sagas would be to the Redux programming model, but he prefers Sagas/Function generators
@jdubray if you want this project to succeed, I urge you to be more opened to criticism (specially from fp which is too big in the general software engineering/academics to ignore), they same way you would expect a hardcore fp person to be opened to sam's new ideas
I'm happy/willing to learn new ideas as well as to give criticism to better understand and improve the ideas I'm interested in at the same time that I thank you to expose to the world these new ideas in the form of sam
in terms of tla+/sam, I'm happy to discuss it another time with a fresher brain :)
@rickmed going back a while, I had the same argument with @jdubray about the use of "pure function" ... I don't want to add oil to the fire, but I think it's safe to say that "pure function" means different things to different people, and at my first look at SAM (and especially at some sample code), "pure function" did not align well with what I felt were "pure functions". I got pretty upset about it, actually! But, now I realize I got tripped up on that and it got in the way of understanding SAM. Now that I see it is tripping up others, I do agree that we should work towards clearing that up. Because it would be a shame for people to turn away from SAM because of that use of "pure function", if they perceive it as "misuse" of the term. I'm not saying who's right and who's wrong here. I'm saying, if people turn away from SAM (just) because of that, (I almost did) -- it would be a shame.
this "pure-function" issue isn't really tripping up anyone. you just simply can't take a well established, well-defined term and redefine it for your own purpose. jdubray often talks about how other people redefine terms like state and action and get it wrong, then himself does the same thing for "pure function". perhaps it wouldn't matter so much in everyday conversation, but this isnt everyday conversation. if semantics are as important as jdubray says then i would have expected him to care the most about abusing or redefining terms. just call it what it is "pure with respect to the model" or whatever
@rickmed i've wanted to bring up that subject on this channel before, about how the defensive and superior attitude is detremental to the reception of SAM. but have held back. glad to see other people think the same thing
@rickmed but I am open, I urge you to consider a simple analogy. The laws of Physics are governed by four concepts: Mass, Light, Energy and Force. You can develop an entire branch of Physics by studying Light, it's called optics. You don't have to know anything about Mass, Forces or even Energy. All other concepts can be conveniently hidden in the Math. Just like Physics, Computing is defined by four irreducible concepts: Type, Action, State and Relation. You can reify some concepts into another, but you cannot ignore one of these four concepts. You can produce valuable formalisms by turning off some of these concepts, OO for instance is solely about Type and Action, State and Relations are reified as properties of a Type. Is OO useless? if Functional Programming useless. Is Optics or Electro-Magnetism useless? no, of course not, but if you try to pretend that Functional Programming is the foundation of Computing, then I will state that this is incorrect, just like Optics is not the foundation of Physics. No one would argue with that. So I am not sure who is closed in this debate? Is it the people who are emotionally and sometimes financially attached to FP or is it me?
@edmulraney It's kind of ironic because I didn't say I disagreed with the definition. If you are trying to say SAM is wrong because your definition of a pure function is wrong, not sure would fly so well. All I am saying is that, just like FP is trying to isolate "side-effects" there is an important consideration which is the type of functions that can be an action cannot make assignments to the model. I am trying to say that actions in SAM are functions which are pure with respect to the model, just like FP needs to define a specific type of functions. They are still functions even in the purest Mathematical sense, it's just a question of boundary, but they locally do not behave like functions. Even a "random" value is a function, it is just that under certain circumstances an observer of a random value may come to the conclusion that they are not.
i think we're talking at cross purposes
I am trying to bring the discussion at the level of first principles and the FP community is trying to say, we have to use FP, period, if you are not using FP you are objectively wrong. So again, I am not sure who is closed and open in that discussion.
SAM cannot be aligned with FP since the Model in SAM is not FP compliant.
ive never seen anyone in the FP community say that. who is saying that?
Again, SAM cannot be FP compliant.
so? no one said it had to be
TLA+ is "Temporal Logic of Action", there are clearly some aspects of TLA+ that cannot be described from an FP perspective, just like there aspects of Physics that cannot be considered when taking into account LIght alone.
Well, then I am not sure why we are having this conversation, if you are trying to nail me on terms, I am happy to adopt any terminology. I don't see the point of discussing names. If you don't like the way I use "pure fonction", we can call them "aseptic functions" because they don't make the model dirty.
If the FP police want to nail loose semantics, please start on the React side, Lee Byron defines an action as:
While Dan defines an action as a Data Structure which has a "type"
I am trying to say that actions in SAM are functions which are pure with respect to the model
SAM needs to define a type of functions, just like FP defines a type of functions
I like that.
I think that would be clearer.
yes exactly @foxdonut , we need to make it clear that the functions in SAM cannot assign properties of the Model
Just like in FP you need to make it clear when a function has/has no side-effects
If you don't want me to use "pure", I'll use aseptic.
I have no issue with that, it's just a name, just like "pure" it conveys nothing about its meaning.
@jdubray I think you'd kill two birds with one stone there. Avoid confusion over "pure function", and drive home one of the important principles of SAM. You could still say "pure", just being more specific as "pure with respect to the model" I think is helpful.
The meaning comes from the shared understanding of what we all agree "pure" describes.
Personally I prefer "pure with respect to the model" over "aseptic".
I have been very clear from the beginning, I understand the FP definition of pure.
:-) me too.
Even within the React team, they can't agree on the nature of an action.
So I am not sure why I can be nailed because I use the same word for a different meaning,
Here is the full thesaurus
I can't see a single word that would work in lieu of pure
@jdubray its frustrating how you handle these types of conversations. no one is trying to "nail" anyone
I blame the chat medium, with its lack of tone perception, facial expressions, and other non-verbal communication...
then let's have an open conversation then, SAM is a reactive / functional pattern built on the foundation of TLA+. If you want me to remove both reactive and functional, I am happy to do so. I like both concepts, they are for me part of the picture but I don't believe it is appropriate to align SAM with FP (as defined by say Haskell) or RxJS. Both paradigm are trying to negate (application) state and treat it in a way that I find highly innefficient.
As a result, Redux leaks into Thunks and Sagas, while Elm is trying to define "declarative" effects which only results it to create a slew of ancillary state machines, just to keep track of what's going (such as when you are making an API call). And for what, what is the fundamental benefit achieved by FP? Unit Testing is easier. Since when we adopt a programming paradigm because "unit testing" is easier? Especially when you consider that code coverage is a useless metric and what really matters is "path coverage". In extreme cases, I could have 100% code coverage and 1% path coverage.
As a result, Redux leaks into Thunks and Sagas, while Elm is trying to define "declarative" effects which only results it to create a slew of ancillary state machines, just to keep track of what's going (such as when you are making an API call). And for what, what is the fundamental benefit achieved by FP? Unit Testing is easier. Since when we adopt a programming paradigm because "unit testing" is easier? Especially when you consider that code coverage is a useless metric and what really matters is "path coverage". In extreme cases, I could have 100% code coverage and 1% path coverage.
I don't mind having a discussion, but please define the discussion you want to have. Again, I wrote to Dan, Andre, and Erik Meyer. Happy to share the emails. Actually I'll do just that, and as usual when you touch a sensitive topic, when people are emmotiionally and/or financially attached to an answer, you have no discussion possible. This has been true with a number of fads in our industry.
Please define the discussion you want to have and I'd be more than happy to have that discussion, I am not affraid from the outcome, since I only want the best outcome. I don't care if it's called SAM, PAL, Redux, Cycle.js or whatever. That being said, the last thing I'll do is "just follow", because X, Y or Z has more followers. I have been working in this industry for to long (since 1980 when I produced my first commercial software, for a Bank, at age 16) to think that we can just trust a bunch of followers.
So here are the emails I sent:
9/2015 Chris Chedau
Bonjour Chris,
I really enjoyed your presentation at QCon / InfoQ. I am a (really) big fan of React.js. Ton travail sur React Native est vraiment tres important.
My background is SOA / Composite Applications / API Platforms and I feel that the React programming model is still a bit weak when it comes to connecting APIs to the model.
I came up with two patterns which might be interesting to the React team (Native or otherwise).
The first one I called it ReaCall (phonetically recall). ReaCall makes it easy to create Client APIs SDK that are decoupled from the Web Apps that consume the APIs.
The second pattern, SAM, is replacement for Flux. The formalism underlying to Flux is broken, I explain why here. SAM stands for "State-Action-Model" and IMHO is the correct formalism (Flux is based on Action-Model formalism).
I have created a really thin framework (component model) to use SAM easily: http://bitbucket.org/jdubray/star-javascript/src, here is an example implementing a "reliable API call with SAM".
Cheers,
Jean-Jacques ("JJ") Dubray
Chris responded, but he was not the right guy for this, he just forwarded it, inside Facebook.
Then I wrote to Dan in December 2015
Dan,
Someone introduced me to Redux today, so pardon my ignorance. I came to similar conclusions when I started to use React and landed on Flux. I created earlier this year a very thin library (STAR) using TLA+ semantics which you might appreciate (TLA = temporal logic of action).
I modified slightly the semantics of TLA+ to make state machines explicit. While doing that, I realized that State Machines (Petri Nets) were based on an approximation that needs to fixed. Petri nets and traditional state-action models (such as the one you use in Redux) connect actions and states, I.e. the action decides what the target state is. This is an approximation, it does not have to be that way, the purpose of an action is to calculate new values (purely function), these values are then presented to a “type” (~store) that decides to accept these values (based on constraints and computes the resulting state). This is semantics I implemented in my framework (STAR – State, Type, Action, Relationship).
From what I understand in Redux, you are actually using that approximation (an action decides which states you end up in):
switch (action.type) {
case INVALIDATE_REDDIT:
return Object.assign({}, state, {
didInvalidate: true
})Here is the library: https://bitbucket.org/jdubray/star-javascript/src (100% often source, free to use for any purpose)
Here is an explanation of the SAM pattern (State-Action-Model) http://www.ebpml.org/blog15/2015/06/sam-the-state-action-model-pattern/
Here is an example using SAM (a reliable API call): http://www.ebpml.org/blog15/2015/06/designing-a-reliable-api-call-component-with-sam/
I'd be truly honored if you take a look at STAR. STAR aligns the 3 core formalisms of programming: OO, FP and Petri Nets.
Cheers,
Then I had to contact Chris again, to see if Dan had got my email, but somehow he had not looked at it (which I understand).
Dan responded in Feb:
Hi Jean-Jacques,
I’m sorry I did not respond to your request.
The only letter I see from you in my mailbox is an invitation to Gitter chat but I didn’t really understand the context around that invitation so I didn’t open it.
If you wrote a personal letter to me, I’m not sure where it ended up. :-/I have seen your article come up a couple of times in the discussions.
It’s great to see more people discuss and iterate on different architectures!I am definitely not intentionally ignoring your article.
I have moved into a new apartment in another country on a new job with a new team, and I’m struggling to find time to read everything I want.I will send you my thoughts when I find some time to dive into it.
I don’t want to rush this because it’s hard for me to learn new concepts, and I need to allocate time to do it.Thank you for your contributions to the community.
Cheers,
Dan
Then all discussion ended when I pointed it out that Sagas were Stateful and were breaking Redux principle of Single State Tree, not once after that Dan continued the discussion
So I am not sure who is open and who is not. I don't mind much what people think of me.
I do have a hot button, it is semantics, it's easy to press. What you have to understand is that the number of words we have is far fewer than the semantics we need to express. Ok, sometimes I play intentionally with words and semantics, such as with "state" and "pure", I can admit it. But it is rather honest, I do feel:
a/ "state" is not associated to the correct semantics in software engineering
b/ The concept of "purity" in FP is somewhat part of a Cargo Cult, it is not the side effects that are important but the mutation. Since FP has no mutation per se, then they invent a new concept which I don't see as critical to the programming model. Call me ignorant, whatever, I just don't see the light since ultimately my goal is to mutate the application state.
a/ "state" is not associated to the correct semantics in software engineering
b/ The concept of "purity" in FP is somewhat part of a Cargo Cult, it is not the side effects that are important but the mutation. Since FP has no mutation per se, then they invent a new concept which I don't see as critical to the programming model. Call me ignorant, whatever, I just don't see the light since ultimately my goal is to mutate the application state.
I do admit that, yes, I am a but tired, and I have said it before, that "monadic" programming models are a complete waste of time: "Every thing is X" does not work, has never worked, will never work. Pick your favorite poison: X is a class, a function, an actor, ... whatever X is, that will not work. I am not smart enough to prove it, but I am old enough to have experienced it.
Here are the emails to Erik Meijer (May 2016)
Erik,
thank you for accepting my invitation to connect. I watch several of your videos/keynotes on reactive programming and it seems that there is a trend in the industry (Cycle.js / ELM and now Redux) to concentrate strictly separate "the effects from the logic". ELM speaks of "effects as data" and it looks like Redux is trying to do the same thing.
Not sure if you heard about the SAM pattern (I am the author and I'd be honored if you did, http://sam.js.org). I have created SAM as an interpretation, my interpretation of TLA+. I had a brief but intense exchange of emails with Dr. Lamport last year on creating a programming model aligned with the semantics of TLA+ and ultimately it resolved into SAM. In SAM there are three key elements: Actions which propose value to the model, the Model which Accept value (as a critical section), and the State function which is in charge of making sure that everyone who needs to learn about the changes in the application state, while triggering the next-action if there is any.
SAM does not care about effects because the model controls the critical section where the application state changes. No action can present data until a stable "State" is reached. Actions themselves can invoke APIs for instance before they present data to the model, SAM does not care since no application state has changed until the action present the data to the model. This means that actions can easily be changed and in particular, SAM inherits the notion of "program step" from TLA+.
So the question I have is what is your position on Cycle.js / ELM and the idea of separating effects from the business logic? From what I can tell, they are having a lot of difficulties doing so, Redux introduces ... Sagas (really?) and Cycle has changed again its core API.
From the videos that I have watched you seem to claim that it's not wise to try to separate effects from the logic, nor even desirable. Is that correct?
Apologies that's a pretty basic question, but it seems at this point that a lot of people are struggling with it.
thank you,
JJ-
Erik,
I apologize to bother you but this question keeps coming up. This is not a heated debate, at the moment, people are just trying to find the best way to deal with effects in Front-End architectures.
Not sure if I could interest you in joining our discussion room: https://gitter.im/jdubray/sam
Elm seems to be the most mature (from a Front-End perspective) in handling "effects as data", but even Richard Feldman (the authority in that question https://www.youtube.com/watch?v=6EdXaWfoslc) seems to not make a very good case for doing so. He claims in the talk, that Elm makes it possible to not have to write stubs to test your effects, but his code looks a lot like he is writing the stub(s) in the application code, so the gain seems to be pretty low.
Another argument that came about this week is that this "effect as data" approach seems to require that maintain additional state/status in your model just to keep track of what's in flight.
Anyways, I am sure your are busy, but I can assure you that this is one of most important questions at the moment in Front-End architecture.
Thank you,
JJ-
I really don't think I can be accused not wanted to have a genuine discussion about these topics.
@jdubray thank you for sharing all those details! personally, i understand your perspective much better now. particularly on "state" not being associated with correct semantics and the concept of "purity". that is, the industry has assigned terms such as "pure function" a specific definition, and you understand it, but for you some of the details in those definitions are a sort of superficial dressing.
i don't understand all of lamport's talks and materials, but i did read and watch a handful of them. i noticed he talked repreatedly of engineers getting hung up on language details and missing out on "true equivalence" underlying various outcomes. from that perspective, it makes sense to me how you can see some of the details of the definition of things like "pure function" to be missing the point.
SAM would work just as well with "effects as data", there is nothing conflicting with SAM, it's just on face value this seems a lot more work than it's worth.
re: "closeminded", i think there are levels of open vs closed with different purposes. to invent something while remaining unavaialble for comment on it, that would be truly closed. yet you are very active here about discussing SAM, and that availability to me is a great openness.
i do think the terminology issue is superficial. afaict, you are defending what SAM is as you have defined it, and that part must be "closed" or becomes not-SAM. i'd expect anyone to defend the "is-ness" of their invention -- which exists separate from the language used to attempt to describe it. you've done the hard work of inventing and now it's our turn to apply it.
feedback not on the level of application seems disingenuous to me, like spelling or grammar nazis. understanding your meaning seems much more valuable ot me. when i don't understand your meaning, attempting to apply it and then discussing that attempt has taught me much more than bikeshedding vocabulary! :^)
I am not even trying to defend SAM, if someone comes with something better I'll take it, but from what I have seen, I am not exactly convinced.
But I am not ready to take arguments like "FP is better therefore Elm/Redux are better"
right, defend is the wrong word probably :^)
The silence from Eric Meijer on TLA+ is deafening. He has interviewed Leslie Lamport, but he has never mapped the implications of TLA+ on FP. I would at a minimum expect from a guy his caliber to do that (there is no side-effects/purity in TLA+ and there is no "temporal logic" in FP)
It would be really helpful if someone his caliber would come forward and put these two great theories in perspective
I don't dispute that FP is great, it's just I am not ready to use it for everything.
i watched that interview!
yeah, i'm not sure what "blah blah is better" tries to accomplish, other than bullying. certainly that is not about discussing anything. if someone has decided what is better, they should just use it. for them, there is no question. but i'm interested in learning about the applied merits of these things by actually practicing them
e.g. SAM!
If anything paradigms like OO, FP, RxJS, MVC, SAM... have huge implications on the amount of code we write and how maintainable that code is. It certainly deserves a conversation. When I watch Rich Feldman's presentation on Elm claiming that you don't need to write stubs, then you look at the amount of code he writes, to avoid writing stubs, you wonder what there is to gain, it's at least a valid question to ask. Just try to get an answer on that question! I'd be surprised if anyone answers it.