プログラマーはなぜ「reduce」を嫌うのか

mapとfilterは通常引数が1つだけで、2つある場合でも2番目はほぼ常に0始まりのインデックスだ。ほとんどの言語で見た目は同じで、MicrosoftがSelectとWhereと呼ぶ場合でもそうだ。

reduceにはアキュムレータと2引数の関数があり、言語間でreduce(initial_acc, callback(acc, elem))なのか、reduce(callback(acc, elem), initial_acc)なのか、reduce(callback(elem, acc), initial_acc)なのか、あるいは何なのか、一貫性がない。

覚えにくい。さらに、初期アキュムレータを全く取らないreduceのバージョンを持つ言語もあり、これは空のコレクションにぶつかるのを待っているだけの足を撃つ銃だ。それに、匿名型をサポートしていない、あるいは匿名型レコードの簡単な変更をサポートしていない言語では、アキュムレータは簡単に扱いにくくなる。ほとんどの言語がそうだ！

パフォーマンスが悪化するという点に関連して、reduceがPython 3から「追放」された——Python 2の組み込みreduce()ではなくfunctools.reduce()に格下げされた——現場に居合わせたとほぼ確信している。

話は2006年か2007年頃、Guido van RossumがGoogleの内部コードレビューツール（彼が書いた）でウェブページのレンダリングに30秒以上かかる理由をデバッグしていたときにさかのぼる。

これは基本的に「本番」インシデントで、何千人ものGoogleのエンジニアがそのツールに依存していた。このようなリクエストはスレッドを占有し、スレッドプールを枯渇させていた可能性がある。

最終的に、reduce()で書かれた行折り返しアルゴリズムに行き着いた。彼が書いたものではないと思う——依存関係を通じて入り込んだのかもしれない。多くの人が知っているように、reduce()は基本的に：

s1 + s2

s1 + s2 + s3

s1 + s2 + s3 + s4

...

そしてs_iが文字列の場合、これはO(n^2)になる。5000行以上のdiffや5000行以上のファイルを表示したときに現れたと思う。（Githubのような新しいプログラムもここで苦しむ）

当時のPythonでは、+=はすでにこれを避けるように最適化されていたと信じている（本質的にすべてのJS VMがそうであるように）。あるいは、listにappend()してからjoin()するイディオムを使うこともできる。

しかしreduce()は基本的に非効率な実装を強制し、これはPython 3でも依然として真実だと確信している。

---

つまり、Guidoはreduce()に関連するパフォーマンス問題のデバッグに長い時間を費やし、ユーザーが「足を撃つ銃」を避けるのを助けるために、それを排除する決定を下した。当時彼のオフィスメイトだったので覚えているが、私はその場に居合わせたわけではな[…]

仕事でreduceを使ったのはほんの数回だが、そのたびに眉をひそめられる。

しかし、たくさんのSparkデータフレームを結合する場合、

df = reduce(DataFrame.union, list_of_dfs)

は

df, *rest = list_of_dfs

for other in rest:

df = df.union(other)

よりもずっと良いと思う。

特に今はfunctoolsからインポートしなければならないので、みんな少し変な反応をする。

できるだけmapとfilterで置き換えてreduceの使用を減らそうとよく試みる者として言うと、私にとってreduceに頼るのはwhileループやforループに頼るのと似ている：できるなら避ける。

reduceの問題は、あまりにも多くのことができるため、素早く読んだときに何をしているのかが明確でないことだ。