During my four years at university we have been using much functional programming in several functional programming languages. But I have also used much object oriented programming to, and in fact I use object oriented languages more when doing my own small project to prepare for my first job. But I often wish that I was coding in a functional programming language when doing these projects.

However, when looking for a job, it is very rare to see a job where knowledge of a functional programming language is required.

Why isn't functional programming languages used more in the industry? There is quite much news about functional programming languages these days, so I wonder if functional programming is catching on in the industry now?

  • 3
    To some extent, I disagree with the premise of your question. Language features inspired by "functional languages" are being added to languages like Java and JavaScript. In fact, JavaScript has always been (in some ways) a functional language, though a lot of people didn't realize it until recently.
    – Tyler
    Commented Sep 30, 2011 at 17:44
  • 1
    @MatrixFrog: One might ask "Why go functional only half way by adding a few functional concepts to non-functional languages instead of adopting a full-fledged FP language? After all the paradigm has been around for many years and is very mature."
    – Giorgio
    Commented Nov 13, 2012 at 19:46
  • world doesn't switch to superior alternatives (and pure FP is a superior alternative) for different reasons including backward compatibility, inertia etc. Consider DVORAK keyboard layout: it's more efficient for touch typing but we all stuck with QWERTY simply because there's so much software with qwerty-friendly shortcuts.
    – KolA
    Commented Aug 21, 2019 at 9:44

12 Answers 12


I was a professor and, just like programmers, professors are always looking for the Next Big Thing. When they think they've found one, they make it a bandwagon, and everyone piles on. Since they are preaching to students who think professors must be really smart, else why would they be professors, they get no resistance.

Functional programming is such a bandwagon. Sure it's got lots of nice interesting questions to investigate, and lots of sort-of-interesting conference articles to write. It's not a particularly new idea, and you can do it in just about any modern language, and ideas don't have to be new to be interesting. It's also a good skill to have.

Given that, functional programming is just one arrow to have in your quiver, not the only one, just as OOP is not the only one.

My beef with computer science academia is lack of practical interplay with industry to determine what actually makes real-world sense, i.e. quality control. If that quality control were there, there might be a different emphasis, on classifying problems and the ranges of solutions to them, with tradeoffs, rather than just the latest bandwagons.

  • 1
    This is a really good comment. +1 to arrows in your quiver, and ranges of solutions with tradeoffs.
    – user21007
    Commented Apr 7, 2011 at 22:00
  • 2
    +1 for QC. That MSc would have been much more useful with dedicated subjects covering testing, code review, code complexity and similar. Being able to automatically verify that a program does what it should after the last patch is worth any number of "it should work now" hand-wavy gibberish.
    – l0b0
    Commented Jun 17, 2011 at 14:00
  • 5
    @l0b0: Thanks, although actually I was thinking of the quality control of what is taught and how. As it is, CS professors just teach what they personally find most interesting. Compare that to engineering, where there is interplay with industry, or medicine, where the real-world relevance is very high. IME, CS profs figure the real world will do the teaching of what matters in the real world, but students don't come out eager to learn - rather they are eager to proselytize what the profs were most excited about. Commented Jun 17, 2011 at 21:59
  • @Mike: just about any modern language? Are you including C++ and Java? Commented Sep 30, 2011 at 17:45
  • 1
    12 years later, and I return to read the answers, and now I select this as the "accepted" answer.
    – Jonas
    Commented Aug 27, 2022 at 14:17

