関数型プログラミングは宣言的なパラダイムです。FPの長所の1つは、副作用が回避されることです。いくつかの問題では、FPは適切ではないと言われています。
関数型プログラミングが適合しない一般的な問題は何ですか?
関数型プログラミングは宣言的なパラダイムです。FPの長所の1つは、副作用が回避されることです。いくつかの問題では、FPは適切ではないと言われています。
関数型プログラミングが適合しない一般的な問題は何ですか?
回答:
本質的に非常にステートフルなアプリケーション。ビデオゲームは実世界をモデル化しているため、良い例です。何かが変化するたびに以前の状態から再構築するのではなく、世界の状態を変更することを考える方がはるかに理にかなっています。
具体的な例は、怪物が撃たれた後に怪物の健康状態を変えることです。単にヘルスを変更するほうが、ヘルスが低下したことを除いて、あらゆる点で同じ完全に新しいモンスターに置き換えるよりもはるかに賢明です。これらの種類の変更は、ゲームの世界のほぼすべてを構成し、純粋に機能的な方法でこれを行うことはあまり直感的ではありません。少なくとも純粋に関数型言語で実行している場合は、パフォーマンスに重大なペナルティが生じる可能性があると思います。
(補足として、ゲームの問題の中には、AIなどの関数型プログラミングに非常に適しているものもあります。ハイブリッド関数/命令型言語は、これらの場合に最適です。)
リアルタイムの組み込みプログラミングはすべて副作用です。デジタルおよびアナログIO、タイマー、シリアルおよびパラレルポートとのやり取り、興味深いことはすべて、副作用を伴う関数を呼び出すことによって行われます。
GUIプログラミングは、関数型プログラミングには適していないと思います。GUIは一般に非常にステートフルであり、副作用なしで使用するよりも状態を使用してモデリング/管理する方がはるかに簡単です。GUIに関数型プログラミング言語を使用することは確かに可能ですが、おそらくそれは良い考えではありません。
別の回答で述べたように、ゲームは状態を追跡することで管理が容易になることが多く、関数型言語でゲームを書くことはできますが、「ステートフル」言語(つまり、オブジェクト指向の言語)言語)。
データ駆動型ビジネスアプリケーション。ユーザーインターフェイスと単純なデータ操作には、FPは必要ありません。
filter
、reduce
そしてmap
です。一部で投げsort
、partition
、groupBy
。結局のところ、そのようなアプリケーションを作成するために最も広く使用されているプログラミング言語は、関数型言語であるExcel です。
関数型プログラミング自体には適さない問題セットを簡単に却下することはできません。
関数型プログラミングに使用される実際の言語とその機能に大きく依存します。
1つの例は、リアルタイム組み込みシステム用の既述のErlangです。
ステートフルネスは、関数型プログラミングに対する優れた基準でもありません。これに対処するために、関数型プログラミング言語で実装されたいくつかの成功した方法があります。
関数型プログラミングに対する副作用もしばしば言及されています。完全に独創的ではないすべてのプログラムには、副作用があります。したがって、現実世界のすべてのFP言語には、これに対処する方法がありますが、それは世界の副作用をいかにエレガントにカプセル化するかだけです。
グローバル変数のような任意の副作用はまったく必要ありません。
しかし、問題をよく見かける方法をひねらないため、関数型プログラミングを簡単に行えるようにする問題セットがあります。しかし、ひとたび機能的に考えるようになれば、より多くの問題がより少ない副作用に開かれます。
Cをプログラミングする場合でも、グローバル変数などの任意の副作用を可能な限り減らすことは常に良い考えです。