
Why Functional Programming is not more widely used in industry? - xmklb
The advantages of functional programming appear to put it ahead of other paradigms (like procedural and object oriented programming), yet it seems it still remains associated mostly with academia, if at all.
======
brianolson
Because it's hard and non-obvious. Nothing in the real world works this way
(including computers). It's mathy, it's hard like math, it's beautiful like a
proof, but that only works for the small subset of the population who want to
be mathematicians. Maybe there's some brain structure thing where this works
better for 5% of the population. Maybe their biologically wired implicit
grammar processor in their brain is a little different. Maybe in the next
century we'll find a gene for 'functional programmer'. But it still just
doesn't work for the majority of people. If it works for you, rock on with
that for your solo work or find a group of likeminded people and do something
with them, but I think it's just not going to have appeal to most people.

~~~
SubMachineGhost
> Because it's hard and non-obvious.

I would argue that for someone who never programmed functional programming
will be much easier to learn.

Your statement is only correct for people who programmed for years in an
imperative style and then tried to pick up FP, because at this point you have
a lot of unlearning to do, and a lot of your know how becomes absolute, don't
use variables, don't use loops, push your side effects out... and after all
this unlearning you'll have to learn new concepts and abstractions like Monads
and Applicative...

~~~
gerritsg
Do you think monads, functors, recursion, and immutability (just to take a few
staples of functional programming) are easier for a beginner to wrap their
head around than loops, re-using variables, etc?

I would be surprised if, using a sample group of say 100 beginner programmers,
the majority found Haskell easier to learn and write beginner stuff in than
JavaScript, python, or insert-primarily-imperative-language-here.

~~~
didibus
Most of these are advanced topics though. You don't teach a beginner about OOP
design patterns from the get go either.

If you start with defining functions, calling them, composing them, and using
map/filter/reduce and all the stream like operations filter, remove, select,
merge, substract, etc. I think it might be just as simple.

Haskell is a bad choice though, because it also forces you to learn about
advanced type theory.

The truth is, I do believe there is a gap in that there's no FP language that
doesn't also introduce another complex paradigm. MLs introduce advanced type
theory. Lisps introduce advance meta-programming and homoiconicity.

If you take Python, and teach it using only its FP constructs, I think that is
probably simpler to learn to a beginner.

------
rossdavidh
First, I think functional programming is used more often than you realize. Not
_pure_ functional programming, to be sure, but the use of functions instead of
objects is found in tons of real-world software.

Now, as to why pure functional programming is not used, well it's the same
reason why pure anything is not found much outside of academia, or why there
aren't always unit tests, or why there is still lots of procedural
programming. The software gets written in a hurry, by lots of different
programmers with different levels of experience, and they do it in different
ways. Some of them use a functional style, and some use objects, and some use
bubble gum and duct tape.

~~~
didibus
It's unclear though if functions that are not pure can be considered
functional programming, or those are just procedures, and the use of
procedural programming.

------
didibus
I think its because you don't need too.

I love functional programming, and actually work in Clojure at my job, we
switched from Java.

That said, it is not a killer feature. It is only marginally better in a way
that only converts can appreciate.

To management and devs not using it, they don't notice anything different
about the software we deliver.

Yes, it makes you marginally more productive. Yes, our code is marginally
safer. And ya, you could probably measure the difference given rigorous study.
But its not big enough to be obviously better.

And while you gain a marginal boost in productivity, safety, evolvability and
simplicity. You also lose in performance and memory consumption. Unfortunatly,
the latter two metrics are much easier to measure, and thus more noticeable.

Also, most FP languages have extra barriers to entry. Lisps have unfamiliar
syntax and meta-programming tacked on. MLs have complex type theory tacked on.
There's not really an FP language that has a simple type system, and familiar
Algol like syntax.

