¡Que poco sexy eres COBOL!

Las universidades lo desprecian, las empresas de tecnología lo obvian, las nuevas generaciones de programadores lo detestan, las consultoras llevan muchos años anunciando su muerte,... pero ahí está, ¡que no muere!

Hace cuatro años Computerworld  apuntaba a COBOL como número uno en la lista de las diez tecnologías que estaban muertas o muriendo. Sin embargo, a día de hoy se estima que hay más de 200.000 millones de líneas de código COBOL activas a nivel mundial y más de un millón de programadores que se ganan la vida con COBOL aportando 1.000 millones de líneas de código nuevas cada año. Más aún, a nivel mundial se estima que cada día se ejecutan más de cien veces más transacciones COBOL que todas las de la Web 2.0 (Google, Facebook, Amazon,...) juntas. No en vano, la mayor parte de la banca, compañías aéreas, telcos, compañías de seguros, médicas, transporte,... basan sus sistemas de backend en aplicaciones COBOL.

Es evidente que hay una falta de alineamiento -una más- entre lo que quiere la industria de TI y lo que ocurre en la vida real. Existe una enorme desconexión entre la programación COBOL y el mundo de Internet porque, en general, las aplicaciones COBOL no miran a la Web.

Mirando al pasado

COBOL nace en el año 1959 (es decir, con sus 50 años bien cumpliditos es más longevo que gran parte de los profesionales de TI en activo) dentro del Conference on Data Systems Languages (CODASYL). Este comité fue auspiciado por el Departamento de Defensa norteamericano y sus miembros eran, casi a partes iguales, personal de la Administración Pública y fabricantes de renombre de la época como IBM, RCA o Burroughs.

Su objetivo era crear un lenguaje de programación que pudiera ser usado en cualquiera de sus equipos independientemente del fabricante de la máquina. Vaya, curiosamente, el mismo objetivo que la máquina virtual Java pero cincuenta años antes.

Desde entonces ha habido varios estándares aceptados por la certificación ISO en los años 1965, 1974. 1985 y 2002 llegando hasta nuestros días en los que COBOL está preparado para soportar programación orientada a objetos (OOP), soportar el procesamiento y generación de formatos XML o ser utilizado en modernos GUI -Windows o la Web, por ejemplo- dirigidos por eventos. La capacidad de adaptación al medio de COBOL es indiscutible.

COBOL desata pasiones

Uno de los mayores teóricos de la computación de la historia, Edsger Dijkstra, dijo una vez de COBOL 'the use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense' (el uso de COBOL paraliza la mente y su enseñanza debería ser considerada como un delito).

Sin embargo, lo simple es bello y es indudable que COBOL es lo más simple que se puede ser siendo lenguaje de programación. Su gramática es tremendamente básica y prácticamente idéntica a como se narrarían las instrucciones en inglés a un profano en la programación.

Es probablemente esa simplicidad lo que tanto gusta a los programadores COBOL. Y es también esa sencillez en el diseño de la gramática del lenguaje la que permite una gran estabilidad y rendimiento a los binarios generados con él. No hay nada en el lenguaje que haga referencia a reserva o liberación de zonas de memoria, punteros o estructuras similares. COBOL no permite la gestión dinámica de la memoria y todas las reservas de zonas de memoria son automáticamente realizadas por el motor de runtime de COBOL lo que, sin duda, evita 'sustos' por accesos a memoria no reservada debido a fallos de programación.

Su acceso a datos, tanto a ficheros como a bases de datos, es totalmente acoplado; el programa COBOL debe conocer de antemano las estructuras de información (las famosas COPYs) a intercambiar con las fuentes de datos. Esto le da una brutal rigidez pero a cambio consigue un extraordinario rendimiento dado que la base de datos conoce de antemano las consultas que el programa realizará y tiene un plan de acceso optimizado para ello.

Por el contrario, quienes repudian a COBOL le achacan la gran cantidad de código que es preciso escribir para tareas, a veces, sencillas. Los lenguajes más modernos tienen a su disposición una gran cantidad de librerías y clases que permiten hacer prácticamente de todo. Su gramática es más compleja pero también mucho más potente lo que permite hacer más con menos aunque a veces sea a costa de empeorar la legibilidad del código que en COBOL es extraordinaria.

Al tiempo, el acceso a datos de lenguajes como C#, Java o VB es significativamente menos eficiente dado que, en general, utilizan métodos de acceso (ADO, ODBC, JDBC,...) desacoplados. El programa determina en tiempo de ejecución los campos a los que accede de la base de datos y ésta debe construir el plan de acceso de forma dinámica o, como mucho, utilizar la experiencia que le aportan los accesos previos. Sin duda, esto es mucho menos eficiente, aunque mucho más flexible, que el SQL estático propio de los programa COBOL.

Otra gran diferencia entre la cultura COBOL y la del resto de lenguajes es la programación mediante componentes. Un ejemplo de ello se percibe en los listados e informes. Si se plantea a un programador COBOL la necesidad de generar un informe probablemente lo diseñará mediante la generación de un fichero de salida que, tal vez, se componga posteriormente con un preformato para darle un aspecto más profesional. Es decir, la generación del informe se realiza a base de programación pura y dura calculando posiciones y tamaños para el posicionamiento de la información. Por el contrario, el mismo problema planteado a un programador Java probablemente se llevará a cabo mediante un generador de informes (Crystal Report, SQL Reporting Services,...) totalmente visual donde no será preciso calcular coordenadas para posicionar campos ni para verificar que no se supera el tamaño de línea. Este listado estará totalmente desacoplado del programa y es probable que no requiera ni una sola línea de programación.
Se percibe como los programadores Java o VB tienen la visión para utilizar componentes externos mientras que los programadores COBOL están fuertemente alineados con que todo debe salir del código de programación.

