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
COBOL, el lenguaje del futuro en 1959
Y además suelen ser sistemas muy entrelazados con otros, con interfaces sin documentar..
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
No hay huevos.
Encima, deben tener un lío de dependencias entre sistemas que da miedo.
Si el software funciona ¿Para que. As a rehacerlo con el coste que conlleva?
si funciona, no lo toques!
Es un sinvivir
Y luego usar coma fija con dos decimales para todo.
"no dejes que algo deje de funcionar por no tocarlo"
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).
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.
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.
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
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.
¿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.
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.
¿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.
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.
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.
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.
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.
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.
Edit: Puse php por poner algo, yo soy de la vieja escuela: sólo Pascal Objects, C/C++ y, recientemente, C#, que estoy aprendiendo.
IBM intenta informar y acercar el mainframe a los jóvenes (masterthemainframe.com/), falta que las universidades, FPs, academias, etc lo incluyan/mantengan en los planes.
Soluciona un problema: Si
Cuesta menos mantenerlo que hacerlo de 0: Si
Mejora algo la tecnología actual: No.
¿firmas tu un software que dure lo mismo sin fallos?
PD: si pone dinero NJ no le faltarán candidatos para trabajar.
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.
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.
Prácticamente ningún programador joven quiere aprender COBOL.
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.
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.
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.
...
www.meneame.net/story/soy-programador-estas-son-mis-razones-apostar-le
digo
COBOOOOOL?
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.