Anecdotally, programmers dislike "reduce"Anecdotally, programmers dislike "reduce"by Evan Hahn,
posted
Sep 13, 2026, tagged
#software-development
#cultureIn short: from my experience, people like map and filter, but not reduce.I use functions like map and filter all the time. When I put that code up for review, my peers rarely complain. I get plenty of feedback about other decisions, but not about my use of map and filter.I cannot say the same for reduce. Often, when I’ve submitted a patch with reduce inside, I get a comment like, “this part is hard to read.” And I see reduce way less than map, filter, some, and so on.Anecdotally, I have come to believe that programmers don’t like reduce as much.I don’t know why, but I have a few theories:reduce is harder to read.reduce is less familiar.reduce can have worse performance compared to other options.reduce is less elegant in languages I use, like JavaScript, Python, and Swift. In my blissful stint as a Clojure developer, I did not get this feedback.I’m wrong, and I’m seeing a trend that’s not real.I usually just change reduce to something else and move on. Even though I prefer it, I don’t usually care much. But it’s a little social phenomenon I’ve observed, and I thought I’d document it.I’ve also noticed this less recently, possibly because code review is less thorough nowadays.Do you notice this? Do you like reduce? Please tell me.About meContactProjectsGuidesBlogRSSNewsletterMastodonUnless noted otherwise, content is licensed under the Creative Commons Attribution-NonCommercial License and code under the Unlicense.
Logo by Lulu Tang.
Profile photo by Ali Boschert-Downs.

Anecdotally, there is a perception among programmers that they dislike the use of the reduce function compared to other functional operations like map and filter. The author, Evan Hahn, observes that while functions such as map and filter are generally accepted during code review without complaint, the use of reduce frequently elicits comments regarding readability, such as the assertion that a section using reduce is difficult to read. This observation suggests a social phenomenon regarding coding practices rather than an objective technical failing of the reduce operation itself.

The author posits several potential reasons for this observed aversion to reduce. These theories include the idea that reduce is inherently harder to read, less familiar to some developers, potentially offers worse performance compared to alternative methods, and lacks the elegance found in certain languages like JavaScript, Python, and Swift. The author notes a contrast between their personal experience as a Clojure developer, where such feedback was absent, and the current trend they are observing. Furthermore, the author speculates that this trend may be less pronounced recently, possibly due to a decrease in the thoroughness of modern code review processes. Ultimately, the author documents this perceived discrepancy, questioning whether others share this feeling about the reduce pattern.