Explore as ideias centrais de Alan Kay sobre Smalltalk e as primeiras GUIs — e como elas moldaram a visão atual de software como sistemas de objetos que interagem.
Alan Kay não é apenas um nome da história da programação. Muitas suposições cotidianas que temos sobre computadores — o que é uma “janela”, por que o software deve ser interativo, como programas podem ser construídos a partir de partes que cooperam — foram moldadas por ideias que ele promoveu (muitas vezes com equipes no Xerox PARC).
Este post trata de conceitos, não de curiosidades. Você não precisa saber programar para acompanhá‑lo, e não encontrará um tour por detalhes técnicos obscuros. Em vez disso, focaremos em alguns modelos mentais que ainda aparecem nas ferramentas e produtos que usamos: como o software pode ser compreendido, modificado e aprendido.
Primeiro, Smalltalk: não apenas uma linguagem, mas todo um ambiente de trabalho que encorajava exploração e aprendizagem.
Segundo, GUIs (interfaces gráficas): janelas, ícones, menus — software interativo como algo que você manipula diretamente, não apenas instrui.
Terceiro, pensamento em sistemas: ver o software como um conjunto de partes que interagem com loops de feedback, em vez de um amontoado de arquivos de código.
Não trata Kay como um gênio solitário, nem afirma que um paradigma “certo” resolve tudo. Algumas ideias funcionaram brilhantemente, outras foram mal compreendidas, e algumas não se espalharam tanto quanto poderiam.
O objetivo é prático: ao final, você deve conseguir olhar para apps e bases de código modernas com mais clareza sobre por que elas são como são — e o que pode aproveitar no seu próximo projeto.
Alan Kay entrou em uma cultura de computação poderosa, cara e em grande parte indiferente às pessoas comuns. Computadores eram tratados como infraestrutura compartilhada: você reservava tempo, submetia trabalhos e esperava resultados. Esse modelo moldava tudo — a aparência dos programas, quem os usava e o que significava “sucesso”.
Para muitos usuários, computação significava entregar um trabalho para a máquina (via cartões ou terminais em fila) e receber a saída depois. Se algo dava errado, você não “fuçava” para aprender — reenviava e esperava novamente. A exploração era lenta, e o computador parecia mais um serviço remoto do que uma ferramenta com a qual pensar.
O alvo de Kay não era simplesmente “computadores menores”. Era uma relação diferente: um computador como meio pessoal para aprender, escrever, simular, desenhar e construir ideias — especialmente para crianças e não especialistas. Isso exigia imediaticidade. Era preciso ver o efeito das ações, revisar rapidamente e manter um fluxo criativo.
Para perseguir esse tipo de mudança, precisava haver espaço para experimentar hardware, software e design de interação juntos. Laboratórios de pesquisa como o Xerox PARC financiaram apostas longas: novos displays, novos dispositivos de entrada, novos modelos de programação e maneiras de empacotá‑los numa experiência coerente. O objetivo não era lançar um recurso — era inventar um novo tipo de uso do computador.
Se o computador ia ser uma máquina de aprendizagem e criação, usabilidade não podia ser um detalhe. A interface tinha de suportar descoberta, feedback e ações compreensíveis. Esse foco empurrou Kay para sistemas onde o “jeito” da interação — o que acontece quando você clica, edita ou explora — estava ligado à forma como o software era estruturado.
Alan Kay não começou com “Como acelerar o trabalho de escritório?”. Ele começou com outra pergunta: e se uma criança pudesse carregar um computador pessoal como um livro, e usá‑lo para explorar ideias, fazer coisas e aprender fazendo? Esse pensamento virou o Dynabook — menos uma especificação de produto e mais uma estrela guia para a computação pessoal.
O Dynabook foi imaginado como leve, com bateria e sempre disponível. Mas a palavra mais importante não era “portátil”. Era “pessoal”. Esse computador pertenceria ao usuário do mesmo modo que um caderno ou instrumento — algo que você molda ao longo do tempo, não apenas opera.
Igualmente importante: tinha de ser aprendível. O objetivo de Kay não era esconder a computação atrás de um muro de menus; era deixar que as pessoas se tornassem autoras gradualmente, não apenas consumidoras.
Os “killer apps” do Dynabook eram ler, escrever, desenhar, compor música, simular experimentos científicos e construir histórias interativas. Tratava a programação como literacia — outra forma de expressar ideias — em vez de um ofício especializado reservado a profissionais.
Esse foco muda o que “bom software” significa. Uma ferramenta de aprendizagem deve convidar ao mexer, dar feedback rápido e tornar seguro tentar novamente.
É aqui que Smalltalk e as primeiras interfaces gráficas entram. Se você quer que pessoas criem, precisa de manipulação direta, resultados imediatos e um ambiente onde experimentar seja natural. O sistema vivo e interativo do Smalltalk e as metáforas visuais da GUI apoiavam o mesmo objetivo: encurtar a distância entre uma ideia e um artefato funcionando.
O Dynabook não estava “prevendo o tablet”. Propunha uma nova relação com a computação: um meio para pensar e criar. Muitos dispositivos podem chegar perto disso, mas a visão trata de empoderar usuários — especialmente aprendizes —, não de um tamanho de tela ou design de hardware específico.
Quando as pessoas ouvem “Smalltalk”, frequentemente imaginam uma linguagem de programação. A equipe de Kay o tratou como algo maior: um sistema completo onde linguagem, ferramentas e experiência do usuário foram projetadas como uma única coisa.
Em termos simples, Smalltalk é um sistema onde tudo é um objeto. As janelas na tela, o texto que você digita, os botões que clica, os números que calcula — cada um é um objeto que você pode pedir para fazer coisas.
Smalltalk foi construído para aprender fazendo. Em vez de escrever código, compilar e torcer para que funcione, você podia inspecionar objetos enquanto o sistema rodava, ver seu estado atual, alterá‑los e experimentar uma nova ideia imediatamente.
Essa vivacidade importava porque transformava programar em exploração. Você não estava apenas produzindo arquivos; estava moldando um mundo em execução. Isso encorajava curiosidade: “O que é essa coisa?” “O que ela contém?” “O que acontece se eu mexer aqui?”
As ferramentas de desenvolvimento do Smalltalk não eram complementos separados. Navegadores, inspetores, depuradores e editores faziam parte do mesmo universo baseado em objetos. As ferramentas entendiam o sistema por dentro, porque foram construídas no mesmo meio.
Essa integração mudou a sensação de “trabalhar em software”: menos gerenciar código distante, mais interagir diretamente com o sistema que você está construindo.
Pense em editar um documento enquanto ele está aberto e responsivo — mudanças de formatação aparecem instantaneamente, você pode procurar, reorganizar e desfazer sem “reconstruir” o documento. O Smalltalk buscava esse tipo de imediaticidade, mas para programas: você edita o que está rodando, vê resultados na hora e segue em frente.
A ideia mais útil de Kay não é “classes e herança”. É a noção de que um objeto é um pequeno computador autônomo: guarda seu próprio estado (o que sabe agora) e decide como responder quando você pede algo.
Pense em cada objeto como tendo:
Esse enquadramento é prático porque muda o foco de “onde os dados estão armazenados?” para “quem é responsável por isso?”
Uma confusão comum é tratar objetos como registros de dados sofisticados: um feixe de campos com algumas funções auxiliares. Nessa visão, outras partes do programa mexem livremente nos internos.
A visão de Kay aproxima‑se mais de atores em um sistema. Você não abre o objeto e remexe suas gavetas. Você lhe envia um pedido e deixa que ele gerencie seu próprio estado. Essa separação é o ponto central.
Passagem de mensagens é simplesmente pedido/resposta.
Imagine um café: você não entra na cozinha para fazer sua refeição. Você faz um pedido (“faça um sanduíche”) e recebe um resultado (“aqui está seu sanduíche” ou “acabou o pão”). O café decide como cumprir o pedido.
Objetos de software funcionam da mesma forma: você envia uma mensagem (“calcule o total”, “salve”, “renderize‑se”) e o objeto responde.
Quando outras partes do sistema dependem apenas de mensagens, você pode mudar como um objeto funciona internamente — trocar algoritmos, alterar armazenamento, adicionar cache — sem forçar reescritas em todo lugar.
É assim que sistemas crescem sem quebrar tudo: acordos estáveis nas fronteiras e liberdade dentro dos componentes.
As pessoas frequentemente tratam “programação orientada a objetos” como sinônimo de “usar classes”. Isso é compreensível — a maioria das linguagens ensina POO por diagramas de classes e árvores de herança. Mas a ênfase original de Kay era diferente: pense em termos de peças que se comunicam.
Uma classe é uma planta: descreve o que algo sabe e o que pode fazer.
Uma instância (ou objeto) é uma coisa concreta criada a partir dessa planta — seu “um daquele”.
Um método é uma operação que o objeto pode executar quando solicitado.
Estado é os dados atuais do objeto: o que ele lembra agora, que pode mudar com o tempo.
Smalltalk ajudou a popularizar um modelo uniforme de objetos: tudo é um objeto, e você interage com objetos de forma consistente. Também enfatizou passagem de mensagens — você não mexe nos internos de outro objeto; você envia uma mensagem e deixa ele decidir o que fazer.
Esse estilo combina bem com binding tardio (via despacho dinâmico): o programa decide em tempo de execução qual método trata uma mensagem, baseado no objeto receptor. O benefício prático é flexibilidade: você troca comportamentos sem reescrever o chamador.
Uma boa regra: projete pensando em interações. Pergunte “Quais mensagens devem existir?” e “Quem deve possuir este estado?” Se os objetos colaborarem de forma limpa, a estrutura de classes tende a ficar mais simples — e mais favorável à mudança — quase como efeito colateral.
Uma interface gráfica mudou a sensação de “usar software”. Em vez de memorizar comandos, você aponta para coisas, move‑as, abre‑as e vê resultados imediatamente. Janelas, menus, controles e ícones fizeram a computação parecer mais próxima de manipular objetos físicos — manipulação direta em vez de instrução abstrata.
Essa “coisificação” mapeia naturalmente para um modelo de objetos. Em uma GUI bem desenhada, quase tudo que você vê e com que interage pode ser tratado como um objeto:
Isso não é só conveniência de programação; é uma ponte conceitual. O usuário pensa em termos de objetos (“mova esta janela”, “clique naquele botão”) e o software é construído de objetos que realmente podem executar essas ações.
Quando você clica, digita ou arrasta, o sistema gera um evento. Em uma visão orientada a objetos, um evento é essencialmente uma mensagem enviada a um objeto:
Objetos podem então encaminhar mensagens a outros (“diga ao documento para salvar”, “diga à janela para redesenhar”), criando uma cadeia de interações compreensíveis.
Porque a UI é composta por objetos persistentes com estado visível, ela parece entrar em um espaço de trabalho em vez de executar um comando único. Você pode deixar janelas abertas, arrumar ferramentas, voltar a um documento e retomar de onde parou. A GUI vira um ambiente coerente — um lugar onde ações são conversas entre objetos que você pode ver.
Uma das ideias mais distintivas do Smalltalk não era uma característica de sintaxe — era a imagem. Em vez de pensar um programa como “código fonte que compila para um app”, o Smalltalk tratava o sistema como um mundo em execução de objetos. Quando você salvava, podia salvar o ambiente vivo inteiro: objetos na memória, ferramentas abertas, estado da UI e o estado atual do seu trabalho.
Um sistema baseado em imagem é como pausar um filme e salvar não só o roteiro, mas o quadro exato, o cenário e a posição de cada ator. Ao retomar, você volta ao ponto onde parou — com ferramentas abertas, objetos ainda existentes e suas alterações já em movimento.
Isso sustentava loops de feedback apertados. Você podia mudar um comportamento, testar imediatamente, observar o que aconteceu e refinar — sem o reset mental de “reconstruir, relançar, recarregar dados, navegar de volta à tela”.
O mesmo princípio aparece em fluxos modernos de “vibe‑coding”: quando você descreve uma mudança em linguagem natural, a vê aplicada de imediato e itera, aprende o sistema mais rápido e mantém o ímpeto. Plataformas como Koder.ai exploram isso transformando construção de apps em um loop conversacional — planejar, ajustar, pré‑visualizar — enquanto ainda produzem código real que você pode exportar e manter.
Você pode ver ecos da ideia de imagem em recursos valorizados hoje:
Não são idênticos às imagens Smalltalk, mas compartilham o objetivo: manter a distância entre ideia e resultado o mais curta possível.
Salvar um mundo em execução traz questões difíceis. A reprodutibilidade pode sofrer se “a verdade” mora em estado mutável em vez de um processo de build limpo. Deploys ficam mais complicados: enviar uma imagem pode confundir app, dados e ambiente. Depurar também pode ser mais complexo quando bugs dependem de uma sequência particular de interações e estado acumulado.
A aposta do Smalltalk foi que aprendizado e iteração mais rápidos valiam essas complicações — e essa aposta ainda influencia como muitas equipes pensam sobre experiência de desenvolvedor.
Quando Alan Kay falava de software, muitas vezes via‑o menos como um monte de código e mais como um sistema: várias partes interagindo ao longo do tempo para produzir o comportamento que você deseja.
Um sistema não é definido por um componente isolado. É definido por relacionamentos — quem fala com quem, o que podem pedir e o que acontece quando essas conversas se repetem.
Alguns componentes simples podem criar comportamento complexo quando você adiciona repetição e feedback. Um temporizador que tica, um modelo que atualiza estado e uma UI que redesenha podem ser simples. Juntos, produzem animações, desfazer/refazer, autosave, alertas e aqueles momentos de “por que isso mudou?”.
Por isso o pensamento em sistemas é prático: ele força você a procurar loops (“quando A muda, B reage, o que aciona C…”) e tempo (“o que acontece após 10 minutos de uso?”), não apenas chamadas de função pontuais.
Num sistema, interfaces importam mais que implementação. Se uma parte só pode interagir com outra por mensagens claras (“incrementa contador”, “renderiza”, “registra evento”), você pode trocar internals sem reescrever todo o resto.
Isso está muito próximo da ênfase de Kay em passagem de mensagens: você não controla diretamente outras partes; você pede, elas respondem.
Imagine três objetos:
Fluxo ao longo do tempo:
clicked.increment ao CounterModel.changed(newValue).changed e redesenha.record("increment", newValue).Nenhum componente precisa bisbilhotar o outro. O comportamento emerge da conversa.
Alan Kay defendia uma ideia simples que ainda soa radical: software deve ser fácil de aprender, não apenas poderoso. Design “esperto” frequentemente otimiza pela satisfação do criador — atalhos, truques escondidos, abstrações densas — deixando usuários comuns presos memorizando rituais.
Kay se importava com simplicidade porque ela escala: um conceito que um iniciante entende rápido é algo que times podem ensinar, compartilhar e ampliar.
Muito software trata usuários como operadores: aperte os botões certos, obtenha a saída. O objetivo de Kay era mais próximo de uma ferramenta de pensamento — algo que convida à exploração, suporta tentativa e erro e deixa as pessoas construir modelos mentais.
Por isso ele valorizava sistemas interativos onde você vê o que acontece e ajusta enquanto trabalha. Quando o sistema responde imediatamente e de forma significativa, aprender passa a ser parte do uso.
Kay frequentemente usava a aprendizagem — às vezes imaginando crianças como usuários — como força para clareza. Se um conceito pode ser manipulado diretamente, inspecionado e explicado sem rodeios, é mais provável que funcione para todos.
Isso não significa “projetar só para crianças”. Significa usar ensinabilidade como teste de qualidade: o sistema pode revelar sua própria lógica?
Aprendibilidade é um recurso de produto. Você pode projetar para isso ao:
O ganho não é só iniciantes mais felizes. É onboarding mais rápido, menos tickets de suporte e um produto que as pessoas se sentem confiantes para estender — exatamente o tipo de “agência do usuário” que Kay queria amplificar.
O trabalho de Kay não “inventou tudo o que usamos hoje”, mas influenciou fortemente como muitos pensam sobre construir software — especialmente software voltado a humanos, não apenas máquinas.
Muitas práticas modernas ecoam ideias que o Smalltalk e a cultura do Xerox PARC concretizaram e popularizaram:
Alguns aspectos da visão original não foram tão bem preservados:
Se você olhar de relance, muitos padrões atuais rimam com passagem de mensagens: UIs baseadas em componentes (React/Vue), aplicações orientadas a eventos e até microservices comunicando via HTTP ou filas. Não são a mesma coisa — mas mostram como a ideia central de Kay (sistemas como partes que interagem) continua a ser reinterpretada sob restrições modernas.
Se você quer uma ponte prática da história para a prática, a última seção (veja /blog/practical-takeaways) transforma essas influências em hábitos de design que você pode usar já.
O trabalho de Kay pode soar filosófico, mas se traduz em hábitos muito práticos. Você não precisa usar Smalltalk — ou mesmo “fazer POO” — para se beneficiar. O objetivo é construir software que permaneça compreensível à medida que cresce.
Ao começar (ou refatorar), tente descrever o sistema como um conjunto de papéis que trabalham juntos:
Isso mantém o foco em responsabilidades, não em “usar classes porque precisamos de classes”.
Antes de discutir tabelas de banco ou hierarquias de classes, defina as mensagens — o que uma parte pede à outra.
Um exercício útil: escreva uma breve “conversa” para uma ação do usuário:
Só depois decida como esses papéis serão implementados (classes, módulos, serviços). Isso coloca comportamento primeiro, estrutura depois — alinhado com a ênfase de Kay em passagem de mensagens.
Kay se preocupava com sistemas vivos onde você vê os efeitos das mudanças rapidamente. Num time moderno, isso normalmente significa:
Se você não consegue dizer o que mudou — ou se ajudou — está voando às cegas.
Se você está construindo com um fluxo conduzido por chat (por exemplo, em Koder.ai), o mesmo conselho vale: trate prompts e saída gerada como forma de iterar mais rápido, mas mantenha fronteiras explícitas e use salvamentos/snapshots e exportação de código para que o sistema permaneça compreensível ao longo do tempo.
Se essa seção ressoou, explore:
Esses tópicos são menos sobre nostalgia e mais sobre desenvolver gosto: como construir software que seja aprendível, adaptável e coerente como sistema.
Alan Kay defendia uma relação diferente com os computadores: não trabalhos em lote enfileirados, mas um meio pessoal e interativo para aprender e criar.
Essa mentalidade moldou expectativas que hoje consideramos normais — retorno imediato, interfaces manipuláveis e software que pode ser explorado e modificado enquanto você trabalha.
O Dynabook foi uma visão de um computador portátil e pessoal projetado principalmente para aprendizagem e criatividade (leitura, escrita, desenho, simulação).
Não se trata tanto de “ele previu tablets” quanto de “ele definiu como a computação capacitadora deveria se sentir”: usuários como autores, não apenas operadores.
No Smalltalk, linguagem, ferramentas e interface formavam um único ambiente coerente.
Na prática, isso significa que você podia inspecionar objetos em execução, alterar comportamentos, depurar interativamente e continuar trabalhando sem reconstruir e reiniciar constantemente — encurtando a distância entre ideia e resultado.
A ideia central de Kay não era “classes e herança”, mas objetos como agentes independentes que se comunicam enviando mensagens.
Em termos de design, isso leva você a definir limites claros: chamadores dependem das mensagens que um objeto aceita, não da disposição interna dos seus dados.
Um erro comum é tratar POO como uma taxonomia de tipos: muitas classes, herança profunda e dados mutáveis compartilhados.
Uma regra prática segundo Kay:
As GUIs fazem o software parecer algo que você manipula — janelas, botões, ícones — e isso mapeia bem para um modelo de objetos onde cada elemento de UI tem estado e comportamento.
Ações do usuário (cliques, arrastos, teclas) viram eventos que, em termos práticos, são mensagens enviadas a objetos, que podem repassar solicitações pelo sistema.
Uma imagem Smalltalk salva o mundo em execução: objetos na memória, ferramentas abertas, estado da UI e seu trabalho atual.
Benefícios:
Compromissos:
O pensamento em sistemas foca no comportamento ao longo do tempo: loops de feedback, reações em cadeia e quem conversa com quem.
Na prática, isso leva a designs com interfaces mais claras (mensagens) e menos dependências ocultas, porque você trata o aplicativo como partes que interagem — não apenas funções isoladas.
Use um design message-first para um fluxo de trabalho:
getTotal, isAvailable, authorize).Só então escolha implementações (classes, módulos, serviços). O checklist em /blog/practical-takeaways é um bom ponto de partida.
Ferramentas modernas frequentemente rimam com os objetivos de Kay, mesmo que os implementem de forma diferente:
Não são iguais às imagens do Smalltalk, mas perseguem o mesmo resultado prático: tornar mudança e aprendizado baratos.