[Eslopes]

Para mí, el gran villano de toda esta historia es el comité ISO encargado de mantener el estándar del COBOL (antes esta responsabilidad estaba en manos del ANSI). Durante décadas, este grupo bloqueó sistemáticamente las innovaciones que habrían sido necesarias para mantener el lenguaje atractivo para nuevas generaciones de programadores. La programación orientada a objetos (OO) se discutía ya desde principios de los años ochenta. Recuerdo haber leído que, en una de las reuniones sobre el futuro del estándar, el equipo de Realia propuso seriamente implementar OO ya en 1989, argumentando que con un COBOL más potente, verdaderamente orientado a objetos, incluso podrían desarrollarse videojuegos de gran complejidad. La respuesta fue una mezcla de escepticismo y burla.

Los fabricantes y miembros del comité ni siquiera lograron consensuar mejoras básicas que ya en esa época resultaban evidentes, como la creación de una biblioteca estándar de clases para el lenguaje, algo que lenguajes como Java, .NET o Python ofrecen desde su concepción. Con una librería así, no tendríamos que reinventar la rueda en cada proyecto: habría componentes reutilizables para manejo de cadenas, estructuras de datos, interfaces gráficas, comunicación con bases de datos y mucho más. Sin embargo, nadie quiso colaborar. La sensación era que cualquier contribución a un código común sería interpretada como una ayuda gratuita a la competencia, y esa mentalidad cerrada terminó frenando cualquier intento serio de modernización.

Hoy, COBOL sobrevive como un paciente en estado terminal, sostenido apenas por sistemas heredados en entornos donde su presencia todavía es tolerada por necesidad. Decir que programas en COBOL fuera de estos ambientes de gran porte es, en cierto modo, como declarar que padeces lepra o alguna enfermedad contagiosa: genera sorpresa, incomodidad y hasta cierto prejuicio.

¿Y qué ha quedado en pie? Fujitsu mantiene NetCOBOL (y la versión PowerCOBOL) principalmente para cumplir contratos existentes con clientes que dependen de esas plataformas. Micro Focus ha sido adquirida —por enésima vez— por una compañía que jamás tuvo vínculo alguno con COBOL y cuyo interés real en el lenguaje es, como mínimo, discutible. Otros fabricantes históricos como Liant, Realia, Ryan-McFarland, Acusoft, PerCOBOL, RM/COBOL, Wang COBOL, DEC/VAX COBOL, HP COBOL, IBM VisualAge COBOL y varias implementaciones universitarias fueron absorbidos, descontinuados o simplemente desaparecieron del mapa. De vez en cuando surgen iniciativas aisladas, como Veryant, que generan código Java equivalente al código COBOL y luego producen un binario en bytecode. Es una estrategia curiosa e ingeniosa, pero condenada a extinguirse, porque ¿quién va a mantener un código puente que en el futuro nadie sabrá —o querrá— tocar?

Incluso lenguajes derivados o dialetos con fuerte arraigo en ciertas plataformas han ido cayendo: versiones específicas para mainframes propietarios, ediciones adaptadas para minicomputadores y compiladores especializados para sistemas bancarios o de telecomunicaciones han terminado en el olvido. La desaparición de sus fabricantes o el cierre de los sistemas para los que fueron creados los dejó sin espacio en el mundo moderno.

Es importante recordar que COBOL estuvo presente en prácticamente todas las plataformas de relevancia de los últimos 40 años. Desde microcomputadoras de 8 bits como CP/M, Commodore 64, MSX y Apple II, pasando por máquinas de 16 bits como IBM PC/XT, PC/AT y Amiga, estaciones de trabajo Unix como Sun, HP-UX y AIX, minicomputadores como VAX/VMS, AS/400 y HP3000, hasta mainframes IBM zSeries, Unisys ClearPath y Burroughs. En cada una de estas plataformas existió al menos un compilador COBOL, adaptado a sus características, lo que demuestra la ubicuidad y flexibilidad del lenguaje, aunque esta diversidad también contribuyó a su fragmentación.

Dicho todo esto, no me sorprendería que, dentro de 75 años, todavía haya quien esté debatiendo sobre cómo clonar antiguos programadores COBOL a partir de su ADN, con la esperanza de corregir el famoso bug del año 2100. Quizás para entonces, el propio COBOL sea visto más como un fósil de museo que como una herramienta viva, pero aún así seguirá teniendo esa aura de “lenguaje inmortal” que nunca termina de desaparecer.