Hooks are not functional. The most elementary rule of functional programming is no state and no side effects. If you break these rules and justify your rule-breaking by pointing to esoteric concepts then you're violating the spirit of functional programming.
IO isn’t (typically) functional, and neither is the IO monad. But like reference types in Clojure, it’s how you express “the world is stateful, my program usually is not, but for this exceptional case my program interfaces with the world.” I don’t think React hooks are a good way to signal that, but they’re one of the ways people who prefer FP in real world use do it. I think Redux type solutions are a better signal in some cases, and the rare stateful class component has is better in others. I hope hooks don’t take over the React ecosystem, but if they do I’ll be looking for other solutions similar to earlier React with regular functions and stateful escape hatches.
IO isn't functional and that's the reason FP languages such as Haskell have a system for dealing with functions that have side-effects, that neatly separates the part of the program that is pure and the part of the program that is impure (and does all the dirty work like updating the screen). Impure parts of the program is fenced off from the pure parts. Pure functions cannot call impure functions.
The important part here is keeping portions of your code that has side-effects separate — and minimizing the amount of such code. If code that has side-effects is spread all over your program then you are not really using functional style.
> IO isn’t (typically) functional, and neither is the IO monad
"(pure) functional" is an attribute of expressions, not of concepts. Hence saying "the IO monad is not functional" does not make much sense.
a function that returns an `IO` type, which when executed performs a side-effect, is indeed pure functional though. Hence, react hooks are not pure functional, by the common definition of functional programming.
I don’t think I’ve ever seen anybody claim that hooks are ‘functional’
The fact that each time you call useState in a render method you get back a different value should be a clue.
You have to have a fairly sophisticated/twisted mental model of a react component’s function signature as effectively including each of the hooks it requires to be able to mentally model hooks as pure functions.
Hooks are a clever imperative hack that works only if you stay in the strict subset of JavaScript behavior that react expects, but which lets you get the benefits of some algebraic-effect-like contextual handling that would be easily expressed in a functional syntax, but they’re not functional.
Mind you, an OO person might equally say they are an imperative hack to get you the benefits of dependency injection that would be more easily expressed in an OO syntax, but they’re not OO.
What hooks are is more ‘imperative reactive’, I would suggest.
> I don’t think I’ve ever seen anybody claim that hooks are ‘functional’
That's not quite true. The linked story tries to explain Hooks as algebraic effects. Before Hooks, functional components were explained as "UI is a function of state". After Hooks, they are continuing on FP ideas as the justification or explanation of their design choices: https://overreacted.io/algebraic-effects-for-the-rest-of-us/
I'm not sure what the problem is with using functional ideas as a justification? It feels like you're complaining about a sort of cultural appropriation.
Functional ideas are sometimes good, and they should be borrowed and used in nonfunctional contexts. Like continuation-passing-style got lifted and used to inspire promises and async/await. That doesn't mean languages with async/await are functional, or that programming with async/await is taught as functional, it's just the pedigree of the idea.
React hooks lift some ideas from algebraic effects, and embed them in a decidedly nonfunctional, VERY non-pure-functional context. But the pedigree of the idea is still... algebraic effects.
I’ve personally never thought I was doing functional programming with React. I think of it more like borrowing from the functional programming paradigm to gain better control over state and corresponding UI behaviours and appearances, at least where it’s useful to do so, and otherwise it’s not very functional at all. It feels like a very borrowed term. There is heaps of non functional programming involved in React code bases.
> borrowing from the functional programming paradigm to gain better control over state and corresponding UI behaviors
That's an exercise in futility. If you are rendering read-only screens than you can use pure functions to render the screen. But if you need interactivity then attempting to add interactivity while using pure functions is counter-productive.
I am asserting it is counterproductive. In other words, the code will be convoluted and hard to maintain, which is the opposite of the goal of functional programming.
Pure functional languages such as Haskell have some facilities to do things that are not 100% pure, such as I/O. Similarly, OCaml has effects, but functional programmers minimize their use of such impure facilities.
Effects in OCaml are impure: "However, the effect system also allows for tracking side-effects more generally. It distinguishes impure functions, which perform side-effects, from pure functions, which do not." See: https://www.janestreet.com/tech-talks/effective-programming/
In Haskell impure functions are fenced off from pure functions. So for example, pure functions are not allowed to call impure ones.
If nearly all of the functions in your app are impure (and use React hooks) then you are definitely not doing functional programming.
I didn't think that OCaml had a way of distinguishing functions with side effects... the link you sent seems to describe a prospective extension/system, not a built-in of the language.
> In Haskell impure functions are fenced off from pure functions
That's a great way of explaining it. But at the same time how can we say that Haskell is a "pure functional language" when Haskell programs consist of both pure and impure functions?
Yes they are separated which in other words means you do have both of them. Is that really "pure" then? Or is that more like 'as pure as possible"?
According to this definition a pure programming language could not have any side effect (Not very useful). Maybe as pure as possible is the only interpretation that makes sense, then.
> 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. When a pure function is called with some given arguments, it will always return the same result, and cannot be affected by any mutable state or other side effects.
It is a closely associated idea, but it is not necessarily "core" to what FP is.
Why is it important to not mislead a whole generation of JavaScript programmers into believing they are doing functional programming when they're really not?
I'm not sure that they do. Just because Hooks was inspired by functional concepts like algebraic effects doesn't mean the core React team is suggesting that writing React code is functional programming.
With that said, my point is that it's more important what you can _do_ with a tool, rather than the purity of the tool with respect to an abstract concept. Or, in this case, with with respect to your interpretation of the abstract concept.
I don't think anyone is suggesting with a straight face that React code is purely functional -- this is JavaScript, after all! However, Hooks are a valuable feature, and if they were inspired by algebraic effects, then so be it.
A lot of React developers believe Hooks are functional and that they are doing functional programming by using Hooks. Whether the core React team is responsible for this perception or not I am not sure, but misleading developers about what functional programming is, is not cool.
Thanks to React Hooks a whole generation of JavaScript programmers are being misled into believing they are doing functional programming when they're really not. More on that here: https://medium.com/weekly-webtips/dysfunctional-programming-...