なぜ多くのアヒル型の動的プログラミング言語は、プロトタイプベースのOOPではなくクラスベースのアプローチを使用するのでしょうか。
非常に多くの動的プログラミング言語には ダックタイピング の機能があり、クラスまたはインスタンスメソッドをいつでも開いて変更できます（- Ruby や Pythonなど） ）、それから…
質問1）動的言語のクラスの必要性は何ですか？なぜプロトタイプ方式ではなくオブジェクトを使用するのではなく、クラスをある種の「テンプレート」として使用するように言語が設計されているのですか？
また、 JavaScript はプロトタイプベースですが、 CoffeeScript （JavaScriptの拡張バージョン）はクラスベースの方法を選択します。 Lua （プロトタイプベース）および MoonScript （クラスベース）の場合も同じです。さらに、ES 6にはクラスがあります。だから…
質問2）とりわけプロトタイプベースの言語を改善しようとする場合、クラスベースに変更する必要があることを示唆していますか？そうでない場合、なぜそのように設計されているのですか？
質問1）動的言語のクラスの必要性は何ですか？プロトタイプの方法でオブジェクトを使用するのではなく、クラスをある種の「テンプレート」として使用するように言語が設計されているのはなぜですか？
最初のOO言語（ "OO"と呼ばれていなくても））Simulaには継承がありませんでした。継承はSimula-67で追加され、クラスに基づいていました。
同じ頃、アランケイは新しいプログラミングパラダイムのアイデアに取り組み始めました。これは後に「オブジェクト指向」と名付けられました。彼は継承が本当に好きで、自分の言語で継承したかったのですが、クラスも本当に嫌いでした。ただし、クラスなしで継承する方法を思い付くことができなかったため、継承が好きであるよりもクラスが嫌いであると判断し、Smalltalkの最初のバージョンであるSmalltalk-72をクラスなしで継承せずに設計しました。
数か月後、Dan Ingallsはクラス自体のオブジェクト、つまりメタクラスのインスタンスであるクラスの設計を思いつきました。 Alan Kayは、この設計が以前の設計よりもわずかに魅力的でないことを発見したため、Smalltalk-74は、クラスとクラスに基づく継承を使用して設計されました。
Smalltalk-74の後で、Alan KayはSmalltalkが間違った方向に進んでいると感じ、実際にはOOのすべてが何であるかを表していないと思いました。したがって、Smalltalk-76、Smalltalk-80（Smalltalkの最初のバージョンが研究者にリリースされる）、最後にSmalltalk-80 V2.0（最初に商用リリースされるバージョン、および基礎となったバージョン）が続きました。 ANSI Smalltalkの場合）。
Simula-67とSmalltalk-80はすべてのOO言語の祖父母と見なされているため、その後に続くほとんどすべての言語は、クラスの設計とクラスに基づく継承を盲目的にコピーしました。数年後、クラスではなくミックスインに基づく継承や、クラスに基づく継承ではなくオブジェクトに基づく委譲などの他のアイデアが浮上したとき、クラスベースの継承はすでに定着しすぎていました。
興味深いことに、Alan Kayの現在の言語はプロトタイプ委任に基づいています。
多くのプログラマーはクラスでの作業を好みます。これは非常に理解しやすい概念であり、世界に関する人間の思考プロセスの優れたモデルです（つまり、実際のオブジェクトを、それらが属していると考えるアイテムの抽象的なグループに本能的に関連付けます。これはクラスです）。 。また、クラスを使用すると、オブジェクトタイプについての推論が容易になります。クラスベースの言語では、 Liskov置換 のような原則を適用することは、異なるメソッドを持つ可能性のあるオブジェクトや、 JavaScriptの場合のように、型は実行時に変更されることもあります。
JavaScriptでも、非常に多くのコードがプロトタイプ機能を使用してクラスをエミュレートしていることに注意してください。これは主に、多くのプログラマーがそのように考えることを好むためです。
クラスベースの言語が好まれるもう1つの理由もあります。それらを効率的なコードにコンパイルする方が簡単です。最も効率的なJavaScript VMは、メソッドとプロトタイプが変更されると、JavaScriptオブジェクトのタイプを表すクラスを効果的に動的に作成します。これが行われる理由の根拠については、 V8の実装のこの説明 を参照してください。
人々のチームが同じコードで共同作業している大きなプロジェクトでは、その柔軟な言語（実行時にオブジェクトのプロパティとメソッドを変更できる）は他のチームメンバーが望まない自由だと聞いたことがあります持つため。
彼らは、オブジェクトを処理するとき、オブジェクトが設計図が言うように動作することを知りたいと思っています。他の野心的な開発者が自分のタスクを完了するために変更することに決めたモーフィングされた方法ではありません。
したがって、私が思いつくことができる唯一の理由は、誰かがこれらの素晴らしい動的言語によって提供される柔軟性を望まないのは、チームの開発、デバッグ、自動ドキュメント化を簡素化したいということです。
個人的に、私は両方の方法論でアプリケーションを開発し、動的言語を使用して物事をより速く完了させました。私は、動的言語を再びクラスベース言語に戻すように設計されたこれらのフレームワークを使用していません。そのようなことは私の好みへの回帰です。
私にとってのOOPは、メッセージング、ローカルでの保持と状態プロセスの保護と非表示、およびすべてのものの極端な遅延バインディングのみを意味します-Alan Kay
したがって、ここで彼が言っていることは、OOは、メッセージに応答するブラックボックスを作成することに関するすべてです。ある意味、RESTは、究極のOOシステムは、動詞（つまり、メッセージ）とリソース（つまり、一部のデータを含む不透明なボックス）を使用します。
したがって、なぜ一部がクラスベースであり、他のものがプロトタイプベースであるかという問題は、それが本当に重要ではないという点を逃しています。どちらも単なる実装にすぎません。メソッド呼び出しではなくメッセージングのみを使用するシステムは、2つのインスタンスと同じようにOOと同じです。