I see a lot of talk on here about functional languages and stuff. Why would you use one over a "traditional" language? What do they do better? What are they worse at? What's the ideal functional programming application?

+5  A: 

One key feature in a functional language is the concept of first-class functions. The idea is that you can pass functions as parameters to other functions and return them as values.

Functional programming involves writing code that does not change state. The primary reason for doing so is so that successive calls to a function will yield the same result. You can write functional code in any language that supports first-class functions, but there are some languages, like Haskell, which do not allow you to change state. In fact, you're not supposed to make any side effects (like printing out text) at all - which sounds like it could be completely useless.

Haskell instead employs a different approach to IO: monads. These are objects that contain the desired IO operation to be executed by your interpreter's toplevel. At any other level they are simply objects in the system.

What advantages does functional programming provide? Functional programming allows coding with fewer potentials for bugs because each component is completely isolated. Also, using recursion and first-class functions allows for simple proofs of correctness which typically mirror the structure of the code.

Kyle Cronin
+24  A: 

Functional languages use a different paradigm than imperative and object oriented languages. They use side effect free functions as a basic building block in the language. This enables lots of things and makes a lot of things more difficult (or in most cases different from what people are used to)

One of the biggest advantages with functional programming is that the order of execution of side effect free functions is not important. For example in erlang this is used to enable concurrency in a very transparent way. And because functions in functional languages behave very similar to mathematical functions it's easy to translate those into functional languages. In some cases this can make code more readable.

Traditionally one of the big disadvantages of functional programming was also the lack of side effects. It's very difficult to write useful software without IO, but IO is hard to implement without side-effects in functions. So most people never got more out of functional programming than calculating a single output from a single input. In modern mixed paradigm languages like F# or scala this is easier.

Lots of modern languages have elements from functional programming languages. C# 3.0 has a lot functional programming features and you can do functional programming in python too. I think the reasons for the popularity of functional programming is mostly because of two reasons. Concurrency is getting a real problem in normal programming because we're getting more and more multiprocessor computers. And the languages are getting more accessible.

You CAN do functional programming in python, but it's really terrible.

In addition to the other answers, casting the solution in pure functional terms forces one to understand the problem better. Conversely, thinking in a functional style will develop better* problem solving skills.

*Either because the functional paradigm is better or because it will afford an additional angle of attack.

Rodrick Chapman
+2  A: 

Checkout Why Functional Programming Matters

+6  A: 

I must be dense, but I still don't get it. Are there any actual examples of small app's written in a functional language like F# where you can look at the source code and see how and why it was better to use such an approach than, say, C#?

Mike at KBS
Good remark +1. @Mendelt: "more accessible" ? Do you mean the headache is quicker when you watch the code ?
+78  A: 

The main plus for me is its inherent parallelism, especially as we are now moving away from more MHz and towards more and more cores.

I don't think it will become the next programming paradigm and completely replace OO type methods, but I do think we will get to the point that we need to either write some of our code in a functional language, or our general purpose languages will grow to include more functional constructs.

Steven Robbins
We already are seeing this happening. And it will happen more in the future. So I agree 100% on this point.
Jason Baker
The tricky thing is that it's the shared nothing / no side-effects aspects of FP that make it so suitable for parallelism. And those are the aspects that don't sit well with OO solutions - making effective hybrids is *extremely* hard. Perhaps FP glue between OO nodes?
Alabaster Codify
For an effective hybrid have a look at the 2.0 branch of the D programming language. It's an alpha/work in progress, but it's getting there.
I found this answer interesting, I don't know any functional language, why are they considered more proper for parallelism?
Since there's no shared data, functions have no side-effects. All you care about is the return value. (This is quite a hard idea for an OO/procedural programmer to get her head round.) Many functions can therefore be called at once, as long as the output from one isn't used as the input to another.
Tom Smith
+1  A: 

I'm actually learning LISP after reading Hackers and Painters and I do believe I will LEARN something from LISP that will give me a better undertanding of everything else I program. Now I dont think I will actually be using LISP in my everyday just because some guy in 1995 created a website that became Yahoo Stores. So its a win-win anyway (if it catches on I win if not, I get more points of views on how to program and how stuff works)

