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.

Functional programming is one of the oldest programming paradigms. However it isn't used much in the industry compared to more popular paradigms. But it have largely been emphasized in academia.

What's your strongest opinion against functional programming?

share|improve this question
5  
LINQ? .NET delegates? DSLs like Mathematica? –  Jon Harrop Dec 27 '10 at 19:15
5  
Incidentally, the term "functional programming" is used by different people to mean different things so you need to clarify which meaning you are using. –  Jon Harrop Feb 5 '11 at 17:53
2  
You'll never, ever find any people to code on your functional code base. Not a great business decision, limiting your talent pool. –  Patrick Hughes Dec 7 '11 at 17:13
add comment

closed as not constructive by Mark Trapp Dec 7 '11 at 23:03

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.

15 Answers

up vote 45 down vote accepted

The problem is that most common code inherently involves state -- business apps, games, UI, etc. There's no problem with some parts of an app being purely functional; in fact most apps could benefit in at least one area. But forcing the paradigm all over the place feels counter-intuitive.

share|improve this answer
17  
Absolutely. Pure functional programming is NOT well suited for very state-oriented applications. This is why I like hybrid languages that can do both. Use functional paradigms for functional problems, imperative paradigms for imperative problems. –  Matt Olenik Oct 13 '10 at 17:29
7  
Agreed! State is an essential part of programming. This is why even Haskell, in some ways the purest of the FP languages, allows use of state and IO - it simply enforces a distinction between IO code/mutable state code and pure code, which is very nice for testing and for ease of understanding. –  Bill Dec 12 '10 at 3:49
5  
That's why i love Haskell. It encourages to minimize those stateful code. In OO i aim to write reusable, easy to understand and easy to test code. Most of the time i end up with code i would not write much different in Haskell. –  LennyProgrammers Feb 1 '11 at 9:41
4  
"it simply enforces a distinction between IO code/mutable state code and pure code, which is very nice for testing". You cannot even print debug messages without either circumventing the type system or introducing monad creep. –  Jon Harrop Feb 5 '11 at 17:22
2  
Presumably a pure function program would leave the world totally unchanged by running it ? –  Martin Beckett Nov 6 '11 at 22:05
show 6 more comments

The problem with functional programming isn't functional programming itself -- it's most of the people who do it and (worse) most of the people who design languages in which to do it.

The problem stems from the fact that despite being very smart (sometimes downright brilliant) far too many of the people are just a little too fanatical about purity, perfection, and enforcing their own (often rather narrow) view of the world and programing onto the language and everybody who uses it.

One of the results is a failure to compromise. This leads (among other things) to roughly 10,000 languages and dialects that are enough different to annoy but only rarely enough different for one to have a truly significant advantage over the others. Many also look at the real world, and decide that since it doesn't fit the functional model very well, it's basically just wrong and best ignored.

The inability to compromise has also led to quite a few languages that are absolutely beautiful for a specific type of problem (or a few specific types of problems) but really suck for a lot of others. Some of that is probably caused by the functional model itself, but a lot more seems (at least to me) to be caused by the basic personality type that's attracted to this area to start with.

That leads to a number of problems. First of all, learning "functional programming" is mostly of philosophical value. With most other types of languages, knowing one language of a particular genre is of significant help in learning another. If my project uses language X I can usually hire somebody who knows language Y (but not X) fairly safely. With functional languages, that's much less true. You might know Erlang quite well, but still find Haskell monads completely foreign and incomprehensible.

Couple the number of languages with the limited portability of talent between them, and you get an ugly situation: it's almost impossible for one language or dialect to form the "critical mass" necessary to make it into reasonably general use. That's slowly changing, but it's still a lot like Linux becoming the dominant desktop OS -- every year, people come up with convincing arguments that finally this is going to be the year -- and just like the people who've been predicting that every year for decades now, they'll be wrong yet again. That's not to say that it (either one) can't ever happen -- just that the people who look at the predictions and think "nope, not this year" have been the ones who were right so far.

share|improve this answer
3  
Perhaps there would be more crossover between functional languages if there were more functional languages. –  Barry Brown Nov 7 '10 at 18:53
3  
You can't be "functional" without that purity. Once you step over the line the entire concept falls apart and you end up with a messy, parallel, standard language without any of the advantages. –  Patrick Hughes Dec 7 '11 at 17:16
4  
So your first problem is that functional languages are not different enough to have an advantage over each other, and your second problem is that they are too different to easily go between? –  Tikhon Jelvis Dec 8 '11 at 6:14
add comment

I think that the reason functional programming isn't used very widely is because it gets in your way too much. It's hard to take a serious look at, for example, Lisp or Haskell, without saying "this whole language is one big abstraction inversion." When you establish baseline abstractions that the coder can't get beneath when necessary, you establish things that the language simply can't do, and the more functional the language is, the more of these it tends to have.

