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.

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?

share|improve this question

closed as not constructive by Walter, Ryathal, ChrisF Nov 14 '12 at 20:42

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.

2  
To some extent, I disagree with the premise of your question. Language features inspired by "functional languages" are being added to languages like Java and JavaScript. In fact, JavaScript has always been (in some ways) a functional language, though a lot of people didn't realize it until recently. –  MatrixFrog Sep 30 '11 at 17:44
1  
@MatrixFrog: One might ask "Why go functional only half way by adding a few functional concepts to non-functional languages instead of adopting a full-fledged FP language? After all the paradigm has been around for many years and is very mature." –  Giorgio Nov 13 '12 at 19:46
add comment

12 Answers 12

up vote 26 down vote accepted

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!

share|improve this answer
6  
How is functional programming in any way 'new'? –  Evan Plaice Sep 12 '10 at 2:15
5  
I think he meant 'unused' instead of 'new'. –  Vinko Vrsalovic Sep 15 '10 at 19:32
6  
So it is unused... because it is unused? Hm. –  Alex Baranosky May 12 '11 at 2:12
16  
@Alex - Exactly. Sucks, don't it? –  KeithS Sep 30 '11 at 17:08
4  
@Stargazer712: What are those reasons? I know lots of developers who don't know functional programming, so ignorance makes sense to me. Did functional programming have a massive failure in the past that chased the industry away from it that I'm unaware of? –  Sean McMillan Sep 30 '11 at 20:11
show 7 more comments

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.

share|improve this answer
    
This is a really good comment. +1 to arrows in your quiver, and ranges of solutions with tradeoffs. –  user21007 Apr 7 '11 at 22:00
1  
+1 for QC. That MSc would have been much more useful with dedicated subjects covering testing, code review, code complexity and similar. Being able to automatically verify that a program does what it should after the last patch is worth any number of "it should work now" hand-wavy gibberish. –  l0b0 Jun 17 '11 at 14:00
4  
@l0b0: Thanks, although actually I was thinking of the quality control of what is taught and how. As it is, CS professors just teach what they personally find most interesting. Compare that to engineering, where there is interplay with industry, or medicine, where the real-world relevance is very high. IME, CS profs figure the real world will do the teaching of what matters in the real world, but students don't come out eager to learn - rather they are eager to proselytize what the profs were most excited about. –  Mike Dunlavey Jun 17 '11 at 21:59
    
@Mike: just about any modern language? Are you including C++ and Java? –  kevin cline Sep 30 '11 at 17:45
    
+1. Couldn't have said it better myself. –  Stargazer712 Sep 30 '11 at 17:53
show 3 more comments

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.

