Debido a la crisis sanitaria del COVID-19, el gobernador de New Jersey (USA) ha hecho un llamamiento para reclutar programadores de COBOL. Se necesitan con urgencia para mantener los sobrecargados sistemas de gestión de desempleo y en previsión a las posibles bajas de programadores, que en su mayoría son mayores de 50
|
etiquetas: covid19 , cobol , new jersey
Es un sinvivir
Falla, como todo sw, lo que pasa es que a un programa que lleva corriendo 30 años, ya se le han detectado todos los bugs
Y además suelen ser sistemas muy entrelazados con otros, con interfaces sin documentar..
Pero tal y como dicen un programador bueno aprende Cobol en dos patadas.
Yo di Cobol en la carrera, a un nivel muy básico, y no es difícil como lenguaje.
De hecho en programación la dificultad no suele estar en el lenguaje sino en el algoritmo.
Algunos lenguajes facilitan cierto tipo de algoritmos y por eso es importante escoger el lenguaje en función de la necesidad.
Hay lenguajes pensados para tratar datos, otros para operar a nivel HW, otros por su tipado hacen más difícil cometer errores, y otros que dan más libertad para hacer lo que quieras.
El lenguaje es una herramienta, y cada herramienta está enfocada a una necesidad.
Un lenguaje moderno puede ser un destornillador eléctrico multifunción con muchos cabezales, pero igual tu necesidad es clavar clavos. Con tu destornillador eléctrico podrás clavarlos a lo bruto, pero quedarán peor que con un martillo.
si funciona, no lo toques!
No hay huevos.
Encima, deben tener un lío de dependencias entre sistemas que da miedo.
Mi último proyecto en cobol fue actualizar una app de una compañía fabricante de cacharros que vuelan para prolongar su vida útil.
El resultado. Tras 6 meses de proyecto, conocía yo más los entresijos y las tripas de su aplicativo que sus ingenieros
Por supuesto, app ochentera, cero documentación disponible
¿Que durante una consulta Google no consigue hacer un barrido de todas las webs, o no siempre responde igual? Pues no pasa nada, pero ese no es el nivel de exigencia para otros negocios.
Y las peticiones que reciben no son transacciones en el sentido que se da para los mainframe, son peticiones web y no tienen por qué ser atómicas ni tienen por qué atenderse en orden estricto.
Comparas cosas distintas.
¿Mi negocio depende de que mi móvil tenga batería, o de que reciba mails?
En el primer caso además tengo opciones, puedo pillar un móvil que no se agote la batería o puedo asegurarme de tener siempre el cargador y un enchufe cerca.
Por otro lado si fuese tema de pasta no entiendo que los bancos paguen millonadas a IBM por los mainframe y el DB2, o a Oracle, pudiendo usar MariaDB o Postgre.
En su negocio lo crítico es la integridad y validez del dato (aunque estar sin web les haga palmar pasta) y por lo tanto toman medidas distintas que otros casos donde la criticidad es el aplicativo por encima del dato.
Esto hace que filtre muchísimos errores en tiempo de compilación. Pocos lenguajes hay tan fiables. Cuando consigues hacer el ejecutable, si falla algo será porque esta mal diseñado el procedimiento, pero el programa ni se va a colgar ni va a hacer cosas raras ni nada que no hubiera previsto el programador.
Ademas es muy facil de mantener, puedes leer el codigo y saber lo que hace aunque no tenga comentarios. Tiene un lenguaje más parecido al humano que al de la máquina.
Edit: Puse php por poner algo, yo soy de la vieja escuela: sólo Pascal Objects, C/C++ y, recientemente, C#, que estoy aprendiendo.
COBOL, el lenguaje del futuro en 1959
Coñe, por eso es fiable y "zero failure"
Y luego usar coma fija con dos decimales para todo.
Cobol hace lo que hace mejor que cualquier otro lenguaje en fiabilidad, eficiencia y estabilidad, y está completamente integrado en su ecosistema (servidores mainframe, BBDD, gestores de transacciones, etc).
No sentido cambiarlo si no es para mejorar, y ahora mismo no hay nada mejor en muchos casos, y suelen ser sitios donde el volumen de datos y transacciones a tratar es brutal (conozco sitios donde se ha quitado con éxito, pero no entran dentro de lo que llamo volumen brutal).
Aquí lo que prima es, con Cobol funciona, y mientras se pueda mantener el coste es bajo.
Rehacerlo y que alguien la cague cuesta millones, por tanto, si algun dia nadie usa COBOL sera un problema de la banca de mañana.
Doy soporte a un par de entidades bancarias pequeñas (muy pequeñas) que miran la pela, y que las inversiones se analizan teniendo en cuenta los costes a años vista (no cambian ni un firewall fortigate pequeño si no es a 5 años), y ahí siguen con el cobol a pesar de la pasta que les cuesta en licencias, soporte, subcontratas, etc.
Si pudiesen migrar ya lo habrían hecho, el retorno de la inversión sería de 5 años o menos en costes de licencias y operativos.
¿firmas tu un software que dure lo mismo sin fallos?
PD: si pone dinero NJ no le faltarán candidatos para trabajar.
news.eternal-september.org, tu cliente favorito (Pan/XNews/Slrn)... y a tirar millas. No, evita Google Groups, tienen un ban masivo a esa mierda para evitar SPAM e imbeciles.
Si lo que sugieres es ponerle dos alas al barco, te puedes imaginar lo que pasaría.
La inmensa mayoría de informáticos/programadores trabajan en lo que encuentran, no en lo que quieren (al menos en España), si tu pones dinero sobre la mesa, con planes de carrera, te llegarán buenos programadores dispuestos a programar cobol 8h (o 7h) por un buen sueldo. Incluso 5h y luego 3h en proyectos en otras tecnologías.
Si me ponene 50K en remoto, mañana estoy picando Cobol.
Si el software funciona ¿Para que. As a rehacerlo con el coste que conlleva?
Algún día se darán cuenta de que pagar programadores al peso al final no es la mejor estrategia.
Se puede hacer y algún banco que otro lo hizo, pero el número de aplicaciones que hay que convertir es inmenso, y dar el salto de un sistema al otro sin detener el funcionamiento es una locura.
Software AG se encargó de pasar la informática del banco Espirito Santo desde una plataforma IMB a una tipo UNIX. De esto hace ya bastantes años.
A mi me encanta que sigan los lenguajes como el Cobol. Es bonito. Llevo oyendo eso de que va a desaparecer 25 años y si me sale una oferta la de programador Cobol y me paguen 40.000€/año la cogeré. Menos dolores de cabeza.
Fortran es casi tan arcaico que COBOL, estamos en la misma.
numpy es una extensión del lenguaje, hacemos trampas
R, tal vez se le acerque, pero desconozo que tal funciona como lenguaje "normal" imperativo que acceda a bd, cosa que COBOL no hace del todo mal.
Y eso que es robusto... un lenguaje que no evoluciona tiene fallostanto en al arquitectura de diseño seguro. Como pasa en C con las asignaciones en la pila de memoria.
Yo sufri un par de años con cobol antes de pasar al delphi , durante el cambio de siglo, y ni jarto vino vuelvo a aquel cenagal. Ya he pasado por tantas cosas que ahora ya pienso retirarme con el c# y algo de python... a no ser que go y rust al final consigan ser de adopcion mayoritaria, cosa que de momento dudo.
De hecho esta exitosa técnica unido al pergamino y la vitela garantizaron el registro portable de los eventos durante miles de años hasta que un diabólico invento chino llamado actualmente PAPEL allá por el siglo VIII empezó la invasión de Europa.
El golpe de gracia lo dieron esos hijos del diablo, los arabes, que en la localidad de játiva construyeren una fabrica de papel en el año de nuestro señor 1056.
Si estudiamos la etimología de la diabolica palabra "PAPEL" vemos con profundo horror que viene del catalán PAPER.
Todo esto demuestra un milenario complot Chino-Arabe-Catalan, seguramente no ajeno a la ausencia de programadores de COBOL.
Y el número de transacciones también es otra farsa, si fuera así las bolsas usuarían COBOL y mainframes, pero no lo hacen porque hay mejores soluciones para alto volumen de transacciones y baja latencia, y antes de eso tampoco lo hacían usaban cosas como SPARC, y no creo que nadie niegue que una orden en bolsa requiere mucha más precisión y velocidad que cualquier otra transacción que te puedas imaginar.
Además de eso en todos los bancos que he trabajado siempre acaban teniendo sistemas de reconciliación de la parra para todo porque salen errores cada dos por tres en las transacciones entre ellos de todo tipo.
Para poder migrar todo, tienes que replicar toda esa funcionalidad que ha tardado décadas en hacerse, pero eso no es todo, mientras haces eso, la funcionalidad ha seguido evolucionando, es una carrera de fondo.
No merece la pena lo que te paguen por esas tecnologías, es pegarse hostias contra un muro durante X horas, sin información, sin comunidad, tu un manual de mierda es lo único que tienes a mano.
Por cierto por 50k en remoto te pones a programar muchas cosas que no generen esa frustración, deberías de dejar el sector de las cárnicas.
Espero que seas mejor programando (o lo que sea que hagas para vivir) que contando los años que han pasado desde 1960.
"...la realidad es que casi todos los sistemas que requieren gran capacidad de procesamiento por lotes (Batch), tanto las entidades bancarias como otras grandes empresas con sistemas mainframes utilizan COBOL. Esto permite garantizar la compatibilidad de los sistemas antiguos con los más modernos, así como tener la seguridad de que el lenguaje es perfectamente estable y probado".
En lo de la duda acerca del Zero Failure; estoy de acuerdo contigo. Porque, si bien al IDE original es muy posible que ya se le hayan encontrado todos los bugs; como se siguen escribiendo sobre 5.000 millones de líneas de código en COBOL cada año (algunas en una cosa que se llama Eclipse... que hace tiempo que no veo, pero que se que se sigue usando...); para mantener la retrocompatibilidad con otros programas más antiguos que corren en mainframes, siempre pueden aparecer nuevos bugs.
Sobre todo si esas nuevas líneas anuales las introducen desde Eclipse o NETCobol... donde casi seguro están escribiendo en Java.
"no dejes que algo deje de funcionar por no tocarlo"
Tu tienes un nokia6310 que no fallaba o un smartphone que apenas le dura un día la bateria? no hay mas preguntas señoria.
Los bancos pagan millonadas a lo que saben que funciona, DB2 es una mierda mas grande que mi cabezón, pero en ciertos sistemas es muy arriesgado el cambio, por eso van a ir pegando patadas hacia delante hasta que la cosa no aguante mas.
Respecto al tema de la pasta, muchas empresas se gastan casi todo el presupuesto del departamento de IT en licencias como las de SAP, porque al final sabes que no falla, aunque la UX sea una mierda, y sea carisimo de mantener.
Bancos, seguros,... fueron los pioneros y programaron en Cobol que es un lenguaje sencillo y muy estable, no falla. Sustituir millones de lineas de codigo supondria mucho dinero, para no obtener ninguna mejora.
Y me parece muy bien que le paguen un paston a la gente de Cobol y luego tengamos gente con .NET o java cobrando 900 euros.
Aunque sea prehistórico y aunque todos lo estemos abandonando precísamente por eso.
No se le da bien hacer cositas monas en un móvil, pero para llevar una contabilidad o una gestión de pedidos...
Soluciona un problema: Si
Cuesta menos mantenerlo que hacerlo de 0: Si
Mejora algo la tecnología actual: No.
Migrar un programa con varios millones de lineas de código en el que el más mínimo bug te puede hacer perder muuucho dinero te hace plantearte si realmente necesitas migrar un código que funciona bien desde hace décadas.
Cuidado, porque si miras un plan de estudios actual de cualquier ingeniería informática, de software, de teleco, etc. te darás cuenta de que C y C++ se siguen dando por muy antiguos que sean, ya que aportan unas enseñanzas que COBOL no lo hace.
Por otra parte, el hecho de que sean necesarios programadores de COBOL para momentos puntuales y empresas puntales no es como para que ahora en las universidades o en los ciclos formativos tengan que volver a enseñarlo de nuevo, más aún a sabiendas de que conociendo otros lenguajes como C o Java puedes aprender rápidamente. Otro cantar sería con Haskell, Lisp, y por el estilo.
Prácticamente ningún programador joven quiere aprender COBOL.
Lo mejor es que la gentuza que pensó eso a abandonó el barco hace tiempo.
De todos modos hablo de la fiabilidad de la arquitectura, este micro salió en el 82, dudo que los aviones de ahora usen micros fabricados en los 80, pero usan la misma arquitectura, que es más fiable porque es mas simple su fabricación, 134.000 transistores del 286, frente a los 2600 millones del i9, uno está fabricado en 14nm y el otro 90nm.
EN los 80 fabricar en 90nm tendría su complejidad, pero ahora mismo no. De ahí su uso en sistemas que tienen que ser 100% fiables.
No quise decir que ese lenguaje no sea robusto o fiable. Quise decir que el resto de lenguajes mainstream para transacciones de negocios o cualquier otra operación que requiera asincronía, concurrencia etc son tan fiables como COBOL, y por lo tanto si COBOL sigue utilizándose masivamente en lugar de lenguajes más jóvenes (en los que da gusto programar, no como en COBOL) entonces probablemente los tiros vienen por otro lado y no por fiabilidad (por pura inercia como comentaba antes en este hilo).
Me hace gracia por otro lado que hables de pasta habiendo puesto de ejemplo a Google y Facebook, que tomaron las decisiones que tomaron justamente porque empezaron sin un duro...
Y oye, que justamente por haber tenido que empezar sin pasta escogieron componentes estándar y baratos, y es lo que luego ha propiciado que se desarrolle toda una infraestructura distribuida del copon.