[albedoa]

> The fact that you single out .reduce() here is really telling to me. .reduce() definitely has a learning curve to it, but once you're used to it the resulting code is generally much simpler and the immutability of it is much less error-prone. I personally expect JS devs to be on the far side of that learning curve, but there's always a debate about what it's reasonable to expect.

Not only that, but the words that GP uses to single out .reduce() start with:

> I see so much convoluted code with arr.reduce() or many chained arr.map().filter().filter().map()

Which I do not doubt, but the point is diminished when one understands that a mapping of a filtering of a filtering of a mapping is itself a convoluted reduction. Just say that you prefer to read for-statements.

[madeofpalk]

I say convoluted. I prefer using the functional-style array methods, but there's a time and place for everything, and I feel a lot of Javascript developers extend those methods beyond what is reasonable and into a convoluted mess, especially with reduce.

Give me a good classic `T[] => I` reduce function and I'm fine with it. Not the more common case of folks mutating the accumulator object.