Filosofía de la ingeniería: Rich Hickey, lo simple no es lo fácil

Ideas clave

• Lo simple no es lo fácil. Simple significa sin entrelazar —una sola preocupación por cosa— y es objetivo; fácil significa familiar y a la mano, y es subjetivo. Constantemente elegimos lo fácil y lo etiquetamos mal como simple.
• Entrelazar es la raíz de la complejidad. La complejidad no es la cantidad de partes, sino cuán enredadas están. Trenzar el estado con el tiempo, la identidad con el comportamiento o la política con el mecanismo es lo que produce un sistema sobre el que solo puedes rezar.
• Desenredar sin descanso. Separa las preocupaciones trenzadas en piezas independientes que compones de forma deliberada. La simplicidad es “una elección” que “exige vigilancia constante”: nunca llega cuando echas mano de la herramienta familiar.
• Prefiere los valores a los lugares, los datos a los objetos. Haz de la inmutabilidad el comportamiento por defecto y deja que el pasado se acumule como hechos inmutables en lugar de sobrescribir el estado en su sitio: la disciplina que sostiene tanto a Clojure como a Datomic.

El principio

“Las raíces de esta palabra son ‘sim’ y ‘plex’, y eso significa ‘un pliegue o una trenza’ […] justo al lado o en oposición a ‘complex’, que significa ‘trenzado en conjunto’ o ‘plegado en conjunto’.” – Rich Hickey, Simple Made Easy¹

Casi toda discusión sobre la calidad del software es en realidad dos discusiones que comparten una sola palabra, y la contribución de Rich Hickey consiste en separarlas. Simple y fácil no son sinónimos. Ni siquiera están en el mismo eje: una mide la cosa, la otra mide tu distancia respecto a ella. Simple viene del latín simplex —un pliegue, una trenza, un giro—. Describe la cosa en sí: cuántas preocupaciones hay entrelazadas en ella. Es objetivo, y su opuesto es complejo —trenzado en conjunto, plegado sobre sí mismo—. Fácil, en cambio, proviene de una raíz que significa “yacer cerca”, la misma raíz de adyacente.² Fácil describe tu relación con la cosa: qué tan a la mano está, qué tan familiar resulta, qué tan poco esfuerzo te cuesta empezar. Es subjetivo, y su opuesto es difícil.¹²

Una vez que ves la distinción, ya no puedes dejar de verla. La herramienta a la que recurres porque está a un solo npm install de distancia es fácil. Si es simple —si enreda la persistencia con tu validación con tu UI con tus reglas de negocio— es una pregunta completamente aparte, y la respuesta casi siempre es no. Elegimos lo fácil constantemente y lo llamamos simple, y luego nos ahogamos en la complejidad que invitamos. La palabra de Hickey para el acto de enredar es complect (entrelazar): “interpolar o entrelazar o trenzar”.³ Entrelazar es el pecado original. Es lo que convierte un sistema sobre el que podías razonar en uno sobre el que solo puedes rezar, porque una vez que dos preocupaciones están trenzadas ya no puedes tocar una sin entender y arriesgar la otra.

La disciplina, entonces, es desenredar —separar sin descanso las preocupaciones trenzadas en piezas independientes—, y Hickey es directo sobre su costo. “La simplicidad es una elección”, dice. “Es tu culpa si no tienes un sistema simple”.⁴ No ocurre por echar mano de la herramienta familiar; ocurre mediante “vigilancia constante” y cuidado deliberado.⁴ Ahí está todo el principio en cuatro palabras: lo simple no es lo fácil. La simplicidad es el camino más difícil, elegido y sin entrelazar, y es el único que se acumula a tu favor. La misma convicción está debajo del argumento de que la calidad es la única variable: no llegas a un sistema limpio dando el paso conveniente cada vez; lo eliges, contra la pendiente, cada vez.

Contexto

Rich Hickey es un programador independiente que pasó cerca de dos décadas escribiendo sistemas en C++, Java y C# para ganarse la vida antes de construir aquello por lo que se le conoce.⁵ Sabía cómo hacer grandes sistemas en esos lenguajes, y su conclusión tras veinte años no fue que les faltaran funciones. Fue que eran máquinas de entrelazar: hacían que trenzar preocupaciones en conjunto fuera algo sin esfuerzo y casi no ofrecían ayuda alguna para separarlas.

