JavaScript's Functional Programming Mythology
Tags: javascript, functional, codequality, programming
Published: 2020-07-29 03:17:10

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."
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3hbcatlsyjxmgnf4qncb.jpg)
## 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".<br/>

1. There's often disagreement about what the mythos _actually_ means.<br/>

1. 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).<br/>

1. 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.<br/>

1. 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.<br/>

1. 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.<br/>

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??
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/cfr52qbngwmvvf70l158.jpeg)
## 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...
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/s8xl58exbs08642725f9.jpg)
## 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.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/45hxqgen9jc9702b3f30.jpg)
## 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).<br/><br/>

> All of my code is now _in functions_.  Because I love Functional Programming!  And this makes my code "FP"!

<br/>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.<br/><br/>

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

<br/>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.<br/><br/>

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

<br/>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_):<br/><br/>

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

<br/>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.
1. A `Function` is... an object.
1. `NULL` is... an object.  (Yeah.  I know.  Wrap your head around that one for a minute.)
1. A `Set` is... an object.
1. Most of the "standard functions" we're accustomed to using in JS are part of... the global _object_.
1. 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.)
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6p5z2lazwthdeo26ch5o.jpg)
## 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. 
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/32yo2kdqzjtuj5mai3t1.jpg)
## 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:

```javascript
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_.<br/><br/>

> _Yay???_

<br/>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. 
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/4e55qecg7y6zc0l4izwu.jpg)
## 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.