What s wrong with Array.reduce ?

Nothing. Most people are more familiar with imperativ or object orientated programming, so so functional programming practices are unfamiliar. Unfortunately for some developers unfamiliar automatically means it's wrong.

Reduce is fine in my view. A little bit tricky, but you can solve many problems. Main meanings: const result = something.reduce(reduceProcess, startingValue).

for example pipe function:

export const pipe = (inner, ...outers) => outers.reduce((result, calc) => calc(result), inner);

There is nothing wrong with reduce, it's only sin is to be slightly more difficult to understand than a for loop. The arguments against reduce can be reduced to this phrase.

I can do this with a for loop.

That's it. Anything that you can do with reduce you can do with a for loop, but since the for loop is the "simpler more readable" choice then it must be the right one.

This isn't a very good use of reduce, in my opinion, in any case.

In almost every case where you have an inlined reduction function, you're better off using a for loop, because it is less complicated.

const valid = [];
const invalid = [];
for (const record of records) {
  if (isValid(record)) {
    valid.push(record);
  } else {
    invalid.push(record);
  }
}

Simple, stupid, and gets the job done.

Your use of reduce just adds extra rubbish in the way, and is really a kind of abuse of a reducer in any case -- you're destructively updating it in-place -- so why not just do that in a more obvious fashion?

However, had you defined a reusable reducer, would have been a bit different.

const categorized = records.reduce(toValidAndInvalid);  

Now it's starting to look much more reasonable.

And let's get over this "in a functional way" nonsense.

array.reduce isn't functional -- it's just an application of procedural abstraction, there's nothing functional about it.

At best you can say that it's procedural code being used in a 'functional style', except that, really you can't say that, because you're not using it in a functional style.

So it's a bit like building a run-way in the jungle in hope that presents will magically drop out of the sky. :)

I haven't used array.reduce enough to really have an informed opinion on that specifically. In my job I don't write core code, I merely maintain and review it after the engineers move on. 90% of the code I read isn't my own and in order to be cost effective I have to be able to read and understand what was written.

When I worked in video games, I can also remember a number of times where an engineer would leave and we'd have meetings pulling various engineers in to decipher some random piece of code. The succession plan of your code is greatly improved if it's simple and readable. I imagine Open Source products benefit in the same fashion.

From that perspective, it might not be just preference that influences the decision but a business decision to favor code that is simple and readable over complex and/or elegant.

The way I see it, it's mostly familiarity bias. reduce will be harder to understand to someone who is not used to it and, well, since anything that can be done with reduce can be done with a for loop, why learn a new construct?

Also, regarding your example, I think a better functional primitive to use here would be partition. Unfortunately, Javascript doesn't have partition out of the box, but it's a function that takes a predicate and a list and returns a list with all the elements for which the predicate evaluates to true and another with all the elements for which the predicate evaluates to false.

The implementation is straightforward with reduce:

const partition = (pred, xs) =>
  xs.reduce(([ t, f ], x) =>
    pred(x)
      ? [ t.concat(x), f ]
      : [ t, f.concat(x) ],
    [[], []]
  )

Or you can take it for instance from ramda.

And then your analyzeResults is just a one liner:

module.exports.analyzeResults = (records = []) =>
  partition(isValid, records)

This is to show that, while reduce is super useful, there are still a lot of functional primitives missing in Javascript, which forces people to use less elegant solutions, and might contribute to the perception of reduce being hard to read.

I agree your example is one where reduce is better expressed in other ways. But I think there's cases where reduce is the correct metaphor and the clearest construction:

const max = (numbers) => numbers.reduce((max, number) => number > max ? number : max);

I will never be convinced that a for loop is more readable than that (and map and filter aren't options for this type of computation)

This seems like a very personal choice. I personally am a fan of reduce as it forces me to identity what I'll be "managing" over the loop. I also don't usually use many of the for loop alternatives, even though they are essentially just as capable.

A perk of JS is its flexibility, so there are multiple ways to do the same thing. As a side-effect, people will always have opinions on which is the right way.

If you like reduce, keep using reduce. If someone else hates reduce that isn't on your project, don't worry about it. If they are on your project, then decide the best way forward together :)

I don't think reduce is bad, it's just the way some use it to make it more complicated than it should be. Those same things can be done easily with a for loop and with the inclusion of the for ... of loop, it becomes quite easy to perform those operations.
Jake actually has a video for the same and you can see that how simple use cases are over engineered with reduce.
I also agree with the point that reduce has its parameters reversed, the callback should always be last, but that's a personal opinion.

The JavaScript community continues to follow the trend of syntactical additions being requested, added, praised, and then criticized because of unreadability and mental overhead. If you want to use reduce because it fits your context and provides clarity, then use it. The problem is that too many people misunderstand why the convention was initially introduced — not to provide a "swiss-army knife" replacement for for loops, but to alleviate complexity and provide more purity when writing functional code.