Pure functional programming is always about purity, functional programming is about first class functions. Pure functional programming is a subset of functional programming, not the other way around.
I'm not really sure where you are getting your information from but everything that I have read disagrees with this idea that functional programming is about purity.
I think in recent times the term functional programming has been overloaded to mean what you describe, and many people use it that way, but I don't think it should be used that way.
Maybe we should just say "non pure functional" or "pure functional" so it's always clear what we are talking about!
My point is that the definition of functional programming is this purity you mention not using first-class functions. Pure means that something has more of that thing you want and impure means it has less - so pure functional programming has more 'functional programming' then 'standard functional programming'. Sure completely pure functional programming is impractical - there are degrees to how purely functional are the languages we use in practice - but this is the point practical languages are more or less functional and how much are they functional depends on how much they depend on state manipulation not on using higher order functions or having first class functions.
Defining functional programming as programming with first-class functions is a consistent definition and could be used if not the fact that more people use the other definition (at least that is what the wikipedia definition and other online material makes me believe).
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.
Sorry, but you're missing the forest for the trees. This is what wikipedia has to say: "Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming"[0]
In FP as an umbrella, purity is not a hard requirement for the entire paradigm, only a predominantly pipeline oriented style based around expressions is (in contrast to, say, C, where one generally passes a pointer to the same state around to procedures that pick and choose what to modify in that state bag, as a series of statements). Common Lisp and OCaml are often cited as examples of functional languages that don't attempt to enforce purity guarantees even in terms of idiomatic usage, let alone at a compiler-enforced level.
Using higher order functions for, say, promises (remember, they're stateful!) doesn't mean you're not using functional programming, just like using Array.prototype.map doesn't mean you're not using OOP (it implements fluent interfaces, if you haven't noticed). It's the absence of functional tools/techniques that qualifies a program as not functional.
IMHO, the unfortunate situation is that most JS people don't understand there are different degrees of functional-ness and certain guarantees only exist within specific subsets (and React doesn't conform to that subset).
I'll talk about Erlang for example. Functional purity is objectively beautiful because it solves or minimizes a large number of typical problems. These problems such as large mutable states, large mutable state modifications during high levels of concurrency. A good functional language, using closures can mimic other patterns while having a very small core set of rules.
Purity doesn't mean moral superiority (although it sounds like) purity means referential purity for example, where the function when called no matter how many times with the same argument returns the same result. That is beautiful because it allows for interesting compiler optimizations, good for testing. Other looser explanations of purity are -- confinement of mutable state (this could mean monads in Haskell modifications to shared global state), immutable data structures in Erlang or Clojure.
Now that said these are all tools. As I mentioned, in practice, a lot of these people in their day job will end up using Java or C++. But the fact that they decided and managed to learn a new paradigm is what is the key.
Heck it could have been data-flow programming or logic programming (Prolog is awesome too, especially when mixed with constraint satisfaction).
Yet another way of putting it, familiarity with these things point to a level of passion and sets someone apart, that is quite desirable. Now, yes, there is a self-referential quality to it all, the more we think functional programming is a proxy for developer quality, the more people will do tutorials just to put it on their resume. Well, then the next fashion will be something else -- quantum algorithms perhaps, who knows.
Functional programming is simply the obsession with functions: the use of the function call, and indirection on functions, as the only control mechanism.
Functional programming emphasizes recursion, deferral of control decisions into functions (e.g. pass functional arguments to some function, and let it decide which are called and which are not), and the re-ification of all control mechanisms as functions (e.g. continuations).
If it has loops, ifs and gotos, it is not functional. If it just has function calls, then it's functional, even if there is mutation going on of variables or array elements and such.
Purity plays well into functional programming, because if we have structured the control flows in the program based on function calls, we can determine which functions are pure and which are not, and get a good grip on reasoning about and managing the side effects to avoid surprises.
Functional programming DOES NOT PERMIT mutability or side-effects.
I think the word you don't realize is missing there is "Pure".
Pure functional programming, and pure functional style, is everything you think functional programming and functional style are. Purity is precisely the technical requirement that constrains a function to not have side-effects and to not mutate data. If, as you say, functional programming did not permit mutability, the term "pure functional programming" would have been meaningless.
But functional programming is not, and has never been, solely pure functional programming; and despite the positive connotations that the word "pure" commonly evokes, functional programming with mutable data is not some kind of inferior version of pure functional programming, a poor distant relative fresh from the provinces come to beg favors from a wealthy merchant. No. This belief commonly stems from ignorance of the history of functional languages coupled with wide-eyed admiration of an especially elegant pure functional idiom recently learned.
Some people believe that the purer the better (this belief has only gained popularity relatively recently, in fact), others think that mutable state is just fine where it helps rather than hinders. Both kinds of people happily write functional programs using functional programming languages.
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).
> The functional aspects mean every function has no side effect.
This is not accurate. Any function can print, can call a DB or a web service.
"Purity" (as in referentially transparent) is tangential to function programming. It can be achieved with other paradigms. That being said, functional programming does encourage it.
Functional programming used to mean programming with first class functions and closures; they even put it in the name "functional"al programming (just like OOP meant program with objects, whether this involved classes or not).
So that is Lisp, the first FP in the 60s, and then the MLs of the 70s/80s. They knew about purity, and even preferred it (for things like list comprehensions, it is very useful), but were never very dogmatic about it.
A language need not force purity to allow for purely functional programs. Besides, purely functional languages all need a way to cheat to actually do anything useful. Any nontrivial program needs a mix of paradigms.
Purity is a false idol. CL is a functional programming llanguage. Functional as in programming with functions. Maintenance of referential transparency is the duty of the programmer. As long as you have HOFs and some form of lexical closure as basic language features, you can call a language functional. tail-call optimization, default immutability, automated structure cloning, parameteric datatypes, default currying and h-m type inference are language features that make mathematical reasoning easier, but they are neither essential nor definitive requirements of a functional programming language.
In my opinion the most important part of functional programming is the purity of functions. There is a great quote about this on one of the Clojure doc pages
"If a tree falls in the woods, does it make a sound?
If a pure function mutates some local data in order to produce an immutable return value, is that ok?"
Function purity enforces that mutations are localized to small areas of the code, while maintaining composition.
Functional programming means functions are first class citizens and can be constructed on the fly. Modern python, c++, rust, even java now do this.
Purity is a nice to have (and arguably rusts borrow system enforces a kind of purity).
reply