Explora las ideas clave de Alan Kay sobre Smalltalk y las primeras GUI, y cómo moldearon la visión actual del software como sistemas de objetos que interactúan.
Alan Kay no es solo un nombre de la historia de la programación. Muchas suposiciones cotidianas sobre los ordenadores —qué es una “ventana”, por qué el software debería ser interactivo, cómo construir programas a partir de partes que cooperan— fueron moldeadas por ideas que promovió (a menudo con equipos en Xerox PARC).
Esta entrada va de conceptos, no de curiosidades. No necesitas saber programar para seguirla, y no encontrarás un recorrido por detalles técnicos oscuros. En cambio, nos centraremos en algunos modelos mentales que siguen apareciendo en las herramientas y productos que usamos: cómo el software puede ser comprendido, cambiado y aprendido.
Primero, Smalltalk: no solo un lenguaje de programación, sino un entorno de trabajo completo que fomentaba la exploración y el aprendizaje.
Segundo, las interfaces gráficas (GUI): ventanas, iconos, menús—software interactivo que puedes manipular directamente, no solo instruir.
Tercero, pensamiento en sistemas: ver el software como un conjunto de partes que interactúan con bucles de retroalimentación, en lugar de un montón de archivos de código.
No tratará a Kay como un genio solitario, ni afirmará que un único paradigma “correcto” lo arregla todo. Algunas ideas funcionaron de maravilla, otras se malinterpretaron y otras no se difundieron tanto como podrían.
El objetivo es práctico: al final deberías poder mirar aplicaciones y bases de código modernas con una idea más clara de por qué se sienten como se sienten—y qué puedes tomar prestado para tu próximo proyecto.
Alan Kay llegó a una cultura informática potente, cara y en gran medida indiferente a la gente común. Los ordenadores se trataban como infraestructura compartida: reservabas tiempo, presentabas trabajos y esperabas resultados. Ese modelo moldeó todo: cómo eran los programas, quién podía usarlos y qué significaba “éxito”.
Para muchos usuarios, computar significaba entregar un trabajo a la máquina (a menudo mediante tarjetas o terminales en cola) y recibir salida más tarde. Si algo fallaba, no “curioseabas” para aprender: volvías a enviar y aguardabas otra vez. La exploración era lenta y el ordenador se sentía más como un servicio remoto que como una herramienta con la que pensar.
El objetivo de Kay no fue simplemente “ordenadores más pequeños”. Fue una relación distinta: el ordenador como un medio personal para aprender, escribir, simular, dibujar y construir ideas—especialmente para niños y no especialistas. Eso requería inmediatez. Tenías que ver lo que hacían tus acciones, revisar rápidamente y mantener un flujo creativo.
Para perseguir ese cambio necesitabas espacio para experimentar con hardware, software y diseño de interacción juntos. Los laboratorios de investigación como Xerox PARC financiaron apuestas a largo plazo: nuevas pantallas, nuevos dispositivos de entrada, nuevos modelos de programación y formas de empaquetarlos en una experiencia coherente. La meta no era lanzar una característica: era inventar una nueva manera de usar el ordenador.
Si el ordenador iba a ser una máquina para aprender y crear, la usabilidad no podía ser una ocurrencia tardía. La interfaz debía apoyar el descubrimiento, la retroalimentación y acciones comprensibles. Ese enfoque empujó a Kay hacia sistemas donde el “feeling” de la interacción—qué ocurre al hacer clic, editar o explorar—estaba estrechamente conectado con cómo estaba estructurado el propio software.
Alan Kay no empezó con “¿Cómo hacemos más rápido el trabajo de oficina?” Empezó con otra pregunta: ¿y si un niño pudiera llevar un ordenador personal como un libro y usarlo para explorar ideas, hacer cosas y aprender haciendo? Esa idea se convirtió en el Dynabook—menos una especificación de producto y más una estrella del norte para la computación personal.
El Dynabook se imaginó ligero, con batería y siempre disponible. Pero la palabra más importante no era “portátil”. Era “personal”. Este ordenador pertenecería a su usuario del mismo modo que una libreta o un instrumento—algo que moldeas con el tiempo, no algo que simplemente manejas.
Igualmente importante: debía ser aprendible. El objetivo de Kay no era ocultar la computación tras un muro de menús; quería que la gente se convirtiera gradualmente en autor, no solo en consumidora.
Las “killer apps” del Dynabook eran leer, escribir, dibujar, componer música, simular experimentos científicos y construir historias interactivas. Consideraba la programación como una alfabetización—otra forma de expresar ideas—en lugar de un oficio especializado reservado a profesionales.
Ese enfoque cambia lo que significa “buen software”. Una herramienta de aprendizaje debe invitar a trastear, dar retroalimentación rápida y hacer seguro intentarlo de nuevo.
Aquí encajan Smalltalk y las primeras GUI. Si quieres que la gente cree, necesitas manipulación directa, resultados inmediatos y un entorno donde experimentar resulte natural. El sistema vivo e interactivo de Smalltalk y las metáforas visuales de la GUI apoyaban el mismo objetivo: acortar la distancia entre una idea y un artefacto funcional.
El Dynabook no “predijo la tableta”. Propuso una nueva relación con la computación: un medio para el pensamiento y la creación. Muchos dispositivos pueden acercarse a esa idea, pero la visión trata de empoderar a los usuarios—especialmente a los aprendices—no de un tamaño de pantalla u diseño de hardware concreto.
Cuando la gente oye “Smalltalk” a menudo piensa en un lenguaje de programación. El equipo de Kay lo trató como algo mayor: un sistema de trabajo completo donde lenguaje, herramientas y experiencia de usuario estaban diseñados como una unidad.
En términos sencillos, Smalltalk es un sistema donde todo es un objeto. Las ventanas en pantalla, el texto que escribes, los botones que pulsas, los números que calculas—cada uno es un objeto al que puedes pedir cosas.
Smalltalk se construyó para aprender haciendo. En lugar de escribir código, compilar y esperar que funcione, podías inspeccionar objetos mientras el sistema estaba en ejecución, ver su estado actual, modificarlos y probar una idea de inmediato.
Esa vivacidad importaba porque convertía la programación en exploración. No estabas solo produciendo archivos; estabas moldeando un mundo en ejecución. Fomentaba la curiosidad: “¿Qué es esta cosa?” “¿Qué contiene?” “¿Qué pasa si la modifico?”
Las herramientas de desarrollo de Smalltalk no eran complementos separados. Navegadores, inspectores, depuradores y editores eran parte del mismo universo basado en objetos. Las herramientas comprendían el sistema desde dentro porque estaban construidas en el mismo medio.
Esa integración cambió la sensación de “trabajar en software”: menos como gestionar código distante y más como interactuar directamente con el sistema que estás construyendo.
Piensa en editar un documento mientras está abierto y responde—los cambios de formato son instantáneos, puedes buscar, reorganizar y deshacer sin “reconstruir” antes. Smalltalk aspiraba a esa inmediatez, pero para programas: editas la cosa en ejecución, ves resultados al instante y sigues avanzando.
La idea más útil de Kay no es “clases y herencia”. Es pensar que un objeto es un pequeño ordenador autosuficiente: mantiene su propio estado (lo que sabe ahora) y decide cómo responder cuando le pides que haga algo.
Imagina que cada objeto tiene:
Este encuadre es práctico porque cambia el foco de “¿dónde se almacena el dato?” a “¿quién es responsable de manejar esto?”
Una confusión común es tratar a los objetos como estructuras de datos sofisticadas: un paquete de campos con algunas funciones auxiliares. En esa visión, otras partes del programa miran libremente dentro y manipulan los internos.
La visión de Kay se acerca más a los actores en un sistema. No se entra en un objeto para reorganizar sus cajones. Le envías una petición y dejas que gestione su propio estado. Esa separación es el punto entero.
El envío de mensajes es simplemente petición/respuesta.
Imagina un café: no entras a la cocina para cocinar tu propia comida. Haces un pedido (“hazme un sándwich”) y recibes un resultado (“aquí está tu sándwich” o “nos quedamos sin pan”). El café decide cómo cumplir la petición.
Los objetos de software funcionan igual: envías un mensaje (“calcula el total”, “guarda”, “représentate”), y el objeto responde.
Cuando otras partes del sistema dependen solo de mensajes, puedes cambiar cómo funciona un objeto internamente—cambiar algoritmos, modificar almacenamiento, añadir cachés—sin forzar reescrituras en todas partes.
Así es como los sistemas crecen sin romperlo todo: acuerdos estables en los límites y libertad dentro de los componentes.
La gente suele usar “orientado a objetos” como sinónimo de “usar clases”. Es comprensible: la mayoría de lenguajes enseñan OOP mediante diagramas de clases y árboles de herencia. Pero el énfasis original de Kay era distinto: piensa en piezas que se comunican.
Una clase es un plano: describe lo que algo sabe y lo que puede hacer.
Una instancia (u objeto) es una cosa concreta hecha a partir de ese plano—tu ejemplar particular.
Un método es una operación que el objeto puede ejecutar cuando se le solicita.
El estado es la información actual del objeto: lo que recuerda ahora, y que puede cambiar con el tiempo.
Smalltalk popularizó un modelo uniforme de objetos: todo es un objeto y se interactúa con ellos de forma consistente. También insistió en el envío de mensajes: no fisgas en los internos de otro objeto; le mandas un mensaje y él decide.
Ese estilo va de la mano con el enlace tardío (a menudo mediante despacho dinámico): el programa decide en tiempo de ejecución qué método manejará un mensaje, según el objeto receptor. El beneficio práctico es flexibilidad: puedes intercambiar comportamientos sin reescribir al que llama.
Una regla útil: diseña en torno a interacciones. Pregunta “¿qué mensajes deberían existir?” y “¿quién debe poseer este estado?” Si los objetos colaboran limpiamente, la estructura de clases suele simplificarse—y volverse más manejable—casi como efecto secundario.
Una interfaz gráfica cambió la sensación de “usar software”. En lugar de memorizar comandos, podías señalar cosas, moverlas, abrirlas y ver resultados de inmediato. Ventanas, menús, controles e iconos hicieron que la computación se sintiera más cerca de manipular objetos físicos—manipulación directa en lugar de instrucciones abstractas.
Esa “cualidad de cosa” encaja naturalmente con un modelo de objetos. En una GUI bien diseñada, casi todo lo que ves e interactúas puede tratarse como un objeto:
Esto no es solo una conveniencia de programación; es un puente conceptual. El usuario piensa en términos de objetos (“mueve esta ventana”, “haz clic en ese botón”) y el software está construido con objetos que realmente pueden realizar esas acciones.
Cuando haces clic, escribes o arrastras, el sistema genera un evento. En una visión orientada a objetos, un evento es esencialmente un mensaje enviado a un objeto:
Los objetos pueden reenviar entonces mensajes a otros objetos (“dile al documento que guarde”, “dile a la ventana que redibuje”), creando una cadena de interacciones comprensibles.
Porque la UI está hecha de objetos persistentes con estado visible, se siente como entrar en un espacio de trabajo en vez de ejecutar un comando único. Puedes dejar ventanas abiertas, ordenar herramientas, volver a un documento y retomar donde lo dejaste. La GUI se convierte en un entorno coherente—uno en el que las acciones son conversaciones entre objetos que puedes ver.
Una de las ideas más distintivas de Smalltalk no fue una característica de sintaxis, sino la imagen. En vez de pensar en un programa como “código fuente que se compila en una app”, Smalltalk trataba el sistema como un mundo en ejecución de objetos. Cuando guardabas, podías almacenar todo el entorno vivo: objetos en memoria, herramientas abiertas, estado de UI y el trabajo en curso.
Un sistema basado en imágenes es como pausar una película y guardar no solo el guion, sino el fotograma exacto, el decorado y la posición de cada actor. Cuando reanudas, vuelves al punto en el que estabas—con tus herramientas abiertas, tus objetos aún presentes y tus cambios ya en movimiento.
Esto apoyaba bucles de retroalimentación cerrados. Podías cambiar un comportamiento, probarlo de inmediato, observar qué ocurría y refinar—sin el reinicio mental de “recompilar, relanzar, recargar datos, navegar de nuevo a la pantalla”.
Ese mismo principio aparece en flujos de trabajo modernos de “vibe-coding”: cuando puedes describir un cambio en lenguaje natural, verlo aplicado al instante y iterar, aprendes más rápido y mantienes el momentum. Plataformas como Koder.ai explotan esto convirtiendo la creación de apps en un bucle conversacional—planifica, ajusta, previsualiza—mientras siguen generando código real que puedes exportar y mantener.
Se ven ecos de la idea de imagen en funciones que la gente aprecia hoy:
No son idénticas a las imágenes de Smalltalk, pero comparten la meta: mantener la distancia entre la idea y su resultado lo más corta posible.
Guardar un mundo en ejecución plantea preguntas difíciles. La reproducibilidad puede sufrir si “la verdad” vive en un estado mutable en vez de en un proceso de construcción limpio. El despliegue se complica: distribuir una imagen puede difuminar la línea entre app, datos y entorno. Depurar también puede ser más complejo cuando los errores dependen de una secuencia particular de interacciones y del estado acumulado.
La apuesta de Smalltalk fue que aprender e iterar más rápido valía esos inconvenientes—y esa apuesta sigue influyendo en cómo muchos equipos piensan sobre la experiencia del desarrollador.
Cuando Alan Kay hablaba de software, a menudo lo trataba menos como un montón de código y más como un sistema: muchas partes que interactúan a lo largo del tiempo para producir el comportamiento que te importa.
Un sistema no se define por un único componente. Se define por relaciones—quién le habla a quién, qué pueden pedir y qué ocurre cuando esas conversaciones se repiten.
Unas pocas piezas simples pueden crear comportamientos complejos cuando añades repetición y retroalimentación. Un temporizador que hace tics, un modelo que actualiza estado y una UI que redibuja pueden ser sencillos por separado. Júntalos y obtienes animaciones, deshacer/rehacer, autosave, alertas y momentos de “¿por qué eso cambió?”
Por eso el pensamiento en sistemas es práctico: te empuja a buscar bucles (“cuando A cambia, B reacciona, lo que activa C…”) y a considerar el tiempo (“¿qué pasa tras 10 minutos de uso?”), no solo llamadas a funciones aisladas.
En un sistema, las interfaces importan más que la implementación. Si una parte solo puede interactuar con otra mediante mensajes claros (“incrementa contador”, “renderiza”, “graba evento”), puedes cambiar lo interno sin reescribir todo lo demás.
Esto está cerca del énfasis de Kay en el envío de mensajes: no controlas otras partes directamente; pides y ellas responden.
Imagina tres objetos:
Flujo en el tiempo:
clicked.increment a CounterModel.changed(newValue).changed y vuelve a renderizar.record("increment", newValue).Ningún componente necesita mirar dentro de otro. El comportamiento emerge de la conversación.
Alan Kay defendía una idea simple que sigue pareciendo radical: el software debería ser fácil de aprender, no solo poderoso. El diseño “ingenioso” suele optimizar la satisfacción del creador—atajos, trucos ocultos, abstracciones densas—mientras deja a los usuarios ordinarios memorizando rituales.
Kay valoraba la simplicidad porque escala: un concepto que un principiante puede comprender con rapidez es algo que los equipos pueden enseñar, compartir y ampliar.
Mucho software trata al usuario como operador: pulsa los botones correctos y obtienes el resultado. La meta de Kay era más cercana a una herramienta para pensar—algo que invite a explorar, soporte prueba y error y permita construir modelos mentales.
Por eso valoraba los sistemas interactivos donde puedes ver lo que ocurre y ajustar sobre la marcha. Cuando el sistema responde de forma inmediata y significativa, aprender se convierte en parte del uso.
Kay solía usar el aprendizaje—a veces imaginando niños como usuarios—como una fuerza de clarificación. Si un concepto puede manipularse, inspeccionarse y explicarse sin ambigüedades, es más probable que funcione para todos.
Esto no quiere decir “diseñar solo para niños”. Significa usar la enseñabilidad como prueba de calidad: ¿puede el sistema revelar su propia lógica?
La aprendibilidad es una característica de producto. Puedes diseñarla mediante:
La recompensa no es solo usuarios principiantes más felices. Es incorporación más rápida, menos tickets de soporte y un producto que la gente siente que puede ampliar—justo la clase de “agencia del usuario” que Kay quería amplificar.
El trabajo de Kay no “inventó todo lo que usamos hoy”, pero influyó mucho en cómo muchos piensan en construir software—especialmente software pensado para humanos, no solo para máquinas.
Muchas prácticas modernas reflejan ideas que Smalltalk y la cultura de Xerox PARC hicieron concretas y populares:
Algunas partes de la visión original no se trasladaron tal cual:
Si fuerzas la vista, muchos patrones actuales riman con el envío de mensajes: UIs por componentes (React/Vue), apps orientadas a eventos e incluso microservicios que se comunican por HTTP o colas. No son lo mismo, pero muestran cómo la idea central de Kay (sistemas como partes que interactúan) sigue reinterpretándose bajo limitaciones modernas.
Si quieres un puente práctico de la historia a la práctica, la última sección (ver /blog/practical-takeaways) convierte estas influencias en hábitos de diseño que puedes usar de inmediato.
El trabajo de Kay puede sonar filosófico, pero se traduce en hábitos muy prácticos. No necesitas usar Smalltalk—ni siquiera “hacer OOP”—para beneficiarte. La meta es construir software que siga siendo comprensible a medida que crece.
Cuando empiezas (o refactorizas), intenta describir el sistema como un conjunto de roles que trabajan juntos:
Esto te mantiene enfocado en responsabilidades, no en “clases porque necesitamos clases”.
Antes de discutir tablas de base de datos o jerarquías de clases, define los mensajes—qué le pide una parte a otra.
Un ejercicio útil: escribe una breve “conversación” para una acción de usuario:
Solo después decides cómo implementar esos roles (clases, módulos, servicios). Esto refleja el énfasis de Kay en envío de mensajes: comportamiento primero, estructura después.
A Kay le importaban los sistemas vivos donde puedes ver los efectos de los cambios rápido. En un equipo moderno, eso suele implicar:
Si no puedes decir qué cambió—o si ayudó—vas a ciegas.
Si construyes con un flujo guiado por chat (por ejemplo en Koder.ai), el mismo consejo aplica: trata los prompts y la salida generada como forma de iterar más rápido, pero mantén límites explícitos y usa salvaguardas como snapshots/rollback y exportación de código fuente para que el sistema siga siendo entendible con el tiempo.
Si esta entrada te resonó, explora:
Estos temas no son nostalgia; son desarrollar gusto: construir software aprendible, adaptable y coherente como sistema.
Alan Kay defendía una relación distinta con las computadoras: no trabajos en lote en cola, sino un medio personal e interactivo para aprender y crear.
Esa mentalidad moldeó expectativas que hoy damos por sentadas: retroalimentación inmediata, interfaces manipulables y software que puede explorarse y modificarse mientras trabajas.
El Dynabook fue una visión de un ordenador personal y portátil diseñado principalmente para aprender y crear (leer, escribir, dibujar, simular).
No se trata tanto de que “predijo las tabletas” como de que definió cómo debería sentirse una computación que empodera: usuarios como autores, no solo como operadores.
En Smalltalk, el lenguaje, las herramientas y la interfaz formaban un único entorno coherente.
En la práctica, esto significa que podías inspeccionar objetos en ejecución, cambiar comportamientos, depurar de forma interactiva y seguir trabajando sin reconstrucciones constantes—acortando la distancia entre la idea y el resultado.
La idea central de Kay no era “clases e herencia”, sino objetos como agentes independientes que se comunican enviando mensajes.
Desde el punto de vista del diseño, esto te empuja a definir límites claros: quienes llaman dependen de qué mensajes acepta un objeto, no de cómo mantiene sus datos internamente.
Una confusión habitual es ver la POO como una taxonomía de tipos: muchas clases, herencias profundas y datos mutables compartidos.
Una regla práctica desde la perspectiva de Kay:
Las interfaces gráficas hacen que el software parezca algo que manipulas (ventanas, botones, iconos). Eso encaja de forma natural con un modelo de objetos donde cada elemento de la UI tiene estado y comportamiento.
Las acciones del usuario (clics, arrastres, teclas) se convierten en eventos que son básicamente mensajes enviados a objetos, que a su vez pueden reenviarlos por el sistema.
Una imagen de Smalltalk guarda el mundo en ejecución: objetos en memoria, herramientas abiertas, estado de la UI y tu trabajo actual.
Beneficios:
Compromisos:
Pensar en sistemas significa fijarse en el comportamiento a lo largo del tiempo: bucles de retroalimentación, reacciones en cascada y quién le habla a quién.
En la práctica, lleva a diseños con interfaces más claras (mensajes) y menos dependencias ocultas, porque tratas la app como partes que interactúan, no como funciones aisladas.
Usa diseño centrado en mensajes para un flujo de trabajo:
getTotal, isAvailable, authorize).Solo entonces elige implementaciones (clases, módulos, servicios). El checklist del post en /blog/practical-takeaways es un buen punto de partida.
Herramientas modernas suelen rimar con los objetivos de Kay aunque los implementen distinto:
No son lo mismo que las imágenes de Smalltalk, pero buscan el mismo resultado práctico: abaratar el cambio y el aprendizaje.