El problema con COBOL: el lenguaje de programación que sostiene el mundo pero nadie sabe cómo reemplazar

A principios de la pandemia de covid, el gobernador de Nueva Jersey hizo una confesión inusual: se había quedado sin desarrolladores de COBOL. Los sistemas de seguro de desempleo del estado estaban escritos en este lenguaje de programación de 60 años de antigüedad y necesitaban actualizarse para gestionar los cientos de miles de solicitudes. El problema era que pocos empleados estatales sabían cómo hacerlo. La crisis se extendió más allá de Nueva Jersey, uno de los muchos estados que dependían de estos sistemas engorrosos. Según un cálculo aproximado, las ineficiencias de COBOL le costaron al PIB de EE UU 105 mil millones de dólares en 2020.

Cabría pensar que Nueva Jersey habría reemplazado su sistema tras esto, y que el covid supuso el fin de COBOL. Pero no fue así. El nuevo sistema de desempleo del estado trajo consigo una serie de mejoras en la calidad de vida, pero, en el fondo, seguía funcionando gracias a una computadora central que utilizaba un lenguaje obsoleto.

El lenguaje de programación más popular de la historia

COBOL, abreviatura de Common Business-Oriented Language o “Lenguaje común orientado a los negocios” es el lenguaje de programación más adoptado de la historia. De los 300,000 millones de líneas de código que se habían escrito en el año 2000, el 80% eran en COBOL. Su uso sigue estando muy extendido y da soporte a un gran número de sistemas gubernamentales, como los registros de vehículos y el seguro de desempleo; en un día cualquiera, puede gestionar transacciones financieras por valor de unos 3 billones de dólares. En mi opinión, COBOL es una especie de asbesto digital, casi omnipresente en otros tiempos y ahora increíble y peligrosamente difícil de eliminar.

COBOL fue propuesto por primera vez en 1959 por un comité integrado por la mayor parte de la industria informática estadounidense (incluida Grace Hopper). Su objetivo era establecer especificaciones para un lenguaje de programación común para computadoras digitales automáticas, con el fin de solucionar un problema creciente: el elevado costo de la programación. Los programas se escribían a la medida para máquinas específicas, y si se quería ejecutar en otro sistema, era necesario reescribirlos casi por completo. El comité se puso en contacto con el Departamento de Defensa, que acogió el proyecto con entusiasmo.

El diseño de COBOL lo diferenciaba de otros lenguajes, tanto entonces como ahora. Estaba pensado para escribirse en inglés sencillo, de modo que cualquiera (incluso los no programadores) pudiera utilizarlo; la notación matemática simbólica solo se añadió tras un considerable debate. La mayoría de las versiones de COBOL permiten el uso de cientos de palabras (Java solo permite 68), incluyendo «is«, «then» y «to«, para facilitar la escritura. Hay quienes han llegado a decir que COBOL pretendía sustituir a los programadores de programación, que en los años 60 ocupaban un lugar enrarecido en muchas empresas. Eran maestros de una tecnología que la mayoría de la gente apenas podía comprender. Los diseñadores de COBOL también esperaban que generara su propia documentación, ahorrando tiempo a los desarrolladores y facilitando su mantenimiento a largo plazo.

Una instrucción problemática

Pero, ¿qué significaba realmente ser ‘legible’? Los programas no son libros ni artículos; son conjuntos de instrucciones condicionales. Mientras que COBOL podía destilar la complejidad de una sola línea de código en algo que cualquiera pudiera entender, esa distinción se desmoronaba en programas de miles de líneas (es como un manual de montaje de Ikea: cada paso es sencillo pero, de alguna manera, el resultado no termina de encajar). Además, COBOL se implementó con una lógica que llegó a ser detestada: la instrucción ‘GO TO’, un mecanismo de ramificación incondicional que te lanzaba de una sección del programa a otra. El resultado era lo que los desarrolladores suelen llamar “código espagueti”, que hacía que la autodocumentación perdiera sentido.

Muchos informáticos tuvieron problemas con COBOL desde el principio. Edsger Dijkstra lo aborrecía abiertamente, diciendo: «El uso de COBOL paraliza la mente; por lo tanto, su enseñanza debería considerarse un delito». Dijkstra también odiaba la instrucción GO TO, argumentando que hacía que los programas fueran casi imposibles de entender. Había cierto grado de esnobismo: a menudo se despreciaba el COBOL por considerarlo un lenguaje puramente utilitario destinado a resolver problemas aburridos.

Jean Sammet, uno de los diseñadores originales, lo veía de otra manera: el lenguaje simplemente tenía la compleja tarea de representar conceptos complejos, como la seguridad social. O como escribió otro defensor: “Lamentablemente, existen demasiados programas de aplicaciones empresariales escritos por programadores que nunca se beneficiaron de una buena formación en COBOL estructurado”. Un buen COBOL era, en efecto, autodocumentado, pero dependía en gran medida del programador. Fred Gruenberger, matemático de la Rand Corporation, lo expresó así: “COBOL, en manos de un experto, es una herramienta magnífica, una herramienta muy potente. COBOL, si lo maneja un empleado inexperto, será un desastre”.