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 languages

For 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.

  • 1
    You are looking for this one, I guess? paulgraham.com/avg.html Actually, I think the article is a bit outdated, in between lots of functional concepts have entered the mainstream languages.
    – Doc Brown
    Jan 2 '15 at 18:49
  • 34
    Why should high-level management give a damn what programming languages and methods are used ? Why would they be involved in such a decision ? Surely that's a matter for the technical managers ? Jan 2 '15 at 19:04
  • 8
    @HighPerformanceMark: Substitute "technical managers" for "high-level management," and evaluate the question again. Jan 2 '15 at 19:05
  • 2
    What business are you in? If you do contract programming and consulting, functional programming may be a buzz-word that management may think will impress your clients.
    – JeffO
    Jan 2 '15 at 19:55
  • 3
    What business arguments did management give you for the languages you currently use?
    – JeffO
    Jan 3 '15 at 3:54

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.

  • If you can find actual research/evidence for these assertions to back them up - especially "Functional languages help to get rid of some of these challenges" - so far this is poised to be the best available answer.
    – DVK
    Jan 2 '15 at 23:24
  • This very question has already been discussed a few times, e.g. quora.com/Why-does-functional-programming-favor-concurrency or stackoverflow.com/questions/474497/…
    – Ashalynd
    Jan 3 '15 at 0:54
  • 3
    Except that many OOP languages support functional programming as well, so you can use the functional aspects with throwing the baby out with the bath water.
    – Andy
    Jan 3 '15 at 14:35
  • 1
    Right, the question was about "functional programming" not about "functional languages". Will change the wording.
    – Ashalynd
    Jan 3 '15 at 14:50

You are approaching this from the wrong side. In most companies, management is not responsible for "choosing the programming paradigm", they are (or at least should be) responsible for making the team work efficient. If your whole team is convinced functional programming will improve the speed or quality of your work, it should not be too hard to convince management, too. Moreover, if your team just starts to use functional constructs in your established programming languages, and everybody is happy with that, you should not even have to ask for a permission (heck, a non-programmer might not even understand the difference between non-functional and functional constructs, so why do you want to discuss that issue with him?).

But beware, if the rest of your team has a different opinion about FP, and they start complaining about functional code of yours which other team members do not understand, you might run into trouble with management - for a good reason, since in such a case, the team looses efficiency.

So the gist is: convince other team members, or your team leaders, but, not high-level management!

EDIT: due to your comment - actually, this is an answer to your question ;-). The one factual argument I am talking about is "the whole team thinks FP is helpful for doing the job. IMHO that's the argument with the highest chance of beeing accepted by high level management, and it is very practically applyable. Trying to use technical arguments to non-technical people directly seldom works, not because they are "too dumb to understand the technical reasoning", but because they are smart enough to know that technical decisions should be made by technical experts, and they are also smart enough not to rely on the opinion of only one expert.

  • 7
    I'm amazed that 19 people upvoted an answer that does not answer the question at all. It's a practical question, in a practical situation. Team members do NOT have a voice, and don't need to be convinced. They also won't be working - and neither will I for that matter - on unapproved technology/language, as the question made crystal clear.
    – DVK
    Jan 2 '15 at 23:07
  • 1
    @DVK if nobody else is going to see your code, then you don't need to convince anyone else that your language is good. Just start using it.
    – user253751
    Jan 3 '15 at 3:16
  • 2
    @DVK - you need to provide more insight into how management is controlling the language(s) used in your company. In most cases, management has little input in this area because they leave it up to teams and their leaders.
    – JeffO
    Jan 3 '15 at 3:54
  • 3
    @DVK: People upvote the answwers they find are most helpful for the question at hand. If most people are upvoting answers that state you are approaching the wrong problem, then that might suggest a large number of programmers have been similar situations and found these "non-answers" helpful. Most agree there is something fundamentally unhealthy in your business, and it has nothing to do with language choices. Most agree that that needs to be addressed, any any attempt to go directly after language choice will simply lead you to the next obstacle, rather than a series of solutions.
    – Cort Ammon
    Jan 3 '15 at 4:39
  • 1
    @CortAmmon While I'll happily agree that the question indicates something wrong with the way the asker's company is managed, it's highly unlikely that he's in a position to fix such problems. I've seen first hand the problems an opinionated CTO can cause (in fact, only yesterday I had to spend a substantial length of time working around a problem caused by a rule that our company won't deploy software outside of the "program files" directories on Windows machines, but Ruby won't install in a directory with a space in its name.
    – Jules
    Jan 3 '15 at 9:53