Finally, the fact that the benefits are not obvious, and only marginal,
combined with the huge lead that procedural and OOP languages have. Which they
gained because for a long time FP was too slow to be practical. Means that its
almost impossible to make a dent in the industry. The momentum for OOP and
procedural is too strong. More experts to teach beginners, and more existing
code writen in them, means people only learn and work on and get better at OOP
and procedural.

------
cimmanom
Because for the vast majority of software, fast to build is far more important
than provably correct.

Because there aren’t any batteries-included RAD frameworks in functional
languages yet.

Because most undergrad degrees, if they touch on functional programming at
all, do so in only a cursory manner.

Because for most purposes a smart CTO will choose to develop a project in a
language/framework that’s good enough and for which it’s relatively easy to
hire skilled developers over a language/framework that offers some minor
technical advantages but will make hiring even more excruciating than it is
for widely-used tools.

------
nikonyrh
One of the reasons could be that most programming languages do not have
immutable datastructures by default, and most students are taught to progam
within a "mutable" environment. Isn't of the first things they teach at
schools about "variables", symbols which refer to locations in RAM which might
change their contents at any time (at languages like C, Java and C#)?

I think Rich Hickey calls this "place oriented programming" ;)

It is funny how mathematical formulas do not have a "return" statement, they
are just evaluated. Math doesn't have an assignment operation either.

~~~
modells
I'll see your monad and lift you a functor.

Or maybe computer programming should start bottom-up, progress through single-
static assignment (SSA) and then get to impure, mutable constructs.

------
a-saleh
Depends where.

I.e. I spent 3 years on nodejs project, and first require was either lodash or
underscore, bringing in the usual suspects of map, reduce, filter along with
some sort of pipelining operator.

I spent 6 months on C# project using RX, and the code was quite functional,
with anonymous functions and closures everywhere.

Of course, once you move away from mutable data-structures and variables as
default (i.e. clojure, erlang), or even to limitting side effects with type
system (haskell), you are entering a niche.

------
seanwilson
For new projects, a lot of it has to do with what existing libraries and tools
you can use to get to market quickly. For established projects, it's going to
be a hard sell to switch over.

I really like OCaml for example but for web projects it's not practical.
TypeScript is a decent compromise at the moment. I like that the industry is
(veryyy) gradually moving towards strong typing though.

------
m3kw9
Another reason is not a lot of people know what it really means to go
functional.

~~~
xmklb
Do you mean they don't know the benefits of functional programming?

------
UK-Al05
Has slightly higher barrier to entry than other languages.

Companies would rather hire 100 replaceable monkeys over 10 highly paid
functional programmers who are hard to replace.

\- Replaceable monkey.

------
Sevii
Functional languages often fall into the trap of making hard things easy at
the cost of making easy things hard and then no one uses them.

~~~
bjourne
Funny, I'd say it is exactly the opposite. :) FP makes easy things almost
trivial but hard problems almost impossible. E.g writing quicksort is trivial
in Haskell, writing an implementation of quicksort that runs _efficiently_ in
Haskell is very hard.

~~~
Jtsummers
However, efficiency should be secondary to ease of reading/writing and
validity of the program (wrt target application) for _most_ programs
(obviously efficiency is a primary concern for certain embedded domains,
network applications, and game engines).

The nice thing (from my view) about functional languages (particularly those
of the ML family, but also the logic languages like Prolog) is that the
semantic distance between specification and implementation is very short. This
means you can rapidly describe your problem domain and translate that to a
reference implementation.

If performance is critical, you can then work on improving the efficiency of
this implementation, or write the program (or parts of it) in a separate
language. When it comes time to verify the second program (with a larger
semantic gap between specification and implementation) you can run both,
ignoring timing, and observe whether they produce comparable output (within
whatever constraints you need for your application, so equal or within some
error bound).

When your specification changes, you can modify the reference implementation
first (where reasoning about the problem ought to be easier) and then work on
your deployed system. This does introduce overhead in that you're maintaining
two systems, but if you're doing good V&V you're already building a
comprehensive model of your deployed system. Why not have a model that can
generate your test procedures and target results for you rather than hand
building everything?

