Date: mer. 23 juil. 2003 09:33:31 -0800 À: Stefan Ram [enlevé pour plus de protection de la vie privée] De: Alan Kay [enlevé pour plus de protection de la vie privée] Sujet: Re: Clarification de "orienté objet"
Salut Stefan -
Désolé pour le retard, mais j'étais en vacances.
À 18h27 +0200 le 17/07/03, Stefan Ram a écrit:
Cher Dr. Kay,
J'aimerais avoir un mot faisant autorité sur le terme "programmation orientée objet" pour ma page de tutoriel sur le sujet. Les deux seules sources que je considère comme faisant "autorité" sont l'Organisation internationale de normalisation, qui définit "orienté objet" dans "ISO / CEI 2382-15", et vous, car, comme on dit, vous avez inventé ce terme.
Je suis à peu près sûr de l'avoir fait.
Malheureusement, il est difficile de trouver une page Web ou une source avec votre définition ou description de ce terme. Il existe plusieurs rapports sur ce que vous auriez pu dire à cet égard (comme "héritage, polymorphisme et encapsulation"), mais ce ne sont pas des sources de première main. Je suis également conscient du fait que plus tard, vous avez mis davantage l'accent sur la "messagerie" - mais j'aimerais tout de même savoir "orienté objet".
Pour les enregistrements, ma page de tutoriel, ainsi que la distribution et la publication, pourriez-vous s'il vous plaît expliquer:
Où et quand le terme "orienté objet" a-t-il été utilisé en premier?
En Utah, quelque temps après le 66 novembre, lorsque, influencé par Sketchpad, Simula, le design de l’ARPAnet, du Burroughs B5000 et de ma formation en biologie et en mathématiques, j’ai pensé à une architecture de programmation. C'était probablement en 1967 quand quelqu'un m'a demandé ce que je faisais et j'ai dit: "C'est de la programmation orientée objet".
La conception originale de celui-ci avait les parties suivantes.
Je pensais que les objets ressemblaient à des cellules biologiques et / ou à des ordinateurs individuels sur un réseau, uniquement capables de communiquer avec des messages (la messagerie est donc arrivée au tout début - il a fallu un certain temps pour voir comment faire de la messagerie dans un langage de programmation suffisamment efficace pour sois utile).
Je voulais me débarrasser des données. Le B5000 a presque réussi à le faire via son architecture HW presque incroyable. J'ai réalisé que la métaphore de la cellule / de l'ordinateur complet supprimerait les données, et que "<-" ne serait qu'un autre jeton de message (il m'a fallu un bon bout de temps pour réfléchir à cela, car j'ai vraiment pensé à tous ces symboles comme des noms fonctions et procédures.
Mes connaissances en mathématiques m'ont fait comprendre que chaque objet pouvait avoir plusieurs algèbres, des familles de celles-ci, qui seraient très utiles. Le terme "polymorphisme" a été imposé beaucoup plus tard (je pense par Peter Wegner) et il n'est pas tout à fait valable, car il provient vraiment de la nomenclature des fonctions, et je voulais bien plus que des fonctions. J'ai inventé le terme "généricité" pour traiter des comportements génériques sous une forme quasi algébrique.
Je n'aimais pas la manière dont Simula I ou Simula 67 héritaient (même si je pensais que Nygaard et Dahl étaient simplement des penseurs et des concepteurs formidables). J'ai donc décidé de laisser l'héritage en tant que fonctionnalité intégrée jusqu'à ce que je le comprenne mieux.
Mes expériences originales avec cette architecture ont été réalisées à l'aide d'un modèle que j'ai adapté de "Generalization of Algol" de Wijngaarten et Wirth et de Euler de Wirth. Tous deux ressemblaient plutôt à LISP mais avec une syntaxe lisible plus conventionnelle. À l'époque, je ne comprenais pas l'idée du métalangage tangible dans LISP, mais je me rapprochais des idées sur les langages extensibles puisées dans différentes sources, y compris IMP.
La deuxième phase consistait à finalement comprendre le LISP, puis à utiliser cette compréhension pour créer des sous-structures beaucoup plus agréables, plus petites, plus puissantes et plus tardives. La thèse de Dave Fisher a été réalisée dans le style "McCarthy" et ses idées sur les structures de contrôle extensibles ont été très utiles. Le planificateur de Carl Hewitt (qui n’a jamais obtenu la reconnaissance qu’il mérite, en raison de la qualité et de la rapidité avec lesquelles il a pu anticiper sur Prolog) a été une autre grande influence à cette époque.
Le Smalltalk original de Xerox PARC est issu de ce qui précède. Les derniers Smalltalk se sont plaints à la fin du chapitre d'Histoire: ils ont rétrogradé vers Simula et n'ont pas remplacé les mécanismes d'extension par des mécanismes plus sûrs et aussi utiles.
Qu'est-ce que "programmation orientée objet" signifie pour vous? (Aucune introduction de type tutoriel n'est nécessaire, juste une courte explication [du type "programmation avec héritage, polymorphisme et encapsulation"] en termes d'autres concepts pour un lecteur familier, si possible. En outre, il n'est pas nécessaire d'expliquer "objet" ", parce que j'ai déjà des sources avec votre explication de" objet "de" Early History of Smalltalk ".)
(Je ne suis pas contre les types, mais je ne connais aucun système de type qui ne soit pas une douleur complète, donc j'aime toujours la dactylographie dynamique.)
La POO pour moi ne signifie que la messagerie, la rétention et la protection locales et le masquage du processus d'état, et la liaison tardive extrême de toutes choses. Cela peut être fait en Smalltalk et en LISP. Il existe peut-être d'autres systèmes dans lesquels cela est possible, mais je ne les connais pas.
[Aussi] L'une des choses que j'aurais dû mentionner est qu'il y avait deux voies principales qui ont été catalysées par Simula. La première (juste par accident) était la voie bio / net que je prenais. L'autre, qui est venu un peu plus tard comme objet d'étude, était constitué de types de données abstraits, ce qui a entraîné beaucoup plus de jeu.
Si nous regardons l’ensemble de l’histoire, nous voyons que les proto-OOP ont commencé avec ADT, qu’il y avait une petite fourchette vers ce que j’appelais des "objets" - ce qui a conduit à Smalltalk, etc., - mais après la petite fourche, le L'établissement CS a à peu près fait ADT et voulait s'en tenir au paradigme de la procédure de données. Historiquement, cela vaut la peine d’examiner le système de fichiers USAF Burroughs 220 (que j’ai décrit dans l’histoire de Smalltalk), les travaux antérieurs de Doug Ross au MIT (AED et antérieurs) dans lesquels il préconisait l’ajout de pointeurs de procédure dans des structures de données, Sketchpad (qui polymorphisme complet - où, par exemple, le même décalage dans sa structure de données signifiait "affichage" et qu'il y aurait un pointeur sur la routine appropriée pour le type d'objet représenté par la structure, etc., et le Burroughs B5000, dont les tables de référence de programme étaient de vrais "gros objets" et contenaient des pointeurs vers les "données" et les "procédures", mais pouvaient souvent faire ce qui était juste si elles essayaient de rechercher des données et de trouver un pointeur de procédure. Et les tous premiers problèmes que j'ai résolus avec mes débuts dans l'Utah étaient la "disparition de données" en utilisant uniquement des méthodes et des objets. À la fin des années 60 (je pense), Bob Balzer a écrit un article plutôt intéressant appelé "Dataless Programming" (Programmation sans données) et peu de temps après, John Reynolds a rédigé un article tout aussi intéressant "Gedanken" (en 1970, je pense) dans lequel il montrait que les expressions de la bonne manière permettrait aux données d’être extraites par des procédures. mais pourrait souvent faire la bonne chose si elle essayait de rechercher des données et de trouver un pointeur de procédure. Et les tous premiers problèmes que j'ai résolus avec mes débuts dans l'Utah étaient la "disparition de données" en utilisant uniquement des méthodes et des objets. À la fin des années 60 (je pense), Bob Balzer a écrit un article plutôt intéressant appelé "Dataless Programming" (Programmation sans données) et peu de temps après, John Reynolds a rédigé un article tout aussi intéressant "Gedanken" (en 1970, je pense) dans lequel il montrait que les expressions de la bonne manière permettrait aux données d’être extraites par des procédures. mais pourrait souvent faire la bonne chose si elle essayait de rechercher des données et de trouver un pointeur de procédure. Et les tous premiers problèmes que j'ai résolus avec mes débuts dans l'Utah étaient la "disparition de données" en utilisant uniquement des méthodes et des objets. À la fin des années 60 (je pense), Bob Balzer a écrit un article plutôt intéressant appelé "Dataless Programming" (Programmation sans données) et peu de temps après, John Reynolds a rédigé un article tout aussi intéressant "Gedanken" (en 1970, je pense) dans lequel il montrait que les expressions de la bonne manière permettrait aux données d’être extraites par des procédures.
Les personnes qui aimaient les objets en tant que non-données étaient moins nombreuses et comprenaient moi-même, Carl Hewitt, Dave Reed et quelques autres - à peu près tout ce groupe appartenait à la communauté ARPA et participait d'une manière ou d'une autre à la conception d'ARPAnet → Internet dans laquelle l'unité de calcul de base était un ordinateur complet. Mais pour montrer à quel point une idée peut rester obstinément accrochée, tout au long des années soixante-dix et quatre-vingt, de nombreuses personnes ont essayé de se débrouiller avec "Appel de procédure à distance" au lieu de penser à des objets et à des messages. Sic transit gloria mundi.
À votre santé,
Alan Kay