Languages do not becomes successful due to their intrinsic qualities. Languages become successful when they are coupled to a successful platform. E.g. C became popular because Unix became popular, JavaScript became popular because of the browser, Objective-C became popular because of the iPhone and so on.

Therefore observing that a language or paradigm is popular or unpopular does not say anything about whether it is good or bad. JavaScript is the most popular language in the world. If Netscape had decided to use a Scheme-like language or a BASIC-like language it would still be the most popular language in the world. So paradigm has nothing to do with it.

Functional programming is less popular because no major successful platform has adopted a functional language as the preferred language.

I don't buy that functional languages are unpopular because they are unintuitive. Losts of stuff in JavaScript is highly unintuitive. It didn't prevent it from becoming the most popular language in the world. People will learn what they need to learn to get the job done.

For me OOP is weird. I never understood what people mean when they say it is close to how they think. It feels like a way to obfuscate the flow of code and requires to make decisions about what thing should have which responsibility and relation with which other thing and building weird hierarchies that will bite you back in the long term.

Relations between Objects change, customers don't know what they want, change is always pain with OOP.

Now people say, composition over inheritance. Right, but isn't that the point of functional programming?

Functional programming maps to how I think. The most important questions is always: What data structures do I need? Get your data in order and the rest will flow naturally.

I don't use functional programming because I am a math nerd or something, I am not even good at math. I use is because it is composible and easy to understand. I can refactor without any fear of side effects.

Now is pure functional programming practical? For some tasks, sure but yeah not always. Imperative programming gets stuff done. Work with the strengths of both.

The thing you are not used to always feels weird, that is a problem with you not the thing you try to learn.

Some of the weirdness is so completely avoidable that it frustrates me, but languages and libraries dig in on ‘you get used to it.’ I’m talking about the f(g(h(x))) vs x | h | g | f. Right to left chains of functions seem more popular than chains of pipes in FP, but even being someone who has drunk the kool-aid deeply, I always prefer pipes.

‘Take the pan out of the over once it’s been in for 30min, where the pan contains a folded together eggs and previously mixed flour and sugar’ isn’t more FP than ‘Mix the flour with the sugar, then combine with eggs, then fold together, then put it into the oven, then take out after 30min.’ But people new to it so often think it’s an FP thing for no good reason. It’s a new user issue that ought to be totally fixable as a community.

FP has enough great ideas that I’d recommend everyone learn pure functional solutions just to put into their tool belt, but it’s absolutely true that getting up to speed is harder than it needs to be. My hot take: it won’t be really mainstream until someone figures out how to make dependent types really ergonomic, which seems a long way away.

I recently watched this talk-

Why Isn't Functional Programming the Norm? (https://youtu.be/QyJZzq0v7Z4)

Here's the HN thread- https://news.ycombinator.com/item?id=21280429

I learned in that talk, among other things that Oracle spent $500 million to promote and market Java.

- https://www.theregister.com/2003/06/09/sun_preps_500m_java_b...

- https://www.wsj.com/articles/SB105510454649518400

- https://www.techspot.com/community/topics/sun-preps-500m-jav...

Fully functional programming (e.g. Haskell) isn't popular because it isn't ideal and computers work imperatively.

Even in a "functional" task (e.g. compiling) sometimes you just want an imperative algorithm. And while Haskell allows this via state monads, they're clunky.

Meanwhile there's practically no tradeoff to writing functional code in an imperative language. In fact there's lots of functional code in most C++/Java/Python programs. Most "imperative" languages are actually hybrid functional and imperative, supporting "functional" constructs like lambdas and pattern matching.

99% of the time a functional program will get executed sequential and strict anyways. The other 1% of the time, in an imperative language you can explicitly encode functionality (e.g. generic stream operators which work concurrently and on lazy streams).

It really isn't. Just see Racket, Clojure, Elixir, and F# for practical functional programming languages.

This article is pretty terrible. There isn't even a functional implementation, with just a half hearted attempt to even understand how to do it.

Functional languages excel at state machines. The example is pretty terrible too with regards to imperative programming being a good fit, because literally no one enjoys the real life statefulness and mutation when cooking. If you mess up, there's no going back. Why would you want to embrace or repeat that feature in your implementation? Functional state machines just pass explicit state around instead of mutating some random collection of variables.

