> I need few references (books, scientific articles, ...)to justify the
> following claims:
> - Functional languages are known to be concise and programs written in
> such languages are therefore easier to maintain.

> - Functional languages are more resistant to problems related to memory
> management and runtime errors.

> - Using a purely functional programming language (or only use pure
> techniques) can impact on performances.

> - Since modularity is the key to successful programming, the functional
> programming style is vitally important to solve real world problems.
> (This is actually a quote from Hueghes. Do you agree ?).

> Hi all,
> I need few references (books, scientific articles, ...)to justify the
> following claims:
>
> - Functional languages are known to be concise and programs written in
> such languages are therefore easier to maintain.
> - Functional languages are more resistant to problems related to memory
> management and runtime errors.
> - Using a purely functional programming language (or only use pure
> techniques) can impact on performances.
> - Since modularity is the key to successful programming, the functional
> programming style is vitally important to solve real world problems.
> (This is actually a quote from Hueghes. Do you agree ?).
> - Functional programs are easily verifiable using formal methods
> techniques.
> - Even if the methodological benefits of functional programming are
> well known, the vast majority of programs are still written in
> imperative languages such as C. This contradiction can be explained
> on the one hand by the historical lack of performance of functional ...

>> - Using a purely functional programming language (or only use pure
>> techniques) can impact on performances.

> I think the grand hope is to be able to stay pure and still get good
> performance, under some definition of purity that includes monads.

>> - Since modularity is the key to successful programming, the functional
>> programming style is vitally important to solve real world problems.
>> (This is actually a quote from Hueghes. Do you agree ?).

> I think Hughes' numerical examples are pretty neat but I'm not totally
> convinced yet. Hughes is specifically talking about lazy evaluation.
> Haskell guru Simon Peyton-Jones in "Wearing the Hair Shirt" argues
> that purity is a more essential feature of Haskell than lazy evaluation is:
> http://research.microsoft.com/~simonpj/papers/haskell-retrospective/index.htm
> SICP has a fair amount of material on stream-based programming using
> lazy evaluation in Scheme:
> http://mitpress.mit.edu/sicp/

>> I think the grand hope is to be able to stay pure and still get good
>> performance, under some definition of purity that includes monads.

>
> any papers/survey about comparison ? I can cite the shootout ... but ...

>> This would seem to be true, not just about FP, but for example see
>> Paul Graham's rants about Lisp, e.g.
>> http://www.paulgraham.com/avg.html

>
> this was a nice reading !

> - Functional languages are known to be concise and programs written in
> such languages are therefore easier to maintain.
> - Functional languages are more resistant to problems related to memory
> management and runtime errors.
> - Since modularity is the key to successful programming, the functional
> programming style is vitally important to solve real world problems.
> (This is actually a quote from Hueghes. Do you agree ?).

> - Even if the methodological benefits of functional programming are
> well known, the vast majority of programs are still written in
> imperative languages such as C. This contradiction can be explained
> on the one hand by the historical lack of performance of functional
> programs and on the other, by the inherent conceptual difficulty of
> writing functional programs.

> The following points are addressed by my book on OCaml (see my .sig):
>
> Pietro Abate wrote:

>> - Functional languages are known to be concise and programs written in
>> such languages are therefore easier to maintain.
>> - Functional languages are more resistant to problems related to memory
>> management and runtime errors.
>> - Since modularity is the key to successful programming, the functional
>> programming style is vitally important to solve real world problems.
>> (This is actually a quote from Hueghes. Do you agree ?).

>
> OCaml certainly scales better than C++, both to bigger projects and to
> larger groups of programmers.

>

>> - Even if the methodological benefits of functional programming are
>> well known, the vast majority of programs are still written in
>> imperative languages such as C. This contradiction can...

> For non-trivial tasks, OCaml is usually much faster than C++.

> Jon Harrop wrote:

>> For non-trivial tasks, OCaml is usually much faster than C++.

>
> I read C/C++ not C++
>
> For non-trivial tasks (whatever that means) is OCaml usually much
> faster than C? What experience/data do you base that assertion upon?

>>> - Even if functional languages are still slower then C/C++ in particular
>>> domains, the difference in performance has been considerably reduced
>>> in the last decade

>> For non-trivial tasks, OCaml is usually much faster than C++.

> I read C/C++ not C++
> For non-trivial tasks (whatever that means) is OCaml usually much
> faster than C? What experience/data do you base that assertion upon?