4 ms·

> The whole thing has been functional programming from the start, if you know what algebraic effects are then the functional underpinning should be obvious to y

> The whole thing has been functional programming from the start, if you know what algebraic effects are then the functional underpinning should be obvious to you as well as anyone with the slightest brush with FP. That's a lot of hot air. There is nothing functional about React. Algebraic effects represent impure behavior in a functional programming language, such as input and output, exceptions, nondeterminism etc. all treated in a generic way. Impure behavior, including algebraic effects, is best avoided in functional programming. Sorry to post the link again, but please read this: https://mckoder.medium.com/why-react-is-not-functional-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

Grimm1 5y ago
So what would you call this style of programming? Saying there is nothing functional about it seems like hyperbole. It's just not as pure as you'd like. I say as someone in the world of people who need to get things done, why do we/I care? I read the article FWIW, it didn't particularly convince me. I think even writing things in the style of functional programming, if that's what we want to call it, still makes it easier to reason about the code. Confining side effects to hooks also means there's only one place we have to reason about having non pure consequences.
- flowerlad 5y ago
  Functional Programming is about purity. At the core of FP is pure functions. If you don't care about purity don't use FP. There is a lot to like about React, and Hooks and so on. Just don't call it FP though.
  - Zababa 5y ago
    No, it's not. The "purity" part was mostly pushed by Haskell enthusiasts, because Haskell cares a lot about purity. On the other hand, ML and its descendants don't care that much. Here's an example in OCaml: let add (x: int) (y: int) : int = print_string (Format.sprintf "x: %d, y: %d" x y); x + y This is a function. It's not pure. There is nothing that's stopping me from using it exactly the same way as a pure add implementation. OCaml is still a functional programming language. As said on Wikipedia: "Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming which treats all functions as deterministic mathematical functions, or pure functions.". Functional programming is not only purely functional programming.
    - flowerlad 5y ago
      Disagree. Functional programmers often speak of implementing programs with a pure core and a thin layer on the outside that handles effects. (Read the article I pointed to earlier.) If you don't have a pure core then you are not using FP.
      - Zababa 5y ago
        > Functional programmers often speak of implementing programs with a pure core and a thin layer on the outside that handles effects. No, they don't really. Haskell programmers tend to program like that because monads are annoying to use everywhere in your application. But this is really just the hexagonal pattern in different clothes. DDD programmers care a lot about business logic, so the core is business logic. People that like pure functional programming care a lot about pure functions, so the core is pure functions. Some people even mix both (a good example of that is Doman Modeling Made Functional, the talk or the book). I guess people that care a lot about performance would put performance at the center, at the cost of purity and/or abstraction. Basically this whole pattern is a way to ask yourself "What are my values? What's my priority when I develop software?", and to make sure that it's at the litteral center of your application. So again, you are mixing functional programming, "functional programmers" (which I don't think means anything), and people that value pure functional programming a lot. Which brings us back to react. Is React functional? What does it means, to be functional? I can at least try see what people mean when they say "React is functional". There are probably multiple things: 1) React is more functional than its predecessors. 2) React share values with functional programming. These are a bit fuzzy, but we can try to answer them. 1) React is more functional than its predecessors: It's surely more functional than traditional vanilla JS, jQuery and Angular. I know that before React Backbone was popular, but I don't know anything about it, so maybe Backbone is even more functional than React, which would undermine this point. I may also have forgot some important development along the way (Ember ? Meteor? CoffeeScript? I wasn't into programming at that time so it's hard to judge the popularity/influence of everything). From what I know, I'd say it's a yes. At least in the most popular frameworks (Angular, React, Vue), React is the most functional. 2) React share values with functional programming. On the frontpage of React, we can see "Declarative: React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable and easier to debug.". That sounds a lot like what you can hear for some functional programming advocates. "Make the code declarative, be more productive, and the compiler will take care of the performance", in a way. Then there is "Component-Based: Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state out of the DOM.". Making a complex UI by composing simple parts again sounds like composing functions in functional programming. "Encapsulated components that manage their own state" feels more like OO though. I can also add that the React community uses Redux a lot, which was inspired by Elm, which itself is clearly functional programming. I've heard that hooks are a way to get closer to functional programming, but I can't confirm this, as I haven't used them. As a conclusion, I'd say that yes, React share values with functional programming, though it doesn't strive for purity (in both senses of the word). So, again, is React functional? Yes, I'd say it is. What does it mean to be functional? I think a good example here would be OCaml. OCaml is a functional programming language. OCaml also allows you to do imperative programming, or object-oriented programming. However, in the wild, most of the OCaml code you find is functional. How functional? That depends. For some people it will mean functions and data structures. For some it will be this with modules. For others, that will be monads. So in general, maybe a bit less functional than Haskell, but more functional than Python or Java. That's the same with React. When we say "React is functional", we mean "probably a bit less functional than Elm, but more functional than Angular and Vue". You're using "functional" in a very specific way, which is usually covered by "pure" or "purely functional", which is unproductive to these kind of conversations.
  - eyelidlessness 5y ago
    > If you don't care about purity don't use FP. This is unhelpful. I don’t know if I’ve ever encountered this attitude before, I’m enthusiastic about FP and I frequently direct people toward FP principles wherever I possibly can. Dissuading application of those principles in part because they’re not applied in (your view of) full is sending people in the wrong direction. And you might not care, but I do: it’s also gatekeeping. Making people feel like what they’ve learned to make their code more functional, less side-effecting, and generally easier to reason about… making them feel like that’s not important progress they can value unless they share your knowledge and understanding of Category Theory or whatever is going to drive people away from what you want. And it’s going to drive marginalized people away most, probably from programming in general. That stinks. The level of purity you’re demanding isn’t even claimed by most functional languages. And the ones which do use Monads as a sleight of hand to make the claim, but that’s plainly a useful fiction.
    - flowerlad 5y ago
      > > If you don't care about purity don't use FP. > This is unhelpful. You have to care about purity. The benefits of FP hinges on this. Saying you don't care about purity is the same as saying you don't care about FP. That doesn't mean that anything less than "perfect purity" is worthless. You have to always aim for purity, even if you don't always achieve it, because without it there is no FP.
      - eyelidlessness 5y ago
        > That doesn't mean that anything less than "perfect purity" is worthless. This is more helpful. I’m not going to add my own unhelpful reaction to the rest of what you said, I think I already added more value above than I’m inclined to now.
