オブジェクト指向プログラミングのパラダイムは、反モジュラーおよび反並列であるため、時代遅れですか？[閉まっている]

CMUの教授であるRobert Harperが投稿した論争の的となっている記事Teaching FPを新入生に読みました。彼は、CMUが「最新のCSカリキュラムには適さない」ため、入門コースでオブジェクト指向プログラミングを教えることはもはやないと主張しました。

そして彼はそれを主張した：

オブジェクト指向プログラミングは、その性質上、反モジュラーかつ反平行であるため、導入カリキュラムから完全に排除されます。

OOPを反モジュラーおよび反並列と見なす理由

入門的なCSカリキュラムクラスを教えるためのハーパーのニーズは、実際のプロジェクトのニーズとは非常に異なることを考慮してください。彼の仕事は、基本概念（モジュール性、並列性、帰納法など）を新入生に教えることです。そのため、選択された言語（およびパラダイム）がこれらの概念をできるだけ少ない式（構文および概念）で表現できることが非常に重要です。このコンテキストでは、親しみやすさ、ツールサポート、利用可能なライブラリ、実行パフォーマンスなどはまったく関係ありません。次のことを考慮するときは、このことに留意してください...

OOが反モジュラーであるという見解は、適切に設計されたクラスのオブジェクトでさえ、最終的には他のクラスへの多数の依存関係に起因します。OOの支持者の目から見ても、これが問題であることは、過去数年間のDependency Injectionフレームワーク、記事、書籍、ブログ投稿の急増を見れば明らかになります（モックやスタブの増加も興味深いです）。

別のヒントは、デザインパターンの重要性とそれらを実装する複雑さです。他のプログラミングパラダイムと比較して、たとえばファクトリー、ビルダー、アダプター、ブリッジ、デコレーター、ファサード、コマンド、イテレーター、メディエーター、オブザーバー、ストラテジー、テンプレートメソッドなどです。 Compositeは、OOコードのモジュール性の改善に何らかの形で関連しています。

継承にも問題がある（例えば壊れやすい基本クラスの問題）と（サブタイプ）多型誘惑は1への変更が全体の継承チェーンに波及することができ、複数のクラス間のアルゴリズムの実装までこぼした（アップとダウンを！）。

反平行であることの責任は、計算と比較した状態の強調に関連しています（別名、可変性対不変性）。前者は、状態が管理されている場所（別名、インスタンス変数が宣言されているファイル）から通常推論できないため、サブ計算の依存関係を表現することをより複雑にします（これはHarperの並列処理です！）どの時点でそれを変更します。

状態管理がなく、サブ計算の依存関係を表現したい場所で結合される関数/計算だけであるため、不変性と計算に重点を置くと、サブ計算の依存関係をはるかに簡単に表現できます。

これはおそらく大胆な主張ですが、私はどういうわけか、このロバート・ハーパーは実際に彼の人生で実際のソフトウェアを書いたことはありません。彼が関心を持っているのはMLと静的型システムだけです。それはおそらく大きな貢献かもしれませんが、OOPについての彼の主張がどのように関連性を持っているのかわかりません。

この記事は議論の余地はありません。論争には、試験、議論、議論が含まれます。あなたがここにいるのは、議論を提供することなく、たった1つの声明で2つの非常に基本的な告発を出す無知な学者です。

1. OOPが反モジュラーであるという主張は、まったくナンセンスです。私も、それにだけでなく、引数はありませんし、応答する方法を知らないだけでなく、デザインによってOOPがあるカプセル化と抽象化の手段を通じて個々のモジュール間の非常に低いのカップリングとモジュール性を確立するためのアプローチが。

2. OOPが反平行であると主張することは、単に理解不足を示しています。OOPは、並行性に関する決定をロックしません。OOPはそれらを隠すように指示するだけです。適切に構築された場合、オブジェクトの実装が並列であるかどうかを言うことはできません。
   したがって、最終的にOOPと並列プログラミングは直交します。アクターモデルは、同時実行のエレガントなモデルであり、オブジェクトシステムに直接反映することができます（そうする必要はありません）。

