多くのアヒル型動的プログラミング言語が、プロトタイプベースのOOPではなくクラスベースのアプローチを使用するのはなぜですか？

23

非常に多くの動的プログラミング言語にはダックタイピングの機能があり、クラスやインスタンスのメソッドをいつでも開いて変更できるため（RubyやPythonなど）、...

質問1）動的言語のクラスの必要性は何ですか？プロトタイプ言語ではなくオブジェクトを使用するのではなく、クラスを何らかの「テンプレート」として使用するように言語が設計されているのはなぜですか？

また、JavaScriptはプロトタイプベースですが、CoffeeScript（JavaScriptの拡張バージョン）はクラスベースの方法を選択します。また、Lua（プロトタイプベース）とMoonScript（クラスベース）でも同じです。さらに、ES 6にはクラスがあります。

質問2）特にプロトタイプベースの言語を改善しようとする場合、クラスベースに変更する必要があることを示唆していますか？そうでない場合、なぜそのように設計されているのですか？

— iceX
ソース

9

多くのプログラマーは、何か新しいことを学ぶことに煩わされたくありません。（あまりにも異質で「難しい」）。したがって、それらにコンパイルされるすべてのクラスベースのライブラリと言語。

— トーマスエディング

1

私はトーマスに同意しますが、おもしろいのは、動的なアプローチを学んだ後、実際に簡単になることです（難しくはありません）。オブジェクトの概念はまだ存在します。最初にいくつかの愚かな「青写真」を再コンパイルせずにオブジェクトを変更できるというだけです。5番目の脚を椅子に置きたい場合、最初に設計図を変更する必要はありません。脚を追加するだけです。私の意見では、動的言語は現実をより密接にモデル化します。

— ロニーベスト

1

OOPは、型を宣言する必要がある静的に型付けされたコンテキストで発明されました。そこでは、クラスはレコードとモジュールからの賢明な前進です。プロトタイプベースのOOPは、Self言語の興味深い研究トピックに過ぎず、本質的に機能的な言語の「OOP」の流行語をチェックする最も簡単な方法として、JavaScriptに組み込まれました。良い点は、プロトタイプの上にクラスを実装できることです。私はメタオブジェクトが好きですが、クラスをインスタンスから分離することにより、適切にファクタリングされたシンプルで疎結合のコードを簡単に記述できます。

— アモン

3

まず最初に：JavaScript自体classは、次のECMAScript標準（ECMAScript 6）でキーワードをサポートします。JavaScriptのクラスのサポートは長い間計画されています。さて、クラスは単なる構文上の砂糖であり、同じ型のオブジェクトのモデルについて推論するのは簡単です。JSではこのようになり、Pythonや他の動的言語ではこのようになります。

— ベンジャミングリュンバウム

1

@BenjaminGruenbaum "...クラスは単なる構文上の砂糖..."うわー、これは私にとって非常に斬新なアイデアです。実際、RubyやPythonなどの言語では、オブジェクトを使用するかテンプレートとしてのクラス—どちらもとにかくその場で修正できます。また、継承をどのように処理するかは重要ではありません。そのため、動的言語のクラスベースのアプローチとプロトタイプベースのアプローチを区別する必要はないかもしれません:)

— iceX

12

質問1）動的言語のクラスの必要性は何ですか？プロトタイプ言語ではなくオブジェクトを使用するのではなく、クラスを何らかの「テンプレート」として使用するように言語が設計されているのはなぜですか？

最初のオブジェクト指向言語（「OO」とは呼ばれませんでしたが）、Simulaには継承がありませんでした。Simula-67で継承が追加され、クラスに基づいていました。

同じ頃、アランケイは新しいプログラミングパラダイムのアイデアに取り組み始めました。これは後に「オブジェクト指向」と名付けられました。彼は継承が本当に好きで、自分の言語でそれを持ちたいと思っていましたが、クラスも本当に嫌いでした。しかし、彼はクラスなしで継承する方法を思い付くことができなかったので、彼は継承を好むよりもクラスを嫌うことを決定し、Smalltalkの最初のバージョン、Smalltalk-72をクラスなしで、したがって継承なしで設計しました。

数か月後、Dan Ingallsはクラスの設計を思い付きました。クラス自体はオブジェクト、つまりメタクラスのインスタンスでした。Alan Kayは、この設計が古いものよりもやや弱いことを発見したため、Smalltalk-74はクラスとクラスに基づく継承を使用して設計されました。

Smalltalk-74の後、Alan Kayは、Smalltalkが間違った方向に動いており、実際にはOOが何であるかを表していないと感じ、チームがSmalltalkを放棄して新たに始めたと提案しましたが、彼は献身的でした。したがって、Smalltalk-76、Smalltalk-80（研究者にリリースされるSmalltalkの最初のバージョン）、Smalltalk-80 V2.0（商業的にリリースされる最初のバージョン、およびANSI Smalltalkの基礎となったバージョン）に続きました。。

Simula-67とSmalltalk-80はすべてのOO言語の祖父母と見なされているため、その後のほとんどすべての言語は、クラスとクラスに基づく継承の設計を盲目的にコピーしました。数年後、クラスの代わりにミックスインに基づいた継承、クラスに基づいた継承の代わりにオブジェクトに基づいた委任などの他のアイデアが表面化したとき、クラスベースの継承はすでに定着しすぎていました。

興味深いことに、アランケイの現在の言語はプロトタイプの委任に基づいています。

