28

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?

3
  • 5
    LINQ? .NET delegates? DSLs like Mathematica?
    – J D
    Commented Dec 27, 2010 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.
    – J D
    Commented Feb 5, 2011 at 17:53
  • 3
    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
    Commented Dec 7, 2011 at 17:13

13 Answers 13

Reset to default
58

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.

13
  • 21
    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
    Commented Oct 13, 2010 at 17:29
  • 9
    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
    Commented Dec 12, 2010 at 3:49
  • 10
    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
    Commented Feb 1, 2011 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.
    – J D
    Commented Feb 5, 2011 at 17:22
  • 2
    Presumably a pure function program would leave the world totally unchanged by running it ?
    – Martin Beckett
    Commented Nov 6, 2011 at 22:05
30

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.

11
  • 4
    Perhaps there would be more crossover between functional languages if there were more functional languages.
    – Barry Brown
    Commented Nov 7, 2010 at 18:53
  • 5
    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
    Commented Dec 7, 2011 at 17:16
  • 7
    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
    Commented Dec 8, 2011 at 6:14
  • 2
    To me, this answer reads like a rant. Your argument would be much more compelling if you were to give some examples.
    – Benjamin Hodgson
    Commented Mar 29, 2015 at 22:33
  • 1
    ...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... No, that sounds like all these procedural langs. Java, Scala, Kotlin, C++, C#, Groovy, Cheddar, ES6, Ceylon, Python, the list goes on and on -- they're all just boring iterations of C that don't solve the real issues. That's my ranty opinion to complement this ranty answer :D
    – cat
    Commented Apr 28, 2016 at 22:44
21

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.

6
  • 11
    +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
    Commented Oct 29, 2010 at 0:56
  • 18
    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
    Commented Jan 3, 2011 at 17:10
  • 6
    @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
    Commented Sep 28, 2011 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
    Commented Dec 7, 2011 at 22:44
  • 4
    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
    Commented Dec 8, 2011 at 6:25
8

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.

1
  • 5
    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
    Commented Jan 3, 2011 at 17:15
5

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.

3

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.

1
  • 3
    "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
    Commented Apr 22, 2012 at 17:14
2

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.

5
  • Agree with the first sentence, disagree with the second. You basically can't do FP without garbage collection.
    – dsimcha
    Commented Apr 12, 2011 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
    Commented Apr 13, 2011 at 19:11
  • "You basically can't do FP without garbage collection." - Why?
    – quant_dev
    Commented Apr 16, 2011 at 19:20
  • 1
    +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
    Commented May 9, 2011 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
    Commented Dec 8, 2011 at 6:22
2
  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.

1

Time To Market

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

2
  • 3
    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
    Commented Oct 28, 2010 at 15:55
  • paulgraham.com/avg.html
    – Job
    Commented Oct 19, 2011 at 3:37
1

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.

5
  • 9
    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
    Commented Dec 27, 2010 at 19:48
  • 3
    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
    Commented Jan 3, 2011 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
    Commented Apr 22, 2012 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
    Commented Apr 22, 2012 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
    Commented Apr 22, 2012 at 16:49
0

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.

1
  • 5
    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
    Commented Dec 8, 2011 at 6:19
0

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.

7
  • 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
    Commented Oct 28, 2010 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
    Commented Oct 28, 2010 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
    Commented Oct 28, 2010 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
    Commented Oct 28, 2010 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
    Commented Oct 29, 2010 at 5:09
0

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.

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