These are chat archives for jdubray/sam

20th
May 2016
Jean-Jacques Dubray
@jdubray
May 20 2016 16:32

And here is Redux-Loop: https://github.com/raisemarketplace/redux-loop

A port of elm-effects and the Elm Architecture to Redux that allows you to sequence your effects naturally and purely by returning them from your reducers.

Here is the core of the argument:

Methods for handling effects in Redux, especially those implemented with action-creators, incorrectly teach the user that asynchronous effects are fundamentally different from synchronous state transitions. This separation encourages divergent and increasingly specific means of processing particular types effects. Instead, we should focus on making our reducers powerful enough to handle asynchronous effects as well as synchronous state transitions. With redux-loop, the reducer doesn't just decide what happens now due to a particular action, it decides what happens next. All of the behavior of your application can be traced through one place, and that behavior can be easily broken apart and composed back together. This is one of the most powerful features of the Elm architecture, and with redux-loop it is a feature of Redux as well.

Jean-Jacques Dubray
@jdubray
May 20 2016 16:39
blob
Sorry, but I don't see the light, I don't need stubs to be able to test effects, I use "service/API virtualization" (record/replay requests/responses). This obsession to separate effects from the logic seems to require a lot of energy for no real purpose (even though it is logically correct). This is the image I have of Cycle.js and Redux-Loop (see above)
I feel already bad enough that nap() can lead to that result but at least you can use nap() sparsely, when an "automatic" action needs to be triggered. The loop/cycle approach also requires that you handle all 3rd party requests via effects (such as the getPostalAddress() example), there is absolutely no reason whatsoever for the application state to be aware of third party API calls.
Jean-Jacques Dubray
@jdubray
May 20 2016 16:46
If someone can explain to me the big value of effect free business logic (other than "it makes it easier to test" which I disagree with), happy to discuss. "Loop" architectures are obviously supported by SAM via nap() (which shows one more time the robustness of TLA+), but I certainly would not recommend using them.
@gfortaine did I read you were volunteering to build a "reason"(able) sample implementation of SAM?
weepy
@weepy
May 20 2016 17:24
The difficulty you face in promoting your ideas is that you mostly talk down other efforts. I'm not saying you're wrong about them. But the alternative you suggest is kinda "built it yourself the SAM way". I can see SAM being quite a clever way to think about it but it's going to be difficult to persuade most developers without a solid library implementation. #justsaying :-)
Jean-Jacques Dubray
@jdubray
May 20 2016 17:26
I understand that, and I appreciate the feedback, but when you try to talk "up" and ask, so why do you do it that way? the answer is "#justbecause...", which is not really conducive to a discussion. The argument is that by "asking questions" you are promoting your approach.
I would have thought that being "library" free/vanilla.js would be a huge driver for adopting it, but I agree, libraries/frameworks are "addictive" a bit like drug or sugar. You get this instant "kick" and you never look at the long term cost (addiction/health/overweight...)
weepy
@weepy
May 20 2016 17:30
Sorry I don't quite follow. Well a library is at least a stake in the ground that can be objectively criticised and improved.
I'm suggesting it might be a way to increase engagement
Jean-Jacques Dubray
@jdubray
May 20 2016 17:31
SAM's library is one line of code...
V = S( M.present(Action(data)),nap(M))
weepy
@weepy
May 20 2016 17:32
That's maths not code :-)
Jean-Jacques Dubray
@jdubray
May 20 2016 17:32
Actually, I have been surprised at the number of people downloading SAM-SAFE
weepy
@weepy
May 20 2016 17:32
Oh yes?
at my level, considering the levels of marketing I am doing for SAM...
Each time I release a new version I get close to a hundred downloads
weepy
@weepy
May 20 2016 17:33
Nice.
Jean-Jacques Dubray
@jdubray
May 20 2016 17:38
Redux is #36 most popular project on Github, how can I compete with that?
:-)
cycle is #1500 (#justsaying)
weepy
@weepy
May 20 2016 17:40
It's not about competing
Just saying I believe it would drive higher quality engagement
Guillaume FORTAINE
@gfortaine
May 20 2016 17:55
@jdubray Yes :smile:
Jean-Jacques Dubray
@jdubray
May 20 2016 18:06
I don't disagree, but currently our industry is on its way to become "functional reactive" just like it was once "object oriented", you can't have a discussion when people are on a mission. I am not.
@gfortaine fantastic, really curious to see what reason is about
weepy
@weepy
May 20 2016 18:07
Fair enough :)
Jean-Jacques Dubray
@jdubray
May 20 2016 18:11
Just try to have a discussion with OO zealots in 1999? I was rebuked by the inventor of the MVC pattern himself when I started to talk about "extensible object models" at this oopsla workshop in 1999 http://jeffsutherland.org/oopsla99/Dubray/dubray.html
Of course now we have JSON/JavaScript and the debate is closed
blob
Now, I am suggesting that there is no need to separate effects from the business logic, it is better to spend your energy factoring the business logic around "mutating" state (the correct way). what a strange idea! You have state, all you do all day is mutating it, and some people focus all their energy on effects and abstracting state away? really?
weepy
@weepy
May 20 2016 18:16
:)
weepy
@weepy
May 20 2016 18:47
Make sense
Michael Terry
@formido
May 20 2016 18:53
Now, I am suggesting that there is no need to separate effects from the business logic, it is better to spend your energy factoring the business logic around "mutating" state (the correct way). what a strange idea! You have state, all you do all day is mutating it, and some people focus all their energy on effects and abstracting state away? really?
reminds me of a comment by Rich Hickey in a great talk he gave
Simple Made Easy
"Data, please, we're programmers, we're supposed to write data processing programs, there's all these programs, they don't have any data in them...they have all these constructs we put around it, globbed on top of data. Data is actually really simple. There's not a tremendous number of variations in the essential nature of data, right? There are maps, there are sets, there are linear sequential things. There are not a lot of other conceptual categories of data. We create hundreds of thousdands of variations that have nothing to do with the essence of the stuff and make it hard to write programs that manipulate the essence of the stuff. We should just manipulate the essence of the stuff! That's not hard! It's...simpler."
Jean-Jacques Dubray
@jdubray
May 20 2016 19:42
Yes, exactly, we can't really ignore these first principle constraints, abstractions are great but they need to be brought in with purpose not so much "just because".
Jean-Jacques Dubray
@jdubray
May 20 2016 23:18
The presentation is a bit long, but basically Richard explains why he loves Elm (and everyone else on his team)