¿Es Cobol tan robusto como cuentan?

El diario El País se ha hecho eco de algo que no hace falta ser particularmente perspicaz para advertir. Y no me refiero tanto a la tesis global del artículo como a este parrafito,

[…] ambos opinan que la primera disfunción está en la Universidad. «Estamos hablando de trabajadores sobreeducados que, sin embargo, carecen de las habilidades necesarias para desempeñar el trabajo». Este contrasentido está en relación directa «con el tipo de docencia impartida en las Universidades», añaden. «Los graduados se quejan de que los modos de enseñanza se siguen basando en clases magistrales, dándole poca importancia a las clases prácticas a la adquisición directa de experiencia laboral». Esta formación academicista, exenta de habilidades prácticas, es el factor que más influye, según el estudio, […]

que se refiere a un estudio de FUNCAS. De hecho, la única asignatura universalmente troncal de nuestra (la española) universidad tiene un temario simplicísimo: aceptar acríticamente cuanto profiere el señor de la pizarra (con la esperanza de que el número que aparezca en la esquina superior izquierda de unos folios que se entregan cada seis meses sea, cuando menos, cinco).

No sé hasta qué punto los alumnos que se gradúan saben resolver el átomo de hidrógeno, en qué siglo tuvo lugar el Bienio Progresista o, apuntando por lo bajo, qué hacer con un fichero de extensión csv. Pero lo que he advertido en mi experiencia profesional es que esa asignatura troncal implícita deja una imborrable impronta en el espíritu del licenciado español medio que lo hace doblegarse sumisamente y sin emplear un solo pulso neuronal frente a las ocurrencias de un señor con corbata y galoncillos (galoncillos de gerente, director o vice-algo).

Así, la gente desaprende lo poco que de útil pueden haberle servido sus cinco o más años de asistencia a nuestras venerables instituciones educativas y va dejando que en su sique germinen semillas atávicas.

Ninguna hace tanto mal en el sector en el que ahora me desenvuevo —seguro que a causa de los pecados de alguna preencarnación mía que ahora purgo— que el mantra de que «… pero Cobol es robusto». Creo que es imposible encontrar otras cuatro palabras del diccionario que, combinadas, hayan sustraído tanto potencial productivo a la economía nacional.

Para entender el porqué hemos de remontarnos a la época en que en este país ya había bancos pero ni siquiera trenes. De hecho, BBVA y el primer ferrocarril peninsular son, más o menos, coetáneos. Las sucursales bancarias operaban aisladas entre sí, separadas por jornadas enteras en mula. Es natural que a lo largo de los años los bancos inventasen mecanismos de funcionamiento robustos, que permitiesen que sus partes continuasen operando con cierta normalidad aun cuando las comunicaciones con la central fuesen precarias. De ahí también el nacimiento de conceptos bancarios tan exóticos para el cliente moderno como el de plaza (¿ha tratado alguna vez alguno de mis lectores cobrar un cheque emitido en otra plaza?).

Con el advenimiento de los ordenadores y su campeón de sus primeros tiempos, IBM, los bancos comenzaron a adquirir maquinones y a contratar hordas de programadores en lo que fue el novamás en décadas pasadas: Cobol. Es natural suponer (y se deduce del funcionamiento actual de los sistemas bancarios) que los ingenieros de entonces se dedicaron a reproducir informáticamente las operaciones que venían realizandose tradicionalmente a mano y a lomos de équido. El incremento de productividad tuvo que ser increíble. Pero la robustez de los sistemas tuvo mucho menos que ver con esas propiedades semimísticas del lenguaje —que aporta solidez a todo lo que toca, algo así como el Rey Midas— que con el hecho de que los procesos que sustituían de manera más o menos literal habían sido creados con no otro objetivo en mente que el ser en sí mismos robustos —y que generaciones de banqueros habían hecho mejorar durante un par de siglos hasta funcionar, digámoslo así, satisfactoriamente—.