Take Haskell, for example. In the name of functional purity, you're required to use brain-breaking abstraction inversions that nobody understands in order to manage state and I/O, the two most fundamental parts of any and every computer program that interacts with anything! That gets old fast.

share|improve this answer
8  
+1, though I sometimes feel the same way when I program in high-level imperative languages. For example, why the fsck do I need to make a single method class that implements a single method interface in Java instead of just using a function pointer like I would in C? –  dsimcha Oct 29 '10 at 0:56
11  
I would say it's not that you "can't get beneath" those abstractions, it's more that it just takes a lot of work. We're used to picking up a banana and eating it in an imperative language; Haskell (for example) makes you fill out a 20-page form first because it prioritises guaranteeing that no banana will ever mysteriously get eaten when you weren't looking. Which helps when reasoning about bananas, but sometimes you're just hungry. –  j_random_hacker Jan 3 '11 at 17:10
3  
@dsimcha: this is a peculiarity of Java rather than a trend in high level imperative languages. In fact, high level languages are probably more likely to have the function as a first-class object. –  Muhammad Alkarouri Sep 28 '11 at 19:11
3  
The necessity for monads in Haskell stems not from functional purity but from the fact that side effects and lazy evaluation are two great flavours that do NOT taste great together. Monads force sequential evaluation. (Really, they should be called Computation Builders or something. 'Monad' is a lousy name for anyone other than a category theorist.) And you can happily do FP without (knowingly using) monads! –  Frank Shearar Dec 7 '11 at 22:44
2  
One thing to note: given these "abstraction inversions", the language may be more limited, but the compiler and runtime have more guarantees about your code and can do more. This is just like garbage collection--in a gc language, you can't just malloc space (which could be useful), but in return, the runtime can manage all your memory for you, potentially more efficiently than you could manually. It's the same with functional purity. –  Tikhon Jelvis Dec 8 '11 at 6:25
add comment

With all due respect, I think your question is ill posed. Functional programming is a tool, or rather a set of tools that are useful for solving certain kinds of problems. Having an opinion about it only makes sense in the context of a specific problem or application. Having an opinion against it in general, is like having an opinion against pliers or wrenches.