And god, those C++ examples make me nauseous.

Functional programmer here. It's a different way of thinking is all, I don't see it as solving puzzles exactly. It's unfortunate if people see it as being about complexity or being clever. Done well, it should be the opposite. Once you understand the key abstractions, it can make code a lot easier to write and reason about in some cases. That's the joy of it for me. It furthers my day to day software engineering concerns of readability, maintability, testability etc. Nothing more.

It's just another tool though and there are many places where it's not appropriate. It's also a personal taste thing, I get that. It's worth persisting with it on a deeper level though just for the sheer joy of those 'a-ha' moments that come. Even if you don't use it in your day job, just bending your brain with different programming paradigms is well worth it.

I don't know. I don't write functional because it's hard and I'm super smart, I write functional because it's easy and I'm lazy.

I'm also not sure the example in TFA is much of an argument. From a glance looks like the programmer got entangled in their own cleverness, but the slice we are shown is too small to show if there's some external reason to do it like that.

story time: once did a compile time parser generator with c++ templates. "Zero-cost" abstraction and all that jazz. Turns out the binary was so large that a type-erased vtable system ran faster, for all its nonzero cost.

Templates are orthogonal to functional or imperative. It's a code generator. Understand what you generate!

Fact: functional programming takes more time to learn. It's not full of people that are "smarter' or "snobs" it's just full of people that have taken the time and invested in educating themselves to get to the point where they can do it well. It's not "better", it's just a useful tool for certain types of problems. I'd advise any young engineer to just learn how to do both "imperative" and "functional" programming well and avoid getting dogmatic about it. The vitriol here is in dogma here to be sure

Subversion:

Functional programming is popular because it's intuitive!

Perhaps "immanent" or "diagrammatic" is a better word than functional. I mean that a function _is_ what it does, but not so with a procedure. One cannot bake a value as one does a cake!

See React's dominance. See the usefulness of declarative state machines. See async/await.

Functional programming gets a bad rep. People often fail to see the functional elements in more imperative code and the imperative elements of more functional code. In fact very few language constructs are necessary to open up 99% of functional possibilities in imperative languages (functions as values) or imperative possibilities in functional code (do-notation). Any critique that dismisses one or the other misses the point.

May add more explanation later.

I've seen a handful of articles and conference talks where the main thrust is "why isn't functional programming more popular". Apparently it works well and is "intuitive" for some people. I think the first thing we should do is recognize the amount of neurodivergence amongst programmers.

