関数型プログラミングの支持者は、Code Completeでこのステートメントにどのように答えますか？

Steve McConnellは、第2版の839ページで、プログラマーが大きなプログラムで「複雑さを克服する」ためのすべての方法について議論しています。彼のヒントは次のステートメントで終わります。

「オブジェクト指向プログラミングは、アルゴリズムとデータに同時に適用される抽象化のレベルを提供します。これは、機能分解だけでは提供されない一種の抽象化です。」

「複雑さを軽減することは、間違いなく効果的なプログラマーになるための最も重要な鍵」（同じページ）という彼の結論と相まって、これは関数型プログラミングへのほとんどの挑戦のようです。

FPとOOの間の議論は、並行性または並列化の課題に特に由来する複雑性の問題に関するFPの支持者によってしばしばフレーム化されます。ただし、ソフトウェアプログラマが克服する必要があるのは、同時性だけではありません。おそらく、ある種の複雑さを減らすことに焦点を合わせると、他の次元では大幅に増加するため、多くの場合、ゲインはコストに見合うものではありません。

FPとOOの比較の条件を、並行性や再利用性などの特定の問題からグローバルな複雑さの管理にシフトした場合、その議論はどのように見えるでしょうか？

編集

私が強調したかったのは、オブジェクト指向はデータとアルゴリズムの両方の複雑さをカプセル化して抽象化しているように見えますが、関数型プログラミングはデータ構造の実装の詳細をプログラム全体に「公開」することを奨励しているようです。

たとえば、ここで「データ型の過剰な指定」は「慣用的なOOスタイルの否定的な結果」であり、AddressBookをより豊富なOOオブジェクトではなく単純なベクトルまたはマップとして概念化することを推奨するStuart Halloway（Clojure FP支持者）を参照してください追加の（非ベクター的かつ非マップ的）プロパティとメソッドがあります。（また、オブジェクト指向およびドメイン駆動設計の支持者は、AddressBookをベクトルまたはマップとして公開すると、カプセル化されたデータがドメインの観点からは無関係または危険なメソッドに過度に露出されると言うかもしれません）。

この本は20年以上にわたって書かれたものであることを忘れないでください。当時のプロのプログラマーにとって、FPは存在しませんでした-それは完全に学者と研究者の領域にありました。

作業の適切なコンテキストで「機能分解」を組み立てる必要があります。著者は関数型プログラミングについて言及していません。これを「構造化プログラミング」とGOTOそれ以前の混乱に結び付ける必要があります。参照点が関数を持たない古いFORTRAN / COBOL / BASICであり（幸運にも単一レベルのGOSUBを取得できた場合）、すべての変数がグローバルであり、プログラムを分解できる場合機能の層への大きな恩恵です。

OOPは、この種の「機能の分解」をさらに改良したものです。命令を関数にまとめることができるだけでなく、関連する関数を作業中のデータでグループ化できます。その結果、明確に定義されたコードの一部が得られ、コードベース全体を追ってデータを操作する可能性のあるものを見つける必要なく、（理想的には）見て理解することができます。

関数型プログラミングの支持者は、ほとんどのFP言語が「関数分解のみ」よりも抽象化の手段を提供すると主張し、実際にオブジェクト指向言語のそれに匹敵する抽象化の手段を許可すると想像するでしょう。たとえば、そのような抽象化の手段として、Haskellの型クラスまたはMLの高階モジュールを引用できます。したがって、ステートメント（関数型プログラミングではなく、オブジェクト指向と手続き型プログラミングに関するものであると確信しています）は、それらには適用されません。

FPとOOPは直交する概念であり、相互に排他的ではないことも指摘する必要があります。したがって、それらを互いに比較することは意味がありません。「命令型OOP」（Javaなど）と「機能的OOP」（Scalaなど）を非常によく比較できますが、引用した文はその比較には適用されません。

関数型プログラミングは、複雑さを管理するのに非常に役立ちます。ただし、複雑さは別の方法で考える傾向があり、複雑さをOOPの意味でのカプセル化ではなく、さまざまなレベルで不変データに作用する関数として定義します。