To understand why Functional Programming hasn't taken over the world, you have to understand the corporate thinking behind programming language decisions. To pick on Java for a moment:

  1. There are armies of programmers available that can write reams of ordinary Java code. This is not true of Lisp or Haskell (or even Scala) programmers.
  2. Everyone else is using Java, so it must be good. Corrolary: managers don't have to justify their choice of Java versus some obscure language nobody in the command structure has ever heard of.

If your organization is already entrenched in the Kingdom of Nouns, making a wholesale change to Functional Programming is just not going to happen. The language choice (and all the other choices that surround it) is already deeply embedded in the corporate culture.

Assuming your goal is to grow as a software developer, your best bet is to

  1. Incorporate functional concepts into your existing programs where they are useful and appropriate,
  2. Use new functional language features as they are added to the language, and
  3. Learn object-oriented design patterns, some of which exist to overcome the language deficiencies in OO languages that are not present in Functional languages.

Paul Graham's arguments really only apply to startups, and there have been a number of cautionary tales of companies that started out using purely Functional languages, but then they got bought out by another company whose first order of business was to immediately convert the functional code base to an OO language so that their existing software developers could understand it.

  • 1
    No, my goal is NOT (for the purposes of this question) to " grow as a software developer". My goal is to collect a best set of arguments to present to people who make decisions, that would sway them towards permitting FP as approved approach. Nothing more, and nothing less. Highlight benefits of FP, especially compared to standard OOP/procedural stack.
    – DVK
    Jan 2 '15 at 23:14
  • Also, unless I made a major wording mistake, the question definitely didn't mean to allude to "wholesale change" as the intended result of the arguments being sought.
    – DVK
    Jan 2 '15 at 23:15
  • +1 for Kingdom of Nouns. I've been calling it "The War Between Nouns and Verbs".
    – sea-rob
    Jan 3 '15 at 15:30
  • 4
    @DVK: The way to convince management of anything has been the same since time began: show them how it will save them money. Jan 3 '15 at 16:20

In my (somewhat cynical) experience, having worked for a shop where we did use functional programming, and interviewed at several others:

  1. There was always a CTO and other high-level technical people who had experience with functional programming and managed to convince the non-technical executives of it. (And incidentally, these folks are better qualified to answer your question than I am.)
  2. Once these folks leave the company, and get replaced by folks who don't have this inclination, things will go south. The new guys will blame everything that goes wrong (including, and particularly their own failings) on the weird programming language and paradigm used to build what came before. They will marginalize the remaining folks with functional programming skills, pushing them out of the company. The system built on the functional language will deteriorate unmaintained. This sort of thing, in my mind, the biggest risk that a business takes on if they adopt a functional language, and must not be underestimated.
  3. The organization has to have a "build instead of buy" culture for this to work. Because adopting a functional language will mean fewer "buy" options.
  4. There was almost always some compromise to the technical and non-technical detractors of the idea. The most common of these compromises is that any non-JVM language was just out of consideration; Clojure and Scala were proposed, Haskell and O'Caml were just out right off the bat.

