For one thing, functional programming typically handles multithreaded situations much better because of the lack of mutable state. As a result, things that you typically would do sequentially, you can spread out among multiple threads, and you can thread by task. Also, the idea of functions being first class citizens can be a useful paradigm when trying to move away from an global event manager model (which I have grown to hate). Just a couple of ideas, there are more.

"Functional style" normally refers to "stateless programming", but I've also heard it used to refer to "using higher order functions" (see http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf).

Stateless programming means that you cannot modify existing data, e.g. once a list is created, you cannot add new elements to it. This is not as useless as it sounds, as you can just create a new list which is equal to the old list with the extra elements added to it. This in turn might seem like a waste of memory, but again, it isn't, as you can reuse parts of old data structures in your new ones, since they are guaranteed never to change anyway.

This approach can have many advantages: it makes reasoning about programs easier, it can be more efficient, etc. Functional style can make using multithreading much easier. Formally, a variable in functional setting can be seen as just something with a value, which does never change. A variable in a stateful setting, however, has a value that changes in time, i.e. there's an extra dimension to take into account. Multithreading can be seen as "your code will run, but you can't know when". In that sense, it is easy to see why functional style simplifies multithreading.

Functional and imperative (= non-functional) style can easily coexist. For example, Haskell is a purely functional language (whereas for example O'Caml has ref cells which introduce state). However, Haskell gets translated to imperative code (due to laziness), so underlying a functional layer lies an imperative one. But, using certain syntactic tricks (monads, do-notation, ...) it is possible to introduce state in Haskell programs, so from functional elements one can build an imperative program.

Same thing in other languages: in java/C#, strings appear immutable to the user, while internally, they probably use state, but it is abstracted away. These purely functional strings are then used in an imperative setting, etc. etc. You can switch between functional and imperative style at will inside one program.

Also related is the expression problem. This has less to do with stateless vs stateful however, but rather as having functions or classes as building blocks. One can distinguish two "dimensions": functionality and cases. Let's take shapes as an example: one can have circles, squares, etc. as cases, and area, circumference, intersection, ... as functionality. An OO language allows you to easily add new cases (i.e. new shapes) by writing a new subclass, and implementing all necessary methods. This does not require you to make changes to existing code. If however you need new functionality, you would have to modify the superclass (Shape), i.e. add extra methods, and implement these in all subclasses.

Functional style can be seen as orthogonal to this. Adding new functionality is trivial: just define a new function, no existing code needs modifications. However, adding a new case requires you to extend the data type definition and adjust all existing functions to deal with this new case.

Technically, it is possible to add extra functionality in OO programs and add new cases in functional programs without modifying existing code, but it can lead to some ugly results, which sometimes bypass the type system (I'm thinking of using instanceof in java, which bypasses some correctness checks (exhaustivity, i.e. making sure that all abstract methods are implemented) done by its type system).

If you come from an imperative background, it's kind of hard to envision what functional techniques are good for unless you try using them.

I use C#, so the only functional stuff I really use are first class functions and lambdas. For me, the benefit of using these is reduction in the amount of state that I need to manually implement.

For example, let's say I want to filter a collection:

Imperative style:

public List<int> FindPositiveIntegers(List<int> inputs)
{
  List<int> values = new List<int>();

  foreach (int input in inputs)
    if (input > 0)
      values.Add(input);

  return values;
}

Functional style:

List<int> values = inputs.Where(x => x > 0).ToList();

In my opinion, the functional case's advantages include:

- The code is shorter, which usually means it's easier to maintain.

- The variable mutation is entirely hidden from the programmer by the LINQ methods. Reducing the number of variables that a programmer has to deal with also means that there are fewer *effective* states that the program can be in (this is a good thing - fewer states means it's easier to prove that it works correctly in those states).

- There is less manual flow control being performed by the programmer. Flow control is another kind of state that a programmer has to consider.

- I can more easily write a function which gets negative numbers instead; In both cases I can copy/paste the whole thing and just change the condition, but in the functional case it's easier because there is less code to maintain.

- The "Where" and "ToList" methods seen here are reusable. They've been proven to work correctly, so the only burden on the programmer is understanding what they do and writing the lambda expression "x => x > 0" inside the Where call. Allowing for reuse of code where *parts of the algorithm itself* are interchangeable is a consistent theme when using functional style.


TL;DR:

OOP encapsulates data, Functional style encapsulates code.

For folks interested in checking out FP, it may be useful to know that a new round of a functional programming basics course has just started at Coursera. The language used is Scala, but you aren't expected to have previous knowledge, and the focus is on general FP concepts as opposed to diving deep into the languge. (Though it's a good opportunity to get started with Scala as well; the lecturer is Martin Odersky, the author of the language.)

https://www.coursera.org/course/progfun

FP-oriented thinking is useful even for the hobbyist because it leads to more expressive code, cutting down development time, errors and maintenance. And it has become critical for high performance. Single cores stopped getting significantly faster a long time ago, and concurrency and parallelism are now the major bottleneck for most interesting things. FP helps you survive in an environment with those two phenomena.

I'm "thinking functionally" a lot of the time even when coding C++.