Thread

1. RomanKornev · 1789606146 · focus · HN ↗

   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.

   1. wingman-jr · 1789608467 · focus · HN ↗

      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?

      1. int_19h · 1789797030 · focus · HN ↗

         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.
   2. tehnub · 1789619225 · focus · HN ↗

      This one doesn't seem expressible in those terms:

          from functools import reduce
      
          df = reduce(DataFrame.union, dfs)

Unofficial Hacker News client; not affiliated with Y Combinator.