Así que construyó la alternativa él mismo, solo. A partir de 2005 más o menos, Hickey pasó cerca de dos años y medio desarrollando Clojure —en buena parte autofinanciado, trabajando sin salario— en un Lisp para la Java Virtual Machine que haría de la inmutabilidad y la simplicidad el camino de menor resistencia, en lugar de un acto de heroísmo.⁵ Lo lanzó públicamente en 2007. No había una empresa detrás, ni un comité, ni una subvención. Era un solo programador que había visto la enfermedad de cerca y que decidió gastar años de su propia pista de despegue construyendo la cura. Más tarde creó Datomic, una base de datos inmutable,⁵ y dio una serie de charlas de conferencia —Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet?— que son, en conjunto, el cuerpo de filosofía de diseño más influyente de la programación funcional moderna.⁶

El trabajo

Simple Made Easy: simple frente a fácil, y entrelazar

Pronunciada en Strange Loop en septiembre de 2011, Simple Made Easy es la charla que reorganizó la forma en que toda una generación de programadores habla de la complejidad.¹ Toda su fuerza nace de negarse a dejar que simple y fácil signifiquen lo mismo. Simple se refiere a la construcción: ¿es un solo pliegue o muchos trenzados en conjunto? Fácil se refiere a ti: ¿está a la mano, es familiar, está dentro de tu capacidad actual? Puedes tener cosas que son simples pero poco familiares (difíciles de aprender, fáciles de mantener) y cosas que son fáciles pero complejas (familiares, cómodas y silenciosamente ruinosas). La mayor parte de lo que la industria vende como productividad es del segundo tipo.¹

El verbo en el centro es complect (entrelazar): trenzar, interpolar, entretejer.³ Entrelazar es lo que hace complejo a un sistema: no la cantidad de partes, sino cuán enredadas están. El estado entrelaza el valor con el tiempo. Los objetos entrelazan el estado con la identidad y el comportamiento. La herencia, los ORM, los condicionales dispersos por un método: cada uno trenza preocupaciones que podrían haber permanecido separadas. Y el costo de una trenza no se paga una sola vez; se paga en cada cambio futuro, porque ya no puedes tocar una hebra sin perturbar todas las demás.

La cura es desenredar —separar las hebras en cosas independientes que puedes componer después, según tus propios términos—. La afirmación de Hickey, y es contundente, es que desenredar no es una pérdida de poder. “Puedes escribir un sistema tan sofisticado con herramientas dramáticamente más simples”, dice: los mismos programas, solo que ahora sobre los que de verdad puedes razonar, que puedes cambiar y en los que puedes confiar.⁴ La simplicidad no es el subconjunto de capacidades para principiantes. Es la disciplina del experto de negarse a trenzar.

Clojure: un Lisp para la JVM, datos sobre objetos

Clojure es el principio hecho ejecutable: un dialecto de Lisp dinámico y funcional que corre sobre la JVM, diseñado por Hickey como “un Lisp para la programación funcional en simbiosis con una plataforma establecida diseñada para la concurrencia”.⁷ Dos decisiones codifican la filosofía. Primero, la inmutabilidad es el comportamiento por defecto, no una opción: las estructuras de datos centrales de Clojure son inmutables y persistentes, de modo que lo más natural de escribir es también lo que no puede corromperse por una mutación lejana.⁷ Segundo, datos sobre objetos: en lugar de una maraña de clases a medida, cada una con su estado privado y su comportamiento trenzados dentro, Clojure favorece “muchas funciones definidas sobre pocas estructuras de datos primarias” —secuencias, mapas, vectores, conjuntos—.⁷ Simplemente usa mapas. Simplemente usa datos.

Esta separación es desenredar al nivel de la gramática de un lenguaje. Los objetos trenzan en conjunto el estado, la identidad y el comportamiento en una única cosa sellada; Clojure los separa: valores inmutables para lo que una cosa es, funciones simples para lo que haces con ella, tipos de referencia explícitos para el cambio gestionado a lo largo del tiempo. Al hacer de la JVM la plataforma en lugar de pelear contra ella, Hickey también desenredó el lenguaje del entorno de ejecución: Clojure obtiene gratis la madurez, las bibliotecas y el rendimiento de la JVM, y gasta todo su presupuesto de novedad en el modelo del estado y el tiempo.⁷