The WISV-IV GAI tests for verbal comprehension and perceptual reasoning. It provides an estimate of general intellectual ability, with less emphasis on working memory and processing speed. My GAI is 124. Which means I'm fairly intelligent (sic. "superior") when it comes to understanding language and reasoning. It makes me a fairly good problem solver. I'm an ok programmer (judged against the hundreds of programmers I've paired with through my consulting work).

That said, I've tried to learn Haskell three times and given up each time. The functional model of D3js kicks my ass. I cannot grok LISP.

It turns out my WMI (working memory index from Wechsler Adult Intelligence Scale) is BELOW AVERAGE. This makes holding lots of recursion or abstraction in my head at once quite difficult. I also suffer from adult ADHD.

I love long functions in a procedural style. I'm quite proficient working that way. There's not too much abstraction and behavior hiding (why I grew to hate OO). You can see how my neurological makeup impacts what "good" code looks like. I also understand that James Gosling has a kind of synesthesia and that impacts the structure of his code to the point of causing problems for others (see Lex Friedman interview).

I said all that to say this. What makes code understandable/readable/clean is in the eye of the beholder. There's quite a bit of neurodivergence in our field and we need to account for that when deciding on how to critique code. After all shouldn't code be written first and foremost for humans to understand and only incidentally for compilers? (paraphrased from SICP)

I wonder now much C++ matters here. I rarely reach for functional patterns when the language I'm using does not provide proper constructs for readable, declarative code like pattern matching, nominative discriminated unions, and pipe operators.

Sure, you can fake all that with other constructs or patterns. But then it really does feel more like a puzzle.

IMO, good FP is good when it is maximally declarative and organized in the linear way in which humans reason best.

Maybe the author should try F# or OCaml instead of Haskell! I love FP and have also tried and hated Haskell three or four times.

OpenAI Codex is pretty good at translating code between languages. It's far from perfect - but it can get simple cases perfectly. It knows languages like Rust, Haskell, Erlang, and more.

I found that I could translate Python to Haskell using Codex and get more real working Haskell code far, far quicker than I could manually.

I think Codex will be a simply incredible tool for learning new programming languages, could definitely make FP easier. It may not be super "smart", but it's smart enough, it knows a ton, and it's got superhuman recall.

Another idea is that you could filter Codex suggestions for those that pass the type-checker, and keep regenerating until it passes.

It's so incredibly fun. It made me want to never stop coding.

Functional Programming Is Not-Popular Because It-Is-Weird,

not

Functional Programming Is Not Popular-Because-It-Is-Weird.

I just found the ambiguity amusing, in the title of this particular blog post.

It's probably just me, but I found loops much more intuitive than recursions for those non-recursion oriented problems. That is to say that I prefer to use recursion ONLY for those are un-intuitive to solve by loops in a trivial way.

Functional programming forces you to think a bit like a theoretical physicist seeking to write equations for fundamental laws: the universe is modeled as interacting particles that start free, collide and interact and end up free again. No concept of historical dependence or sequential evolution. In physics these attributes emerge only as descriptive crutches in the context of poorly understood complex, macroscopic, systems undergoing various transitions. We have much less clue how to write universal equations for such systems.

So FP might have a theoretical advantage as a building block of low-level software systems that are not throwaway labor (that is: only valuable in specific historical window / context).

In any case the factors driving programming language popularity have changed dramatically ever since the developer universe got truly "connected". There is a winner-take-all network mechanic that basically inflates whatever initial advantage into a (difficult to explain ex-post) catholic dominance.

Functional programming isn’t how people think, and it isn’t how computers work. Therefore it’s a bad way for the two to communicate.

I'm happy the author wrote this blog post, it very much reflects my take on FP.

And if I had to keep one sentence from it: mutable states are very useful.

FP addicts consider mutable states to be something to be banished at all cost, much like a generation of 70's academics tried to do away with goto's.

The fact is, there are lots of situations in the real world where using mutable state variable is the very best way to model the problem:

   - easier to understand
 
   - faster to execute

I am not a huge functional programmer, but the big weapon in FP's wheelhouse is that pure side-effect FP is far more suited to multicore/threading/processing, which is where all the future gains in processing will probably come from.

Functional programming is the most popular current paradigm. What is everyone on about? Javascript, a functional language, is one of the most popular languages ever. Rust and go, two other popular languages, also eschew object-oriented programming, the former dominant paradigm, for a truly functional one.

C++ is gaining more and more functional features, and this is quickly becoming the predominant style.

Here's "clippy", Rust's style enforcement system, complaining about an insufficiently functional form.

    warning: manual implementation of `Option::map`
       --> src/viewer/regionindex.rs:265:13
        |
    265 | /             match vlinkopt {
    266 | |                 Some(vlink) => Some((*vlink).clone()),
    267 | |                 None => None
    268 | |             }
        | |_____________^ help: try this: `vlinkopt.map(|vlink| (*vlink).clone())`
        |
 
    note: `#[warn(clippy::manual_map)]` on by default

    for further information visit 
    https://rust-lang.github.io/rust-clippy/master/index.html#manual_map

I like the puzzle analogy but I'm not sure it holds too much weight. Didn't imperative style also kind of feel like a puzzle when you first started learning how to code?

Remember those light bulbs that went off when you finally incremented an index variable at the right moment, or when you finally figured out the right condition for a while loop? Clearly all styles are puzzle-like when you are first learning them.

I think functional programming has more or less the same learning curve as other styles.

In my view, the reason functional programming isn't more popular is because of Comp Sci curricula.

There are plenty of institutions where there may be one course on functional programming (if you're lucky). Then, many students seem to (incorrectly) internalize the idea that anything their degree doesn't cover extensively must be of lesser importance.

Discussed at the time:

Functional Programming Is Not Popular Because It Is Weird - https://news.ycombinator.com/item?id=11188570 - Feb 2016 (75 comments)

This talk by Richard Feldman is an excellent discussion about why Functional Programming is not the norm -

https://www.youtube.com/watch?v=QyJZzq0v7Z4

For me the problem is that "functional programming" embodies a lot of questionnable ideas:

- the idea that readability is not the first thing to pursue

- the idea that macros are great

- the idea that leaving performance off the table is OK

- the idea that objects and subtyping are useless

- the idea that mutability is hard to reason about

- the idea that recursion is super important

- the idea that somehow closures are more readable than objects

- the idea that tuple are somehow better than structs with named fields

It is a style that thrive _in opposition_ to the style of useful programs out there: readables, no macros, fast, with an UI, with mutability, with objects, with names.

I find functional programming reasonably straightforward to learn but difficult to master.

For example, this Common Lisp cheat sheets covers a large part of the language and isnt hard to follow

https://github.com/ashok-khanna/lisp-notes

I was doing some Haskell and Racket and I found basics not too hard to learn, but I did then too hard to master, but I think thats to do more with the complexities of the problems I tried to solve and less to do with the languages themselves

Something I've wondered is why we can't have a language that looks totally procedural but uses monads under the hood to reason about state at any given point in the process. This would mostly be sugar, but I think it could make that stuff much more accessible.

We get small, specialized fragments of this in Rust's borrow-checker and TypeScript's control-flow analysis, but I'm not aware of something that tries to take the whole of IO-monads and reshape them into a familiar format.

I believe that functional programming is not as popular as some think it should be, because the more popular languages stole a lot of its mojo. Other languages absorbed and used many functional programming concepts.

It became like, "No need to go over there, you can do most of it here, in a language you already know."

As for OOP, I think many people have found ways to circumvent or minimize how much they use it, so are not going over the edge with inheritance and another kind of spaghetti. If they can use a struct, record (Delphi/Free Pascal also have advanced records), prototype (JavaScript, Lua...), OOP without classes (Go, Vlang...), or classes with only data then they do. There is more awareness to try and avoid the traps and excesses of class-based OOP.

I actually don't like recipes written in an imperative style and I don't think this is how cooks think about them internally. They are the norm for written recipes, but whenever I read one I (and I assume other experienced cooks) translate it into a functional style for internal storage.

Consider a recipe for macaroni cheese. In imperative style it might be written like this:

Thread 1, step 1: melt butter, add flour, gradually beat in milk, simmer.

Thread 1, step 2: remove sauce from heat and stir in cheese.

Thread 2, step 1: bring water to boil, add salt, add 125g of pasta, simmer.

Thread 2: step 2: drain pasta.

Join threads: Fold pasta into sauce and serve.

Nobody thinks about how to make macaroni cheese like this. My internal record for macaroni cheese is more like this:

"Basically it's macaroni and cheese sauce mixed together. You cook pasta in boiling water with salt. Cheese sauce is béchamel sauce with grated cheese. Béchamel sauce is made with a roux and milk. A roux is butter and flour."

In fact, if you look in any decent cookery book, the information will be stored like this. A good book teaches you techniques and builds up raw ingredients into basic building blocks and then final recipes. Only a stupid book tells you how to make béchamel sauce 20 times because 20 different dishes use it.

Hm, what about a language like Joy or Factor? It is written sequentially, as a recipe, and (in the case of Factor) can have side effects. And yet it is deeply functional, because of the compositionality of words.

I really like Haskell, but I think Factor is going to be my next thing (although it needs better type system, like Kitten has attempted to), for the reason that it further simplifies Haskell's (already simple) syntax.

I am quite intrigued by functional programming and I spent a fair amount of time with Haskell. I believe that there are cases where functional programming should be relevant, for example numerical software, where by definition you pickup an input once, do a lot of calculations and produce an output (think of lapack, or numerical functions). There is no event loop or continuously looking for input to adjust state. Shouldn’t functional languages be ideal in implementing such algorithms in a simple way and perform better than fortran? They clearly don’t thrive there, but they should. So in the end I got the impression that functional languages about the mental challenge of finding a non trivial problem that an a functional language can solve better than a more traditional language. It might be a form of art in programming: finding the best problem for the tool.

There is an opinion that learning things more thoroughly is helped by making said things in some particular ways[0] harder to learn (so we struggle at first, make our discoveries and get that dopamine boost when we grasp a concept).

If we take it as a given, then (controversial opinion) it seems possible that popularity of languages and paradigms that are easy and make intuitive sense (and are not weird, like functional languages) could by itself lead to a lowering of average knowledge level across the industry, even if the difficulty of a language has nothing to do with it being objectively somehow better.

[0] Not the way Brainf*^%k does it, though.

1. It's weird because it's different. It's different is because it's on the other branch of the skillsets most people used to for years.

2. To learn things on the other branch, people need to unlearn until they reach the common ancestor node.

3. Unlearn is a form of subtraction. Humans suck at subtraction, be it learning things, making products, or just the human civilization itself - it's even easier for it to collapse and start over.

It's the same idea that Japanese is much harder to learn than German: Because it assumes the learner speaks English, while Chinese people that don't speak English would mostly find Japanese is much easier.

I read this title as: "Functional programming [is popular, but not] because it is weird."

I was hoping how it would discuss how building software using functional programming techniques made the paradigm uniquely suitable for popular use.

Anyway, I digress.

I often wonder, if LOGO, which was inspired by Lisp became more popular than BASIC whether functional programming would have become popular earlier. Many Gen X kids like me were exposed to both, but basic was more broadly avaialbe and often was the OS of your computer, But LOGO was really good for its time and it made it simple to structure your program around functions and build upon functions in a semi lispy/schemey way. It instantly change the way I thought about programming and often attempted to replicate that method of programming in basic.

I think the actual problem is that a lot of the functional programming discipline is about writing code to be understood by machines (eg: compilers, theorem provers, etc) in ways that can trade off against the convenience of people reading and writing it. When I have to write a program that computes functions of programs, I always reach for my FP knowledge, first thing, and start using the more "theoretical" branches quite quickly.

But program analysis and synthesis are different actual endeavors from writing some bog-standard, everyday code.

I'm not convinced with a convoluted C++ example. Why would you reason about FP in a language that was never built for it? Also, there are some mixed paradigm languages (like Clojure) that avoid pitfalls of the pure FP programming. And yes, I do consider purity a pitfall for some kinds of applications. Actually, Clojure even has OOP features that are a la carte and don't create the artificial inconveniences that make you build enormous GoF pattern based solutions to overcome those.

For me functional languages lose to imperative ones because they make it harder to reason about what actually happens when the program is executed. When you see a nested loop, you immediately know that it will probably perform O(n^2) operations. This is not so in functional languages. I clearly understood it when I was reading about Haskell and learned that out of `foldl` and `foldr` one works in constant time and another in linear. I don't remember which.

undefined

Pure Functional programming’s cost comes up front when you are trying to solve and express your solution. Imperative programming’s cost comes after you have written code, because it is inevitably buggy and incorrect. Imperative programmers and managers don’t mind because fixing bugs feels and looks like productive work, and they don’t believe bugs are largely avoidable.

Why does functional programming need to be popular or not popular? Functional programming is one of the several programming paradigms in Python, C++ 20 and Java programming languages. It could be used when appropriate, just as other programing paradigms. I think FP is the norm, when needed, in Python and now increasingly in Java and C++.

I like functional programming because I like algebra.

When I can reason about things in a way that I understand, that makes me happier as a programmer.

I don't think it needs be any more complicated than that.

If it's not popular, so be it. Most of what I am interested in is not popular. I don't care.

This article is from 2016, so if we're going to look back a bit, then maybe some perspective is in order?

In the grand scheme of things, I look at ReactJS today, with its modern incantation of hooks, and that "language" reminds me a lot more of SML (yes, anyone remember SML?), than it does with C or Java. I started programming professionally back in 2005. Back then OCaml was the rage because we thought it would support OO, and bridge FP and OO, and ReactJS did not exist yet. It was taken for granted that OO and "imperative" were practical. So it's interesting to me that modern ReactJS is more like SML than it is like OCaml. And it's actually practical. People for whatever reason don't consider it weird. Meanwhile, "idempotency" is something desired by the masses, even in infra / devops. For example, at least amongst my coworkers, we generally agree that e.g. terraform is "better behaved" than ansible.

If you're looking for a revolution in these sort of things, I don't think you're going to get it, because FP a la Haskell is indeed too "weird." As working engineers, the most important thing at the end of the day is to deliver some working tool or product.

The current generation of actual-FP languages have been too much of a pain to be practical. They had to be. They were breaking new ground as far as what could be done. In my mind, Haskell proved the limits of System F. The language was pretty much a test-bed for what you could do if you eschewed any attempt at "backwards-compatibility" with previous mental methods of programming. From a research perspective, that was hard enough to do.

But meanwhile, Swift is a massively better language to code in because Haskell and SML existed.

Change did not come as a revolution, the way we expected it. People understand FP better than they ever have, on some instinctive level, and that's how the world was able to move further away from C++ / Java, and towards SML. Ironically this happened in UI – and in the web – which in 2005 seemed like the last place where FP could possibly succeed. It was generally understood in 2005 that FP was bad at "state," and UIs, of all things, were highly stateful. (To be clear, Haskell is still a pain as far as state goes, but not as much of a pain as it used to be.) So when you put this all together, we can say that the world works in weird ways. It wouldn't surprise me too much if the languages of tomorrow actually turned out to be weird, but that'll probably take another 15-20 years to see out.

Any new thoughts since this post

Previous discussion: https://news.ycombinator.com/item?id=11188570

I think the big difficulty in trying to bake the functional cake is that the author tried to name every step, when he didn't do this for the imperative cake.

A big shout out to those institutes and universities that teach FP in intro to programming(CS 101). FP is the foundation for computer science theory.

comments are bringing out grand thesis or bike shed of FP, but wjat OP actually wrote the article about was being forced to use recursion instead of iteration andnconsidered that FP.

If OP had titled his post recursion is weird I think we'd be seeing some different line of comments.

Secondly, his recursion example not really support his opening comments about FP and cakes.

Thirdly, you dont have to do things backwards in FP.

The monadic recipe is

    main :: IO ()
    main = do
      // … followed by imperative recipe

This is possibly the best article on functional programming I've ever read.

My experience is that fp is notoriously bad at dealing with errors. Errors are quite common in everyday business cases, although usually ignored, (like in c#), which makes it hard to “fit” into whatever you are working with. Any language that doesn’t treat errors as a first class citizen in it's syntax is a bad one, which I feel like that languages like Haskell isn’t doing well. Also errors are contextual so it’s not always so that an error is one in some context and may be so in others. So the language must be flexible enough to handle both in a nice way. I think Java is kind of a good example of this where it had checked exceptions to signal errors, but when introducing fp syntax they completely botched how errors work. This left you with a mess and programs keeps crashing because people didn’t know that code could throw errors.

>Ah screw it I can’t finish this. I don’t know how to translate the steps without mutable state. I can either lose the ordering or I can say “then mix in the bananas,” thus modifying the existing state. Anyone want to try finishing this translation in the comments? I’d be interested in a version that uses monads and one that doesn’t use monads.

He's wrong and he completely misunderstood functional programming. It's not weird at all. Let's get things straight. First off there's a difference between functional programming and types. Monads are more of a type centric thing and also haskell centric. Haskell is a big part of functional programming but it's only one style. You can do functional programming without monads and also without type checking. Additionally type checking and even haskell-like type checking AND monads can exist in imperative languages as well (like rust.) Does rust having monads make it functional? No.

Second functional programs can be very very very very readable. It depends on how you structure it and your naming conventions. See example below:

   list of data primitives (aka ingredients and tools): 
      cake
      grease
      flour
      small_bowl
      large_bowl
      pan
      whisk
      salt
      oven
      cream
      butter_milk
      white_sugar
      brown_sugar
      walnuts


      heatedOven = preHeatOven(oven, 175)
      panWithGreaseAndFlour = putGreaseAndFlourInPan(grease, flour, pan)
      bowlWithWhiskedIngredients = whiskStuffIntoBowl(small_bowl, whisk, salt, flour, baking_soda)
      bowlWithSugars = mixStuffInBowl(large_bowl, white_sugar, brown_sugar)
      bowlWithSugarsAndBananas = mixStuffInBowl(bowlWithSugars, bananas)
      bowlWithAllingredients = mixStuffInBowl(bowlWithSugarsAndBanas, bowlWithWhiskedIngredients, buttermilk, walnuts)
      panWithAllIngredients = pourContentsOfBowlIntoPan(bowlWithAllingredients, pan)
      heatedPan = heatPan(panWithAllIngredients, heatedOven, 30)
      finishedProduct = coolPan(heatedPan)

      Create a heated oven by heating an oven to 175 degrees.
      Create a pan with grease and Flour by putting grease and flour into a pan.
      Create a bowl with whisked ingredients by whisking salt, flour and baking soda into a small bowl with a whisk.
      ....

Think about it this way. Let's say we live in an imperative world where we have an oven. We then heat the oven. Now in the imperative world the oven is destroyed and replaced by a heated oven. We only refer to the "heated oven" as an "oven" for convenience but in fact the original "oven" is actually destroyed as in it no longer exists.

In functional programming THE only difference is that the original oven is NOT DESTROYED. That's it. You have a heated oven, but you still have a reference to the original oven. But you don't ever need to refer to original oven if you don't want to. This makes English describing imperative processes more or less IDENTICAL to functional processes.

Another perspective to think about this is that in the English language we create the heated oven but the original oven is not destroyed but moved! The oven is now moved into a namespace called the past, we can only refer to the original oven by appending or prepending one of the many names and phrases of the "past" namespace to the oven! For example: The oven "before it was heated", the oven "from the past", the "original" oven,... etc.

So from that perspective then the only difference between FP and english is that variables once operated on, are moved to a different namespace. So literally just extra past-tense embellishment on English grammar is the ONLY difference.

It gets crazier than this. Is anything in reality really mutable? What does mutability even mean? We live in a universe where each instance of time is it's own namespace. The universe is a function of time. At t1 there is an oven, at t2 there is a heated oven. So really mutability is just syntactic sugar over immutability where just gloss over mentioning what time namespace we're in for convenience. Yes you heard that right. Everything is actually immutable and mutability doesn't exist. Our concept of "mutability" arises from language shortcuts we take and assumptions of present tense.

Either way from the examples this guy writes it's pretty obvious functional programming didn't click for him. He understands the rules like immutability and he sees all the crazy tricks and nutty types people associate with functional programming but he missed the big picture. Hopefully this explanation will let the concept of functional programming click a bit more with people.

There is in fact a deeper intuition for why functional programming is "better" than imperative programming. But that's another long explanation. Most people don't ever reach this point of realizing how functional programming is better. They could spend years doing functional programming and completely miss it. Instead they reach a state where they think functional programming is sort of a style of programming used to express intellectual arrogance with no practical benefits and they give it up and move back to imperative programming. Well, they are wrong and they missed a deeper understanding of a fundamental concept. If this sounds like you, I'm telling you... you missed the big picture.

Literally the OP is a picture perfect example of this. Completely missed the point of FP but spent enough time with FP to understand what a monad is, even though a monad isn't really technically an FP thing.

I like the FP syntax in Java 16, rust and clojure.

I dislike it in Scala, C++ and javascript

Ah, to be reminded of high school, where one could be not popular simply because they are weird.

I think that they've confused functional and declarative?

Clickbait garbage.

Functional programming isn't popular because the talent pool for experts in languages like Haskell is

* tiny

* composed largely of insufferable snobs who will insist on reminding you that they're smarter than you and understand computing on a deeper level

Whereas the talent pool for jalopy languages like Javascript and Python is full of easygoing can do barbarian hustlers who will do everything wrong but make your prototype work well enough for you to get the next round of funding. And if you really need heavy duty people who are still pragmatic, there's always the large and deep C++ talent pool

People always underestimate how much the aesthetics of things actually matter. Language adoption is a numbers game and good marketing matters.

This is why Lisp never won. However powerful and elegant it may be, Lisp syntax is downright ugly.

The exact same thing happens with Haskell. However amazing the language is, its freaking unapproachable and the syntax is - like the OP says, weird.