Things to consider for upper management when/if upper management is involved in selecting programming languages (which is odd, they should leave it to trusted, knowledgeable people (both technology and business savvy):

  • Productivity
    • Both current and future employees
    • All roles (architects, developers, testers, OPs, ...)
  • Supported platforms
    • Operating systems, (hardware?)
  • Publisher of the language/platform
    • Licences
  • Maturity of the language/platform
    • Support of/by the publisher and/or community
    • Libraries
  • Migrating current code base
    • Or integration with

Note that these are not specific to functional programming languages. These are also no arguments unless you provide data with these. We cannot give you the data as they completely depend on your business' environment. The only thing we could do is collect data from the web to show how much knowledge and interest there is for a specific language. Be careful when translating many questions on StackOverflow or many tags on Linkedin into a language being popular.

  • 1
    Businesses are also concerned about hiring people, so if its harder to replace a functional dev i'd say that's a good reason for them to be involved in such decisions.
    – Andy
    Jan 3 '15 at 14:38
  • 1
    @Andy - Yes, that is why I am not refuting the question and I do think that managers should be interested in the topics I stated. My worry is more or less that the solution (Functional Programming Languages) is chosen BEFORE the problem (???) is defined.
    – Emond
    Jan 3 '15 at 14:48
  • Is it really that hard to replace a functional developer? By the number of informed developers that post here and on other sites on the Internet, I suspect that there are much more functional developers than managers think.
    – Giorgio
    Jan 3 '15 at 16:20
  • @Giorgio - I never said that it is hard to replace them but I my experience the availability can differ from location to location. Some college graduates never even learned the basics whereas some universities specialize in them. For a business it is very important to look to the long term and the expected need of new hires.
    – Emond
    Jan 3 '15 at 16:58
  • @Erno: I agree with your view. I was commenting on Andy's comment. Anyway, I have always assumed that there are very few functional programmers and that FP is seen as something esoteric. Lately my impression is rather that there much more FP developers than there are FP jobs.
    – Giorgio
    Jan 3 '15 at 17:04

I don't think arguments or facts will help. And certainly not without stating the problems you want to solve.

Against common believe and typical self evaluation many decisions are made based on gut feeling. And often these decisions are very good decisions, because they incorporate on a subconscious level a lot of experience of the individual making the decision.

If you want to challenge such a decision like "We'll stick to C like language until the end of all computers" you have to do more than just provide some arguments.

The first step is probably to uncover the persons and reasons behind the decision that senior management should have a saying in such technical decisions. Of course I can only guess here, but very likely they have quite a track record of decisions made by technical personal gone bad. Let's face it: Most developers aren't very good at making (even technical) decisions on a company level.

Once you found these people talk to them in order to gain there trust. Possibly the best approach is: listen to them. What are they concerned about, what are the risk and chances they see. What are problems they are challenged with. From here you might move to get technology people involved into this kind of decision. Management often doesn't really want to make these decisions, but doesn't trust others with it. So if you team starts to get involved into architectural decision and demonstrate that the decisions you propose are sound management might be willing to trust you/your team.

Important in order to come up with sound architectural decisions is:

  • Gather input from stake holders (Management, Users, Administrators, Sales, Clients ...)
  • Base decisions on that input
  • Communicate clearly: What the (proposed) decisions are; What risk they aim to mitigate; What conflicting interests are and with some delay: how well they worked.

If you work for a large company with say 10K+ employees, be prepared to learn some of the following lessons.

  • speed of coding isn't really relevant for the bottom line.
  • things like maintainability on the scale of decades is.
  • the problems you think you can solve using functional languages aren't really relevant for the bottom line
  • problems like training 1000 developers, the natural resistance to change and maintaining a code base written by developers with less than 5years experience in the technology used are.

Once you reached a level of trust that your arguments are heard and considered you will also have established a way of gathering and considering requirements that you, your team and management trusts.

If this process produces the recommendation to use a functional approach in certain areas you are done.

If this process produces the recommendation to ignore functional approaches going beyond what the current main programming language offers you are done as well.

The bad news is: Depending on the size and style of the company this might easily take a couple of years or decades.

The good news is: You will learn a lot on the way.

Since the first step is to start to talk and especially listen to senior management I'd recommend starting with reading Just Listen.


One good approach would be to show that it's shown good results in the industry and adopted.

You can get some data from:

Ideally, try to talk to the managers at some listed companies, especially if in your industry, and get numbers and testimonials from them.

Google has many other similar links for Haskell, OCaml, etc.

  • 3
    Some companies are going to see this as a case against, since OO practicioners outnumber FP adherents by a wide margin. Jan 2 '15 at 19:56
  • 1
    @RobertHarvey - that's a bit of a red herring argument, at least in my specific case. They are already intelligent enough to know THAT. What they do NOT know (and what I found out from this answer) is that Eaton Vance uses Scheme and more importantly, Faceboook, BoA/ML, Deutsche Bank and Google [use Haskell]. Meaning, it's something they CAN consider dipping a toe in, since other worthies decided to. Amazing that the only actually useful answer that tried to address the question I asked (and not the one people felt like answering) is the one with least votes
    – DVK
    Jan 2 '15 at 22:26
  • 1
    @dvk: The question you asked (if I understand it correctly) is "How do I convince my bosses that FP is a good thing?" Well, sometimes it isn't. We live in a mutable world, and Functional Programming is, quite honestly, a bit of an oddball. If you don't believe me, take a look at monads. Answers that address these oddities (and how they affect the software design and development process) are useful, whether you think they are or not. Jan 2 '15 at 22:42
  • @RobertHarvey (1) I take that back. Now TWO of the useful answers are lowest voted :) (new one that just got posted could be improved with facts but is a good start).
    – DVK
    Jan 2 '15 at 23:01
  • @RobertHarvey - yes. The question was NOT "Is FP a good thing" or "Is it possible to convince people FP is good thing". The question was very precisely "Which arguments can be used to support WHEN trying to convince it's a good thing". It was NOT "How can I stealthily introduce FP into my work/coding in a positive way" either, which is what you answered - if that was an option I wouldn't be asking in the first place, I'd be coding :)
    – DVK
    Jan 2 '15 at 23:05

