Map and filter usually have only one arg and if they have 2, the 2nd is almost always a 0-based index. They look identical in most languages, even when Microsoft chooses to call them Select and Where.
Reduce has an accumulator and a 2-arg function and languages are not very consistent amongst each other as to whether it's reduce(initial_acc, callback(acc, elem)) or reduce(callback(acc, elem), initial_acc) or reduce(callback(elem, acc), initial_acc) or what.
Hard to remember. Also some languages have a version of reduce that doesn't take an initial accumulator at all, which is just a footgun waiting for you to hit an empty collection. Also ALSO, the accumulator can easily become awkward in languages that don't support anonymous types or don't support easy mutation of an anonymous type record. Which is most of them!
By rspeele 2 days ago
In GNU Guile `reduce` is described as a special case of `fold`, where the first element is suitable to be used as initial value, while `fold` is more general and lets you specify another initial value. I think that makes a lot of sense.
By zelphirkalt 3 hours ago
> … to call them Select and Where.
While map is a great name, I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them.
I mean, it’s like a colander: you filter noodles and water, but which one do you keep? The noodles, right? But, replace noodles with tea and now you want to keep the water part.
Naming is hard I guess.
By jiehong 3 hours ago
Talking about un-guessable, misleading function names,
C++ std::remove.
I would never have guessed what it does exactly. (It moves elements that match the filter to the front, and moves the end-marker forward. Leaves all the elements in the collection. You need to erase them yourself. )
By reddit_clone 2 hours ago
Oh it's a bit like unordered-delete when using an arena. I guess I would have expected an ordered-delete instead
By anitil an hour ago
It returns the new end marker
By mitxela an hour ago
I've never run into a generic "filter" function which keeps only the non-matching elements.
By seanw444 3 hours ago
Smalltalk has #reject: which does that. You could, of course, just wrap a not around the test in the closure, but sometimes reject with a well-named predicate is easier to read.
Common Lisp's filter is remove-if which works this way.
(It also has remove-if-not but that's deprecated and if you use it your code smells.)
By dreamcompiler 7 minutes ago
> I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them
if you had parameter names maybe it might help?
`filter(where:)` like in swift...?
By andrekandre 2 hours ago
Doesn't seem to help the ambiguity to me.
By mikebenfield 2 hours ago
If you're making tea with a colander something is very wrong ;)
By dcminter 3 hours ago
depends on the size of the sieve, but sometimes one does cook a whole stewpot of tea at once (f.e. in canteen)
By NooneAtAll3 2 hours ago
Maybe those two could be filter_for (the “where” case) and filter_out.
By pavlov 3 hours ago
select/reject (Ruby)
By quaverquaver an hour ago
An IDE can fix that
By mitxela an hour ago
Meh, if you need a computer program to understand an API its a bad api.
APIs should make sense inherently. An IDE can band-aid a bad design, but that doesn't make it a good design.
By bawolff an hour ago
There are lots of APIs where the order of argument isn't obvious, it doesn't mean they're bad designs
By atherton94027 an hour ago
For me it's the name[0]. map puts out an array that has been mapped from another array. filter puts out an array that is a filter of the input array. both of those are always true. reduce, on the other hand, may put out a reduction of the input array (probably most of the time), but the fact that it may not means that what is happening is not actually a reduction. In languages like js/ts, you don't even have to return anything of the same type as the input array's elements. You could literally "reduce" and array of integers to a cancellation token, or a state object, or anything else.
I realize it's not the most efficient way to work, but I like my code to read like instructions. There's nothing reduce will do that a for loop won't accomplish and the for loop (+ an accumulator, of course) is more clearly "readable" than reduce. If I read map, I know what's going on. If I read filter, I know what's going on. If I read reduce, I have to figure out what's going on, even if I'm pretty sure what is going on. If I could rely on reduce to always give me back an element of the input array, I would use it more. But since it can give back anything, I prefer the simplicity of a for loop.
[0] I don't have any suggestions for "better" names because the whole operation is hard to sum up in a word? "dispatch" makes sense, as a function dispatching a function over each element in an array, but it masks the concept of accumulation from return values. "transform" is accurate, but hardly descriptive at all. the list goes on. It's an undeniably useful little function, it's just hard to make it easy to understand and therefore debug.
By catapart 3 hours ago
Ruby adds an alias `inject` for reduce. The #1 way I see it used there is like this:
But I honestly very rarely use it (by either name) outside of a couple of pasted-in snippets (that I can't recall right now) where the strategy fits exceptionally well, probably because of the dumb reason that I tend to forget which block argument comes first (accumulator, or iterated item)! With other two-item argument lists such as `Hash#map` it being `key, value` makes sense, but with reduce/inject I don't see an obvious order. And I guess I learned before it was likely that some kind of AI autocomplete would be filling the args in for me.
By xp84 3 hours ago
The name inject and the argument order comes from Smalltalk (Ruby is heavily inspired by it). In Smalltalk arguments are part of the message name:
collection inject: aValue into: aBlock
By diegof79 2 hours ago
Ruby inject appears to be derived from Smalltalk #inject:into:
#(1 2 3 4 5 6 7) inject: 10 into: [ :sum :each | sum + each squared ].
The way I remember the order is it reflects the assignment you'd do is a while loop, sum := sum + each.
By jdougan 2 hours ago
I like the name `fold` as used by Haskell, Racket, et al. It gives me an image of folding up a long list into a ball, one chunk at a time.
By adamddev1 2 hours ago
I like fold too, but I can never remember foldl vs foldr, it's always backwards to what I expect somehow
By anitil an hour ago
There is a big difference in there I think.
'for' loop is mutating.
Using 'reduce', you can do the same functionally. In some (somewhat) purely functional languages, there is no choice.
By reddit_clone 2 hours ago
It doesn't have to be exactly correct. It just need to express intuitively the most common use(es?).
Aggregate, accumulate, combine for example.
By scotty79 3 hours ago
I’m so confused, how are you supposed to perform aggregation without reduce? This is like saying “I like plus and times, but I don’t like divide because it’s hard.” I mean sure, but you need it??
By remywang 8 minutes ago
Every single `reduce` can be replaced with a more intuitive `groupBy`, `partition`, `mapValues`, `keyBy`, etc.
Reduce can approximate anything, that doesn't mean we should use it.
Like, why? Not only is this ridiculously inefficient O(N^2), it's also longer and less understandable than "build a new map" version.
By RomanKornev 18 minutes ago
Ive only used reduce at work half a dozen times and it does raise an eyebrow each time.
But for unioning a bunch of spark dataframes together i think
df = reduce(DataFrame.union, list_of_dfs)
is much nicer than
df, *rest = list_of_dfs
for other in rest:
df = df.union(other)
People just get a bit funny, especially now you have to import it from functools
By el_oni 2 days ago
Speaking as someone who often tries to reduce my use of reduce by replacing it with map and filter where possible, for me, falling back to reduce is analogous to falling back to a while loop or a for loop: I avoid it if I can.
The problem with reduce is that it can do so much, and therefore it is less clear when reading it quickly what it might be doing.
By adverbly 4 hours ago
I remember finally getting what closures and reduce are when I learned Ruby in 2008 for my first Rails job.
A pivotal moment on the same level as when I finally understood how recursion and pointers work in 1995 in my first semester CS classes (taught in Modula 2), two concepts I had only ever read about in programming books, but not been able to understand on my own.
In 2024 I did Advent of Code in Swift, without using mutable state, custom data types or loops, and used reduce rahther generously. [1]
(JS/TS is my main language)
I love reduce()! It's a hammer/nail method for me. Everything looks like a problem solvable by reduce. (I'm often wrong on that, but I quite enjoy learning why by trying).
I really like taking the implementation away from the call site, so that the call site reads
const myNewValue = data.reduce(doSomethingMagic);
(and then `doSomethingMagic` is defined somewhere else). So simple.
I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop. Loops are easier, for sure, but they sprawl and are open to hacking. They can bring in state from outside the loop. They make the call site long (you always have to read the implementation to learn that you don't need to read it). The same interviewer actively liked to have loop bodies modify the loop conditions (e.g. by taking items out of the source array and decrementing the end condition, so the loop would end earlier). That's the kind of "clever" I find unpredictable and hard to think about. Probably a good thing he rejected me.
By the_other 3 hours ago
> Everything looks like a problem solvable by reduce. (I'm often wrong on that, but I quite enjoy learning why by trying).
I agree, but I think that’s kind of the objection. It can be tempting to write your code as little brainteasers but…
By kenferry 2 hours ago
> The same interviewer actively liked to have loop bodies modify the loop conditions (e.g. by taking items out of the source array and decrementing the end condition, so the loop would end earlier).
Wow. That is the kind of monkey business that would have me running for the exits. Yikes.
By xp84 3 hours ago
> I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop.
Honestly, sounds like the reviewer failed the interview, not the other way around.
By anyfoo 3 hours ago
Nah. Reduce is less performant and less readable than a regular loop. In my anecdotal experience, only people who want to appear smart and minimize the number of characters prefer reduce.
By baxuz 3 hours ago
I don't know about JavaScript, but those statements are definitely not universally true in other languages.
By anyfoo 2 hours ago
I think this is because in an imperative language, `reduce` does not actually give you much over a `for item in collection` loop. With `map` and `filter`, you immediately learn something about the result (it's a list of the same length as the original, with each item only depending on the corresponding original item; it's a list containing some of the original elements unchanged and nothing else). This is useful, so `map` and `filter` are good.
With `reduce`, the result could be anything, and in an imperative language, side effects are also possible. So it's just a loop with worse syntax.
(Admittedly, in an imperative language, `map` and `filter` could also have side effects, though I think most people would consider this bad style.)
By Skeime 3 days ago
I think what makes reduce less popular is that it takes two lambdas:
- a slightly awkward one that takes a partial result and the next value to produce a new partial result
- one that maps the final partial result to the result
Also, in many languages, when reading the code, you have to skip initialization of the partial result, read the lambda, and then jump back to make sense of the initial values
I think something like awk’s syntax, with BEGIN and END blocks would improve on that. Example of a first go at such syntax (needs work):
Items.BEGIN
min = ∞
max = -∞
sum = 0
n = 0
ITER
min = Min(min,_)
max = Max(max,_)
n += 1
sum += _
RETURN
average = sum / n
(min, max, average)
Advantages:
- items in the partial results have names, making them easier to understand
- result also is easier to understand
Price paid is wordiness, and you cannot simply write a function name for either of the lambdas.
However, I think the latter only is useful in case the partial result is the final result. There, you can keep
sum = items.reduce(0,+)
if you want to.
By Someone 3 days ago
I think that in every imperative language that offers `map`, `filter`, `reduce`, or similar, the written contract of this API should state that any higher-order function handed to it as an argument must be free from side effects.
I think I’ve seen several language core APIs have this in their contract, e.g. `Stream#reduce` in Java [0] (emphasis mine):
> accumulator - an *associative, non-interfering, stateless* function for combining two values
In Rust these specifically take `FnMut`, a function which can update internal/borrowed state, rather than `Fn` which can't easily. In `map` or `filter` you shouldn't rely on the iteration order so that's not often useful – maybe something 'logically' stateless but which needs a mutable connection/threadpool/cache, or eg a counter which is really an ancillary reduction. There's even `inspect` which is explicitly for such side effects. In `fold`, the order is guaranteed and you could use it for a state machine, a fiddly `zip` with other mutable iterators, etc – something you need to perform the reduction, but which isn't really an output, I think you could reasonably write either
I mean, most of the code that I write would be side-effect free anyway. In an imperative loop, this would also be true except for updating local variables. If this is the case, `reduce` really is the same as a loop over a collection, except that the names for the state passed between iterations come out better. In the `reduce` version, you can name the parameters to the reducer, but often not the return values. As a reader, one needs to connect the return values to the parameters by position.
(Note that by "loop over a collection", I explicitly mean a looping construct that gives the elements of the collection directly, instead of looping over indices and extracting the elements manually.)
By Skeime 3 days ago
Even though it makes print debugging harder, I think it would be better if the language enforced such a contract.
By Someone 3 days ago
It's simple really: looping is something we've all done a ton. Map is just a specialized version of something you do all the time, made better/simpler: what's not to like (and learn quickly)?
Reduces are used much, much less often. Most devs don't get familiar with them as a result, so every time they have to read a `reduce` they have to re-learn it. And of course, it's a much more involved/complex function, so that exacerbates it.
By hungryhobbit 4 hours ago
I came to like reduce when I learned clojure transducers. even in clojure, I always go for looping construct before transducer and then both reduce and transducer just clicked at the same time and I like reduce more now.
By keychera 38 minutes ago
I've seen a lot of technical points about reduce, all of which are true.
But I think the real reason might be even simpler: you can't tell what it does just from the name. What `map` does is consistent with well-known programming jargon. What `filter` does is consistent with the word's everyday meaning. But if you don't already know what `reduce` does, it's name isn't even enough to hazard an educated guess.
That's not true in Clojure because for lisp programmers for two reasons. First, `reduce` is a ubiquitous and well-known concept in lisp.
Second, in most lisps manually doing the same task with imperative code is an ugly verbose eyesore. But in algol-style languages, the imperative alternative is only 1-2 extra lines of very simple code, so using `reduce` is arguably just code golf.
By bunderbunder 3 hours ago
map() and reduce() are equivalent in terms of jargon, IMO. Map also suffers from name collision with dictionaries/objects/whatever your language wants to call a key-value pairing.
By OkayPhysicist 3 hours ago
I dislike reduce because people sometimes do wild things in the callback that take a lot of mental effort to understand.
Sometimes people abuse .map as well to do things that are not obvious (i.e. instead of mapping elements of an array to another array, they modify global variables in a for-loop fashion, and discard the result).
But reduce is abused more often and you always need to think really hard if e.g. the initial accumulator is passed or not (it's optional in some languages!), if a correct one is passed (when a compound type is used) and so on.
By jakub_g 3 hours ago
> sometimes do wild things in the callback that take a lot of mental effort to understand
And even when they don't, you have to spend effort to determine that they aren't.
By Terr_ 2 hours ago
IDK, in JS I love reduce and think it is invaluable. If you don't care about closures, never used underscore/lodash, and have not written several hundred var self = this; then you don't share my pain. IMO fat arrow const/let kids don't know about walking uphill to school both ways. Also I agree with commenters who use prev instead of acc, it is much easier on my brain to use prev.
TypeScript basically ruined reduce for me though, so there is that.
By felizuno 2 hours ago
In python: I've always thought it's funny that of the list functions (map, filter, reduce?), reduce is the one that was removed, but is the only one that I occasionally reach for. (When I remember it doesn't exist, I'm usually happy to write the more readable three-line for loop.)
The other two can be simply expressed as a list comprehension, but afaik you can't with reduce (and if you can, it's probably awful).
By kevinwang 2 hours ago
I like it, but it is by far the most ungainly of the three with the most footguns in it's usage.
Totally get it. `reduce` feels like a hammer for every nail; often `map` or `filter` makes intent clearer for others.
By grommet_kit 44 minutes ago
My favorite gotcha is Java's `Stream.reduce(accumulator)` doesn't call the accumulator if your stream has zero or one elements. This is used for `min(comparator)` and `max(comparator)`. It's very funny when the comparator throws, but only when you have 2 or more elements.
By tantalor an hour ago
I find `reduce` useful for operations where:
- arg1, arg2 and return value are all of the same type e.g `ADD`, `MAX`, `CONCAT` etc
- and there is an identity value e.g zero for `ADD`, -math.inf for `MAX`
I recommend checking this article[1] on how monoids play nicely with reduce.
reduce has complexity to handle the edge case of an empty iterable, and also for the case of a binary function with different types for inputs and outputs. That makes it harder to reason about and "uglier" than map and filter. People probably hate sum and product significantly less, both those also have the edge cases of empty iterable, in which case the natural result is 0 for sum and 1 for product sure, but of what type?
While we're on the subject, can someone explain to me why in Rust, you need to annotate the type when you call .sum() on an iterable? For example
let p: i32 = [1i32, 2, 3].iter().sum();
println!("hello {}", p);
That works, but fails if I replace `p: i32` with `p` or `p: i64`, and I cannot find a satisfactory answer in any thread or llm. The obvious question is why the compiler cannot infer the type from the element type of the container, and the naive response to that is for flexibility summing into a bigger type. But in that case, why would `p: i64` be rejected? And what other type is allowed besides i32?
By xdavidliu 2 hours ago
Yeah, it usually adds cognitive load for anything beyond basic summation. Simpler to just use a good old `for` loop.
By Bayard_ne an hour ago
Map maps a value into another value. It's a function call. Easy to understand.
Filter picks values according to a rule. It's a select from where condition. Maybe not as easy as map but familiar.
Reduce is, what? Even the name is ill fated. Who wants to be reduced? Hence, harder to understand and probably not as common as the other two.
By pmontra 2 hours ago
Reduce with barriers is essential (and amazingly powerful) in parallel functional programming languages like CUDA Thrust.
By very-old-sw an hour ago
Yea, reduce is most useful as a parallel operation, like in MapReduce
(Or, at minimum, when the reduction operation is commutative)
By odo1242 37 minutes ago
One of the books that most affected my understanding, ability, and joy of programming was Mark Jason Dominus' "Higher Order Perl."
So I love reduce, and have for many years.
By scelerat 4 hours ago
It would be clearer if the operation were part of the name. The most common operations have good names, like sum(), product(), concat(), and so on.
If there's no standard function for it, it's trivial to write a utility function.
And as part of writing the function, give it a good name and think a bit about the order of operations?
So I think reduce() is just unnecessarily generic, unless it's part of a more complicated system like running a map-reduce.
By skybrian 3 hours ago
I'm the weird one here. In JS at least, I reach for reduce before map and filter in most cases. Often it is because I want the accumulator, particularly when I have a list of objects with various properties that I wish to sum together in a reduced object.
By altruios 3 hours ago
I was going to write a question asking if reduce is the thing I know as accumulate (I think I picked this up from SICP). But then I went to wikipedia, and it seems that an even more common name is fold.
Here's a hypothesis: The fact that the same operation has half a dozen different names makes it sound like there is a lot to learn. If I am totally familiar with fold, and i come upon a reduce, I may need to think more about what's going on, which is distracting.
I don't think map and filter have so many synonyms? I know select for filter, but it seems to me less common.
By futune 3 days ago
And in some contexts you have the subtle distinction that fold is linear and reduce requires an associative operation and an identity element (aka a monoid)
By 3836293648 2 days ago
Reduce introduces state (accumulator), unlike map/filter which normally are used for immutability.
I use both, but do not like reduce at all. It's harder to read, yes.
But I see the point of using them all.
By yipinwong 3 hours ago
reduce with barriers is essential in parallel functional programming. See the CUDA thrust package.
By very-old-sw an hour ago
I agree, but I think a lot of it is variable name abuse on the accumulator, making it unclear.
I've seen a lot of single letter or worse, a coworker who named it "cum" for short which is super not okay
By olivewong 2 days ago
Sure, I'm up for some bike-shedding. [0][1] Unless performance demands otherwise, I prefer map+filter because:
1. It's cheaper/faster at communicating intent to humans reading your code. Since a reduce call can do all sorts of interesting things, people need to stare harder to realize "oh, it's just doing a a map and filter together."
2. Things are easier to debug. I can vet the process of transformation (and its intermediate results) and then vet the process of excluding some of those results.
_____
With respect to debugging, a sample form Elixir's REPL where the piping (|>) to the dbg() function reveals the intermediate state:
iex(1)> [5,34,6,2,7,3,1] |>
Enum.map(fn x -> x * x end) |>
Enum.filter(fn x -> x < 10 end) |>
dbg()
[iex:4: (file)]
[5, 34, 6, 2, 7, 3, 1] #=> [5, 34, 6, 2, 7, 3, 1]
|> Enum.map(fn x -> x * x end) #=> [25, 1156, 36, 4, 49, 9, 1]
|> Enum.filter(fn x -> x < 10 end) #=> [4, 9, 1]
In my experience, it depends a lot on the language and the folks you work with. I’ve gotten an eyebrow and a stern talking to for using ‘map’ in JavaScript once. Some people are die-hard about statements and keywords and imperative programming and their world view and be myopic.
“We can’t have map in our codebase, we need to be able to hire anyone off the street and have them comfortable in our codebase.”
Well… since when did we hire random people off the street?
I’m used to functional programming. For me, reduce is perfectly normal. Fewer intermediate variables. No pesky statements, just a nice expression. Great.
Buuuut… some languages think implementing tail call optimization is too hard or bad or for ivory tower academics. Or they’re dynamically typed. And then reduce does become difficult to special case and make performant. So even if you like the juice it’s probably not worth the squeeze.
It was a great time working with Haskell professionally. I didn’t have to constantly defend my style of programming! But in “everything” languages… well you do. Everyone has to agree on which subset to use. And programmers are like cats. Good luck getting them to agree on anything. Even once you agree there will always be that one challenging the decree.
By agentultra 3 hours ago
For can have another set of variables in the header too. You can simulate it more readably even if you need to call the lambda.
By hyperhello 2 days ago
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)
which is map + reduce. And that's only if x[1] is a number. That's about it. No equivalent in JS. Whenever some JS code has map, I'm like why, and rewrite it as a loop.
This is also assuming we're talking about regular code and not an actual map-reduce framework like Spark.
By mahboi 3 hours ago
Alternative theory - reduce is badly named.
combine, accumulate it aggregate would have way more use.
By rspeele 2 days ago
By zelphirkalt 3 hours ago
By jiehong 3 hours ago
By reddit_clone 2 hours ago
By anitil an hour ago
By mitxela an hour ago
By seanw444 3 hours ago
By jdougan an hour ago
By dreamcompiler 7 minutes ago
By andrekandre 2 hours ago
By mikebenfield 2 hours ago
By dcminter 3 hours ago
By NooneAtAll3 2 hours ago
By pavlov 3 hours ago
By quaverquaver an hour ago
By mitxela an hour ago
By bawolff an hour ago
By atherton94027 an hour ago
By catapart 3 hours ago
By xp84 3 hours ago
By diegof79 2 hours ago
By jdougan 2 hours ago
By adamddev1 2 hours ago
By anitil an hour ago
By reddit_clone 2 hours ago
By scotty79 3 hours ago
By remywang 8 minutes ago
By RomanKornev 18 minutes ago
By el_oni 2 days ago
By adverbly 4 hours ago
By antfarm 2 hours ago
By the_other 3 hours ago
By kenferry 2 hours ago
By xp84 3 hours ago
By anyfoo 3 hours ago
By baxuz 3 hours ago
By anyfoo 2 hours ago
By Skeime 3 days ago
By Someone 3 days ago
By Hackbraten 3 days ago
By speedstyle 2 days ago
By Skeime 3 days ago
By Someone 3 days ago
By hungryhobbit 4 hours ago
By keychera 38 minutes ago
By bunderbunder 3 hours ago
By OkayPhysicist 3 hours ago
By jakub_g 3 hours ago
By Terr_ 2 hours ago
By felizuno 2 hours ago
By kevinwang 2 hours ago
By dochne 3 hours ago
By grommet_kit 44 minutes ago
By tantalor an hour ago
By ducaale 2 days ago
By xdavidliu 2 hours ago
By Bayard_ne an hour ago
By pmontra 2 hours ago
By very-old-sw an hour ago
By odo1242 37 minutes ago
By scelerat 4 hours ago
By skybrian 3 hours ago
By altruios 3 hours ago
By futune 3 days ago
By 3836293648 2 days ago
By yipinwong 3 hours ago
By very-old-sw an hour ago
By olivewong 2 days ago
By Terr_ 3 hours ago
By agentultra 3 hours ago
By hyperhello 2 days ago
By mahboi 3 hours ago
By scotty79 3 hours ago