OOPの問題は、Alan Kayが定義したという意味で実際に理解している人はほとんどいないということです。

1. OOPはアプローチです。一部の言語ではパターンを使用して実装され、他の言語では組み込み言語のイディオム（Ruby、Objective-C、Smalltalk、Ioなど）を直接使用できます。
2. 一般的な信念に反して、OOPはクラスに関するものではありません。オブジェクトについてであり、オブジェクトはメッセージの受け渡し、またはカプセル化と抽象化の同様に漏れのない方法についてです。

JavaがOOPに向けられているのは、尖った棒が海戦に向けられている理由です。これは他の多くのいわゆる「OOP言語」にも当てはまりますが、Javaについてのことは、JavaがOOPを教えるために使用されるべきであるという、大学での一般的な信念のようです。

Javaを使用したOOPの紹介をCSカリキュラムから削除すべきだと考えるすべての人々に同意します。また、OOPの基本的な理解を明らかに欠いている人は教えるべきではないと思います。したがって、ボブが自分のコースでMLに固執し、彼がしっかりと理解していることを単に教えるなら、おそらくより良いでしょう。
現在、OOPはよりファッショナブルなエチケットであり、人々はすべてにこだわることを好みます。これはOOPに害を及ぼし、人々に言われました。OOPは時代遅れではありません。人々は最終的に、それはそれが何であるかについては何かを理解するときOOPの黄金時代は、まだ来ていないですない程度（例えばキーワード使用して可能なすべての問題を解決するclass500回）。

すべてのストライプの熱狂者を取得します。

オブジェクト指向プログラミングは特効薬ではありません。それはなかった。それは、誇大広告の被害者です。必然的に、人々は誇大宣伝にうんざりし、（パラダイムの実際の有用性に関係なく）バックラッシュが発生し始めます。

20年後、間違いなく関数型プログラミングに対して他の反発があるでしょう。

著者の漠然とした考えを2番目にしか推測できないため、この質問に完全に答えることはできません。私は、この記事が著者に何らかの恥ずかしさを引き起こそうとしていることを強く疑っています。OOPにはモジュール式でも並列式でもないことを示唆するものはありません。

モジュール性：OOPの主要な側面は、実際にモジュール式であるということです（ただし、モジュール性は異なるコンテキストで異なることを意味します）。したがって、著者が一般化と静的プログラミングのどちらについて話しているかに関係なく、彼は間違っています。

並列化：並列プログラミングに関しては、ほとんどのフレームワークは、interupts then threadingをサポートしており、.Net framework 4.0で見られるような適切な並列化と、それに対応するOOP言語をサポートしています。

私は、関数型プログラミングとOOPが相互に排他的に使用されているという誤解があるという点で、著者がファッションの犠牲者になったのではないかと考えています。OOP言語には、文書化された機能的なスタイルがあります。たとえば、Oliver Sturmはこの分野で公開しています。

著者は、OOPは新入生のプログラマーにとって理解するのが難しすぎると主張しています。反モジュラーおよび反並列ステートメントは、純粋に関数型の言語と比較した場合、狭いコンテキストでは正しいかもしれませんが、パラダイム全体を非難することはほとんどありません（使用方法を知っている人にとってはうまくいくようです）。

提案されたカリキュラムは、あるクラスの機能プログラミング、別のクラスの命令型（手続き型）プログラミング、および別のクラスのデータ構造を教えます。新入生がこれらの3つのことをマスターしたら、彼/彼女はOOPを学ぶ準備ができているはずです。

個人的にはそれはやり過ぎだと思いますが、学者は新しい極端なことを試してみたいです。カウンターバランスとして、MITは1つの新入生クラスですべての主要なプログラミングパラダイムを教えていました（そして今でもそうかもしれません）。

奇妙なことに、どちらの学校も優れたプログラマーを輩出しています。図を移動します。