share|improve this answer
3  
That's a logically valid point, but it can be remedied by tacking "for the kind of programming problems you frequently encounter" onto the final sentence of the OP's question. (It doesn't matter that individual readers will encounter different problems, providing they describe what they are.) –  j_random_hacker Jan 3 '11 at 17:15
add comment

My thoughts on functional programming (and probably others too): It's very interesting and I'd love to learn it someday. Unfortunately, I'm too busy doing real work now.

share|improve this answer
4  
Paul Graham wrote an interesting essay on how Lisp was a competitive advantage for his startup. Could it be that maybe this kind of languages are harder to master, but then are more powerful? –  UncleZeiv Oct 2 '10 at 20:42
3  
I'm not sure how true it is, but I heard that the people behind reddit read it and wrote the site in Lisp, just to rewrite it later on in a less functional language :-) –  Magnus Oct 4 '10 at 9:27
9  
Do yourself a favour and read why the Reddit folks rewrote from Common Lisp. –  Frank Shearar Oct 10 '10 at 20:45
    
What I'd like is more interop options. For instance, you can call Clojure functions from Java and vice versa. Then I can use functions for the things they're good at (stateless) and other languages for what they're good at (state, graphics?). –  Michael K May 9 '11 at 13:43
1  
@MasonWheeler It was lack of decent multithreading (on FreeBSD), and lack of decent, well tested libraries (blog.reddit.com/2005/12/on-lisp.html). You can write Common Lisp code that runs faster than C, in certain situations. Speed is not the problem. Libraries are. –  Frank Shearar Dec 7 '11 at 22:20
show 2 more comments

Even if I had mastered it, I might be disinclined to use a functional language for a commercial product for the simple reason that they are not widely understood and if I expected the business to grow I would be concerned about the ability to find other developers capable of maintaining or extending it over time.

It's not inconceivable, and you would probably get a higher standard of developer because a javaschool grad with no real hacking skills wouldn't know where to start on a project of that type, but the limited pool of capable developers would certainly be a necessary consideration from a business perspective.

share|improve this answer
add comment

I don't believe you should be forced to write functionally pure code (Haskell, although I still like the language.).

share|improve this answer
2  
Try Scala. It caters to a (non-lazy) functional approach but does not get in your way if you want to write side-effecting code. –  Randall Schulz Oct 2 '10 at 17:16
3  
@Randall Schulz: Scala gets in your way if you aren't a Java programmer. This kind of OO means a lot of unnecessary work and knowledge to read and understand other people's code. Scala is too big. –  stesch Oct 2 '10 at 18:00
2  
Scala in no way requires more than a smattering of Java knowledge. I don't even understand the 2nd sentence. The assertion that it is big is demonstrably false. –  Randall Schulz Oct 2 '10 at 18:38
9  
@Randall Schulz: Yes, that's the problem with Java people. You are so deep into UML diagrams, abstract classes and interfaces, that you can't understand anymore that there are simpler ways to program. –  stesch Oct 2 '10 at 18:54
3  
@Jonas: Real world code in Erlang looks very different from the easy examples that lure you into trying Erlang. –  stesch Oct 2 '10 at 20:24
show 7 more comments

Time To Market

Difficult to rid a full IT landscape of procedural code and mantras.

share|improve this answer
1  
Functional programs are often easier to test. And they are shorter. So disagree. I think you answer another question "What's your strongest opinion against switching to funtional programming?". –  Jonas Oct 28 '10 at 15:55
    
paulgraham.com/avg.html –  Job Oct 19 '11 at 3:37
add comment

FP is cool in academia because it is cool to write nice short programs, while ignoring performance. There isn't some conspiracy against it in real world. Also for example implementing some stuff(radix sort for example) seems like total pain in FP. Oh and generated code is IMHExperience sloooooooooooooooooooow.

share|improve this answer
3  
Yeah, that's just patently untrue. Haskell code is usually on par with C and Java, and much faster than Python and friends. It's also usually trivial to parallelize, potentially giving even more speed. –  Tikhon Jelvis Dec 8 '11 at 6:19
add comment

I am a big fan and advocate of functional programming. But here are my points:

  • easy to learn
    Programming languages like python and ruby (and many other languages) are easy to learn. Advanced functional programming, with languages like Haskell, Agda, Coq, ATS, etc., is quite hard to learn. Some use the term “mathematical structured programming”. It’s easy if you are familiar with category theory and abstract mathematics, but quite some work if you have no clue what for instance "monads" are.

  • programming with a scripting language can mean more productivity.
    In some situations using scripting languages like python and ruby can lead to more productivity. This means fast prototyping and gluing together different packages or libraries. Even using dynamic languages (e.g. dynamic object oriented programming) can be a good thing in this context. Usually static typing is better, but scripting with dynamic types can have a positive effect.

  • business considerations
    Programming is only a small subset of successful software projects. Software has to work, users have to be happy and this is don't necessarily depend on the programming language used. Managers have to think of the benefits and risk when evaluating new technology and programming languages. Can new programmers learn quickly the new programming language? Is there experience in the company with the technology? Is there a risk and will this be hard to argue with upper management?

In the business context, functional programming can be used in systems that add to the core software components,e.g., components that are not so mission critical. For example a bank that will hardly change the core software, but add new parts (GUI, monitoring software, etc.) in new programming language. (Maybe there are exceptions, but this is my experience with banks.)

Further, functional programming is very useful when formal verification is a benefit or a must.

share|improve this answer
    
thanks for the edit. I found another typo. cheers! –  mrsteve Dec 7 '11 at 17:39
2  
"easy to learn": I do not find mastering Haskell any harder than mastering modern C++. I think we tend to consider hard what we are not familiar with. –  Giorgio Apr 22 '12 at 17:14
add comment

I'm not opposed to FP as a useful paradigm, but I'm opposed to it as the only paradigm available in a programming language.

It offers advantages in solving a lot of problems. However FP can, and has been, applied in procedural languages like C.

share|improve this answer
    
Agree with the first sentence, disagree with the second. You basically can't do FP without garbage collection. –  dsimcha Apr 12 '11 at 3:14
    
There's no requirement that a language's runtime system lack transparent memory management (with garbage collection) in order to fit the "procedural" label, so it's ironic you phrased your second sentence that way. BASIC is one such language. –  Huperniketes Apr 13 '11 at 19:11
    
"You basically can't do FP without garbage collection." - Why? –  quant_dev Apr 16 '11 at 19:20
    
+1 Functional programming at the most basic level is stateless programming. I don't think there is any language that can't do this to some extent. I've written functions in C, C++, Java, assembly, C#, even Basic. All that is required is that the function not have side effects or retain state between calls. –  Michael K May 9 '11 at 14:39
    
On the other hand, if your language is entirely pure, the compiler has more leeway in its optimizations. Also, the code becomes easier to test and reason about. Being functional throughout does give some benefits over a hybrid approach; if you're going to have the majority of your code be stateless anyway, you may as well go a little further and reap the added benefits. –  Tikhon Jelvis Dec 8 '11 at 6:22
add comment

first of all i don't accept any of the arguments regarding state-ful programming and fp. look into the State monad in haskell and you will find a number of interesting new ways to assess the impact of state on your code.

if i was to make a meaningful argument against fp, it would be that learning a serious functional language like haskell is like learning to drive a formula one car....exhilarating and educational, but sadly useless for everyday industrial coding because, on average, your coworkers are driving camrys and are quite happy to do so. it is still extremely difficult to find work in an fp-friendly environment, and i don't see this changing unless one is willing to strike out on their own or seek out some of the well-known practitioners of fp.

i suppose my answer shows me up as a fp fanboy. i suggest giving a real fp language like haskell a serious spin before worrying about finding reasons why you shouldn't.

share|improve this answer
5  
I think your first paragraph describes exactly what's wrong with the FP mindset. We don't want "interesting new ways to assess the impact of state on our code." What does that even mean?!? We just want the state to be there and easily accessible because we need it to actually get things done. –  Mason Wheeler Dec 27 '10 at 19:48
2  
The Camry I drive has its problems, but it doesn't require me to constantly check under the hood for space leaks. Haskell is more like a language that looks like an F1 car, but can't actually do high revs for a sustained period of time. :-P –  j_random_hacker Jan 3 '11 at 17:24
1  
@Mason Wheeler: "We don't want interesting new ways to assess the impact of state on our code." Instead, we prefer to spend a week tracking down a very nasty bug due to an unwanted side-effect (I speak from personal experience). –  Giorgio Apr 22 '12 at 16:42
    
@brad clawsie: I think the whole issue of controlling side-effects in FP can serve to make coding much more productive: it takes longer to write but less time to fix. Unfortunately one has to put quite some effort into learning first, and lots of programmers do not have this long-term thinking: things must get done quickly. There is no time to do it properly the first time, but there is always time to debug and fix it later. :-) –  Giorgio Apr 22 '12 at 16:47
    
