Filosofía de la ingeniería: Guido van Rossum, la legibilidad importa

Ideas clave

• El código se lee mucho más de lo que se escribe, así que van Rossum optimizó Python para la persona que leerá la línea más tarde, no para la máquina ni para quien la escribe en ese instante.
• El espacio en blanco significativo vuelve honesta la lectura: la sangría que ves es la estructura de bloques que se ejecuta, de modo que la apariencia de un programa en Python no puede mentir sobre lo que hace.
• “Debería haber una forma obvia de hacerlo” significa que el código escrito por desconocidos sigue leyéndose como si lo hubiera escrito una sola mano: converger en un único modismo es un regalo para cada lector futuro.
• El Zen de Python es de Tim Peters, no de van Rossum: una atribución errónea común. Peters destiló valores que ya estaban incorporados en el lenguaje.

El principio

“Una de las ideas clave de Guido es que el código se lee mucho más de lo que se escribe.” – PEP 8, atribuyendo la idea a Guido van Rossum¹

Esa idea es la afirmación revolucionaria más silenciosa del diseño de lenguajes, y casi todo el mundo asiente ante ella para luego ignorarla. Lee la frase despacio. El código se lee mucho más de lo que se escribe. Una línea que escribes una vez se leerá decenas de veces: por quien revisa y la aprueba, por el colega que la amplía, por el desconocido que la hereda y, más a menudo que nadie, por ti mismo, seis meses después, tratando de recordar qué querías decir. Si eso es cierto, entonces el público del código fuente no es la máquina ni quien lo escribe en el momento de escribirlo. Es la persona que lo lee después. Y un lenguaje debería optimizarse para su público real.

Casi ningún lenguaje lo hacía. Los lenguajes de sistemas de los años ochenta se optimizaban para el compilador y la máquina; los lenguajes de scripting se optimizaban para la comodidad de quien los escribía en el momento, razón por la cual tantos de ellos se volvían ilegibles al día siguiente de haberse escrito. La apuesta de Guido van Rossum fue que se podía optimizar para el lector en su lugar: que la claridad, convertida en opción por defecto e impuesta por la propia gramática, se acumularía a lo largo de toda una comunidad durante décadas. Tuvo razón por un margen que casi nadie predijo. El Zen de Python destila ese mismo valor en tres palabras que todo programador de Python ha leído: “La legibilidad importa.”²

Esa convicción es la misma que sostiene el argumento de que el buen gusto es un sistema técnico y no una vibra que se proclama. La legibilidad no es una preferencia blanda que se añade con una guía de estilo después del hecho. En Python es estructural: está integrada en la sintaxis, de modo que el lenguaje no te deja escribir la versión ilegible con tanta facilidad como la legible. La apuesta de van Rossum fue que, si haces de lo claro el camino de menor resistencia, todo un ecosistema derivará hacia la claridad sin que se lo ordenen.

Contexto

Guido van Rossum nació el 31 de enero de 1956 en La Haya, Países Bajos, y obtuvo una maestría en matemáticas e informática por la Universidad de Ámsterdam en 1982.³ Fue a trabajar al Centrum Wiskunde & Informatica (CWI), el instituto nacional neerlandés de investigación en matemáticas e informática en Ámsterdam, donde lo esperaba la experiencia formativa de su carrera: el lenguaje de programación ABC.

ABC, diseñado en el CWI por Leo Geurts, Lambert Meertens y Steven Pemberton, era un lenguaje pedagógico creado para ser aprendible y legible, y van Rossum dedicó varios años a mediados de los años ochenta a trabajar en su implementación.⁴ ABC tomó dos decisiones que resonarían en todo lo que él hizo después: usaba la sangría para marcar la estructura de bloques – la “regla del margen”, sin llaves, sin begin/end – y trataba la legibilidad como un objetivo de diseño primordial, con programas que solían tener una cuarta parte del tamaño del equivalente en Pascal o C.⁴ Van Rossum llegó a amar la idea de la sangría; más tarde dijo que acababa con las inútiles guerras religiosas sobre dónde colocar las llaves.⁵ Pero ABC también tenía defectos fatales: una implementación monolítica, un diseño cerrado y difícil de extender, una insularidad académica que lo mantuvo lejos de los programadores reales de Unix. Él había usado el lenguaje legible y había visto las dos mitades de la lección: cuáles ideas eran genuinamente buenas y cuáles eran los errores que lo mataron.