Now... on another question kinda related, do I think programming will change a lot with 32 cores procs arriving next year? YES, I dont know if it will be functional programming but... im pretty sure there will be something diferent!

Could you please use capital I 's? it's driving me insane...
Eran Galperin
I did it for him (and you)
+2  A: 

I agree with the first point, but times change. Corporations will respond, even if they're late adopters, if they see that there's an advantage to be had. Life is dynamic.

They were teaching Haskell and ML at Stanford in the late 90s. I'm sure that places like Carnegie Mellon, MIT, Stanford, and other good schools are presenting it to students.

I agree that most "expose relational databases on the web" apps will continue in that vein for a long time. Java EE, .NET, RoR, and PHP have evolved some pretty good solutions to that problem.

You've hit on something important: It might be the problem that can't be solved easily by other means that will boost functional programming. What would that be?

Will massive multicore hardware and cloud computing push them along?

+15  A: 

Most applications are simple enough to be solved in normal OO ways

1) OO ways have not always been "normal." This decade's standard was last decade's marginalized concept.

2) Functional programming is math. Paul Graham on Lisp (substitute functional programming for Lisp):

So the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn’t get stale. The right thing to compare Lisp to is not 1950s hardware, but, say, the Quicksort algorithm, which was discovered in 1960 and is still the fastest general-purpose sort.

Michael Paulukonis
+38  A: 

Even if you never work in a functional language professionally, understanding functional programming will make you a better developer. It will give you a new perspective on your code and programming in general.

I say there's no reason to not learn it.

I think the languages that do a good job of mixing functional and imperative style are the most interesting and are the most likely to succeed.

Good point, but I'd like to see an explanation of "in what way will it make you a better developer"
Different programming paradigms approach problems from different angles and often require a "different way of thinking" or mindset. And training yourself in multiple different ways of thinking (implying learning which one to use in which situation...) is never a bad thing.
+3  A: 

Most application can be solved in [insert your favorite language, paradigm, etc. here].

Although, this is true, different tools can be used to solve different problems. Functional just allows another high (higher?) level abstraction that allows to do our jobs more effectively when used correctly.

+1  A: 

It's not really taught at universities (or is it nowadays?)

I don't know about nowadays, but I was taught both Miranda and Lisp as part of my CS course in the mid 1990s. Despite not using a pure functional language since, it has influenced the way I solve problems.

Most applications are simple enough to be solved in normal OO ways

In the same mid '90s CS course, OO (taught using Eiffel) was taught pretty much on a par with functional programming. Both were non-mainstream at the time. OO may be "normal" now, but it was not ever thus.

I'll be interested to see whether F# is the thing that pushes FP into the mainstream.

gosh yes, i forgot Miranda - did that too...
+3  A: 

I think one reason is that some people feel that the most important part of whether a language will be accepted is how good the language is. Unfortunately, things are rarely so simple. For example, I would argue that the biggest factor behind Python's acceptance isn't the language itself (although that is pretty important). The biggest reason why Python is so popular is its huge standard library and the even bigger community of 3rd party libraries.

Languages like Clojure or F# may be the exception to the rule on this considering that they're built upon the JVM/CLR. As a result, I don't have an answer for them.

Jason Baker
+1 but don't forget the power of marketing, and the fact that your company's mountain of legacy code isn't going to switch languages by virtue of some cool new trend.
And you forgot to mention: Google is popularizing python.
Hao Wooi Lim
+7  A: 

F# could catch on because Microsoft is pushing it.


  • F# is going to be part of next version of Visual Studio
  • Microsoft is building community for some time now - evangelists, books, consultants that work with high profile customers, significant exposure at MS conferences.
  • F# is first class .Net language and it's the first functional language that comes with really big foundation (not that I say that Lisp, Haskell, Erlang, Scala, OCaml do not have lots of libraries, they are just not as complete as .Net is)
  • Strong support for parallelism


  • F# is very hard to start even if you are good with C# and .Net - at least for me :(
  • it will probably be hard to find good F# developers

