Resumen

  • Tras volver al servicio naval en 1967, Grace Hopper ayudó a crear un esfuerzo de pruebas y validación de compiladores. En su historia oral de 1980 atribuyó a George Baird una técnica esencial para que las mismas rutinas de prueba pudieran ejecutarse en distintas máquinas.
  • Las pruebas permitían observar funciones COBOL seleccionadas y comparar resultados. No demostraban que un compilador fuera perfecto, que se hubieran probado todas las combinaciones ni que cualquier aplicación se trasladara sin cambios.
  • Una norma define el comportamiento esperado; una suite examina una muestra limitada de una implementación; una prueba de migración verifica la aplicación y su entorno reales. Llamar «portabilidad» a los tres niveles oculta lo que aún no se ha comprobado.

El comprador necesitaba algo más que una norma

Para una agencia que adquiría ordenadores de varios fabricantes, COBOL ofrecía una posibilidad atractiva: conservar el programa aunque cambiara el proveedor. Pero compartir el nombre del lenguaje no aseguraba que todos los compiladores implementaran del mismo modo cada función requerida. El estándar fijaba una referencia; no era una medición de la máquina entregada.

Ahí comienza una etapa menos conocida de Grace Hopper. La historia habitual se detiene en su trabajo temprano con compiladores y en la influencia de FLOW-MATIC sobre COBOL. Este artículo sigue otra pregunta: ¿cómo se convirtió una meta de compatibilidad en evidencia que una institución pudiera revisar antes de comprar? La respuesta no fue una frase en un pliego, sino una prueba repetible con entradas, salidas esperadas, resultados observados y un procedimiento para localizar fallos.

El trabajo tenía antecedentes colectivos. En su artículo de 1972 sobre el sistema de validación COBOL del Department of Defense, George N. Baird describió un grupo de trabajo que había empezado en 1963. El grupo escribía programas para comprobar la disponibilidad de funciones definidas por el estándar. No intentaba depurar todos los compiladores ni probar todas las combinaciones posibles. Seleccionaba funciones, solas o combinadas, y registraba el comportamiento.

Del error a un informe reproducible

Las primeras rutinas de la U.S. Navy, según Baird, ampliaron ese trabajo con informes más útiles: el resultado generado podía compararse con el esperado y el reporte identificaba el procedimiento donde aparecía un fallo. La versión preliminar tenía 12 programas y cerca de 5.000 líneas de código fuente.

La diferencia entre una consigna y una evidencia es importante. «Nuestro compilador es compatible con COBOL» deja mucho sin precisar. «Aceptó estas construcciones requeridas y produjo estas salidas en esta configuración de prueba» es una afirmación que otro comprador puede repetir. La suite no sustituía el juicio técnico; hacía que una parte de ese juicio quedara a la vista.

En la entrevista que el Computer History Museum grabó en 1980, Hopper recordó que Norman Ream le pidió volver al servicio activo en 1967. Según su relato, el objetivo era desarrollar procedimientos de prueba y validación para sostener estándares y permitir que los programas pasaran de un sistema a otro. Ella comparó la tarea con ensayar un producto: una norma necesita pruebas para mostrar si una implementación la cumple.

Hopper dijo que pidió programadores para formar el equipo. Mencionó al civil Ed Ford, a un teniente y a dos marineros; George Baird estaba entre los primeros integrantes. Arnold Johnson se incorporó más tarde. Un artículo de Datamation de enero de 1971 aporta una señal contemporánea: informó que la U.S. Navy exigía entonces validar los compiladores COBOL y que el DoD y el National Bureau of Standards habían acordado en principio desarrollar rutinas comunes contra la norma ANSI. «En principio» no significa que el servicio federal ya estuviera terminado.

El mecanismo que Hopper atribuyó a Baird

