3 ms·

> There is nothing functional about React. The whole concept of React is to model the UI as a function of the state. React was first made in Standard ML (you d

by Zababa 5y ago

> There is nothing functional about React. The whole concept of React is to model the UI as a function of the state. React was first made in Standard ML (you don't really get more functional than this). Jordan Walke, the creator, went on to work on ReasonML, an hybrid between the OCaml and JavaScript ecosystems, to try to leverage the functional parts of OCaml. > Impure behavior, including algebraic effects, is best avoided in functional programming. This is wrong though. Functional programming doesn't shy away from impurity. Algebraic effects are a way to handle impurity, which is unavoidable.

flowerlad 5y ago
> Functional programming doesn't shy away from impurity. Disagree. Functional programmers often speak of implementing programs with a pure core and a thin layer on the outside that handles effects. If you don't have a pure core then you are not using FP.
- lhorie 5y ago
  Sorry, but you're missing the forest for the trees. This is what wikipedia has to say: "Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming"[0] In FP as an umbrella, purity is not a hard requirement for the entire paradigm, only a predominantly pipeline oriented style based around expressions is (in contrast to, say, C, where one generally passes a pointer to the same state around to procedures that pick and choose what to modify in that state bag, as a series of statements). Common Lisp and OCaml are often cited as examples of functional languages that don't attempt to enforce purity guarantees even in terms of idiomatic usage, let alone at a compiler-enforced level. Using higher order functions for, say, promises (remember, they're stateful!) doesn't mean you're not using functional programming, just like using Array.prototype.map doesn't mean you're not using OOP (it implements fluent interfaces, if you haven't noticed). It's the absence of functional tools/techniques that qualifies a program as not functional. IMHO, the unfortunate situation is that most JS people don't understand there are different degrees of functional-ness and certain guarantees only exist within specific subsets (and React doesn't conform to that subset). [0] https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming.
  - flowerlad 5y ago
    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.

by Zababa 5y ago

flowerlad 5y ago

> Functional programming doesn't shy away from impurity. Disagree. Functional programmers often speak of implementing programs with a pure core and a thin layer on the outside that handles effects. If you don't have a pure core then you are not using FP.

lhorie 5y ago
Sorry, but you're missing the forest for the trees. This is what wikipedia has to say: "Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming"[0] In FP as an umbrella, purity is not a hard requirement for the entire paradigm, only a predominantly pipeline oriented style based around expressions is (in contrast to, say, C, where one generally passes a pointer to the same state around to procedures that pick and choose what to modify in that state bag, as a series of statements). Common Lisp and OCaml are often cited as examples of functional languages that don't attempt to enforce purity guarantees even in terms of idiomatic usage, let alone at a compiler-enforced level. Using higher order functions for, say, promises (remember, they're stateful!) doesn't mean you're not using functional programming, just like using Array.prototype.map doesn't mean you're not using OOP (it implements fluent interfaces, if you haven't noticed). It's the absence of functional tools/techniques that qualifies a program as not functional. IMHO, the unfortunate situation is that most JS people don't understand there are different degrees of functional-ness and certain guarantees only exist within specific subsets (and React doesn't conform to that subset). [0] https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming.
- flowerlad 5y ago
  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.