JavaScript's Functional Programming Mythology

JavaScript has acquired quite a mythology around itself. Like any good mythos, some of it's based in truth. Some of it's... not. Some take it as gospel. Some look at it skeptically. But the longer the mythos lives on, the harder it becomes to separate fact from fiction.

I'm talking specifically about the mythology that's grown up around JavaScript & Functional Programming.

Any mature technology goes through stages - fads - where people parrot catchphrases and slogans. JS is not unique in this regard.

PMs and dev managers have pull-strings in their backs, and every time you pull them, they say "Agile!" When I first started programming, the snooty senior types couldn't get through a paragraph without mentioning: "abstraction", "encapsulation", "inheritance", or "polymorphism". In the 2000s, no one believed that you could program a Hello World demo without making thorough use of "MVC".

And the JavaScript community can't even manage to cross the street unless they click their heels three times while chanting the JS Buddhist Mantra: "There's no programming like Functional Programming."

Technological Incantations

Every sector of tech experiences trends. Does this mean that every trend is part of a deeper mythos?? Not at all.

When I talk about a "mythos", I'm referring to a handful of key features:

1. The mythos is often heralded by a smaller group of generally-acknowledged "thought leaders".
   

2. There's often disagreement about what the mythos actually means.
   

3. Many people tend to blindly invoke the mythos's name - as though merely speaking it is the equivalent of implementing the technology (and solving hairy, real-world problems).
   

4. A mythos acquires followers (which I often refer to as: "fanboys"). These followers can be outright caustic in their unyielding support for the mythos - and their aggressive dismissal of alternate solutions.
   

5. Alternate histories are often crafted to imply that the mythos "has always been" and "will always be". References are made to the mythos in historical contexts that never previously made any sense.
   

6. The mythos's overbearing admirers can often obscure the fact that the mythos has many strong factors in its favor. In other words, if you're a fairly level-headed, empirical thinker, the fanboys can actually sully the reputation of the very thing they're fawning over.
   

Now look back over these points and tell me whether you personally think any of them can apply to the overall paradigm of Functional Programming? Especially as that paradigm is applied within the JavaScript community??

Some Quick Disclaimers

This is no s**tpost about FP. I'm one of the many, many people over the last 10-or-so years who've started to openly rail against some of the misguided dictates of OOP. As someone who started his career on the "server side", I've found frontend JS development to be downright refreshing.

Although it's taken me awhile, I've been slowly opening my eyes to ever more possibilities that exist in FP. If I'm being honest with myself, I become even more of an FP fanboy nearly every day.

But even though I'm enjoying this little journey, that doesn't mean I'm blind to the ever-growing sheen of hype that's been buffed onto the surface of FP. I don't know if there's a single aspect of FP that I don't like. But I still can't help but to occasionally roll my eyes at the ridiculous love that gets heaped onto the latest "Paradigm du Jour" that we now call "Functional Programming".

Let's explore some of the silliness that I currently see around FP...

Whatever You Want It To Be

FP is the Rorschach Test of the programming world. Ask 10 different programmers to define FP and you'll likely get 10 different answers. And those answers will say far more about those giving the answers than they will about the true meaning of FP.

At the risk of disparaging my own colleagues, I gotta say that FP's amorphousness is especially galling amongst some in the JS community. If you're one of the "cool kids" in JS, you spew endlessly about the mythical powers of FP. But to hang with those "cool kids", there's no entrance exam. All you gotta do is sing the praises of FP and they'll teach you the secret handshake.

If this sounds like I'm ruthlessly targeting some faceless crowd of FP supporters, please believe me - I'm not. Because simply defining Functional Programming isn't the elementary task one might assume it would be.

If you have a taste for programming theory and no social life (like... me), then spend a few nights going down the Google rabbit hole of "What is functional programming?"

Seriously. Give it a spin. I'll wait. Till next week. When you finally get exasperated and crawl back.

I can find hundreds of articles online that all give fairly consistent answers to, "What is object-oriented programming?" But when I try to do the same for FP, it's maddening to see the minute fractals I get pulled down from one site to another.

I'm not claiming that there is no definition of FP. I'm just saying that, if you spend enough time reading enough sites, and talking to enough programmers, and going through enough tutorials, it can be bewildering to see how much contradictory information you find.

Lies, Damn Lies, and Blind Faith

Rather than trying to define exactly what FP means, it may be more expedient to discount what others believe that it means. So here is a sampling of the effery that I routinely hear about FP (especially as it applies to JS).

All of my code is now in functions. Because I love Functional Programming! And this makes my code "FP"!

Umm... no. I'm sorry. This isn't even close to being correct.

Granted, it's a perfectly logical conclusion. It's one that I think most programmers have made at some point early in their careers. And on the surface, it seems... obvious. Right???

But as simple as it would be to state that "my code is in functions, and therefore this is Functional Programming," the simple fact is that most of FP's definitions make it clear that this isn't even vaguely correct.

I've learned (from experience, or by falling inline behind my more-senior programming peers) that OOP sucks. And I'm not even trying to write OOP. Therefore, I write FP.

Honestly, this "definition" isn't that far off from the truth. At least, it's not that far from the "truth" - as it's practiced in most dev shops.

