Functional programming

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 state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions. 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) both times. 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. In the other well known declarative programming paradigm, logic programming, relations are at the base of respective languages.
In contrast, imperative programming changes state with commands in the source language, the most simple example is the assignment. Functions do exist, not in the mathematical sense, but in the sense of subroutine. They can have side effects that may change the value of program state. Functions without return value therefore make sense. Because of this, they lack referential transparency, i.e. the same language expression can result in different values at different times depending on the state of the executing program.

C# 3.0 and Java 8 added constructs to facilitate the functional style.

Functional Programming, as far as I understand it, seeks to describe what you want done rather than specify how you want something done. It's probably best understood in contrast to imperative programming. For instance, if you have a list in C and you want to pull out every Nth element, you have to point at the first element, set a counter at one, move to the next element, increment the counter, check to see if you're at the Nth element and so on. The functional equivalent would be to write a function that recognizes when the size of a list is a multiple of N, and then pass that function to the list, possibly with another snippet of code to hand back the head of the list if your N-recognizer evaluates to true and discarding it if it evaluates to false. The two functions recurse through the list, and finally hand back a list consisting of every Nth element.

The latter method might seem like the more confusing way to go about things, and that's because it is. Functional programming can be a mind-bender, which is one reason why Lisp, Scheme, and Haskell have never really surpassed C, C++, Java and COBOL in commercial popularity. But there are benefits to the functional way. For one, if you can get the logic correct, functional programming requires orders of magnitude less code than imperative programming. That means fewer points of failure, less code to test, and a more productive (and, many would say, happier) programming life. As systems get bigger, this has become more and more important.

Are there more exotic types? Not yet. There are hybrids between the two of them (like Scala), but these merely seek to leverage the strengths of both types. Then there's Object-oriented programming, which is really just a new way to organize data in an imperative program. And even with strange new technologies like quantum computing, the (planned-for) underlying languages fall somewhere in the declarative/imperative spectrum.