So, I give 50:50 chance to F# to become important. Other functional languages are not going to make it in near future.

I'd argue that Scala was a pretty deep foundation with the JRE.
Regarding libraries, it really depends what you're doing. F# is targeted at the finance sector and is also applicable to scientific computing but OCaml actually has far better libraries for such applications than .NET. For example, when I came to F# from OCaml I failed to find a decent FFT and ended up writing (and selling) my own in C# and then F#.
Jon Harrop
LINQ is a good bridge to using functional concepts with C# and VB.Net... And I find it to be much less painful to read when compared to F#
Matthew Whited
+1  A: 

Because FP has significant benefits in terms of productivity, reliability and maintainability. Many-core may be a killer app that finally gets big corporations to switch over despite large volumes of legacy code.Furthermore, even big commercial languages like C# are taking on a distinct functional flavour as a result of many-core concerns - side effects simply don't fit well with concurrency and parallelism.

I do not agree that "normal" programmers won't understand it. They will, just like they eventually understood OOP (which is just as mysterious and weird, if not more so).

Also, most universities do teach FP, many even teach it as the first programming course.

Sorry, but FP has been around almost 3 times as long as OOP. This simply isn't a matter of needing more time. It will take something more to make FP mainstream.
Jason Baker
How could you miss the part of my post where I explain that the "something more" could very well be many-core?And something "being around" isn't really relevant. People understood OOP because it offered tangible benefits at the time, FP has only recently become practical.
+7  A: 

The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it

That one is just a matter of time though. Your average corporate programmer learns whatever the current Big Thing is. 15 years ago, they didn't understand OOP. IF FP catches on, your "average corporate programmers" will follow.

It's not really taught at universities (or is it nowadays?)

Varies a lot. At my university, SML is the very first language students are introduced to. I believe MIT teaches LISP as a first-year course. These two examples may not be representative, of course, but I believe most universities at the very least offer some optional courses on FP, even if they don't make it a mandatory part of the curriculum.

Most applications are simple enough to be solved in normal OO ways

It's not really a matter of "simple enough" though. Would a solution be simpler (or more readable, robust, elegant, performant) in FP? Many things are "simple enough to be solved in Java", but it still requires a godawful amount of code.

In any case, keep in mind that FP proponents have claimed that it was the Next Big Thing for several decades now. Perhaps they're right, but keep in mind that they weren't when they made the same claim 5, 10 or 15 years ago.

One thing that definitely counts in their favor, though, is that recently, C# has taken a sharp turn towards FP, to the extent that it's practically turning a generation of programmers into FP programmers, without them even noticing. That might just pave the way for the FP "revolution". Maybe. ;)

MIT _used_ to teach Scheme in its intro CS course, but it uses Python now.
"15 years ago, they didn't understand OOP" - The problem is that 15 years ago, they didn't understand FP either. And they still don't today.
Jason Baker
+1  A: 

Functional Programming has already caught on IMHO, it's just not very visible yet. The strength of such languages is mathematics/algorhithms, which is one of the reasons why the Halo Guys use it for their TrueSkill stuff.

Or, as some guy put it: F# should be the lingua-franca of BI.

Michael Stum
+3  A: 

It seems to me that those people who never learned Lisp or Scheme as an undergraduate are now discovering it. As with a lot of things in this field there is a tendency to hype and create high expectations...

It will pass.

Functional programming is great. However, it will not take over the world. C, C++, Java, C#, etc will still be around.

What will come of this I think is more cross-language ability - for example implementing things in a functional language and then giving access to that stuff in other languages.

C# is now a functional programming language (as much as Lisp) because it has first-class lexical closures. Indeed, they are already used in WPF and the TPL. So functional programming is obviously already here.
Jon Harrop
+1  A: 

Things have been moving in a functional direction for a while. The two cool new kids of the past few years, Ruby and Python, are both radically closer to functional languages than what came before them — so much so that some Lispers have started supporting one or the other as "close enough."