Luego llegó la famosa historia de origen, y de verdad ocurrió tal como cuenta la leyenda. “Hace más de seis años, en diciembre de 1989”, escribió van Rossum, “buscaba un proyecto de programación ‘de hobby’ que me mantuviera ocupado durante la semana de Navidad.”⁶ Su oficina en el CWI estaba cerrada por las fiestas. Se propuso construir un lenguaje de scripting que conservara las mejores ideas de ABC – la legibilidad, la sangría – y corrigiera sus errores, esta vez dirigido a los hackers de Unix/C que ABC nunca había alcanzado. Como nombre, “en un estado de ánimo algo irreverente (y siendo gran fan de Monty Python’s Flying Circus)”, eligió Python.⁶ No la serpiente. El grupo de comedia. Lanzó públicamente la primera versión en 1991.³

El trabajo

La legibilidad y el espacio en blanco significativo

La decisión de diseño más trascendental que van Rossum trajo de ABC es la que los recién llegados discuten y los veteranos dejan de notar: la sangría es sintaxis. En la mayoría de los lenguajes la estructura de bloques se marca con llaves o palabras clave, y la sangría es solo decoración que el ojo humano usa y el compilador ignora. Lo que significa que ambas pueden contradecirse. Las llaves pueden decir una cosa mientras la sangría dice otra, y el código puede parecer que hace una cosa mientras ejecuta otra – el clásico error de sangría engañosa, la familia de fallos que produjo el infame agujero SSL goto fail de Apple, donde una segunda línea sangrada quedó fuera de un if que visualmente parecía contenerla.

Python vuelve estructuralmente imposible esa clase de error. La sangría que ves es la estructura de bloques que se ejecuta. No hay una segunda verdad oculta de la cual pueda divergir. Van Rossum heredó esto de ABC porque mataba los debates sobre la colocación de las llaves, pero la recompensa más profunda es exactamente su principio: vuelve honesta la lectura. Lo que el ojo del lector percibe como la forma del programa es, por definición, la forma que el intérprete ejecuta.⁴⁵

La estructura honesta es también la razón por la que Python le parece a un no programador lo que parece: pseudocódigo estructurado que da la casualidad de que se ejecuta. Ese era el punto. Van Rossum, una persona muy visual según su propia descripción, diseñó la superficie para que fuera accesible y la estructura para que fuera visible, de modo que la distancia entre “leer el código” y “entender el programa” sea tan pequeña como la gramática lo permita.

El Zen de Python y “una forma obvia”

En 1999, el veterano desarrollador del núcleo Tim Peters puso por escrito los valores de diseño que animaban a Python en veinte aforismos. Con el tiempo quedaron consagrados como el PEP 20, el Zen de Python, y vienen dentro del propio lenguaje: escribe import this en un intérprete de Python y se imprimen. El crédito importa y a menudo se equivoca: el texto lo escribió Tim Peters, no van Rossum.² Pero el Zen es una destilación de la sensibilidad de diseño de Guido: Peters articulaba los valores que ya estaban en el lenguaje, del mismo modo en que un buen crítico articula la intención de un artista mejor de lo que el propio artista puede.

Dos líneas cargan con toda la filosofía. “La legibilidad importa.” Y: “Debería haber una – y preferiblemente solo una – forma obvia de hacerlo.”² Esa segunda línea es la inversión deliberada del célebre lema de Perl, “Hay más de una forma de hacerlo.” El Python de van Rossum apuesta en la dirección contraria: un lenguaje que ofrece una forma obvia es un lenguaje cuyo código se ve igual sin importar quién lo escribió, lo que significa que cualquiera puede leer el de cualquier otro. Converger en un único modismo no es una restricción para quien escribe; es un regalo para cada lector futuro. (Hasta la propia puntuación del aforismo – las rayas que envuelven “y preferiblemente solo una” – es una broma astuta sobre el hecho de que la regla se viola ligeramente al enunciarla.)

