These are chat archives for jdubray/sam

19th
Dec 2016
Jean-Jacques Dubray
@jdubray
Dec 19 2016 01:17
@devinivy That's my point, we have a number of definitions that can be aligned, we can come up with a unified definition if we want to and tell people that's an action, then every one can build a programming model, wiring and architectures around it. Until then I feel we are spending a log of energy to create a mess that will be hard to unwind. With a standard definition of what an action is, everyone can get what a model is (and therefore how it relates to actions), then things become more open when it comes to rendering the model, do you need a state function, nap,... I am certain some people can come up with other concepts, but at a minimum action vs model would be really helpful.
devin ivy
@devinivy
Dec 19 2016 03:55
i think that would be useful. to start, we need to decide on what ideas are common to multiple programming paradigms. rather than what words are common to multiple programming paradigms.
Edward Mulraney
@edmulraney
Dec 19 2016 09:33
@jdubray what problem do you foresee occuring as a result of not having a clear definition of action between developers
Jean-Jacques Dubray
@jdubray
Dec 19 2016 10:02
@edmulraney the same problem we would see if we didn't have a common paradigm for function or classes. Imagine, I tried to talk about separating wiring form programming model and some people slam me claiming I don't know what a function is. The biggest problem though would be the factoring of your code, with varying definitions people would start factoring their code in the wrong place. That's what you get with OOP vs FP. In OOP you just have methods (no function) and when you need a function, then you start creating dedicated classes or on the contrary you just slam them on unrelated classes.
In redux, because the definition of action came about too quickly Dan had to start introducing other concepts like thunks and action creators, then Sagas poped up. You can't just stitch you programming model like Redux.
Edward Mulraney
@edmulraney
Dec 19 2016 10:06
functions and classes are programming constructs tho - part of the syntax. we can't do action blah() {} like we can with function or class as it doesn't exist as a construct, and wouldn't be possible as widespread construct
because it encompasses a concept/idea spread over a system
function/class are stand alone
Jean-Jacques Dubray
@jdubray
Dec 19 2016 10:09
ah because function and classes have been part of the programming model since day 1? This was the article that sparked OOP: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.3043&rep=rep1&type=pdf
(as I understand it)
Take goto for instance, it was erradicated from programming models, while this was a perfectly good way to handle state transition? Unfortunately, for some reasons developers don't understand actions/state constructs.
Edward Mulraney
@edmulraney
Dec 19 2016 10:47
not because function and classes have been there since day 1 (which obviously they haven't :P) - but it just seems hard to envisage how an action could become a generic construct in programming languages
mostly because all it is is a function with signature: function blahAction(present, ...args)
so it seems like youre saying the presenter should be imposed on the language
Edward Mulraney
@edmulraney
Dec 19 2016 11:04
also with regard to the goto statement, you don't seriously think goto was a stronger candiate for control flow than structured programming blocks like if, while etc. do you?
Jean-Jacques Dubray
@jdubray
Dec 19 2016 12:01
Even if it doesn't become part of the language, it should have clear semantics, nobody is questioning what a queue is, even though we don't have a queue construct the vast majority of programming languages.
It would greatly help to have a standard definition, I am not sure I understand the rationale for not having a common definition for such a common concept, every one is writing "actions".
No, I am not but from a state machine perspective, once goto was gone, so was our ability to transition from one state to another, I am just saying that goto was unecessarily axed from the programming model, and it is possible that the cure was worse than the disease.
Edward Mulraney
@edmulraney
Dec 19 2016 12:27

In redux, because the definition of action came about too quickly Dan had to start introducing other concepts like thunks and action creators, then Sagas poped up.

Not quite. Actions are called actions because that's what the flux community were calling them and Dan wanted redux to appeal to them. Redux is good at synchronous flow and never added async support to core since that decision can be left to the developer, which allows them to build rich async helpers for their needs/preferences. hence sagas/redux-observables/etc.

thunk is about isolating where side-effects happen. in SAM anything goes and you can have whatever side effects you want, wherever you want, to create actions. obviously this is convenient but that doesnt necessarily mean its better for apps that need to scale and be developed on by a team
Edward Mulraney
@edmulraney
Dec 19 2016 12:32
its much of a sameness. Raw SAM just doesnt impose that you use middleware
personally i would impose a controlled area for side effects like some libraries do (tom, dva, etc.)
Zach Dahl
@schtauffen
Dec 19 2016 17:10
But I like having a job
Edward Mulraney
@edmulraney
Dec 19 2016 17:10
haha
devin ivy
@devinivy
Dec 19 2016 19:08
i find it hard to imagine what the author is really picturing
Zach Dahl
@schtauffen
Dec 19 2016 19:34
I had discussions at my previous gig with one of the system architects who was convinced AI would be writing all the codes in the next century. I argued it would be impossible unless they were sentient. Too much creative thinking involved... automating certain, well-defined tasks sure. But not developing products
(not to say the singularity won't occur in the next 100 years :P)
Vincent Jo
@inrix-vincent-jo
Dec 19 2016 20:13
@schtauffen I recently argued with a co-worker about similar issues.. about if computers will ever be better than a human in creation
I argued that it won't ever be, because machines won't ever be able to understand our needs as much as other human beings thereby not being able to be as good as a human in creating services / value that we need