Discussion on: What s wrong with Array.reduce ?

I didn't mean "businesses don't care" to be a sweeping statement, but again, it comes down to the audience.

When you're bringing it into the arena of empowerment, it's almost an entirely different discussion. A lead developer or senior dev or engineering manager typically help bridge the gap between product managers/stake-holders which I perceive to be "the business". To me, that's divorced from the implementation as stakeholders at companies that I've been at have no say and won't even be able to read code. Even if you take Sundar Pichai and ask him, unless he's worked in a language, he's probably not going to have a valuable opinion on how some deliverable should be implemented.

When we're talking about style guides, these are created and consumed by developers and if you're in the business of building for developers (I currently work on APIs for devs), it is important that everyone is on the same page about these sorts of things. As someone that also contributes to documentation, I'd probably share both examples and let the end-consumer decide which is best in their case, but in the source code of the library, follow the established or agreed-upon style guide (if any) internally.

And you're totally right in your last paragraph -- I think this entire discussion started on the premise that our code is intended to be read by others and why reduce may be bad. But like any tool, it's just a tool and they can be used well or poorly. Someone stuffing a massive reducer as the callback to Array.prototype.reduce is a code smell, but so is stuffing that same conditional logic within the body of a for-loop. And if there are multiple declarations an initialization of collection objects (arrays, objects, sets, map) that the for-loop will be mutating scattered about on different lines, it's going to be very difficult to keep track and who knows if between those lines some other code is mutating it before it reaches the for-loop. Reduce keeps things atomic. There are a segment of folks that will tell you that the readability trade-off for atomicity is HUGE, because debugging won't be an issue with reduce as you're sure that mutations happen in ONE place. The easy thing to do doesn't always yield the desired result. The one thing that is constant in software is change -- the more churn and change that happens to such code will inevitably result in a regression that becomes hard to track down, fix, and/or refactor. Look no further than scripts. Scripts are ad-hoc and implicitly coupled to the very specific use case the author had in mind, but are not maintainable by a team of people. This is why patterns exist and abstractions and sometimes it is good to force the wider audience to learn and adapt to them if there is merit and that merit being less pain later on. It's not to "be smart". Those that are deeply down the functional paradigm can be assholes but unfortunately what they spout is too far to bridge the gap between what most people are used to and what they've come to realize (useful and arguably better). But I think core functional facilities like reduce strike a good balance and it's best that people are familiar with when and why to reach for it and also not be taken aback when it is used. Lastly, they should also call out when it is abused -- stuffing a massive callback/reducer. Just rip it out and give that a name and unit-test the reducer in isolation. It's not reduce's fault that someone decided to write an anonymous/lambda/callback that is untenable and unreadable. People are arguing about the wrong things here...

// this should be tested in isolation
function sum(total, num) { return total + num; }

// read as: "reduce to a sum"
let numbers = [1,2,3,4,5];
numbers.reduce(sum);