Los programas deben escribirse para que las personas los lean, y solo de manera incidental para que las máquinas los ejecuten. - Harold Abelson
—¿Qué perdura después de esta línea?
La prioridad de la legibilidad
Harold Abelson invierte la intuición común: aunque el software termina ejecutándose en una máquina, su vida real transcurre en la mente de quienes lo construyen, lo revisan y lo mantienen. Por eso, el “lector” principal del código es otra persona—o tu yo de dentro de seis meses—tratando de reconstruir intenciones, supuestos y decisiones. A partir de esa idea, la ejecución pasa a ser casi un detalle inevitable: los compiladores e intérpretes ya son extraordinariamente estrictos; los humanos, en cambio, somos vulnerables a la ambigüedad. Un programa puede funcionar hoy y aun así ser un fracaso si nadie puede entenderlo lo suficiente como para corregirlo mañana.
Código como comunicación
Si el código se escribe para ser leído, entonces se parece menos a una “instrucción a la máquina” y más a una carta al equipo. En esa carta importan el vocabulario (nombres), la estructura (módulos, funciones), y el tono (consistencia y estilo). Abelson, desde el espíritu de *Structure and Interpretation of Computer Programs* (Abelson y Sussman, 1985), trata la programación como un medio para expresar ideas con precisión. De ahí se desprende una consecuencia práctica: cuando un fragmento de código obliga a “adivinar”, ya está fallando como comunicación. La computadora lo ejecutará igual, pero el lector humano pagará la deuda en forma de tiempo, errores y fricción.
Mantenibilidad y costo real
Con el tiempo, casi todo el trabajo en software se convierte en mantenimiento: leer lo existente, entenderlo, modificarlo y no romperlo. En ese ciclo, la legibilidad se transforma en economía. Un ejemplo típico ocurre cuando alguien hereda un servicio crítico con variables crípticas y lógica duplicada: cada pequeño cambio se vuelve una expedición arqueológica, y el riesgo de introducir fallos se dispara. Por eso, la frase de Abelson conecta con la noción de “costo total”: el código que hoy parece “más corto” o “más ingenioso” puede ser, en realidad, más caro si dificulta la comprensión. Así, escribir para humanos es una estrategia de reducción de riesgos.
Abstracción para pensar mejor
Luego aparece la abstracción como herramienta de lectura: funciones pequeñas, límites claros, y datos modelados con intención. La abstracción no solo ayuda a la máquina a organizar la ejecución; sobre todo ayuda al humano a manejar complejidad, porque permite razonar por capas. En SICP (1985), la abstracción se presenta como el mecanismo central para construir sistemas comprensibles a partir de piezas simples. En consecuencia, un buen diseño no se mide únicamente por rendimiento, sino por cuán fácil es seguir el hilo mental: “¿qué hace esto?” y “¿por qué está aquí?”. Cuando esas preguntas tienen respuesta inmediata en el propio código, el programa se vuelve confiable.
Nombres, estilo y intención explícita
Aterrizando la idea, escribir para humanos significa hacer visibles las intenciones: nombres que describan el dominio, no solo la mecánica; comentarios escasos pero reveladores cuando el “por qué” no es obvio; y convenciones consistentes. En lugar de optimizar la sorpresa, se optimiza la previsibilidad: que el lector pueda anticipar dónde encontrar algo y cómo está hecho. Además, la claridad suele venir de decisiones pequeñas: evitar trucos, preferir expresiones directas, y separar responsabilidades. Así, el código se convierte en un documento vivo, donde cada elección ayuda a orientar al siguiente lector.
Equilibrio con la eficiencia de la máquina
Finalmente, Abelson no niega que el código deba ser ejecutable y, a veces, altamente eficiente; solo recuerda el orden de prioridades. Primero se busca claridad; después, si la medición lo justifica, se optimiza. Esta secuencia evita caer en “micro-optimizaciones” que oscurecen el programa sin beneficios reales. Con esa perspectiva, la mejor ingeniería combina ambas cosas: un sistema que la máquina ejecuta bien y que las personas pueden entender sin esfuerzo excesivo. En última instancia, los programas duraderos no solo corren: también se leen, se discuten y se mejoran.
Un minuto de reflexión
¿Dónde aparece esta idea en tu vida ahora mismo?
Citas relacionadas
4 seleccionadasLos programas deben escribirse para que las personas los lean, y solo de manera incidental para que las máquinas los ejecuten. - Harold Abelson
Harold Abelson
Harold Abelson coloca la legibilidad en el centro del oficio: el propósito principal del código no es “convencer” a la computadora —que acepta instrucciones literales— sino permitir que otras personas (incluido tu yo fut...
Leer interpretación completa →El verdadero problema no es si las máquinas piensan, sino si las personas lo hacen. — B. F. Skinner
B. F. Skinner
Skinner desplaza el foco desde la tecnología hacia la autocrítica: quizá la pregunta “¿pueden pensar las máquinas?” es menos urgente que “¿estamos pensando nosotros?”. Con ese giro, no niega la complejidad de lo artifici...
Leer interpretación completa →Imagina una solución; luego avanza hacia ella programando, una línea a la vez. — Ada Lovelace
Ada Lovelace (1815–1852)
El aforismo de Lovelace propone un puente entre la imaginación y la ejecución: primero concebir la forma de la solución y, acto seguido, avanzar hacia ella con el ritmo humilde de una línea de código por vez. Así, la ide...
Leer interpretación completa →La IA no reemplazará a los humanos, pero quienes usen IA reemplazarán a quienes no. — Garry Kasparov
Garry Kasparov
Kasparov no plantea una distopía donde la IA “toma” el lugar de la humanidad, sino un cambio competitivo: la sustitución ocurre entre personas, según adopten o no herramientas nuevas. En otras palabras, la IA no es el su...
Leer interpretación completa →Más del autor
Más de Harold Abelson →