06.10.2026 · Signal Titans Editorial
John Backus dijo que la pereza impulsó su trabajo. El resultado fue FORTRAN.
John Backus explicó una de las invenciones más importantes de la programación con un motivo inesperadamente simple:
“Gran parte de mi trabajo ha surgido de ser perezoso. No me gustaba escribir programas, así que empecé a trabajar en un sistema para hacerlos más fáciles de escribir.”
Ese sistema se convirtió en FORTRAN.
Antes de FORTRAN, programar un ordenador científico podía parecer combate cuerpo a cuerpo con la máquina.
Los programadores escribían largas secuencias de instrucciones de bajo nivel, gestionaban detalles del hardware manualmente y pasaban enormes cantidades de tiempo depurando código ligado a una máquina concreta.
Backus miró todo ese esfuerzo e hizo una pregunta peligrosa.
¿Por qué deberían los humanos seguir haciendo trabajo que el ordenador podía hacer por ellos?
Entró en IBM casi por casualidad
Backus no siguió un camino perfecto hacia la informática.
Abandonó una universidad tras faltar demasiado a clase. Probó medicina y la dejó. Finalmente obtuvo un máster en matemáticas en Columbia.
En 1950 entró por casualidad en la sede de IBM en Nueva York, donde se mostraba el enorme Selective Sequence Electronic Calculator.
Mencionó su interés por las matemáticas.
Un empleado le planteó varios problemas.
Backus los resolvió.
IBM lo contrató como programador aunque, según contaría más tarde, apenas sabía qué era programar.
Programar era caro porque los humanos hacían trabajo de máquina
La programación temprana obligaba a pensar constantemente en el hardware.
Las instrucciones eran extremadamente de bajo nivel.
Los programas debían adaptarse a máquinas específicas.
Los programadores invertían muchísimo tiempo traduciendo intención matemática a las operaciones diminutas que entendía el procesador.
IBM describió después problemas que podían requerir hasta mil instrucciones escritas a mano y expresarse en solo 47 sentencias FORTRAN.
La diferencia no era que FORTRAN simplificara las matemáticas.
Permitía decir más directamente qué cálculo se quería realizar.
El compilador se encargaba de gran parte de la traducción tediosa.
La objeción obvia era: el código generado será lento
Era una objeción seria.
En los años cincuenta, el tiempo de ordenador era enormemente caro.
Los programadores expertos se enorgullecían de escribir código de máquina eficiente a mano.
Muchos creían que un compilador jamás produciría código suficientemente bueno para justificar la comodidad de un lenguaje de alto nivel.
Así que el equipo FORTRAN no solo debía hacer la programación más fácil.
Debía producir programas rápidos.
Por eso el compilador fue una parte tan extraordinaria del proyecto.
El equipo de Backus desarrolló técnicas de optimización capaces de generar código competitivo con programas cuidadosamente escritos a mano.
La comodidad no exigía renunciar al rendimiento.
La productividad explotó cuando la abstracción se volvió confiable
Cuando los programadores confiaron en el compilador, cambió la economía.
Científicos e ingenieros podían expresar fórmulas en una forma mucho más cercana a su notación matemática.
Los programas tardaban menos en escribirse.
La depuración sufría menos errores de bookkeeping de bajo nivel.
El código podía moverse entre máquinas con compiladores compatibles.
Programar dejó de ser un pequeño sacerdocio de personas que conocían cada detalle de un ordenador concreto.
Más expertos de dominio podían programar directamente.
Eso es lo que hace una abstracción poderosa.
No solo ahorra pulsaciones.
Cambia quién puede participar.
La “pereza” en ingeniería puede ser una forma de ambición
La frase de Backus funciona porque la pereza parece lo contrario del logro.
Pero hay dos clases de pereza.
Una evita el trabajo necesario.
La otra se niega a hacer trabajo innecesario.
La segunda puede ser extraordinariamente productiva.
¿Por qué escribir el mismo boilerplate otra vez?
¿Por qué reconciliar datos manualmente si el sistema puede hacerlo?
¿Por qué memorizar un ritual operativo que puede codificarse?
¿Por qué obligar a cada ingeniero nuevo a redescubrir la misma regla oculta?
La automatización suele empezar con irritación.
Las mejores herramientas eliminan una categoría entera de pensamiento
Una herramienta mediocre hace una tarea antigua un poco más rápida.
Una herramienta transformadora hace innecesaria parte de esa tarea.
FORTRAN no fue solo una sintaxis más bonita para código de máquina.
Trasladó responsabilidad del programador al compilador.
El programador podía pensar más en el problema.
El compilador podía pensar más en la máquina.
Ese reparto del trabajo está por todas partes en la informática moderna.
Garbage collectors gestionan memoria.
Motores de base de datos eligen planes de consulta.
Plataformas cloud asignan máquinas.
Compiladores reordenan instrucciones.
Herramientas de IA generan código y transformaciones repetitivas.
Cada capa vuelve a hacer la pregunta de Backus:
¿Qué detalle todavía necesita atención humana y cuál conservamos solo porque la herramienta anterior nos obligaba?
Backus nunca dejó de desafiar la abstracción
Incluso después de que FORTRAN se convirtiera en uno de los lenguajes más influyentes de la historia, Backus no lo trató como respuesta final.
Más tarde criticó los límites del estilo de programación convencional y exploró programación funcional, otro intento de permitir que los programadores describieran problemas a un nivel más alto.
También ayudó a desarrollar la notación conocida como Backus-Naur Form para describir la gramática de lenguajes.
El patrón continuó.
Que la máquina gestione más maquinaria.
Que el humano piense en un nivel más útil.
La verdadera pregunta de productividad no es “¿cómo trabajamos más duro?”
Los equipos responden a la sobrecarga con más horas, más personas, más checklists y más proceso.
A veces la mejor pregunta es si el trabajo debería existir.
Backus no se hizo más disciplinado escribiendo programas de bajo nivel.
Ayudó a cambiar el nivel en el que ocurría la programación.
¿Qué trabajo estás intentando hacer más rápido cuando sería más valioso eliminarlo por completo?
Fuentes
- IBM History — John Backus
- IBM History — Fortran
- IBM Research — The History of FORTRAN I, II, and III
- Computer History Museum — John Backus
- ACM — entrevista de John Backus para el Turing Award
- Imagen destacada — John Backus, foto de PIerre.Lescanne, CC BY-SA 4.0 vía Wikimedia Commons. Adaptada a un lienzo 16:9; la obra derivada mantiene CC BY-SA 4.0.
SIGNAL TITANS