Scaling in functional programming

I heard that programs written in a functional language tend to scale better. Is this true and if so then what are the differences from non functional langu开发者_Python百科ages that cause this?

Whoever you heard this from was most likely referring to the fact that "Disallowing side effects provides for referential transparency, which makes it easier to verify, optimize, and parallelize programs, and easier to write automated tools to perform those tasks."

In other words, functional programs tend to not have side effects (modifying global state) so running many instances of a functional program in parallel should produce the same output. For example, consider the difference between

int a;
void increment_a() {
    a++;
}

and

int increment(int a) {
    return a+1;
}

The second has no side-effects and can be run in parallel, provided you structure your code so that you provide all the necessary inputs.

The choice of programming language has no effect on how well a program scales. That's a function of the program's design. A well-designed C program can scale well (assuming that's a design goal), and poorly-designed Erlang can scale extremely poorly.

If it's true, I would suggest there are three factors possibly at work:

1. Functional programs have features which make it easier to design programs with scalability in mind. Possibly, but I haven't worked on a large-scale project so I can't really say. In Haskell at least, purity is at the root of most features people use for designing large-scale programs such as Software Transactional Memory. But most functional languages aren't pure.

2. The design requirements when working in a functional language make it easier to think about these issues up front. It's often argued that well-designed functional programs are created as a function to transform input to output. Maybe thinking in this manner makes it easier to address issues of scale (and modularity) up front?

3. Functional languages tend to be testing grounds for new language structures, programming models, etc. So they may have more stuff built-in to address problems of scale. I certainly think this is part of Erlang's success: the core language and libraries have excellent support for fault-tolerant distributed processing because it's part of the purpose of the language. As such, writing fault-tolerant distributed code can be relatively simple. But again, this is partially specific to Erlang. The same design goals wouldn't be true for Haskell or SML.

Considering the quicksort example in Haskell is not optimal I have my doubts.

It isn't all roses, of course. The C quicksort uses an extremely ingenious technique, invented by Hoare, whereby it sorts the array in place; that is, without using any extra storage. As a result, it runs quickly, and in a small amount of memory. In contrast, the Haskell program allocates quite a lot of extra memory behind the scenes, and runs rather slower than the C program.

Those ingenious techniques are usually what determine how well an app scales. Here's another telling article about functional programming.