While studying functional programming, I quite heard the term "pure function", or pure function . What characterizes this type of function and what is its importance for the functional paradigm?
Without locking up the functional programming issue, I did not understand what this kind of function might bring to advantage. What are the pros in writing pure functions? Should a pure function depend only on its parameters alone?
A pure function is one that does not cause side effects, that is, it does not change any state in the application. But not only this, it must always generate the same result with the same arguments, that is, it must be completely deterministic.
The philosophy of functional programming is that changeable states cause problems. And it's true, it's the cause. Of course, to always have states that do not change generate other problems. Note that it is virtually impossible to create an application that does something useful without some change of state.
If the result of a function is always expected, it is easier to handle that function.
So its use has to do with facilitating development, even if this eventually causes a loss of performance. This is why most pragmatic languages use immutability when it is really useful and does not bring other problems.
One of the difficulties of an impure function is that it can only be used in other impure functions since an impure contaminates the pure.
When the function only generates a deterministic result and does not change state, it is easier to understand its operation, the flow of operations is more predictable, it is easier to debug and test the code, it is necessary to debug less code since it tends to have less errors, it's much easier to deal with concurrency and parallelization, and it's easier to do complex things given its simplicity, which even allows for aggressive optimizations.
Contrary to what many people think is not the algorithm that is difficult to handle is the data structure. She's the one who always gives trouble. It is not the behavior but the state. Unless the algorithm is too complex and badly done.
So many people think that OOP is the eighth wonder of the world. It tends to facilitate the best data structure (although most people understand it wrong and make it more difficult to make it easier, and that is not well OOP, but rather the modularization that does this occur ), but OOP still preaches the state mutation, preaches the behavior to change the state.
Functionalists consider OOP to be crap because the state changes a lot. Pragmatists know when to use every thing. And for this you have to understand what you are doing, which is not easy because there is no cake recipe and there is a lot of information that needs to be combined to make the right decision.
So we should prefer the state that does not change whenever this does not cause other problems, of performance, for example. We should prefer behaviors that do not change state and that do not use states that can change, these behaviors are pure.
A function that accesses something external to the application can not be pure. Any data entry (read keyboard, access storage, receive network packet, access another application, ask something for the operating system like clock, etc.) or any calculation that depends on the state of something that the application does not control and does not can guarantee that the state is always the same (true random generation is the greatest example of something that must give a result that depends on a nondeterministic state, has a random function that is deterministic, although it must be used specifically to be pure) . To help deal with this the functional languages have monads .
Mathematical functions are generally pure. What works with value types passed by value is usually pure, what works on something by reference that is an immutable object is usually pure.
Academically you usually assign these characteristics to a pure function:
