DEV Community

Discussion on: What Subset Of The Language Do You Not Use?

Collapse
 
johnkazer profile image
John Kazer

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?

Collapse
 
functional_js profile image
Functional Javascript

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

Collapse
 
johnkazer profile image
John Kazer

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.

Thread Thread
 
functional_js profile image
Functional Javascript • Edited

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.

Thread Thread
 
johnkazer profile image
John Kazer

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.