Grace Hopper: El compilador que lo cambió todo

Ella hizo que las máquinas entendieran palabras

21.01.2026, Por Stephan Schwab

Antes de Grace Hopper, programar significaba pensar en binario. Su invención del compilador no solo hizo la programación más fácil — la hizo posible para todos los que no eran matemáticos. La abstracción que ella pionera sigue siendo el fundamento de cada línea de código escrita hoy.

El problema que nadie quería resolver

En 1952, programar una computadora significaba escribir secuencias de números. Código máquina. Unos y ceros, o si tenías suerte, valores hexadecimales que representaban unos y ceros un poco más compactamente. Cada instrucción, cada dirección de memoria, cada cálculo — números.

Los programadores de esa era eran matemáticos. Tenían que serlo. La carga cognitiva de traducir la intención humana en secuencias numéricas requería un tipo particular de mente. La mayoría de la gente miraba la programación y veía un muro impenetrable.

Grace Hopper miró el mismo muro y se hizo una pregunta diferente: ¿Por qué deberían los humanos aprender a pensar como máquinas cuando podríamos enseñar a las máquinas a entender a los humanos?

Sus colegas pensaron que estaba loca. Las computadoras hacen aritmética, dijeron. No puedes hacer que una computadora entienda palabras. La máquina no sabe inglés.

Ella lo construyó de todos modos.

El sistema A-0: Prueba de que las abstracciones funcionan

En 1952, Hopper creó el sistema A-0 para el UNIVAC I. No era bonito. No era rápido. Lo que hacía era revolucionario: tomaba notación matemática que los humanos podían leer y la traducía a código máquina que las computadoras podían ejecutar.

Un compilador. El primero. El concepto de que podías escribir en un lenguaje y hacer que una máquina lo tradujera automáticamente a otro.

La reacción del establishment de la computación fue predecible. No le creyeron. Durante tres años, demostró su compilador y le dijeron que no podía funcionar — mientras lo veían funcionar. La resistencia no era técnica. Era psicológica. Los programadores habían invertido un esfuerzo enorme en aprender a pensar en código máquina. Se habían hecho indispensables a través de una habilidad arcana. Un compilador amenazaba esa posición.

¿Les suena familiar?

De A-0 a FLOW-MATIC a COBOL

Hopper no estaba satisfecha con hacer la programación más fácil para los matemáticos. Quería hacerla accesible para la gente de negocios que necesitaba resolver problemas de negocios.

En 1958, lideró el equipo que creó FLOW-MATIC, el primer lenguaje de programación que usaba sintaxis similar al inglés. No notación matemática. Palabras reales. COMPARE, TRANSFER, MULTIPLY. Instrucciones que un gerente de negocios podía leer y entender.

El sacerdocio de la computación estaba horrorizado. Los programadores de verdad no usan inglés, insistieron. Esto hará la programación demasiado fácil. Dejará entrar a la gente equivocada.

La respuesta de Hopper fue característica: “Es más fácil pedir perdón que pedir permiso.” Lo construyó de todos modos. FLOW-MATIC influyó directamente en COBOL, que para 1970 era el lenguaje de programación más utilizado en el mundo.

Miles de millones de líneas de COBOL siguen funcionando hoy. En bancos. En compañías de seguros. En sistemas gubernamentales. Código escrito en un lenguaje diseñado para ser leído por no programadores, todavía procesando transacciones sesenta años después.

La abstracción que sigue dando

El compilador fue más que una herramienta. Fue una prueba de concepto. Demostró que la abstracción — ocultar la complejidad detrás de interfaces más simples — no solo era posible sino esencial para el crecimiento de la computación.

Cada lenguaje de programación que usas hoy existe porque Grace Hopper demostró que las máquinas podían traducir código legible por humanos a instrucciones de máquina. Python, JavaScript, Rust, Go — todos dependen de compiladores o intérpretes que trazan su linaje conceptual hasta A-0.

El principio se extiende más allá de los lenguajes. Cada framework que oculta complejidad. Cada biblioteca que proporciona una interfaz más simple a un problema más difícil. Cada API que abstrae detalles de implementación. Todos encarnan la misma idea: los humanos no deberían tener que pensar como máquinas.

