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.
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.
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.
> 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.
I think you have to start by answering this question:
What is the benefit of being functional?
If there is no benefit then this whole discussion is moot. If there is a benefit to FP that isn't easily achievable using other styles, then does React achieve that benefit by doing FP style?
Or is React leaning on the cachet of FP for marketing purposes?
For React, the idea is building the UI as a function of the state. The benefit is to make the code easier to understand, debug, test, etc. I don't think I have to discuss with your the benefits of pure functions.
> If there is a benefit to FP that isn't easily achievable using other styles, then does React achieve that benefit by doing FP style?
I think it does, partially. Though it isn't going as far as something like Elm.
> Or is React leaning on the cachet of FP for marketing purposes?
I would almost say the opposite, React succeeded at first because it didn't push too much the functional stuff. Elm went farther, and doesn't have the market share of React, because insisting too much on FP, especially at that time, would only scare away developers. If you start to go the FP path, at some point you realize that using JavaScript can't work, and you have to switch to something new. People have experience and huge codebases, so they don't want to switch. You can see the same with TypeScript. TypeScript succeeded because it embraced JavaScript, especially its flaws. That means that as standalone language, TypeScript isn't as good as it could be. But as an incremental improvement in the JavaScript ecosystem, it's good, very good.
To see what happens when you use FP for marketing purpose, you can take a look at ReScript, the current reincarnation of ReasonML.
> To see what happens when you use FP for marketing purpose, you can take a look at ReScript, the current reincarnation of ReasonML.
Reason has always felt weird and half-baked. It had all that nice syntactic sugar for the benefit of javascript developers — but in the middle of it, there was some OCaml ugliness, like different math operators for integers and floats, or special treatment of recursive functions. Plus a half-baked async story, or lack of unicode support. It was all very weird.
But in other areas: I understand Swift was a great marketing success, and it is heavily influenced by FP, right (I haven't used it personally, so don't know). And so was Kotlin?
I agree, I like OCaml, I like JS, I'm not a fan of Reason. It just feels off somehow, and half-baked.
From my limited exprience in Swift, it does have functional parts, although I don't know if that's the main focus of the language, or just a nice thing to have.
Kotlin seems a bit more functional than Java, although Java has been catching up recently (sealed classes, pattern matching, record).
> For React, the idea is building the UI as a function of the state
Well, if you have state you're already not functional.
Look, React does not have to be functional to be useful! Let's not misappropriate the FP label and apply it to a tech that is clearly not functional, misleading a whole generation of developers.
> State will exist, whether you like it or not, and you'll have to deal with it.
Yes, state will exist... in a thin outer layer. Pure core with a thin impure outer layer. If state is distributed throughout the entire program then it is not 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.
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.
> 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.
