I. El triunfo del objeto

García Márquez observó que en Macondo la historia no avanza: gira. Los Buendía repiten los mismos errores generación tras generación, convencidos de que esta vez será diferente. La industria del software tiene el mismo problema, aunque tarda décadas en reconocerlo.

El nombre de Grady Booch sirve para fijar algo que ocurrió en los años ochenta y noventa: el triunfo del objeto. Antes, el software era proceso — verbos en COBOL, subrutinas en Fortran, funciones en C. Describías lo que el sistema hace, no lo que es. Los programas tenían flujos, instrucciones, verbos. La máquina ejecutaba una secuencia; tú seguías la secuencia.

Luego llegaron el Lenguaje Unificado de Modelado, los patrones de diseño, la noción de que podías abstraer la realidad en clases y jerarquías y responsabilidades. El catálogo de la Banda de los Cuatro prometía orden: Observer, Strategy, Adapter. Cada patrón era una forma de objeto, una manera de organizar el código en torno a sustantivos en lugar de verbos. El Object-Oriented Analysis and Design de Booch se convirtió en la gramática de una nueva forma de pensar la computación: cosas que saben cosas, cosas que hacen cosas, cosas que heredan de otras cosas.

Funcionó. La programación orientada a objetos escaló a sistemas suficientemente grandes como para necesitar estructura, jerarquía, una forma de razonar sobre la complejidad. IBM, Microsoft, Java. El objeto se convirtió en la unidad de pensamiento.

II. Las grietas

Pero observa lo que pasó en los márgenes. A medida que los sistemas crecían, el problema eran las conexiones entre objetos. Los datos empezaron a vivir en otro lugar — una base de datos relacional, otro sistema, la red. Ya no podías ocultarlo. Así que inventamos la arquitectura orientada a servicios y luego los microservicios. ¿Qué son esos? Un retorno a los procesos. Sistemas que hacen cosas, que se comunican, que tienen fronteras, que exponen comportamiento en lugar de esconder estado.

El movimiento de los microservicios empezó como liberación — libera el monolito, deja que cada servicio haga una cosa. Lo que siguió fue una pesadilla de sistemas distribuidos: fallos parciales, latencia de red, consistencia eventual, el teorema CAP sobrevolando cada decisión de diseño. Los objetos habían ocultado la complejidad dentro de jerarquías. Los microservicios distribuyeron esa complejidad por la red. Habíamos intercambiado un tipo de desorden por otro.

III. El otro lado nunca se fue

Mientras tanto, los lenguajes funcionales — Lisp, Haskell, Scheme — nunca abandonaron el proceso. Insistían en las funciones como transformaciones, en los datos como inmutables, en la composición como la operación fundamental. Durante décadas parecieron el bando perdedor, la preferencia de académicos que no tenían sistemas reales que entregar.

Luego algo cambió. Las goroutines de Go, el modelo de ownership de Rust, el lento giro de Python hacia la inmutabilidad, el abrazo de JavaScript a map y reduce — todo ello señala que el péndulo vuelve. La intuición de que los datos inmutables y las funciones componibles producen menos sorpresas que los objetos con estado no es nueva; Lisp lo sabía en 1958. Simplemente tomó cincuenta años de errores acumulados ponerse de acuerdo.

IV. El arco completo

El almacenamiento de datos cuenta la misma historia. Las tarjetas perforadas eran proceso puro — instrucciones, verbos, secuencias. Los archivos eran sustantivos: podías guardarlos, moverlos, organizarlos. Las bases de datos relacionales intentaron ser ambas: datos organizados por esquema y consultables mediante SQL, un lenguaje de procesos. NoSQL volvió al pensamiento de documentos sin esquema — y luego tuvo que reconstruir el motor de consultas porque nadie podía vivir sin proceso. GraphQL es casi proceso puro: preguntas por lo que fluye, no por lo que existe.

Las metodologías oscilaron también. El cascada definía el flujo del sistema y luego lo construía. El diseño orientado a objetos prometía que especificarías la cosa y el flujo seguiría. Agile argumentó que el proceso es lo que importa — iterar, hablar, entregar. DevOps dio el paso siguiente: el proceso es el sistema. Tu infraestructura, tu despliegue, tu monitoreo — eso es el producto, no el código que ejecutan.

El arco completo: ensamblador (proceso puro), COBOL (proceso con datos), C (datos con punteros a funciones), C++ (objetos con miembros de datos), Java (objetos como toda la historia), Python (objetos que actúan como funciones), Go (funciones que se componen), microservicios (procesos que hablan), serverless (procesos que escalan), observabilidad (la visibilidad del proceso como producto).

V. Lo que enseña el péndulo

No somos más inteligentes ahora que en 1985. Estamos aprendiendo la lección de nuevo.

Borges lo entendió de otra manera. En El idioma analítico de John Wilkins, examina los intentos de clasificar el mundo en categorías perfectas y concluye que cualquier taxonomía es arbitraria — que el universo no se deja dividir limpiamente en objetos discretos. La risa que provoca la enciclopedia china imaginaria no es por lo absurdo de sus categorías, sino porque revela que todas las categorías son un tanto absurdas. Los objetos son recortes convenientes sobre una realidad que fluye.

El insight real no es que un lado tenga razón. Es que hacen la misma pregunta desde ángulos opuestos. Los objetos son procesos congelados. Los procesos son objetos en movimiento. Necesitas ambos. El error es pretender que puedes elegir uno y ganar.

Grady Booch y los años ochenta no estaban equivocados. Solo perdieron de vista para qué servían los objetos — que siempre fue hacer el proceso más claro, más testeable, más mantenible. Cuando el objeto se convirtió en el fin en lugar del medio, el péndulo empezó a volver. Como siempre.

Los Buendía de Macondo también tenían razón en lo que querían, equivocados en creer que podían fijarlo en un objeto, en una cosa, en una fundación. Lo que importa es el trabajo. Los modelos, los paradigmas, los lenguajes — todos intentan hacer el trabajo visible. Ochenta años de oscilación, y la lección no ha cambiado: entiende qué estás haciendo realmente, y la pregunta de cómo representarlo se responde sola.

El mismo argumento, aplicado a la automatización y por qué llamarla “IA” oscurece lo que realmente importa, está en Procesos sobre objetos.

Lecturas recomendadas

Para Eduardo: cuarenta años en esto, y la tecnología sigue corriendo. El péndulo nos debe una disculpa.