著者から：「関数型プログラミングは奇妙だから人気がありません」 という 記事の翻訳は、激しい議論を引き起こしました。 いくつかのコメントは、関数型プログラミングの欠点を議論する際に、最新の開発された関数型言語（元の記事では例はC ++テンプレートに基づいていた）に頼るのが良いだろう、そして例えばHaskellが過去5年間業界で広く使われていることを非常に正しく指摘しました。 この点で、別のブログ（ 科学者のための本F＃の著者）からの2つの非常に実質的な記事に注目したいと思います：（i）「 純粋な関数型プログラミングの欠点 」と（ii）「 Haskellが業界であまり使用されない理由 」 それらの最初の翻訳を以下に示したいと思います。

1.純粋な関数型言語では、効果的な無秩序な辞書とセットはありません

90年代以来、開発での辞書の使用はすべての記録を破りました。 辞書は現在、すべての開発者が標準ライブラリで見つけることを期待している標準コレクションです。



有名な 岡崎のモノグラフに見られるような純粋に機能的または永続的なデータ構造は、優れたツールです。 特に、それらが提供する永続性は、コレクションの変更方法を気にせずにコレクションの古いバージョンにアクセスできることを意味します。 多くの場合（特に、論理プログラミングやコンパイラーの作成などのタスク）、これにより、変更を簡単に追跡できるため、意思決定がより短く簡単になります。 しかし、永続化のためには、パフォーマンスの観点から大きな代償を払わなければなりません：純粋に機能する辞書は通常、適切に実装されたハッシュテーブルよりも約10倍遅く、違いが40倍に達するケースを見てきました。 一部のアプリケーションでは、これは非常に遅いです。



さらに、ほとんどの関数型言語（OCaml、Haskell、Scala）は、 具体化された ジェネリック 、値型、およびガベージコレクターのクイックライトバリアのキラーな組み合わせがないため、高速で可変のジェネリックハッシュテーブルを表現できません。



注意！ Haskellの純粋に機能する辞書は高速であると主張しようとしている人々に注意してください。 同じHaskellの可変ハッシュテーブルと比較します 。 この比較からの正しい結論は、Haskellの可変ハッシュテーブルが遅いということです。

2.純粋に機能する弱いハッシュテーブルはありません。

命令型ガベージコレクション言語では、ノードとグラフのエッジ間の関係は、 弱いハッシュテーブルを使用して表現できます。 ガベージコレクターは、到達不能なサブグラフを収集します。 純粋に関数型の弱いハッシュテーブルがないため、純粋な関数型言語では、ガベージコレクションを記述する必要があります（ おおよそ、Transl。、手で到達できない部分グラフを削除するという意味で）。



ただし、ほとんどの開発者が弱いハッシュテーブルを使用したことがないため、これは最も深刻な欠点ではありません...

3.純粋に機能的なスレッドセーフコレクションはありません。

定義上、不変のコレクションは、スレッドセーフなどの可変性をサポートできません。 したがって、共有の可変コレクション（メモリ内データベースなど）が必要な場合、純粋に機能的なソリューションは存在しません。

4.ほとんどのグラフアルゴリズムは、機能的なスタイルで記述されている場合、外観が悪く、動作がはるかに遅くなります。

関数型プログラミングはいくつかのタイプのタスクに最適なツールですが、私の観察によると、グラフアルゴリズムは、コードのシンプルさとパフォーマンスの両方の点で純粋に関数型のソリューションがしばしば悪い場所です。



Pythonの12行の PrimアルゴリズムとHaskellの20行の Primアルゴリズムを比較してください。 実際、HaskellがライブラリでPrimアルゴリズムを使用するのはなぜですか？ おそらく、Kruskalのアルゴリズムは「 union disjoint set system 」（ union-findコレクション 、別名Disjoint-setデータ構造）のデータ構造に基づいているため 、関数型言語では効率的な実装がありません。

5.従来の命令型データ構造とアルゴリズムの慣性は巨大です

グラフアルゴリズムに加えて、65年の科学文献がほぼ完全に命令型ソリューションに焦点を当てているコンピューターサイエンスの分野が数多くあります。 その結果、命令型言語のプログラマーは巨人の肩の上に立ち 、これらの開発を活用できますが、関数型言語のプログラマーは多くの場合ゼロから始める必要があります。 結局、ほんの数年前にHaskellでのメモ化は博士号の対象でした。



私はかつて、数人のHaskellプログラマー（およびこの言語で学位論文を持っている人もいます）が効果的な並列クイックソートを書くことを提案しました 。

6.結局のところ、関数型言語のすべての既存の実装（純粋なものと不純なものの両方）は、大量のメモリを割り当てるように設計されています。

1960年頃、マッカーシーはLispを発明しました。 主なデータ構造は、単一リンクリストです。 各リスト項目は、ヒープ上で個別に割り当てられました。 現代のすべての関数型言語は、この考えから発展しました。 70年代、Schemeは本質的にLispと同じデータ表示戦略を使用していました。 80年代には、SMLは言語にタプルが含まれるため、アンブロック化を少し追加し、メモリブロック全体としてヒープに割り当てました。 90年代、OCamlは言語に実数のアンパックされた配列が含まれていたため、もう少しアンパックを追加しました。 Haskellは、特定のデータ型をアンパックする機能を追加しました。 しかし、現在までに、デフォルトでアンパックされる関数言語はありません（ およそTransl。どうやら、著者は何らかの理由で「スタックにデフォルトで配置されたタプル」というこの方法を選択しました）。 任意の値タイプを作成できる.NetベースのF＃でさえ、パックされた.Netタプルを使用します。 その結果、現代のすべての関数型言語は、ヒープを頻繁に割り当てる必要がなく、ヒープ上でメモリを頻繁に割り当てるという負担を負います。 その結果、必要以上にガベージコレクタをロードします。 これは深刻な問題です。シングルスレッドコードが遅くなるだけでなく、ガベージコレクタが共有リソースであり、その結果、ガベージコレクタの負荷が並列プログラムのスケーラビリティを低下させるためです。