Se lo han puesto muy fácil

Lo cierto es que, sea o no COBOL un buen lenguaje de programación, la competencia se lo ha puesto tremendamente fácil. Por un lado Java con un pésimo rendimiento a igualdad de hardware, con colapsos de memoria o incomprensibles procesos de garbage collection.
De otra parte Visual Basic con definiciones de variables sin tipo o incluso la utilización de variables no definidas que no hacen sino causar confusión y ambigüedad. Y confusión y ambigüedad mezclada con algo tan determinista como un sistema binario solo lleva al caos.

Afortunadamente, los fabricantes de compiladores y diseñadores de gramáticas han aprendido de sus errores. Hoy no existen ya lenguajes de programación serios que permitan utilizar variables no definidas o variables sin tipo de datos estrictos. Y los rendimientos han mejorado ostensiblemente gracias al JustInTime de Java o al lenguaje intermedio MSIL de .NET, además del exponencial aumento de la potencia del hardware.

COBOL sigue siendo aún más eficiente que cualquiera de sus compañeros de viaje pero las diferencias se igualan cada vez más, casi al mismo ritmo en el que decrecen los costes de hardware, con lo que el rendimiento está dejando de ser un valor diferencial de COBOL. Igualmente, los nuevos lenguajes de programación generan binarios cada vez más estables y más ajustados al juego de instrucciones de los modernos procesadores.

Aún así, cuesta creer que dentro de cinco o diez años veamos las aplicaciones Java o .NET diseñadas hoy funcionando sin cambios y de forma estable, bien sean los cambios derivados de modificaciones de la infraestructura (versión de sistema operativo, JVM, .NET platform,...) o de fallos de programación. Sin embargo, no es difícil encontrar aplicaciones escritas en COBOL que no han sufrido cambios (salvo los evolutivos por nuevas funcionalidades) no ya en los últimos cinco años, ¡en los últimos veinte!

Pero el paso del tiempo juega en su contra

A finales del siglo pasado el cien por cien de las empresas de la lista Fortune 500 mantenía una gran parte de sus sistemas de backend mediante aplicaciones COBOL. Diez años después, la práctica totalidad de las empresas que han entrado en esa lista durante ese periodo, no cuentan con aplicación COBOL alguna. De hecho, hay quien asegura que la fecha de creación de una empresa es un buen indicador para saber si utiliza COBOL o no. La frontera parece estar en algún momento de la década de los '90 del siglo pasado y cualquier empresa de creación posterior a esa fecha no ha utilizado nunca COBOL y probablemente jamás lo hará.

Los programadores COBOL son tremendamente fieles a sus costumbres y formas de hacer pero el lenguaje, en su conjunto, no cuenta con el tiempo como su aliado. Durante una década, cuando menos, las Universidades han obviado este lenguaje de programación en sus planes de estudio y eso se nota.

Es muy significativa la diferencia en la media de edad entre un programador COBOL y un programador Java o C#. De hecho, no creo que resulte descabellado pensar que la media de edad de los programadores COBOL esté entre los 50 y 55 años mientras que la de los programadores en nuevos lenguajes se sitúe en torno a los 30 o 35 años.

Vaya por delante que incluyo el cómic sin el más mínimo ánimo de ofender a nadie

Fue Max Planck quien dijo que 'una nueva verdad científica no triunfa por el convencimiento de sus oponentes y haciéndoles ver la luz, sino más bien porque sus oponentes eventualmente se extinguen, y una nueva generación familiarizada con ella crece'.

En ese sentido, COBOL vivirá sin mayores problemas, probablemente, durante los próximos diez años dado que no hay que olvidar la gigantesca cantidad de líneas de código existentes, la gran cantidad de programadores dispuestos a mantenerlas y los elevados costes que supone plantear una migración en big-bang a un nuevo lenguaje. Pero ¿qué ocurrirá dentro de una década cuando la edad media de los programadores COBOL se acerque a la edad de jubilación?

¿Qué pasará en el futuro?

Hay varias posibles respuestas a esa cuestión pero todas apuntan a una reducción en la capacidad productiva en COBOL lo que implicará una sensible elevación salarial de su legión de programadores por diferencias entre oferta y demanda. Esta subida salarial, a su vez, hará menos interesante en costes la opción de mantener el código COBOL frente a la opción de big-bang en otros lenguajes. Y esto, a su vez, implicará más proyectos de migración a otros lenguajes y con ello una drástica disminución del número de líneas de código COBOL activas. Todo esto, sin olvidar que cualquier planteamiento de migración de lenguaje de programación es y debe ser considerado como un proyecto de ciclo. No es viable pensar en ello como algo que se puede llevar a cabo en seis o doce meses.

De seguir todo como hasta ahora parece claro que en torno a 2020 se podría producir una crisis llamada COBOL dado que el número de líneas no decrece y la fuerza productiva será cada vez menor. Pero todo esto no es más que una perspectiva probable de futuro y los humanos, salvo algún que otro genio, solo sabemos diseñar el futuro en base a proyectar el pasado. Es probable que surja algo disruptivo que haga que todo lo que se cree que ocurrirá simplemente no tenga sentido.

Hay una generación entera de programadores que piensa en COBOL como algo del pasado. Es posible, por tanto, que en base a la edad existan dos tipos de programadores del mismo modo que hay también dos tipos de técnicos de sistemas (ver El técnico de sistemas perfecto).

¡Qué poquito sexy eres COBOL! Tras, cincuenta años de servicio sustentando las grandes instalaciones de TI todo el mundo quiere hacerte desparecer. A fin de cuentas, y volviendo al inicio, el sector de TI lleva 20 años intentando reducirte a la nada y vaya si te resistes...

¿Opiniones?