And with the massively parallel hardware putting evolutionary pressure on everyone — and functional languages in the best place to deal with the changes — it's not as far a leap as it once was to think that Haskell or F# will be the next big thing.


Have you been following the evolution of programming languages lately? Every new release of all mainstream programming languages seems to borrow more and more features from functional programming.

  • Closures, anonymous functions, passing and returning functions as values used to be exotic features known only to Lisp and ML hackers. But gradually, C#, Delphi, Python, Perl, Javascript, have added support for closures. Its not possible for any up-and-coming language to be taken seriously without closures.

  • Several languages, notably Python, C#, and Ruby have native support for list comprehensions and list generators.

  • ML pioneered generic programming in 1973, but support for generics ("parametric polymorphism") has only become an industry standard in the last 5 years or so. If I remember correctly, Fortran supported generics in 2003, followed by Java 2004, C# in 2005, Delphi in 2008. (I know C++ has supported templates since 1979, but 90% of discussions on C++'s STL start with "here there be demons".)

What makes these features appealing to programmers? It should be plainly obvious: it helps programmers write shorter code. All languages in the future are going to support -- at a minimum -- closures if they want to stay competitive. In this respect, functional programming is already in the mainstream.

Most applications are simple enough to be solved in normal OO ways

Who says can't use functional programming for simple things too? Not every functional program needs to be a compiler, theorem prover, or massively parallel telecommunications switch. I regularly use F# for ad hoc throwaway scripts in addition to my more complicated projects.

+88  A: 

I don't think that there's any question about the functional approach to programming "catching on", because it's been in use (as a style of programming) for about 40 years. Whenever an OO programmer writes clean code that favors immutable objects, that code is borrowing functional concepts.

However, languages that enforce a functional style are getting lots of virtual ink these days, and whether those languages will become dominant in the future is an open question. My own suspicion is that hybrid, multi-paradigm languages such as Scala or OCaml will likely dominate over "purist" functional languages in the same way that pure OO language (Smalltalk, Beta, etc.) have influenced mainstream programming but haven't ended up as the most widely-used notations.

Finally, I can't resist pointing out that your comments re FP are highly parallel to the remarks I heard from procedural programmers not that many years ago:

  • The (mythical, IMHO) "average" programmer doesn't understand it.
  • It's not widely taught.
  • Any program you can write with it can be written another way with current techniques.

Just as graphical user interfaces and "code as a model of the business" were concepts that helped OO become more widely appreciated, I believe that increased use of immutability and simpler (massive) parallelism will help more programmers see the benefits that the functional approach offers. But as much as we've learned in the past 50 or so years that make up the entire history of digital computer programming, I think we still have much to learn. Twenty years from now, programmers will look back in amazement at the primitive nature of the tools we're currently using, including the now-popular OO and FP languages.

Just look 20 years back. I don't thing programming has evolved much. Well have better tools, maybe a new language or 2 but fundamentally not much will change. This will take more than 20 years. We all once thought we would see flying cars in 2000. :)
"Twenty years from now..." Isn't that how it always works? It is a good time to be alive, with so much rapid improvement in pretty much every field.
Alex Baranosky
From Henry Baker: the Algol/Fortran world complained for ages that they didn't see what possible use function closures would have inefficient programming of the future. Then the 'OO revolution' happened, and now everyone programs using function closures, but they still refuse to to call them that.
Norman Ramsey
I didn't realize OCaml was Irish. :)
Mark Maxham
OCaml is french.
O'Caml is Irish though.
I don't like this implication that "clean code" is a functional concept.
alex strange
@alex strange: "Favor immutability" and "avoid side effects" have been good rules of thumb for quite a while in both object-oriented and imperative programming schools. (So what's not to like? ;-)
@bibac: 20 years ago we were writing C code, and discussing the merits of Clipper or Turbo Pascal. Object Orientation was the exclusive realm of academics. To propose that little has changed is downright absurd.
And the tools for programming were nothing like the tools we have now.
Alex Baranosky
@Daniel: Please provide a list of these people who argued for the "merits" of Clipper. They need to be hunted down and brought to justice.
+6  A: 

I don't think most realistic people think that functional programming will catch on (becomes the main paradigm like OO). After all, most business problems are not pretty math problems but hairy imperative rules to move data around and display them in various ways, which means it's not a good fit for pure functional programming paradigm (the learning curve of monad far exceeds OO.)

OTOH, functional programming is what makes programming fun. It makes you appreciate the inherent, timeless beauty of succinct expressions of the underlying math of the universe. People say that learning functional programming will make you a better programmer. This is of course highly subjective. I personally don't think that's completely true either.

It makes you a better sentient being.

I don't think that OO is inherently easier than FP. It really depends on your background (I'm a math guy, guess what I find much easier? :) Damn you OO people and your insane rules.
Monads aren't hard to understand. Don't buy in to that bullcrap.
-1 OOP is harder than FP
just somebody
+1  A: 

