I've been hearing a lot of enthusiasm about functional programming languages lately, with regards to Scala, Clojure, and F#. I've recently started studying Haskell, to learn the FP paradigm.

I love it, it's really fun, and fits my math background.

But will it ever really matter? Obviously, it's hardly a new idea.

Here's my questions:

  1. What has contributed to the recent FP enthusiasm? Is is merely boredom with OO, or has something changed to make FP more needed than before?
  2. Is this indicative of a FP future? Or is this a fad, like object orient databases?

In other words, can anyone help me understand where this comes from and where it might be going?

  • 1
    possible duplicate of Functional Programming vs. OOP Commented Nov 19, 2010 at 12:39
  • 13
    Not a duplicate - this is asking why people are suddenly making a fuss, since it's not a new idea, (whilst that question is asking more for objective differences). Commented Nov 19, 2010 at 12:52
  • 2
    People are making a fuss over FP lately? News to me, I thought this was always the case that some group was making a fuss about how FP is going to take over the imperative programming world.
    – Chris
    Commented Nov 19, 2010 at 14:24
  • 1
    I think I've answered this question on StackOverflow before.
    – Ken Bloom
    Commented Nov 19, 2010 at 17:35
  • 1
    Yeah - FP was already old I think when I was using Scheme as an undergrad at Columbia in 1989. It's the shiny new thing I guess.
    – Tim
    Commented Nov 19, 2010 at 21:55

14 Answers 14


One of the major innovations in FP that has resulted in the "explosion" of interest is monads.

In January of 1992, Philip Wadler wrote a paper called The Essence of Functional Programming which introduced monads into functional programming as a way to deal with IO.

The major problem with pure, lazy, functional programming languages was utility in dealing with IO. It's one of member of the "Awkward Squad" in programming, because "laziness and side effects are, from a practical point of view, incompatible. If you want to use a lazy language, it pretty much has to be a purely functional language; if you want to use side effects, you had better use a strict language." Reference

The issue with IO before monads was that maintaining purity was not possible for programs that were actually useful for anything. By IO, we mean anything that deals with changing state, including getting input and output from the user or environment. In pure functional programming, everything is immutable, to allow laziness and purity (free from side effects).

How do monads solve the problem of IO? Well, without discussing monads too much, they basically take the "World" (the runtime environment) as input to the monad, and produce a new "World" as output, and the result: type IO a = World -> (a, World).

FP has therefore entered more and more into the mainstream, because the biggest problem, IO (and others) has been solved. Integration into existing OO languages has also been happening, as you know. LINQ is monads, for example, through and through.

