Lobsters Spent 88 Comments on Why Nobody Uses reduce, and Hacker News Scrolled Past It Twice

On 13 September, Evan Hahn published a short post noting that programmers seem to dislike reduce. His evidence was his own code reviews: submit a patch with a reduce in it, get back a comment that this part is hard to read. He was careful to say he might be seeing a trend that is not really there.

Two days later the post had 97 points and 88 comments on Lobsters, and had been submitted to Hacker News twice, drawing 13 points with 11 comments and 12 points with 13 comments. It never reached the HN front page. Same post, same week, and one community wrote an essay while the other shrugged and scrolled.

We read both threads, then went and counted.

The argument, at its strongest on both sides

The case against reduce is not that it is hard. It is that it is too general to tell you anything. When you see map, you know the output is the same length as the input and each element depends only on its own source. When you see reduce, you know nothing. The reader has to run the whole thing in their head before they learn what it does.

The case for it is that this generality is the point. reduce is the universal operation over a list, map and filter are both definable in terms of it, and objecting to it is objecting to the primitive that the nicer functions are made from. If your problem genuinely is a fold, writing a loop that mimics one is not simpler, it is the same thing with the structure hidden.

The takes

The top comment on Lobsters, from nick4 at 44 points, set the frame everyone else argued inside:

I think it's because reduce is usually too powerful. Map and filter are very focused operations. But reduce is actually pretty powerful.

darichey (25 points, Lobsters) turned that into the readability claim directly:

Code with too much expressive power is harder to read. When you are reading and come across map or filter, it narrows the space of possible things the code could do. reduce doesn't do that at all.

pzel (35 points, Lobsters) made the practical version, which is about working memory rather than theory:

Is this a right fold or a left fold? Does it matter? Is the first argument the base accumulator or the reducer function? In the reducer function, which argument comes first, the element or the accumulator? [...] What gets evicted is probably the domain logic that we're trying to express in the fold.

technomancy (28 points, Lobsters) blamed the word itself, and noted that when the Fennel language needed one, they went looking at Smalltalk's inject and settled on accumulate instead:

reduce is a terrible name. I think fold is marginally better but not by much.

Internet_Janitor (28 points, Lobsters) supplied the one concrete fix in either thread, from the array languages:

K uses / ("over") for reduction and \ for its counterpart, "scan", which produces all the intermediate results [...] A surprising number of languages which offer "reduce" do not also provide a "scan".

Over on Hacker News, snackbroken made the same point as darichey without the type theory:

Map and Filter are nice because they let you reason locally about a single element in isolation. Reduce(Fold) forces you to reason globally about intermediate results.

rspeele (Hacker News) named the thing that actually stops people, which is that no two languages agree on the shape of the call: whether the initial accumulator comes first or last, and whether the callback receives the accumulator or the element first. theamk (Hacker News) offered the blunt workaround: in Python, sum() covers most of it, needs no import, and reads better.

And japgolly (Hacker News) supplied the dissent, which is worth keeping because it is the whole minority position in one line:

fold is awesome and super useful. It's the easiest and most convenient way to turn a collection into a single value. Put me anecdotally in the opposite bucket.

What the two platforms disagreed about

The split is cleaner than we expected, and it is not about the conclusion. Both communities landed in roughly the same place. They got there through completely different doors.

Lobsters answered why. The thread reached for a Böhm-Berarducci encoding of the list type, for Graham Hutton's 1999 paper on the universality of fold, for APL and K's symmetry between over and scan, and for Pyret's dedicated for fold syntax as evidence that the ergonomics are fixable. It is a thread about whether the objection is really about expressive power.

Hacker News answered what to do instead. Argument order. The import from functools. Whether the accumulator variable got a decent name. Use sum. Use a loop. Twenty-four comments across two submissions, both of which stalled.

The interesting part is the non-response. This is a language-design question with a 27-year-old paper behind it, and the larger, more general-purpose audience declined it twice. Lobsters is where this post was always going to land, and that is a fact about the post, not about Hacker News.

The best comment nobody upvoted

Sitting at 13 points, well under the 44-point theory at the top, hyperpape quietly took the whole thread apart:

The power might be related, but the simple for loop is even more powerful. However, for loops that mimic a simple reduce (e.g. sum, product, etc) can be quite readable. [...] My point is just that this isn't just about power, it's also about syntax/pattern recognition.

That is the argument that actually survives. If generality were the problem, the for loop everyone reaches for instead would be worse, because it can do strictly more. It is not worse. So the complaint is about familiarity and shape, not power, and the top-voted explanation on Lobsters is elegant and wrong.

We counted, because anecdotal is fixable

Hahn was not sure his pattern was real. That is a countable question, so we counted: every non-test .js, .ts, .mjs, .jsx and .tsx file across six popular libraries at current main, 2,613 files and 266,977 lines.

Repository	Lines	map	filter	reduce	reduce share
svelte	79,973	211	83	11	3.6%
zod	51,747	179	76	6	2.3%
date-fns	106,380	81	16	1	1.0%
axios	10,877	24	8	1	3.0%
preact	13,093	17	10	1	3.6%
express	4,907	16	4	0	0.0%
Total	266,977	528	197	20	2.7%

Twenty uses of reduce in a quarter of a million lines. That is 0.75 per 10,000 lines against 19.78 for map, a ratio of 26 to 1. Express, which has shipped in production for fifteen years, contains none at all.

Then we ran the same count on three libraries built around the abstraction, and the picture inverts:

Repository	Lines	map	filter	reduce	reduce share
ramda	13,389	23	13	11	23.4%
rxjs	24,991	95	56	17	10.1%
immutable-js	34,275	237	79	25	7.3%

Ramda uses reduce for 23.4% of its trio calls. That is nearly nine times the mainstream rate.

Our read

Hahn's instinct was right and his uncertainty was unnecessary. The pattern is real and it is not subtle.

The trend he was not sure he was seeing runs 26 to 1 in the libraries you already depend on.

But the Lobsters explanation and the Hacker News explanation are both incomplete, and the two tables are why. If reduce were simply too powerful to read, Ramda would avoid it too. It does the opposite. What actually predicts usage is not the function, it is whether the surrounding code is already written in the idiom that makes a fold legible. In a codebase of loops and early returns, a reduce is a register change, and readers experience register changes as difficulty.

Which makes the code review comment correct in context and wrong as a general rule. "This part is hard to read" usually means "this part is written in a different language from the rest of the file", and that is a real objection. It is just not an objection to reduce.

What would change our mind: a codebase in a loop-first idiom where reduce usage is high and review friction is low. We did not find one, but six libraries is six libraries.

Your move

Run the count on your own repo. It is one grep per function, and the number that matters is the ratio, not the total. Is your reduce rate closer to Express at zero or Ramda at 23%, and does that match how your team actually reviews code? We would like the number more than the opinion.

If the two-communities-two-conclusions shape is what interests you here, our piece on Hacker News and r/reactnative reaching opposite verdicts on the same React Native retreat is the same split with much higher stakes attached.