関数型プログラミングの状態問題に対処する

私は主にOOPの観点からプログラミングの方法を学びました（私たちのほとんどがそうであるように）が、機能的な方法で問題を解決する方法を学ぶために多くの時間を費やしました。FPで計算上の問題を解決する方法はよく理解していますが、より複雑な問題になると、常に可変オブジェクトが必要になります。たとえば、パーティクルシミュレータを作成している場合、変更可能な位置を持つパーティクル「オブジェクト」を更新する必要があります。本質的に「ステートフル」な問題は、通常、関数型プログラミング手法を使用してどのように解決されますか？

機能プログラムは状態を非常によく処理しますが、それを見る別の方法が必要です。位置の例については、位置を固定値ではなく時間の関数にすることを検討する必要があります。これは、固定された数学的なパスをたどるパーティクルに対してはうまく機能しますが、衝突後など、パスの変更を処理するには別の戦略が必要です。

ここでの基本戦略は、状態を取得して新しい状態を返す関数を作成することです。したがって、パーティクルシミュレータはSet、入力としてa の粒子を取りSet、タイムステップ後に新しい粒子を返す関数になります。次に、その入力を前の結果に設定して、その関数を繰り返し呼び出します。

@KarlBielefeldtが指摘したように、このような問題に対する機能的なアプローチは、以前の状態から新しい状態を返すと見なすことです。関数自体は情報を保持しないため、常に状態mを状態nに更新します。

新しい状態を計算している間、以前の状態をメモリに保持する必要があると仮定するため、この非効率性を見つけると思います。完全に新しい状態を記述するか、古い状態を所定の位置に書き直すかの選択は、関数型言語の観点からの実装の詳細であることに注意してください。

たとえば、100万個の整数のリストがあり、10単位を1単位増やしたいとします。10番目の位置に新しい番号を付けてリスト全体をコピーするのは無駄です。ただし、これは操作を言語コンパイラーまたはインタープリターに説明する概念的な方法にすぎません。コンパイラまたはインタープリターは、最初のリストを自由に取得して、10番目の位置を上書きするだけです。

この方法で操作を記述することの利点は、多くのスレッドが異なる位置で同じリストを更新したい状況についてコンパイラーが推論できることです。操作が「この位置に移動して、見つけたものを上書きする」と記述されている場合、上書きが衝突しないことを確認するのは、コンパイラーではなくプログラマーです。

以上のことから、Haskellでも、「状態を維持する」ことが問題に対するより直感的な解決策である状況をモデル化するのに役立つStateモナドがあります。しかし、「データベースへの書き込みのように本質的にステートフル」な問題には、Datomicのような不変のソリューションがあることに注意してください。これは概念であり、必ずしもその実現ではないことを理解するまで驚くかもしれません。

適切なメンタルモデルをサブスクライブすると、状態をよりよく考えて管理できます。私の考えでは、最高のメンタルモデルはフリップブックです。これをクリックすると、FPは世界の状態をキャプチャする永続的なデータ構造に大きく依存し、関数を使用してその状態をまったく変更することなく遷移することがわかります。

リッチヒッキーはこれらのアイデアを明らかにします。

• 値の価値
• 値としてのデータベース

他の講演もありますが、これはあなたを正しい方向に導くでしょう。

大規模および中規模のアプリケーションを作成するとき、アプリケーションのステートフルなセクションとステートレスなセクションを区別すると便利なことがよくあります。

ステートフルセクションのクラス/データ構造は、アプリケーションのデータを格納し、このセクションの関数は、アプリケーションのデータの暗黙的な知識で動作します。

ステートレスセクションのクラス/データ構造/関数は、アプリケーションの純粋なアルゴリズムの側面をサポートするためにあります。アプリケーションのデータに関する暗黙の知識はありません。彼らは純粋に機能的な性質で動作します。アプリケーションのステートフル部分では、アプリケーションのステートレスセクションで関数を実行する副作用として、状態の変化が発生する場合があります。

最も難しいのは、どのクラス/関数をステートレスセクションに配置し、どのクラス/関数をステートフルセクションに配置するかを把握し、それらを別のファイル/ライブラリに配置する規律を持たせることです。