Na verdade, não, nem mesmo Smalltalk é 100% pura como OO que na verdade é orientada a mensagens e não a objetos.

Eu concordo que Smalltalk poderia ser mais puro, ele toma vários atalhos de design emprestados de FP, mas o core da linguagem é puramente orientado a objetos e você consegue implementar o design correto baseado só nas ferramentas base da linguagem (o objeto como uma unidade receptora de mensagens). Isso é demonstrado no paper sobre HOMs que eu citei.

Apesar disso eu rejeito a ideia de que existe um paradigma orientado a mensagens puro, seria como dizer que existe um paradigma orientado a funções puro só porque procedures e funções puras tem como base o mesmo mecanismo. Existem tipos de trocas de mensagem, e é isso que diferencia OO de Actor Model por exemplo.

Eu também não gosto da ideia de mudar quem está correto nessa história só porque o que é popular foi quem não significa as ideias originais e nem tem elementos suficientes para ser considerado um paradigma de fato.

Então se eu tivesse que escolher alguém para desistir do nome seria a tradição de Simula, a gente pode chamar de programação orientada a classes e seguir feliz com isso. Até porque todas as linguagens derivadas do sistema de protótipos respeitam bem a ideia original de troca de mensagens do Kay (tá o JS nem tanto, mas ele é flexível o suficiente para você conseguir algo parecido mesmo com a sintaxe atrapalhando).

Eu diria que o próprio Self, origem do JS, seria mais OO que o Smalltalk por ter entendido que classes são um utilitário legal, mas a unidade irredutível é você ter um receptor de mensagens, então você pode fazer tudo simplesmente clonando os objetos e mudando como eles interpretam as novas mensagens.

Herança mesmo vinha de um paper também sobre o paradigma da época que era a programação imperativa/procedural/estruturada. Tanto que o paper falava sobre estender structs (records).
Não sei, tem fontes que eu possa ver sobre isso?

Relendo o próprio paper do criador de Simula que conta a história da linguagem, eu vejo que eles introduziram até o conceito de classes baseado nisso:
https://www.mn.uio.no/ifi/english/about/ole-johan-dahl/bibliography/the-birth-of-object-orientation-the-simula-languages.pdf

O conceito de herança vem desse paper aqui que introduzia um conceito chamado de Hoare Records:
https://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-9-pdf/k-9-u2293-Record-Handling-Hoare.pdf

"Encapsulamento" também não era exatamente algo que nasceu no contexto orientado a objetos já que information hiding já era algo bem discutido muito antes disso e tem exemplos de linguagens procedurais adotando mecanismos similares ao que a gente tem de modificadores de visibilidade já naquela época.
Certo, ainda que algumas pessoas gostem de dizer que isso é o mais importante para OOP, não eu.

Eu também não, a coisa irredutível do paradigma é troca de mensagens com elas podendo ser síncronas. Se você assume só mensagens assíncronas, o modelo computacional é diferente, pois ele tem implicações lógicas diferentes, e nesse caso a gente estaria falando de Actor Model que surgiu mais ou menos na mesma época. Apesar disso, se você pega aquele Kay que escreveu o texto sobre a origem do Smalltalk, eu tenho a forte sensação que seria a cara dele chamar o Actor Model de algo "bem orientado a objetos" kkkk.

Se eu entendi seu texto, posso dizer que o próprio não gosta do termo que ele criou, mas ele pe resistente em falar isso de forma clara. Ele é bem apegado às coisas dele e é uma pessoa bastante orgulhosa (sem juízo de valor).

Olha, existe mesmo um texto do Kay onde ele diz que se arrepende de ter cunhado o termo e anos depois as pessoas não terem entendido nada, e focado na ideia que era só um detalhe para ele, mas isso ele diz na troca de e-mails na comunidade do Self, no meio de uma discussão do povo se OO eram classes ou protótipos, e ele chega para falar que isso não importa.

Mas o que eu me referia ali, ele não se arrepende do termo não, o e-mail que eu cito é o e-mail onde ele está sendo perguntado qual a definição dele de OO no estilo que as pessoas fazem com os 4 pilares (ai ele fala que é retenção local do processo de dados, troca de mensagens, e late-binding extremo de todas as coisas), ai ele começa a explicar o que as pessoas entenderam errado na ideia dele, e ele comenta que um dos pontos que o pessoal não entende direito é o polimorfismo, pois não foi ele que cunhou o termo, não era isso que ele queria dizer, e nem faz muito sentido pensar nisso quando você não tem funções. Aqui a citação:

My math background made me realize that each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful. The term "polymorphism" was imposed much later (I think by Peter Wegner) and it isn't quite valid, since it really comes from the nomenclature of functions, and I wanted quite a bit more than functions. I made up a term "genericity" for dealing with generic behaviors in a quasi-algebraic form.

