1. ホーム
  2. functional-programming

[解決済み】なぜ関数型プログラミングはまだ浸透していないのでしょうか?

2022-04-17 17:23:40

質問

宣言型/関数型プログラミング(言語)についてのテキストをいくつか読み、Haskellを試し、そして自分で書いてみた。私が見たところ、関数型プログラミングは古典的な命令型スタイルに比べていくつかの利点があるようです。

  • ステートレス・プログラム、副作用がない
  • 並行処理:マルチコア技術との相性が抜群に良い
  • プログラムは通常短く、場合によっては読みやすくなる
  • 生産性が上がる(例:Erlang)

  • 命令型プログラミングは(私が知る限り)非常に古いパラダイムであり、21世紀には適さない可能性があります。

なぜ、関数型言語で書かれたプログラムを使う企業はまだ少ないのでしょうか?

関数型プログラミングの利点を考えると、なぜいまだに命令型プログラミング言語が使われているのでしょうか?

1990年当時はまだ早かったかもしれませんが、今はどうでしょう?

どのように解決するのか?

なぜなら、これらのメリットはすべてデメリットでもあるからです。

<ブロッククオート

ステートレス・プログラム、副作用がない

現実のプログラムは、副作用と突然変異がすべてです。ユーザーがボタンを押すのは、何かが起こることを望んでいるからです。ユーザーが何かを入力すると、その状態が、以前そこにあったどんな状態も置き換えることを望むのです。経理のジェーン・スミスが結婚してジェーン・ジョーンズに名前を変えたとき、彼女の給与明細を印刷するビジネスプロセスを支えるデータベースは、その種の変異をすべて処理できるものでなければなりません。 エイリアンに機関銃を撃つとき、ほとんどの人は精神的に、ヒットポイントの少ない新しいエイリアンの構築としてモデル化するのではなく、既存のエイリアンのプロパティの変異としてモデル化します。

プログラミング言語のコンセプトが、モデリングされるドメインに対して根本的に不利に働く場合、その言語を使うことを正当化することは難しい。

<ブロッククオート

並行処理:マルチコア技術との相性が抜群に良い

問題は押し付けられるだけ。不変のデータ構造では、古いデータを扱う可能性があるという代償を払って、安価なスレッドセーフを手に入れることができます。ミュータブルなデータ構造では、常に新しいデータで作業できるという利点がありますが、データの一貫性を保つために複雑なロジックを書かなければならないという代償があります。どちらか一方が明らかに優れているというわけではありません。

<ブロッククオート

プログラムは通常、短く、場合によっては読みやすくなる

ただし、長くて読みにくい場合は別です。関数型スタイルで書かれたプログラムの読み方を学ぶのは難しいスキルです。人々は、プログラムを実行されるべき一連の計算としてではなく、レシピのように従うべき一連の手順として考える方が得意なようです。

<ブロッククオート

生産性が上がる(例:Erlang)

関数型プログラミングの方法を知っているプログラマーを雇うための膨大な費用を正当化するためには、生産性が大幅に向上しなければなりません。

そして忘れてはならないのは、動いているシステムを捨てたくないということです。ほとんどのプログラマーは、ゼロから新しいシステムを構築するのではなく、既存のシステムを保守しており、そのほとんどは非機能的な言語で構築されています。それを株主に正当化しようとすることを想像してみてください。なぜ、何百万ドルもかけて、既存の給与システムを廃棄して、新しいシステムを構築したのでしょうか? なぜなら、関数型プログラミングは素晴らしいからです。

<ブロッククオート

命令型プログラミングは(私が知る限り)非常に古いパラダイムであり、21世紀には適さない可能性がある。

関数型プログラミングもすごく古いんですよ。コンセプトの古さは関係ないと思うのですが。

誤解のないようにお願いします。私は関数型プログラミングが大好きで、関数型プログラミングの概念をC#に取り入れる手助けをしたくてこのチームに参加しましたし、イミュータブルスタイルでのプログラミングは未来の道だと考えています。しかし、そこには 膨大なコスト 関数型プログラミングは、単純に無視することができないのです。より機能的なスタイルへの移行は、数十年かけてゆっくりと、徐々に行われるでしょう。Haskellの純粋さと美しさを全面的に受け入れてC++を放棄するのではなく、より機能的なスタイルへのシフトが起こるのです。

私はコンパイラを作ることを生業としていますが、次世代のコンパイラツールは間違いなく関数型スタイルを採用しています。それは、関数型プログラミングが、私たちが直面している種類の問題に基本的によくマッチしているからです。私たちの問題は、生の情報、つまり文字列やメタデータを取り込み、それらを別の文字列やメタデータに変換することにあります。IDEで誰かがタイプしているような突然変異が起こる状況では、問題空間は本質的に、変更されたツリーの部分のみを段階的に再構築するような関数的手法に適しているのです。 多くのドメインは、明らかに関数型スタイルに従順となるような、このような素晴らしい特性を持っていません。 .