Why isn't functional programming more popular in the industry? Does it catch on now?

Question

During my four years at university we have been using much functional programming in several functional programming languages. But I have also used much object oriented programming to, and in fact I use object oriented languages more when doing my own small project to prepare for my first job. But I often wish that I was coding in a functional programming language when doing these projects.

However, when looking for a job, it is very rare to see a job where knowledge of a functional programming language is required.

Why isn't functional programming languages used more in the industry? There is quite much news about functional programming languages these days, so I wonder if functional programming is catching on in the industry now?

Answer 1

I was a professor and, just like programmers, professors are always looking for the Next Big Thing. When they think they've found one, they make it a bandwagon, and everyone piles on. Since they are preaching to students who think professors must be really smart, else why would they be professors, they get no resistance.

Functional programming is such a bandwagon. Sure it's got lots of nice interesting questions to investigate, and lots of sort-of-interesting conference articles to write. It's not a particularly new idea, and you can do it in just about any modern language, and ideas don't have to be new to be interesting. It's also a good skill to have.

Given that, functional programming is just one arrow to have in your quiver, not the only one, just as OOP is not the only one.

My beef with computer science academia is lack of practical interplay with industry to determine what actually makes real-world sense, i.e. quality control. If that quality control were there, there might be a different emphasis, on classifying problems and the ranges of solutions to them, with tradeoffs, rather than just the latest bandwagons.

Answer 2

