Anecdotally, programmers dislike "reduce"

At least in Python, I've found that "reduce" is very rarely needed. Most of the times, "sum" is enough, sometimes with "start" values customized (set it to [] to flatten an array for example). It is both easier to read, faster, and needs no imports. It also works great with list comprehensions - "sum(foo(x) for x in input if x > 5)" is much easier to read than reduce equivalent.

If you are multiplying, you are likely doing heavy math, and you'll be using numpy - which does not need reduce either.

If you are going to return a list of dict, then it's much faster to mutate the results, so using "reduce" will have significant performance implications (unless you want to return input argument, mis-using it as a glorified "for" loop)

And if returning not a list/dict, if you can use "min" or "max" or "any" or "all" or "next" (take the first element), then you should use it - it will be easier to read and faster too.

So what does this leave us for "reduce"? Frankly, not much. I've only seen it in merging immutable status codes, and that was pretty niche usecase to begin with.

(this was all for Python. In other languages without nice list of built-ins reduce might make more sense)

Well yeah, it's the lowest-level array function. All of the others can be written with reduce, but not vice-versa. Of course it's going to be less friendly.

Reduce requires knowing that the sum of zero entities is zero but the multiply of zero entities is one. They forget to throw the correct number and think that reduce() just do not work for them.

reduce with barriers is essential in parallel functional programming. See the CUDA thrust package.

I've always like reduce myself, didn't realize others had a negative attitude towards it.

Reduce always makes me question the performance and order of operations. The most I'll do in Python is like

  sum(x[1] for x in args)

This is also assuming we're talking about regular code and not an actual map-reduce framework like Spark.

I like neither of the three and prefer for loops and if statements instead. Yay for shallower stacks!

Alternative theory - reduce is badly named.

combine, accumulate it aggregate would have way more use.

I like it, but don't care for the name. I find it easier to think about in terms of an accumulator.

[dead]

[dead]

you guys still reading and review code with ur eyes and brain?