Functional programming is not new, it has been around for many decades. The reason it didn't catch on is because it doesn't map very well to how our brain works. Human brains are object oriented, so OOP is very easy to grasp.
The real question is, why are people now taking a second look at functional programming. And the answer is Moore's law. Moore's law is coming to and end, and CPUs are not getting faster. Instead they are adding more and more cores. To take advantage of lots of cores you need concurrency. OOP is not very concurrency-friendly because objects have state, and to avoid corrupting state in a multi-threaded environment you need locks, and locks reduce concurrency. Functional programming doesn't have state, so you don't need locks, so you can get better concurrency.
That's utter rubbish. My team has been working with Clojure for close to a decade now. We regularly hire coop students from university, and none of them have ever had problems learning functional programming. It typically takes around a couple of weeks for a student to become productive and start writing useful code. The only people I've ever met who say that FP doesn't map to the way our brains work are people who're deeply invested in imperative style and never tried anything else.
The reasons for the imperative style being dominant are largely historical. Back in the day we had single core machines with limited memory and very slow drives. Imperative style and mutability makes a lot of sense in this scenario. Today, the problem of squeezing out every last bit of performance from a single core is not the most interesting one. And we're naturally seeing more and more FP used in the wild because it's a better fit for modern problems.
Have you actually tried it? I dunno, after using Clojure for a while I realize now - there's nothing weirder than having to dig into deep, nested hierarchies of Java classes. I simply don't understand anymore people who willingly write that kind of code and even claim to be happy and productive.
I would venture a guess to say that what makes FP or declarative style programming/thinking feel weird is not any great context like the nature of the human brain but rather the lesser one that usually people try to learn it after already having had learned imperative style stuff.
The functionally written recipe from https://probablydance.com/2016/02/27/functional-programming-... may be less helpful if I need to know exactly what steps to take to bake a cake, but it will actually be much more helpful if I want to know what a baked cake is. It isn't quite a fair example because it leverages how humans already know what a baked cake is, what a preheated oven is, etc and the clunkiness of the FP-style recipe is likely more due to that than anything fundamental to FP.
Let's try a different example that better maps to real world application logic. The task is to build a scootybooty.
Imperatively, a scootybooty program is:
- Acquire four wheels and two axels.
- Chop down a tree.
- Plane wood from tree into curved flat shape.
- Attach axels to convex side of planed wood shape.
- Attach wheels to axel.
Declaratively it is:
- A scootybooty is a planed plank of wood with two trucks.
- A planed plank of wood is a flat board.
- A truck is an axel with two wheels.
Now imagine your boss asks you wtf this scootybooty thing is and what it can do. Which program more quickly allows you to answer these questions? My favorite thing about the FP/declarative paradigm is that the mental model first-classes the abstract thing you are implementing above how you implement it. Imperative style encourages you to think about the steps it takes to do something moreso than the thing itself which IMO can lead to cart-before-horse type mistakes in planning. Declarative programming: "the forest is made of many trees", imperative programming: "tree, tree, tree, tree, tree, tree..."
It's not just my team, there are many of people working with Clojure and other functional languages out there, and there are plenty of FP projects in productions in pretty much every domain.
Functional programming is weird in the same way Japanese is weird to an Anglophone. A person who learned Japanese as their mother tongue will find English equally weird. The comments in the link you posted already address the points the author tries to make, which all boil down to FP being different from what they're used to.
Yeah I've gotta be honest the first few times I was taught OOP I couldn't quite grasp the purpose. I like it now for encapsulation of state, but generally I find it much easier to deal with records + pure functions as building blocks.
No, you can't. Because like the other commenter noted: "This is utter rubbish." It only looks easy to understand on the surface, but quickly becomes a mess. "spaghetti code" and "lasagna code" are the terms invented in OOP realm.
Being said that - some advanced FP concepts can be pretty daunting to grasp as well.
Saying that human brains are OOP or FP oriented is equivalent to saying that human brains wired to recognize patterns in music but not color, or something like that.
> Functional programming doesn't have state, so you don't need locks, so you can get better concurrency.
This is not true.
Many algorithms are intrinsically imperative (e.g., quicksort). You can represent it using some monads in Haskell to hide this, but in the end your code is still imperative; and if you want to parallelize it, you still have to think about synchronization.
The real question is, why are people now taking a second look at functional programming. And the answer is Moore's law. Moore's law is coming to and end, and CPUs are not getting faster. Instead they are adding more and more cores. To take advantage of lots of cores you need concurrency. OOP is not very concurrency-friendly because objects have state, and to avoid corrupting state in a multi-threaded environment you need locks, and locks reduce concurrency. Functional programming doesn't have state, so you don't need locks, so you can get better concurrency.