Wow - this is an interesting discussion. My own thoughts on this:

FP makes some tasks relatively simple (compared to none-FP languages). None-FP languages are already starting to take ideas from FP, so I suspect that this trend will continue and we will see more of a merge which should help people make the leap to FP easier.

Pete OHanlon
+32  A: 

I'm always skeptical about the Next Big Thing. Lots of times the Next Big Thing is pure accident of history, being there in the right place at the right time no matter whether the technology is good or not. Examples: C++, Tcl/Tk, Perl. All flawed technologies, all wildly successful because they were perceived either to solve the problems of the day or to be nearly identical to entrenched standards, or both. Functional programming may indeed be great, but that doesn't mean it will be adopted.

But I can tell you why people are excited about functional programming: many, many programmers have had a kind of "conversion experience" in which they discover that using a functional language makes them twice as productive (or maybe ten times as productive) while producing code that is more resilient to change and has fewer bugs. These people think of functional programming as a secret weapon; a good example of this mindset is Paul Graham's Beating the Averages. Oh, and his application? E-commerce web apps.

Since early 2006 there has also been some buzz about functional programming and parallelism. Since people like Simon Peyton Jones have been worrying about parallelism off and on since at least 1984, I'm not holding my breath until functional languages solve the multicore problem. But it does explain some of the additional buzz right about now.

In general, American universities are doing a poor job teaching functional programming. There's a strong core of support for teaching intro programming using Scheme, and Haskell also enjoys some support there, but there's very little in the way of teaching advanced technique for functional programmer. I've taught such a course at Harvard and will do so again this spring at Tufts. Benjamin Pierce has taught such a course at Penn. I don't know if Paul Hudak has done anything at Yale. The European universities are doing a much better job; for example, functional programming is emphasized in important places in Denmark, the Netherlands, Sweden, and the UK. I have less of a sense of what's happening in Australasia.

