Advantages Of Functional Programming

Here we discuss the advantages (or lack thereof) of FunctionalProgramming.

Please excuse this very basic question, but what are the fundamental advantages FunctionalProgramming is claiming? Being more high-level? Easier to test? ...? -- FalkBruegmann

Practical advantages: The most basic claim of FunctionalProgramming is that ReferentialTransparency is a GoodThing. (i.e., "no side effects") Programming without SideEffects has the following advantages (I will use the generic term "subprogram" instead of function, routine, method, what have you): So based on these observations, we want to limit SideEffects as much as possible. You can do this in any programming language, but if you try it in CeeLanguage, it becomes impractical very fast. As it turns out, you will probably at least need the following: Given all these, FP becomes practical. However, once you have denounced the evilness of SideEffects, some other things become practical, most noticeably: The latter is promised by Data Parallel Haskell ( http://www.haskell.org/haskellwiki/Data_Parallel_Haskell ) which will hopefully be usable soon.


Bravo, that's a very nice answer to the question.

It's a very nice answer to some question.

All the preceding is good stuff, but explains mainly why FP is pleasant. It's an advantage for programmers to work in a pleasant language, of course. But consider this: Ericsson have used a home-grown FPL, ErlangLanguage to build big telecom systems. Apparently they measured improvements in productivity between 9 and 25 times greater. Give that some thought.

Greater compared to what? Hand-hacking in AssemblyLanguage? Coding parallel systems in CeeLanguage?

Greater than whatever they were doing before, which isn't specified. The claim above comes from http://www.haskell.org/aboutHaskell.html Whereas, http://www.erlang.org/faq/t1.html at 5.15 says that developers are as productive in lines of code (!!!) in ErlangLanguage as they are in CeeLanguage, but need five times fewer lines to solve the problem, which isn't unspecified.

The Erlang FAQ also states:

The traditional ways of slowing down projects, like adding armies of consultants halfway through, spending a year writing detailed design specifications before any code is written, rigidly following a waterfall [WaterFall] model, spreading development across several countries and holding team meetings to decide on the colour of the serviettes used at lunch work just as well for Erlang [ErlangLanguage] as for other languages.


About ErlangLanguage especially: I think it comes with a similar component-level programming philosophy to most other FunctionalProgrammingLanguages, but has a very different inter-component communication philosophy. -- PanuKalliokoski


Considering automatic parallelisation, the ConnectionMachine was programmed in a dialect of LispLanguage. DanielHillis considered this the natural choice.


AliceLanguage is a step or two above Erlang, offering more than mega-concurrency. The Oz book (ConceptsTechniquesAndModelsOfComputerProgramming) studies Erlang, ConcurrentMl?, etc. and how Alice/OzLanguage encompasses all such capabilities.


Counterpoint Links

Some rather long, heated discussions concerning skepticism of claims of FP as a GoldenHammer, especially outside the domain of "systems software":


RefactorMe: merge with OoVsFunctional, FpVsOo?
CategoryFunctionalProgramming

EditText of this page (last edited June 2, 2008) or FindPage with title or text search