And monads are impure [1]. If all your functions are impure then you're not doing functional programming.
[1] https://alvinalexander.com/scala/io-monad-doesnt-make-functi...
Not necessarily. The IO Monad (Haskell et al.) is impure, a monad is just a functional abstraction that doesn't have anything to do with purity at all.
Disagree. It is in fact the defining characteristic of functional programming.
Ed: and I suppose if a function call allocates a stack frame it's no longer a pure function? Or are all functions of type crash-or-value?
That's to say, at a certain point, all this is arbitrary.
Pure code is generally easier, but a program that's only pure code is pretty useless. You always need an escape hatch which is what some monads like IO or Futures provide. Monads and other functional paradigms allow us to write and interact with impure code in a pure way and mindset. That's exactly what hooks do as does the react mindset of, your view is a function of state.
Hooks easily let us separate that statefulness into their own abstraction - just as futures do for async calls, and IOs do for the file system. This lets us model our view as a function of state (and props which are just arguments to a function)
No. You can't interact with impure code "in a pure way". That makes no sense whatsoever.
I don't think you read the article I linked to earlier. Here it is again: https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
You need state to do anything useful. A lot of functional programming revolves around the idea of isolating impure aspects of a language from the pure parts.
That's why we have Futures, IOs, Options, Eithers etc.
No one is saying they are pure, the types are an indicator that something impure is happening. They are abstractions that allow us to pretend they're pure and work with them regardless of the context of the type.
I can map over a Future, IO, or Option regardless of whether the Future resolved, the IO was successful, or the Option contains a value.
That's a functional mindset where the impurity is isolated to the data type and methods are exposed on the type that lets us ignore certain possibilities.
I don't care about the context when I map over one of these types, whether its a Future, Option, Array, IO etc. I can write my pure function and pass it off to map. Who cares if the Future really contains an error, the Option is None, or the Array is empty. Map handles all those cases for me and lets me interact with these impure aspects in a pure way.
The function I define and pass to map is pure and lets me interact with impure parts of the code in a pure way.
useState and useEffect should be thought of in the same way. Clearly it denotes something impure is happening, but the stateful value can be treated like a state machine that can be declaratively tested against a finite list of possible states.
In the case of a Promise, it's successful, pending, or error. For an Option its Some<T> or None. Etc etc.
If my hook returns 3 values, result, isPending, error (and if you really want, each value can be an option), I can easily handle each scenario deterministically.
That allows for pattern match like solutions (in JS it can be through cases clauses since there's no FP pattern matching).
This allows for writing components in a pure like approach even when its obviously impure.
There is really no need shoehorn something that's not a good fit for FP into the FP paradigm. It is not like customers are going to pay more money if it is FP. So don't bother.
[1] Mostly useless aside: using a .then()able based plumbing would have opened up the possibility of using the async/await combinator language. The names async/await would give the wrong impression especially prior to the actual concurrency changes to eventually ship in React 18, but would have potentially been a more monadic fit.