¡Que poco sexy eres COBOL!



RSS

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?

RSS

12 comentarios

  1. Totalmente de acuerdo pero cuando terminemos con COBOL habrá que hacer lo mismo con el ABAP de SAP. Es la misma porquería de lenguaje pero recubierto por las clases de SAP.

    ResponderEliminar
  2. Jjajajja, que recuerdos, me vienen muchos compañeros a la cabeza ....
    La verdad es que se te ha olvidado hablar de esa parte sexy en negro y verde .... jajjaa
    La verdad es que estoy de acuerdo en que si se mantiene es por su facilidad, pero también por que ahora mismo está en funcionamiento en muchos sitios críticos, los cuales son difíciles (o al menos da miedo) de migrar.
    Me voy a meter en una posible guerra, pero yo, despues miraría la eliminación de los sistemas 390 ;-)

    ResponderEliminar
  3. Así fue en mi caso, hace unos 10-12 años escuche por primera vez aquello de que el cobol estaba muerto y que progresivamente comenzaríamos a trabajar con otros lenguajes que nos permitieran afrontar con garantías el futuro y atender las demandas de los usuarios. Sobre todo la de pasar de un entorno de aplicaciones de texto (as400, host, cics=el negro y verde que dice Eneko) a uno con más posibilidades visuales y graficas: java/visual basic.
    Hace unos 4 años cambio la onda por un "lo único estable es el cobol" y un "se considera como una fortaleza tener profesionales que dominen este lenguaje".
    Para un programador actual, el cobol puede parecerle el "Betty la fea" o la "Raquel Welch" de la informática, que no es el que más opciones ofrece, pero lo que hace lo borda: multiplataforma, sencillo, rápido, estable, optima gestión masiva de datos, y siempre eficiente.
    A día de hoy afirmo que está vigente y sigue vivo, pero no me atrevo a realizar un pronóstico del futuro que le espera, porque es cierto y coincido contigo, en que sin gente que se forme en este lenguaje el futuro juega totalmente en su contra.

    ResponderEliminar
  4. La gramática de COBOL es simple y brutalmente básica. Tanto o más que, por ejemplo, el formato HTML o el XML y nadie duda del éxito de ambos. Por ejemplo, el XML es lo más simple y absurdo que podría hacer un ingeniero. Y es esa misma simplicidad la que lo hace brillante, flexible, elegante. Es parte de su éxito. Tal vez a COBOL le ocurra lo mismo.

    COBOL sigue vivo porque hay aún mucha aplicación que no 'mira' a la Web pero creo que eso irá a menos cada vez a mayor ritmo. Y la falta de programadores jóvenes hará el resto...

    Es verdad que COBOL y el mainframe IBM se retro-alimentan y ciertamente hay quien piensa que el futuro de ambos está unido. Pero no hay que olvidar que los mainframes soportan zLinux y en un futuro no muy lejano soportarán Windows con su hipervisor KVM. El problema de los hosts IBM no es técnico, en el 99% de los casos es únicamente económico.

    ResponderEliminar
  5. Los mainframe soportan Z/Linux pero no tiene sentido alguno esta arquitectura si no se tienen desarrollos propietarios encima. De hecho la mayoría de las instalaciones Z/Linux son migraciones progresivas de Z/OS a Linux con un paso intermedio. Tras meses estudiando este fenómeno del Z/LINUX para algún cliente, no he encontrado ninguna experiencia de alguien que compre un Z para instalar Linux. Otra cosa es que IBM te persuada para adquirir una partición en el Z para instalar Linux y no perder el maná que suponen a IBM los sistemas Z.

    Respecto a Cobol, los humanos somos animales emocionales, no racionales, por lo que cualquier herramienta está más asociada a factores sociologicos que tecnologicos. El Cobol es un muy buen ejemplo de ello. "Video Killed the Radio Star" ;-)

    ResponderEliminar
  6. Lo interesante es la cantidad de demanda de programadores COBOL que hay. Solo hay que introducir en Infojobs la palabra COBOL y obtenemos 383 ofertas de trabajo :-)

    ResponderEliminar
  7. La misma búsqueda para Java y .Net da 1.302 y 785 respectivamente. ;-)

    Por cierto hay solo 277 para C#; menos que de COBOL. Curioso...

    ResponderEliminar
  8. Para anónimo. ¡Que tiemblen tus clientes!

    Ahora en serio, precisamente, lo que se está haciendo con zLinuz, desde hace 10 años por cierto, es migrar cargas de trabajo de entorno distribuídos al mainframe, no cargas de zOS.

    Resulta curioso ver ejecutar en un huesped zLinux bajo zVM (1 IFL y 32GB) en mainframe una aplicación Apache/JBOSS que desde hace 5 años se ejecutaba en x86; eso si, un 5% mas lenta pero aguantando 500 usuarios concurrentes y solo degradando 2 segundos en tiempo de respuesta desde 5 usuarios a 495. Por cierto, la misma aplicación en x86 (8 Xeon a 2,3 y 128GB con VMware ESX) al llegar a 200 usuario caía, eso sí, era 1 segundo más rápida.

    Tu mismo.

    ResponderEliminar
  9. Por cierto, respecto al COBOL, ya deducireis la edad cuando sigais leyendo, ¿quien dijo que no era sexy?.

    Recuerdo aquellas jovenes grabadoras que tecleaban en sus consolas los programas Cobol/370 que escribíamos en papel, ¡pero si hasta nos equivocábamos intencionadamente para ir a corregir algo cuando no compilaba!.

    Sinceramente, el COBOL se sigue y seguirá utilizando en la medida en que el resto de lenguajes de programación pase de moda.

    COBOL sobrevive porque, como dijo ROI, está vinculado a IBM, IBM posee el 90% del mercado de mainframe y el 80% del volumen de información mundial (cito a Gartner Group) está en mainframe, nos guste o no, el final del soligismo es que está en manos de IBM.

    Ningún CIO de los que cuenta para ese 80% se la jugaría recodificando sus programas críticos escritos en Cobol a un lenguaje de programación de moda (muchas modas han pasado) que puede quedar sin soporte cualquier año de estos; sin ir mas lejos el mismo java es propiedad de Sun (aunque open source) y nos dió un susto hasta que fué adquirida por Oracle. Hasta para migrar a SAP se necesitan años.

    Cobol es viejo, si, pero cualquier programa Cobol de hace 30 años funciona perfectamente en un mainframe de hoy.

    Yo, desde luego, lo tengo claro.

    Saludos.

    ResponderEliminar
  10. Ruscus, IBM tiene el 80% de información mundial dependiendo de como analices y qué valores en esa cuota de mercado. Si valoramos la información en función de su volumen, no creo que los mainframes pasen del 1% a nivel mundial. Piensa que un triste filesystem de cualquier instalación tiene 1.000 veces más volumen de información (medida en TB) que su base de datos DB2. Si medimos la cuota en Ghz de potencia de cálculo no creo que los mainframes salgan bien parados. Si medimos en GB de memoria tampoco. Si medimos en información procesada tampoco.

    Donde sí ganan los mainframes es en información estructurada (bases de datos DB2 fundamentalmente).

    Durante años he estado recibiendo, más o menos por estas fechas, mensajes de IBM y HP diciendo que ambos eran líderes en el mercado de servidores. Y era cierto, ambos decían la verdad pero uno lo era en facturación global y el otro en número de unidades vendidas. Todo depende de lo que quieras medir.

    Y respecto a aplicaciones zLinux con Apache te recomiendo que te des un paseito por la web de netcraft o cualquier otro agente imparcial y midas. Después de quitar todo lo que tiene como frontal web a IIS (obviamente no es un mainframe), lo que tiene a iPlanet/Solaris (al 99% tampoco es un mainframe el servidor de aplicaciones que hay detrás), lo que tiene el inginx y lo que tiene Google (que tampoco son mainframes), verás que la presencia de zLinux como servidor de aplicaciones es residual.

    No discuto que el zOS tenga mejor capacidad para comportarse igual independientemente de la carga a la que se le someta. En eso creo que no hay sistema operativo/transaccional que pueda competir. Pero no parece que el mercado lo reconozca de ese modo... Tal vez (digo) el precio -coste por transacción- tenga algo que ver. ;-))

    ResponderEliminar
  11. Jajajajajaja COBOL muerto... me hace gracia.

    No desacredito tus palabras, pero COBOL está más vivo que algunos lenguajes "modernos".

    Sí, es rígido, estático, "costoso" y se necesitan 10000000 líneas para hacer "algo decente".

    Pero cuando prima la velocidad, compatibilidad entre sistemas, optimización en el acceso a datos, seguridad, y sinónimos allí está COBOL.

    Y lo que dices que no está encarado a web... bueno, la entrada tiene su tiempo, pero a esas alturas creo que ya existía el visual cobol y R3... pero quitando eso, la conexión COBOL-web no es más dificil que lo siguiente:

    Una página del servidor llama al runtime de COBOL para que ejecute "X". Este "X" escribirá un fichero XML, que desde JS (con AJAX, por ejemplo, o con un 'script src="ruta_que_llama_al_ejecutable.php?parametros=los_que_quieras" ') se "parsea" i volía, ahí tienes tu orientación web...

    En fin, un saludo!

    ResponderEliminar
    Respuestas
    1. Hola David,

      Eh, que en el fondo no estamos tan en desacuerdo. ;)))

      De hecho, 100% de acuerdo en lo del rendimiento, estabilidad,... de Cobol. Por reducción a lo absurdo, ¿alguien puede hacer una aplicación en Java y .NET que funcione durante 20 años sin cambios y que tenga un rendimiento máximo y estabilidad de cinco 9s? Pues creo que va a ser que no...

      Ahora bien, dando por bueno lo que dices de Cobol y la web (nosotros trabajamos con Microfocus Cobol para NET y sé que eso se puede hacer) pero no me negarás que nadie piensa en Cobol cuando le plantean hacer un portal o app para la web. Ahora, que lo de parsear un XML desde Cobol tiene su punto. ;)))

      Buen finde.

      Eliminar


Los contenidos de Tons of IT están sujetos a licencia Creative Commons Reconocimiento 3.0 salvo donde se indique lo contrario.