BDFL y gobernanza: dejar el cargo en 2018

Durante la mayor parte de la vida de Python, van Rossum tuvo la última palabra sobre el diseño del lenguaje, bajo un título acuñado medio en broma en un encuentro de Python en 1995 y hecho permanente por Barry Warsaw: BDFL, Benevolent Dictator For Life (dictador benévolo vitalicio).⁷ Era un modelo de gobernanza real. Los cambios al lenguaje fluían a través del proceso PEP – Python Enhancement Proposals, el mecanismo abierto, escrito y archivado mediante el cual se propone, debate y decide cualquier cambio – pero cuando el consenso fallaba, el BDFL decidía. Durante décadas funcionó, porque el gusto de van Rossum era aquello en lo que la comunidad confiaba.

Terminó por un solo operador. El PEP 572 introdujo la expresión de asignación “morsa”, :=, y el debate fue inusualmente agrio – van Rossum lo sacó adelante contra una oposición ruidosa y sostenida. El 12 de julio de 2018, días después de que se aceptara, publicó un correo titulado “Transfer of power” en la lista python-committers. “Ahora que el PEP 572 está hecho”, escribió, “no quiero volver a tener que pelear tan duro por un PEP y descubrir que tanta gente desprecia mis decisiones.” Se concedió “unas vacaciones permanentes de ser BDFL” y – la parte trascendental – se negó rotundamente a nombrar un sucesor (“no voy a designar un sucesor”), dejando que la comunidad inventara su propio gobierno.⁸ Y lo hizo: un Steering Council electo de cinco miembros, ratificado por el PEP 8016, ahora gobierna Python. El dictador benévolo abolió deliberadamente la dictadura.

El alcance de Python

La apuesta por la legibilidad se acumuló hasta convertirse en uno de los mayores resultados de la historia del software. Porque Python era el lenguaje que la gente podía leer, se volvió el lenguaje que la gente podía enseñar: hoy es el lenguaje introductorio dominante en las universidades de todo el mundo. Porque era legible y extensible, se convirtió en el pegamento de la computación científica: NumPy, SciPy, pandas, toda la pila de la ciencia de datos. Y porque la pila de la ciencia de datos ya estaba en Python, la revolución del deep learning también se construyó en Python – PyTorch, TensorFlow, JAX y casi todos los modelos de los que has oído hablar se manejan desde un lenguaje que un programador neerlandés diseñó durante unas vacaciones de Navidad para que fuera amable con el ojo humano. El propio van Rossum salió del retiro en 2020 para unirse a Microsoft y trabajar en el proyecto Faster CPython, un esfuerzo por hacer el intérprete aproximadamente el doble de rápido – regresando, como él mismo dijo, a sus raíces.⁹

El método

El método es una sola convicción – optimizar para el lector – perseguida con una consistencia inusual durante treinta y cinco años.

Optimiza para la persona que lee el código. No para la máquina, no para quien escribe en el momento. Cada decisión de superficie – la sangría, el vocabulario reducido de palabras clave, la insistencia en la claridad – sirve a la persona que leerá la línea más tarde, porque esa persona es el público real y hay muchas más de ellas.¹

Haz visible la estructura y honesta la lectura. La sangría es la estructura de bloques, así que lo que el ojo percibe es lo que el intérprete ejecuta. El lenguaje se niega a dejar que la apariencia del código y su comportamiento diverjan.⁴

Prefiere una forma obvia. Resiste la tentación de ofrecer cinco modismos para la misma tarea. Converger en un único modismo claro significa que el código escrito por desconocidos sigue leyéndose como si lo hubiera escrito una sola mano.²

