As functional-programming-centric engineer myself, I don't use these particular constructs listed below.
I use a subset of the language to achieve all the goals that need to get accomplished, as performantly, robust, readable, and changeable as possible.
For example, in JavaScript, ideally, I do not use...
prototype
IIFE (Immediately Invoked Function Expressions)
bind
call
"this" keyword
"function" keyword
"class" keyword
"extends" keyword (inheritance)
interface classes
abstract classes
getters and setters
overloading
overriding
virtual methods
optional parameters
asynchronous callbacks
let (unless it's a value type that I will explicitly reassign)
implicit casts
implicit type checks
implicit null/undefined checks
single quotes
"require" keyword
polymorphic functions
recursion
generators (function*)
symbols (private keys)
Top comments (10)
It's interesting as recursion is the base concept of FP. Everything in FP is based on recursion. If you take list and any operation on list its pure recursion as you operate on head and you call itself on tail. This is also represented in Haskell by
x:xsThanks for your input Maciej.
For one thing, we're talking about Javascript; so we'll keep the criteria analysis narrowed to that.
And we're talking recursion where a function calls itself within itself, where each call adds another frame onto the stack, which is extremely non-robust and less performant than a loop.
If another language has a way to protect its stack, that's a benefit; but the JavaScript compiler doesn't. The stack will explode once exhausted "
RangeError: Maximum call stack size exceeded". Thus it fails the robustness test. (If you know a way to make JS optimize for tail-call recursion let me know and I'll test it out.)Also, when one is designing systems, one should not think in terms of "should I use recursion or some other implementation". One should think in terms of, "what are the candidate solutions, and which is the most performant while being the most robust". On that criteria set, recursion loses every time in every case I've seen. In a case where it would win out on the criteria set over other candidate solutions, then it would be apropos to use it.
Also, something that is not in the criteria set for choosing best solutions is thinking that one is "supposed" to use it, or "it's how everyone else is doing it", or "it's considered a best practice by somebody somewhere", or "you're not doing X paradigm if you're not doing Y pattern".
I describe the criteria set analysis here. (If you have ideas to add to it let me know)...
dev.to/functional_js/squeezing-out...
So to sum up, I'm not against recursion. I'm against code that is less performant and less robust.
Nice list. I also favor functional programming, so I notice a lot of overlap with your lists, and some differences :)
In Javascript I try to avoid:
I do sometimes use:
Bit surprised by recursion on the list. Especially after I tried hard to learn how to actually use it! What's the alternative you use?
That's a good question John, and I have a draft article saved that I haven't published yet on the pros and cons of recursion, and why they are non-robust. I'll try to publish it this week.
For now, have a look at this post of how to evaluate what code to use for production...
dev.to/functional_js/squeezing-out...
Also have a look at this analysis of the recursion vs iteration idiom...
dev.to/functional_js/comment/13bam
Most reading I've done suggested recursion is more robust because there are fewer variables and less chance of impure functions. Be interested in your views on that.
I guess JavaScript isn't ideal language for recursion on large datasets due to lack of support for tail call optimisation but this isn't something I know lots about!
I do like the mix of while loop and recursive function calls. Although not sure in practice if is logically different from recursive base case.
Thanks for your feedback John.
"Suggested" is not in my criteria set. ;)
I have no idea how an iterative approach lends to making code "impure". If you have an example of that let me know.
Actually to me, iterative is way more readable, and way more debuggable. And it's certainly faster and certainly more robust according to the metrics output by the tests.
At the end of the day the tests make the decision, not me.
The most performant and robust is what gets deployed.
If a recursive variant won out in the testing, I would deploy it.
I guess the worry with iterators (used by for loops and such) is the potential for receiving or setting them outside the function. Just less self contained.
But at the end of the day is all about preference. I just like the way a functional approach let's me think about, and directly represent in code, the logical structure of what I'm trying to achieve.
Mixing paradigms, if that's the right phrase, means thinking in different ways and so perhaps less clearly.
Definitely agree that when performance matters pick the fastest approach.
why not use "single quotes"?
Super !