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

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?

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

@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...

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.

@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?

@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.

@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.

@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"

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.

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 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

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."

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 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.

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.

@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.

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.

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.

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).

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):

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 engineeringb/ 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.

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.

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! :^)

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.

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

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.