DEV Community


Discussion on: Functors and Monads in Javascript

blnkspace profile image
Aviral Kulshreshtha

I'm not sure if that's a blanket perspective I can buy! Yes some of my variable names look like
makeSelectCheckoutStateWithTotals or isElementInViewportAndSticky but how is that bad if you ignore someone's personal preference or dogma or a habit of using short variable names.

Large apps have too much going on for one person to know or remember everything. Expressive variable names work as documentation. Also, to "age" means to grow older, but I would rely less on grammar and name it something like incrementAge.

About performance, it's valid if you write your code in a poor fashion where your compositions are just obfuscating everything for no reason. But if everything is safely composed and is type safe, I don't see any difference in a failure happening by composing something this way vs. a failure happening in the case where things are not composed. I have never been in a situation where chaining (through composition) has rendered me unable to debug a failure when one of my composed functions fails. It's in fact been easier to figure out what's wrong and fix it in my experience.

This post is a trivial example to help learn, but such compositional patterns in real software aren't used to add numbers to ages, but to isolate a lot of curried logic into its own separate bit of code. Which au contraire, makes your code more testable and less prone to failure. If something fails, you know exactly what failed instead of having to spend time figuring that out. Human error is bound to happen in any way you choose to program, but a functional approach makes it easier to pin point what's wrong due to granular separation of concerns.

Moreover, if your code is made with Justs and Nothings, the whole chain will short-circuit and none of the next functions will be called if any return a Nothing, so I really don't see any of your concerns as valid if they're coded by someone who have really embraced functional code and know what they're doing.

Only thing I'd change is using a function like 'pipe' or 'compose' to pass all these chained operators to. I'm not a big fan of .this().that().something() it's ugly in my eyes.

I use patterns like this for making web applications that thousands of people use every day, and these patterns aren't something that need to be applied to "scientific applications" only. You might wanna try Ramda on a small side-project or test app to experience it in real-world usage and see if your mind changes.

akashkava profile image
Akash Kava

I tried Ramda and I don't see the benefit of writing code differently, words like thousands of people are doing it doesn't mean everyone else should do it.

I am not saying it is bad, and again scientific applications was an example, not an absolute statement, you have to evaluate what is best in terms of maintainability, availability of talent and tooling, and whether application really requires functional stuff or not.

This is the biggest problem with developers today, to make things appear cool, they want to do it things differently and I fail to realize the point from business perspective.

Thread Thread
blnkspace profile image
Aviral Kulshreshtha

I'm not doing it because thousands are though, I'm doing it simply for how easy it makes development, and how lesser prone to spaghetti I am.

I don't really know much about a business perspective beyond what I'm programming to be understood and worked on by everyone else independent of me. And while training new people on my project I've found them to appreciate little things like how you can log the output of every link in the chain to literally "time travel" through how your data transducing / logic is happening per step. If code in maintainable and people understand it, that's all that one really needs. Availability of talent is valid, tooling idk. But this is just in my case with the people around me, there could be cases where this paradigm is proving useless, mine isn't such.
But I'll say It's presumptuous and unnerving for you to say that everyone appreciates something they're doing because it's "cool". There's 200 other ways to have discourse about what you appreciate and what you do not that doesn't involve personal and presumptuous remarks!

Forem Open with the Forem app