These are chat archives for jdubray/sam

16th
Jun 2017
Jean-Jacques Dubray
@jdubray
Jun 16 2017 10:25
I'll run a quick test Monday
Jean-Jacques Dubray
@jdubray
Jun 16 2017 14:39
I hope you appreciate how insane Monads are and what happens when you start with a programming model that makes no sense at all ("everything is a pure function", and then continue thinking, "oh I know another cool thing we could do, how about function composition?".
Johan Alkstål
@johanalkstal
Jun 16 2017 14:57
What's wrong with pure functions and composing new functions?
Jean-Jacques Dubray
@jdubray
Jun 16 2017 15:11
Functions can compose, nothing wrong with that, but Actions cannot compose (nap is the only mechanism that would amount to action composition but that's not a good way to look at it). When you pay no special attention about where your actions are and how that code relates to mutation, then you end up in a corner that's really hard to get out of.
Jean-Jacques Dubray
@jdubray
Jun 16 2017 15:23

As I said before, FP (unlike OO) is trying to address the three approximations of programming that we all took for granted for the last 50-60 years:

  • actions can update application state
  • assignments are equal to mutation
  • the is no need to define what a programming step is

In FP functions do not update application state, only one assignment is a mutation, a function is the programming step, but that's just not the right way of doing it. In reality when you look at it closely, FP puts mutation in a big function box and FP reduces itself to just wiring, which RFP takes to the nth degree. Pure functions are as fallacious as the concept of data encapsulation, and immutability is as useless (if not poisonous) as inheritance.

FP looks fresh precisely because we feel that it's trying to address these three approximations.
Jean-Jacques Dubray
@jdubray
Jun 16 2017 15:47
But it's doing it in the wrong way.
Antanas A.
@antanas-arvasevicius
Jun 16 2017 15:54
Hello, do we talk here about doing FP in extremes which forces mutation completely?
if looking at extremes , FP immutability, side effect free functions, no mutation for everything is just not practical in many situations
Antanas A.
@antanas-arvasevicius
Jun 16 2017 15:59
same with OOP extremes: encapsulation, full mutating objects, everything is an object, inheritance, nominal subtyping
but FP is good, it allows OOP programmers to see the world differently
Antanas A.
@antanas-arvasevicius
Jun 16 2017 16:04
Many OO developers creates unneeded object mutating methods add complex internal state validations and modifications, and when I ask him/her, hey what if I just create a new object of you class if I need to change that parameter instead of using your method call? He/she says it would work and would be less code, but it's not efficient.
and they are just adding these methods to do a High Cohesive object/class.
I'd better learn FP than OOP in a first place, would be much less brain damage than now :smile:
Jean-Jacques Dubray
@jdubray
Jun 16 2017 16:17

well, that's what I am arguing about, you have to be crystal clear about your programming model. There shouldn't be anything like XFP or XOOP, your programming model should support as many use cases as possible, and if not, you should still define it with precision and purpose. The more choices you give to someone the easier it is to make the wrong choice

I'd better learn FP than OOP in a first place

yes, OOP actually enforces these three approximations! With FP you get at least a chance to handle these approximations better over time and who knows you may end up on SAM!

Johan Alkstål
@johanalkstal
Jun 16 2017 17:24
And with programming model, we're talking about the model specific for your use case/application?
Jean-Jacques Dubray
@jdubray
Jun 16 2017 17:36
The programming model is the conceptual structure of your code. OOP and FP have a different conceptual structure, but I can show that a closure and a class are conceptually the same, just a different way to declare and instantiate them.
Jean-Jacques Dubray
@jdubray
Jun 16 2017 17:44
I like closures better of course.
Daniel Garcia
@pel-daniel
Jun 16 2017 18:49
@jdubray What are your thoughts about the benefits of FP with concurrent/parallel code ?
Slađan Ristić
@sladiri
Jun 16 2017 19:17
@jdubray When I remember Java and its mandatory classes, well I like JavaScript's closures better too. :D It is 'getting things done'.
Jean-Jacques Dubray
@jdubray
Jun 16 2017 19:22
@pel-daniel FP doesn't do anything for concurrency. It's obviously more useful for parallelism. Concurrency is hard, that's why people write Operating Systems. Single State Tree programming models help for concurrency because it centralizes and synchronizes mutation (whether you do it a la SAM or a la Redux). Shared state is inextricable... SST is very naive but it does the job when the level of concurrency required is pretty low.
?? what do you think?
@sladiri the killer aspect of FP's programming model is to be able to pass functions as arguments, it's not closure (since that's just OOP) or even pure functions / immutability (who really cares about that? yeah, ok I get it, testability, how about code clarity so that you don't need to rely on QA as much, maintaining unit test is a lot of work that doesn't scale and the path coverage is generally too low for unit tests to have enough value at 100% code coverage).
Jean-Jacques Dubray
@jdubray
Jun 16 2017 19:27
Pure functions are totally overrated. It's good to have in your toolbox but that's it.
Slađan Ristić
@sladiri
Jun 16 2017 20:28
@jdubray Yep, functions as first class values, that is nice.
Last week a colleague who works with Android/Java asked me to show him how to apply a transform to a bound Angular value. I guess he was a bit surprised how you could (luckily Angular supports it) just drop in a function call instead of the value. :) He also seemed to like the solution a lot and is interested in Kotlin, which I think is more modern in this regard.
Jean-Jacques Dubray
@jdubray
Jun 16 2017 20:37
Yes, that's so powerful.