「欠陥」などの動作の宣言は議論の余地があることに注意してください。 OCamlコミュニティのXavier Leroyは、 Coqの定理を自動的に証明する環境でOCamlの優れたパフォーマンスの基礎となるため、LispイメージでOCamlのデータを提示することは利点であると考えています。 ザビエルは 、「シンボリックコンピューティングに対するOcamlの戦略は最適に近い」 と述べています。 関数型言語は、命令型コレクションのパフォーマンスが低いため、高パフォーマンスの純粋に機能的なコレクション向けに最適化されることがよくあります。 命令型コレクションはほとんど高速であるため、ほとんどすべての関数型言語でパフォーマンスの上限が人為的に低くなります。

7.純粋な関数型プログラミングは理論的には並行性には適していますが、実際のパフォーマンスの点ではあまり良くありません。実際の高いパフォーマンスが唯一の並行性の問題です。

現在、並列プログラムを作成する理由は2つあります。 1つは、客観的に迅速な意思決定を書くことです。 2つ目は、それほど遅くない決定をすることです。 ほとんどの場合、関数型言語での並列プログラミングは2番目の理由のバリエーションです。 高性能コンピューティングの環境、つまりスーパーコンピューターでは、機能コードを直接実行しない人はほとんどいません。 関数型言語の開発者がプロ​​グラムを並列化する場合、ほとんどの場合、優れた絶対的なパフォーマンスを達成するためにそれを行うのではなく、速度を向上させます。



Haskellのような純粋な関数型言語は、プログラマからメモリと時間を隠すように設計されています。 これはプログラマーにプログラムの鳥瞰図を提供しますが、Haskellプログラムが消費するメモリの量と、結果が得られるまでに実行に要する時間を見積もることは非常に困難です。 並列プログラミングでは、並列化によるゲインが並列コード実行の管理オーバーヘッドを上回ることを常に確認することが非常に重要です。 Haskellでは、これは非常に困難です。 実際、Haskellの並列実行に関する公開された研究では、並列度の結果を非常に選択的に提供するため、パフォーマンスを最大化できますが、この程度は、プログラムを何度も実行することなく事前に予測することはできません。 私の経験では、C ++などの言語では 、パフォーマンスが予測できないHaskellとは異なり 、最も標準的な方法で並列化すると予測可能な速度向上が得られることがよくあります 。



注意！ 絶対的なパフォーマンスに関係なく、プログラムのスケーラビリティについて話す人々に注意してください。 ほとんどの計算は信じられないほどの並列コードで行われるため、コードの各行の後に無意味にマンデルブロ集合を計算することにより、ほとんどすべての並列プログラムのスケーラビリティを改善できます。 スケーラビリティは必要ですが、十分な条件ではありません。 絶対的なパフォーマンスを必ず確認する必要があります。

8.コミュニティでの横柄なスノッブの濃度を、関数型プログラミングに関する有用な答えを得ることができる程度まで希釈するのに50年かかりました

私は20年以上にわたって関数型プログラミングに携わってきました。 何十年もの間、関数型言語のプログラマーと実際の問題を解決したプログラマーの間には、社会的な格差がありました。 神に感謝します。この問題は、Scala、Clojure、F＃などの関数型言語が実際のタスクに使用されるようになり、解決され始めました。 しかし、長年にわたって関数型プログラミングコミュニティを支配していたのは慢なスノッブであり、実際の問題に対する実際の解決策を得ることは非常に困難でした。 この理由は、多くのコミュニティが（数十年にわたってLispを）気づかずに自分のデバイスに任せ、言語（Lisp）がなぜ優れているのかについて非常に（しかし間違った）議論を展開していたためです。 これらの議論の何が間違っているのかを理解するのに何年もかかりました。

9.関数型プログラミングについて多くの誤った情報が流通しています。

Haskell でハッシュテーブルのパフォーマンスを批判する場合（最近の批判はこちら ）、コミュニティの著名人から絶対にワイルドなヒントを得ることができます。たとえば、ガベージコレクションをオフにするように文字通りアドバイスすることができます。



長い間、関数型プログラミングのコミュニティは、エラトステネスとクイックソートのふるいアルゴリズムの非常に短い実装にショックを受けていました。 彼らは何年も学生に教えられてきました。 そして何年もたってから、これらの実装は元のアルゴリズムに対応していないという理解が生まれました。 メリッサ・オニールは、ハスケルにあるエラトステネスのふるいを修正する科学論文も出版しました。 特に、実際のふるいには、エラーのある元のバージョンの100倍のコードが必要です。 Haskellは各クイックソート呼び出しでリストの深いコピーを作成し、元のHoarアルゴリズムの漸近的な複雑さを損なうため、Haskellの「エレガントな」2行バージョンがCのSajwickバージョンよりも1000倍遅いクイックソートにも同じことが当てはまります。 。



Haskellの業界ページの詳細については、 「 業界でHaskellがあまり使用されない理由 」も参照してください。



著者から：私はいつか「Haskellが業界であまり使用されていない理由」という記事を翻訳したいと思っています。Haskellが過去5年間業界で広く使用されているという意見に反論しようとしているからです しかし、（英語のオリジナルバージョンのコメントから判断すると）それはそれほど簡単ではなく、著者自身がいくつかの場所で誇張しているように見えることに注意すべきです。