Because once a technique becomes widely used, we stop calling it "functional."
(Loosely borrowed from the same explanation for the lack of success in AI)
Map/reduce comes from functional languages, but now we're used to it. Write-once variables is an idea from functional languages, now used in most optimizing compilers, so now we're used to it. Transforming input to output according to a backtracking state machine is a functional idea, but now we're used to it as various kinds of parsing.
Ten years from now, we'll all be writing web applications with monads, but "functional" programming will have moved farther into the future, an people will ask: "Why are there no big applications written using functional languages?"
I completely disagree. We talk about people using object oriented programming languages all the time.
I think the issue is that, there are a "pure" functional programming languages (Lisp, Scheme, Closure, ML etc) and pure OO. People see the value in the functional paradigm but they don't want to give up the benefits of OO so we are are seeing a convergence where the language supports elements from both paradigms, and in general people don't look at that as functional language. I'd say javascript is a good mix between OO and functional.
By the way, Common Lisp is neither "pure" functional nor not-OO. It's a multi-paradigm language that supports imperative, functional, object-oriented, language-oriented, etc.
Google for CLOS, the Common Lisp Object System. I'd say it's more "pure OO" than most so-called object systems in use to day.
Haskell would count as purely functional, not Lisp.
Agreed -- I've read the art of the metaobject protocol. But when most people think of functional programming they think of lisp, and this was about perception and not technical accuracy.
But what is the meaning of "pure" here? Stretching back over the last forty years of Lisp, then Prolog, etc., it's a moving target. "Pure" once meant using routines instead of GOTO. Then it meant structured instead of GOTO. Then recursion rather than iteration, followed by structured recursion with fold rather than explicit recursion.
Most recently, it meant first-class functions. Read a lot of papers from the 90's and you'll see this being used as the definition of a real functional language. And lambdas and currying. Now that we've all seen the power these things give, us, they're now mainstream and we have a new definition of "functional programming" in terms of type-controlled effects.
The site seems to be down, so here's the entire post pulled from Google Reader. Note that the author is a Haskell and Scala programmer, and his point is very different than you might think from just the headline out of context:
----
Because there is no such thing as a big application. There is only bigger or smaller. This is a central tenet of functional programming. “Big application” is a euphemism for “My idea of programming does not scale beyond this point.” You don’t realise how much information you give away when you ask this question.
So can we can stop with the piffle and get one with the interesting and important stuff? Ta.
My reaction: Functional programming fits well with both the Unix philosophy and the web architecture. When your modules/functions do not share mutable state, there's often no reason to smoosh them all into one huge program.
Portions of Amazon and Google are written in functional languages or styles, but in a well-designed system you often end up with many smaller programs and no larger ones. Also, there's no strict requirement for one program to be in the same language as any other.
Functional programming is not that uncommon in the financial sector.
Jane St. Capital uses Ocaml, and I know of a hedge fund that uses Mathematica. Goldman's high frequency trading code is written in Erlang and much of their ordinary trading code is done in Slang (their proprietary programming language).
Further, a number of places do functional programming in C++.
Yes, but which great medium sized function app could we point people to ?
So, on one side of the spectrum you have functional factorial and then towards the middle you have Emacs, and on the other side you have (arguably) Google with map-reduce.
The simple answer I would give is that functional programmers are harder to find, so fewer big companies want to take on the risk of FP on a large project.
The technical answer I would give is that you wouldn't want to write _all_ of an application using just FP. The higher-level code will usually always be in a traditional imperative style, since it's counterproductive to avoid statefulness at the highest levels. Almost all large projects will use FP techniques in a lot of lower-level areas (except areas with performance sensitivity.) So now the question becomes whether code that is 90% FP but is "poisoned" by imperative code at the highest levels is still FP.
Any sufficiently complicated Haskell program will contain a call to unsafePerformIO.
But in all seriousness, you're quite right. Most interesting programs have some state in them, and the top-level logic that interacts with the UI will most likely be about viewing and updating that state.
And why does this answer blow it open? It seems like a slightly reactionary response to a pretty reasonable question to me.
I don't think anyone's in any doubt that purely functional programs simply aren't used in large systems, for most definitions of "large". There are counter examples (Erlang, EMACS, Jane's Capital) but they're currently the exception. I think it's totally reasonable to ask why this is, and how we might change it - either by making functional languages more accessible, or by promoting functional programming concepts in mainstream languages. It's totally possible to write largely referentially transparent programs in Java, for example, but most people don't do it - partly because the language and its idioms don't promote it, but also because the average Java programmer hasn't been exposed to the concepts. Maybe the "average" Java programmer would struggle to understand them, but a lot of them wouldn't. This second group could go on to promote functional programming, either in a more functional language or in Java - either way this is good, I think. Dismissing this sort of question out of hand doesn't help this process.
Is anyone using functional programming for the web on Windows? I know of F#, and I'm sure it could be plugged into ASP.NET, but I wonder if there is a more web-centric technology stack out there for enterprise developers on Windows?
ITA software uses Lisp, and Orbitz gets its flight data from ITA.
(Common) Lisp is not, however an especially functional language. Functional programming is possible, but not the default and not especially structurally encouraged by the language. Most implementations require compiler declarations to get tail-call elimination, and imperative looping is much more common than recursion in production CL code I've seen.
(Loosely borrowed from the same explanation for the lack of success in AI)
Map/reduce comes from functional languages, but now we're used to it. Write-once variables is an idea from functional languages, now used in most optimizing compilers, so now we're used to it. Transforming input to output according to a backtracking state machine is a functional idea, but now we're used to it as various kinds of parsing.
Ten years from now, we'll all be writing web applications with monads, but "functional" programming will have moved farther into the future, an people will ask: "Why are there no big applications written using functional languages?"