Then there is this general definition on Quora:
Functional programming is a paradigm which concentrates on computing results rather than on performing actions. That is, when you call a function, the only significant effect that the function has is usually to compute a value and return it. Of course, behind the scenes the function is using CPU time, allocating and writing memory, but from the programmer’s point of view, the primary effect is the return value. Objects in a functional programming language are often immutable (a.k.a. const or final); instead of changing an object, you allocate a new object which looks like the old one except for the change. Compare this with an imperative programming language like Java, where progress is made by changing objects’ fields, inserting them into sets, etc.
In a pure functional language, like Haskell, most functions are guaranteed by the type system not to perform any other actions. In an impure functional language, like ML, a function may have other side effects, such as querying a database or server, generating random numbers, reading or writing the disk, etc.
This definition is not wrong either – although I am not sure that dynamic typing makes a language impure. A pure function is one that, given the same input data, will always produce the same result.
We could read Wikipedia:
In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state andmutable data. It is a declarative programming paradigm, which means programming is done with expressions or declarationsinstead of statements. In functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) each time. Eliminating side effects, i.e. changes in state that do not depend on the function inputs, can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.
Functional programming has its roots in lambda calculus, a formal system developed in the 1930s to investigate computability, the Entscheidungsproblem, function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus.
Again, not wrong, but incomplete according to the purists (that word again) who consider strong typing a core aspect of the paradigm.
If we delve into lambda calculus, we see that Church’s original papers presented untyped (1936) and simply typed (1940) specifications. From my cursory scanning, I don’t think lambda calculus typing maps to strong typing in modern functional languages.
The biggest eye-opener for me (so far) was the concept of expressions instead of statements. I did not understand the implications until reading a paper by McCarthy on the origins of Lisp. I’ll take the reasoning off-line for now.
In Haskell a function has only one input and one output. This is conceptually elegant, but would be awkward without syntax help.
(ref add (lambda [first] (lambda [second] (+ first second)))
(ref result ((add 12) 7) ## is 19
In summary, in a functional programming language
- Function references can be passed to and returned from other function.
- Prefer expressions over statements.
- Support referential integrity (isolating state and I/O).
What can you add to this list?