In which scenarios should I consider a functional programming languages better suited to do a given task? Besides the so recently popular multicore problem of parallel programming.
Anything that involves creating sequence of derived data elements using a number of transformation steps.
Essentially, the "spreadsheet problem". You have some initial data and set of row-by-row calculations to apply to that data.
Our production applications do a number of statistical summaries of data; this is all best approached functionally.
One common thing we do is a match-merge between three monstrous data sets. Similar to a SQL join, but not as generalized. This is followed by a number of calculations of derived data. This is all just functional transformations.
The application is written in Python, but is written in a functional style using generator functions and immutable named tuples. It's a composition of lower-level functions.
Here's a concrete example of a functional composition.
for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
print line[0], line[3]
This is one way that functional programming influences languages like Python.
Sometimes this kind of thing gets written as:
cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
print line[0], line[3]
If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).
Immutable objects is the toughest hurdle.
Often you'll wind up calculating values that create new objects instead of updating existing objects. The idea that it's a mutable attribute of an object is a hard mental habit to break.
A derived property or method function is a better approach. Stateful objects are a hard habit to break.
With so many functional programming languages out there, how would you choose the one the better suit your needs?
It doesn't matter at first. Pick any language to learn. Once you know something, you're in a position consider picking another to better suit your needs.
I've read up on Haskell just to understand the things Python lacks.
That's a good example of two different approaches that carry the notion of performing a task outside the boundary of concern for the calling object.
While it's clear in this example that you should go for the functional approach, in general it will really depend on how complex the behavior the called object has to exhibit is. If it really is a matter of complex behavior, where you'll find yourself reapplying similar logic often, and function generators cannot be used to clearly express it, then you'll probably want to go for class composition or inheritance, where you'll have a bit more freedom to reuse and extend existing behavior on an ad-hoc basis.
One pattern I did observe, though, is that usually developers go for the functional approach initially and only once the demand for more granular behavior arises they decide to go for a class-based approach. I know, for instance, Django went from function-based views, template loaders and test runners to class-based ones once the benefits and requirements became obvious, but not before that.
Best Answer
According the Great Benchmarks Game, ATS is faster than the rest with Haskell, Scala, and one of the variants of Common Lisp in a rough tie for speed close behind that. After that Ocaml and F# are in roughly the same speed category with Racket and Clojure lagging behind...
However, almost none of this means anything at all really. It's all a question of problem, machine, compiler, coding techniques, and in some cases, plain luck. Generally speaking, Directly machine coded languages like Haskell will outperform VM compiled languages like F# and vastly outperform purely interpreted languages. Also generally, Statically typed languages are faster than Dynamically typed due to static analysis allowing all type operations to be calculated at compile rather than run time. Again, these are general rules, there will always be exceptions. "Paradigms" have little to do with it.