— ヨルグ・W・ミッターク
ソース

「...アラン・ケイの現在の言語...」これは...？

— ハビエル

@Javier：名前はないと思います。システムの名前は変わり続けています。

— ヨルグWミットタグ

これは、誰かがオブジェクト指向の要件として継承をリストする次回を指す良い答えになるはずです:)

— ちょっと

1

@iceX：Alan Kayは、彼のアイデアに取り組むためにViewpoints Research Instituteを設立しました。残念ながら、情報は本当にウェブサイトに散らばっています。

— ヨルグWミットタグ

3

OOに関するAlan Kayの引用：「私にとってのOOPとは、メッセージ、ローカル保持と状態プロセスの保護と隠蔽、すべてのものの極端な遅延バインディングのみを意味します。SmalltalkとLISPで実行できます。これは可能ですが、私はそれらを知りません。」

— ジョーリセブレヒト

23

多くのプログラマーは、クラスを使用することを好みます。これは非常にわかりやすい概念であり、世界に関する人間の思考プロセスの優れたモデルです（つまり、本物のオブジェクトを、それらが属すると考えるアイテムの抽象的なグループに本能的に関連付けます。これがクラスです）。また、クラスはオブジェクト型についての推論を容易にします。クラスベースの言語では、リスコフ置換のような原則の適用は、異なるメソッドを持つオブジェクトや実行時に型が変わるオブジェクトだけがある言語よりも簡単です。、JavaScriptの場合のように。

JavaScriptでさえ、非常に多くのコードが単純にプロトタイプ機能を使用してクラスをエミュレートすることに注意してください。これは主に、多くのプログラマーがそのように考えることを好むためです。

クラスベースの言語が好まれるもう1つの理由もあります。効率的なコードにコンパイルするのが簡単です。最も効率的なJavaScript VMは、メソッドとプロトタイプの変更に応じてJavaScriptオブジェクトのタイプを表すクラスを効果的に動的に作成します。これが行われる理由の根拠については、V8の実装に関するこの説明を参照してください。

— ジュール
ソース

4

あなたの最後の段落は実際にあなたが言っていることの正反対をサポートします：V8はあなたが効率的なクラスベースのコードにコンパイルするために言語のクラスを必要としないことを証明します。

— ヨルグWミットタグ

4

はい、あなたはそれらを必要としません-しかし、V8（そしておそらく私はそのシステムの設計についてはあまり読んでいませんがおそらくSelf）が事実上仮想クラスを作成するという事実は、ネイティブにクラスを使用する言語から始めることを意味します確かに簡単であり、したがって、おそらくJITがコードのコンパイルに費やす時間を削減する必要があります。

— ジュール

11

確かに、V8がGOTOsとregisterを効果的に作成するという事実は、すべての抽象化をあきらめてアセンブリに直接書き込むことはほぼ確実に簡単であることを意味します。高レベルの抽象化をサポートするのはコンパイラの仕事です。

— ヨルグWミットタグ

1

はい。しかし、特にAOTコンパイラではなくJITを使用する場合、高レベルの抽象化はほとんどの場合実装が難しく、実行時のパフォーマンスが低下するため、トレードオフです。多くの言語設計者は、これらの理由の一方または両方のためにクラスベースの構造を選択していると思われます。それが、私が取り組んでいる（そうでなければ動的な）言語の固定メンバーを持つクラスを選んだ理由だと知っていますが、他の言語について推測することしかできません。

— ジュール

1

私は、プログラマが「クラスで考える」ことを好む唯一の方法は、それが私たちのほとんどが教えられる方法だからだと主張します。しかし、大学の仲間の学生の多くは、数年前から非常に基本的なオブジェクト指向の概念を把握して理解するのに苦労していたことを間違いなく覚えています。それは後知恵で明らかで簡単に思えます。

— KChaloux

3

人々のチームが同じコードで共同作業している大きなプロジェクトでは、柔軟な言語（実行時にオブジェクトのプロパティとメソッドを変更できる）は、他のチームメンバーがあなたに望んでいない自由だと聞いたことがあります持つ。

彼らは、オブジェクトを扱っているときに、オブジェクトが青写真が言っているように動作することを知りたいと思っています。

だから、誰かがこれらの素晴らしい動的言語によって提供される柔軟性を望まないだろうと私が考えることができる唯一の理由は、彼らがチーム開発、デバッグ、および自動文書化を簡素化したいということです。

個人的に、私は両方の方法論でアプリケーションを開発しました、そして、私は動的言語で物事をより速く終わらせます。動的言語を再びクラスベース言語に戻すように設計されたこれらのフレームワークは使用しません。そのようなことは私の好みの退行です。

— ロニー・ベスト
ソース

1

私にとってのOOPとは、メッセージ、ローカルの保持と状態プロセスの保護と隠蔽、すべてのものの極端な遅延バインディングのみを意味します-Alan Kay

彼がここで言っているのは、オブジェクト指向とは、メッセージに応答するブラックボックスを作ることです。ある意味では、RESTは動詞（つまりメッセージ）とリソース（つまりデータを含む不透明なボックス）を使用するという点で究極のオブジェクト指向システムです。

そのため、なぜクラスベースのものとプロトタイプベースのものとが、実際には問題ではなく、どちらも単なる実装であるという点を見落としているのはなぜかという疑問です。メソッド呼び出しの代わりにメッセージングのみを使用するシステムは、2つのインスタンスと同じくらいオブジェクト指向です。

— gbjbaanb
ソース