The Value of Values: la inmutabilidad y Datomic

The Value of Values lleva el argumento de la inmutabilidad un nivel más arriba, hasta la base de datos misma. El blanco de Hickey es lo que él llama programación orientada al lugar (PLOP): “cada vez que información nueva reemplaza a información vieja, estás haciendo programación orientada al lugar”.⁸ Actualizamos un registro en su sitio, el valor viejo desaparece y, con él, la historia. Sostiene que esto es un resabio de una época de memoria escasa, y que tira a la basura justamente lo que un negocio necesita para razonar: el pasado. Un valor, en cambio, es inmutable por definición: un hecho es “algo que ocurrió, algo que se sabe que ocurrió”, y un hecho no puede actualizarse, solo ser superado por un hecho más nuevo.⁸ Un nuevo presidente no sobrescribe al anterior; lo agrega.

Datomic es esa idea construida como base de datos. Es fundamentalmente inmutable: “Una base de datos Datomic es un conjunto de hechos atómicos inmutables llamados datoms”, y “las transacciones de Datomic agregan datoms, nunca los actualizan ni los eliminan, así que tienes una pista de auditoría completa”.⁹ Como nunca se sobrescribe nada, la base de datos puede tratarse como un valor en un punto en el tiempo: puedes consultarla “as-of” cualquier instante pasado con las mismas consultas que ejecutas contra el presente, sin cambio alguno.⁹ La base de datos deja de ser un único lugar mutable y se convierte en una serie de valores a lo largo del tiempo. Estado, identidad y tiempo: desenredados, en un almacén de datos de producción.

Hammock-Driven Development: piensa primero

El complemento de todo esto es una charla sobre cuándo ocurre el trabajo de verdad, y la respuesta de Hickey es: antes de tocar el teclado. En Hammock-Driven Development sostiene que “el lugar menos costoso para arreglar errores es cuando estás diseñando tu software”, y que la mayoría de las fallas graves de software son fallas de concepción equivocada: no entendimos el problema antes de empezar a resolverlo.¹⁰ El remedio es enunciar el problema de forma explícita, reunir los hechos y las restricciones, y luego pensar —incluso entregándole el problema a tu “mente de fondo”, que hace las conexiones que tu “mente despierta” y analítica no puede forzar—.¹⁰ La hamaca es el mueble literal para no hacer nada más que pensar, sin que nada te perturbe.

El desarrollo guiado por la hamaca es la práctica que hace posible la simplicidad en absoluto. No puedes desenredar un sistema que todavía no entiendes, y no puedes entenderlo mientras corres a compilar. El desarrollo guiado por la hamaca es la mitad delantera, nada glamorosa, de lo simple no es lo fácil: el pensamiento deliberado, lento y vigilante que tiene que ocurrir antes de que pueda aparecer el diseño sin entrelazar.

El método

El método es una sola distinción —lo simple no es lo fácil— aplicada con una terquedad poco común a través de un lenguaje, una base de datos y una forma de trabajar.

Separa “simple” de “fácil” antes de cada decisión. Pregúntate de cualquier herramienta o diseño: ¿es esto sin entrelazar (simple), o simplemente familiar y a la mano (fácil)? Son ejes distintos, y confundirlos es como la complejidad se cuela disfrazada de productividad.¹²

Caza el entrelazado y desenrédalo. La complejidad no es el recuento de partes; es cuán enredadas están. Encuentra dónde el estado está trenzado con el tiempo, la identidad con el comportamiento, la política con el mecanismo, y separa las hebras en piezas independientes que compones de forma deliberada.³

Prefiere los valores y los datos a los lugares y los objetos. Haz de la inmutabilidad el comportamiento por defecto. Representa la información como datos simples —mapas, vectores— y opera sobre ella con funciones, en lugar de sellar el estado y el comportamiento juntos dentro de objetos.⁷⁸

Trata el pasado como un valor, no como estado sobrescrito. La información nueva debería agregarse, no destruir. Un sistema que acumula hechos inmutables a lo largo del tiempo puede razonarse, auditarse y consultarse “as-of” cualquier momento, cosa que un lugar sobrescrito en su sitio nunca podrá.⁸⁹

Piensa antes de teclear. El lugar más barato para arreglar un defecto es en el diseño. Enuncia el problema, entrégaselo a tu mente de fondo y gánate el diseño simple entendiendo primero el problema.¹⁰

