Data: Qua, 23 de julho de 2003 09:33:31 -0800. Para: Stefan Ram [removido por privacidade] De: Alan Kay [removido por privacidade] Assunto: Re: Esclarecimento de "orientação a objetos"
Olá Stefan -
Desculpe pelo atraso, mas eu estava de férias.
Às 18:27 +0200 em 17/07/03, Stefan Ram escreveu:
Caro Dr. Kay,
Eu gostaria de ter alguma palavra oficial sobre o termo "programação orientada a objetos" para a minha página de tutorial sobre o assunto. As únicas duas fontes que considero "autoritativas" são a Organização Internacional de Padrões, que define "orientada a objetos" na "ISO / IEC 2382-15", e você, porque, como dizem, cunhou esse termo.
Tenho certeza que sim.
Infelizmente, é difícil encontrar uma página da web ou fonte com sua definição ou descrição desse termo. Existem vários relatórios sobre o que você poderia ter dito a esse respeito (como "herança, polimorfismo e encapsulamento"), mas essas não são fontes de primeira mão. Também estou ciente de que mais tarde você dará mais ênfase às "mensagens" - mas eu ainda gostaria de saber sobre "orientação a objetos".
Para os registros, minha página de tutorial e mais distribuição e publicação, você poderia explicar:
Quando e onde o termo "orientação a objetos" foi usado primeiro?
Em Utah, pouco depois do dia 66 de novembro, quando, influenciado pelo Sketchpad, Simula, o design do ARPAnet, o Burroughs B5000 e minha formação em Biologia e Matemática, pensei em uma arquitetura para programação. Provavelmente foi em 1967, quando alguém me perguntou o que eu estava fazendo e eu disse: "É uma programação orientada a objetos".
A concepção original tinha as seguintes partes.
Pensei nos objetos como células biológicas e / ou computadores individuais em uma rede, capazes apenas de se comunicar com mensagens (então as mensagens surgiram logo no início - demorou um pouco para ver como fazer as mensagens em uma linguagem de programação com eficiência suficiente para seja útil).
Eu queria me livrar dos dados. O B5000 quase fez isso através de sua arquitetura HW quase inacreditável. Percebi que a metáfora da célula / computador inteiro se livraria dos dados e que "<-" seria apenas mais um token de mensagem (demorei um pouco para pensar nisso, porque realmente pensei em todos esses símbolos como nomes para funções e procedimentos.
Minha formação em matemática me fez perceber que cada objeto poderia ter várias álgebras associadas a ele, e poderia haver famílias delas, e que elas seriam muito, muito úteis. O termo "polimorfismo" foi imposto muito mais tarde (acho que por Peter Wegner) e não é muito válido, pois realmente vem da nomenclatura de funções, e eu queria muito mais que funções. Eu inventei o termo "genérico" para lidar com comportamentos genéricos de forma quase algébrica.
Não gostei da maneira como o Simula I ou o Simula 67 herdaram (embora eu pensasse que Nygaard e Dahl eram apenas tremendos pensadores e designers). Por isso, decidi deixar de fora a herança como um recurso interno até entender melhor.
Minhas experiências originais com essa arquitetura foram feitas usando um modelo que adaptei da "Generalização de Algol" de van Wijngaarten e Wirth e Euler de Wirth. Ambos eram parecidos com LISP, mas com uma sintaxe legível mais convencional. Naquela época, eu não entendi a ideia monstruosa de metal tangível da LISP, mas cheguei perto de idéias sobre linguagens extensíveis extraídas de várias fontes, incluindo o IMP de Irons.
A segunda fase disso foi finalmente entender o LISP e depois usá-lo para criar subestruturas muito mais agradáveis e menores, mais poderosas e mais atrasadas. A tese de Dave Fisher foi feita no estilo "McCarthy" e suas idéias sobre estruturas de controle extensíveis foram muito úteis. Outra grande influência nesse momento foi o PLANNER de Carl Hewitt (que nunca obteve o reconhecimento que merece, dado o quão bem e quão cedo foi capaz de antecipar o Prolog).
O Smalltalk original no Xerox PARC saiu do exposto acima. Os Smalltalk subseqüentes são reclamados no final do capítulo História: eles recuaram em direção a Simula e não substituíram os mecanismos de extensão por mecanismos mais seguros, que eram úteis em qualquer lugar.
O que significa "programação orientada a objetos" para você? (Nenhuma introdução de tutorial é necessária, apenas uma breve explicação [como "programação com herança, polimorfismo e encapsulamento"] em termos de outros conceitos para um leitor familiarizado com eles, se possível. Além disso, não é necessário explicar "objeto" ", porque eu já tenho fontes com a sua explicação sobre" objeto "de" Early History of Smalltalk ".)
(Eu não sou contra tipos, mas não conheço nenhum sistema de tipos que não seja uma dor completa, por isso ainda gosto de digitação dinâmica.)
OOP para mim significa apenas mensagens, retenção e proteção local e ocultação de processos estatais e vinculação extrema de todas as coisas. Isso pode ser feito no Smalltalk e no LISP. Possivelmente existem outros sistemas nos quais isso é possível, mas eu não os conheço.
[Além disso] Uma das coisas que eu deveria ter mencionado é que havia dois caminhos principais que foram catalisados por Simula. A primeira (apenas por acidente) foi a rota de procedimentos sem dados bio / líquidos que eu segui. O outro, que surgiu um pouco mais tarde como objeto de estudo, era de tipos abstratos de dados, e isso ficou muito mais divertido.
Se olharmos para toda a história, veremos que o proto-OOP começou com o ADT, tinha um pequeno garfo em direção ao que eu chamei de "objetos" - que levaram ao Smalltalk, etc., - mas depois do garfo pequeno, o O estabelecimento de CS praticamente fez o ADT e queria seguir o paradigma de procedimento de dados. Historicamente, vale a pena examinar o sistema de arquivos USAF Burroughs 220 (que descrevi na história do Smalltalk), o trabalho inicial de Doug Ross no MIT (AED e anterior), no qual ele defendia a incorporação de ponteiros de procedimento em estruturas de dados, o Sketchpad (que tinha polimorfismo completo - onde, por exemplo, o mesmo deslocamento em sua estrutura de dados significava "exibição" e haveria um ponteiro para a rotina apropriada para o tipo de objeto que a estrutura representava, etc., e o Burroughs B5000, cujas tabelas de referência de programas eram verdadeiros "grandes objetos" e continham ponteiros para "dados" e "procedimentos", mas geralmente podiam fazer a coisa certa se tentassem buscar dados e encontrassem um ponteiro de procedimento. E os primeiros problemas que resolvi com minhas primeiras coisas em Utah foram o "desaparecimento de dados" usando apenas métodos e objetos. No final dos anos 60 (eu acho), Bob Balzer escreveu um artigo bastante bacana chamado "Dataless Programming", e logo depois John Reynolds escreveu um artigo igualmente bacana "Gedanken" (acho que em 1970) no qual ele mostrou que usando o lamda expressões da maneira correta permitiria que os dados fossem abstraídos por procedimentos. mas muitas vezes poderia fazer a coisa certa se estivesse tentando ir atrás dos dados e encontrasse um ponteiro de procedimento. E os primeiros problemas que resolvi com minhas primeiras coisas em Utah foram o "desaparecimento de dados" usando apenas métodos e objetos. No final dos anos 60 (eu acho), Bob Balzer escreveu um artigo bastante bacana chamado "Dataless Programming", e logo depois John Reynolds escreveu um artigo igualmente bacana "Gedanken" (acho que em 1970) no qual ele mostrou que usando o lamda expressões da maneira correta permitiria que os dados fossem abstraídos por procedimentos. mas muitas vezes poderia fazer a coisa certa se estivesse tentando ir atrás dos dados e encontrasse um ponteiro de procedimento. E os primeiros problemas que resolvi com minhas primeiras coisas em Utah foram o "desaparecimento de dados" usando apenas métodos e objetos. No final dos anos 60 (eu acho), Bob Balzer escreveu um artigo bastante bacana chamado "Dataless Programming", e logo depois John Reynolds escreveu um artigo igualmente bacana "Gedanken" (acho que em 1970) no qual ele mostrou que usando o lamda expressões da maneira correta permitiria que os dados fossem abstraídos por procedimentos.
As pessoas que gostaram de objetos como não-dados eram menores em número e incluíam eu, Carl Hewitt, Dave Reed e alguns outros - praticamente todo esse grupo era da comunidade do ARPA e estava envolvido de uma maneira ou de outra com o projeto da ARPAnet → Internet na qual a unidade básica de computação era um computador inteiro. Mas apenas para mostrar o quão teimosamente uma idéia pode se sustentar, durante os anos 70 e 80, muitas pessoas tentaram se dar bem com a "Chamada de Procedimento Remoto" em vez de pensar em objetos e mensagens. Sic transit gloria mundi.
Felicidades,
Alan Kay