dtech 5y ago
> Functional programs are constructed using only pure functions If that's your definition, functional programs basically don't exist in the real world. Wikipedia (and I) don't agree with that [1], it specifically separates out pure FP [2]. [1] https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming [2] https://en.wikipedia.org/wiki/Purely_functional_programming https://en.wikipedia.org/wiki/Purely_functional_programming
- flowerlad 5y ago
  You didn't read the article. How to deal with impurity is described in the article.
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.
bryik 5y ago
> There is nothing functional about React. There is literally an example React component in that article that the author calls "pure and referentially transparent". How can this be if there is "nothing functional about React"?
- flowerlad 5y ago
  But how many React components are that simple? Almost none.

Grimm1 5y ago

So what would you call this style of programming? Saying there is nothing functional about it seems like hyperbole. It's just not as pure as you'd like. I say as someone in the world of people who need to get things done, why do we/I care? I read the article FWIW, it didn't particularly convince me. I think even writing things in the style of functional programming, if that's what we want to call it, still makes it easier to reason about the code. Confining side effects to hooks also means there's only one place we have to reason about having non pure consequences.

flowerlad 5y ago
Functional Programming is about purity. At the core of FP is pure functions. If you don't care about purity don't use FP. There is a lot to like about React, and Hooks and so on. Just don't call it FP though.
- Zababa 5y ago
  No, it's not. The "purity" part was mostly pushed by Haskell enthusiasts, because Haskell cares a lot about purity. On the other hand, ML and its descendants don't care that much. Here's an example in OCaml: let add (x: int) (y: int) : int = print_string (Format.sprintf "x: %d, y: %d" x y); x + y This is a function. It's not pure. There is nothing that's stopping me from using it exactly the same way as a pure add implementation. OCaml is still a functional programming language. As said on Wikipedia: "Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming which treats all functions as deterministic mathematical functions, or pure functions.". Functional programming is not only purely functional programming.
  - flowerlad 5y ago
    Disagree. Functional programmers often speak of implementing programs with a pure core and a thin layer on the outside that handles effects. (Read the article I pointed to earlier.) If you don't have a pure core then you are not using FP.
    - Zababa 5y ago
      > Functional programmers often speak of implementing programs with a pure core and a thin layer on the outside that handles effects. No, they don't really. Haskell programmers tend to program like that because monads are annoying to use everywhere in your application. But this is really just the hexagonal pattern in different clothes. DDD programmers care a lot about business logic, so the core is business logic. People that like pure functional programming care a lot about pure functions, so the core is pure functions. Some people even mix both (a good example of that is Doman Modeling Made Functional, the talk or the book). I guess people that care a lot about performance would put performance at the center, at the cost of purity and/or abstraction. Basically this whole pattern is a way to ask yourself "What are my values? What's my priority when I develop software?", and to make sure that it's at the litteral center of your application. So again, you are mixing functional programming, "functional programmers" (which I don't think means anything), and people that value pure functional programming a lot. Which brings us back to react. Is React functional? What does it means, to be functional? I can at least try see what people mean when they say "React is functional". There are probably multiple things: 1) React is more functional than its predecessors. 2) React share values with functional programming. These are a bit fuzzy, but we can try to answer them. 1) React is more functional than its predecessors: It's surely more functional than traditional vanilla JS, jQuery and Angular. I know that before React Backbone was popular, but I don't know anything about it, so maybe Backbone is even more functional than React, which would undermine this point. I may also have forgot some important development along the way (Ember ? Meteor? CoffeeScript? I wasn't into programming at that time so it's hard to judge the popularity/influence of everything). From what I know, I'd say it's a yes. At least in the most popular frameworks (Angular, React, Vue), React is the most functional. 2) React share values with functional programming. On the frontpage of React, we can see "Declarative: React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable and easier to debug.". That sounds a lot like what you can hear for some functional programming advocates. "Make the code declarative, be more productive, and the compiler will take care of the performance", in a way. Then there is "Component-Based: Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state out of the DOM.". Making a complex UI by composing simple parts again sounds like composing functions in functional programming. "Encapsulated components that manage their own state" feels more like OO though. I can also add that the React community uses Redux a lot, which was inspired by Elm, which itself is clearly functional programming. I've heard that hooks are a way to get closer to functional programming, but I can't confirm this, as I haven't used them. As a conclusion, I'd say that yes, React share values with functional programming, though it doesn't strive for purity (in both senses of the word). So, again, is React functional? Yes, I'd say it is. What does it mean to be functional? I think a good example here would be OCaml. OCaml is a functional programming language. OCaml also allows you to do imperative programming, or object-oriented programming. However, in the wild, most of the OCaml code you find is functional. How functional? That depends. For some people it will mean functions and data structures. For some it will be this with modules. For others, that will be monads. So in general, maybe a bit less functional than Haskell, but more functional than Python or Java. That's the same with React. When we say "React is functional", we mean "probably a bit less functional than Elm, but more functional than Angular and Vue". You're using "functional" in a very specific way, which is usually covered by "pure" or "purely functional", which is unproductive to these kind of conversations.