You see, the programming world seems to be waking up from a long, hazy nightmare that we all knew as OOP. At the same time, there seems to be this irrational exuberance targeted on that shiny new prize known as FP.

So... in many scenarios, I've seen FP kinda loosely defined as "everything that's not OOP". I truly think there are some devs who believe that, if they're not writing classes and instantiating objects, then they must be writing FP.

I'm a JavaScript developer. And JavaScript is a Functional-Programming language. Therefore, I'm an FP-coder.

OMFG. STOP IT. Seriously. You have no idea how many times I've heard-or-read this blatant IDIOCY in the last several years.

At first, I brushed it off as a harmless nugget of misinformation. But it's become so pervasive that I'm starting to lose all patience for it. I don't even know where it originated. But at this point, I really feel like anyone spewing this "JS is an FP language" garbage is borderline-harmful.

But don't take my word for it. This is from what is, IMHO, the best general-purpose JavaScript reference site on the web - MDN (emphasis: mine):

"JavaScript is a prototype-based, multi-paradigm, single-threaded, dynamic language, supporting object-oriented, imperative, and declarative (e.g. functional programming) styles."

You may like the idea of writing FP-style code in JS. And JS certainly supports that. But that doesn't mean that JS is, inherently, an FP language. Nor does it mean that you're writing FP-style code merely because your codebase is written in JS.

If that's not enough evidence for you, let's look at what is-or-is-not an object in JavaScript:

1. An Array is... an object.
2. A Function is... an object.
3. NULL is... an object. (Yeah. I know. Wrap your head around that one for a minute.)
4. A Set is... an object.
5. Most of the "standard functions" we're accustomed to using in JS are part of... the global object.
6. I could go on...

Whether JS fanboys want to admit it or not, JS is downright rotten with objects. The language is practically based upon them.

Can you write functional code in JS? Absolutely. Is your code functional because it's written in JS??? Hell, nawwww. If you want to prove your FP chops by writing in something that's truly an FP language, take a look at Elm. (There are others, obviously. That's just the first one that pops into my head.)

A Cruel Taskmaster

I've also noticed that many of the FP fanboys, who blindly sing its praises, don't seem to fully appreciate what FP means. Or what kind of restrictions it would place on their code if they wanted to be truly FP-compliant.

Do you know what a "monad" is? I don't mean: Have you ever heard of that word before? I mean: Can you explain what a monad does? Can you write one in your own code?

I realize that there will be some people reading this post who fully understand monads. But I can guarantee that most other people - people who claim to love FP - cannot actually write a monad, or explain its purpose, to save their life.

Do you like loops? You know... for loops. while loops. forEach loops. Guess what?? In "basic" FP theory - they don't exist.

And while we're on the subject of "core FP principles", let's talk about side effects and immutability.

I've heard many FP acolytes talk lovingly about avoiding side effects and enforcing immutability. And then... I look at their code.

You see, I'm all for the theory of minimizing side effects and pursuing immutability. But when you start writing your app - your real world app - you might find these concepts a bit more difficult to adhere to. These concepts sound grand - in theory - but when you're writing, you know... real apps that people will use, it's pretty damn difficult to religiously adhere to these concepts.

React Hypocrisy

If I sound a little riled-up about this whole "functional programming issue", maybe that's because I'm a React developer. Over the last several years, I've watched as a virtual horde of FP fanboys have overrun the entire infrastructure of React. They came in with their torches and their pitchforks. And they tried to yell down any other React/JS dev who dared to question their holy FP purity.

And then... they gave us components like this:

export const MyComponent = () => {
  const [mySideEffect, updateSideEffect] = useState('love me some FP');

  const callTheFrigginGLOBALStore = () => {
    // let's make some SIDE EFFECTS!!!
  }

  const callTheAPI = () => {
    // LOOK!!!  MORE side effects!  YIPPEE!!!
  }

  return <div>Do some display here...</div>;
}

To be absolutely clear, I write components like this. I have no real problem with code like this. My only "problem" is that the FP fanboys will look at the code above and begin pleasuring themselves over their amazing Functional Programming skills. And they feel compelled to do this because... everything is, technically-speaking, in a function.

Yay???

I'm not exaggerating when I say that some React FP-fanboys truly have no self-awareness about code like this. If I were to put equivalent code into a class (egads!!!), they'd happily yell me down for using those horrible, unconscionable OOP constructs. But they can write code exactly like this, which is (technically), entirely encapsulated in functions, and they'll strain an oblique trying to pat themselves on the back over their beautiful "FP" code.

Own Your Dogma

So what's the point of all this???

I'm not trying to destroy your dreams of Functional Programming bliss. Hell... I share many of those dreams.

I'm not trying to hold you to any puritanical standard of what is-or-is-not "FP compliant". Show me a 100% fully-FP-compliant app, and I'll show you an app that's probably never been deployed anywhere.

I'm just encouraging you, me, all of us, to own our own dogma. Understand that OOP is not The Great Satan. FP is not Our Lord And Savior. Plain ol' imperative code is - a thing. In fact... there is no single programming paradigm that can, by itself, solve all of our challenges.

Resist dogma. Resist mythology and mindless koans. Think for your damn self. Whether you're right-or-wrong - in the end, you'll sleep much better at night.