> I see so much convoluted code with arr.reduce() or many chained arr.map().filter().filter().map(), that would just be so much simpler and easier to read if it was a classic for-loop.
It's interesting; when I'm writing JS in an actual .js file, I do tend to use for loops. But when I'm writing JS at the (CLI or browser-dev-console) REPL, I'll always reach for arr.map().filter().filter().map().
When you're at a REPL, with its single-line/statement, expression-oriented evaluation, it's always easier / more intuitive to "build up" an expression by taking the last expression from history, adding one more transformation, and then evaluating the result again to see what it looks like now. And you don't really want side-effects, because you want to be able to keep testing the same original line vis-a-vis those modifications without "corrupting" any of the variables it's referencing. So REPL coding leads naturally to building up expressions as sequences pure-FP transforms.
Whereas, when you're iteratively modifying and running a script, with everything getting re-evaluated from the start each time, it's not only more intuitive to assign intermediate results to variables, but also "free" to have side-effect-y code that updates those variables. It's that context where for loops become more natural.
I bet that a lot of the chained-expression JS code you see out there was originally built up at a REPL, and then pasted into a file, without then "rephrasing" it to be more readable/maintainable in the context of a code file.
...though there's also just FP programmers who write JS (or more often TS) as if it were a pure-FP language — either literally making every variable const / using Object.freeze / using Readonly<T>, or just writing all their code as if they had done that — where for loops become almost irrelevant, because they're only really for plain iteration (they're not list comprehensions), and plain iteration has few uses if you're not going to do anything that produces side-effects.
It's interesting; when I'm writing JS in an actual .js file, I do tend to use for loops. But when I'm writing JS at the (CLI or browser-dev-console) REPL, I'll always reach for arr.map().filter().filter().map().
When you're at a REPL, with its single-line/statement, expression-oriented evaluation, it's always easier / more intuitive to "build up" an expression by taking the last expression from history, adding one more transformation, and then evaluating the result again to see what it looks like now. And you don't really want side-effects, because you want to be able to keep testing the same original line vis-a-vis those modifications without "corrupting" any of the variables it's referencing. So REPL coding leads naturally to building up expressions as sequences pure-FP transforms.
Whereas, when you're iteratively modifying and running a script, with everything getting re-evaluated from the start each time, it's not only more intuitive to assign intermediate results to variables, but also "free" to have side-effect-y code that updates those variables. It's that context where for loops become more natural.
I bet that a lot of the chained-expression JS code you see out there was originally built up at a REPL, and then pasted into a file, without then "rephrasing" it to be more readable/maintainable in the context of a code file.
...though there's also just FP programmers who write JS (or more often TS) as if it were a pure-FP language — either literally making every variable const / using Object.freeze / using Readonly<T>, or just writing all their code as if they had done that — where for loops become almost irrelevant, because they're only really for plain iteration (they're not list comprehensions), and plain iteration has few uses if you're not going to do anything that produces side-effects.