Dá para ver ele cita isso numa fase onde ele ainda estava chegando as conclusões que troca de mensagens era simplesmente um mecanismo diferente, ele até admite isso uns parágrafos antes.

Então não era uma questão de apego ou orgulho, é só que o cara perguntou para ele qual era a definição dele, e ele aproveitou para clarificar a situação toda já que ele estava sendo associado com ideias que não eram as dele, e não tinham nada a ver com as ideias dele de qualquer forma.

Simula deu origem ao sistema de objetos que usamos hoje em dia, mas não a POO.
Precisaria de clarificação aqui, mas acho que não. Talvez se considerar que os mecanismos não eram tão óbvios quanto em C++ e as linguagens que se inspiraram nela.

Sim e não, tem um ótimo texto que investiga a historiografia dos termos, e aconteceu de muita gente usar o mesmo termo para coisas totalmente diferentes ao mesmo tempo, e acabar todo mundo sendo colocado no mesmo saco já que o movimento geral não entendia a fundo as ideias de qualquer forma, achou tudo parecido, e deixou a gente nessa confusão toda. Aqui o link:https://www.hillelwayne.com/post/alan-kay/

Teve uma atualização nesse texto que diz que talvez o Kay não tenha cunhado o termo, mas eu diria que isso não invalida a questão, pois meu argumento não é só que ele foi o primeiro a usar o termo, e sim que ele foi o primeiro a usar o termo para descrever um paradigma (mesmo que bem acidentalmente, já que a própria história do Smalltalk mostra que não era exatamente disso que eles estavam atrás), já que por essa métrica, Simula também não chegou a inventar objetos, o termo já vinha sendo usado bem antes, inclusive só se chamou assim pois eles emprestaram o termo do paper do Hoare.

Conforme já falamos disso e falo mais nos links do meu outro comentário. As pessoas sequer entendem o que é um paradigma, e a Wikipedia faz o desserviço de ensinar errado.

É uma lástima mesmo que as pessoas não se aprofundem nisso, ironicamente, o cara que cunhou o termo também não sabia o que era um paradigma kkkkkkk. Eu gosto muito desse artigo que explica essa história: https://www.arxiv.org/pdf/2505.01901

A minha posição é algo entre a abordagem taxonômica original, que é mais ou menos como a gente entende paradigmas de programação no senso comum, e a abordagem mais formal do Peter Van Roy, eu gosto principalmente da ideia de que existem elementos anteriores ao conceito de paradigma, e conseguimos entender eles avaliando como eles se diferenciam nesses critérios, apesar disso, eu rejeito a direção que o campo tomou depois de formalismo extremo, e parece até que a própria academia tem balançado entre achar um meio termo das duas abordagens, pelo menos era assim até a última vez que eu estudei sobre o tema a fundo.

É daí que sai a noção de que OO é programar representando o mundo real pois a gente teve uma mudança de paradigma em como nos aproximamos do problema e modelamos sistemas.
Que é uma das maiores imbecilidades já ditas na computação. Mas atendia ao interesse do biólogo que criou isto.

Não foi o Kay que criou essa noção, isso na verdade era o interesse dos criadores de Simula, tanto que ela tem esse nome justamente pois eles queriam uma DSL que permitissem eles criar simulações do mundo real para poder simular transito numa cidade e coisas do tipo.

O Alan Kay fez a analogia com a biologia, mas ele tava interessado num modelo de computação inspirado em agentes autonomos que respondem a estimulos, e não representar o mundo real, tanto que a outra metade do que ele tinha em mente era o background matemático dele, que levava ele a buscar como algebra seria aplicada aqui.

Vamos combinar que Smalltalk é um completo fracasso porque as pessoas não querem pensar assim e Simula não teve nenhuma proeminência por questões mercadológicas (timing e ação).

Eu não chamaria Smalltalk de completo fracasso, quando ele nasceu ele até que foi bem popular, tanto que várias das coisas que persistem na cultura da programação até hoje (pro bem e pro mal) nasceram ali como o MVC, o movimento ágil, os design patterns (o livro era baseado em C++, mas ele também teve influencia do Smalltalk, tendo até um parágrafo dedicado a ele para falar de MVC), etc.

Eu também acho que essa percepção mudou, afinal é isso que vários devs back-end fazem o dia todo desde que microsserviços e arquiteturas orientadas a eventos viraram hype. A gente só usa termos diferentes, mas a visão que o Kay tinha em mente para um modelo de programação se materializou hoje com sistemas distribuídos.

Mas no campo de linguagens de programação, a comunidade Ruby é bem expressiva até para dizer que não existem pessoas que não gostam de pensar assim.

