You've done an excellent job of explaining why I consider functional programming to be pedantic nonsense created by people who want to take tasks that should be as simple as "see spot, see spot run" and turn it into vector calculus.

As I've said a few times, maybe it's because I started out hand assembling my own RCA 1802 machine language, my first high level language was Pascal, and that decade I spent working with Ada... but "functional programming" strikes me as the type of "Career educator" nonsense that was created by and for people who just don't know how any of this stuff really works.

The language constructs used are often painfully cryptic, unclear, and mired in a "programming is all math" attitude that's more bald faced lie than fact.

That you need all those compiler/interpreter level tricks -- like TCO -- to even make it viable just adds inefficiency overhead, and for WHAT?

Like the idiotic BS about how "bad" side-effects are... the NAME "side effect" seemingly chosen not to describe what's going on (accessing the parent scope) but instead a marketing decision to make people THINK it's a bad thing.

When honestly fighting against "side effects" typically leads to bloated, hard to manage code that makes an absolute mess of stack handling/garbage collection. Typically only viable for isolation via "throwing more code at everything" even if it's the language itself doing so behind the scenes; hiding every evil ugly sin of it from the programmer.

There's a reason Haskell never caught on outside the classroom and LISP has mostly gone the way of CoBol. A handful of holdouts but rarely found in the wild. But sure, let's repeat those abortive mistakes.

And it's painfully obvious what crowd came up with this nonsense too, hence your even mentioning "closures" -- a nasty case of "You keep on using that word".

Like this paranoid, whackjob, nonsensical "wah wah teh loops r teh evils" attitude that's been pissing on JavaScript codebases for a while now, with this each/every CRAP that just adds painful execution overhead in the form of endless moronic function calls for NOTHING.

My biggest problem though being how I've never ONCE seen a rational, reasonable, or sound explanation for what actual benefits there are. You said "all the things that purity offers" -- Such as? WHAT exactly are the benefits because all I ever see are card stacked examples that after 40 years of programming BOTH ways are rubbish.

To be fair though, I'm the nutter who'd write a factorial in JS as:

function factorial(n) {
  for (var x = 1; n > 1; n--) x *= n;
  return x;
}

… because I understand C syntax and don’t have this unfounded, bizzaroland, nonsensical belief that “teh loops r teh evilz!!!”

But your article hits it on the head in the "when to use it" section. It's not about “always using it to the exclusion of other methods”. It's another tool in the toolbox and should be used when appropriate. Just like OOP. The "Functional or nothing" halfwits being as big a bunch of tools as the "Everything should be an object" morons. It’s the same herp, just a different derp.

Honestly, when people start talking about “purity”? Run… just run.

… and remember, that’s coming from someone versed in Ada.