たとえば、最近Clojureでゲームを作成し、ゲームの状態全体を単一の不変のデータ構造で定義しました。

(def starting-game-state {:map ....
                          :player ....
                          :weather ....
                          :other-stuff ....}

また、ゲームのメインループは、ループ内のゲームの状態にいくつかの純粋な関数を適用することで定義できます。

 (loop [initial-state starting-game-state]
   (let [user-input (get-user-input)
         game-state (update-game initial-state user-input)]
     (draw-screen game-state)
     (if-not (game-ended? game-state) (recur game-state))))

呼び出される主要な関数はでupdate-game、これは以前のゲーム状態とユーザー入力を指定してシミュレーションステップを実行し、新しいゲーム状態を返します。

では、複雑さはどこにあるのでしょうか？私の見解では、それは非常にうまく管理されています。

• 確かに、ゲームの更新機能は多くの作業を行いますが、それ自体は他の機能を構成することによって構築されるため、実際には非常に単純です。いくつかレベルを下げても、関数はまだ非常に単純で、「マップタイルにオブジェクトを追加する」などの操作を行います。
• 確かに、ゲームの状態はビッグデータ構造です。ただし、これも下位レベルのデータ構造を構成することで構築されただけです。また、メソッドが埋め込まれているのではなく「純粋なデータ」であり、クラス定義が必要なため（必要に応じて、非常に効率的な不変のJSONオブジェクトと考えることができます）、ボイラープレートはほとんどありません。

OOPはカプセル化によって複雑さを管理することもできますが、これをOOPと比較すると、機能にはいくつかの非常に大きな利点があります。

• ゲーム状態データ構造は不変であるため、多くの処理を簡単に並行して実行できます。たとえば、ゲームロジックとは異なるスレッドで描画画面を呼び出すレンダリングを行うことは完全に安全です。互いに影響を与えたり、一貫性のない状態を確認したりすることはできません。大きな可変オブジェクトグラフでは、これは驚くほど難しい......
• ゲームの状態のスナップショットはいつでも取得できます。リプレイは簡単です（Clojureの永続的なデータ構造のおかげで、ほとんどのデータが共有されているため、コピーはほとんどメモリを占有しません）。また、更新ゲームを実行して「未来を予測」し、AIがさまざまな動きを評価できるようにすることもできます。
• 厳格なクラス階層を定義するなど、OOPパラダイムに適合するために難しいトレードオフを行う必要はありませんでした。この意味で、機能データ構造は、柔軟なプロトタイプベースのシステムのように動作します。

最後に、関数型言語とOOP言語の複雑さを管理する方法についてより多くの洞察に興味がある人のために、Rich Hickeyの基調講演Simple Made Easyのビデオを再編集します（Strange Loopテクノロジー会議で撮影）

「オブジェクト指向プログラミングは、アルゴリズムとデータに同時に適用される抽象化のレベルを提供します。これは、機能分解だけでは提供されなかった一種の抽象化です。」

機能分解だけでは、アルゴリズムやプログラムを作成するには不十分です。データも表現する必要があります。上記のステートメントは、機能的なケースの「データ」が最も初歩的な種類であると暗黙的に仮定している（または少なくとも理解できるようになっている）と考えています。そのような言語でのプログラミングは明らかにあまり便利ではありません。ただし、Clojureなどの多くの、特に新しくて現代的な機能（またはマルチパラダイム）言語は、リストだけでなく、文字列、ベクター、マップとセット、レコード、構造体、オブジェクトなどの豊富なデータ構造を提供します！-メタデータとポリモーフィズム。

オブジェクト指向の抽象化の大きな実用的な成功は、ほとんど議論の余地がありません。しかし、それは最後の言葉ですか？あなたが書いたように、並行性の問題はすでに大きな痛みであり、古典的なオブジェクト指向には並行性の考えがまったくありません。その結果、同時実行性を処理するための事実上のオブジェクト指向ソリューションは単にダクトテープを重ね合わせただけです：動作しますが、簡単に台無しになり、手元の重要なタスクからかなりの量の脳資源を奪い、うまくスケールしません。たぶん、多くの世界のベストをとることが可能です。それが現代のマルチパラダイム言語が追求していることです。

可変状態は、プログラミングとソフトウェア/システム設計に関連するほとんどの複雑さと問題の根源です。

OOは可変状態を採用しています。FPは可変状態を嫌います。

OOとFPの両方に用途とスイートスポットがあります。賢明に選択してください。「クロージャーは貧乏人のオブジェクトです。オブジェクトは貧乏人の閉鎖です。」という格言を思い出してください。

関数型プログラミングはオブジェクトを持つことができますが、それらのオブジェクトは不変である傾向があります。純粋な関数（副作用のない関数）は、それらのデータ構造で動作します。オブジェクト指向プログラミング言語で不変オブジェクトを作成することは可能ですが、それを行うように設計されていなかったため、使用される傾向がありません。これにより、オブジェクト指向プログラムについて推論することが難しくなります。

非常に簡単な例を見てみましょう。OracleがJava Stringsにリバースメソッドを持たせることを決定し、次のコードを記述したとしましょう。

String x = "abc";
StringBuffer y = new StringBuffer(x);
y.reverse();
x.reverse();
x.toString().equals(y.toString());

最後の行は何に評価されますか？これがfalseと評価されることを知るには、Stringクラスの特別な知識が必要です。

独自のクラスWuHoStringを作成した場合

String x = "abc";
WuHoString y = new WuHoString(x);
y.reverse();
x.reverse();
x.toString().equals(y.toString())

最後の行がどのように評価されるかを知ることは不可能です。

関数型プログラミングスタイルでは、次のように記述されます。

String x;
equals(toString(reverse(x)), toString(reverse(WuHoString(x))))

そしてそれは真実であるべきです。

最も基本的なクラスの1つの関数の推論が非常に困難な場合、この可変オブジェクトの概念を導入することで複雑さが増したか減ったかどうか疑問に思います。

明らかに、オブジェクト指向を構成するもの、機能的であることの意味、および両方を持つことの意味についてのあらゆる種類の定義があります。私にとっては、ファーストクラスの関数のようなものは持っていないが、他の言語はそれのために作られている言語で「関数型プログラミングスタイル」を持つことができます。

ほとんどの場合、古典的なOOP抽象化では同時実行の複雑さはカバーされないと思います。したがって、OOPは（本来の意味では）FPを除外しません。そのため、scalaのようなものが表示されます。

答えは言語によって異なります。たとえば、Lispには、コードがデータであるという本当にきちんとしたものがあります。あなたが書くアルゴリズムは、実際には単なるLispリストです！プログラムを作成するのと同じ方法でデータを保存します。この抽象化は、OOPよりも簡単かつ徹底的であり、いくつかの本当にすてきなことを実行できます（マクロをチェックアウトします）。

Haskell（および私が想像する同様の言語）には、完全に異なる答えがあります：代数的データ型。代数データ型はC構造体に似ていますが、より多くのオプションがあります。これらのデータ型は、データのモデル化に必要な抽象化を提供します。関数は、アルゴリズムのモデル化に必要な抽象化を提供します。型クラスおよびその他の高度な機能は、両方に対してさらに高いレベルの抽象化を提供します。

たとえば、楽しみのためにTPLと呼ばれるプログラミング言語に取り組んでいます。代数的データ型は、それが作る本当に簡単な値を表すために：

data TPLValue = Null
              | Number Integer
              | String String
              | List [TPLValue]
              | Function [TPLValue] TPLValue
              -- There's more in the real code...

これが何を言う-非常に視覚的な方法では- TPLValue（私の言語の任意の値）ができることであるNullかNumberとのInteger値、あるいはFunction値のリスト（パラメータ）と最終値（ボディを持ちます）。

次に、型クラスを使用して、一般的な動作をエンコードできます。例えば、私が作ることができるTPLValueのとインスタンスShow、それは文字列に変換できることを意味しています。

さらに、特定の型（自分で実装しなかった型を含む）の動作を指定する必要がある場合は、独自の型クラスを使用できます。たとえば、適切な通常の値を取得して返すExtractable関数を作成できる型クラスがありますTPLValue。こうしてextract変換することができるNumberにIntegerまたはStringにString限りようにIntegerとStringのインスタンスですExtractable。

最後に、私のプログラムのメインロジックは、evalやなどのいくつかの関数にありapplyます。これらは本当にコアです-それらはTPLValues を取り、それらをさらにTPLValuesに変換し、状態とエラーを処理します。

全体として、Haskellコードで使用している抽象化は、実際にはOOP言語で使用したものよりも強力です。

私が見る限り、引用された文はもはや妥当性を持ちません。

現代のオブジェクト指向言語は、種類が*ではない型を抽象化できません。つまり、より高い種類の型は不明です。それらの型システムは、「Int要素を持つコンテナ、つまり要素に関数をマッピングできるコンテナ」という概念を表現できません。

したがって、Haskellsのようなこの基本関数

fmap :: Functor f => (a -> b) -> f a -> f b 

Java *で簡単に書くことはできません）、たとえば、少なくとも型安全な方法ではありません。したがって、基本的な機能を取得するには、多くの定型文を作成する必要があります。

1. リストの要素に単純な関数を適用する方法
2. 同じ単純な関数を配列の要素に適用する方法
3. 同じ単純な関数をハッシュの値に適用する方法、
4. ....セット
5. .... 木
6. ... 10.同じための単体テスト

それでも、これらの5つのメソッドは基本的に同じコードであり、いくつかの方法があります。対照的に、Haskellでは、次のものが必要です。

1. リスト、配列、マップ、セット、ツリーのFunctorインスタンス（ほとんどが事前に定義されているか、コンパイラーによって自動的に派生できます）
2. シンプルな機能

これはJava 8では変更されないことに注意してください（関数をより簡単に適用できますが、正確に上記の問題が発生します。高次関数さえない限り、ほとんどの場合、より高い種類の種類が何に適しているかを理解できます。）

Ceylonのような新しいオブジェクト指向言語でさえ、より高い種類の種類はありません。（私は最近ギャビン・キングに尋ねました、そして、彼は私に言った、それは現時点では重要ではありませんでした。）しかし、コトリンについて知りません。

*）公平を期すために、メソッドfmapを持つインターフェイスFunctorを持つことができます。悪いことは、あなたが言うことはできません：ねえ、私はライブラリクラスSuperConcurrentBlockedDoublyLinkedDequeHasMap、fearコンパイラにfmapを実装する方法を知っています。

dBaseでプログラミングしたことがある人なら誰でも、単一行マクロが再利用可能なコードを作成するのにどれほど役立つか知っているでしょう。私はLispでプログラミングしたことはありませんが、コンパイル時マクロを誓う他の多くの人から読みました。コンパイル時にコードをコードに挿入するという考え方は、すべてのCプログラムで「include」ディレクティブを使用して単純な形式で使用されます。LispはLispプログラムでこれを行うことができ、Lispは非常に反射的であるため、より柔軟なインクルードが得られます。

Webから任意のテキスト文字列を取得してデータベースに渡すプログラマーは、プログラマーではありません。同様に、「ユーザー」データが自動的に実行可能コードになることを許可する人は誰でも、明らかに愚かです。これは、プログラムが実行時にデータを操作し、それをコードとして実行できるようにすることが悪い考えであることを意味しません。私は、この技術が将来不可欠であり、実際にほとんどのプログラムを作成する「スマート」コードを持つと信じています。「データ/コードの問題」全体かどうかは、言語のセキュリティの問題です。

ほとんどの言語の問題の1つは、1人のオフラインの人が自分でいくつかの機能を実行するために作成されたということです。現実世界のプログラムでは、多くの人が複数のコアと複数のコンピュータークラスターから常に同時にアクセスできる必要があります。セキュリティはオペレーティングシステムではなく言語の一部である必要があり、そう遠くない将来になります。