Acepta que la simplicidad es difícil y elegida. No llega por echar mano de lo fácil. “La simplicidad es una elección”, y exige “vigilancia constante”. El camino conveniente y el camino simple rara vez son el mismo camino.⁴

Cadena de influencia

Quién lo formó

Lisp y John McCarthy. Clojure es, en palabras del propio Hickey, “un Lisp no restringido por la compatibilidad hacia atrás”: la homoiconicidad del código como datos y el poder de las macros vienen directamente del linaje de McCarthy, extendido a mapas y vectores en lugar de solo listas.⁷ (Influencia directa)

John Backus y la tradición de la programación funcional. La conferencia del Premio Turing de Backus en 1977, Can Programming Be Liberated from the von Neumann Style?, es el argumento canónico contra la computación orientada al lugar y dirigida por la asignación. La guerra de Hickey contra la programación orientada al lugar y el estado mutable es ese argumento llevado a producción. (Influencia formativa)

La Java Virtual Machine. En lugar de tratar el entorno de ejecución como un enemigo del que abstraerse, Hickey hizo de la JVM la plataforma y construyó el lenguaje encima de ella: un desenredado deliberado del “lenguaje” respecto del “entorno de ejecución” que le dio a Clojure madurez y alcance desde el primer día. (Influencia directa)

El pensamiento relacional y orientado a valores. La visión de Datomic de los datos como hechos inmutables acumulados a lo largo del tiempo, consultables “as-of” cualquier punto, desciende de la separación que hace la tradición relacional entre los hechos y su almacenamiento: la idea de que la información tiene una existencia independiente del lugar que la contiene en este momento.⁸⁹ (Influencia formativa)

A quién formó

El renacimiento de la programación funcional. Clojure, junto con Scala y otros sobre la JVM, ayudó a mover la programación funcional de curiosidad académica a producción dominante, y las charlas de Hickey se volvieron el vocabulario compartido —“simple”, “fácil”, “complect”— que los programadores en activo usan hoy para discutir de diseño.

La inmutabilidad, vuelta corriente principal. La idea de que los datos inmutables por defecto son lo razonable, no una restricción exótica, se propagó mucho más allá de Clojure. Hoy es lo mínimo indispensable en el diseño de lenguajes y bibliotecas en toda la industria.

React, Redux y el mundo del front-end. El modelo orientado a valores —estado inmutable, transformaciones puras sobre los datos, identidad y estado separados— es la columna conceptual de React y, sobre todo, de Redux. Toda una generación de ingenieros de front-end absorbió el pensamiento-valor de Hickey sin siempre saber de quién era.

El hilo conductor

John Carmack reduce un renderizador a su núcleo rápido y simple y rechaza toda función que trenzaría lentitud en el bucle interno; Hickey reduce un sistema a sus preocupaciones sin entrelazar y rechaza toda abstracción que las entrelazaría. Ambos tratan la simplicidad como la cosa difícil y elegida, no como el comportamiento por defecto. Y donde Linus Torvalds valora el “buen gusto” que hace que un caso especial desaparezca dentro del general, Hickey valora el desenredado que hace que dos preocupaciones enredadas se sostengan aparte como una sola: el mismo instinto visto desde extremos opuestos. La estructura correcta no es decoración sobre el problema, es el problema correctamente separado en sus partes reales. Yukihiro Matsumoto optimizó Ruby por cómo se siente escribirlo —lo fácil, en el vocabulario de Hickey—, mientras que Hickey optimizó por lo que la cosa es —lo simple—; juntos trazan los dos ejes que Hickey dedicó una charla entera a insistir en que dejemos de confundir. (Puente de la serie)

Lo que tomo de esto

La lección que conservo es que lo fácil es una trampa disfrazada de virtud. Casi todo arrepentimiento en una base de código empezó como un alcance razonable hacia lo que estaba a la mano: la biblioteca conveniente, la mutación rápida, la responsabilidad extra plegada dentro de una clase que ya existía. Nada de eso se sintió como un error, porque lo fácil nunca lo hace. El regalo de Hickey es el vocabulario para atraparlo en el momento: detenerte y preguntar ¿esto es simple, o solo fácil? y saber que la respuesta honesta suele ser la inconveniente. Ese es el mismo estándar que el de que la calidad sea la única variable: la pregunta nunca es “¿qué puedo alcanzar más rápido?”, sino “¿qué está realmente sin entrelazar aquí?”.

