Why the current enthusiasm for Functional Programming? [closed]

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

[EDIT]

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

Answer 8

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.

Answer 9

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

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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