関数型プログラミングは、問題と解決策の間の「代表的なギャップ」を増やしますか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 機械言語（例：）は、0110101000110101一般にコンピューター言語がより高度な抽象化に進化してきたため、一般的に問題に適用されたときにコードを理解しやすくします。アセンブラーはマシンコードの抽象化であり、Cはアセンブラーの抽象化などでした。 オブジェクト指向設計は、オブジェクトの観点から問題をモデル化するのに非常に優れているようです。たとえば、大学の履修登録システムの問題は、Courseクラス、Studentクラスなどでモデル化できます。 OO言語では、責任を負う同様のクラスがあり、一般に設計、特にコードのモジュール化に役立ちます。この問題をOOメソッドで解決する10の独立したチームに与えた場合、通常、10のソリューションには共通して問題に関連するクラスがあります。これらのクラスの結合と相互作用を開始し始めると、多くの違いが生じる可能性があるため、「表現のギャップがゼロ」というものはありません。 関数型プログラミングの私の経験は非常に限られています（実際の使用はなく、Hello Worldタイプのプログラムのみ）。このような言語がOO言語のようにFPソリューションを問題に（低い表現のギャップで）簡単にマッピングできるようにする方法を私は見ていません。 並行プログラミングに関するFPの利点を理解しています。しかし、私は何かを逃していますか、またはFPは表現のギャップを減らすことではありませんか？ これを尋ねる別の方法：同じ現実の問題を解決する10の異なるチームのFPコードには多くの共通点がありますか？ 抽象化に関するウィキペディア（コンピューターサイエンス）から（強調鉱山）： 関数型プログラミング言語は一般に、ラムダ抽象化（用語を変数の関数にする）、高次関数（パラメーターは関数）、ブラケット抽象化（用語を変数の関数にする）など、関数に関連する抽象化を示します。 [一部の]実際の問題はこのような抽象化では簡単にモデル化されないため、表現のギャップは潜在的に拡大する可能性があります。 表現のギャップを減らすもう1つの方法は、ソリューション要素を問題にまでさかのぼることです。0さんと1マシンコードでSは一方で、バックトレースすることは非常に困難であるStudentクラスは、トレースバックに簡単です。すべてのOOクラスが問題空間に簡単にトレースできるわけではありませんが、多くのクラスがトレースしています。 FPの抽象化は、常に彼らが（離れてから解決されている問題空間のどの部分を見つけるために説明する必要はありません数学の問題）？OK-私はこの部分でいいです。さらに多くの例を見ると、FPの抽象化がデータ処理で表現される問題の一部に対して非常に明確であることがわかります。 関連する質問に対する受け入れられた回答UMLは、機能プログラムのモデル化に使用できますか？-「機能プログラマーは、ダイアグラムをあまり使いません」と言います。それがUMLであるかどうかは本当に気にしませんが、広く使用されているダイアグラムがない場合、FPの抽象化が簡単に理解/通信できるかどうか疑問に思います（この答えが正しいと仮定して）。繰り返しになりますが、FPの使用/理解のレベルはささいなものなので、単純なFPプログラムのダイアグラムの必要はないと理解しています。 OOデザインには、機能/クラス/パッケージレベルの抽象化があり、それぞれにカプセル化（アクセス制御、情報隠蔽）があり、複雑さの管理を容易にします。これらは、問題から解決策へと簡単に戻ることができる要素です。 多くの答えは、オブジェクト指向に類似した方法でFPで分析と設計が行われる方法について述べていますが、これまで高レベルのものを引用する人はいません（paulはいくつかの興味深いものを引用しましたが、低レベルです）。昨日はグーグルで多くのことをして、興味深い議論を見つけました。以下は、サイモン・トンプソンによるリファクタリング機能プログラムからのものです（2004）（強調の鉱山） オブジェクト指向システムの設計では、プログラミングよりも設計が優先されることは当然のことです。デザインは、EclipseなどのツールでサポートされているUMLのようなシステムを使用して作成されます。初心者のプログラマーは、BlueJのようなシステムを使用して視覚的な設計アプローチを学ぶことができます。関数型プログラミングのための同様の方法論に関する作業がFAD：Functional Analysis and Designで報告されていますが、他の作業はほとんどありません。これにはいくつかの理由があります。 既存の機能プログラムは、設計を必要としない規模です。多くの機能プログラムは小さいですが、Glasgow Haskell Compilerなどの他のプログラムはかなりのものです。 機能プログラムはアプリケーションドメインを直接モデル化するため、デザインは無関係になります。関数型言語はさまざまな強力な抽象化を提供しますが、これらが現実世界をモデル化するために必要なすべての抽象化のみを提供すると主張することは困難です。 機能プログラムは、進化する一連のプロトタイプとして構築されます。 上記で引用された博士論文では、分析と設計の方法論（ADM）を使用する利点が、パラダイムとは無関係に概説されています。しかし、ADMは実装パラダイムと整合する必要があるという主張がなされています。つまり、OOADMはOOプログラミングに最適であり、FPなどの別のパラダイムにはあまり適用されません。これは、私が表現ギャップと呼ぶものを言い換えていると思う素晴らしい引用です： どのパラダイムがソフトウェア開発に最適なサポートを提供するかについては長々と議論できますが、問題の説明から実装および配信まで単一のパラダイム内にとどまると、最も自然で効率的かつ効果的な開発パッケージを実現できます。 FADが提案する一連の図を次に示します。 実装で使用する関数を関数に提示する関数依存図。 型に同じサービスを提供する型依存図。そして、 システムのモジュールアーキテクチャのビューを表示するモジュール依存関係図。 FAD論文のセクション5.1にはケーススタディがあります。これは、フットボール（サッカー）リーグに関連するデータの生成を自動化するシステムです。要件は100％機能的です。たとえば、サッカーの結果の入力、リーグテーブルの作成、得点表、出欠表、チーム間での選手の移動、新しい結果の後のデータの更新などです。 、「新しい機能は最小限のコストで許可する必要がある」と述べることは別として、テストすることはほぼ不可能です。 悲しいことに、FADを除いて、FP用に提案されているモデリング言語（視覚）の最新の参照はありません。UMLは別のパラダイムなので、それを忘れてください。