En el mundo en el que construyo ahora —agentes, bucles de herramientas, código de capa local donde el estado, los prompts, los reintentos y los efectos secundarios adoran trenzarse en una sola cosa ingobernable— la tentación es lo fácil al máximo: apilar frameworks, embadurnar el estado por todo el bucle, entrelazar la lógica de decisión con la I/O con el registro hasta que nadie pueda cambiar una parte sin arriesgar el todo. El movimiento de Hickey es desenredar: separar la política del mecanismo, hacer el estado inmutable donde se pueda, tratar cada ejecución como un valor y no como un lugar que sobrescribo. Esa convicción —que el buen gusto es un sistema técnico que eliges con vigilancia, no una vibra que heredas por echar mano de lo que tienes cerca— es el hilo conductor que va de un Lisp autofinanciado en 2007 a una capa de agentes en 2026. Lo simple no es lo fácil. Elígelo de todos modos.

Preguntas frecuentes

¿Cuál es la diferencia entre lo simple y lo fácil?

En el marco de Rich Hickey de Simple Made Easy, simple y fácil son ejes completamente distintos. Simple viene del latín simplex —“un pliegue o una trenza”— y describe la cosa en sí: qué tan pocas preocupaciones hay entrelazadas en ella. Es objetivo, y su opuesto es complejo (“trenzado en conjunto”).¹ Fácil proviene de una raíz que significa “yacer cerca”, la misma raíz de adyacente; describe tu relación con la cosa: qué tan familiar y a la mano está.² Es subjetivo, y su opuesto es difícil. Algo puede ser simple pero poco familiar, o fácil pero profundamente complejo. El punto de Hickey es que constantemente elegimos lo fácil y lo etiquetamos mal como simple, y pagamos la complejidad más tarde.¹

¿Qué significa “complect”?

Complect (entrelazar) es el verbo que Hickey revivió en Simple Made Easy para el acto de trenzar preocupaciones en conjunto. Lo define directamente: “Significa interpolar o entretejer o trenzar”.³ Entrelazar es lo que hace complejo a un sistema: no la cantidad de partes, sino cuán enredadas están. Cuando dos preocupaciones están entrelazadas (digamos, estado y tiempo, o identidad y comportamiento), ya no puedes cambiar una sin entender y arriesgar la otra. El remedio es desenredar: separar las hebras en piezas independientes que puedes componer de forma deliberada. Hickey trata el desenredado como la disciplina central para construir sistemas simples.³

¿Qué construyó Rich Hickey?

Rich Hickey es un programador independiente que creó Clojure, un dialecto de Lisp dinámico y funcional que corre sobre la Java Virtual Machine. Lo desarrolló en buena parte solo a lo largo de cerca de dos años y medio, mucho de ese tiempo autofinanciado y sin salario, y lo lanzó en 2007.⁵⁷ Más tarde creó Datomic, una base de datos inmutable que nunca sobrescribe los datos, sino que acumula hechos inmutables (“datoms”) a lo largo del tiempo, de modo que la base de datos puede consultarse como un valor “as-of” cualquier punto pasado.⁹ También es ampliamente conocido por una serie de charlas de conferencia —Simple Made Easy, The Value of Values, Hammock-Driven Development y Are We There Yet?— que moldearon la forma en que la industria habla de la complejidad, la inmutabilidad y el diseño.⁵⁶

¿Dijo Rich Hickey que “los programadores conocen los beneficios de todo y las contrapartidas de nada”?

Esta frase se atribuye muy ampliamente a Hickey y captura su pensamiento con exactitud, pero no aparece textualmente en las transcripciones de su charla principal; es una paráfrasis cristalizada que ha circulado por libros y charlas de conferencia.¹¹ La versión textual primaria más cercana está en Design, Composition, and Performance, donde insta a desarmar una solución “para ver no solo los beneficios, ¿cierto? Esos suelen ser bastante evidentes. Sino también las contrapartidas: ¿qué parte de esto no va a funcionar?”.¹² El sentimiento es inequívocamente suyo —que los ingenieros se obsesionan con lo que una herramienta les da y examinan de menos lo que les cuesta—, pero el aforismo contundente conviene tratarlo como una paráfrasis y no como una cita directa.

Fuentes