Why hasn't functional programming taken over yet?

Tagged:
Freelance Jobs

I've read some texts about declarative/functional programming (languages), tried out Haskell as well as written one myself. From what I've seen, functional programming has several advantages over the classical imperative style:

  • Stateless programs; No side effects
  • Concurrency; Plays extremely nice with the rising multi-core technology
  • Programs are usually shorter and in some cases easier to read
  • Productivity goes up (example: Erlang)

  • Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21st century

Why are companies using or programs written in functional languages still so "rare"?

Why, when looking at the advantages of functional programming, are we still using imperative programming languages?

Maybe it was too early for it in 1990, but today?


pankraxH
2010-05-14 16:24:03 Scores:39
IMHO this should be community wiki.
Péter TörökH
2010-05-14 16:27:37 Scores:5
There are several language-specific answers to this question, like [this one](http://stackoverflow.com/questions/145228/what-could-make-erlang-more-popular-and-widespread) and [this one](http://stackoverflow.com/questions/68717/will-lisp-ever-become-super-popular).
Robert HarveyH
2010-05-14 16:29:35 Scores:2
@Peter: pankrax doesn't have enough rep to see the cw checkbox, and he probably doesn't know what cw means anyway. Flag for moderation and put "should be community wiki" in the description.
Robert HarveyH
2010-05-14 16:30:19 Scores:0
@Robert: You can make your questions CW at 1 rep but it is strange that the first respone I get comes from the CW police ^^
pankraxH
2010-05-14 16:32:03 Scores:1
Yay, I am a member of the mighty CW Police!!! Where do I get my super cool CW Sheriff badge? ;-)
Péter TörökH
2010-05-14 16:41:02 Scores:3
@pankrax, it is also strange (to me at least) that you, supposedly a newbie at SO, already talk about CW police... apparently some memes spread fast nowadays ;-)
Péter TörökH
2010-05-14 16:42:30 Scores:4
@Péter Török: questions should be marked community wiki when a user wants his question or answers to be publically editable by anyone. Wiki is *not* used to classify posts as subjective or "no single answer", we use tags for that purpose. @pankrax: don't feel pressured into wiki'ing your posts if you don't want to.
JulietH
2010-05-14 16:48:41 Scores:3
Hasn't this been discussed enough already? http://stackoverflow.com/questions/411290/why-do-people-think-functional-programming-will-catch-on-closed, http://stackoverflow.com/questions/36504/why-functional-languages, http://stackoverflow.com/questions/1786969/pitfalls-disadvantages-of-functional-programming, http://stackoverflow.com/questions/216160/are-we-in-a-functional-programming-fad, etc.
gnoviceH
2010-05-14 17:21:35 Scores:2
@gnovice: If this question hadn't been asked, we wouldn't have gotten Eric Lippert's thoughtful and thorough answer.
Robert HarveyH
2010-05-14 17:35:59 Scores:0
@Juliet -- if you want to debate this, please come to Meta and debate it. What you are stating as fact is not the consensus of the community. Some agree, some disagree.
bmarguliesH
2010-05-19 19:56:32 Scores:3
@Juliet: CW is not only for posts to be "publically editable", it's also to prevent rep-whoring (which is much easier with subjective questions).
fretjeH
2010-05-20 13:28:32 Scores:2

13 answers

Answer 1
Scores:215

Because all those advantages are also disadvantages.

Stateless programs; No side effects

Real-world programs are all about side effects and mutation. When the user presses a button it's because they want something to happen. When they type in something, they want that state to replace whatever state used to be there. When Jane Smith in accounting gets married and changes her name to Jane Jones, the database backing the business process that prints her paycheque had better be all about handling that sort of mutation. When you fire the machine gun at the alien, most people do not mentally model that as the construction of a new alien with fewer hit points; they model that as a mutation of an existing alien's properties.

When the programming language concepts fundamentally work against the domain being modelled, it's hard to justify using that language.

Concurrency; Plays extremely nice with the rising multi-core technology

