Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as not constructive by ChrisF Jan 30 '12 at 22:54

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
possible duplicate of Functional Programming vs. OOP –  Amir Rezaei Nov 19 '10 at 12:39
11  
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). –  Peter Boughton Nov 19 '10 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 Nov 19 '10 at 14:24
1  
I think I've answered this question on StackOverflow before. –  Ken Bloom Nov 19 '10 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 Nov 19 '10 at 21:55
show 2 more comments

14 Answers

up vote 26 down vote accepted

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.

share|improve this 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. –  Eric Wilson Nov 19 '10 at 17:03
    
A more relevant example would be type IO a = UI -> (a, UI) a fantastic answer though. –  ChaosPandion Nov 19 '10 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? –  Stefan Monov Nov 19 '10 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. –  Richard Hein Nov 22 '10 at 15:40
    
I started to like FP because of Clojure. LINQ is many things. How is it a monad? It is generators IMO. –  Job May 20 '11 at 2:13
show 1 more comment

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

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

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.

share|improve this answer
5  
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 Nov 19 '10 at 13:45
    
@Inaimathi Ditto. Functional programming is very scalable, so it makes sense on multi-core architectures. –  EricBoersma Nov 19 '10 at 13:59
    
Note that my first comment was written before the answer was edited to contain an additional statement. –  Inaimathi Nov 19 '10 at 14:53
    
Sorry for that. I just forgot this point. –  LennyProgrammers Nov 19 '10 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 Nov 19 '10 at 20:56
add comment

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

share|improve this answer
    
OO is far younger than FP, but it got into the limelight far before. i guess the parenthesis scared too much people –  Javier Nov 19 '10 at 17:15
add comment

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.

share|improve this answer
    
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. –  Mladen Jablanović Nov 19 '10 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 Rowe Nov 19 '10 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 Nov 19 '10 at 16:49
    
@Thorbjørn Ravn Andersen Good article. Inspires me to break out my Lisp editor. –  Gary Rowe Nov 19 '10 at 17:18
add comment

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

share|improve this answer
2  
This was true in 1950, of course. –  Eric Wilson Nov 19 '10 at 15:17
1  
@FarmBoy, not really, but it is today. –  user1249 Nov 19 '10 at 15:39
3  
How does this differ from Dependency Injection? –  Bill K Nov 19 '10 at 17:15
1  
@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 Nov 19 '10 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 Nov 19 '10 at 22:40
show 6 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 ... –  Mike Dunlavey Nov 20 '10 at 20:08
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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