Functional programming start from the point of view that the non-locality of changing variable values cause much more bugs than anything else. After all, the line that changes a variable can affect the flow at another line arbitrarily far - both textually or conceptually - a line that might not have expected its value to changed without its consent.

Said like this it might not sound very important source of bugs. However, keep in mind that one day, a group of computer scientist got pissed enough at that kind of bug that they went on on their anger and invented a whole new programming paradigm - that is no a small feat.

Very precisely, functional programming is coding in C++ with every variable marked as const. For example :

---- imperative style

long factorial(int n) {
  long rtn = 1;
  for(int i=2; i<=n; i++
    rtn*=i;
  return rtn;
}
---- functional style
long factorial(int n) {
  if (n<= 1) return 1;
  const long rest = factorial(n - 1);
  const long rtn = n * rest;
  return rtn;
}
---- or more succinctly
long factorial(int n) {
  if (n<=1) return 1;
  else return n*factorial(n-1);
}
----

As you see, recursive function calls are central to the functional style. This is how you can do loops without incrementing counters. Functional-style oriented compilers will often have outstanding recursion optimization passes.

A pure functional programming style will disallow explicitly freeing memory, since freeing memory changes variables that might still be in use arbitrarily far from the freeing line (a very common C/C++ bug). Thus functional style commands the use of a Java-style garbage collector.

I really wish more people would be familiar with functional-style. Even to the unaware eye, a mostly functional-styled piece of C++ will usually come across as very clean and readable code. The style is quite practicable in C++/Java, albeit not in its pure form.

It is that C++ and Java misses some grammatical construct to make pure functional-style practicable - those very constructs its creators came up with in the 60's. You will find it impossible to const all your C++ variable without lambda's, currying and function composition (1). Those are the telltale features of a functional programming languages.

Fortunately the ghetto of the 'pure' has all but disappeared. The rest of the world agreed to acknowledge the intrinsic performance limits of function-pure code - some rare but useful O(n) algorithms had to become O(nlog n) when rewritten to be function-pure. The rest of the world went on to create hybrid languages, like Ocaml and Haskel, where functional construct cooperate naturally with the imperative one.

With those hybrid languages, safe functional programming is no slower than its safe imperative counterpart, and unsafe functional exists and is just as fast or very close to C.

If functional programming style is not more widely used, it is mostly because of its higher bar of entry. As natural as they become, recursion, lambda's and currying are challenging concepts the first time you meat them - not unlike pointers (which most visual basic programmer still struggle with).

Hopefully you will have found here the motivation to investigate them nevertheless.

  1. note : It is often the typing system that cruelly misses the constructs, and not the grammar or the available operations proper. If it wasn't for the limitations of their respective types system, Java's anonymous inner classes would be lambda's, and C++ operator() construct would provide composition and currying. Alas.
[back]