You're coming at this from the wrong direction.

You're trying to convince management of a switch to a functional paradigm for your own amusement and you're trying to rake in arguments to support this that have got nothing to do with the real reason why you want it. Otherwise you wouldn't need to ask the question, because you'd be able to list your arguments from the top of your head.

Rather, what you should be thinking about is what the current business need is and how it is best served. If it so happens that it is best served using a functional paradigm then - yay! - you get to play. But if you do a fair analysis, taking into account operational business needs, necessary training of co-workers, backgrounds of future programmers, maintenance, and so on and so forth, often it won't be.

  • 2
    This is a tad pedantic, and not too helpful in answering the question, which should be abstracted away from just helping OP out on his "approach."
    – VF1
    Jan 3 '15 at 3:49

Senior management with no technical skills shouldn't care about technical aspects such as the usage of functional paradigms. This is not their domain of expertise, and smells micromanagement. Why aren't they delegating those decisions to persons who actually have required skills?

This being said, here are some hints to convince people with technical background (first case) and those without one (second case).

First case

If you're talking to people who know programming, comparing code written without functional programming paradigms and the same code written in functional style may be convincing enough:

Sample C# code which uses imperative style:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
    if (product.IsEnabled)
        if (!categorizedProducts.ContainsKey(product.Category))
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());


// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
        if (product.Price < minimumPrice)
            minimumPrice = product.Price;

        if (product.Price > maximumPrice)
            maximumPrice = product.Price;

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);

Same code rewritten with functional programming in mind:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))

Then ask them:

  1. How many mistakes can a programmer make in the first sample? What about the second one?

  2. How difficult is it to spot mistakes?

  3. How difficult is it to modify code?

All three factors influence productivity, and so the cost of the product.

Second case

If you're dealing with people who don't know programming, there is no much technical stuff you can tell them. One of the ways to be convincing is to show the actual impact of functional paradigms on your work and the work of your coworkers.

For example, compare two projects made by the same team, one using FP, other not using it. Showing that the number of bugs is much lower or that this was the first project the company actually delivered on time should be convincing enough.

  • 3
    I see what you've done there, but your example isn't entirely convincing. You've basically unrolled your functional example into an imperative one, which is not something that would happen in any practical corporate concern. Your yield return is a bit of a cheat, it being an example of how you would prepare code to be used in a Linq scenario anyway, and your if statements could be written more succinctly with ternary operators. All of your first example could be refactored into imperative functions, so that the complexity is hidden. Jan 2 '15 at 19:03
  • @RobertHarvey You could refactor the first example into a bunch of imperative functions, but they'd be custom imperative functions that are specific to that query; you'd still have to see all of it to convince yourself the query is correct. That refactoring would blow the size of the imperative code up even further as well. Even if you could write it just as compactly, you still have to read the code carefully because all the work is getting done through side effects; you wouldn't want to miss a side effect being done in the second part of a ternary operator at the end of a line.
    – Doval
    Jan 2 '15 at 19:29
  • 1
    @RobertHarvey I'm not even sure the two code snippets are equivalent, since the imperative one "filters" by building a second list instead of just skipping the iteration. Wouldn't the real equivalent use only one loop and thus be even more deeply nested?
    – Doval
    Jan 2 '15 at 19:31
  • 5
    There's no question that you make a good case for incorporating functional concepts in an otherwise imperative/OO language, but not necessarily a good case for using wholly functional languages in a corporate environment that's already imperative/OO. Jan 2 '15 at 19:31
  • Another (perhaps less valid) problem with your example: I could write the first example in fully readable mostly-non-FP Perl in - I'm guessing - 30% of the volume. Maybe less. Depends on whether you accept map/grep as non-FP. IOW, you are presenting arguments that Java is a bad language, not that FP is a good approach.
    – DVK
    Jan 2 '15 at 23:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.