Toma las buenas ideas y corrige los errores. Python es la legibilidad y la sangría de ABC, menos el diseño monolítico, cerrado e inextensible de ABC. Van Rossum no inventó de la nada; fue un editor exigente de lo que vino antes.⁴⁵

Gobierna en abierto, y sabe cuándo soltar. El proceso PEP hizo públicas y escritas las decisiones de diseño. Y cuando el hecho de ser él la autoridad final se volvió un costo para la comunidad en lugar de un servicio para ella, se quitó de en medio – y se negó a ungir un reemplazo, forzando a que se formara una institución duradera en su lugar.⁸

Cadena de influencia

Quién lo formó

ABC, y Lambert Meertens, Leo Geurts y Steven Pemberton en el CWI. ABC le entregó a van Rossum sus dos ideas definitorias – la sangría como sintaxis y la legibilidad como objetivo primordial – y, al fracasar, le enseñó las lecciones negativas: no construir un monolito, no cerrar el diseño, no ignorar al programador que trabaja. Python es la buena mitad de ABC, rescatada. (Influencia directa y formativa)

Modula-3. Su limpio diseño de módulos y excepciones influyó en el de Python, un recordatorio de que van Rossum tomó prestado deliberadamente de los lenguajes que admiraba en lugar de reinventar cada rueda. (Influencia directa)

C y la cultura Unix. C le dio a Python su lenguaje de implementación (CPython está escrito en C) y su público objetivo – los hackers de Unix/C que ABC nunca alcanzó. Python se concibió para ser la capa de scripting legible por encima de C, extensible en C, pegamento para un mundo de C. (Influencia formativa)

A quién formó él

La mayor comunidad de programación de la Tierra. Python es, según la mayoría de las mediciones, hoy el lenguaje de programación más usado del mundo, y el primer lenguaje predeterminado que se enseña a los principiantes. Toda una generación aprendió a pensar los programas en una sintaxis diseñada para leerse.

La ciencia de datos, la IA y la computación científica. NumPy, pandas, PyTorch, TensorFlow – las herramientas de toda la era moderna de la IA descansan sobre Python porque Python era el lenguaje que los investigadores podían leer y extender. La apuesta por la legibilidad es, indirectamente, un pilar para el campo en el que trabajo.

La gobernanza del código abierto. El modelo BDFL, y su disolución deliberada en un Steering Council electo, se convirtió en una plantilla estudiada para entender cómo un proyecto liderado por el gusto de una sola persona puede sobrevivir a la autoridad de esa persona.

El hilo conductor

Yukihiro Matsumoto diseñó Ruby para la felicidad del programador y el principio de la menor sorpresa; van Rossum diseñó Python para el lector. Son los dos grandes lenguajes de la “alegría”, y son el mismo instinto apuntado a blancos ligeramente distintos – Matz optimiza para cómo se siente escribir, van Rossum para cómo se siente leer – razón por la cual convergen tan a menudo y por la que sus comunidades se reconocen entre sí. Donald Knuth llegó al mismo destino desde la academia con la programación literaria: la afirmación radical de que un programa es una obra de literatura escrita para humanos, y que la capacidad de la máquina de ejecutarlo es casi un efecto secundario. Van Rossum incorporó esa convicción a la gramática de un lenguaje en lugar de a una metodología. Y donde Bjarne Stroustrup puso el rendimiento de cero sobrecosto por delante y dejó que C++ creciera hasta volverse un lenguaje que toma años leer con fluidez, van Rossum puso la legibilidad primero y aceptó la lentitud del intérprete como precio – dos diseñadores, prioridades máximas opuestas, cada uno pagando en la moneda que el otro se negó a gastar. (Puente de la serie)

Lo que me llevo de esto