Fora isso, o conceito de state machines ficou relativamente popular no front-end, e enquanto tem diferenças significativas nas ideias, certamente elas não são a mesma coisa, também existem várias semelhanças, e isso aponta que as pessoas não rejeitam isso ineerentemente, é mais falta de marketing mesmo. Se virar hype você faz as pessoas gostarem de qualquer coisa, o Tailwind tá ai para provar isso.

Eu não tenho muito interesse em falar sobre Smalltalk ou OOP do Alan Kay, sobre troca de mensagens, porque eu não vejo tanto valor conceitual assim e não tem uso disseminado no mercado (que eu até ignoraria se fosse algo muito bom). O mesmo vale para Simula, eu nunca a usei, só serviu para entender melhor onde estamos.

Eu fui atrás pois eu tenho interesse na parte intelectual da coisa. Eu sinceramente não me importo muito se é útil ou não, ou se é usado no mercado ou não, o que me moveu a fazer essa pesquisa foi que eu tinha muita curiosidade sobre a resposta do que seria OO, e como não tinha uma resposta única (inclusive um dos meus pontos de partida anos atrás foi a sua resposta no Stack Overflow), fui atrás de pesquisar a história do termo, opiniões online, e qualquer coisa mesmo que me ajudasse a chegar mais perto da resposta.

Talvez porque eu comecei com PHP onde não se tem primitivos na forma de objetos, Smalltalk me pareceu super interessante logo de cara, pois a ideia de que você não precisa de um for, você pode representar isso puramente com uma mensagem timesRepeat de um objeto Int, foi mind blowing, só isso já valeu ter ido atrás do tema, mudou minha perspectiva sobre como modelar boas APIs dos meus módulos, já que elas deveriam corresponder ao que você consegue derivar dos dados que mantém aquele conjunto coeso.

Outra coisa que me interessou logo de cara foi ver como você poderia modelar um if sem uma estrutura de controle de fluxo, e sem usar high order functions (que é aquele boolean encoding clássico do lambda calculus), eu achei bem interessante como você consegue atingir isso usando simplesmente herança como um isomorfismo pra union types.

Eu também tinha um interesse por entender a cabeça de quem fazia o design das APIs da linguagem para ver como ele ia pensar em usar os princípios basilares na prática.

E também tinha interesse em entender como pensavam os programadores da época, então eu li o livro Smalltalk by Example (que me fez criar um interesse tremendo sobre como Tell Don't Ask é muito mais do que só um conselho legal, se você leva ele as últimas consequências, ele vira mais algo como o "evite efeitos colaterais" da FP).

Atualmente eu to lendo o livro de design patterns do Kent Beck que é sobre patterns do Smalltalk em si, e não o clássico do GoF (acho que esse livro veio até antes).

Eu realmente tinha interesse em descobrir se troca de mensagens era só um nome legal para duck typing igual alguns Rubystas argumentam (o que tornaria ele tão não um paradigma quanto a tradição de Simula), ou se tinha um valor real na prática como um modelo distinto de computação.

E, bom, acontece que tem sim, e muito.

Toda a discussão que você tem na galera de microsserviços sobre usar orquestração ou coreografia, essencialmente é sobre desenhar algo com a mentalidade procedural, ou com a mentalidade orientada a objetos.

No campo prático, o paper das HOMs (aqui o link para essa jóia: https://dl.acm.org/doi/10.1145/1146841.1146844) elucida muitas das inovações que a gente poderia ter em APIs mais expressivas em linguagens de programação se elas fossem uma realidade.

Como eu disse Promises transparentes também me parecem ser algo muito útil na prática, visto que isso eliminaria a necessidade de async/await nas linguagens.

Em Smalltalk isso era bem lento, mas existem trabalhos posteriores que mostram que isso poderia ser feito de forma performática se as linguagens tivessem first-class support para isso.

E mesmo pro nível mais mainstream, eu diria que se aprofundar em como estruturar um programa em torno do TDA pode ser um ótimo exercício e que pode ser aplicado até em algumas linguagens mainstream com sistema de tipos estrutural.

A leitura do livro Pratical Object Oriented Design in Ruby da Sandi Metz é bem didático nesse sentido.

Eu não diria que o TDA sozinho seria a coisa mais pura do mundo, e boa parte dos conselhos do livro só é possível em sistemas de tipos estruturais (de preferencia sem tipagem estática), mas não é impossível aplicar aquilo em linguagens estáticas se você tiver um type system com inferencia agressiva como é o da linguagem Crystal.

Eu diria que boa parte das linguagens se beneficiaria simplesmente de copiar o type system do Crystal mesmo sem se importar com toda essa bagagem da OO raíz do Alan Kay.

Então, pelo menos para mim, OO é algo que poderia ser bem relevante é só que infelizmente a tradição não prosperou muito então pouca gente conhece o verdadeiro potencial que essas ideias tinham.

Mas quanto mais eu leio, mais a frente de seu tempo eu vejo que elas eram.