I would say that one of the reasons that functional programming is not more prevalent is the lack of knowledge base. My experience is that corporations are very risk averse in terms of implementing technologies that are not main stream and would rather invest in tried and true frameworks (java, c++, c#). It's only when there is a business need (like in Ericsson) that new paradigms are considered. But even in Ericsson's case I heard that management demanded that c++ be used and Joe Armstrong was compelled to code erlang calls in c++!! This should show how reluctant corporations are to implement new technologies!

  • 9
    How is functional programming in any way 'new'? Commented Sep 12, 2010 at 2:15
  • 7
    I think he meant 'unused' instead of 'new'.
    – Vinko Vrsalovic
    Commented Sep 15, 2010 at 19:32
  • 10
    So it is unused... because it is unused? Hm. Commented May 12, 2011 at 2:12
  • 22
    @Alex - Exactly. Sucks, don't it?
    – KeithS
    Commented Sep 30, 2011 at 17:08
  • 5
    @Stargazer712: What are those reasons? I know lots of developers who don't know functional programming, so ignorance makes sense to me. Did functional programming have a massive failure in the past that chased the industry away from it that I'm unaware of? Commented Sep 30, 2011 at 20:11

Because the biggest problem in software development these days is the ability to manage complexity. This is not the focus of most functional programming languages. As such, languages that do make that a priority (namely the more popular OOP languages) tend to just steal some of the cooler features that come out of the more academic functional languages and so stay on top.

  • 53
    I disagree. Functional programming languages try to minimize the use of a state, and by that get less complex. Programs programmed in a functional language is also easier to test and refactor.
    – Jonas
    Commented Sep 26, 2010 at 15:36
  • 7
    @Jonas: a lot of programmers find it extremely difficult to write a program using almost no state at all (including myself). From that point of view, it is actually a more complex. (Please note that I'm not debating the usefulness of functional programming by any means!)
    – ShdNx
    Commented Sep 26, 2010 at 16:11
  • 4
    @ShdNx: Yes, I know. Even I thought functional programming was hard when I first learned it in university. But after a while I started to prefer it to imperative programming and more specific OOP. At my university functional programming was taught before imperative programming and students that hadn't done any programming before university thought that imperative programming was very hard at the beginning and that functional programming was closer to math.
    – Jonas
    Commented Sep 26, 2010 at 16:37
  • 16
    There is a difference between difficulty and complexity. OOP is definitely more difficult than structured programming because it adds more concepts. For big enough amounts of code, they reduce complexity by providing a structure to the code. FP is the same thing: if you are writing only two lines it seems like overkill, but if your code is big enough then structuring code as stateless subunits improves the scalability and reduces the complexity of the code. Commented Oct 28, 2010 at 10:54
  • 6
    One of the main emphasises of functional programming is composability. If that isn't a tool for managing complexity I don't know what is. Commented Nov 11, 2011 at 15:06

Functional programming is definitely starting to catch on - slowly but surely.

For example, the startup I am building is using a functional language (Clojure) as the primary development language for the following reasons:

  • Productivity - learning FP is hard, but once you get the hang of it it is very hard to beat in terms of power and expressiveness. I'm probably writing about 1/10th of the number of lines to implement any given piece of functionality compared to what I would have needed in C# or Java

  • Reliability - pure functions are much easier to reason about and test than stateful objects. Hence you can write better tests and validate the correctness of your code much more easily.

  • Concurrency - functional languages emphasise immutability, which has enormous benefits for concurrent applications than need to run effectively on multiple cores. And like it or not, running on multiple cores is the future. See http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey for a brillient explanation of why this is so important

  • Composability/modularity - functional languages seem to lend themselves to plugging components together more easily than complex OO systems. I still haven't figured out all the reasons for this, but part of it stems from the fact that you don't have all the "incidental complexity" that OO models drag around with them. The talk on Radical Simplicity by Stuart Halloway explores these ideas in much more depth.

EDIT: In response to Despertar's comment, an example of the "incidental complexity" of OOP systems that limits modularity is the problems with deep cloning vs. shallow cloning: you can't compose objects together and pass them around as composite structures without a very careful analysis of the cloning and mutation semantics. In small cases this is manageable, but in complex systems it rapidly becomes a significant problem. This problem won't exist in the first place if you rely on pure functional data structures.

  • +1, I'd be very interested in hearing your decision making process around why you chose Clojure. (I'm not for or anti Clojure, I'm just interested). Commented Nov 11, 2011 at 15:10
  • 7
    "learning FP is hard": Learning any paradigm is hard. I remember how many hours I spent with imperative code (Pascal) before I had enough experience to be reasonably productive. I think FP is less known because many programmers learned an imperative language first and once they learnt how to program they did not have the time to look at something else. I am a full-time C++ programmer and I am currently learning Scala in the evening after work. If I had a family to look after I could simply forget about it.
    – Giorgio
    Commented Nov 13, 2012 at 20:19
  • 1
    I think the first 3 are great cases, however I disagree with the 4th. OOP is extremely modular and compositional; for me this is one of its greatest strengths. It's also great at hiding complexity through encapsulation and abstraction.
    – Despertar
    Commented Jul 19, 2013 at 8:30
  • 1
    @Giorgio. Exactly. "Learning FP is hard, learning OOP is easy" is as absurd as "Learning Spanish is hard but Chinese is easy". It depends which one was your first language. And I didn't pick Chinese as arbitrary analogue to OOP - because OO idioms are like hieroglyphs: easy to learn one by one but hard to remember them all and impossible to compose. FP is a lot more like a language with an alphabet: separate letters are useless in isolation but allow to compose anything with reasonably small set of rules
    – KolA
    Commented Aug 15, 2019 at 5:03
  • 1
    (continued) so why is it not popular - yet - for the very same reasons. Hieroglyphs existed long before first alphabet was invented and matured. It may take another generation who has alphabetic writing and reading I mean FP as their first paradigm
    – KolA
    Commented Aug 15, 2019 at 5:13

Lack of killer app

Hey, this one over here looks fresh. (dig dig dig)

I think most programming languages thrived by having a "killer app" - something compelling that was exclusive to the language (or viewed that way). This is not to say that all of the uptake was that application, but that it drove the language to a larger acceptance.

Here's my not terribly accurate view of what niche has driven the adoption of some of the languages we have today:

  • C: Works everywhere (This was the late 70s and 80s)
  • C++: GUI frameworks (early 90s)
  • Java: Applets and servlets (in the late 90s)
  • Objective-C: iOS apps (Before that, OS X apps)
  • Ruby: Rails
  • C#: ASP.NET, WinForms
  • PHP: Wordpress, etc.
  • Javascript: AJAX, especially via frameworks
  • lua: Game scripting, especially WoW

Aside from that, many proprietary languages have gotten in the door through powerful sales organizations (Oracle, and to a lesser degree Microsoft's languages), effectively creating their own niche.

One very important note about that list: The language's "niche", as indicated by the killer app, gets more and more specific as decades pass. Note the last one on the list: Game scripting, specifically. It's getting harder and harder for languages to get attention because of the list of things that are already done well enough by another language.

So, what any functional language needs to really take off is a niche. In reality, there aren't any huge functional languages yet, but there are a whole lot in smaller niches:

  • Emacs Lisp: Constant use since the 80s in Emacs by developers. (Hardly ever used anywhere else.)
  • Erlang: Anywhere you want lots of concurrent agents.
  • Scheme: Education
  • APL/J/K: Finance (Let's call these functional, for the sake of the argument)
  • Common Lisp: "AI" - This is what people tend to say it's used for, which is a blessing and a curse.

Now, the only major language I feel I've left out of this discussion is Python. Python has done something very interesting; it has succeeded without appearing to be the winner in any major niche. This could mean that I'm flat-out wrong for viewing language popularity this way. It could also mean that a good enough language can become popular without a killer app to drive adoption and acceptance, but it is very difficult and might take a very long time. (Perl has a similar story, but came a few years earlier and is now has less uptake.)

From this, I can say which functional languages I think are on the rise:

  • Clojure: Web programming, esp. through Heroku
  • Scala: Lift (or maybe Play, these days) - JVM without Java

If you asked me where to look next for popular functional languages, I'd say be on the lookout for a functional language with turnkey cloud development (a la Heroku or GAE) or turnkey mobile app development.

  • I would consider Perl a major language as well. It's an older language that I would say is most often used with Unix-like systems. Although Python seems to be a more modern alternative. It is still a popular language that has gotten a lot of attention and has a large community.
    – Despertar
    Commented Jul 19, 2013 at 8:43
  • 1
    @Despertar - I wasn't trying especially hard to be egalitarian about which languages I mentioned :) And agreed, the story seems a lot like Python, except a few years in the past. Commented Jul 20, 2013 at 9:47
  • 1
    Perl did have a couple of niches. The earliest one was reflected in older versions of its documentation, which refered to the name as being an acronym for "practical extraction and reporting language". The second came along a bit later, and was CGI scripting -- for many years, perl was the language of the web. Obviously it's lost a lot of that popularity now, but have a look at old web sites that still run on the same software they were originally built with, and you'll see a lot of perl (I thinking of slashdot.org, right now, but there are quite a few more).
    – Jules
    Commented May 23, 2016 at 13:14

For the same reason that Lisp never really caught on (let the flamewars begin!). Functional programming is a very alien paradigm compared to imperative and object-oriented programming. If, like the vast majority of CS students, you started off with C and progressed to C++/Java, you tend not to want to learn to think in a way that is completely orthogonal to the way you normally think.

  • 2
    Alien paradigm? It's closer to math than imperative programming is. Here in Sweden I think that most CS students at university is thaut functional programming first. E.g. we started out with Standard ML, before C, Erlang and Java.
    – Jonas
    Commented Sep 4, 2010 at 20:17
  • 4
    Fair enough. I know that a lot of engineering students in the UK and India are taught C first, followed by C++ and/or Java. Often they aren't taught a functional language at all. Commented Sep 4, 2010 at 22:26
  • 14
    @Jonas For a number of folk out there, mathematics is an alien paradigm and anything that takes programming further away from mathematics makes it easier to understand. Commented Apr 1, 2011 at 20:06
  • 5
    I've heard of people who have never heard of trees, let alone function programming, having graduated. Commented Apr 7, 2011 at 21:08
  • 1
    @Tux-D, actually, no, I'm talking about students in the UK. Commented Oct 1, 2011 at 7:49

Let's consider businesses and programming.

There are businesses that use their software as a strategic asset. This isn't typical. For most businesses, IT is something that supports the company's real business. It's a necessary expense. They are conservative because they know that for $X they can get the IT they need, while if they switch to something different they'll save less than $X if everything goes well, and lose real big if everything goes badly.

Moreover, in businesses, the cheapest thing to do is typically what they did yesterday. Change, however, desirable, is expensive. If a company were to change from, say, a C#/.NET solution, even to F#, they'd have problems. Their programmers (which are likely not the sharpest programmers out there) would have to learn a new language, and be proficient in both, and use both frequently. There would be routines written in both for a long time. If they were to move to something like Haskell, or if they were using C++/MFC in the first place, they'd be changing a lot more, and that would be a lot more expensive.

Also, there's going to be a supply of C# programmers, and continuing Microsoft support, for a long time to come. The present IT practices can be counted on. There isn't the same level of institutional support or assurance of continued availability of programmers.

Therefore, for most businesses, making a change to functional programming would be expensive up front, and it will only pay for itself if the reduction in IT costs is sufficient over the long run, except that the long run is potentially iffy.


You already write code in functional style, just you don't know it.

When you are required to make unit tests for your code, you tend to write testable functions, which does not create or depend on side effects, and always returns the same result on the same arguments (so called pure functions). This is the primary advantage of functional programs.

I think functional languages are too limiting. So instead of replacing imperative languages with functional, imperative languages will get functional features. Nowadays almost every programming language has closures and lambdas.


The real problem is state.

Functional languages don't have global state. Most industrial problems require state at the large scale (how do you represent a ledger or a set of transaction) even if some functions at the small scale do not actually require it (processing a ledger).

But we are running code on Von-Neuman architecture machines which are inherently state-full. So we have not actually got rid of state, the functional languages just hide the complexity of state from the developer. This means that language/compiler has to deal with state behind the scenes and managing it.

So though functional languages have no global state, their state information is passed as parameters and result.

So the question then becomes can the language handle the state efficiently behind the sense? Especially when the data size far exceeds the size of the architecture.

Looking at it from Hardware Side

The OS has helped a lot in the last couple of years in visualizing address space so applications do not officially need to worry about it. But applications that do not worry about fall into the trap of thrashing the hardware when memory pressure becomes intense (thrashing hardware will slow your processes to a crawl).

As the programmer has not direct control over state in the functional language they must rely on the compiler to handle this and I have not seen functional languages that handle this well.

On the converse side of the coin the state-full programmer has direct control over state and can thus compensate for low memory conditions. Though I have not seen many programmers that are actually smart enough to do so.

Looking at from the industry side:

Industry has a lot of inefficient state-full programers.

But it is easy to measure improvements in these programs over time. You throw a team of developers at the problem they can improve the code by improving how the program handles state.

For functional programs the improvements are more difficult to measure as you need to improve the tools that will improve the programs (we are just looking at how applications handle underlying state efficiently here, not the overall improvement of the program).

So for industry I think it comes down to the ability to measure improvements in the code.

From a hiring perspective

There are a lot of stat-full programmers available for hire. Functional programers are hard to find. So your basic supply and demand model would kick in if industry swapped to functional style programing and that is not something they want to happen (programmers are expensive enough as it is).

  • 2
    Functional languages, especially "impure" functional languages, can deal with global state perfectly fine. I find that often programs decompose into alternating layers: eg, global state... but functional state transitions... with occasional local (masked) state to implement performance-critical parts of those transitions, etc. The problem with imperative languages, IMO, is that they often lead programmers to use state inappropriately, when functional patterns would work better. But languages seem to be evolving in the direction of supporting both styles well. Commented Sep 30, 2011 at 20:57
  • 1
    It's very easy to deal with state in functional languages, but it requires a shift in emphasis. Whereas in imperative languages you write procedures that modify state, in functional languages you write functions that return procedures that modify state. Commented Nov 11, 2011 at 15:17
  • "Functional languages don't have global state" - You do not need global state. Pretty much all state management can be done through monads. Commented Oct 25, 2018 at 8:30

I believe there's only one real answer to your question. You can get into a lot of related reasons why this answer is the case, but those are different questions.

Here it is:

  • Software architects provide solutions they are confident will work.
  • The majority of architects do not work in functional languages.
  • Once technologies and languages are chosen, businesses find people who can work with them.

Is it catching on? That all depends upon whether people who are confident in using functional languages are becoming architects and choosing to use it for the projects they work on.


This question have slightly wrong premise. For the following reasons:

  1. Functional programming is actually pretty common in the industry. But it's only used where experienced programmers are available. Beginners cannot be expected to know it. Almost all large programming projects are using it, but they just keep it in areas which are handled by experienced programmers. Beginners will deal with the easy modules which do not require functional programming.
  2. Given this reality, companies that are hiring people (usually young ones coming from university) cannot really ask for functional programming experience. Anyone in projects which requires functional programming has already been in the same company for 15 years.
  3. Universities are starting to teach it, because they know already now that functional programming knowledge will be very useful in 30 years. Their time range is in 30 years, not the normal half year like in companies.
  4. These points are the reason why people get disappointed when they enter the work force and see that the stuff they learned in university are not used. But they were designed for 30 year timespan, and it will be useful eventually -- it's just that companies are using the simple stuff - the stuff they can expect people to know.
  5. Also you would be arrogant if you think after few years of university, you know functional programming well enough to use it in actual software projects. Start from the simple stuff first. You don't really need to do the most complex piece of software as your first task when you start working. You'll eventually get to the complex stuff, but it takes time.
  • 2
    1) "almost all large programming projects are using it". My experience is that this is far from the reallity. Very few companies are using functional programming as what I know. Most only use Java and C# (even though C# have got more functional constructs the last few years), C++ and C.
    – Jonas
    Commented Sep 30, 2011 at 17:34
  • 2
    2) My experience is the opposite. People from universities seem to be the only ones that know functional programming. Here in Sweden, most universities teach functional programming from the first year. And universities like MIT have until recently been using functional programming in their first programming course (Scheme).
    – Jonas
    Commented Sep 30, 2011 at 17:34
  • @jonas: no, the programming language has nothing to do with it. Of course C and C++ and java etc is used by large number of projcts. The functional programming is also working in c++ code. The current practise seems to be that part of the project is using OO and part of it uses functional programming. Both parts use the same language (usually c/c++)
    – tp1
    Commented Oct 1, 2011 at 10:55
  • Yeah, you could do OO in C too. But it's not recommended. C and C++ doesn't have many constructs for functional programming e.g. not immutable by default, no good support for pattern matching, no included immutable datastructures and so on...
    – Jonas
    Commented Oct 1, 2011 at 12:22
  • Well, that's why it requires experienced programmers. Since it's pretty much impossible to change the programming language from the mainstream ones, the next best thing is to do functional programming in c++. Also c++ has things like const which help quite much.
    – tp1
    Commented Oct 1, 2011 at 13:30

Because it's harder to debug FP.

  • 12
    I disagree. Without collateral effects the debug process is easier. Maybe you think it's harder because functional paradigm is different and needs experience to got comfortable with new way to do things, including debug.
    – Maniero
    Commented Sep 25, 2010 at 3:39
  • 3
    Functional programming languages are actually easier to test, since pure functions is stateless.
    – Jonas
    Commented Sep 26, 2010 at 15:38
  • 4
    Jonas, I didn't say "test", I said "debug" ie. find a mistake that you've made. Testing is part of that, but so is reasoning about the program, etc. bigown - I stand by this. It's a function of FP's power. The more work any particular line of code does, the harder it is to see which line of code is causing a problem. The mapping between line of code, and effect, is more diffuse eg. a single higher-order function might touch dozens of behaviours of the program and vice versa. The symptoms can vary wildly between different points for the same error.
    – interstar
    Commented Sep 28, 2010 at 5:15
  • In my experience it is not hard to debug at all. I am using F# and I can't find any reason why you would find it more difficult to debug than C# for example. May be debugging is harder in Haskell because of the laziness (I have no idea), but eager FP programming is simpler due to statelessness as Jonas said. In other words, FP code is more predictable because you know the result is not influenced by unseen variables. Commented Oct 28, 2010 at 10:49
  • 3
    So long as your functions are pure, debugging is easy. If you can't debug by adding unit-tests then your not doing an adequate job of writing tests. Commented Apr 7, 2011 at 21:12

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