Norman Ramsey
I don't know about the UK universities. You're more than likely to find that many universities over here teach very few programming languages (Java, C, maybe Perl if you're lucky). The problem over here is the difference in quality, as the best (few) universities have the best CS programmes.
I disagree the examples you gave are flawed, niche perhaps, or suited for certain areas, but general purpose enough to be taken up universally without a massive learning curve. that's probably the biggest reason they're so successful.
I did Forth and Lisp at uni in the UK (as well as Pascal, C, Modula2 and Cobol) but that was 20 years ago..
@gbjbaanb: Plenty of stuff has been "general purpose enough to be taken up universally without a massive learning curve" and has not caught on. Examples: Modula-3 died without even leaving a corpse, and Objective C is on life support. Both are much easier to learn than C++ or Perl.
Norman Ramsey
I thought the standard was to initially teach an OO language (C++/Java/C#), and then later on teach a course on the basics of computer languages (i.e. create a compiler, etc) in something like scheme
@John: "OO first" has been popular but seems to be falling out of favor. There's enough variety in compiler courses that I dare not generalize---plus, lots of students never take compilers.
Norman Ramsey
I was taught Java/C++ at uni (in Australia), but a few of my co-workers went to different universities where they did several units in Haskell. It was used both for intro to programming and one of their final year units.I laughed when i heard what my co-worker said to a Java lecturer after he was introduced to casting for the first time (at this point he only knew Haskell) - "What?! You mean you've got something and you don't _KNOW_ what type it is?!"
Jacob Stanley
Look at what happened to C# with all those Europeans in the team :)
Well, at the University of California at Berkeley, the intro course is based on Scheme and starts out concentrating on functional programming. OOP is going to be covered later, but so far it has given me a very good overview of functional languages as well as a good argument for using them. My professor here (Dr Brian Harvey) teaches the material very well and will probably get some people to use functional languages; however, he is retiring, so who knows what will happen next...
Tikhon Jelvis

It has already caught on with Map/reduce in Hadoop


Is FP suitable for UI programming? Maybe it is best to use C# for the UI and F# for the business logic? Can anyone explain?

the state of the ui can just be the result of a calculation. You can recieve input from the ui as a continous stream of input parameters for a calculation. Instead of centrally managed global state, you pass a state object from function to function. It's just a different way of conceptualizing.
It is suitable in general, but most current UI frameworks are not adapted to this way of working. In particular, you would have to forgo the built-in databinding.
Alexey Romanov

I think the biggest argument for functional programming languages to become the "next big thing" is that in the future multi-core processors will be the norm. Programmers will have to take advantage of that, and functional programming offers really wonderful possibilities for building top of the line concurrent software.

P.S. When I was in college at Boston University ('98-'02) we spent a semester learning Scheme which is a close cousin of LISP. When we first started learning it, I wanted to rip my hair out. By the end of the course it was very natural.

Alex Baranosky
I had the same experience at Michigan Tech (2003-2008). About halfway through the semester it "clicked". Unfortunately I haven't had a chance to use Scheme for anything since then (I took that class in 2004, I think).
Adam Jaskiewicz
+17  A: 

I don't see anyone mentioning the elephant in the room here, so I think it's up to me :)

JavaScript is a functional language. As more and more people do more advanced things with JS, especially leveraging the finer points of jQuery, Dojo, and other frameworks, FP will be introduced by the web-developer's back-door.

In conjunction with closures, FP makes JS code really light, yet still readable.

Cheers, PS

That is how I really started to dig functional programming. Nothing is better than Prototype.js's list.Each(function(item){}) or jQuery's whole method of operation.
Cory R. King
Javascript allows one to program in a functional way. It is, however, a cross paradigm language, allowing one to program in a variety of different ways (which I prefer, but that's not relevant)... OO, functional, procedural, etc.
+1, see
just somebody

I don't know whether it will catch on or not, but from my investigations, a functional language is almost certainly worth learning, and will make you a better programmer. Just understanding referential transparency makes a lot of design decisions so much easier- and the resulting programs much easier to reason about. Basically, if you run into a problem, then it tends to only be a problem with the output of a single function, rather than a problem with an inconsistant state, which could have been caused by any of the hundreds of classes/methods/functions in an imparative language with side effects.

The stateless nature of FP maps more naturally to the stateless nature of the web, and thus functional languages lend themselves more easily to more elegant, RESTFUL webapps. Contrast with JAVA and .NET frameworks that need to resort to horribly ugly HACKS like VIEWSTATE and SESSION keys to maintain application state, and maintain the (occasionally quite leaky) abstraction of a stateful imperative language, on an essentially stateless functional platform like the web.

And also, the more stateless your application, the more easily it can lend itself to parallel processing. Terribly important for the web, if your website happens to get popular. It's not always straightforward to just add more hardware to a site to get better performance.

+6  A: 

I bet you didn't know you were functional programming when you used:

Excel formulas

Quartz Composer


Logo (Turtle graphics)

LINQ, SQL... many more
Matthew Whited

I think the answer to your question lies more in the statement, "the right tool for the job", than the hottest thing. There will always be hot new technologies, and there will always be those who jump on them.

Functional languages have been around for a while, it's just now they are getting more press.

+2  A: 

It's catching on because it's the best tool around for controlling complexity. See:
- slides 109-116 of Simon Peyton-Jones talk "A Taste of Haskell"
- "The Next Mainstream Programming Language: A Game Developer's Perspective" by Tim Sweeney

Links to add:
+1  A: 

Uh, sorry to be a pedant, but it has already caught on - we call it Excel.

The vast majority of programmes that run on computers are written in Excel or one of the many popular clones of it.

(there are many programmes that are run many times, and programmes written in Excel tend NOT to be ones of these - most Excel programmes have 1 run instance)

Today, the term "functional programming" means supporting first-class lexical closures and, preferably, tail calls. Excel supports neither.
Jon Harrop

FP is the next best paradigm that is for sure. Now which language could be the next step, That is the hard stuff but I believe could be Haskell, F#, Clojure, Ocaml or Erlang. Or could be Python with more FP constructs and better support for parallelism/performance or also Perl 6 with parrot looks very interesting.

Dem's be fightin' words.
javascript is already catching on.
Cory R. King
+1  A: 
  • How long did it take OOP to get understood by the average corporate programmer...?
  • I was taught functional programming at Utrecht University in - I think - 1994 and only see it start to catch on "in the real world" in the last couple of years.
  • There is no such thing as a "simple application". ;-)

I think that (approaching) side effect free programming for some key parts of software will be essential when we start to get more and more cores in our hardware. Give functional programming a bit more time. And the functional sprinkling in current and future versions of C# will go a long way in preparing those corporate programmers for functional programming without them even realising it...

+2  A: 

My view is that it will catch on now that Microsoft have pushed it much further into the mainstream. For me it's attractive because of what it can do for us, because it's a new challenge and because of the job opportunities it resents for the future.

Once mastered it will be another tool to further help make us more productive as programmers.

+1  A: 

Some thoughts:

  • The debate between FP and imperative programming (OO, structured, etc), has been raging since Lisp versus Fortran. I think you pose excellent questions but recognize that they are not especially new.
  • Part of the hoopla over FP is that we seem to be recognizing that concurrency is very difficult, and that locks and other mechanisms in OO (e.g. Java) are just one solution. FP offers a refreshing sea change with ideas such as Actors and the power of stateless computing. To those wrestling with OO, the landscape seems highly appealing.
  • Yes, schools teach FP. In fact, the University of Waterloo and others offer Scheme in first year classes (reference here).
  • Regarding the average programmer, I'm sure that the same arguments were given against C++ back in the early 1990s. And look what happened. If businesses can gain an advantage via a technology, you can bet that people will receive training.

This is not to say that it is a sure thing, or that there won't be a backlash in 3-5 years (as there always is). However, the trend towards FP has merit and is worth watching.

Michael Easter
+3  A: 

When reading "The Next Mainstream Programming Language: A Game Developer’s Perspective" by Tim Sweeney, Epic Games, my first thought was - I got to learn Haskell.


Google's HTML Version

Janis Veinbergs

There's a great article from Slava Akhmechet called Functional Programming For The Rest of Us (this was the article that got me into FP btw). Amongst the benefits FP brings, he unorthodoxly emphasizes the following (which I believe contributes to the appeal for software engineers):

  • Unit Testing
  • Debugging
  • Concurrency
  • Hot Code Deployment
  • Machine Assisted Proofs and Optimizations

And then goes on to discuss the goodness of more traditionally discussed aspects of FP like higher order functions, currying, lazy evaluation, optimization, abstracting control structures (although not discussing monads), infinite data structures, strictness, continuations, pattern matching, closures and so on.

Highly recommended !


Lots of people have mentioned Functional Languages.

But some of the Most commonly used Functional Languages in use today besides Javascript.

Excel, SQL, XSLT, XQuery, J and K are used in financial realm.

Of course Erlang.

So I would say that from that list that Functional Programming techniques are used in mainstream every day.


Functional Programming will likely be a tool that is used by Engineers, Scientists to solve the problems that they are facing. It isn't going to take the world like earlier langages. However, the hard product to beat is Excel, if I am an engineer and need to do calculations, Excel is awesome.

However, F# is going to be another source and will likely fill design needs by the non-Computer Scientists. Let's face it, Computer Scientists have done a great job of creating a WHOLE new way of doing things. Object Oriented Programming is GREAT. But sometimes you just need a way to solve an equation, get a solution and graph it. That's it. Then a language like F# fills the bill. Or maybe you want to build a finite state machine, F# again could be one of the solutions, but then C could be a solution as well.

But when it comes to parallel processing, Excel shines and in time F# will be there as well. In a friendly manner though, F#= friendly.

+2  A: 

A point missed in the discussion is that the best type systems are found in contemporary FP languages. What's more, compilers can infer all (or at least most) types automatically.

It is interesting that one spends half the time writing type names when programming Java, yet Java is by far not type safe. While you may never write types in a Haskell programm (except as a kind of compiler checked documentation) and the code is 100% type safe.


Microsoft is really pushing F# with the next version on Visual Studio. It is a hybrid language such as Scala and integrates very nicely with the rest of the .net framework. I think a lot of Microsoft shops are going to use it to speed-up the development of highly parallel data-processing applications and functions.


I have a hard time envisioning a purely functional language being the common language of the day, the reasons for which I won't get in to (because they're flame fodder). That being said, programming in a functional way can provide benefits no matter the language (if it allows such). For me, it's the ability to test my code much easier. I work with databases a lot... I tend to:

  1. write a function that takes data, manipulates it, and returns data
  2. write a dead simple wrapper that calls the database and then returns the result of passing that data through my function