Y así pasaron los años, llegaron el modelo relacional, UNIX, NoSQL, Internet, la Web 2.0, Google, los sistemas distribuidos, etc. y las hordas de coboleros, embelesados en sus pantallas setenteras, ni se percataron. Los responsables de la cosa dieron con el mantra al que me refiero arriba y los bancos mantuvieron sus decimonónicos esquemas mentales. Peor aún, los denunciables errores de arquitectura de ese trabazón inexpugnable siguen propagándose a todo tipo de superestructura informacional moderna que quiera construirse por encima hasta el punto de que el ibuprofeno forma parte del equipo de trabajo de todo consultor que trabaje en banca.

Las consecuencias del estado de las cosas, resumidas en baja productividad y un servicio al cliente caro y malo, dan, no obstante, para un sinfín de anécdotas jocosas muchas de las cuales ya han amenizado las charlas de café en que a veces, cuando no me reclaman ocupaciones más perentorias, incurro.

Lectores míos, ¡sed rebeldes!

11 comentarios sobre “¿Es Cobol tan robusto como cuentan?

  1. J. Sales 30 diciembre, 2010 9:40

    Amigo mío, no puedo estar menos de acuerdo… en realidad no depende de cobol si no de la plataforma en que se encuentra. Lo que es robusto, y es el motivo por el que todo lo que hay en banca, aeropuertos, hospitales y demás servicios críticos, es el host. La arquitectura típica de sistemas medios (los unix y demás que comentas) requiere un mantenimiento constante para no ser desastroso. Porque sí, unix está mucho mejor que windows… pero un z es una roca en comparación. Y z entiende cobol. Y he ahí la razón. 😉

  2. rvaquerizo 30 diciembre, 2010 19:06

    A día de hoy NADA se ha mostrado más robusto que COBOL. Debería ser imprescindible una formación profesional específica tanto en COBOL como REXX, Easytrieve, entornos Mainframe, DB2,… Ojo, he dicho formación profesional, no universitaria, es una tecnología imprescindible y los pocos que la controlan están a punto de jubilarse.

  3. carlosortega 31 diciembre, 2010 9:10

    «Cobol is a very bad language, but all the others (for business data processing) are so much worse». Robert L. Glass. «Facts and Fallacies of Software Engineering»

    http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering-Development/dp/0321117425/ref=sr_1_1?s=books&ie=UTF8&qid=1293785979&sr=1-1

    Si tenéis la oportunidad de leer este libro, muy recomendable para los del gremio (¿o será ciencia?). Y ya puestos, los más recientes:

    http://www.amazon.co.uk/Software-Conflict-2-0-Science-Engineering/dp/0977213307/ref=pd_sim_b_2

    http://www.amazon.co.uk/Software-Creativity-2-0-Tom-DeMarco/dp/0977213315/ref=ntt_at_ep_dpt_5

    La ventaja de alguien que vio nacer esta industria y que ha crecido con ella, es que puede ofrecer una visión amplia de los muchas promesas incumplidas de los nuevos paradigmas que nos siguen prometiendo realidades que no terminan por verse materializadas.

  4. datanalytics 31 diciembre, 2010 9:56

    @J. Sales
    @rvaquerizo
    @carlosortega

    Con gusto os daría la razón a los tres si pudiéseis encontrar un indicio de que cualquiera de estas empresas usan tecnologías pre-Reagan: Google, Amazon, eBay, Twitter, Facebook, PayPal, Yahoo.

    O la Bolsa de Londres.

    O el Nasdaq: ¿cuántas ofertas de trabajo hay en Nasdaq OMX (la empresa que da soporte tecnológico a Nasdaq) en Cobol y similares? ¿Y en Linux y C++? Podéis comprobarlo vosotros mismos en

    http://www.nasdaqomx.com/whoweare/careers/jobopeningsus/

    ¿Hospitales? ¿Bancos? ¡Aeropuertos! ¡Vuelva Vd. mañana porque la aplicación X todavía no ha enviado el fichero Y (EBCDIC, por supuesto)!

  5. Freddy López 2 enero, 2011 16:18

    ¿Bank of Google? Sería aplastante que Google creara un banco con su tecnología: ellos no usarían, creo, COBOL. Saludos.

  6. rvaquerizo 3 enero, 2011 18:44

    @datanalitycs

    Google, Amazon, eBay, Twitter, Facebook, PayPal, Yahoo. 7 compañías perfectamente prescindibles.

  7. J. Sales 4 enero, 2011 15:25

    @datanalytics
    Con comentarios del tipo «¿Hospitales? ¿Bancos? ¡Aeropuertos! ¡Vuelva Vd. mañana porque la aplicación X todavía no ha enviado el fichero Y (EBCDIC, por supuesto)!» es inútil discutir. Te pierde la prepotencia, hermano, y el no estar dispuesto a escuchar (cosa que dicho sea de paso seguro que tampoco es la primera vez que escuchas). Lástima, acabas de perder un lector 😉

  8. datanalytics 4 enero, 2011 18:12

    @J. Sales
    No me sea susceptible, que se me equivoca.

    Es cierto que no me gusta escuchar, pero sólo a quien ni sabe resumir ni tiene criterio: soy muy gracianesco en eso de prestar atención. Y Vd. puede ser tan breve como sensato. También debería saber que he aprendido mucho de y con Vd. en el pasado y que por eso lo tengo en gran estima.

    Dicho lo cual me sorprendió tanto que rompiese una lanza en pro (en lugar de en las costillas) de IBM que sólo por no estorbar no le pedí más cumplidos detalles de su parecer. Eso sí, los ejemplos que me dio no me valen: uso de bancos, hospitales y aeropuertos; ellos tienen mi dinero, mi salud y la llave para emigrar a un país con mejor clima. Pero no mis respetos en todo cuanto tiene que ver con eficacia: para perderte una maleta y hacerte venir de Oviedo en bus (aeropuertos), darte cita para tres meses después (hospitales) o abonarte un cheque dos días después no hacen falta demasiadas alforjas.

    Y sobre los bancos, de cuyas trastiendas extraigo la mayor parte el pan que como, atesoro un sinfín de anécdotas que hacen reír la primera vez y llorar el resto.

    Que para eso usen máquinas caras («rocas» con nombre de letra postrera) a las que se pueda desaflojar alguna tuerca en caliente y sin reiniciar no sé si quita o pone a lo que dejé escrito. No critico el hierro (si acaso, en calidad de accionista y en otro foro). Ni siquiera he dicho nada del sistema operativo de esos beneméritos engendros porque nada sé de él. No dije nada del color del gato: unicamente que si cazó algún ratón, yo no lo vi.

    Insisto, tengo la máxima curiosidad por conocer su criterio sobre la cosa. Pero no crea, también le advierto, que con mis años y mi mundo me voy a dejar impresionar de la primera sigla oropelada.

  9. Steve 13 enero, 2011 14:09

    Amigos,

    @rvaquerizo

    Das en el clavo. Terminé FP de informatica allá por el 94 y aún hicimos COBOL. Lo recuerdo como algo entrañable; es ciertamente un lenguaje sólido, estable, auto-comentado (su literalidad no precisa comentarios, rem’s, ‘, %, o //’s). E incluso divertido; está muy orientado a resultados, y es facil desarrollar una aplicación de mantenimiento en un par de dias sin que ello requiera aprender nuevas ontologias, dialecticas, conceptos abstractos y toda esa verborrea de marketing, embedida en los ‘maravillosos y nuevos’ lenguajes de los ultimos años.
    Por ello me parece/ria estupendo que en FP aun se siguiera enseñando. En la universidad posiblemente también, aunque quizás podria ser mas util en ADE o economicas.

    A fac
    Lo cual no és ápice de algunos ‘facts’ que también hay que considerar:

    – En contra: Si no recuerdo mal, una pequeña aplicación para hacer un listado, te venia a requerir programar unas 60 lineas de código, contando las 4 divisiones. Demasiado código para algo tan trivial hoy en dia, a menudo en una sola linea…

    – En contra: Una cosa es hacer/te una pequeña aplicación de mantenimiento -que al final acabará siendo de todo, menos pequeña!- y otra hacer un mantenimiento/resolución-de-incidencias de algunas de las monumentales aplicaciones del sector financiero, administración y cia. De divertido y facil nada. He conocido gente dedicada al analisis y programación de COBOL en departamentos de resolución de incidencias de grandes bancos, y la mayoria acusan algo así como un permanente dolor de cabeza y a menudo, cierta frustación; buscar bugs en cientos de miles o millones de lineas de codigo no es facil ni divertido. Una aplicación normal de banco en COBOL, puede sumar perfectamente unos 6 millones de lineas de codigo.

    – A favor: Paradojas. Todo lo expansivo que es en codigo, lo tiene tambien de austero en lo referente a recursos necesarios. Es lo que tiene trabajar en ASCII con emulación de terminal

    – A favor: Ya Kernighan i cia. en su mítico libro de ‘C’ cargaba contra los programadores en COBOL. Algo así como que no son/eran ‘auténticos programadores’. Vamos a ver, son ‘auténticos programadores’ los consultores SAP? Y los programadores en Visual Basic??… La etimología no suele engañar y el cobol sirve para lo que sirve, es decir lo que las siglas de su acrónimo indican. Desde luego a nadie normal le puede pasar por la cabeza hacer I+D en Cobol, ni un S.O. nada, ni un servidor web… Pero es que no está para eso, ni para competir con el bajo nivel del C,C++!!

    – A favor: Los ‘problemas informáticos’ en sistemas de misión crítica, son reales, existen y por supuesto también para sistemas Mainframe corriendo COBOL. Pero también existen en el mundo ‘fashion’ de Java’s, Ruby-on-Rails, Groovy’es y todas esas complejidades por capas. La complejidad del cobol es inherente a la longitud del codigo requerido para desarollar aplicaciones. Por contra, las abstracciones de esos nuevos lenguajes, que en cuatro lineas te crean una aplicación, dificultan muy mucho la resolución de dependencias. Es dificil saber que hay que modificar-para-tener-tal-cosa, precisando tal o cual libreria, con tanta abstracción. En cobol, cojes el codigo, el runtime y ale…

    A finales de los 90, algunas grandes empresas se creyeron que la auditoria de sistemas de información, saldria mejor valorada si migraban a JAVA. Lo que hubieron fué un montón de problemas durante un par de años críticos con las migraciones. A dia de hoy, la mayoria siguen usando COBOL, eso si, con menus de ventanitas…

    Resumiendo. Si tu empresa trabaja con COBOL y funciona no lo toques!. Pero si tienes que desarrollar algo nuevo, pondera otras opciones. Python, Scheme, Lisp, C, C++. Como bases de datos Postgree + PL/SQL, etc… En los ultimos años se viene desarrollando un interprete/compilador -via c- libre, llamado OpenCobol que funciona muy bien (he probado de correr aplicaciones cobol antiguas y va perfecto).

    Sin duda, COBOL es el lenguaje de programación que ha movido y mueve mayores cantidades de dinero en la historia. Pensad solo en los recibos que se emiten diariamente… Para eso, para desarrollar una aplicación de recibos, facturación, etc.. COBOL es casi perfecto.

    Pero los analisis y comentarios del autor de este magnífico blog, no tratan sobre ciclos de facturación y esas cosas mas o menos triviales. Hacer mineria de datos sobre lo que produce/genera un ERP/CMS mediano, implementado parches en COBOL es simplemente una perdida de tiempo y una apuesta fija para nuevos quebraderos de cabeza. No tiene sentido, y creo que el autor del blog a ello se referia; Hacer aplicaciones, modificaciones en poco tiempo, para lo que suelen exigir de rapidez y flexibilidad los departamentos de marketing hoy en dia, no es posible. Los tiempos han cambiado y cobol vale para los modelos de negocio que perduren sin sobresaltos (hay alguno??) pero no para lo que imponen los nuevos tiempos de hiper-competitividad.

    Hay que poder hacer implementaciones y correcciones de forma mucho mas sucinta. Abstracción? Si, pero sin verborrea extra ni conceptos de marketing. Si quieres abstracción real usa LISP y si quieres resultados rapidos usa Python y sus miles de librerias.

    Para todo lo demas, C.

    Steve,

Los comentarios están desabilitados.