Why are there no big applications written using functional languages?
blog.tmorris.net
blog.tmorris.net
(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 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.
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.
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.
----
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.
----
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.
"Big" should never be a goal in programming.
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++.
map/reduce is a functional concept. Google use map/reduce. Google is one of the most used, if not biggest applications, on the planet.
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 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.
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.
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.
See also: http://prog21.dadgum.com/41.html - this blog has a lot of interesting material on this theme.
(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.