Doing so allows me to write unit tests for my manipulation function, without the need to create mocks and the like.

I do think purely functional languages are very interesting... I just think it's what we can learn from them that matters to me, not what we can do with them.


I'd point out that everything you've said about functional languages, most people were saying about object-oriented langauges about 20 years ago. Back then it was very common to hear about OO:

* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways

Change has to come from somewhere. A meaningful and important change will make itself happen regardless of whether people trained in earlier technologies take the opinion that change isn't necessary. Do you think the change to OO was good despite all the people that were against it at the time?


I personally think for distributed systems and multi-threaded/parallel programming functional programming will have a break-through soon. As long as it integrates with existing OOP paradigms through programming libraries. So... the purely functional approach - in my opinion - will remain academic.


Functional programming has been around for a long time, since LISP was one of the earliest languages to have a compiler, and since MIT's LISP machines. It's not a new paradigm (OO is much newer) but the dominant software platforms have tended to be written in languages that translate easily to assembly language, and their APIs heavily favor imperative code (UNIX with C, Windows with C, and Macintosh with Pascal and later C).

I think the new innovation in the last few years is for a diversity of APIs to catch on, particularly for things like web development where the platform APIs are irrelevant. Since you're not coding directly to the Win32 API or the POSIX API, that gives people the freedom to try out functional languages.

