News for hackers. Stuff that matters.
Re:Anecdotally, Programmers Dislike "Reduce" by RomanKornev on Wednesday September 16, 2026 @08:49PM (#49735088)
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.

My favorite antipattern is

  items.reduce(
    (acc, item) => ({
      ...acc,
      [item.id]: item,
    }), {}
  );
Like, why? Not only is this ridiculously inefficient O(N^2), it's also longer and less understandable than "build a new map" version.
Re:Anecdotally, Programmers Dislike "Reduce" by wingman-jr on Wednesday September 16, 2026 @09:27PM (#49735327)
I think this along with the other answers discussing the difficulty remembering the specific arguments of `reduce` (especially when varying by language!) are key reasons. After reading this conversational thread, I think maybe Microsoft got it right with LINQ: - `Where` is perhaps more intuitive than `filter` - `Select` seems no worse than `map` by invoking SQL-like syntax - While `reduce` is preserved as `Aggregate`, provide `GroupBy` and other handy methods as the preferred methods. In the code I write, it's probably these other methods that get called 95+% of the time. Who wants to `Aggregate` when they can simply `Sum` for example?
Re:Anecdotally, Programmers Dislike "Reduce" by int_19h on Saturday September 19, 2026 @01:50AM (#49763706)
LINQ was very intentionally designed to use SQL terminology for this because at the time (to remind, this was 2007), your typical C# or VB developer had no clue whatsoever about functional programming and the usual terminology there, while SQL knowledge would be much more widespread.
Re:Anecdotally, Programmers Dislike "Reduce" by tehnub on Thursday September 17, 2026 @12:27AM (#49736411)
This one doesn't seem expressible in those terms:

    from functools import reduce

    df = reduce(DataFrame.union, dfs)