@Mason Wheeler: From a functional point of view, having a shared state is only useful for optimization purposes: copying values around takes too much time and memory, so you share a data object to avoid unneeded copying. But enforcing a shared state as a rule from the beginning is a kind of premature optimization. –  Giorgio Apr 22 '12 at 16:49
add comment
  1. (and by far the most important) The programmer workforce is not trained in those languages or styles
  2. Many of the functional evangelists come off as a-holes or fruitcakes because of the way they try to sell functional. No one likes an a-hole, and no one is going to throw money behind a fruitcake. Mind you, I really like the functional stuff and would like to pull it in, but I know at my workplace I'd be the only person who could develop it without spending money on training (hard sell), and almost all of the good references talk-down at the reader.

Functional will come around when we have hundreds of cores and hit the realization that locks don't scale. Then nested data parallel will be the only way to go for "big iron" programs, and functional excels at that.

share|improve this answer
add comment

Some have a learning curve quite steep, taking a long time (especially if you come from OOP; you'll beak your head a few times before getting the paradigm shift).

Even though i started getting functional programming (coming from Java and going to Clojure) i still find it quite difficult. The community does not seem to write code as expressive as Java.

Seems like there is a small loss in expressiveness and a small increase in complexity.

share|improve this answer
    
I think that people without previous programming experience would say that OOP has steeper learning curve than FP, since FP is closer to Math. I don't understand what you mean with " The community does not seem to write code as expressive as Java", what is your point? –  Jonas Oct 28 '10 at 15:58
    
I never heard of functional language losing expressiveness. But then I've never used a less expressive language than Java either, so I may have a different deffinition of "expressive". –  glenatron Oct 28 '10 at 16:29
    
@Jonas - because of one simple thing: shortcuting names for functions, variables, etc... i mean, why not just name things for what they are or are supposed to do ? why "pmap" ? –  Belun Oct 28 '10 at 19:23
1  
@Belun: That has nothing with functional programming to do. You must refer to a specific programming language. Map is a function common in many functional programming languages, and it has a good name. pmap you refer to may be a parallell variant. –  Jonas Oct 28 '10 at 19:31
    
i said "the community does not seem to write". it means that it's what i experienced and it reffers to the comunity i watched. it does not have to apply to all, although i doubt it. it does have to do with the functional programming, it's like its style –  Belun Oct 29 '10 at 5:09
show 2 more comments

Even though I have little experience with functional programming languages (I know some Haskell and Lisp) I find the FP paradigm very powerful and often more elegant than other paradigms. I wish I had the opportunity to work on a serious project using FP.

The only area in which I have some serious doubts regarding the effectiveness of FP is in how it can deal with complex data structures that cannot be defined inductively, e.g. graphs. For example, if I have to implement an algorithm that works on a large graph, possibly walking through the graph and making small local changes, I wonder if an FP approach can match an imperative approach in which the program is allowed to move from node to node using pointers.

share|improve this answer
add comment

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