11 ms·

> Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript The whole thing has been functional programming from the

> Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript 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. Hell, the original React prototype was in Standard ML, later ported to OCaml and then JavaScript. > Throwing Promises for Suspense is basically Algebraic Effects The fact that you disregard Suspense as a head-scratching algebraic effect, instead of using simple "Promises" goes to show how much the JavaScript ecosystem seems to be about fooling people into doing functional programming without triggering their gut reaction of "FP is spooky unproven thing, but Node enterprise ready!". Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M" and it's just a monoid in the category of endofunctors.

flowerlad 5y ago
> 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.
- 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.
tshaddox 5y ago
Yeah, but if you are opposed to functional programming (or opposed to exposure to any new programming paradigms) of course you’ll hate the library that has had perhaps the largest impact in bringing concepts from functional programming into the mainstream. That’s perfectly understandable. But I like functional programming and I very much like React’s impact in this area.
- dexwiz 5y ago
  Using Functional Paradigms in a FP language. Cool! All for that. Bootstrapping pseudo FP styles into a Prototype Language with no types (JS is technically not OO, even `class` is just prototype sugar). Please no. I really like concepts behind FP. I have tinkered with Haskell and gone through Bartosz Milewski's Category Theory material. That said, its radically different than traditional Procedural or OO coding. It really needs language level support to be useful, and that usually starts with types and the compiler. Open up "FP" libraries in non FP languages, and you often discover its just the same objects as the rest of the language. That said, immutability is awesome. The concept of creating mutability boundaries and only exposing immutable data to external services and clients solves a whole class of bugs related to "who changed that?"
eyelidlessness 5y ago
> Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M" and it's just a monoid in the category of endofunctors. I think many of us familiar with the FP inspiration for language features like Promise also understand that it’s a Monad. But this is a weird response to a comment about the oddity of throwing a Promise. I may be mistaken, but it seems unusual (in the FP analogue) to return an Either<Future<B>, A>, and even weirder to obfuscate that in a seemingly synchronous interface to trick you into thinking you’re returning A | B.
- nsonha 5y ago
  > this is a weird response to a comment about the oddity of throwing a Promise which actually has nothing to do with functional programming, it's just sloppy programming This is because this person is one of those clowns who learnt one thing about functional programming and use that in every conversation to deflect criticism without much understanding of the criticism > Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M"
  - eyelidlessness 5y ago
    > which actually has nothing to do with functional programming, it's just sloppy programming I’m really cautious to agree here. We’re talking about something that’s increasingly core to React’s design (you don’t throw Promises yourself, the internal APIs do, and it’s documented that way so other libraries can interop). It’s a weird design but I don’t think I could call it sloppy. > This is because this person is one of those clowns This is also unhelpful. I hope we can get better at critiquing without attacking the person, even where we disagree with them.
    - nsonha 5y ago
      > I don’t think I could call it sloppy Instead of comming up with new API they retrofit existing one (the render function) to add continuation passing. They use throwing and promise, neither is for continuation passing. Somewhere in this thread there is a link to the crankjs article which does the same thing using a generator-based API. It is also weird from a conventional point of view but at least simpler and somewhat more intuitive > better at critiquing without attacking the person How would you critique an attitude (pretentiousness and unhelpfulness) without attacking the person? This is a shitty trait and you have it but do not feel offended?

flowerlad 5y ago

> 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.
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.

tshaddox 5y ago

Yeah, but if you are opposed to functional programming (or opposed to exposure to any new programming paradigms) of course you’ll hate the library that has had perhaps the largest impact in bringing concepts from functional programming into the mainstream. That’s perfectly understandable. But I like functional programming and I very much like React’s impact in this area.

dexwiz 5y ago
Using Functional Paradigms in a FP language. Cool! All for that. Bootstrapping pseudo FP styles into a Prototype Language with no types (JS is technically not OO, even `class` is just prototype sugar). Please no. I really like concepts behind FP. I have tinkered with Haskell and gone through Bartosz Milewski's Category Theory material. That said, its radically different than traditional Procedural or OO coding. It really needs language level support to be useful, and that usually starts with types and the compiler. Open up "FP" libraries in non FP languages, and you often discover its just the same objects as the rest of the language. That said, immutability is awesome. The concept of creating mutability boundaries and only exposing immutable data to external services and clients solves a whole class of bugs related to "who changed that?"

eyelidlessness 5y ago

> Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M" and it's just a monoid in the category of endofunctors. I think many of us familiar with the FP inspiration for language features like Promise also understand that it’s a Monad. But this is a weird response to a comment about the oddity of throwing a Promise. I may be mistaken, but it seems unusual (in the FP analogue) to return an Either<Future<B>, A>, and even weirder to obfuscate that in a seemingly synchronous interface to trick you into thinking you’re returning A | B.

nsonha 5y ago
> this is a weird response to a comment about the oddity of throwing a Promise which actually has nothing to do with functional programming, it's just sloppy programming This is because this person is one of those clowns who learnt one thing about functional programming and use that in every conversation to deflect criticism without much understanding of the criticism > Imagine for a second that a Promise's .then is called .bind, put it in a thunk if you want to be extra precise and tell me what it is. Hint: It starts with "M"
- eyelidlessness 5y ago
  > which actually has nothing to do with functional programming, it's just sloppy programming I’m really cautious to agree here. We’re talking about something that’s increasingly core to React’s design (you don’t throw Promises yourself, the internal APIs do, and it’s documented that way so other libraries can interop). It’s a weird design but I don’t think I could call it sloppy. > This is because this person is one of those clowns This is also unhelpful. I hope we can get better at critiquing without attacking the person, even where we disagree with them.
  - nsonha 5y ago
    > I don’t think I could call it sloppy Instead of comming up with new API they retrofit existing one (the render function) to add continuation passing. They use throwing and promise, neither is for continuation passing. Somewhere in this thread there is a link to the crankjs article which does the same thing using a generator-based API. It is also weird from a conventional point of view but at least simpler and somewhat more intuitive > better at critiquing without attacking the person How would you critique an attitude (pretentiousness and unhelpfulness) without attacking the person? This is a shitty trait and you have it but do not feel offended?