For more information, I recommend reading about monads and the papers referenced in my answer.

  • Extremely informative, thanks. I'm accepting this answer, not because it is right and others are wrong (I've upvoted several) but because I think it deserves the resulting visibility. Commented Nov 19, 2010 at 17:03
  • A more relevant example would be type IO a = UI -> (a, UI) a fantastic answer though. Commented Nov 19, 2010 at 17:27
  • @Richard: "type IO a = World -> (a, World)" sounds almost too good to be true (I thought I'd never get monads). I guess you liken LINQ to monads because when you pass a lambda into a LINQ operator, the lambda "sees" its entire environment, is that right? Commented Nov 19, 2010 at 18:54
  • @Stefan: It sounds somewhat accurate to say the lambda sees it's environment, but I'm not 100% clear on that, so I hesitate to answer until I learn more myself. However, I can say with 100% certainty, that LINQ is monads, because the creators have said so on many occasions. SelectMany is exactly equivalent to Bind in Haskell. If you haven't read "The Marvels of Monads" (blogs.msdn.com/b/wesdyer/archive/2008/01/11/…) I highly recommend it ... it'll reveal how LINQ is really monads. Cheers. Commented Nov 22, 2010 at 15:40
  • 1
    @Job, See blogs.msdn.com/b/wesdyer/archive/2008/01/11/… as referenced in the comment above. Commented May 20, 2011 at 12:11

One of the major problems when programming traditional languages like C, Java, C#, assembler etc. is that you have an awkward sequence of steps you have to take in order to accomplish a given task because you need to have prepared all the dependencies first and THEIR dependencies earlier

An example: In order to do A, you must have B and C present, and B depends on D and E, resulting in something like

  • D
  • E
  • C
  • B
  • A

because you have to have the ingredients prepared before you can use them.

Functional languages, especially the lazy ones, turn this one upside down. By letting A say it needs B and C, and let the language runtime figure out when to get B and C (which in turn requires D and E) all of which are evaluated when needed to evaluate A, you can create very small and concise building blocks, which result in small and concise programs. The lazy languages also allows using infinite lists as only the elements actually used are calculated, and without needing to store the whole datastructure in memory before being able to use it.

The really nice trick, is that this automatic "oh, I need a B and a C" mechanism is scalable because there is no restriction - as in the sequential program - about where and when this evaluation can happen, so it can happen at the same time and even on different processors or computers.

That's why functional languages are interesting - because the "what to do when" mechanism is taken over by the runtime system as opposed to the programmer having to do it manually. This is as important a difference as the automatic garbage collection was for Java to C, and one of the major reasons why it is easier to write robust, scalable multi-threaded software in Java than in C. It is even easier to write robust, scalable multi-threaded software in functional languages...

  • 3
    This was true in 1950, of course. Commented Nov 19, 2010 at 15:17
  • 1
    @FarmBoy, not really, but it is today.
    – user1249
    Commented Nov 19, 2010 at 15:39
  • 5
    How does this differ from Dependency Injection?
    – Bill K
    Commented Nov 19, 2010 at 17:15
  • 2
    @Bill K, excellent observation - I had not made that connection myself. The difference is that the objects to be injected - at least in Java - are eagerly evaluated, and not lazily evaluated. You cannot inject an infinite list.
    – user1249
    Commented Nov 19, 2010 at 21:35
  • 1
    @Thorbjørn Ravn Andersen I'm not quite sure I understand why an infinite list would be useful, can you actually do sum of (infinite list) type operations? Seems very unlikely. Otherwise it just sounds like the way Java uses iterators, you just code the iterator in such a way that it only instantiates the objects when you ask for them--not quite infinite, but never-ending (there is a BIG difference, eh?)
    – Bill K
    Commented Nov 19, 2010 at 22:40

In the late 80ies/early 90ies computers became powerful enough for Smalltalk-style OOP. Nowadays computers are powerful enough for FP. FP is programming at a higher-level und thus often - while more pleasant to program in - not the most efficient way do solve a certain problem. But computers are so fast that you don't care.

Multi-core prorgamming can be easier with purely functional programming languages since you are forced to isolate state-changing code.

Also programming language borders are blurred today. You don't have to give up one paradigm if you want to use another. You can do FP in most popular languages so the entry barrier is low.

  • 6
    Was going to add an answer, but you hit my point in your last sentence; Functional Programming is going to become more and more prevalent as the number of cores in a single machine goes up. The inherent lack of state makes it easier to mechanically split functional programs across processors (meaning that if you have a purely functional program, a compiler can theoretically take care of the parallelism for you with minimal effort on your part see youtube.com/watch?v=NWSZ4c9yqW8 for a discussion of data parallelism).
    – Inaimathi
    Commented Nov 19, 2010 at 13:45
  • 1
    @Inaimathi Ditto. Functional programming is very scalable, so it makes sense on multi-core architectures. Commented Nov 19, 2010 at 13:59
  • Note that my first comment was written before the answer was edited to contain an additional statement.
    – Inaimathi
    Commented Nov 19, 2010 at 14:53
  • Sorry for that. I just forgot this point. Commented Nov 19, 2010 at 14:58
  • Is it really generally accepted that functional compilers cannot produce machine code just as optimized as an OOPS? I cannot think of any theoretical reason why that must be true; and I can think of ways that more advanced optimizations are possible than in an OOPS.
    – Jeremy
    Commented Nov 19, 2010 at 20:56

Todays need for distributed computing.

FP uses functions as building blocks, which don't have state, so invoking them n times with the same parameters should return the same value always, they don't have side effects.

Thus, you can send the same function to a bunch of machines to perform and have the doing the work in parallel.

In OO paradigm, this is a bit harder, because the building blocks are objects, which are almost by definition stateful. If you invoke several times the same method, you have to be careful in synchronizing the internal data, to avoid data corruption. While still possible, the FP paradigm works better than the OO in some scenarios where computation has to be distributed.

The advent of FP ( and NoSQL at some extent ) comes after the stories about amazing computing results in hundreds of thousands of computers working in parallel, and how easy it is.

But probably this is only a niche the kind of applications that need this kind of setup. For many, many other applications/systems, procedural and OO work just fine.

So is all about to expand our programming horizons and re-take these concepts we once thought wouldn't go beyond academia.

I learned to program in Lisp years ago, and back then I didn't knew that was even FP. By now I have forgotten almost everything about it, but certainly help me to understand concepts like recursion very easily.

  • 2
    The question is asking about advantages of FP-like languages. What you described can be done using traditional languages as well.
    – Pacerier
    Commented Aug 26, 2014 at 18:46

We're moving to an era where multi-core processing isn't just something done in the back rooms of science labs or on specialty hardware. It's now being done with commodity processors. Functional programming, at least most of the variants I've been exposed to, generally attempts to push a view on side-effect free, stateless computational units. This is the quintessential paradigm for multi-core work as there is no need to keep state commingled between processors.

This is only one of the reasons but a damn good reason to see functional programming taking hold.


I think the main answer to that question is 'exposure'.

Functional programming is nothing new, I was taught Haskell at university some 12 years ago and loved it. But rarely got to use the language in my professional work.

Recently there have been a number of languages gaining traction in the main stream that use a multi-paradigm approach; F#, JavaScript being prime examples.

JavaScript in particular, especially when used with a functional-style framework language like jQuery or Prototype, is becoming an everyday language for many people due to all the work on dynamic modern websites. This exposure to the functional style makes people realise the power it grants, especially when one is able to drop back to an imperative style at will.

Once people are exposed, they try out more fully fledged variants of functional languages and start to use them for day-to-day tasks.

With F# becoming a first-class language in Visual Studio 2010 and jQuery (et al) becoming so important, it is becoming realistic to use these languages, rather than just something obscure to play with or make isolated programs.

Remember that code has to be maintainable - a critical mass of developers must use and support languages in order for companies to feel safe in using them.


In this talk Anders Hejlsberg explains his view on the topic.


Sorry, the link was wrong. Now it points to the right place.

Extremely short summary of some points of the one-hour-talk:

Functional languages allow for a more declarative style of programming than procedural languages, so programs written in FLs usually concentrate more on the what instead of the how. Because of their elegant mathematical structure FLs are also easier to optimize and transform by compilers, which also enables easy meta-programming and the construction of embedded DSLs. All this together makes funtional programs more succinct and self-documenting than procedural programs.

Also, in the face of the manycore era of the near future, programming languages need to be able to utilize multi threading/processing in different ways. Multi threading on single core machines was in effect a time sharing mechanism, and the architecture of systems reflected this. Multi threading on manycore machines will be very different. Funcional languages are especially suitable for parallelization, since they mostly avoid state, so one needn't worry as much about the integrity of shared mutable data (because there tend to be no shared mutable data).

  • 1
    Could you summarize?
    – user1249
    Commented Nov 19, 2010 at 13:44
  • 1
    @Thorbjorn That reminds me of the man who could not summarize. (Not directing that at you, answer author.)
    – Mark C
    Commented Nov 19, 2010 at 14:02
  • 1
    The link doesn't even link to the right place.
    – Ken Bloom
    Commented Nov 19, 2010 at 17:46

I think it is to do with the close correlation between the functional programming paradigm and programming for the web.

Ruby on Rails brought the whole functional programming approach into sharp relief since it offered a very quick path to a functional (heh heh) web application. There is an interesting discussion on SO about this, and one particular answer stands out:

Functional programming matches web apps very well. The web app recieves a HTTP request and produces a HTML result. This could be considered a function from requests to pages.

Compare with desktop apps, where we typically have a long running process, a stateful UI and dataflow in several directions. This is more suited to OO which is concerned about objects with state and message passing.

Given that functional programming has been around for ages, I wonder why I don't see many job adverts looking for Lisp developers for greenfield web projects.

  • I think functional analogy applies to web only incidentally, for the underlying protocol is stateless. Web applications aren't really stateless, which is in fact a reason that we always have to work around HTTP somehow. Commented Nov 19, 2010 at 14:57
  • @Mladen Hmmm, is it possible that you are conflating client-server communication state (HTTP) with application state (DAOs etc)? Quoting Stefan Tilkov from here (codemonkeyism.com/stateless-applications-illusion) "In a web application each individual request should contain enough information to be processable independently of whether or not a previous request did or did not occur. Persistent server-side resource state is fine, client-side state is fine, transient communication (session) state isn’t because it’ll ruin scalability and bookmarkability." This is the basis of REST.
    – Gary
    Commented Nov 19, 2010 at 15:22
  • 1
    you may want to read paulgraham.com/avg.html to get a better understanding of why there are not many job adverts looking for Lisp developers.
    – user1249
    Commented Nov 19, 2010 at 16:49
  • @Thorbjørn Ravn Andersen Good article. Inspires me to break out my Lisp editor.
    – Gary
    Commented Nov 19, 2010 at 17:18

Functional programming gives me the same tingling sense of "wow, this is new" as when I first started dabbling with objects years ago.

I realize that FP is not a new concept by far, but neither was OO when it got its real break in the nineties when "everyone" suddenly jumped ship from procedural programming. This was largely due to the timely success of Java and later C#.

I imagine the same thing will happen with FP eventually once the next batch of languages starts spreading in the same way. Much as they already have, at least in some circles, with languages like Scala and F#.

  • OO is far younger than FP, but it got into the limelight far before. i guess the parenthesis scared too much people
    – Javier
    Commented Nov 19, 2010 at 17:15

Here's my questions: 1. What has contributed to the recent FP enthusiasm? Is is merely boredom with OO, or has something changed to make FP more needed than before? 2. Is this indicative of a FP future? Or is this a fad, like object orient databases?

Others have given good technical reason.

I think the main reason FP is gaining traction among the average developer and manager types is it's promise to allow better use of multi-core CPUs. From everything I have read FP allows easier (not easy) parallel programming.

It's future widespread use will be if the promise is real and is fulfilled.

  • That's a big "if". COBOL, being "in English" was going to mean anybody could program. AI was going to make programming obsolete. OO was going to make programming as simple as assembling tinkertoys. Coders are like rock groupies, always looking for the "next big thing", and the one after that, and the one ... Commented Nov 20, 2010 at 20:08

I think it's a combination of two trends:

  1. Functional features being added to mainstream languages (e.g. C#).
  2. New functional languages being created.

There's probably a natural limit on the first trend, but my guess is that any new language will have to support functional programming, at least as an option, in order to be taken seriously.


It used to be that people were writing programs to run on the desktop using the operating system's native APIs, and those APIs were (generally) written in C, so for the most part if you wanted to write a program for the native APIs, you wrote that program in C.

I think the new innovation in the last 10 years or so is for a diversity of APIs to catch on, particularly for things like web development where the platform APIs are irrelevant (since constructing a web page basically involves string manipulation). Since you're not coding directly to the Win32 API or the POSIX API, that gives people the freedom to try out functional languages.


It's neaty and nifty and tickles your brain. That's fine.

It's also, IMHO, a classic bandwagon. A solution looking for a problem.

It's like all those startup companies founded by engineers dazzled with a favorite idea, that burn brightly for a while, but are quietly overtaken by companies founded on providing what is needed.

That's the new idea I would like to see take off, need-based programming, not nifty-idea-based programming. Maybe that sounds mundane, but I think it can in fact be pretty creative, and nifty.


Definitely because of F#, though sometimes it is hard to tell which one is the cause and which one is the effect.

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