There are tons of theoretical arguments for why functional programming is a Good idea (too many for that to have stayed as an open question, and correctly so).However, most of them are arguments either made from theory (elegance, etc...), or, aimed at developers.The problem is, most of them are entirely useless when one's goal is to present the idea to senior management of a large company, some of whom aren't even developers, and all of whom mostly care about business arguments: cost, human capital management, product delivery, client service and revenue; as well as quantitative facts over theoretical points that can't quite be backed up with facts.Are there any compelling arguments to present to address those business concerns as far as considering adoption of functional programming as a concept (not any specific language), vs. the typical mix of procedural/OOP, e.g. Java/C++/(Perl|Python).Preferably, I am looking for arguments that are quantitative and/or based on research or case studies. E.g. according to this reference, the bug rate of multithreaded systems in Lisp/F# is 10% that of Java or 80% of top graduates expressing preferences of desired technology named functional programing as on of top 3 interests. I know that Graham presented use cases of functional programming for a starup and would be open to some of his arguments assuming they can be valid for a larger established company.p.s.I'm perfectly aware that you can do something close to functional programming in Perl, likely Python, and (possibly) even Java 8 or C++ 14. But that doesn't mean that an organization using Perl, C++ or Java would endorse functional vs OOP/procedural approaches even in those languagesFor the purposes of this language, large is defined as large enough to have dedicated development engineering/tools group, which dictates what all the developers are allowed to use/do; and at least hundreds of developers on low end.
What would be good factual arguments to convince high level management to consider functional programming?
functional programming;business;language choice
There is one very simple argument, which might at least amuse the management. It is well known that the modern computers are not becoming faster like they used to be, because frequency scaling, for now, hit the limit. They increase their potential productivity by adding cores. This implies that to benefit most from this architecture, the programs have to be parallellized. But parallel programming is way harder than sequential programming, due to a lot of new challenges it brings (consult Wiki article for comprehensive overview). Functional programming helps to get rid of some of these challenges, e.g. race conditions don't apply if you only use immutable variables and methods without side effects. The learning curve for functional programming is often steep, but the learning curve for parallel programming might be even steeper, and not at all intuitive. So if the challenge is to write more efficient programs in more efficient way, one can compare costs of training people to write parallel programs with costs of training people to learn functional programming, and the risks both approach might bring.Regarding mixed languages (which support both functional and imperative programming style): from one point, they might be handy for the transition (people might start using them in the familiar way and gradually learn new approaches). From another point, this might be a blessing in disguise, because the potential advantages the functional programming brings might be cancelled with someone's clumsy code. One can mitigate this by establishing clear coding guidelines (see e.g. Effective Scala by Twitter), though following the guidelines requires a certain level of team maturity. From this point of view, pure functional languages might be easier for software development because of the stricter rules they impose by design.