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...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I think the awful part of the Rise of FP is how it keeps happening over and over again right now. My professional worklife has lasted only seven years, but I'm experiencing a second wave of it. It first happened with CoffeeScript: if you found someone using CS it was very likely they were also very "fond" of FP, and had a very bad attitude towards everything else.
These days we have TypeScript. It is better and more usable tool than CoffeeScript ever was (you can actually read what you wrote the last time!), but somehow it seems to have a link to this same kind of fondness to FP. It is a bit odd as there is nothing FP about TypeScript, but I guess it goes with how people want to use new things.
The thing about React's hooks is that you can clearly see it being helpful and easier to reason about than the old classes. With classes you didn't have as clear path managing state and you just had to know what to do in
constructor,componentDidUpdateandcomponentWillUnmount. It might be an interesting exercise to try and make a custom wrapper over the class logic that would let you make something similar to hooks; not exactly like hooks, instead just make it prettier and easier to reason about state.Now that was a side step. What I was thinking originally... ah yes, hooks. I guess that pattern made more people aware of FP and thus caused a new additional spike to it, and here we are with another wave of newly found FP enthusiasts that give more credit and value for it than it deserves. Especially if they're at the beginning of their programming career.
It is very troublesome when this happens to individuals who are loud speakers with strong opinions, and no ability to listen.
FWIW, I'll state again that I use Hooks. I write code just like the sample shown above. I have no problem with the general concept of Hooks. However, I do have a bit of annoyance over how I believe Hooks came to be.
The crowd that believes
FP === puttingYourCodeInFunctions && allCodeInsideFunctions === FPwas getting themselves in a tizzy over "standard" class-based components in React. On one hand, they sang the praises of "pure" functions and desired to get all of their React code into functions. On the other hand, there was much about React that you simply could not do inside a function declaration.So they "solved" this by creating Hooks. Now, all their code could be inside those beauteous functions. And they never had to write another one of those scary
classkeywords again. And they could feel content in the (misplaced) knowledge that they were now truly writing in an FP style.This. Sooooo much this!
This is really my entire point - about any mythology.
they click their heels three times while chanting the JS Buddhist Mantra: "There's no programming like Functional Programming."Such an emotional stance. You mad? Who cares how people Define things? Everybody's different, and I think that's what's great about JavaScript. It's flexible enough to be however you want to use it.
Nope. I'm a pretty-chill guy.
I don't care about how people define things. Define them however you want. I only care about how people interact with each other, after they've created their own, private, isolated, disconnected definition of things.
If you want to call the orange thing in your hand a banana, then... great! You do you, boo. But too many times, in tech, I've seen someone decide that the orange thing is now a "banana" - then proceed to use passive-aggressive techniques against anyone else on the team who doesn't also want to call it a banana.
Interesting, like many of your posts which I've enjoyed reading recently, thank you !
But what has that photo of those statues in a private South Korean garden got to do with this article ? It seems very provocative and likely to offend some people.
It was meant to invoke the idea of dogma as ideas that we (internally) bow down to. Maybe it wasn't a perfect connection... I don't claim to spend copious hours curating the images.
Maybe. There are several images in this post directly referencing religions and cultures. They could all cause someone offense, I suppose. I'm not inclined to change them at the moment. But I sincerely appreciate you pointing this out.
Perhaps you don't know the story behind these statues in which case you may care to read this article:
theguardian.com/world/2020/jul/29/...
Ahhhh. Interesting. I did not know the history of those statues.
Much obliged.
No worries, I only wanted to be helpful. Now you've changed the image, perhaps we can delete these comments since they are just a distraction from the main content ?
I don't think I can delete them. But I've hidden the thread - which I'm pretty sure hides it for everyone else as well.
Functional programming is about leveraging invariant relationships.
It is their invariance which gives benefits, since it means that there is no change in the system.
Which means that time must be modeled explicitly in a functional system.
Not to be confused with procedural abstraction, which leverages decoupling implementation and interface by using procedure calls.
This is yet another definition that I've heard for FP.
To be clear, I'm not saying that it's in any way "wrong". I'm just saying that FP tends to evoke a lot of different definitions from a lot of different people.
I think it's broadly misunderstood, and there is usually a conflation of 'functional programming' with a 'functional programming style'.
The functional programming style is generally procedural abstraction, with an aspiration to avoid side effects, but misses the fundamental qualities of functions.
But without understanding the fundamental qualities of functions, it's hard to know where and when it's appropriate, which leads to a general devolution into superstition and mythology. :)
Which is why I always bring it back to time -- it isn't time invariant, it isn't a function.
Once you understand this, everything else flows naturally from this fundamental property.
You have explained this extremely well. Excellent points - all of them.
Interesting writeup there Adam.
Where are you meeting all these people? LOL
I've never met people like that.
But I sense some creative histrionics.
It's true there are misconceptions about FP.
It's just that we use it to different degrees.
Though my username is "Functional Javascript", I use probably less than 5% of what is considered "pure" or the "mathematical" FP. (I'm a minimalist)
You could analysis mine—or anyone else's software systems—for those attributes, and find them. But I don't think in that way in order to build systems.
One could say I think in building blocks.
We're building waterways (functions) to maximize the flow of the water (data).
To me FP means two things...
(actually, those are kind of one thing ;-)
My goal isn't to be or aspire to be Functional.
It's to try to build systems as simply, fast, performant, robust, secure, readable and changeable as possible.
Everything in life we should split-test.
My "control" piece (or paradigm) is the functional approach to system building.
P.S.
Keep up the good work.
Let's all keep pondering.
Have I ever taken any creative license?? Sure. But also keep in mind two things: 1) I've been doing this now for almost a quarter century and I tend to be a bit restless in my jobs - so I'm not typically in one place more than a year or two. This means that I've met a lot of people. 2) When I talk, in general, about some of these people, I haven't met many of them in person. But that doesn't mean they don't exist. Some nights I spend hours watching/listening to programming presentations on YouTube. Or reading programming blogs. Or sifting through the new-feature debates in various open source communities. So while I haven't met all of these people in person, I'm very confident that there's a lot of dogma out there.
As for your general approach to FP, I think we're almost perfectly aligned. I'm genuinely a fan of FP concepts. And I keep striving to be a little more FP in my coding. But I don't get hung up on the theory.
Write small standalone (atomic, even) functions that "do one thing, and do it well". Minimize dependence upon global data or any data outside the function scope. Simplify application "flow". Craft features that can be independently tested. I could go on...
I truly believe that FP's greatest strengths lie not in the rigid application of dogma. It's more - as you put it - aspirational.
I think a good way for one to introspect on how they approach designing systems, is to reflect on what one does NOT use.
It helps answer the question, "How minimalist am I?"
Or, how "As simple as possible but no simpler" am I?
I created a list of "program constructs I do not use" here...
dev.to/functional_js/what-subset-o...
I agree that this a very interesting way to quantify one's approach. With almost any language, there are far more tools / keywords / packages / frameworks / etc. available to us than we would ever use (or ever want to use). The tools you purposely choose to avoid probably say a lot about your coding style and your priorities when crafting solutions.
On a technical level I disagree with some aspects of what you say. But on a more pedagogical/sociological level I am with you a 100%:
Own Your Dogma
(and overcome it eventually)
Loving it!
Thank you for the feedback!
And yeah... on a technical level, there's certainly some detail in this post to quibble over. But then again - that would kinda be missing the point. :-)
I'm not there yet, beyond dogma :D
I thought the Javascript mantra was
this.method = this.method.bind(this);I mean, it's even got restraint and self-flagellation
Just plain brilliant!
What do you think about wrapping the component with an HOC that does all the side effects so that the component remains a pure function?
I'm not honestly certain whether your comment is sincere or sarcastic. But I think the question evokes some interesting questions for FP methodology so I'll try to answer it sincerely. (And if your comment was sarcastic, then, well... you got me.)
As I tried to make clear in my article, I'm actually an ever-increasing fan of functional programming. And I think there's a ton value to be had in learning it and striving to make your code more FP-compliant (even if JS is NOT inherently a "functional programming language").
So from that perspective, there's absolutely some value to be had in creating those HOCs that wrap all of those nasty side effects and, in turn, leverage the pure functions. My "official" response to that approach is... do it - until it's annoying to do it.
You see, it's all fine-and-good to strive for pure functions. And, in general, I encourage the thought process that leads you to look at every function and think, "But... how can I make this pure???" But there are limits...
This is probably a subject for a separate blog, but if you've been programming for long enough, you might understand what I mean by "limits". When you start trying to think in FP terms, you will probably find that that there are some - or even, many - of your functions that can easily-and-swiftly be converted into pure functions. (In React, another way to think of these functions is as controlled components.) But there's probably a batch of other components that are not so easily converted.
I can tell you from experience that, when you start going down a theoretical rabbit hole (like: the "rabbit hole" of pure functions), it's extremely easy to follow that rabbit hole too damn far. In other words, there are some functions that, due to their very nature, are just damn-near-impossible to convert into pure functions.
When you find such functions, you often need to decide whether you want to A. redesign the whole damn app (which is almost never a good idea), or B. accept the fact that "purity" is a question for theorists - and, at some point, you still need to deliver working code on a manageable deadline.
A good, anecdotal example of this is: any function/component that uses session values. In theory, any function that leverages session values is, by definition, impure. In practice, even if you worship at the altar of pure functions, there are just some times when session values are absolutely positively necessary. So if you're writing the Holy Grail of FP, and you find yourself needing a session value, how do you handle it???
One answer may be to create HOCs. And that might be a viable solution. But I would ask you this: Does your HOC just split into two what might have previously been a simple, concise component?? Even if that "simple, concise" component would've originally leveraged session values (thus, making it "impure"), you may not have solved any problem by chopping it into a (impure) HOC and a (pure) component.
So in conclusion, all I'm trying to say is that your proposal might be a solid approach. But if you are breaking apart all of your "impure" components into HOC and "pure" components, you may find that you're just creating more work for yourself - all for the sake checking off some theoretical box that claims you write pure functions.
Question was indeed sincere.