Portada
mis comunidades
otras secciones
#2:
Año 2137.
Empresas de todo el mundo siguen buscando desesperadamente a programadores COBOL y las farmacias españolas siguen recortando el código de barras de los medicamentos con receta.
Empresas de todo el mundo siguen buscando desesperadamente a programadores COBOL y las farmacias españolas siguen recortando el código de barras de los medicamentos con receta.
#1:
Yo con estos articulos parto.
Traducir COBOL a Java es lo fácil.... ahora quien tiene los santos cojones de verificar que eso es correcto? En finanzas, en movimientos de cuenta intradiarios de miles de millones?
Traducir COBOL a Java es lo fácil.... ahora quien tiene los santos cojones de verificar que eso es correcto? En finanzas, en movimientos de cuenta intradiarios de miles de millones?
#9:
"Traducirlo a Java".
A ese. Justo a ese. No había ningún otro. Será por lenguajes. Y eligen Java.
A ese. Justo a ese. No había ningún otro. Será por lenguajes. Y eligen Java.
#5:
Ineficiente, dice. Eso lo dudo porque el cobol se compila y se traduce a lenguaje máquina. Lo que pasa que no encuentran gente con cojones a coger un código montado hace 40 años, mucho sin comentarios, y poderlo mantener y saber qué hace cada línea.
#12:
#8 Es más fácil hacer un modulo en Cobol desde cero que intentar entender la lógica de algunas de sus aplicaciones, no es un lenguaje difícil, te lo digo yo que llevo años con el, y seguiré con el bastante más tiempo, porque llevan matando a Cobol 30 años, han salido traductores a otros lenguajes, pero ahora dile tú a Visa, AIG, Carrefour que confíen en esa traducción cuando ese programa en Cobol que tiene 40 años funciona aunque cambies de un 4381 a AS/400 a un 360 o un z/14 y sin recompilar, lo que deben hacer es formar más a la gente y pagar de verdad lo que deben pagar.
#15:
Os voy contar alguna experiencia que he tenido indirectamente con el COBOL y la madre que lo parió.
El lenguaje en sí, no es complicado. De hecho, como conozcas un poco de ensamblador rústico (nada de CUDA, x64 y similares) enseguida hacer un paralelismo entre el COBOL y el ensamblador. De hecho en COBOL se utiliza MOVE para asignar valores como se hace en ensamblador.
¿Dónde se complica la cosa? Pues en la cantidad de mierdas que utilizan para hacer cosas teniendo en cuenta que antes la memoria y el disco eran carísimos. Si se pueden usar valores de BIT mejor que usar BYTES o enteros. Hace un montón de años nos enfrentamos a sustituir una APP de Telefonica que se dedicaban a las averías (AF se llamaba la jodía) y resulta que la muy hija de puta hacía cien mil cosas más de las que esraba diseñada originalmente debido a que como era una APP que estaba en todas las centrales, era más barato meter funcionalidad en esa APP (aunque no tuviera nada que ver) que desarrollar una nueva (idos 20 años atrás, no penséis con mentalidad de ahora)
Luego añade cosas como que por ejemplo había cosas hechas a mano como un indexado de fichero porque en la época de su desarrollo. no había BD disponibles (hablo de a lo mejor hace 50 años) o eran demasiado caras. O que parte del código estuviera hecho en ensamblador aunque para esto había dos teorías:
- La oficial, se hizo en ensamblador para mejorar las prestaciones.
- La extraoficial. Con el paso de los años hemos perdido los fuentes y hemos tenido de desensamblar a ver qué leches había ahí.
Y no veas la risa que daban las limitaciones que metía el dueño del servidor, cosas como "máximo dos segundos de CPU" ... anda que no nos acordamos del mangante que puso esto cuando tenías que dividir una operación en varios por ese requisito.
Por suerte no me he vuelto a acercar a un chisme de esos, pero sí tengo compañeros que sí lo han hecho para pasar de COBOL .... ¡oh campos de soledad, mustios collados! ¡¡¡ a JAVA !!! (por ahi lo han mencionado también) Parece absurdo pero es que el "conversor" hacía eso.
El lenguaje en sí, no es complicado. De hecho, como conozcas un poco de ensamblador rústico (nada de CUDA, x64 y similares) enseguida hacer un paralelismo entre el COBOL y el ensamblador. De hecho en COBOL se utiliza MOVE para asignar valores como se hace en ensamblador.
¿Dónde se complica la cosa? Pues en la cantidad de mierdas que utilizan para hacer cosas teniendo en cuenta que antes la memoria y el disco eran carísimos. Si se pueden usar valores de BIT mejor que usar BYTES o enteros. Hace un montón de años nos enfrentamos a sustituir una APP de Telefonica que se dedicaban a las averías (AF se llamaba la jodía) y resulta que la muy hija de puta hacía cien mil cosas más de las que esraba diseñada originalmente debido a que como era una APP que estaba en todas las centrales, era más barato meter funcionalidad en esa APP (aunque no tuviera nada que ver) que desarrollar una nueva (idos 20 años atrás, no penséis con mentalidad de ahora)
Luego añade cosas como que por ejemplo había cosas hechas a mano como un indexado de fichero porque en la época de su desarrollo. no había BD disponibles (hablo de a lo mejor hace 50 años) o eran demasiado caras. O que parte del código estuviera hecho en ensamblador aunque para esto había dos teorías:
- La oficial, se hizo en ensamblador para mejorar las prestaciones.
- La extraoficial. Con el paso de los años hemos perdido los fuentes y hemos tenido de desensamblar a ver qué leches había ahí.
Y no veas la risa que daban las limitaciones que metía el dueño del servidor, cosas como "máximo dos segundos de CPU" ... anda que no nos acordamos del mangante que puso esto cuando tenías que dividir una operación en varios por ese requisito.
Por suerte no me he vuelto a acercar a un chisme de esos, pero sí tengo compañeros que sí lo han hecho para pasar de COBOL .... ¡oh campos de soledad, mustios collados! ¡¡¡ a JAVA !!! (por ahi lo han mencionado también) Parece absurdo pero es que el "conversor" hacía eso.
#57:
Mi primer trabajo como programador en COBOL.
Me viene un account manager de mi empresa cárnica y me dice que en una semana empiezo en un cliente nuevo como programador en COBOL.
Le respondo que no tengo ni idea de COBOL y me dice que no es problema, que con lo que sé de mainframe es suficiente y que me estudie un manual de COBOL por las tardes.
Llego al nuevo cliente el lunes y el hijodeputa del Account Manager me presenta al cliente como “ el experto en COBOL del que te había hablado”
Me viene un account manager de mi empresa cárnica y me dice que en una semana empiezo en un cliente nuevo como programador en COBOL.
Le respondo que no tengo ni idea de COBOL y me dice que no es problema, que con lo que sé de mainframe es suficiente y que me estudie un manual de COBOL por las tardes.
Llego al nuevo cliente el lunes y el hijodeputa del Account Manager me presenta al cliente como “ el experto en COBOL del que te había hablado”
#63:
Al lenguaje de programación COBOL lo quieren jubilar [...] no hay ya muchos profesionales que puedan programar en este lenguaje, así que IBM se ha propuesto tomar otro camino: traducirlo a Java."
JAAAAAAAAAAAA JAJAJAJAJAJAJAJAJAJ DIOOOOOOOOOOOS JJJAJAJAJJAJAJAJAJJAJAJAJAJAJJAJAJAAJJAJAAAAAAAAAAAAAAAAAAAAJAJAJAJJJAJAJAJAJAJJ
https://i.gifer.com/7Djv.gif
JAAAAAAAAAAAA JAJAJAJAJAJAJAJAJAJ DIOOOOOOOOOOOS JJJAJAJAJJAJAJAJAJJAJAJAJAJAJJAJAJAAJJAJAAAAAAAAAAAAAAAAAAAAJAJAJAJJJAJAJAJAJAJJ
https://i.gifer.com/7Djv.gif
#8:
#5 Creo que llevas razón, a mí me tocó hace un par de años un código de esos (montado hace unos 30 años), y sin tener ni idea de COBOL, tuve que modificarlo para añadir algunas historias y tampoco me pareció para tanto, a la que sepas un par de lenguajes y seas un poco despierto (y sepas leer documentación en inglés), te haces con ello. Otra cosa sería hacer cosas complejas de cero, que seguro sería incapaz. De hecho, a la siguiente cosa similar que hubo que hacer (pero bastante más gorda), lo pasamos a Java y santas pascuas.
#54:
#2 lo de los medicamentos está destinado a extinguirse en breve. Creo que para 2024 tenían establecido meter un código único en los envases para escanearlo y evitar tener que recortar nada. Piensa que hasta ahora recortar el código de barras del envase era la única forma de verificar que no estaban tangando al estado en la venta de productos con receta... 1 código recortado = 1 producto vendido.
Comentarios
Año 2137.
Empresas de todo el mundo siguen buscando desesperadamente a programadores COBOL y las farmacias españolas siguen recortando el código de barras de los medicamentos con receta.
#2 si funciona, para que cambiarlo?
#2 #35 #38 En la mía lo de las recetas no (para el sistema público, claro)
#2 y pegándolos en una libreta con celo.
#2 lo de los medicamentos está destinado a extinguirse en breve. Creo que para 2024 tenían establecido meter un código único en los envases para escanearlo y evitar tener que recortar nada. Piensa que hasta ahora recortar el código de barras del envase era la única forma de verificar que no estaban tangando al estado en la venta de productos con receta... 1 código recortado = 1 producto vendido.
#54 El código QR único ya está en las cajetillas. De hecho, en las farmacias que voy, es lo que pasan por el escaner. Aunque luego les toque recortar el código de barras.
Por cierto, así, además tienen fichado quien ha comprado dicha cajetilla, por si luego aparece en la reventa.
#2 El programa que gestiona los medicamentos estará hecho en Cobol
#2 si yo te contara cuando fui a la oficina presencial cuando fui a sacarme el certificado digital personal....
#2 Conoci el COBOL hace ya mas de 42 años y ya se decia ..."El COBOL ha muerto" ... sigue alli y parece que seguira alli
Yo con estos articulos parto.
Traducir COBOL a Java es lo fácil.... ahora quien tiene los santos cojones de verificar que eso es correcto? En finanzas, en movimientos de cuenta intradiarios de miles de millones?
#1 pues mas IA en cloud computing in the edge con smartdust y mas palabros que ahora mismo no se me ocurren
#4 a mi me gusta Powered by Entropy Neural Engineering, no significa nada, pero mola
"A este departamento lo que le falta es un poco de P.E.N.E." creo que es el futuro de la empresa
#6 Eso combinado con un Virtual Asisted Generated Integrated Neural Alignment (V.A.G.I.N.A) y lo petas por todas partes.
#17 "Lo petas por todas partes"
#6 No creo que lo que suela faltar en departamentos de informática sea P.E.N.E.
Me inclino más por la opción de #7
#28 lo que hace falta es programming assistance, summarization, and testing automation (PASTA).
#55 Y sobra mucho high developer programmer (H.D.P)
#61 high developer language general programmer (H.D.L.G.P)
#6 Trabaje para una empresa en la que venían gente de todos los departamentos a perder el tiempo en nuestras reuniones: "hola somos de PMC", "venimos en representación de I+D+I", "merche de QA",..., "somos chus y paco, de Planificación y Seguimiento (así sin siglas ni nada)".
#6 ¿Como que no? Si yo tengo un máster en eso
#4 Inteligencia artificial en cálculo nuboso al filo con polvo listo.
Traducido al español parece un plato del Dabiz Muñoz.
#16 más bien parece un artículo chungo de aliexpress
#23 ¿Hay alguna diferencia?
#16 A mi me has convencido con lo del polvo.
#43 Es que en informática hace falta mucho de eso que dices...
#52 Es que la informática funciona gracias a la magia.
#56 Muchas veces es así.
#4 Blockchain! Cancamusa!
#29 Y de postre?
#29 #31 Y de beber, albóndigas.
#4 se te olvidó el grafeno
#4 "y ahora vete de aquí o inventaré más palabras"
#1 el mundo de las finanzas sería bastante sencillo pero lo han convertido en una gigantesca telaraña con el objetivo de: lavar dinero, eludir impuestos, estafar gente.
No soy religioso, pero la Biblia habla del diezmo, cómo impuesto. Más sencillo imposible. Pero no, te llega un ejército numeroso para convertir el diezmo en el más complejo y complicado ejercicio tributario posible.
Si las finanzas fueran sencillas, cualquier lenguaje de programación serviría.
#14 En el mundo preindustrial, los cereales había que segarlos a mano, así que una persona recogía/producía una cantidad que no era muy superior a lo que acabaría consumiendo. De ahí el diezmo.
#1 Suerte con los go to.
#22 Pues los PERFORM los carga el diablo
#97 Te cambio 10 perform por 1 go to.
#1 no tanto el problema es el lenguaje, ahora que lo van a sacar de mainframe y ponerlo en la nube, sino cambiar toda la filosofía batch y plantearlo con microservicios, que sería lo interesante para usar Java.
Pero eso tiene tela marinera
#1 Hombre, traduces el programa en COBOL y traduces los test unitarios y de integración y luego ya lo ejecutas todo y ya está, no?
#37 test unitarios y de integracion en CoBol ????
#1 Lo pones a funcionar en paralelo con el sistema viejo y vas comprobando que ambos proporcionan la misma salida para identicos datos de entrada.
#40 asi lo estan haciendo en el Santander
#1 acaban antes pasándose a la blockchain
#1 Creo recordar que con programación estructurada existe una lógica que te puede garantizar que el resultado obtener es correcto y que el algoritmo acaba.
Con programación no estructurada creo que no es que no se conoce una lógica así, es que creo que no puede existir esa lógica.
COBOL es no estructurado
#51 Hace años que incluso soporta programación orientada a objetos.
#99 El lenguaje sí, pero la mierda de programas que hay por ahí no tendrán ni funciones.
#1 "eso" que ha sido escrito por una IA que no sabe lo que hace y está especializada en escribir cosas que dan el pego.
#1 Y de mantener el engendro COva que salga de ahí. Luego IBM te venderá la IA que lo mantenga porque no encuentran programadores de COva.
#1 y como si el problema no fuera precisamente la confiabilidad de COBOL sobre Java. Sinceramente, siendo desarrollador Java, si algún día me entero que los bancos se pasan a él, saco mi dinero y lo keto bajo el colchón. Más seguro estará.
#1 y la capacidad del lenguaje y del mainframe, es un lenguaje simple, pero muy eficiente en lo suyo
#1 Te respondo yo.
Contratando a una persona que sabe lo justo de Java, y para tener que lidiar con la versión antigua de Java que use el banco en cuestión, y cotejando los resultados en cobol con los resultados en Java en unas cifras con muchos decimales.
Son puestos que requieren cierto conocimiento tanto de Cobol como de Java, así que pillan al primer ingeniero que se preste a hacerlo y le pagan ilegalmente todas las horas extras que le hagan hacer.
#1 Y el rendimiento... mañana.
Los coboleros de mi época escuchábamos garbage collection y nos imaginábamos camiones de basura.
Que como lenguaje es limitadísimo, no lo niego. Pero para lo que se diseñó iba de narices, no me imagino la forma de salirme de la memoria de un PIC 9(9)V99 ni poder tirar un equipo.
Para las virgerias ya teníamos el ensamblador o el C... Coño, ahora que recuerdo el último cobol con el que trabajé permitía llamar a rutinas en ensamblador, así que me la envaino un poco.
#94 El rendimiento se la suda a la mayoria. Tengo el culo pelado de ver cruzarseles los ojos a los desarrolladores cuando les hablas de algo como el recolector de basura o gestionar a manija la memoria. Ni que decirte las peleas que hay con los hilos o el control de consultas, que parece que les regalan los recursos.
Pero weno... cada uno tendrá su librillo.
#1 Test unitarios?
#1: Como el MCAS de los aviones 737 MAX.
A ver, murió gente, no tiene gracia, pero es que este tipo de propuestas son tan ridículas...
"Traducirlo a Java".
A ese. Justo a ese. No había ningún otro. Será por lenguajes. Y eligen Java.
#9 Sugiere uno más adecuado. Hay toda una industria multimillonaria esperando soluciones.
#34 ¿Alguno con un sistema de tipado seguro?
#46 #34 Ada?
#46 TypeScript
#34 si quieres eficiencia nivel COBOL y seguridad: Rust.
Si quieres la JVM: Scala o Clojure.
Si quieres algo moderno: Mojo.
Si quieres verificación formal: Elixir, Erlang, o Haskell.
Si quieres crear un portal al infierno: JavaScript.
#47 Y si quieres el respeto de Carmack, C/C++
#69 Carmack te puede respetar con JavaScript, no porque hagas Doom realidad, sino esto:
#34 QuickBasic
#34 JavaScript
#9 java mola.
Pero kotlin mas.
#36 Java da asco. No me entra no hay manera de que me guste. Los errores de Java son crípticos, poco claros. Y el lenguaje es feo.
#9 A día de hoy, Java es el mejor lenguaje de programación para desarrollar backends. Robusto, maduro y con un gran ecosistema (Spring/SpringBoot, Quarkus, etc..)
#41 y encima ha evolucionado MUCHO desde java7
#9 ¿qué sugieres? ¿Pasarlo a Python? ¿A javascript? ¿A Go? ¿A Rust?
#42 Sí.
#9 obsolescencia programada
luego traducirán java a basic, y que siga la fiesta
#9 es que debe ser una migración muy suave: de una inmunda mierda putrefacta a una inmunda mierda. Poco a poco la humanidad saldrá de ese pozo de mierda informática
#9 el daño que ha hecho Java a la informática es irreparable
#9 Eligen el lenguaje en que los monos cobren menos cacahuetes.
A ver, no es una decisión tecnológica. Es una subnormalidad que se le ocurren a gestores para convencer a gestores de venderles algo.
Luego, una vez vendido, pues ajo y agua. De contratos con esa empresa no puede salir nada bueno.
#9 Como dice #119, si el problema es la falta de profesionales que conozcan COBOL, Java es una estupenda solución 😂
Ineficiente, dice. Eso lo dudo porque el cobol se compila y se traduce a lenguaje máquina. Lo que pasa que no encuentran gente con cojones a coger un código montado hace 40 años, mucho sin comentarios, y poderlo mantener y saber qué hace cada línea.
#5 Creo que llevas razón, a mí me tocó hace un par de años un código de esos (montado hace unos 30 años), y sin tener ni idea de COBOL, tuve que modificarlo para añadir algunas historias y tampoco me pareció para tanto, a la que sepas un par de lenguajes y seas un poco despierto (y sepas leer documentación en inglés), te haces con ello. Otra cosa sería hacer cosas complejas de cero, que seguro sería incapaz. De hecho, a la siguiente cosa similar que hubo que hacer (pero bastante más gorda), lo pasamos a Java y santas pascuas.
#8 A veces si hay que añadir alguna función si que es genial gracias a su modularidad. Lo malo es cuando lo hacen correr en un sistema nuevo o el SO nuevo requiere modificaciones en el código para que funcione correctamente lo que funcionaba antes y luego no te funciona ni a tiros, o no hace lo mismo, y arreglas algo y se te estropea otra cosa, etc. Entonces si entiendo hacerlo de cero en otro lenguaje, lo malo es que para plataformas S/IBM COBOL es ideal.
#8 Es más fácil hacer un modulo en Cobol desde cero que intentar entender la lógica de algunas de sus aplicaciones, no es un lenguaje difícil, te lo digo yo que llevo años con el, y seguiré con el bastante más tiempo, porque llevan matando a Cobol 30 años, han salido traductores a otros lenguajes, pero ahora dile tú a Visa, AIG, Carrefour que confíen en esa traducción cuando ese programa en Cobol que tiene 40 años funciona aunque cambies de un 4381 a AS/400 a un 360 o un z/14 y sin recompilar, lo que deben hacer es formar más a la gente y pagar de verdad lo que deben pagar.
#12 pero igual no pueden contratar aunque estén dispuestos a pagarlo a un programador senior con experiencia y conocimiento, porque por la política de diversidad e inclusión dictada desde la central, resulta que ya tienen muchos perfiles similares en la plantilla, y queda mal el informe de RSC.
Así que lo contratan como consultor externo, llevándose la cárnica su porcentaje pero teniendo al trabajador cabreado desde el minuto uno, por ejemplo obligándole a presencial sin permitirle usar el parking de la empresa, o viendo que perfiles mucho más junior sí tienen contrato en cliente final, por enchufismo+diversidad. Así que el trabajo queda hecho a medias, chapuceramente y en cuanto puede ser pira a otro proyecto el que pillaron para arreglarlo.
#33 Pero no solo ocurre en el entorno Mainframe, ocurre en muchos departamentos de informática y en otros muchos trabajos, en España lamentablemente se suele respetar muy poco al trabajador.
#8 La mayoría de los lenguajes de programación non son difíciles; el "problema" viene en conocer y manejarse bien con las bibliotecas estándar o de terceros más usadas, herramientas específicas, acostumbrarse y recordar usar las peculiaridades del lenguaje,...
#27 O entender la forma de pensar de todos los que han pasado por allí... Primera versión, parches, cosas que no se usan ya pero que no se borran...
Programar es un arte, pero el mantenimiento es otro nivel.
#8 "y seas un poco despierto "
Eso es lo que marca la diferencia y es lo que se llama talento y no todo el mundo lo tiene.
#8 A que si te multiplican el sueldo por tres, haces todo lo que haya que hacer.
#5 sigo sin ver la complicación, si cobol tuviera perspectiva de futuro positivias, cualquiera te programa en el.
#5 si algo tiene COBOL es que está súper documentado y que es muy fácil de entender en un vistazo y estructurado
#5 Sí que encuentran gente. Lo que no quieren es pagar por ella.
Os voy contar alguna experiencia que he tenido indirectamente con el COBOL
y la madre que lo parió.El lenguaje en sí, no es complicado. De hecho, como conozcas un poco de ensamblador rústico (nada de CUDA, x64 y similares) enseguida hacer un paralelismo entre el COBOL y el ensamblador. De hecho en COBOL se utiliza MOVE para asignar valores como se hace en ensamblador.
¿Dónde se complica la cosa? Pues en la cantidad de mierdas que utilizan para hacer cosas teniendo en cuenta que antes la memoria y el disco eran carísimos. Si se pueden usar valores de BIT mejor que usar BYTES o enteros. Hace un montón de años nos enfrentamos a sustituir una APP de Telefonica que se dedicaban a las averías (AF se llamaba la jodía) y resulta que la muy hija de puta hacía cien mil cosas más de las que esraba diseñada originalmente debido a que como era una APP que estaba en todas las centrales, era más barato meter funcionalidad en esa APP (aunque no tuviera nada que ver) que desarrollar una nueva (idos 20 años atrás, no penséis con mentalidad de ahora)
Luego añade cosas como que por ejemplo había cosas hechas a mano como un indexado de fichero porque en la época de su desarrollo. no había BD disponibles (hablo de a lo mejor hace 50 años) o eran demasiado caras. O que parte del código estuviera hecho en ensamblador aunque para esto había dos teorías:
- La oficial, se hizo en ensamblador para mejorar las prestaciones.
- La extraoficial. Con el paso de los años hemos perdido los fuentes y hemos tenido de desensamblar a ver qué leches había ahí.
Y no veas la risa que daban las limitaciones que metía el dueño del servidor, cosas como "máximo dos segundos de CPU" ... anda que no nos acordamos del mangante que puso esto cuando tenías que dividir una operación en varios por ese requisito.
Por suerte no me he vuelto a acercar a un chisme de esos, pero sí tengo compañeros que sí lo han hecho para pasar de COBOL .... ¡oh campos de soledad, mustios collados! ¡¡¡ a JAVA !!! (por ahi lo han mencionado también) Parece absurdo pero es que el "conversor" hacía eso.
#15 los programadores y las mierdas que nos encontramos.
Cuando puedes mascar las pocas ganas de trabajar de otro, o el bajo presupuesto, o la falta de tiempo, o los pocos conocimientos, o una combinación de todo ello.
Ha veces te sientes tan sólo delante del teclado,,,,
¿No encontráis a gente para programar en cobol? Pay them more.
Jajajajjaja están los bancos, aseguradoras, IRS y aerolineas (entre otros) que cambian su COBOL por cosas generadas por AI. Ah coñe, espera que es cuñataka.
Mi primer trabajo como programador en COBOL.
Me viene un account manager de mi empresa cárnica y me dice que en una semana empiezo en un cliente nuevo como programador en COBOL.
Le respondo que no tengo ni idea de COBOL y me dice que no es problema, que con lo que sé de mainframe es suficiente y que me estudie un manual de COBOL por las tardes.
Llego al nuevo cliente el lunes y el hijodeputa del Account Manager me presenta al cliente como “ el experto en COBOL del que te había hablado”
#57 hostia ¿era Axpe Consulting?
Al lenguaje de programación COBOL lo quieren jubilar [...] no hay ya muchos profesionales que puedan programar en este lenguaje, así que IBM se ha propuesto tomar otro camino: traducirlo a Java."
JAAAAAAAAAAAA JAJAJAJAJAJAJAJAJAJ DIOOOOOOOOOOOS JJJAJAJAJJAJAJAJAJJAJAJAJAJAJJAJAJAAJJAJAAAAAAAAAAAAAAAAAAAAJAJAJAJJJAJAJAJAJAJJ
https://i.gifer.com/7Djv.gif
#63 Osita QUE LO DICEN EN SERIO
JJJJJAJAJAAAAAAJAJAAJAJAJAAJJJAAJ AJAJAAJAJAJAJAAJAJAJ AAAAAAAAJAJAJJAJAJJAAJJAJAJJAJAJAJAJAJJAJAJAAJJJJJAJAJAAJAJAJAJ
#67 Y encima usando una IA! Esto no para de mejorar.
¿Pero no sabéis que las IAs NO PIENSAN y pueden sacar un cósdigo chulísimo pero que rompa cualquier otra cosa evidente?
Anda, contratad a #64
Probablemente esos programas COBOL se mucho más eficientes que los supuestos programas java que los sustituyeran. Entre otras cosas por la dificultad de debug o por las infinitas dependencias de librerías.
Y eso no solo pasa con el COBOL, en la administración pública española también está muy extendido el Pl-Sql de Oracle que también costaría unas decadas dejar migrado a java o similar
#49 infinitas dependencias....
Tio....
Q no es javascript....
#49 ¿dependencias de qué?
Y PL-SQL migrar a Java, ¿para? PL-SQL y Java pueden coexistir y coexisten
El tema del COBOL no es solo el lenguaje en sí, sino también la máquina en la que se ejecuta: el Mainframe de IBM, con su alta disponibilidad, su gestor transaccional y demás.
Cuando pasen todo a distribuido y se empiecen a caer los tamagotchis se echarán las manos a la cabeza...
#18 Santander UK lleva un año casi con toda la parte corporativa del batch migrada a Oracle y Linux con la solución de Microfocus. Y el plan es mover el resto del batch en 2 o 3 años y quitarse todo el mainframe.
Le queda mucha vida al COBOL
#18 sí, yo creo que en eso está la clave del asunto
Cuando se picaba en cobol muchas cosas no etaban estandarizadas y se hacían ñapas para ahorrar espacio.
Cobol es una maravilla porque depende de la capacidad del programador. Normal que los pisateclas no puedan hacer nada. Y es sólido como una roca.
Java en cambio es una mierda sin paliativos. Todo el mundo descargándose clases y código de repositorios que frikis hacen en su tiempo libre. Y luego esperan que funcione bien. Por no hablar de la cantidad de recursos que necesita y que consume.
#60 sabes bastante poco de java, me parece
Es el ecosistema mas robusto (en todos los sentidos) y, con cosucss como ScummVM te consume basicamente lo q en C...
#89 Yo hablo de desarrollo en grandes clientes como bancos o eci. Para no saber, lo llevo sufriendo en diversos proyectos desde la versión 5.
Y cada dos por tres sale un framework nuevo que hay que usar por cojones, lo que lleva a migraciones que te dejan temblando. ¿ Cuantas aplicaciones web usas en un desarrollo java?
Y robusto mis cojones. A nivel de transacciones no se me ocurre nada más sólido que cobol-cics-db2.
Por aquí tienen un buen listado de cursos que desarrolla IBM https://aprendergratis.es/tag/IBM/
Hay un par de ellos de Cobol, el lenguaje de programación que perdura por mas de 70 añazos
Hace años que se hizo algo parecido (unos 18 años creo recordar) en varias cajas de ahorros y las pruebas no salieron del todo mal. Se pasaron algunas transacciones a Java y eran eficientes y sin fallos.
#26 Qué cabrones los bancos. Probemos la beta en las cajas de ahorros y si falla, las absorbemos. Win-Win
#71 Cabrones los bancos? a estas cajas de ahorro ningún banco les dijo que probaran...
Miedo me da que se fien de una traducción automática de Cobol a Java. Ahora tendrán que buscar personas que sepan Cobol y Java para verificar que lo que sale de la churrera de AI es correcto. Otra cagada más de IBM que en España se están luciendo con el cambio de sede, el hacer su Sintel para mandar a la gente que más les ha currado al paro, pero en diferido eso si, para que se note poco... hasta que haya otra crisis más en el sector, y entonces ya se irá al carajo otra empresa
Desde que apoyaron al holocausto vendiendo sus máquinas de censo, luego su consultoría a Huawei, sus PCs a Lenovo, etc etc estos no dan pie con bola.
Titular erróneo: COBOL siempre ha sido un dolor de cabeza.
#13 No lo se... lo que yo he visto ( y no soy programador) es que el dolor de cabeza ha sido tratar de deshacerse del Cobol... que no es lo mismo
Cuando entré en la carrera me decían que COBOL era un muerto que gozaba de muy buena salud.
Lo llevan enterrando desde antes de los años noventa y ahí sigue.
Si entras hoy en la carrera, no sé si me especializaría en cobol, porque los sueldos que deben pagar deben ser bastante jugosos
#100 Son un mojón.
Fuente: llevo trabajando en cobol desde 2006
CC #64
Yo hice un curso para programar en PL/1 donde tambien dimos algo de COBOL. Me pareció muy farragoso. EL PL/1, en cambio, me encantó. Dos años estuve programando para La Caixa. Mi hermana aun sigue allí despues de 25 años.
#24 Habrás visto que un programa en COBOL es directamente escribible en PL/1 línea por línea, sin adaptar nada.
#59 Es lo que recuerdo. PAra mi el COBOL era hacer lo mismo pero escribiendo mucho mas.
#74 Es que depende de lo que hagas, en mi caso agarraba cualquier programa , me iba a la procedure division , cambiaba un par de lineas y ya tenia algo diferente... demoraba menos de 5 minutos incluida la compilacion .... nunca puede hacer algo asi con otros lenguajes..
jaja. jajajaja. JAJAJAJAJAJAJAAJA.
NO
Que puede salir mal. Sin manos! (Escena de precuela de alien que prefiero no nombrar)
Utilizar una IA que traduce código... Luego habría que poner a alguien a revisarlo, o se va a subir a producción algo que ha migrado una IA? Van a integrar las pruebas? Esta integración la hace la IA y se hace trampas al solitario? No se, no creo que algo así funcione.
Y la migración a mano conocida de toda la vida... Creo que alguno ya lo ha comentado, el problema no es cobol. Los problemas son básicamente 2.
El primero, que la mayoría de código en cobol, no está hecho por ingenieros informáticos, sino por economistas reconvertidos, lo cual hace que el código, en el mejor de los casos, sea difícilmente entendíble.
El segundo es que las empresas han estado lastrando la migración durante años, porque nunca quieren asumir costes en tiempo o económicos, y cuanto más se alarga, más costosa es.
Por terminar, hablo por mi y otros compañeros que conozco: A nadie le gusta ni los proyectos de migracion, ni coger proyectos mal hechos de hace mucho tiempo por gente que no sabía del tema lo que debiera.
#87 Seguro que IBM tiene invertido mucha pasta en esa solución... Pero - y solo a modo ilustrativo - quiero recomendar la entrada que hace chema alonso sobre el tema (https://www.elladodelmal.com/2023/08/si-eres-developer-y-buscas-soluciones.html)
Aunque ciertamente los porcentajes podrían ser achacables a que es "gratuíta", me bastaría suponer un 10% de tasa de error en la traducción para tener confianza 0 en lo realizado por la IA... tal y como comentas.
Soy programador, me interesa aprender COBOL y vivir de las rentas? Si hay pocos estarán demandados, digo yo...
#64 Es superapasionante.
Mi grupo de homenaje al punk setentetero se llamará PROCEDURE DIVISION
https://imgflip.com/i/7wonnd
#64 no, tienes un mercado muy limitado y es mentira que no haya gente programando en cobol, hay miles de de españoles trabajando en mainframe
#64 https://i.imgflip.com/7ws4h6.jpg
Bienaventurado el que crea que puede resolver un problema de programación con IA por qué pronto tendrá 2 problemas.
Vamos, que en vez de aprender el lenguaje de moda, mejor aprender COBOL.
¿Estoy en lo correcto?
El problema no es el cobol, es la barbaridad de dinero que cobra ibm por el uso y mantenimiento del mainframe.
Eres cautivo y a pagar y pagar..
#90 Dinero que pasará de IBM a Amazon, Google o similares con las nubes. Je je je
Tampoco lo van a arreglar mucho traduciendolo a Java. Peor si hubieran pensado en Javascript.
Vendiendo humo.
Estoy bastante seguro de que a una IA tipo ChatGPT le pasas fragmentos de COBOL y ya te los traduce a Java bastante bien.
El problema es cómo conviertes ese código en algo que tenga las características de un software moderno en cuanto a escalabilidad, etc ... Y a la vez mantienes la fiabilidad de algo que se ha ejecutado millones de veces y está más testeado que el cagar sentado.
Como siempre, llegará el consultor de turno, se llevará su pasta y el trabajo lo terminarán los becarios haciendo guardias 24/7 pagadas con caramelos y pizzas.
Cambian los tiempos, pero el hombre no cambiará jamás
JAVA.....???.Rápido, sacad el dinero de ahí y meterlo bajo el colchon