I like reduce if the reduction function is super simple, but the common cases usually already have their own specialized functions (sum, max, average, etc) so I rarely need reduce itself. The only times I can think of are concatenating a stream of strings in Java, and bitwise-or-ing a bit array into an integer bitset in JS.
Anything more complicated and I reach for a loop. Especially if the aggregated value is itself some kind of collection.
Reduce is harder to read. Maps and filters are deeply simple. The problem space a reduce can solve is, I’m pretty sure, strictly larger than both of them. Its generality is its downfall.
I’ll happily use a reduce, but it has to be either as a well named function or immediately stored in a well named variable. If the reduce is complex enough that you can’t name it, that’s a smell to me, reach for a different tool.
Absolutely. I’ve used many reduces that I later regretted. It’s powerful, but also too cryptic.
And reduce has hidden performance risks. I’ve seen reduce used where the collector was assembled with a spread operator. But that’s a loop within a loop, and can get very expensive. A simple forEach loop and just appending the new value in old fashioned ugly pedestrian imperative code, does not carry that risk.
I like the concept of reduce and in many cases a different implementation is not necessarily more readable. But I hate how I have to look up the syntax every time, in every language I’ve written. I don’t know if that’s a me problem though.
I don’t hate it, but I prefer not to use it mostly for readability
With explanations like this, who can blame them 😁
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reduce
thats perfectly readable to me
Yeah, it sounds really abstract until you see that summation example. Then it’s suddenly really obvious…
Isn’t reduce just aggregation operations such as count, sum, etc? What’s even the alternative there if someone disliked doing aggregation for some reason? What if I anecdotally disliked subtraction?
It’s aggregation in general. It’s the iterator function you can use to implement sum, or count, or both at the same time.
This post is just saying that’s interesting that people dislike is more than say map or filter
If u don’t like subtraction you can add after multiplying by -1
The alternative most people probably use is iterative loops, like for loops and while loops and the like, with a mutable variable somewhere. I don’t love it, personally.
I guess the other potential alternative is doing the iteration recursively, but I doubt that’s what most people think of as an alternative to reduce.
Clojure masterrace
Found my brave and true friend.
I’ve used reduce a decent bit to write som expressions in pyspark without being as verbose so I must say I definitely don’t hate it
I don’t think it’s really less elegant in Python or Swift. Especially not in Swift where you can write it very concisely in some cases, like numbers.reduce(0, +). Admittedly Python is a bit more verbose.
But maybe Python and Swift programmers are not used to it in the same way as Clojure programmers are.
also python has built-ins for sum, min, max, and math.prod - which account for a lot of use cases of reduce in a more readable way.
But if you’re really crunching numbers, it’s just better to go with something like numpy, pandas, polars, …
I like it ¯\_(ツ)_/¯
I cannot recall needing Reduce while writing in GDscript (imperative language for the Godot game engine). I find use for Filter and Any easily, and use Map when trying to write functional code. I assume using Map is harder to read for fellow Godot users, so Reduce is probably a total unknown - it’s not the normal way to code in that enviroment.