La lección que conservo es que la legibilidad no es cortesía; es el producto real. El código se lee mucho más de lo que se escribe, así que la versión que es clara de leer es la versión que vale más – y “ya lo limpiaré después” es una promesa a un lector que estoy traicionando en silencio ahora mismo. La jugada de van Rossum es hacer de la versión clara la opción por defecto, de modo que hacer lo correcto sea el camino de menor resistencia en lugar de un acto de disciplina. Ese es el mismo estándar que la calidad como única variable: la pregunta nunca es “¿esto funciona?”, sino “¿la próxima persona que lea esto lo entenderá tan rápido como lo necesita?”.

En el mundo en el que construyo ahora – agentes, bucles de herramientas, prompts, código de arnés que otros agentes y mi yo futuro leerán a las 2 de la mañana – la tentación es lo contrario de “la legibilidad importa”: líneas ingeniosas de una sola línea, estado implícito, cinco formas de hacer lo mismo dispersas por una base de código que nadie puede sostener en la cabeza. La jugada de van Rossum es elegir la única forma obvia y hacer honesta la estructura, de modo que lo que lees sea lo que se ejecuta. Esa convicción – que la claridad, vuelta estructural e impuesta por la gramática del sistema en vez de dejada a la fuerza de voluntad, se acumula a lo largo de todos los que la leen después – es el hilo conductor que va desde un proyecto-hobby de Navidad de 1989 hasta un arnés de agentes de 2026. El lector es el público. Construye para él.

Preguntas frecuentes

¿Cuál es la filosofía de ingeniería de Guido van Rossum?

La convicción central de van Rossum es que el código se lee mucho más de lo que se escribe, así que un lenguaje debería optimizarse para la persona que lo lee.¹ Construyó Python en torno a la legibilidad como objetivo primordial y estructural – no una pauta de estilo añadida después, sino integrada en la gramática mediante la sangría significativa, un vocabulario reducido de palabras clave y el principio de que debería haber “una forma obvia de hacerlo”.² Lo acompañó gobernando el lenguaje en abierto a través del proceso PEP y, en 2018, dejando deliberadamente de ser su autoridad final.⁸

¿Por qué Python usa sangría en lugar de llaves?

Van Rossum adoptó la estructura de bloques basada en la sangría (la “regla del margen”) del lenguaje ABC, en el que trabajó en el CWI en los años ochenta; le gustaba que pusiera fin a las discusiones interminables sobre dónde colocar las llaves.⁴⁵ La razón más profunda por la que perdura es que vuelve honesta la lectura: en los lenguajes con llaves la sangría es decorativa y puede contradecir las llaves, así que el código puede parecer que hace una cosa mientras ejecuta otra (el error de sangría engañosa). En Python la sangría que ves es la estructura de bloques que se ejecuta – no hay una segunda verdad oculta de la cual pueda divergir.

¿Quién escribió el Zen de Python?

Tim Peters, un veterano desarrollador del núcleo de Python, escribió el Zen de Python – los veinte aforismos consagrados como PEP 20 e impresos cuando ejecutas import this. No lo escribió Guido van Rossum, una atribución errónea común.² Lo que hace es destilar los propios valores de diseño de van Rossum en una forma memorable – líneas como “La legibilidad importa” y “Debería haber una – y preferiblemente solo una – forma obvia de hacerlo” articulan la sensibilidad que ya estaba incorporada en el lenguaje.

¿Por qué Guido van Rossum dejó de ser el BDFL de Python?

Van Rossum había liderado Python durante décadas como su BDFL – Benevolent Dictator For Life (dictador benévolo vitalicio), un título acuñado medio en broma en un encuentro de Python en 1995.⁷ Renunció el 12 de julio de 2018, días después de la polémica aceptación del PEP 572 (el operador morsa :=), que había sacado adelante contra una fuerte oposición. En un correo titulado “Transfer of power”, escribió: “Ahora que el PEP 572 está hecho, no quiero volver a tener que pelear tan duro por un PEP y descubrir que tanta gente desprecia mis decisiones”, se concedió “unas vacaciones permanentes de ser BDFL” y se negó tajantemente a nombrar un sucesor.⁸ La comunidad lo reemplazó con un Steering Council electo de cinco miembros.

Fuentes