The problem is just pushed around. With immutable data structures you have cheap thread safety at the cost of possibly working with stale data. With mutable data structures you have the benefit of always working on fresh data at the cost of having to write complicated logic to keep the data consistent. It's not like one of those is obviously better than the other.

Programs are usually shorter and in some cases easier to read

Except in the cases where they are longer and harder to read. Learning how to read programs written in a functional style is a difficult skill; people seem to be much better at conceiving of programs as a series of steps to be followed, like a recipe, rather than as a series of calculations to be carried out.

Productivity goes up (example: Erlang)

Productivity has to go up a lot in order to justify the massive expense of hiring programmers who know how to program in a functional style.

And remember, you don't want to throw away a working system; most programmers are not building new systems from scratch, but rather maintaining existing systems, most of which were built in non-functional languages. Imagine trying to justify that to shareholders. Why did you scrap your existing working payroll system to build a new one at the cost of millions of dollars? "Because functional programming is awesome" is unlikely to delight the shareholders.

Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21th century

Functional programming is very old too. I don't see how the age of the concept is relevant.

Don't get me wrong. I love functional programming, I joined this team because I wanted to help bring concepts from functional programming into C#, and I think that programming in an immutable style is the way of the future. But there are enormous costs to programming in a functional style that can't simply be wished away. The shift towards a more functional style is going to happen slowly and gradually over a period of decades. And that's what it will be: a shift towards a more functional style, not a wholesale embracing of the purity and beauty of Haskell and the abandoning of C++.

I build compilers for a living and we are definitely embracing a functional style for the next generation of compiler tools. That's because functional programming is fundamentally a good match for the sorts of problems we face. Our problems are all about taking in raw information -- strings and metadata -- and transforming them into different strings and metadata. In situations where mutations occur, like someone is typing in the IDE, the problem space inherently lends itself to functional techniques such as incrementally rebuilding only the portions of the tree that changed. Many domains do not have these nice properties that make them obviously amenable to a functional style.

Eric Lippert H
2010-05-14 16:43:34
+1 good answer, and def. right that functional programming is v. old too ... I'm young, and I was taught first an old functional language and then one of the modern imperative ones ...
eglasius H
2010-05-14 16:55:24 Scores:1
"When Jane Smith in accounting gets married and changes her name to Jane Jones, the database backing the business process that prints her paycheque had better be all about handling that sort of mutation." There will be a record Jane Smith's former name, we don't retroactively update all instances of Jane's former name to her new name ;)
Juliet H
2010-05-14 16:55:42 Scores:11
@Juliet: Sure. My point is that if you have an object that represents an employee, it makes sense to think of the operation "change the name of the employee" to be a mutation of the object representing the employee *that does not change object identity*. When Jane Smith changes her name you don't create a *different* employee called Jane Jones that is otherwise the same. There aren't two employees with two different names. It is natural to model this process as a mutation of an object, not as the construction of a new object.
Eric Lippert H
2010-05-14 16:58:38 Scores:9
Funtional programming is indeed old. Is there any high-level programming language older than LISP?
Gabe H
2010-05-14 17:00:52 Scores:0
I wish I could upvote this twice.
luiscubal H
2010-05-14 17:05:13 Scores:24
This is a good answer, but I think you overstate your case at times. Like Juliet said, although people might think of it as a name change, it really is a name replacement on a deeper level. And although functional programs might be harder for people to read (because it *is* a learned skill), that isn't generally because they're longer. A Haskell program will almost always be more terse than, say, a Java program — even in a "bad fit" domain with lots of inherent state.
Chuck H
2010-05-14 17:17:17 Scores:10
@Chuck: Harder to read doesn't necessarily mean longer. While Java is a very verbose language, it's possible to write it so that it reads close to plain English. My experience with functional languages is limited, but I've usually had to switch mental gears and parse out the syntax before beginning to understand the code.
Anna Lear H
2010-05-14 17:25:35 Scores:1
Look at the brilliant design of F#, which blends functional, concurrent, procedural, and OO styles, including access to the .NET BCL and non-F# .NET assemblies. If F# had been strictly a functional language derived from ML and OCaml its relevance, usefulness, and adoption rate in the .NET universe would be much less.
Simon Chadwick H
2010-05-14 17:33:59 Scores:2
@Chuck: The point is that you're replacing (or updating) the name, NOT creating a whole new employee with a different name who has all of the same attributes, characteristics, etc. Looking at it from a real-world point of view, you don't fire a person just because their name changes and then re-hire them immediately with a new name. In a "Grand Design" view, you aren't taking someone's life (with your own hands/program) and then creating a new person who IS that newly deceased person except that the person's name is different.
Dustin H
2010-05-14 22:54:18 Scores:0
@Gabe: Well, FORTRAN, but just by a year or so.
Tim Goodman H
2010-05-15 17:44:04 Scores:2
+1 for incorporating machine guns and aliens into your answer.
Dubs H
2010-05-18 13:07:11 Scores:46
"I joined this team"?
Amnon H
2010-05-30 14:05:18 Scores:0
@Amnon: the C# compiler team.
Eric Lippert H
2010-05-30 14:46:14 Scores:1
+1 It was such a breath of fresh air to read this answer. Fantastic to hear such pragmatism (with an underlying passion for functional programming) from someone in your position.
David HAust H
2010-08-03 05:13:05 Scores:6
+1 for using an example that includes "hit points". Hey, I'm an old school RPG fan, what can I say? Also, that C# thing you helped create is pretty neat :)
Ed S. H
2011-01-12 08:06:05 Scores:0
+1, I think SO should give exceptions for this kind of post to do +2 or more.
Sanjeevakumar Hiremath H
2011-03-15 08:41:46 Scores:0
Random perspective from Philosophy (Specifically the problem of personal identity and free will) which I'll just state rather than support (hard to do with this character limit): when you shoot that Alien, a new Alien with less hitpoints is indeed returned. Whether you mutate state or take an old state to return a new one they are both just two ways of modelling the same thing. That "same thing" is an abstraction that transcends any one true representation. So use whichever one gets the job done faster :) (Freaking epic post btw. I wish I could upvote again)
TheIronKnuckle H
2011-12-05 12:18:13 Scores:0
Answer 2
Scores:16

