3 ms·

Functional Programming has to serve a purpose. What is the point of functional programming? There are 3 benefits, mainly: (1) Ease of verification, (2) Paralle

Functional Programming has to serve a purpose. What is the point of functional programming? There are 3 benefits, mainly: (1) Ease of verification, (2) Parallelism and (3) Data-centric computation. (See article I linked for details.) Of these, Parallelism doesn't work in JavaScript. Since JavaScript doesn't support lazy evaluation, data-centric computation doesn't work that well either. That leaves us with the first benefit alone. But ease of verification is reliant on pure functions. If functions aren't pure then it is just regular code that isn't necessarily easy or hard to verify. React uses FP for a 4th benefit you won't find in any textbooks on FP: Marketing.

lhorie 5y ago
This article[0]? Sorry, but that's not an authoritative source, it's literally just some random guy talking on the internet :) No offense, but your argument is kinda self-defeating if you are trying to claim that two out of the three purported benefits aren't even applicable (and I'd argue that even that first so called benefit doesn't have a great story in JS either). Saying that verifiability is somehow intrinsically related to purity is IMHO making an overly broad generalization. You're starting from the premise that unit testing a pure function is easy, but that doesn't really generalize in any direction. Array.prototype.splice is not pure and yet it's trivially easy to test. Reasoning about the crashing potential of JS tail recursion is not easy even with purity guarantees. Large functional point-free compositions in JS have impenetrable stack traces. Valgrind et al exist so clearly it's possible to reason extensively about messy stateful things. Different paradigms aren't oil-and-water and they don't have a monopoly on any given benefit, it's perfectly possible to mix and match features of various paradigms to achieve expressiveness, idiomaticness, predictability, etc. [0] https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
- flowerlad 5y ago
  I don't see any credentials mentioned in your profile, which means we're all random guys on the internet :) With reference to the article, it builds on top of authoritative articles (see References section at the bottom), so you don't have to take anything at face value! You're right, I am indeed saying that verifiability is intrinsically related to purity. The concept of pure functions is at the core of FP. You take that core away and you no longer have the right to call your code FP. Why is it important to label something as FP in any case? React is useful even if it is not functional. What I am opposed to is misappropriating the "FP" label for marketing purposes, by the React team.
  - lhorie 5y ago
    > The concept of pure functions is at the core of FP. Only in the subset that you consider canon, not generically for all FP. Wikipedia is quite authoritative, FWIW. I agree that the React team has made some flat out wrong claims (e.g. incorrectly calling hooks pure at one point), but you're engaging in exactly the same sort of "marketing" you dislike, by biasedly claiming your specific flavor of FP is the "real deal", when in reality there are many different cohorts within the larger FP community that prioritize different things. If I had to criticize your purity-centric flavor, I'd say it's very reminiscent of the height of the OOP craze, with algebraic terminology elitism being similar to the one surrounding GoF pattern terminology. Also similar are the grandiose theories of maintainability, and the dichotomy between what loudmouths preach and what code in the wild looks like. People log things from .map callbacks. They don't grok monads. It seems entirely arbitrary to me to deny the functionalness of some code based on some technicality (case in point, do you avoid promises and do you Object.freeze(Object.create(o)) all your objects?) IMHO, there's no point defending some notion of an FP brand. Looking around this thread, you can see that people already view React's hot take on FP as problematic. Same goes for general perception of the more elitist corners of the FP community.
    - flowerlad 5y ago
      I can agree with most of what you are saying. My alarm stems from the fact that a lot of developers' understanding of FP these days comes from their React experience (which they mistakenly believe is FP) and a lot of these developers also believe that OOP is now obsolete... all based on their mistaken understanding of what FP is. I think there is a need for course correction here.

lhorie 5y ago

This article[0]? Sorry, but that's not an authoritative source, it's literally just some random guy talking on the internet :) No offense, but your argument is kinda self-defeating if you are trying to claim that two out of the three purported benefits aren't even applicable (and I'd argue that even that first so called benefit doesn't have a great story in JS either). Saying that verifiability is somehow intrinsically related to purity is IMHO making an overly broad generalization. You're starting from the premise that unit testing a pure function is easy, but that doesn't really generalize in any direction. Array.prototype.splice is not pure and yet it's trivially easy to test. Reasoning about the crashing potential of JS tail recursion is not easy even with purity guarantees. Large functional point-free compositions in JS have impenetrable stack traces. Valgrind et al exist so clearly it's possible to reason extensively about messy stateful things. Different paradigms aren't oil-and-water and they don't have a monopoly on any given benefit, it's perfectly possible to mix and match features of various paradigms to achieve expressiveness, idiomaticness, predictability, etc. [0] https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

flowerlad 5y ago
I don't see any credentials mentioned in your profile, which means we're all random guys on the internet :) With reference to the article, it builds on top of authoritative articles (see References section at the bottom), so you don't have to take anything at face value! You're right, I am indeed saying that verifiability is intrinsically related to purity. The concept of pure functions is at the core of FP. You take that core away and you no longer have the right to call your code FP. Why is it important to label something as FP in any case? React is useful even if it is not functional. What I am opposed to is misappropriating the "FP" label for marketing purposes, by the React team.
- lhorie 5y ago
  > The concept of pure functions is at the core of FP. Only in the subset that you consider canon, not generically for all FP. Wikipedia is quite authoritative, FWIW. I agree that the React team has made some flat out wrong claims (e.g. incorrectly calling hooks pure at one point), but you're engaging in exactly the same sort of "marketing" you dislike, by biasedly claiming your specific flavor of FP is the "real deal", when in reality there are many different cohorts within the larger FP community that prioritize different things. If I had to criticize your purity-centric flavor, I'd say it's very reminiscent of the height of the OOP craze, with algebraic terminology elitism being similar to the one surrounding GoF pattern terminology. Also similar are the grandiose theories of maintainability, and the dichotomy between what loudmouths preach and what code in the wild looks like. People log things from .map callbacks. They don't grok monads. It seems entirely arbitrary to me to deny the functionalness of some code based on some technicality (case in point, do you avoid promises and do you Object.freeze(Object.create(o)) all your objects?) IMHO, there's no point defending some notion of an FP brand. Looking around this thread, you can see that people already view React's hot take on FP as problematic. Same goes for general perception of the more elitist corners of the FP community.
  - flowerlad 5y ago
    I can agree with most of what you are saying. My alarm stems from the fact that a lot of developers' understanding of FP these days comes from their React experience (which they mistakenly believe is FP) and a lot of these developers also believe that OOP is now obsolete... all based on their mistaken understanding of what FP is. I think there is a need for course correction here.