Cuando alguien te dice que los “programadores de verdad” no usan frameworks, o que deberías entender todo lo que pasa a nivel de máquina antes de que se te permita usar herramientas de más alto nivel, están repitiendo la misma resistencia que Hopper enfrentó en 1952. El gatekeeping no ha cambiado. Solo la capa de abstracción que se defiende se ha desplazado.

La perspectiva organizacional

Los tres años de Hopper demostrando un compilador funcional a personas que insistían en que no podía funcionar nos dice algo importante. Las barreras al progreso en software rara vez son técnicas. El compilador A-0 funcionaba. La resistencia era humana.

Este patrón se repite constantemente. El desarrollo guiado por pruebas funciona. La integración continua funciona. El desarrollo basado en trunk funciona. La evidencia es abrumadora. Sin embargo, las organizaciones se resisten, no porque las técnicas no funcionen, sino porque adoptarlas requiere cambiar cómo las personas piensan sobre su trabajo.

Hopper no solo construyó un compilador. Pasó años evangelizando el concepto, demostrándolo, convenciendo a escépticos uno por uno. El logro técnico era necesario pero no suficiente. El trabajo humano — cambiar mentalidades, superar la inercia institucional — era igualmente importante.

Permiso y perdón

Su famosa cita — “Es más fácil pedir perdón que pedir permiso” — no era sobre ser imprudente. Era sobre reconocer que los guardianes a menudo protegen sus posiciones en lugar de los intereses de la organización. A veces la única manera de probar que algo funciona es construirlo y mostrar resultados.

Esto no significa ignorar preocupaciones legítimas. Significa reconocer cuándo las “preocupaciones” son en realidad miedo al cambio disfrazado de lenguaje técnico. El compilador de Hopper no amenazaba las máquinas. Amenazaba el monopolio de un pequeño grupo de especialistas.

Cada vez que alguien te dice que tu enfoque no funcionará — sin probarlo — pregúntate si están protegiendo la integridad técnica o el territorio profesional. La respuesta suele ser obvia.

El estándar que emerge

COBOL se convirtió en un estándar no porque un comité lo decretara, sino porque FLOW-MATIC y lenguajes similares demostraron el valor del enfoque. El estándar siguió a la práctica, no al revés.

Hopper entendió esto. Construyó sistemas funcionales primero. La estandarización — COBOL, desarrollado por un comité en el que ella participó — vino después de que el concepto se había probado en producción. El estándar codificó lo que funcionaba, en lugar de especificar lo que podría funcionar teóricamente.

Esto sigue siendo un buen consejo. Construye algo que funcione. Demuestra valor. Deja que el estándar emerja de la práctica. La alternativa — diseñar estándares antes de la implementación — produce especificaciones que satisfacen la política de comités pero fallan en la realidad.

Lo que ella nos enseña

La contribución de Grace Hopper al desarrollo de software no fue solo el compilador. Fue la demostración de que:

La abstracción es fuerza, no debilidad. Cada capa de abstracción que oculta complejidad y expone interfaces más simples hace el software más accesible y más poderoso.

El código funcional vence a los argumentos teóricos. Tres años de demostrar un compilador funcional eventualmente superaron la resistencia que ninguna cantidad de argumentos podría haber derrotado.

El gatekeeping es sobre poder, no calidad. Las personas que insisten en que la programación debería seguir siendo difícil están protegiendo su posición, no el oficio.

Los estándares siguen a la práctica. Construye lo que funciona, prueba su valor, y el estándar emergerá.

El cambio humano es más difícil que el cambio técnico. El compilador fue la parte fácil. Convencer a la industria de usarlo fue el verdadero trabajo.

La próxima vez que uses un lenguaje de programación de alto nivel — cualquiera de ellos — estás construyendo sobre el fundamento que Grace Hopper estableció en 1952. No solo técnicamente, sino conceptualmente. Ella demostró que no tenemos que pensar como máquinas. Podemos enseñar a las máquinas a entendernos en su lugar.

Esa perspectiva lo cambió todo.