Despite the advantages of functional programming, imperative and object oriented programming will never go away completely.

Imperative and object-oriented programming is a step-by-step description of the problem and its solution. As such, it can be easier to comprehend. Functional programming can be a bit obscure.

Ultimately, a useful program will always have side effects (like providing actual output to the user for consumption), so the purest of functional languages will still need a way to step into the imperative world from time to time.

The current state-of-the-art is that imperative languages (such as C#) borrow features from the functional world (such as lambda statements) and vice-versa.

Robert Harvey H
2010-05-14 16:32:07
Isn't OOP some sort of subset of imperative programming?
pankrax H
2010-05-14 16:35:24 Scores:1
OOP is a superset. OOP is to imperative as C++ is to C.
Robert Harvey H
2010-05-14 16:44:23 Scores:4
I don't think OOP is necessarily reliant on imperative programming. Look a Clojure or CLOS -- both are functional, yet object-oriented.
Gabe H
2010-05-14 16:55:44 Scores:4
OO languages tend to be imperative, but don't have to be. OCaml is a strongly (though not purely) functional language whose entire raison d'etre is OO.
Chuck H
2010-05-14 17:09:35 Scores:4
and then you can get OO languages which are neither imperative nor functional. Like good old Smalltalk
TheIronKnuckle H
2011-12-05 12:20:43 Scores:0
Answer 3
Scores:11

The stock answer is that neither will or should replace the other - they are different tools that have different sets of pros and cons, and which approach has the edge will differ depending on the project and other "soft" issues like the available talent pool.

I think you're right that the growth of concurrency due to multi-core will increase the percentage (of the global set of development projects) when functional programming is chosen over other styles.

I think it's rare today because the majority of today's professional talent pool is most comfortable with imperative and object-oriented technologies. For example, I have more than once chosen Java as the language for a commercial project because it was good enough, non-controversial, and I know that I will never run out of people that can program (well enough) in it.

Greg H
2010-05-14 16:34:17
This is very insightful and delightfully pragmatic. Definitely the best answer I've seen to this question in all its forms.
Benson H
2010-05-14 16:46:29 Scores:0
Answer 4
Scores:10

Masterminds of Programming: Conversations with the Creators of Major Programming Languages

[Haskell]

Why do you think no functional programming language has entered the mainstream?

John Hughes: Poor marketing! I don't mean propaganda; we've had plenty of that. I mean a careful choice of a target market niche to dominate, followed by a determined effort to make functional programming by far the most effective way to address that niche. In the happy days of the 80s, we thought functional programming was good for everything - but calling new technology "good for everything" is the same as calling it "particularly good at nothing". What's the brand supposed to be? This is a problem that John Launchbury described very clearly in his invited talk at ICFP. Galois Connections nearly went under when their brand was "software in functional languages," but they've gone from strength to strength since focusing on "high-assurance software."

Many people have no idea how technological innovation happens, and expect that better technology will simply become dominant all by itself (the "better mousetrap" effect), but the world's just not like that.

Nick Dandoulakis H
2010-05-14 16:46:32
Haskell: after 20 years, an overnight success!
Juliet H
2010-05-14 17:05:50 Scores:8
follow the link and read the reviews for a rather amusing dis of Grady Booch. No idea who Booch is, but it made me lol anyway.
fearofawhackplanet H
2010-05-14 23:39:19 Scores:0
Grady Booch is responsible, ultimately, together with Jacobson and Rumbaugh, for the abomination that is UML.
JUST MY correct OPINION H
2010-05-30 13:53:17 Scores:1
Answer 5
Scores:7

Hasn't it?

Smalltalk was a great object-oriented system back in the day. Why hasn't object-oriented programming taken over? Well, it has. It just doesn't look like Smalltalk. Mainstream languages keep getting more Smalltalk-like with C++, Java, C#, etc. Fashion and style change slower than anything, so when OO went mainstream, we got it by gluing parts of OO to old languages so it looked enough like C to swallow.

Functional is the same way. Haskell was a great functional language. But we've got even more mass of mainstream programmers using C-like syntax today than 20 years ago. So it has to look like C. Done: look at any LINQ expression and tell me it isn't functional.

Ken H
2010-05-14 23:02:18
Interesting point, but how have mainstream languages been getting more Smalltalk-like? C++, Java and C#, for instance, are not based on message-sending, which (I believe) is the most important part of the Smalltalk paradigm.
Jonathan Sterling H
2010-05-16 03:06:29 Scores:1
Jonathan: Pick any Smalltalk feature, and observe how it's weakest in C++ (the oldest), OK in Java, and better in C#. For example, GC (Java/C# only), autoboxing (later Java/C# only), closures (C# only), and reflection (present in Java, better in C#). If you want message-passing, look at C# 4's `dynamic`. That's the most Smalltalk-y of these features, so it's no surprise to me that it's only present in the latest version of the most modern of these three languages. :-)
Ken H
2010-06-02 17:54:15 Scores:3
Answer 6
Scores:5

I believe that imperative languages are more prevalent simply because that's what more people are used to. Neither functional programming nor the imperative programming model is more obscure or academic than the other. In fact, they are complements.

One poster said that imperative code is easier to understand than functional programming code. This is only true if the reader has already seen imperative code, especially if the prior examples are part of the same "family" (for example, C/C++, Perl, PHP and Java). I would not claim that it's true for any imperative language; take a comparison of Java and Forth, to make an extreme example.

To a layperson, all programming languages are indecipherable gibberish, except maybe the verbose languages such as Hypertalk and SQL. (Of note, SQL is a declarative and/or functional language and enjoys enormous popularity.)

If we had been initially trained on a Lisp-y or Haskell-y language from the start, we'd all think functional programming languages are perfectly normal.

Barry Brown H
2010-05-14 23:05:34
Answer 7
Scores:4

No Perceived Need

I recall my old Boss Rick Cline's response when I showed him a copy of John Backus' Turing Award lecture entitled Can Programming Be Liberated from the von Neumann Style?

His response: "Maybe some of us don't want to be liberated from the von Neumann style!"

Mark Harrison H
2010-05-16 02:31:02
Answer 8
Scores:3

You've gotten enough answers already that I'll mention only a couple of things I don't see mentioned yet.

First and (in my mind) foremost, procedural languages have benefited greatly from their degree of commonality. For one example, almost anybody who knows almost any of the mainstream procedural (or OO) languages to almost any degree can read most of the others reasonably well. I actively avoid working in Java, C#, Cobol, Fortran, or Basic (for just a few examples) but can read any of them reasonably well -- almost as well, in fact, as people who use them every day.

On the functional side, that's much less true. Just for example, I can write Scheme quite reasonably as well, but that's of little use in reading Ocaml or Haskell (for only a couple of examples). Even within a single family (e.g., Scheme vs., Common Lisp) familiarity with one doesn't seem to translate nearly as well to the other.

The claim that functional code is more readable tends to be true only under a narrow range of conditions. For people who are extremely familiar with the language, readability is indeed excellent -- but for everybody else, it's often next to nonexistent. Worse, while differences in procedural languages are largely of syntax and therefore relatively easily learned, differences in functional languages are often much more fundamental, so they require considerable study to really understand (e.g., knowing Lisp is of little help in understanding Monads).

The other major point is that the idea that functional programs are shorter than procedural ones is often based more on syntax than semantics. Programs written in Haskell (for one example) are often quite short, but its being functional is a rather small part of that. A great deal if it is simply that Haskell has a relatively terse syntax.

Few purely functional languages can compete well with APL for terse source code (though, in fairness, APL supports creating higher level functions as well, so that's not quite a large a difference as in some other cases). Contrariwise, Ada and C++ (for only a couple examples) can be quite competitive in terms of number of operations necessary to accomplish a given task, but the syntax is (at least usually) substantially more verbose.

Jerry Coffin H
2010-05-14 18:18:39
Answer 9
Scores:2

Read this then ask again.

Jeremy H
2010-05-14 16:31:35
Pretty pointless article if it just leads OP to re-ask the same question. ;)
Sarah Vessels H
2010-05-14 16:52:57 Scores:13
Answer 10
Scores:2

Two things:

  1. It just takes time no matter how good a technology is. The ideas behind FP is about 70 years old. But its mainstream usage in Software Engineering (in the trenches, in industry) is probably less than 10 years. Asking developers to adopt racially new mindsets is possible but just takes time (many, many years). For example, OOP really got mainstream usage in the early 1980's. However, it did not gain dorminance until the late 1990's.
  2. You need people to be forced to face a technology's strength before it hits it big. Currently, people are using tools that does not not make use of parallelism and things works okay. When apps that do not use parallelism become unbearably slow; then many people will be forced to use parallelism-tools and FP may shot up in popularity. This may also apply to FP's other strengths.
Phil H
2010-05-14 16:37:43
but functional programming isn't recent ...
eglasius H
2010-05-14 16:58:38 Scores:1
FP is _very_ good at code reuse. Probably better then OO. I've had to deal with it at work a few times, migrating to different types, and a new system and it was painless.
nlucaroni H
2010-05-14 17:35:44 Scores:1
@Freddy Rios and @nlucaroni. I reworded the comment to clear up misinterpretation.
Phil H
2010-05-14 22:30:18 Scores:0
Answer 11
Scores:2

When I think about what functional programming might bring to my projects at work I'm always led down the same path of thought:

  1. To get the full advantages of functional programming you need laziness. Yes, there are strict functional languages, but the real benefits of functional programming don't shine as well in strict code. For example, in Haskell it's easy to create a sequence of lazy operations on a list and concatenate them and apply them to a list. Eg. op1 $ op2 $ op3 $ op4 $ someList. I know that it's not going to build the entire list and internally I'm just going to get a nice loop that walks through the elements one at a time. This allows you to write really modular code. The interface between two modules can involve handing over potentially vast data structures, and yetyou don't have to have the structure resident.
  2. But when you have laziness, it becomes hard to reason about memory usage. Changing the Haskell compiler flags frequently changes the amount of memory used by an algorithm from O(N) to O(1), except sometimes it doesn't. This isn't really acceptable when you have applications that need to make maximum use of all available memory, and it's not great even for applications that don't need all memory.
user207442 H
2010-05-14 22:52:43
Laziness also interacts less-than-ideally with debugging.
Brian H
2010-05-15 00:35:22 Scores:0
As I find that many of the bugs I chase in other languages are related to lack of referential transparency I'm less worried about the debugging issues, even though they can be a pain sometimes.
user207442 H
2010-05-15 23:15:46 Scores:0
Answer 12
Scores:1

I don't imagine a future with a pure functional languages. But I really believe that functional and OOP languages can be a very good and powerful pair. For example if I will have a little free time I would really enjoy to have a little project with mix of C# and F#. So in general don't view functional languages as replacement for OOP languages like C++, C# or Java... But they can bring a lot of advantages.

Incognito H
2010-05-14 16:50:42
Answer 13
Scores:-1

Functional programming is not for the masses to adopt because it's very hard to understand. Some people just may never understand even though they try.

ktasy H
2010-05-15 03:13:59
I think that those people, however, deserve at most to be called “code monkeys”. If you cannot or do not have the patience to wrap your head around functional programming, you surely can't possess the wizardry necessary for the title “programmer”. Just my two cents.
Jonathan Sterling H
2010-05-16 03:15:24 Scores:4
Sometimes you have to be a 'code monkey' to get a paycheck titled 'programmer'
Jeff O H
2010-09-16 15:06:01 Scores:4
Share |
View original post at stackoverflow.com

Related topics

If we can do functional programming with Python, do we need a specific functional programming language?

Using generators and lambda, we can do functional programming with Python. You can also achieve the same thing with Ruby. So the question is: why do we need specific functional programming languages such as Erlang, Haskell, and Scheme? Is there anything different that these specific functional programming languages provide? Why can't ...

Introducing functional programming constructs in non-functional programming languages

This question has been going through my mind quite a lot lately and since I haven't found a convincing answer to it I would like to know if other users of this site have thought about it as well. In the recent years, even though OOP is still the most popular programming ...

Is functional programming the next step towards natural-language programming?

This is my very first question so I am a bit nervous about it because I am not sure whether I get the meaning across well enough. Anyhow, here we go.... Whenever new milestones in programming have been reached it seems they always have had one goal in common: to make ...

Should functional programming be taught before imperative programming?

It seems to me that functional programming is a great thing. It eliminates state and makes it much easier to automatically make code run in parallel. Many programmers who were first taught imperative programming styles find it very difficult to learn functional programming, because it is so different. I began to ...

Is functional programming a subset of imperative programming?

One of the main characteristics of functional programming is the use of side-effectless functions. However, this can be done in an imperative language also. The same is true for recursion and lambda functions (for example C++0x). Therefore I wonder whether imperative programming languages are a superset of functional ones. ...

Erlang (Functional Programming) vs Object Oriented Programming in terms of thinking

I am learning Erlang and I am trying to create a very sample blog program. However my mind currently is trapped in the OO world (var p = new Post(); p.Title = ""; p.Save();). I would like to understand some basic thinkings in Erlang. Instead of creating Post object what ...

Functional programming vs Object Oriented programming

I'm an Object Oriented programmer looking forward to learning a functional language. My questions are: When do you choose functional programming over object oriented ? What are the typical problem definitions where functional programming is a better choice? ...

Can someone give me examples of functional programming vs imperative/procedural programming?

Are procedural and imperative the same thing? ...

Stateless Object Oriented Programming vs. Functional Programming?

One of the prime reasons for the increasing shift in attention towards functional programming these days is the rise of multithreading/processing and the advantages of FP's focus on side-effect free, stateless computation in making scalability effortless. Certainly, though, in Object Oriented programming, we could also shift to a stateless paradigm, ...

Are functional programming languages suitable for graphics programming?

Just very curious about this, from my own experience , all the graphic programming seems to C or C++ related. Like the Direct10X. Does functional programming language provide some sort of graphic library to develop video game? ...