I would say that one of the reasons that functional programming is not more prevalent is the lack of knowledge base. My experience is that corporations are very risk averse in terms of implementing technologies that are not main stream and would rather invest in tried and true frameworks (java, c++, c#). It's only when there is a business need (like in Ericsson) that new paradigms are considered. But even in Ericsson's case I heard that management demanded that c++ be used and Joe Armstrong was compelled to code erlang calls in c++!! This should show how reluctant corporations are to implement new technologies!

Answer 3

Because the biggest problem in software development these days is the ability to manage complexity. This is not the focus of most functional programming languages. As such, languages that do make that a priority (namely the more popular OOP languages) tend to just steal some of the cooler features that come out of the more academic functional languages and so stay on top.

Answer 4

Functional programming is definitely starting to catch on - slowly but surely.

For example, the startup I am building is using a functional language (Clojure) as the primary development language for the following reasons:

• Productivity - learning FP is hard, but once you get the hang of it it is very hard to beat in terms of power and expressiveness. I'm probably writing about 1/10th of the number of lines to implement any given piece of functionality compared to what I would have needed in C# or Java

• Reliability - pure functions are much easier to reason about and test than stateful objects. Hence you can write better tests and validate the correctness of your code much more easily.

• Concurrency - functional languages emphasise immutability, which has enormous benefits for concurrent applications than need to run effectively on multiple cores. And like it or not, running on multiple cores is the future. See http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey for a brillient explanation of why this is so important

• Composability/modularity - functional languages seem to lend themselves to plugging components together more easily than complex OO systems. I still haven't figured out all the reasons for this, but part of it stems from the fact that you don't have all the "incidental complexity" that OO models drag around with them. The talk on Radical Simplicity by Stuart Halloway explores these ideas in much more depth.

EDIT: In response to Despertar's comment, an example of the "incidental complexity" of OOP systems that limits modularity is the problems with deep cloning vs. shallow cloning: you can't compose objects together and pass them around as composite structures without a very careful analysis of the cloning and mutation semantics. In small cases this is manageable, but in complex systems it rapidly becomes a significant problem. This problem won't exist in the first place if you rely on pure functional data structures.

Answer 5

Lack of killer app

Hey, this one over here looks fresh. (dig dig dig)

I think most programming languages thrived by having a "killer app" - something compelling that was exclusive to the language (or viewed that way). This is not to say that all of the uptake was that application, but that it drove the language to a larger acceptance.

Here's my not terribly accurate view of what niche has driven the adoption of some of the languages we have today:

• C: Works everywhere (This was the late 70s and 80s)
• C++: GUI frameworks (early 90s)
• Java: Applets and servlets (in the late 90s)
• Objective-C: iOS apps (Before that, OS X apps)
• Ruby: Rails
• C#: ASP.NET, WinForms
• PHP: Wordpress, etc.
• Javascript: AJAX, especially via frameworks
• lua: Game scripting, especially WoW

Aside from that, many proprietary languages have gotten in the door through powerful sales organizations (Oracle, and to a lesser degree Microsoft's languages), effectively creating their own niche.

One very important note about that list: The language's "niche", as indicated by the killer app, gets more and more specific as decades pass. Note the last one on the list: Game scripting, specifically. It's getting harder and harder for languages to get attention because of the list of things that are already done well enough by another language.

So, what any functional language needs to really take off is a niche. In reality, there aren't any huge functional languages yet, but there are a whole lot in smaller niches:

• Emacs Lisp: Constant use since the 80s in Emacs by developers. (Hardly ever used anywhere else.)
• Erlang: Anywhere you want lots of concurrent agents.
• Scheme: Education
• APL/J/K: Finance (Let's call these functional, for the sake of the argument)
• Common Lisp: "AI" - This is what people tend to say it's used for, which is a blessing and a curse.

Now, the only major language I feel I've left out of this discussion is Python. Python has done something very interesting; it has succeeded without appearing to be the winner in any major niche. This could mean that I'm flat-out wrong for viewing language popularity this way. It could also mean that a good enough language can become popular without a killer app to drive adoption and acceptance, but it is very difficult and might take a very long time. (Perl has a similar story, but came a few years earlier and is now has less uptake.)

From this, I can say which functional languages I think are on the rise:

• Clojure: Web programming, esp. through Heroku
• Scala: Lift (or maybe Play, these days) - JVM without Java

If you asked me where to look next for popular functional languages, I'd say be on the lookout for a functional language with turnkey cloud development (a la Heroku or GAE) or turnkey mobile app development.

Answer 6

For the same reason that Lisp never really caught on (let the flamewars begin!). Functional programming is a very alien paradigm compared to imperative and object-oriented programming. If, like the vast majority of CS students, you started off with C and progressed to C++/Java, you tend not to want to learn to think in a way that is completely orthogonal to the way you normally think.

Answer 7

Let's consider businesses and programming.

There are businesses that use their software as a strategic asset. This isn't typical. For most businesses, IT is something that supports the company's real business. It's a necessary expense. They are conservative because they know that for $X they can get the IT they need, while if they switch to something different they'll save less than $X if everything goes well, and lose real big if everything goes badly.

Moreover, in businesses, the cheapest thing to do is typically what they did yesterday. Change, however, desirable, is expensive. If a company were to change from, say, a C#/.NET solution, even to F#, they'd have problems. Their programmers (which are likely not the sharpest programmers out there) would have to learn a new language, and be proficient in both, and use both frequently. There would be routines written in both for a long time. If they were to move to something like Haskell, or if they were using C++/MFC in the first place, they'd be changing a lot more, and that would be a lot more expensive.

Also, there's going to be a supply of C# programmers, and continuing Microsoft support, for a long time to come. The present IT practices can be counted on. There isn't the same level of institutional support or assurance of continued availability of programmers.

Therefore, for most businesses, making a change to functional programming would be expensive up front, and it will only pay for itself if the reduction in IT costs is sufficient over the long run, except that the long run is potentially iffy.

Answer 8

You already write code in functional style, just you don't know it.

When you are required to make unit tests for your code, you tend to write testable functions, which does not create or depend on side effects, and always returns the same result on the same arguments (so called pure functions). This is the primary advantage of functional programs.

I think functional languages are too limiting. So instead of replacing imperative languages with functional, imperative languages will get functional features. Nowadays almost every programming language has closures and lambdas.

Answer 9

The real problem is state.

Functional languages don't have global state. Most industrial problems require state at the large scale (how do you represent a ledger or a set of transaction) even if some functions at the small scale do not actually require it (processing a ledger).

But we are running code on Von-Neuman architecture machines which are inherently state-full. So we have not actually got rid of state, the functional languages just hide the complexity of state from the developer. This means that language/compiler has to deal with state behind the scenes and managing it.

So though functional languages have no global state, their state information is passed as parameters and result.

So the question then becomes can the language handle the state efficiently behind the sense? Especially when the data size far exceeds the size of the architecture.

Looking at it from Hardware Side

The OS has helped a lot in the last couple of years in visualizing address space so applications do not officially need to worry about it. But applications that do not worry about fall into the trap of thrashing the hardware when memory pressure becomes intense (thrashing hardware will slow your processes to a crawl).

As the programmer has not direct control over state in the functional language they must rely on the compiler to handle this and I have not seen functional languages that handle this well.

On the converse side of the coin the state-full programmer has direct control over state and can thus compensate for low memory conditions. Though I have not seen many programmers that are actually smart enough to do so.

Looking at from the industry side:

Industry has a lot of inefficient state-full programers.

But it is easy to measure improvements in these programs over time. You throw a team of developers at the problem they can improve the code by improving how the program handles state.

For functional programs the improvements are more difficult to measure as you need to improve the tools that will improve the programs (we are just looking at how applications handle underlying state efficiently here, not the overall improvement of the program).

So for industry I think it comes down to the ability to measure improvements in the code.

From a hiring perspective

There are a lot of stat-full programmers available for hire. Functional programers are hard to find. So your basic supply and demand model would kick in if industry swapped to functional style programing and that is not something they want to happen (programmers are expensive enough as it is).

Answer 10

I believe there's only one real answer to your question. You can get into a lot of related reasons why this answer is the case, but those are different questions.

Here it is:

• Software architects provide solutions they are confident will work.
• The majority of architects do not work in functional languages.
• Once technologies and languages are chosen, businesses find people who can work with them.

Is it catching on? That all depends upon whether people who are confident in using functional languages are becoming architects and choosing to use it for the projects they work on.

Answer 11

This question have slightly wrong premise. For the following reasons:

1. Functional programming is actually pretty common in the industry. But it's only used where experienced programmers are available. Beginners cannot be expected to know it. Almost all large programming projects are using it, but they just keep it in areas which are handled by experienced programmers. Beginners will deal with the easy modules which do not require functional programming.
2. Given this reality, companies that are hiring people (usually young ones coming from university) cannot really ask for functional programming experience. Anyone in projects which requires functional programming has already been in the same company for 15 years.
3. Universities are starting to teach it, because they know already now that functional programming knowledge will be very useful in 30 years. Their time range is in 30 years, not the normal half year like in companies.
4. These points are the reason why people get disappointed when they enter the work force and see that the stuff they learned in university are not used. But they were designed for 30 year timespan, and it will be useful eventually -- it's just that companies are using the simple stuff - the stuff they can expect people to know.
5. Also you would be arrogant if you think after few years of university, you know functional programming well enough to use it in actual software projects. Start from the simple stuff first. You don't really need to do the most complex piece of software as your first task when you start working. You'll eventually get to the complex stuff, but it takes time.

Answer 12

Because it's harder to debug FP.