FPConfカンファレンスはすでに今週の土曜日に開催されています。すでに160人であり、最後の馬車に乗るのに遅すぎません。 登録はこちらです。
そして前日、私たちはスピーカーにかなり曖昧な質問をすることにしました。 回答を公開します。コメントであなたのオプションを歓迎します！
オブジェクト指向言語には、Gang of Fourの有名なデザインパターンのリストがあります。 関数型言語では、このような既知のリストは存在しません。 あなたの観点から、なぜそうですか？
関数型言語でプログラミングする場合、このようなパターンは必要ありませんか、それともそれらの正規リストがまだ開発されていないというだけですか？
アントン・ホロミエフ、ハスケル
Haskellにはそのようなリストがありますが、別の方法で呼ばれ、他のパターンがあります。
FPのスタイルで。 ここに
セルゲイ・ロビン、スカラ
私の意見では、パターンはキューブとして使用できるFPの原則であり、素晴らしいプログラムを収集します:)
セルゲイ・ティコン、F＃
プログラミング言語のパターンの問題については、「デザインパターンはプログラミング言語に対するバグ報告です」と言ったPeter Norvigに同意します。 従来のGang of Fourパターンが解決した問題のほとんどは、何らかの形の関数型言語ですでに解決されています。 開発されたアプリケーションの複雑さを管理するための一連の一般的なアプローチとして、「機能的パターン/抽象化」があります（たとえば、Monads）。 時間が経つにつれて、私たち全員が標準として認識する一般的なリストが表示される可能性がありますが、これは、関数型言語を解決できるタスクの複雑さの顕著な増加によって引き起こされます。
アレキサンダー・グラニン、ハスケル
質問は私のレポートのトピックと非常に相関しています。 そして、私たちの会議LambdaNskで何度かそれを上げました。
OOPのデザインパターンは、自然な方法では解決できない特定の技術的な問題（言語構文、トップレベルのイディオム、または概念）を解決する人工的な構造です。 パターンの大部分（すべてではないにしても）は、OOPの概念「継承」、「ポリモーフィズム」、「抽象化」で動作しますが、これらの概念もOOP言語の他の特定の構文構成も直接問題を解決しません。 同時に、関数型言語では、これらのパターンは縮退するか（Visitor）または単純に不要になります（Command）-FP自体には問題を直接解決できる概念があります：FWP、ラムダ、パターンマッチング、ファーストクラス関数、不変性、構成、怠lazなど。 たとえば、VisitorはパターンマッチングとFEPに簡単に置き換えられ、Commandは単に第一級の機能です。 OOPでは、パターンはOOP言語自体に固有ではない複雑な構造です。 つまり、問題を解決するには、OOP言語とその要素だけでは不十分です。これらの要素で1つまたは別のメカニズムを構成する必要があります。 そして、多くの同様のメカニズムがOOPパターンにまとめられています。 それどころか、FPでは問題を解決するために、言語構造だけで十分であり、多くの場合、単に関数のタイプを構成するだけで十分です。 型が存在する場合、関数の実装は既に簡単です。
同時に、FIには独自の「パターン」がありますが、私は「イディオム」と呼んでいます。 あなたはそれらについて聞いた：異なるモナド、コモナ、ファンクター、矢印、適用ファンクター、コンビネーター、トランスデューサー。 さらに、AFにはFRP、STM、レンズなどのパターンがあります。 私の意見では、OOPパターンとFPイディオムの違いは何ですか？
OOPパターンは、命令型アプローチによる「外部」の問題の解決策です。 OOPパターンは、エンティティとその変更可能な相互作用に対処します。 OOPパターンは、システムの動作を説明します。 言語にはない機能的なイディオムを実現するためにのみ必要なOOPパターンがあります（VisitorはサンプルおよびFVPとの比較です）。
FPイディオムは、機能宣言的アプローチによる「内部から」の問題の解決策です。 FP-idiomは、プロパティとその不安定な変換に対処します。 FPイディオムは、エンティティが何であるか、その不可分なプロパティが何であるかを説明します。
私たちはどんな特性について話しているのですか？ たとえば、機能的なリストがある場合、それは最初は、それを知らなくてもモナドです。 ゲーム「Life」をお持ちの場合、そのセルフィールドはすでにチームです。 ちなみに、FPプログラマーは問題の解決策を構築するだけでなく、隠された特性、サブジェクトエリアのプロパティを検索し、この知識に基づいて1つまたは別のFPイディオムを使用して問題を解決します。 そのようなコード-プロパティと変換に基づいて構築-は、慣用的な機能コードになります。
しかし、関数型言語で大規模なアプリケーションを設計するというトピックは、もちろん、これらの言語の普及率が低いことを考えると、まだ十分に理解されていません。 したがって、文献はほとんどありません。 私のレポートでは、この重要な問題を提起するだけです。
関連リンク
* FPはGOFパターンを置き換えますか？
* Haskellのデザインパターン
* FPデザインパターン
* 慣用的な機能コード（LambdaNskでのスピーチからのプレゼンテーション）
* HaskellおよびFPのイディオム： 1および2
デニス・レドズボフ、ハスケル
前の回答に+1。
ニコライ・リジコフ、Clojure
すべてのGOFパターンが同じというわけではありません。 いくつかは低すぎます-例えば、イテレーター。 FPには、マップ、リデュース/フォールド、ウォーカーなどのタスク用の独自の（より表現力豊かな）武器庫があります。 モナド、ジッパー、トランスデューサーなど、非常に機能的な低レベルのテンプレートも多数あります。
ただし、テンプレートの重要な部分は、経験豊富なプログラマーが大規模にプログラムを構造化して説明するのに有用で理解しやすい高レベルの構造です。 また、FPで使用することもできますが、元の実装とはわずかに異なる場合もあります。
たとえば、機能の装飾としてHOFを介してChain of Responsibilityを表現できます（アクセシビリティにはjsを使用します:)：
function handler1(next_handler) { return function(args){ if (exp){ // some logic next_handler(args); //pipe to next handler } else { return some_responce; //intercept } } } var stack = handler1(handler2(handler3)) // build chain (stack) stack(args); // process chain
したがって、FPのデザインパターンを再リリースする必要があると思います。 この本を書くのはあなたかもしれません:)
ニキータ・プロコポフ、Clojure
パターンはそこにあります。 OOP言語は次のことを示します。オブジェクトがあり、必要なことを行います。 自由ですが、建設的ではありません。 パターンは、「そのようなスキームに従ってオブジェクトを構築する場合、そのような目的のために使用できます」です。 コンクリート化。
したがって、FP言語にパターンを無効にするいくつかの特別なプロパティがあるとは限りません。 パターンは、頻繁に遭遇する「コード形式」の単なる分類子です。 オブジェクトがないため、GoFからの特定のOOPパターンは必要ありません。 ただし、FPパターンが必要です。 どういうわけか彼らはFPコードを書くのですが、一人一人がユニークなわけではありません。
よく知られているリストはありません。誰もまだコンパイルしていないからです。 非公式には、単に暗黙的に送信されるだけです。 さらに、少なくとも型付きFPと型なしの言語では、言語によって大きく異なる可能性があります。
型付きの場合、パターンの必要性が高くなることをお勧めします。 特定の問題を回避するために、タイプを「ラップ」する方法に関するレシピが必要です。 そのようなレシピは非常にすぐに重要なものになり、心でそれらに到達することはますます難しくなっています。 そのため、教育の観点からは、「型付きAFパターン」が非常に人気があります。
ミハイル・リマンスキー、スカラ
私たちは職人ではなく創造的な人間なので、機能主義者はパターンを必要としません。
しかし真剣に、OOPでは、パターンはオブジェクトモデル自体の複雑さによって生成されます。 カプセル化、継承、およびポリモーフィズムだけがありますが、使用方法の言語には組み込みの意味はありません。 つまり OOP言語と概念の知識は、自分の足を撃たず、コードを狂った混乱に変えないほど十分ではありません。 このためには、パターンが必要です（パターンが役に立たないときにリファクタリング領域が救助に来るとき）。
それどころか、FPでは、振る舞いから-すでに言語の一部である型クラスから。 プログラミングのための特定のUnixの方法が判明しました-小さな型クラスは1つの小さな問題を解決し、それをうまく行います。
Arseny Zhizhelev、Scala
4人のギャングは、当時存在していたパターンのリストを「杭打ち」し、普遍的で広く適用できるように見えました。 時間が経つにつれて、新しいパターンが出現し、古いパターンに欠陥が出現しました（たとえば、依存関係の注入がファクトリーに置き換わりました）。
前述のように、関数型言語にも優れたプラクティスのセットがありますが、そのうちの1つだけがまだ広く知られ普及しているわけではありません。 これにより、この新しいアプローチとそれらを実装するライブラリのリストに含める可能性が広がります。 関数型言語を使用する興味深い方法の1つは、Scalaで関数型リアクティブプログラミングアプローチを実装するSynapseGridライブラリに関する私の講演で説明します。
UPD。 午前中、エドワードから返答を受け取り、 別の投稿で公開することにしました。
他の参加者および会議のスピーカーからの更新はコメントにあります。 FPConfでお会いしましょう！