- eyelidlessness 5y ago
  > If you don't care about purity don't use FP. This is unhelpful. I don’t know if I’ve ever encountered this attitude before, I’m enthusiastic about FP and I frequently direct people toward FP principles wherever I possibly can. Dissuading application of those principles in part because they’re not applied in (your view of) full is sending people in the wrong direction. And you might not care, but I do: it’s also gatekeeping. Making people feel like what they’ve learned to make their code more functional, less side-effecting, and generally easier to reason about… making them feel like that’s not important progress they can value unless they share your knowledge and understanding of Category Theory or whatever is going to drive people away from what you want. And it’s going to drive marginalized people away most, probably from programming in general. That stinks. The level of purity you’re demanding isn’t even claimed by most functional languages. And the ones which do use Monads as a sleight of hand to make the claim, but that’s plainly a useful fiction.
  - flowerlad 5y ago
    > > If you don't care about purity don't use FP. > This is unhelpful. You have to care about purity. The benefits of FP hinges on this. Saying you don't care about purity is the same as saying you don't care about FP. That doesn't mean that anything less than "perfect purity" is worthless. You have to always aim for purity, even if you don't always achieve it, because without it there is no FP.
    - eyelidlessness 5y ago
      > That doesn't mean that anything less than "perfect purity" is worthless. This is more helpful. I’m not going to add my own unhelpful reaction to the rest of what you said, I think I already added more value above than I’m inclined to now.

dtech 5y ago

> Functional programs are constructed using only pure functions If that's your definition, functional programs basically don't exist in the real world. Wikipedia (and I) don't agree with that [1], it specifically separates out pure FP [2]. [1] https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming [2] https://en.wikipedia.org/wiki/Purely_functional_programming https://en.wikipedia.org/wiki/Purely_functional_programming

flowerlad 5y ago
You didn't read the article. How to deal with impurity is described in the article.

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.

bryik 5y ago

> There is nothing functional about React. There is literally an example React component in that article that the author calls "pure and referentially transparent". How can this be if there is "nothing functional about React"?

flowerlad 5y ago
But how many React components are that simple? Almost none.