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?
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.
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.
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.
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.
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.
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.
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.
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.
Time To Market
Difficult to rid a full IT landscape of procedural code and mantras.
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.
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.
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.
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.