share|improve this answer
33  
I disagree. Functional programming languages try to minimize the use of a state, and by that get less complex. Programs programmed in a functional language is also easier to test and refactor. –  Jonas Sep 26 '10 at 15:36
4  
@Jonas: a lot of programmers find it extremely difficult to write a program using almost no state at all (including myself). From that point of view, it is actually a more complex. (Please note that I'm not debating the usefulness of functional programming by any means!) –  ShdNx Sep 26 '10 at 16:11
2  
@ShdNx: Yes, I know. Even I thought functional programming was hard when I first learned it in university. But after a while I started to prefer it to imperative programming and more specific OOP. At my university functional programming was taught before imperative programming and students that hadn't done any programming before university thought that imperative programming was very hard at the beginning and that functional programming was closer to math. –  Jonas Sep 26 '10 at 16:37
11  
There is a difference between difficulty and complexity. OOP is definitely more difficult than structured programming because it adds more concepts. For big enough amounts of code, they reduce complexity by providing a structure to the code. FP is the same thing: if you are writing only two lines it seems like overkill, but if your code is big enough then structuring code as stateless subunits improves the scalability and reduces the complexity of the code. –  Muhammad Alkarouri Oct 28 '10 at 10:54
2  
One of the main emphasises of functional programming is composability. If that isn't a tool for managing complexity I don't know what is. –  dan_waterworth Nov 11 '11 at 15:06
show 2 more comments

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.

share|improve this answer
    
+1, I'd be very interested in hearing your decision making process around why you chose Clojure. (I'm not for or anti Clojure, I'm just interested). –  dan_waterworth Nov 11 '11 at 15:10
2  
"learning FP is hard": Learning any paradigm is hard. I remember how many hours I spent with imperative code (Pascal) before I had enough experience to be reasonably productive. I think FP is less known because many programmers learned an imperative language first and once they learnt how to program they did not have the time to look at something else. I am a full-time C++ programmer and I am currently learning Scala in the evening after work. If I had a family to look after I could simply forget about it. –  Giorgio Nov 13 '12 at 20:19
    
I think the first 3 are great cases, however I disagree with the 4th. OOP is extremely modular and compositional; for me this is one of its greatest strengths. It's also great at hiding complexity through encapsulation and abstraction. –  Despertar Jul 19 '13 at 8:30
add comment

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.

share|improve this answer
1  
Alien paradigm? It's closer to math than imperative programming is. Here in Sweden I think that most CS students at university is thaut functional programming first. E.g. we started out with Standard ML, before C, Erlang and Java. –  Jonas Sep 4 '10 at 20:17
3  
Fair enough. I know that a lot of engineering students in the UK and India are taught C first, followed by C++ and/or Java. Often they aren't taught a functional language at all. –  Chinmay Kanchi Sep 4 '10 at 22:26
9  
@Jonas For a number of folk out there, mathematics is an alien paradigm and anything that takes programming further away from mathematics makes it easier to understand. –  scriptocalypse Apr 1 '11 at 20:06
4  
I've heard of people who have never heard of trees, let alone function programming, having graduated. –  dan_waterworth Apr 7 '11 at 21:08
1  
@Tux-D, actually, no, I'm talking about students in the UK. –  dan_waterworth Oct 1 '11 at 7:49
show 3 more comments

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.

share|improve this answer
    
I would consider Perl a major language as well. It's an older language that I would say is most often used with Unix-like systems. Although Python seems to be a more modern alternative. It is still a popular language that has gotten a lot of attention and has a large community. –  Despertar Jul 19 '13 at 8:43
    
@Despertar - I wasn't trying especially hard to be egalitarian about which languages I mentioned :) And agreed, the story seems a lot like Python, except a few years in the past. –  Jesse Millikan Jul 20 '13 at 9:47
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
1  
Functional languages, especially "impure" functional languages, can deal with global state perfectly fine. I find that often programs decompose into alternating layers: eg, global state... but functional state transitions... with occasional local (masked) state to implement performance-critical parts of those transitions, etc. The problem with imperative languages, IMO, is that they often lead programmers to use state inappropriately, when functional patterns would work better. But languages seem to be evolving in the direction of supporting both styles well. –  Ryan Culpepper Sep 30 '11 at 20:57
1  
It's very easy to deal with state in functional languages, but it requires a shift in emphasis. Whereas in imperative languages you write procedures that modify state, in functional languages you write functions that return procedures that modify state. –  dan_waterworth Nov 11 '11 at 15:17
add comment

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.
share|improve this answer
1  
1) "almost all large programming projects are using it". My experience is that this is far from the reallity. Very few companies are using functional programming as what I know. Most only use Java and C# (even though C# have got more functional constructs the last few years), C++ and C. –  Jonas Sep 30 '11 at 17:34
2  
2) My experience is the opposite. People from universities seem to be the only ones that know functional programming. Here in Sweden, most universities teach functional programming from the first year. And universities like MIT have until recently been using functional programming in their first programming course (Scheme). –  Jonas Sep 30 '11 at 17:34
    
@jonas: no, the programming language has nothing to do with it. Of course C and C++ and java etc is used by large number of projcts. The functional programming is also working in c++ code. The current practise seems to be that part of the project is using OO and part of it uses functional programming. Both parts use the same language (usually c/c++) –  tp1 Oct 1 '11 at 10:55
    
Yeah, you could do OO in C too. But it's not recommended. C and C++ doesn't have many constructs for functional programming e.g. not immutable by default, no good support for pattern matching, no included immutable datastructures and so on... –  Jonas Oct 1 '11 at 12:22
    
Well, that's why it requires experienced programmers. Since it's pretty much impossible to change the programming language from the mainstream ones, the next best thing is to do functional programming in c++. Also c++ has things like const which help quite much. –  tp1 Oct 1 '11 at 13:30
add comment

Because it's harder to debug FP.

share|improve this answer
11  
I disagree. Without collateral effects the debug process is easier. Maybe you think it's harder because functional paradigm is different and needs experience to got comfortable with new way to do things, including debug. –  bigown Sep 25 '10 at 3:39
2  
Functional programming languages are actually easier to test, since pure functions is stateless. –  Jonas Sep 26 '10 at 15:38
4  
Jonas, I didn't say "test", I said "debug" ie. find a mistake that you've made. Testing is part of that, but so is reasoning about the program, etc. bigown - I stand by this. It's a function of FP's power. The more work any particular line of code does, the harder it is to see which line of code is causing a problem. The mapping between line of code, and effect, is more diffuse eg. a single higher-order function might touch dozens of behaviours of the program and vice versa. The symptoms can vary wildly between different points for the same error. –  interstar Sep 28 '10 at 5:15
    
In my experience it is not hard to debug at all. I am using F# and I can't find any reason why you would find it more difficult to debug than C# for example. May be debugging is harder in Haskell because of the laziness (I have no idea), but eager FP programming is simpler due to statelessness as Jonas said. In other words, FP code is more predictable because you know the result is not influenced by unseen variables. –  Muhammad Alkarouri Oct 28 '10 at 10:49
2  
So long as your functions are pure, debugging is easy. If you can't debug by adding unit-tests then your not doing an adequate job of writing tests. –  dan_waterworth Apr 7 '11 at 21:12
show 1 more comment

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