3 ms·

> The hooks follow similar laws to Monads. And monads are impure [1]. If all your functions are impure then you're not doing functional programming. [1] https

> The hooks follow similar laws to Monads. 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-function-pure-obvious-impure/ https://alvinalexander.com/scala/io-monad-doesnt-make-functi...

WorldMaker 5y ago
Yes, I stated that. Those functions are impure. Purity is a lovely goal, but purity also isn't a defining characteristic of functional programming, it's a modern pursuit. I've met enough classic LISP practitioners that lived their whole programming lives in the most impure of functional programming, that I would never want to tell them to their face that what they did didn't count as functional programming because of all the leaky impurity in LISP (due to pragmatic considerations of the time).
- flowerlad 5y ago
  > purity also isn't a defining characteristic of functional programming Disagree. It is in fact the defining characteristic of functional programming.
  - e12e 5y ago
    It may be defining of pure functional programming. But not for "functional programming". Some arguments for why (and indeed some discussion for why not, too !) : https://wiki.c2.com/?FunctionalProgramming https://wiki.c2.com/?FunctionalProgramming 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?
1_player 5y ago
> monads are impure 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.
bern4444 5y ago
If you get really technical, any program is impure as running the code has the side effect of increasing the temperature outside the cpu from running the program. That's a side effect. And running a program is going to change the temperature in a different way each time 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)
- flowerlad 5y ago
  > Monads and other functional paradigms allow us to write and interact with impure code in a pure way and mindset. 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-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
  - bern4444 5y ago
    It lets us think like that despite it not being true. 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.

WorldMaker 5y ago

Yes, I stated that. Those functions are impure. Purity is a lovely goal, but purity also isn't a defining characteristic of functional programming, it's a modern pursuit. I've met enough classic LISP practitioners that lived their whole programming lives in the most impure of functional programming, that I would never want to tell them to their face that what they did didn't count as functional programming because of all the leaky impurity in LISP (due to pragmatic considerations of the time).

flowerlad 5y ago
> purity also isn't a defining characteristic of functional programming Disagree. It is in fact the defining characteristic of functional programming.
- e12e 5y ago
  It may be defining of pure functional programming. But not for "functional programming". Some arguments for why (and indeed some discussion for why not, too !) : https://wiki.c2.com/?FunctionalProgramming https://wiki.c2.com/?FunctionalProgramming 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?

1_player 5y ago

> monads are impure 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.

bern4444 5y ago

If you get really technical, any program is impure as running the code has the side effect of increasing the temperature outside the cpu from running the program. That's a side effect. And running a program is going to change the temperature in a different way each time 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)

flowerlad 5y ago
> Monads and other functional paradigms allow us to write and interact with impure code in a pure way and mindset. 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-b1ed12a41323 https://mckoder.medium.com/why-react-is-not-functional-b1ed1...
- bern4444 5y ago
  It lets us think like that despite it not being true. 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.