
Ask HN: Why is functional programming not more popular? - allanmacgregor
In the last couple of years I been getting involved with Elixir development and as of late starting get my toes wet with Scala.<p>The more I learn and use functional programming languages like Elixir, the more I&#x27;m convinced there is a significant advantage to using functional languages&#x2F;paradigms specially in certain domains.<p>Yet, Functional programming is still regarded as a fad or fringe, curious to hear HN perspective on the matter.
======
stevenalowe
Dear FP evangelists - Here’s how to sell the unwashed masses on FP:

1\. Shut up about monads. “Monads” sound like a bad D&D monster. No one cares
about either of those things

2\. Benefits sell, not mechanisms. Show me the benefits in a way that solves
my problem without warping my brain around in the process, and I’ll buy it.

3\. Every new paradigm has a ‘gap’ that must be overcome, a proverbial “click”
of a new brain-circuit forming, before understanding/enlightenment is
possible. This process is accelerated by direct experience, but slowed
glacially by overly formal abstract presentations

4\. Stop trying to show me how hip/smart/woke/l33t you are by spouting FPisms;
that impresses no one, bores most, and makes you look like a poseur. Benefits,
McCoy.

5\. I love Scala, but it’s an acquired taste that didn’t happen overnight, and
it started as a non-threatening “better Java” path that led to self discovery
through refactoring. Please Give us space to breathe and languages that don’t
cause Calculus 101 PTSD flashbacks.

~~~
quickthrower2
The space to breath argument is interesting. I like Elm because there is no
room to “breath” in the sense you can’t do all the bad old JS stuff. That’s
what makes it useful: Guarantees. In other words way fewer bugs where
something weird happens and no one can fix it.

------
SamReidHughes
There are several kinds of FP:

There's FP as in, it isn't horrid C++/Java class-making with virtual functions
and constructor boilerplate.

There's FP as in, hey we've got lambdas and are doing stuff with them (like
chaining callbacks or using futures).

There's FP as in, a language that materially inhibits your ability to be non-
explicit about what your code is doing.

So it might be good to be aware of what mechanisms by which FP provides a
benefit. Much of it is, it's not horrid class-making and workarounds to do
basic stuff the language should support. It's just half-decent language
design. But then there's the matter of being materially or somewhat culturally
being explicit about side effects. And these are two different aspects.

And many devs don't get the latter. They're kind of smart-sounding words and
they'll agree with them if you say it, but they don't really get it.

And among people who don't really get it, there's also the FP people who
cargo-cult it. I'm talking about the people that rewrite their for loops in
terms of map/reduce/std::transform or what-have-you, because they're crazy
people unwilling to make mutable local variables. (Kind of like how some will
never make a function-local goto statement.)

------
yesenadam
(Probably this is a very naive comment. Anyway..)

I've dabbled in some FPish languages, most lately Prolog (which I loved) and
ML. I do a lot of graphics programming, so was wondering how to do that with
ML. Like say you have an 3D array representing colour pixels, and want to
change a pixel's colour. It seems in FP either you make a new copy of the
whole updated array, or use fiddly workarounds where you store the changes and
actually do them at some later time.. Googling about it, I felt quite
embarrassed for FP, since all the talks I'd seen present it as a mega-cool
super-sophisticated best way of doing everything. And as if changing variable
values is a barbaric sin. ..So, back to C to do graphics.

Situations like this, where large data structures must be repeatedly changed
in small ways, which happens in a lot of domains I guess, seem tricky to do
efficiently with FP!

------
Tomte
* People think imperatively most of the time.

Together with

* Imperative/OOP programming works. All kinds of cool software have been built using those paradigms.

that means that few people have a pressing need to look into functional
programming. Some who are curious do. Some of those love it and don't want to
go back.

But there's nothing wrong with not doing functional programming!

And last

* Both C++ and Java have adopted (or stolen) quite a few things from functional programming languages.

The FP purist will say that it doesn't matter, but it really does. They stole
those parts that get their users maybe a quarter the way to functional
nirvana, but with very little effort. That's obviously enough to succeed.

~~~
valand
Agreed with most of this comment, except:

> _People think imperatively most of the time._

Most of the time people think declaratively. Heck, people dream, wish, and
plan declaratively. They wouldn't even know how they got to their thoughts and
dreams. They're just there instantly.

------
fulafel
In the market of ideas, there usually isn't any reason that makes the good
ideas unpopular. That's the default outcome.

Some good ideas eventually make it to mainstream / conventional wisdom because
there's some second factor that brings them to the spotlight. For languages it
might be a killer app, big corporate investment, etc.

In
[https://www.youtube.com/watch?v=QyJZzq0v7Z4](https://www.youtube.com/watch?v=QyJZzq0v7Z4)
Richard Feldman puts up a (well founded IMO) argument that OO became
accidentally popular because of C++. C++ didn't do OO well, nor was OO the
main benefit of C++, it just happened to be something that came with C++.

------
p1esk
Because no one can clearly explain the advantages of FP. Not “in theory”, but
using commonly used practical tasks. I don’t care about immutability unless it
clearly makes my life easier and so far I got by just fine with non-FP style
of doing things. The only valid argument I heard is “it expands your mind as a
programmer”. Yeah, whatever.

~~~
girishso
> it expands your mind as a programmer

That’s exactly what got me interested in FP. But after doing some serious work
in FP, I must say typed FP really does help keep my mind more saner, knowing
nothing’s broken in the product, with my changes here and there.

Of course, TDD helps in OO/imperative languages, but with typed FP you get
that almost for free.

~~~
valand
The last part really captures how TypeScript saved me from headaches. :D

~~~
girishso
When I said typed FP, I meant languages with ADTs.. Elm/Haskell etc., not
Typescript! :)

~~~
valand
I thought we were talking about FP paradigm, not the language, and the Typed
data concept which includes compile time type validations, type inference.

And also I'm pretty sure TypeScript has union, intersections, tuples, record
which are pretty much ADTs.

~~~
girishso
You're right, my bad. I didn't know TypeScript had ADTs. Should probably take
a serious look at TypeScript.

------
phonebanshee
You live in a world where the dominant programming languages include things
like JavaScript, PHP, and Python. It's not that no one cares about functional
programming, it's that almost no one cares about _any_ kind of structure.
(Yes, that's an exaggeration, but not by a lot.)

------
a_bored_husky
This is a recent talk on the topic by Richard Feldman:
[https://www.youtube.com/watch?v=QyJZzq0v7Z4](https://www.youtube.com/watch?v=QyJZzq0v7Z4)

------
artemisyna
You are correct that it is easier to use functional languages in some domains.
There are quite a few messaging clients that use Erlang under the hood.
Facebook uses Haskell for its spam engine, where being very explicit about if
a long chain of things fails open or closed is important. These days, most of
the major programming languages have ways of representing functional elements.

However, it's hard to make functional programming general purpose. There are
some posts about it elsewhere, but iterative programming tends to make
reasoning about the storage of different objects in memory quite a bit easier.
Given how all abstractions are leaky anyhow, there will almost always
eventually be some component that is easier to deal with using OOP. The
inverse is not necessarily true.

There are some practical considerations here as well. While it's possible to
make OOP-esque structures in functional languages, it's not trivial.
Meanwhile, using a piece of functional code in an already OOP system generally
isn't too bad - there is, once again, some syntactic sugar, but the scope
tends to be clearer. Putting a bit of functional code inside say, a class,
tends to muck with the usage and assumptions of said class less than putting a
bit of OOP into functional code.

~~~
lonelappde
Facebook had a working spam classification system, and they replaced the data
dependency graph engine with Haskell as a performance experiment. It's not to
do with failing open or closed. Note that they hired the inventor of GHC
Haskell's concurrency engine to do it, and he is not available to work at the
company :-)

~~~
artemisyna
Ehhhh I’ve heard the predecessor engine had much to be desired, so it probably
wasn’t only just the performance bit. That said, I could see performance (in
addition to execution guarantees) being part of the factors.

Sorry, not parsing the last sentence - what do you mean by “he is not
available to work at the company”?

------
muzani
I'd turn the question around. What does functional programming do better? What
would you miss about not having it?

I like OOP because it's like boxes where you can just plug one cable from one
part into another. It's easy to write "contracts" in, as in assigning what
object does what.

There are definitely flaws with this, in that it can get messy, but does FP
solve it better? What exactly does FP do better?

~~~
0_gravitas
Immutability is a big one, and I absolutely love things like Elixir's pattern
matching and pipe operator, I'll never program the same after coming into
contact with them. And I love never really needing to write a loop or to have
a "counter" variable, the declarative style just makes things much easier to
read, write, and understand imho.

------
ktpsns
My gut feeling: Because it is more difficult. Many people fear the learning
curve and better do what everybody else is doing.

~~~
AnimalMuppet
My take: Because it is more difficult _for most people_. I suspect that most
peoples' brains don't work as well in that style. Yes, they can learn. But no,
it would never be the best fit for them.

For some, FP is actually _more_ natural. To them, it's a revelation and a
freedom, and they can't understand why everyone else doesn't also find it to
be wonderful.

~~~
ktpsns
Well, for many people BASIC with "goto 10" feels natural and easy. Maybe for
most of us, if the programs are small. The question is: How do we deal with
increasing complexity? FP is an answer, OOP is another (certainly not
orthogonal) one. But people learn some traditional imperative OOP language at
college and stick to it. They are told "goto considered harmful", but
"imperativism considered harmful" did not really make it in their head.

------
valand
1\. Older paradigms have been reinforced by many predecessors, creating lindy
effect.

2\. Being a relatively new paradigm, less people understand where, when, how,
and why FP fits. There is a lack of effective education over FP.

3\. Having some radical jargons (e.g. HOF, recursion > looping) , FP brings
fear of change. Especially, recursion > looping can only be applied to
languages with gc, preferably those with tail call optimization.

4\. FP's more universal virtues (immutability, pure functions, type system, no
side effect) are not advertised enough compared to other virtues (recursion,
hof).

~~~
fulafel
I think your 3/4 are true for some people, maybe for those who were taught
academically flavoured FP in a computer science program, but on the other hand
when I web search for "why functional programming", the articles bring up
immutability and side effects first and rarely mention recursion or higher
order functions.

Also, can't resist nitpicking about tail call optimization: clang/llvm and gcc
implement it in a non-gc language (C), but meanwhile some FP language
implementations lack it, at least Clojure does. So while there's more demand
for that feature in the FP world and some FP languages like Scheme require
implementations to perform this optimization, it's conceptually somewhat
orthogonal to FP or GC.

~~~
valand
I didn't mean to say immutabilty and no-side-effects are advertised less. It's
just not enough of them are effective.

Those concepts helped me avoid a lot of headaches without knowing that those
are concepts of FP. Then there was a day where I just realized, "Oh, this is
FP"

I guess people need to be educated, or experience themselves, the concepts,
before hearing the word "FP" which mean less to them.

The examples provided in the internet needs to be more ambituous than mere
chains of functions. They need to be "remaking rsync with minimum IFs" or
"large scale React App without a single getDerivedState"

------
0xdead
Suppose you're in a situation where you have to resolve a bug under 15
minutes, or you'll get fired, or maybe your company will go bankrupt. If the
codebase if FP based, it is certainly going to be more difficult to quickly
find and fix the bug as compared to a codebase written in a simpler language.
FP is good for experimenting and playing with, but IMO it is not suitable for
anything serious. Rust is also not going to get too far for the same reason I
believe.

------
adamzapasnik
Give it some time, Elixir is clearly gaining traction.

I think it's mostly related to the "age" we live in. For the last two decades
OOP has been the main thing. New problems arise, software is written
differently now and a lot of development related things have been changing, so
maybe/probably there will be a shift to FP.

That's my sole opinion, though.

------
django77
Because when you start learning, you learn what is popular - in my case that
was OOP principles in python and javascript. Only later on I learned about
functional programming through Clojure. It's really hard to do that mental
shift, and it takes time. A lot of people don't want to invest into learning a
different paradigm