Lo más revelador de la entrevista no es una reivindicación personal. Hopper dijo que George Baird ideó cómo aislar en datos de configuración las diferencias propias de cada máquina, como nombres especiales y tarjetas de control. Así, la lógica de las pruebas podía permanecer en COBOL estándar y un archivo pequeño podía aportar los detalles necesarios para un ordenador concreto.

La portabilidad tenía que alcanzar también a la herramienta de validación. Si cada compilador exigía reescribir todos los programas de prueba, la comparación entre fabricantes habría sido cara y difícil de mantener. Separar las pruebas comunes de los adaptadores locales permitía repetir la misma lógica y documentar, a la vez, las diferencias entre sistemas.

El testimonio de Hopper es retrospectivo, por lo que conviene tratarlo como su recuerdo de la división del trabajo. El artículo de Baird, publicado en 1972, ofrece un anclaje técnico cercano a los hechos. En conjunto, las fuentes sostienen una atribución prudente: Hopper ayudó a establecer la misión y el equipo; Baird aportó un mecanismo importante; otras personas y organismos habían desarrollado piezas anteriores. No sostienen que una sola persona escribiera COBOL o todo el sistema de validación.

Lo que una aprobación no certificaba

Una ejecución satisfactoria mostraba que el compilador había aceptado las funciones seleccionadas y producido los resultados esperados bajo esas condiciones. No demostraba que se hubieran ensayado todas las combinaciones válidas, que se hubieran descubierto todos los defectos ni que una aplicación concreta funcionara sin cambios en otra máquina.

No era una limitación exclusiva de COBOL. La historia de NIST sobre otro esfuerzo, los programas de prueba FORTRAN dirigidos por Betty Holberton y Elizabeth Parker, explica que un conjunto finito de pruebas no puede demostrar por completo que un compilador sea correcto. Aquel trabajo del NBS era paralelo, no el sistema COBOL de Hopper. Mantener la distinción da un retrato más exacto: la validación de lenguajes se estaba convirtiendo en una práctica institucional con equipos y lenguajes distintos.

La conformidad del compilador y la portabilidad de una aplicación son capas diferentes. Un compilador puede superar los casos seleccionados mientras el programa depende de una extensión del fabricante, un servicio del sistema operativo, un formato de archivo, una conducta del runtime o una representación de datos. Esa conclusión se infiere del alcance de las pruebas; no significa que la suite naval examinara cada una de esas dependencias. Para mover una aplicación hacen falta pruebas propias y un registro del entorno donde funcionaba.

La lección no es desconfiar de las normas ni de las pruebas, sino nombrar exactamente qué acreditan. La norma define el objetivo. Una suite verifica una muestra acotada de una implementación. La prueba de migración comprueba el sistema que la organización quiere mover. Reducirlo todo a «portabilidad» convierte una evidencia parcial en una promesa demasiado amplia.

La ventaja de conservar los límites

La contribución de Hopper resulta más interesante sin inflarla. Ayudó a transformar una aspiración de interoperabilidad en una función de validación con personal y procedimientos. Su relato también muestra un estilo de dirección que rara vez cabe en la imagen del inventor solitario: pedir colaboradores y atribuir el mecanismo técnico a quien lo diseñó.

La solución de Baird explica por qué ese crédito importa. La portabilidad dependía del diseño de los casos, la configuración para cada equipo, la comparación de resultados y la repetición de la prueba. Una norma sin comprobaciones observables dejaba al comprador con una afirmación. Una suite sin autores borraba parte del trabajo. Una etiqueta de aprobado sin límites podía prometer más de lo que la evidencia demostraba.

En software de larga vida, la evidencia debería acompañar a la afirmación: versión de la norma, compilador, pruebas, configuración específica de la máquina y resultados. El trabajo naval de Hopper no eliminó las diferencias entre proveedores. Dio a las instituciones un modo de revelar algunas, comparar implementaciones y decidir compras con mejores datos. Es menos grandioso que «COBOL hizo portátil el software», pero mucho más útil.

Fuentes