Datum: Mi, 23 Jul 2003 09:33:31 -0800 An: Stefan Ram [aus Datenschutzgründen entfernt] Von: Alan Kay [aus Datenschutzgründen entfernt] Betreff: Betreff: Erläuterung von "objektorientiert"
Hallo Stefan -
Entschuldigung für die Verspätung, aber ich war im Urlaub.
Um 6:27 PM +0200 17.07.03 schrieb Stefan Ram:
Lieber Dr. Kay,
Ich hätte gerne ein verbindliches Wort zum Begriff "objektorientierte Programmierung" für meine Tutorial-Seite zu diesem Thema. Die einzigen zwei Quellen, die ich als "maßgeblich" betrachte, sind die International Standards Organization, die "objektorientiert" in "ISO / IEC 2382-15" definiert, und Sie, weil Sie diesen Begriff, wie sie sagen, geprägt haben.
Ich bin mir ziemlich sicher, dass ich es getan habe.
Leider ist es schwierig, eine Webseite oder Quelle mit Ihrer Definition oder Beschreibung dieses Begriffs zu finden. Es gibt verschiedene Berichte darüber, was Sie in dieser Hinsicht gesagt haben könnten (wie "Vererbung, Polymorphismus und Einkapselung"), aber dies sind keine Quellen aus erster Hand. Mir ist auch bewusst, dass Sie später mehr Wert auf "Messaging" legen - aber ich würde immer noch gerne etwas über "objektorientiert" erfahren.
Für die Aufzeichnungen, meine Tutorial-Seite und weitere Verbreitung und Veröffentlichung können Sie bitte erklären:
Wann und wo wurde der Begriff "objektorientiert" zuerst verwendet?
Irgendwann nach dem 66. November in Utah, als ich, beeinflusst von Sketchpad, Simula, dem Design für das ARPAnet, den Burroughs B5000 und meinem Hintergrund in Biologie und Mathematik, an eine Architektur für die Programmierung dachte. Es war wahrscheinlich im Jahr 1967, als mich jemand fragte, was ich tue, und ich sagte: "Es ist objektorientierte Programmierung".
Die ursprüngliche Konzeption hatte die folgenden Teile.
Ich dachte an Objekte, die wie biologische Zellen und / oder einzelne Computer in einem Netzwerk sind und nur mit Nachrichten kommunizieren können (Messaging stand also am Anfang - es dauerte eine Weile, bis ich herausgefunden hatte, wie Messaging in einer Programmiersprache effizient genug ist, um zu funktionieren nützlich sein).
Ich wollte Daten loswerden. Der B5000 hat dies dank seiner fast unglaublichen HW-Architektur beinahe geschafft. Ich erkannte, dass die Metapher für die Zelle / den gesamten Computer keine Daten mehr enthält und dass "<-" nur ein weiteres Nachrichtentoken ist (es dauerte eine Weile, bis ich mir das überlegte, weil ich all diese Symbole wirklich als Namen für diese Symbole angesehen hatte Funktionen und Verfahren.
Durch meinen mathematischen Hintergrund wurde mir klar, dass mit jedem Objekt mehrere Algebren verknüpft sein könnten und dass es Familien von diesen geben könnte, und dass diese sehr, sehr nützlich wären. Der Begriff "Polymorphismus" wurde viel später auferlegt (ich denke von Peter Wegner) und ist nicht ganz gültig, da er wirklich aus der Nomenklatur der Funktionen stammt und ich ziemlich viel mehr als Funktionen wollte. Ich habe mir einen Begriff "Generizität" ausgedacht, um mit generischen Verhaltensweisen in einer quasi-algebraischen Form umzugehen.
Mir hat nicht gefallen, wie Simula I oder Simula 67 geerbt haben (obwohl ich dachte, Nygaard und Dahl wären nur großartige Denker und Designer). Deshalb habe ich beschlossen, die Vererbung als integrierte Funktion wegzulassen, bis ich sie besser verstanden habe.
Meine ursprünglichen Experimente mit dieser Architektur wurden mit einem Modell durchgeführt, das ich von van Wijngaarten und Wirths "Generalization of Algol" und Wirths Euler adaptiert hatte. Beide waren eher LISP-artig, jedoch mit einer konventionelleren lesbaren Syntax. Ich verstand damals die Monster-LISP-Idee von greifbarer Metasprache nicht, kam aber den Ideen über erweiterbare Sprachen aus verschiedenen Quellen, einschließlich Irons IMP, ein Stück näher.
Die zweite Phase bestand darin, LISP endlich zu verstehen und dieses Verständnis dann zu nutzen, um viel schönere und kleinere, leistungsfähigere und später gebundene Unterstrukturen zu erstellen. Dave Fischers Abschlussarbeit wurde im "McCarthy" -Stil gemacht und seine Ideen zu erweiterbaren Kontrollstrukturen waren sehr hilfreich. Ein weiterer großer Einfluss zu dieser Zeit war Carl Hewitts PLANNER (der nie die Anerkennung erhalten hat, die er verdient, wenn man bedenkt, wie gut und wie früh er Prolog antizipieren konnte).
Das ursprüngliche Smalltalk bei Xerox PARC ist aus dem oben Gesagten hervorgegangen. Die folgenden Smalltalks werden am Ende des Kapitels "Geschichte" beanstandet: Sie sind in Richtung Simula zurückgefallen und haben die Verlängerungsmechanismen nicht durch sicherere ersetzt, die bei weitem nicht so nützlich waren.
Was bedeutet für Sie "objektorientierte [Programmierung]"? (Es ist keine Tutorial-ähnliche Einführung erforderlich, nur eine kurze Erklärung [wie "Programmieren mit Vererbung, Polymorphismus und Kapselung"] in Bezug auf andere Konzepte für einen Leser, der mit ihnen vertraut ist, wenn möglich. Außerdem ist es nicht erforderlich, "Objekt" zu erklären ", weil ich bereits Quellen mit Ihrer Erklärung von" object "aus" Early History of Smalltalk "habe.)
(Ich bin nicht gegen Typen, aber ich kenne keine Typensysteme, die keine völligen Schmerzen bereiten. Deshalb mag ich dynamisches Tippen immer noch.)
OOP bedeutet für mich nur Nachrichtenübermittlung, lokale Aufbewahrung und Schutz sowie das Verstecken von staatlichen Prozessen und extrem spätes Binden aller Dinge. Dies kann in Smalltalk und in LISP erfolgen. Es gibt möglicherweise andere Systeme, in denen dies möglich ist, aber ich kenne sie nicht.
Eines der Dinge, die ich hätte erwähnen sollen, ist, dass es zwei Hauptpfade gab, die von Simula katalysiert wurden. Der erste (nur aus Versehen) war der von mir eingeschlagene Bio / Net-Weg, bei dem keine Daten verarbeitet wurden. Der andere, der etwas später als Untersuchungsgegenstand kam, waren abstrakte Datentypen, und dies brachte viel mehr Spielraum.
Wenn wir uns die ganze Geschichte ansehen, sehen wir, dass das Proto-OOP-Zeug mit ADT begann, eine kleine Abzweigung zu dem hatte, was ich "Objekte" nannte - das führte zu Smalltalk usw. -, aber nach der kleinen Abzweigung, dem Das CS-Establishment tat ADT so ziemlich und wollte am Paradigma der Datenprozedur festhalten. Historisch gesehen lohnt sich ein Blick auf das USAF-Burroughs-220-Dateisystem (das ich in der Smalltalk-Geschichte beschrieben habe), die frühen Arbeiten von Doug Ross am MIT (AED und früher), in denen er die Einbettung von Prozedurzeigern in Datenstrukturen befürwortete (Sketchpad) vollständiger Polymorphismus - wo z. B. der gleiche Versatz in seiner Datenstruktur "Anzeige" bedeutete und es einen Zeiger auf die entsprechende Routine für den Typ des Objekts geben würde, das die Struktur darstellt, usw., und die Burroughs B5000, Ihre Programmreferenztabellen waren echte "große Objekte" und enthielten Zeiger sowohl auf "Daten" als auch auf "Prozeduren", konnten aber oft das Richtige tun, wenn sie versuchten, Daten zu suchen und einen Prozedurzeiger zu finden. Und das allererste Problem, das ich mit meinen frühen Utah-Sachen löste, war das "Verschwinden von Daten", bei dem nur Methoden und Objekte verwendet wurden. Ende der 60er Jahre (glaube ich) schrieb Bob Balzer eine ziemlich raffinierte Abhandlung mit dem Titel "Dataless Programming", und kurz darauf schrieb John Reynolds eine ebenso raffinierte Abhandlung mit dem Titel "Gedanken" (glaube ich 1970), in der er dies unter Verwendung der Lamda zeigte Ausdrücke auf die richtige Weise würden es ermöglichen, Daten durch Prozeduren zu abstrahieren. konnte aber oft das Richtige tun, wenn versucht wurde, Daten zu suchen und einen Prozedurzeiger zu finden. Und das allererste Problem, das ich mit meinen frühen Utah-Sachen löste, war das "Verschwinden von Daten", bei dem nur Methoden und Objekte verwendet wurden. Ende der 60er Jahre (glaube ich) schrieb Bob Balzer eine ziemlich raffinierte Abhandlung mit dem Titel "Dataless Programming", und kurz darauf schrieb John Reynolds eine ebenso raffinierte Abhandlung mit dem Titel "Gedanken" (glaube ich 1970), in der er dies unter Verwendung der Lamda zeigte Ausdrücke auf die richtige Weise würden es ermöglichen, Daten durch Prozeduren zu abstrahieren. konnte aber oft das Richtige tun, wenn versucht wurde, nach Daten zu suchen und einen Prozedurzeiger zu finden. Und das allererste Problem, das ich mit meinen frühen Utah-Sachen löste, war das "Verschwinden von Daten", bei dem nur Methoden und Objekte verwendet wurden. Ende der 60er Jahre (glaube ich) schrieb Bob Balzer eine ziemlich raffinierte Abhandlung mit dem Titel "Dataless Programming", und kurz darauf schrieb John Reynolds eine ebenso raffinierte Abhandlung mit dem Titel "Gedanken" (glaube ich 1970), in der er dies unter Verwendung der Lamda zeigte Ausdrücke auf die richtige Art und Weise würden es ermöglichen, Daten durch Prozeduren zu abstrahieren.
Die Leute, die Objekte als Nicht-Daten mochten, waren zahlenmäßig kleiner und schlossen mich, Carl Hewitt, Dave Reed und einige andere ein - so ziemlich alle dieser Gruppe gehörten der ARPA-Gemeinschaft an und waren auf die eine oder andere Weise in die ARPA involviert Design von ARPAnet → Internet, bei dem die Grundeinheit der Berechnung ein ganzer Computer war. Aber nur um zu zeigen, wie hartnäckig eine Idee sein kann, gab es in den siebziger und achtziger Jahren viele Menschen, die versuchten, mit "Remote Procedure Call" auszukommen, anstatt über Objekte und Nachrichten nachzudenken. Sic Transit Gloria Mundi.
Prost,
Alan Kay