Ken Bloom
Agreed. The age of the rich API is starting, and it is a powerful concept when done right. But OOP is not quite the right language technology to support it. LINQ is good example of things to come - a functional programming foundation, and requiring FP extensions to C# to work.

I now have a team of Indian programmers using Scheme in our corporation. I would have classed them as 'average' but they've soon got the hang of it.


Man cannot understand the perfection and imperfections of his chosen art if he cannot see the value in other arts. Following rules only permits development up to a point in technique and then the student and artist has to learn more and seek further. It makes sense to study other arts as well as those of strategy.

Who has not learned something more about themselves by watching the activities of others? To learn the sword study the guitar. To learn the fist study commerce. To just study the sword will make you narrow-minded and will not permit you to grow outward.

-- Miyamoto Musashi, "A Book of Five Rings"


I don't think that functional languages will solve anything, and that this is just a hype that management is trying to sell, remember the only truth:

There is no silver bullet.

All the rest, is bullshit, also they've said that OO would solve our problems, that Web Services would solve our problems, that Xml would solve our problems, but in the end the above truth applied, and everything went down. Also, twenty years from now on, who says that we will be using binary computers at all? Why not quantic computers? No one can predict the future, at least not on this planet. (That is the second truth)

Yeah, there's no silver bullet. But is this worth digging out a really old question, which also has a dozen answers saying the same thing? Propably no. Therefore, third only truth: Think, read the question and look at its date before posting.