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?

Jonas
  • 14,867
  • 9
  • 69
  • 102
  • 5
    LINQ? .NET delegates? DSLs like Mathematica? – J D 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. – J D Feb 05 '11 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 Dec 07 '11 at 17:13

13 Answers13

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Note to self - think of a name
  • 3,916
  • 1
  • 26
  • 24
  • 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 Oct 13 '10 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 Dec 12 '10 at 03:49
  • 1
    Most widely used tools just do not provide convenient facitlities for being functional. So one would not be completely off track advocating it. As it was said "in politics like in archery: if you want to hit the target you should aim higher". So let functional fad be. Hopefully we'll have better tools in a while. –  Jan 20 '11 at 13:17
  • 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 Feb 01 '11 at 09: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 Feb 05 '11 at 17:22
  • 1
    Well stated. In fact, Microsoft isn't pushing F# (their .NET function language) as a stand-alone language, but rather encouraging developers to use it along side existing code, as a way of enforcing the segregated use of purely functional code in an already state-heavy system. – cwharris Oct 19 '11 at 07:16
  • 1
    @xixonia, F# is not a pure functional language, it is perfectly imperative (and eager). – SK-logic Oct 19 '11 at 09:59
  • @SK_logic, true, but if it's as an imperative language, the developer is missing the point. Also, I never said F# was a purely functional language. – cwharris Oct 19 '11 at 14:16
  • 2
    Presumably a pure function program would leave the world totally unchanged by running it ? – Martin Beckett Nov 06 '11 at 22:05
  • 1
    @JonHarrop: You can use Debug.Trace.trace. It's a tiny bit more work than just a print statement, but not much. Certainly easier than putting a print statement in a Python lambda, for example. – Tikhon Jelvis Dec 08 '11 at 06:10
  • 1
    Also, I think UI may be a bad example. We're just used to writing UIs in terms of state, but FRP offers an interesting alternative. I haven't done more than read about it myself, but others seem to find it a very elegant way to implement UIs. – Tikhon Jelvis Dec 08 '11 at 06:12
  • I disagree. An SPA is very state-based and yet Elm & PureScript are quite wonderful with it allowing you to do side-effects in only very limited places such that it is split off from the rest – Post Self Feb 25 '21 at 16:24
  • In Haskell exp `seq` unsafePerformIO can be used to add print logging to pure functions although it doesn't enforce ordering. – aoeu256 Apr 22 '21 at 16:25
29

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.

Jerry Coffin
  • 44,385
  • 5
  • 89
  • 162
  • 4
    Perhaps there would be more crossover between functional languages if there were more functional languages. – Barry Brown Nov 07 '10 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 Dec 07 '11 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 Dec 08 '11 at 06: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 Mar 29 '15 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 Apr 28 '16 at 22:44
  • 1
    @cat: partly true, but definitely only partly. For one thing, in the case of procedural languages the gratuitous proliferation doesn't generally result from failure to compromise, but from sheer ignorance and stupidity (e.g., PHP) or from marketing at the expense of technical mediocrity (e.g., Java). The question wasn't about the problems with procedural programming languages though, so that would have been off-topic. – Jerry Coffin Apr 29 '16 at 00:08
  • @cat: In any case, your "all just boring iterations of C that don't solve the real problems" just shows pretty much the same attitude: narrow-minded certainty that you know the real problems with C, and the people who designed all these are ignorant, stupid, or for whatever other reasons missed the ultimate truth to which you are privy. This despite the fact that many of them are routinely used (and can even work reasonably well) for tasks to which C would be extremely poorly suited at best. – Jerry Coffin Apr 29 '16 at 00:16
  • @JerryCoffin Well, my narrow-minded certainty about the problems of C *is* narrow-minded, because in fact those are the problems *I personally* have with C and its children. I don't think there's one perfectly perfect language for all things; I think different languages and different things work for different people, and that's why they design their language that way. Some days I wake up and feel like I could rule the world in Lisp, and other (most) days I feel the same with [Factor](http://factorcode.org), and people who like PHP need counselling (that we can agree upon.) – cat Apr 29 '16 at 00:26
  • @JerryCoffin But the point I was trying to get at with the "boring iterations" thing was they all just seem to blindly follow their immediate predecessor. For instance C#, JS and PHP have semicolons and braces (ugly or not) because Java / C++ did because C did because BCPL did because people were too lazy to implement lexers that didn't rely on semicolons. I don't quite see this same sort of blind follow-the-leader stuff across all functional languages. Sure, all Lisps have (((lots of these))) but that's cause it's Lisp (more lazy parser writers). – cat Apr 29 '16 at 00:29
  • C#, JS, PHP, AS, Kotlin, Java, C++, also all seem to have *literally the same exact object system / heirarchy*, and some would even prod that it's not "proper OOP", because "proper OO" is Smalltalk and Self. That's the point I was kinda getting at. But off-topic it is, and I sure wasn't expecting a reply. :P – cat Apr 29 '16 at 00:33
  • A lot of the "follow the leader" mentality is (I think) more a matter of marketing (but: BCPL actually *didn't* require semicolons in many cases). I can see similarity between C#, Java, and Scala class hierarchies; C++...a *lot* less so. From a practical viewpoint, I think the syntactical similarity is more a asset than a liability in most cases (e.g., if Java hadn't looked extremely familiar, nobody would have bothered). – Jerry Coffin Apr 29 '16 at 00:50
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.

Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
  • 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 Oct 29 '10 at 00: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 Jan 03 '11 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 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 07 '11 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 Dec 08 '11 at 06:25
  • Lisp is an abstraction inversion...? It lets you do lots of cool things like define your own version of let, do, set, define, if, apply - this is very powerful, in many languages these things are just fixed in stone. – aoeu256 Apr 22 '21 at 16:40
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.

Dima
  • 11,822
  • 3
  • 46
  • 49
  • 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 Jan 03 '11 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.

glenatron
  • 8,729
  • 3
  • 29
  • 43
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.

mrsteve
  • 450
  • 3
  • 10
  • 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 Apr 22 '12 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.

Huperniketes
  • 2,205
  • 14
  • 17
  • Agree with the first sentence, disagree with the second. You basically can't do FP without garbage collection. – dsimcha Apr 12 '11 at 03: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
    +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 09 '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 08 '11 at 06: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.

anon
  • 1,474
  • 8
  • 8
1

Time To Market

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

Jé Queue
  • 3,937
  • 2
  • 29
  • 37
  • 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 Oct 28 '10 at 15:55
  • http://www.paulgraham.com/avg.html – Job Oct 19 '11 at 03: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.

Brad Clawsie
  • 740
  • 3
  • 7
  • 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 Dec 27 '10 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 Jan 03 '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
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.

NoSenseEtAl
  • 253
  • 1
  • 6
  • 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 Dec 08 '11 at 06:19
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.

Giorgio
  • 19,486
  • 16
  • 84
  • 135
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.

Vatine
  • 4,251
  • 21
  • 20
Belun
  • 1,314
  • 8
  • 15
  • 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](http://en.wikipedia.org/wiki/Map_%28higher-order_function%29) 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 05:09
  • Expressiveness is relative. Once you understand Lisp, you can read it just like any other language. – Michael K Jan 14 '11 at 18:18
  • it is relative, indeed. i just have trouble reading a line of code that has many things done in it (and that's because it's something you can do in fp) – Belun Jan 17 '11 at 12:18