The do notation is just imperative sugar over a functional core. Haskell doesn't pretend to be imperative.
Compare that to React which has a somewhat functional appearance (skin) over an essentially imperative core. React pretends to be functional.
When you compile your pure Haskell code the resulting machine code is imperative and effectful. What's more, Haskell compiler (GHC) is partly written in imperative languages like C. From your strict point of view that probably make it an impostor that pretends to be functional while having imperative core. ;)
React doesn't pretend to be functional. It clearly states that it is influenced by functional programming concepts and this is reflected in its API.
React can't have a fancy functional syntax that could please every purist because it isn't a compiled language but a view library.
Yes, a library. A library is just a bunch of code providing some functionality that can be shared and used easily in many applications. React fulfills that definition. It also fulfills the definition of a framework so you can call it a view framework if you wish, but "view framework" name is kind of already taken by another project.
But if you see a sentence:
React is not a framework like Angular but just a library for building user interfaces
and all you get from it is that "React is not a framework" then it's not the sentence that's wrong - it's your interpretation of the sentence.
In many ways React's true nature is best revealed by createReactClass (formerly React.createClass).
Even the naming is awkward — it really should have been React.createComponent - but to seem more current they went with Class in ES5 to seem more respectable in context of a OO mainstream.
It's called createClass because it creates a class. It was needed because creating creating classes in ES5 is really awkward.
useState() serves to have former component invocations affect later invocations and more importantly allows the "outside world" to have an effect on the component instance state.
useState() serves the same purpose as State Monad. The difference here is that state management is pushed out of your Haskell code and managed outside (Haskell compiler does the dirty work). React is just a bunch of JS code so the state is still kept within the realm of JavaScript. But no, "outside world" cannot directly change the state - even a component can't do it directly - all state changes must have to go through React setState call and only React can change it. React guards the access to component state in similar way as Haskell guards access to State Monad.
Even if this happens somewhat under the control of React there is no rigidly enforced compile and run time contract like there is with, for example, the IO monad.
Yes, it's not Haskell, it's JS so you still can do some weird stuff but React is rigid enough and doesn't give you many options to mess things up.
Hooks make functions impure and are just a React specific mechanism for code organization and perhaps reuse - that's it and in that capacity they may be considered an abstraction of some sort.
Yeah, you can be very picky about functional programming and only recognize the following definition:
Functional programs contain no assignment statements, so variables, once given a value, never change. More generally, functional programs contain no side-effects at all. A function call can have no effect other than to compute its result.
The functional programmer sounds rather like a mediæval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing.
If I can have more or less the same benefits as in a pure functional language but without having to switch from the most universal and ubiquitous language in the world that's a pretty good deal for me.
When you compile your pure Haskell code the resulting machine code is imperative and effectful.
And during the compilation process the code is verified to comply with numerous constraints that permit the compiler to make some very specific and beneficial assumptions about the code.
React doesn't pretend to be functional.
I think here we have to differentiate between React and the React community. Now clearly React itself can't be responsible for the entire React ecosystem - but often the wording in the documentation or the statements by core members encourage certain notions in the community.
React's mental model is often oversimplified as view = fn(state) — which is clearly functional as it implies view generation from state through transformation by a pure function.
React actually doesn't work that way — there are two sources of state — props which is state as handed down from the owner component to the nested component and state which is "persisted and managed" by React on behalf of the component instance. So while components do generate the view they also can change state in the process - i.e. components are not enforced to be referentially transparent or in web terms idempotent. So React cannot grant the typical benefits or guarantees that a typical FP environment can.
React's reliance on immutability further feeds into the image of being functional.
Then there is the fact that the community often refers to Function Components as Functional Components.
So when it comes right down to it, one has to wonder how much of "hooks and stateful function components" actually had to do with necessary innovation or whether or not the whole "functional image" is about keeping React trendy within the web development community at large.
but "view framework" name is kind of already taken by another project.
React predates Vue by about a year and despite its name Vue doesn't get to monopolize an entire tool category by virtue of how its name sounds.
all you get from it is that "React is not a framework" then it's not the sentence that's wrong - it's your interpretation of the sentence.
@jpochtar@reactjs@angular I think React is a UI library. It’s possible that our definition of “UI” might be a bit broader than what people tend to consider “view layer”, but I also think it’s not a framework.
19:12 PM - 09 Aug 2018
but I also think it’s not a framework.
It's not my interpretation, it's an active image being defended by a large portion of the React community. A framework, due to inversion of control, exerts a significant amount of design pressure on the structure of the "client side architecture". Calling React a library is disavowing the influence that React has as evidenced by countless sources describing React as unopinionated. Just because React is less constraining than Angular does not imply that it is "unopinionated" — it's just a matter of degree — React is very much opinionated, just not as much as Angular.
It was needed because creating classes in ES5 is really awkward.
Did it return a constructor function? A factory function for component instances? At best it's bad naming because createComponent would have been more apt — at worst it's trendy naming because in 2013 "real programmers" used class-based object-orientation — not just plain functions and objects.
Generators are pure functions as long as you don't mutate state within them.
Most generators used in JavaScript are not pure. And JavaScript has no controlled runtime support for lazy evaluation, so lazy evaluation is emulated with mutable state inside the function's closure.
useState() serves the same purpose as State Monad.
"Purpose" perhaps but again without committing to any constraints. In order to preserve referential transparency functions operating within a state monad have a signature of (state) => [state, result]. React function components could have easily adopted a similar signature. One benefit would have been that it would be trivial to micro test components without having to provide an entire "React environment" for the component to run in.
And that's just the point — React does just enough to pander toward maintaining a "functional image" but doesn't commit to the necessary constraints that would afford developers the actual benefits of many FP techniques.
But no, "outside world" cannot directly change the state
Of course it can - that is the whole principle of how third party libraries like Redux integrate themselves with the React component tree — especially since the introduction of hooks. And even before that the "outside world" invaded the component tree via Higher Order Components (connect, Provider pattern) which are all still "React Components".
React guards the access to component state in similar way as Haskell guards access to State Monad.
There is no "guarding" of any constraints.
It maintains control for the purpose of detecting changes to component instance state and to maintain full control over view reconciliation and scheduling.
If I can have more or less the same benefits as in a pure functional language but without having to switch from the most universal and ubiquitous language in the world that's a pretty good deal for me.
The functional programmer sounds rather like a mediæval monk,
Frankly, I couldn't care less if React was functional or not — but I am getting tired of the pretentiousness exuded by it and a significant part of it's community.
For example wickedElements is not functional in nature at all but it is brilliant in the way it leverages JavaScript and the DOM ("the platform"). It is what it is and it is good at at it.
Meanwhile there seems to be a cult-like following around React unwilling to examine and evaluate the tool objectively but instead is willing to propagate half-truths:
React is unopinionated — due to inversion of control it has a definite opinion, just not as severe as Angular.
React is functional in nature — it uses functions. So does the C language, neither of them is functional in the FP sense.
React is declarative — it manipulates the DOM so you don't have to. Meanwhile there are no benefits of declarative programming, it's just the usual BBoM; i.e. it's just an excuse to avoid learning how to manipulate the DOM or use something else that actually leverages the browser's strengths.
Alex Russell
@slightlylate
I'm not saying React was a mistake, exactly, but its apologists need to reckon honestly what it has done to the ecosystem. twitter.com/TheRealNooshu/…
09:57 AM - 29 Aug 2021
Matt Hobbs
@TheRealNooshu
@slightlylate @AndyDavies @samthor
That image tells quite a story doesn't it. That poor Moto G4 user! 😬 https://t.co/2CvGSowwqh
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When you compile your pure Haskell code the resulting machine code is imperative and effectful. What's more, Haskell compiler (GHC) is partly written in imperative languages like C. From your strict point of view that probably make it an impostor that pretends to be functional while having imperative core. ;)
React doesn't pretend to be functional. It clearly states that it is influenced by functional programming concepts and this is reflected in its API.
React can't have a fancy functional syntax that could please every purist because it isn't a compiled language but a view library.
Yes, a library. A library is just a bunch of code providing some functionality that can be shared and used easily in many applications. React fulfills that definition. It also fulfills the definition of a framework so you can call it a view framework if you wish, but "view framework" name is kind of already taken by another project.
But if you see a sentence:
and all you get from it is that "React is not a framework" then it's not the sentence that's wrong - it's your interpretation of the sentence.
It's called
createClassbecause it creates a class. It was needed because creating creating classes in ES5 is really awkward.useState()serves the same purpose as State Monad. The difference here is that state management is pushed out of your Haskell code and managed outside (Haskell compiler does the dirty work). React is just a bunch of JS code so the state is still kept within the realm of JavaScript. But no, "outside world" cannot directly change the state - even a component can't do it directly - all state changes must have to go through ReactsetStatecall and only React can change it. React guards the access to component state in similar way as Haskell guards access to State Monad.Yes, it's not Haskell, it's JS so you still can do some weird stuff but React is rigid enough and doesn't give you many options to mess things up.
Yeah, you can be very picky about functional programming and only recognize the following definition:
But this makes you like this:
If I can have more or less the same benefits as in a pure functional language but without having to switch from the most universal and ubiquitous language in the world that's a pretty good deal for me.
And during the compilation process the code is verified to comply with numerous constraints that permit the compiler to make some very specific and beneficial assumptions about the code.
I think here we have to differentiate between React and the React community. Now clearly React itself can't be responsible for the entire React ecosystem - but often the wording in the documentation or the statements by core members encourage certain notions in the community.
React's mental model is often oversimplified as
view = fn(state)— which is clearly functional as it implies view generation from state through transformation by a pure function.React actually doesn't work that way — there are two sources of state — props which is state as handed down from the owner component to the nested component and state which is "persisted and managed" by React on behalf of the component instance. So while components do generate the view they also can change state in the process - i.e. components are not enforced to be referentially transparent or in web terms idempotent. So React cannot grant the typical benefits or guarantees that a typical FP environment can.
React's reliance on immutability further feeds into the image of being functional.
Then there is the fact that the community often refers to Function Components as Functional Components.
So when it comes right down to it, one has to wonder how much of "hooks and stateful function components" actually had to do with necessary innovation or whether or not the whole "functional image" is about keeping React trendy within the web development community at large.
React predates Vue by about a year and despite its name Vue doesn't get to monopolize an entire tool category by virtue of how its name sounds.
It's not my interpretation, it's an active image being defended by a large portion of the React community. A framework, due to inversion of control, exerts a significant amount of design pressure on the structure of the "client side architecture". Calling React a library is disavowing the influence that React has as evidenced by countless sources describing React as unopinionated. Just because React is less constraining than Angular does not imply that it is "unopinionated" — it's just a matter of degree — React is very much opinionated, just not as much as Angular.
Did it return a constructor function? A factory function for component instances? At best it's bad naming because
createComponentwould have been more apt — at worst it's trendy naming because in 2013 "real programmers" used class-based object-orientation — not just plain functions and objects.Most generators used in JavaScript are not pure. And JavaScript has no controlled runtime support for lazy evaluation, so lazy evaluation is emulated with mutable state inside the function's closure.
"Purpose" perhaps but again without committing to any constraints. In order to preserve referential transparency functions operating within a state monad have a signature of
(state) => [state, result]. React function components could have easily adopted a similar signature. One benefit would have been that it would be trivial to micro test components without having to provide an entire "React environment" for the component to run in.And that's just the point — React does just enough to pander toward maintaining a "functional image" but doesn't commit to the necessary constraints that would afford developers the actual benefits of many FP techniques.
Of course it can - that is the whole principle of how third party libraries like Redux integrate themselves with the React component tree — especially since the introduction of hooks. And even before that the "outside world" invaded the component tree via Higher Order Components (connect, Provider pattern) which are all still "React Components".
There is no "guarding" of any constraints.
It maintains control for the purpose of detecting changes to component instance state and to maintain full control over view reconciliation and scheduling.
So the the Curse of the Excluded Middle is just Erik Meijer ranting again? And he can rant.
Frankly, I couldn't care less if React was functional or not — but I am getting tired of the pretentiousness exuded by it and a significant part of it's community.
For example wickedElements is not functional in nature at all but it is brilliant in the way it leverages JavaScript and the DOM ("the platform"). It is what it is and it is good at at it.
Meanwhile there seems to be a cult-like following around React unwilling to examine and evaluate the tool objectively but instead is willing to propagate half-truths: