Ask HN: Why is functional programming not more popular?

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

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

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.

* 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.

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.

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.)

This is a recent talk on the topic by Richard Feldman: https://www.youtube.com/watch?v=QyJZzq0v7Z4

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.)

(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!

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?

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).

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.

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 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++.

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.

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.