私はステートレスプログラミングの利点について疑問に思っていましたが、私の質問を共有している人を見つけました： ステートレスプログラミングの利点は？
しかし、答えを読んでいると、逆の質問に興味を持ちました。ステートフルプログラミングの利点は何ですか？最近はステートレスコードに注目が集まっているようですが、トレンドには警戒しています。
ステートフル（つまり命令型）プログラミングは、ステートレス（つまり関数型）プログラミングよりも特定のシナリオに適しているようです。ステートフルプログラミングで解決できる問題をよりよく認識できるようにしたいと思います。
不変のステートレスプログラミングモデルと比較して、可変の共有状態に基づくプログラミングモデルに議論の余地のない利点がある場合はごくわずかです。可変性が大きな利点をもたらすことができる1つの領域は、アルゴリズムがインプレースで機能できるようにすることです。haskell wikiには、クイックソートの実装に関する優れた例があります：http: //www.haskell.org/haskellwiki/Introduction#When_C_is_better
要約すると、リストメモリへの変更を許可しない場合は、ソートされたコピーを作成する必要があります。同じことが、AVLツリーなど、一部のデータ構造を変更する他のほとんどすべてのアルゴリズムにも当てはまります。
一般に、関数型プログラミング言語は、命令型プログラミング言語よりもメモリを大量に消費する傾向があります。最近のメモリは安価ですが、帯域幅は非常に重要であり、メモリ速度はCPUパワーの増加に比例して増加していません。ただし、Haskellの実行モデルでは、メモリ使用量とアクセスパターンに関しても、コンパイラがいくつかの気の利いた最適化を実行できることに注意する必要があります。ある程度、これは理論上の欠点を補うことができます。
読みやすさが重要です。私は関数型プログラミングが好きです（現在、私はclojureの大騒ぎをしています）が、状態は世界がどのように機能するかです。オブジェクト指向パラダイムが機能的または他のタイプのプログラミングよりも人気があるのは偶然ではありません。OOPと手続き型プログラミングは、新しいプログラマーにとって最も抵抗の少ない道です。ほとんどの人は、オブジェクトの概念を、再帰を支援するYコンビネータではなく、状態を変更するもの（移動中、色の変更など）として直感的に理解します。
状態は重要です。このユニバースのすべてのビットには状態があり、システムの動作を定義する状態です。状態はシステムを動的で使用可能にしますが、状態は非常に重要であるため、この状態にアクセスして操作する方法も重要です。人間が他の人間の状態（人間の脳の内容としての状態）を操作できるとしたら、それは良くありません。状態に関する私の見解は、明示的にする必要があり、コード全体に散らばって、システムがどの状態にあり、システムのどの部分がどの部分に責任があるのかを知るのが難しいという非常に暗黙的なものであってはならないというものです状態。状態は、システムの状態のこの部分がこのモジュールによって処理され、このモジュールのみによって処理されると簡単に言えるように制御する必要があります。
実際のFPプログラムでは、常に2つの部分があります。1つはコアアルゴリズムなどのステートレスであり、もう1つはプログラムの状態を維持する部分です。