Portada
mis comunidades
otras secciones
#19:
#1 Cada vez que escucho: "No encontramos (ponga aquí el profesional que desee)" o "Casi no hay (ponga aquí profesional que desee)". Lo que quieren decir en realidad es: "No encontramos (profesional mencionado) que quiera aceptar salarios de miseria" o "Casi no hay (profesional mencionado) que quiera trabajar en condiciones deplorables sin quejarse".
Esa es la realidad.
#14 lo relata estupendamente.
Pay them more.
#FreeAssange
Esa es la realidad.
#14 lo relata estupendamente.
Pay them more.
#FreeAssange
#1:
Que paguen bien y verán como cualquier desarrollador con experiencia se apunta y se pone al día con la sintaxis de Cobol en muy poco tiempo.
#17:
#1 cualquiera que tenga más de 50 años seguro que ha pasado un tiempo trabajando en Cobol.
Ya no me acuerdo mucho, la verdad, pero estuve unos 8 años trabajando en Cobol para una aseguradora, no creo que me costase mucho volver a cogerle el tranquillo.
Pero era aburrido de narices, así que, si me quieren, solo es cuestión de poner pasta sobre la mesa.
Ya no me acuerdo mucho, la verdad, pero estuve unos 8 años trabajando en Cobol para una aseguradora, no creo que me costase mucho volver a cogerle el tranquillo.
Pero era aburrido de narices, así que, si me quieren, solo es cuestión de poner pasta sobre la mesa.
#21:
#1 #11 Y mas un lenguaje como COBOL donde el resto del ecosistema es muy diferente. IBM z/OS, VSAM, CICS Transaction Server for z/OS, JCL, ISPF, ..... y un monton de mierdas mas que casi no se usan y casi nadie sabe.
Yo en su dia sabia bastante ... dios me guarde de volver a usar nada de eso antes de retirarme.
Yo en su dia sabia bastante ... dios me guarde de volver a usar nada de eso antes de retirarme.
#14:
A mí si me sueltan 10K/mes y me dejan trabajar desde algún puebloh barato de la España Vaciada, me pongo a estudiar cobol como un loco.
Por lo demás, si cobol, c, unix, etc. siguen en el candelero desde hace décadas, seguro que ya es difícil encontrar algo mejor, por mucho empeño que pongan.
Por lo demás, si cobol, c, unix, etc. siguen en el candelero desde hace décadas, seguro que ya es difícil encontrar algo mejor, por mucho empeño que pongan.
#34:
#11 Por eso he hablado de un desarrollador con experiencia. Alguien que lleva años en el mundillo del desarrollo se aprende la sintaxis en una tarde, y sabe perfectamente que eso es lo de menos y como tu bien dices toca estudiar y documentarse.
El problema que tienen los de RRHH cuando buscan a alguien para este puesto es que piensan que o importante es encontrar a alguien que lleve años en ese lenguaje concreto cuando lo que realmente importa es saber de estructuras, arquitecturas y entornos.
El problema que tienen los de RRHH cuando buscan a alguien para este puesto es que piensan que o importante es encontrar a alguien que lleve años en ese lenguaje concreto cuando lo que realmente importa es saber de estructuras, arquitecturas y entornos.
#18:
Creo que el problema no es solo el Cobol, es el sistema ALREDEDOR del Cobol.
Un IBM 3090 está pensado para leer de muchas fuentes de datos a la vez y procesarlas mientras las leen, un ordenador de sobremesa actual tiene muchisima más potencia… pero no está pensado para trabajar de esta forma, por lo que se deben cambiar todos los procedimientos y la forma de trabajar con los datos, y eso es lo complicado de la migración.
Tratar de conseguir exactamente los mismos resultados a nivel de centimos haciendo cosas muy, pero que muy, distintas, no es nada fácil.
Un IBM 3090 está pensado para leer de muchas fuentes de datos a la vez y procesarlas mientras las leen, un ordenador de sobremesa actual tiene muchisima más potencia… pero no está pensado para trabajar de esta forma, por lo que se deben cambiar todos los procedimientos y la forma de trabajar con los datos, y eso es lo complicado de la migración.
Tratar de conseguir exactamente los mismos resultados a nivel de centimos haciendo cosas muy, pero que muy, distintas, no es nada fácil.
#52:
#19 No, en el caso de COBOL no se trata de "pay them more".
Se trata de que es un nicho laboral: los clientes son grandes empresas que tienen su IT, incluyendo desarrollo, externalizado a grandes consultoras.
Tu crecimiento laboral está limitado a pasar de NTT Data a Sopra, de Sopra a Accenture, de Accenture a Tata, etc. Vas cambiando de cliente y ganando más dinero pero mucha gente, irónicamente*, tiene una sensación de inseguridad, de que el mainframe va a morir mañana y se van a quedar en la calle porque aunque son clientes y consultoras grandes, son pocas consultoras. Por ese motivo, un alto porcentaje de la gente que se inició el COBOL con las becas que comento en #51 se pasan a otra tecnología (.NET, frontend, Go, Kubernetes, AWS/Azure, etc) al cabo de 5 años más o menos.
* Digo "irónicamente" porque personalmente considero que antes morirá Kubernetes que el mainframe.
Se trata de que es un nicho laboral: los clientes son grandes empresas que tienen su IT, incluyendo desarrollo, externalizado a grandes consultoras.
Tu crecimiento laboral está limitado a pasar de NTT Data a Sopra, de Sopra a Accenture, de Accenture a Tata, etc. Vas cambiando de cliente y ganando más dinero pero mucha gente, irónicamente*, tiene una sensación de inseguridad, de que el mainframe va a morir mañana y se van a quedar en la calle porque aunque son clientes y consultoras grandes, son pocas consultoras. Por ese motivo, un alto porcentaje de la gente que se inició el COBOL con las becas que comento en #51 se pasan a otra tecnología (.NET, frontend, Go, Kubernetes, AWS/Azure, etc) al cabo de 5 años más o menos.
* Digo "irónicamente" porque personalmente considero que antes morirá Kubernetes que el mainframe.
#10:
El problema no es migrarlo, lo que dice el artículo ya había empresas que lo ofrecían antes, solo que ahora se ha añadido lo de IA. Ni siquiera que tenga que ser revisado y ajustado posteriormente por programadores. El principal problema es asegurar que el código nuevo hace exactamente lo mismo que el código en COBOL y ahí, teniendo en cuenta que se usa en empresas que mueven mucho dinero como bancos y aseguradoras, ya no es tan fácil que haya alguien que se moje y certifique que funciona igual porque como dicen nadie sabe exactamente todo lo que hacen, y eso incluye a la gente de negocio no solo a los desarrolladores.
#4:
¿Os acordáis cuando dijeron que iban a sustituir a trabajadores por IAs si no volvían al trabajo en la oficina?
#3:
Entre la DATA DiVISION y la CONFIGURATION SECTION ... pues algunos PIC 999
Comentarios
Que paguen bien y verán como cualquier desarrollador con experiencia se apunta y se pone al día con la sintaxis de Cobol en muy poco tiempo.
#1 Cada vez que escucho: "No encontramos (ponga aquí el profesional que desee)" o "Casi no hay (ponga aquí profesional que desee)". Lo que quieren decir en realidad es: "No encontramos (profesional mencionado) que quiera aceptar salarios de miseria" o "Casi no hay (profesional mencionado) que quiera trabajar en condiciones deplorables sin quejarse".
Esa es la realidad.
#14 lo relata estupendamente.
Pay them more.
#FreeAssange
#1 cualquiera que tenga más de 50 años seguro que ha pasado un tiempo trabajando en Cobol.
Ya no me acuerdo mucho, la verdad, pero estuve unos 8 años trabajando en Cobol para una aseguradora, no creo que me costase mucho volver a cogerle el tranquillo.
Pero era aburrido de narices, así que, si me quieren, solo es cuestión de poner pasta sobre la mesa.
A mí si me sueltan 10K/mes y me dejan trabajar desde algún puebloh barato de la España Vaciada, me pongo a estudiar cobol como un loco.
Por lo demás, si cobol, c, unix, etc. siguen en el candelero desde hace décadas, seguro que ya es difícil encontrar algo mejor, por mucho empeño que pongan.
seaCOBOL mundo
#1 #11 Y mas un lenguaje como COBOL donde el resto del ecosistema es muy diferente. IBM z/OS, VSAM, CICS Transaction Server for z/OS, JCL, ISPF, ..... y un monton de mierdas mas que casi no se usan y casi nadie sabe.
Yo en su dia sabia bastante ... dios me guarde de volver a usar nada de eso antes de retirarme.
Creo que el problema no es solo el Cobol, es el sistema ALREDEDOR del Cobol.
Un IBM 3090 está pensado para leer de muchas fuentes de datos a la vez y procesarlas mientras las leen, un ordenador de sobremesa actual tiene muchisima más potencia… pero no está pensado para trabajar de esta forma, por lo que se deben cambiar todos los procedimientos y la forma de trabajar con los datos, y eso es lo complicado de la migración.
Tratar de conseguir exactamente los mismos resultados a nivel de centimos haciendo cosas muy, pero que muy, distintas, no es nada fácil.
#11 Por eso he hablado de un desarrollador con experiencia. Alguien que lleva años en el mundillo del desarrollo se aprende la sintaxis en una tarde, y sabe perfectamente que eso es lo de menos y como tu bien dices toca estudiar y documentarse.
El problema que tienen los de RRHH cuando buscan a alguien para este puesto es que piensan que o importante es encontrar a alguien que lleve años en ese lenguaje concreto cuando lo que realmente importa es saber de estructuras, arquitecturas y entornos.
#1 Aprender un lenguaje para trabajar no es conocer la sintaxis básica, sino las herramientas más usadas, los problemas habituales,... y en caso como estos, los entornos donde se usan.
¿Os acordáis cuando dijeron que iban a sustituir a trabajadores por IAs si no volvían al trabajo en la oficina?
El problema no es migrarlo, lo que dice el artículo ya había empresas que lo ofrecían antes, solo que ahora se ha añadido lo de IA. Ni siquiera que tenga que ser revisado y ajustado posteriormente por programadores. El principal problema es asegurar que el código nuevo hace exactamente lo mismo que el código en COBOL y ahí, teniendo en cuenta que se usa en empresas que mueven mucho dinero como bancos y aseguradoras, ya no es tan fácil que haya alguien que se moje y certifique que funciona igual porque como dicen nadie sabe exactamente todo lo que hacen, y eso incluye a la gente de negocio no solo a los desarrolladores.
#19 No, en el caso de COBOL no se trata de "pay them more".
Se trata de que es un nicho laboral: los clientes son grandes empresas que tienen su IT, incluyendo desarrollo, externalizado a grandes consultoras.
Tu crecimiento laboral está limitado a pasar de NTT Data a Sopra, de Sopra a Accenture, de Accenture a Tata, etc. Vas cambiando de cliente y ganando más dinero pero mucha gente, irónicamente*, tiene una sensación de inseguridad, de que el mainframe va a morir mañana y se van a quedar en la calle porque aunque son clientes y consultoras grandes, son pocas consultoras. Por ese motivo, un alto porcentaje de la gente que se inició el COBOL con las becas que comento en #51 se pasan a otra tecnología (.NET, frontend, Go, Kubernetes, AWS/Azure, etc) al cabo de 5 años más o menos.
* Digo "irónicamente" porque personalmente considero que antes morirá Kubernetes que el mainframe.
Entre la DATA DiVISION y la CONFIGURATION SECTION ... pues algunos PIC 999
#10 la IA reservando unos céntimos en cada transacción para construir skynet
#7 una mierda. Pon pasta sobre la mesa y ya verás la de cracks que aparecen. Pero de los buenos buenos.
Yo mismo dejé el cobol por .Net por la poca proyección (poca oferta y mal pagada)
#7 Ademas te tienes que comer una fase de testeo sin gente que entienda ni el codigo ni lo requisitos de negocio ... prefiero hacer malabares con motosierras, es mas seguro.
#34 "Alguien que lleva años en el mundillo del desarrollo se aprende la sintaxis en una tarde"
Para aprender mainframe tus dos o tres semanas le echarás, pero bueno, se aprende relativamente rápido.
"El problema que tienen los de RRHH cuando buscan a alguien para este puesto es que piensan que o importante es encontrar a alguien que lleve años en ese lenguaje concreto"
Meeec, COBOL no es así. La tendencia es a dar "becas" de un mes o mes y medio a gente que muchos de ellos ni son informáticos ni nada, te encuentras hasta algún periodista, y cuando acaban van directos a la cárnica a trabajar para Accenture, Everis o Indra, con subcontrata de por medio (o sea, dos niveles de "intermediarios" por delante del cliente) y cobrando el sueldo mínimo.
Por eso mismo dicen que no encuentran, porque los informáticos normales o no van a eso o si van trabajan un tiempo y cuando pueden se van rápido de ahí, van ahí como el que curra en el McDonalds un verano.
A los "viejos" de COBOL que sí ganaban su buen dinero los fueron jubilando mientras contrataban a becarios para ir ahorrando costes.
El problema no es COBOL, es un lenguaje sencillo pensado para que cualquiera pudiera programarlo. La mayoría de lenguajes
actuales le da mil vuelas en complejidad y tienen curvas de aprendizaje mucho más empinadas.
El problema es que llevan funcionando muchos años y nadie sabe al 100% funcionalmente cómo lo hacen.
Es decir, que puedes aprender todos los secretos de COBOL en un par de semanas, pero luego a ver quién es el guapo que le mete mano a un sistema de seguridad social de un departamento de EE.UU que lleva funcionando desde hace más de 40 años.
#21 Y además no creo que haya muchos emuladores de estas plataformas. Yo trabajé bastante tiempo con DB2 sobre OS/390 y no creo que haya ningún sitio para aprender esto, ni CICS, ni muchas otras cosas del viejo mundo mainframe.
#4 Yo recuerdo el meneo este que salió por aquí, lo que no dice lo de volver a la oficina: IBM pausará contrataciones en un plan para sustituir 7.800 puestos de trabajo por IA
IBM pausará contrataciones en un plan para sustitu...
es.investing.comYo he trabajado desarrollando en Cobol. Ya en su día la media de edad de mis compañeros era muy alta y hace diez años.
#21 #62 El viejo entorno mainframe... estaba chulo, tenía sus cosas con ese toque retro.
Espero no volver a tocarlo ni aunque la humanidad esté al borde de la extinción y su única posibilidad de supervivencia sea utilizar COBOL.
Pero estaba chulo, con sus JCL y sus rutinas de miles de líneas muchas de ellas copypaste de otras a la que habían cambiado una línea o un parámetro.
Si funciona, no lo toques.
Hace tiempo vi una oferta de Infojobs (sí, de una empresa lider en el sector) donde buscaban gente programar en Cobol y si no sabías te formaban. Creo que había cerca de 1000 personas inscritas.
#21 que casi no se usan?. Echa un ojo:
https://www.precisely.com/blog/mainframe/9-mainframe-statistics
https://planetmainframe.com/2022/12/relevance-of-mainframe/
El Mainframe todavía controla el mundo!
#18 Que un ordenador de sobremesa actual tiene más potencia que un mainframe... solo indica tu nivel de desconocimiento, sorry pero es la realidad, aunque como chiste es bueno eh.
Estas hablando de sistemas con varios procesadores ubicados en sus propias tarjetas funcionando en paralelo con un sistema operativo capaz de soportar cambios en caliente, cientos de personas trabajando, y aceptación de millones de datos en tiempo real, y soportar todo eso la vez, además, resistente a cualquier avería y capaz de seguir funcionando mientras se arregla insitu sin desconectar nada.... y garantizado el funcionamento el 365 días al año.
#21 Tecnología dinosauria esperando que caiga un meteorito.
#c-61" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3887127/order/61">#61 el lenguaje no es el problema siempre que lo conozcas.
Un código que es a vez c# y python no sé ni como llamarlo.
#17 Yo trabajé dos años con el como mucho, es insufrible pero si hay pasta lo retomo también.
#18 ¿3090? Me parece que hace más de 40 años que no estás cerca de un mainframe. La serie 30xx es del año la polca. El 3090 ya estaba en producción en la década de los '80 (me tocó estrenar alguno). El sucesor, la familia Z, ahora ya va por la generación z16, con z/OS, o z/VM o hasta Linux... He migrado varias cargas desde Z a distribuidos. Alguna con cobol. La mayoría de las veces con resultados bastante nefastos. En la práctica fueron más caros de mantener, de explotar y con muchas más incidencias, que el original en mainframe. Pero, sí; coincido con lo último que dices, IMHO no es que se no se puede hacer desaparecer al COBOL; es que, para determinadas cargas, sigue sin haber algo mejor...
#3 Ya tiré yo algunos procedures division y perform en mi vida.........durante el siglo pasado
#38 Conozco varios casos de directores de IT y CIOs que prometieron que cuando ellos mandaran, se iban a cargar el mainframe, que eso era una cosa antigua... y nada más lejos de la realidad: cuando vieron la fiabilidad, rendimiento y eficiencia del mainframe, han doblado su apuesta por él. La redundancia del mainframe les da tranquiliadad absoluta, y el alto rendimiento por la cercanía entre computación y datos lo hace muy eficiente.
Tengo clientes que han migrado de Kubernetes en x86-64 a Kubernetes en mainframe (!). Obviamente, hablo de clientes grandes, esto no es para Bar Paco ni para Talleres Juan.
#1 1+1 no es dos en este caso. El problema es que son programas que apenas han necesitado mejoras, estáticos y ahora ya no hay quien los modernice
#1 realmente por cobol ya pagan bién... Pero el problema realmente no es cobol (aunque parezca asm lo veo más tipo Basic) si no entender lo que hay programado pero de lo que no tenemos documentación y sibre todo entender la mentalidad de l aque salian las chapuzas, como salen ahora... Sigo encontrandome ifs del estilo "if (true) {" porque les da pereza eliminar los elses.....
#85 pyc#hón
#17 #20 Los de cuarenta tambien hemos trabajado en COBOL ... pero yo paso, soy generoso y dejo esta ocasion toda para vosotros ...
#17 tu lo has dicho. Cada vez que leo estás noticias para mí como leer el No se encuentran camareros.
#17 Lo mismo digo, hace siglos programé en Cobol/400.
Veamos la pasta y hablamos.
#66 Lo de usar un lenguaje de los 50 no lo superas nunca.
#32 Pero eso es porque seguro que eres un perroflauta que ni siquiera hicistes la mili ... COBOL te hace un hombre
#1 #17 #20 #25 400€/hora
Esa es la oferta en Freelance.com
#52 Lo de externalizar ahora se esta viendo que fue una idea "genial".
Gente que conocía el negocio a fondo, a tomar por culo y le damos la informática a una
cárnica de mierdaconsultora externa, que ya sabemos como trabajan.Pues ahora no cuentan con gente que conozca a fondo del negocio ni el COBOL.
QUE SE JO DAN.
#63 te entiendo perfectamente. Ojo, solucionan un problema y lo solucionan muy bien. El caso es que probablemente no solucionan nuestro problema, sino el de Google, Meta, Amazon... pero como están de moda se aplican donde no toca.
No necesitas Kubernetes para una aplicación monolítica de intranet con 1000 usuarios diarios (ni 10000, ni 100000...) Tampoco necesitas una arquitectura de microservicios.
#9 Vendo Ciro de la Fuente.
#47 no como ahora, que cualquier Framework te hace una carpeta de proyecto que ocupa 100 megas para poner Hola Mundo en una pantalla
#12 Pues no...
https://www.casadellibro.com/libro-curso-de-programacion-rm-cobol-85/9788478970704/37743
185€ ahora de segunda mano!! Con que alegría lo tiré a la basura!! jajaja
#10 En un importante banco Español (y mundial) se intento inventariar todo el software y fue imposible. Habia un 40% que nadie sabia exactamente que hacia pero que pertenecia al core del banco.
#5 me estás robando el upvote a punto de pistola
#38 Yo llegue a trabajar con los 4381 mira si soy viejuno, ahora z/16 en z/OS
#38 un banco no es nada especial. Claro que hay cosas mejores que cobol, otra cosa es que a la vez que cobol tengas que cambiar 7 cosas más.
El lenguaje rara vez es el problema.
#43 he trabajado en un banco español y ahora en una faang. Créeme, un banco no es nada especial.
#17 Se me pone ácido el estómago solo de pensarlo....
El antiàcido es caro
#3 ¡Ay, COBOL! ¡Qué recuerdos! Después de 200 líneas de código aún no has empezado el algoritmo para hacer un programa básico.
#24 pero encendidas?? Eléctricas o a gasolina?
Pues aquí alguien que sigue desarrollando en COBOL, y a mucha honra.
Desarrollo en un ERP de RRHH para empresas grandes (>5000 empleados). Nada he visto más rápido para gestionar un proceso batch grande y complejo como un cálculo de nómina. Llevo unos 7000 empleados en esa aplicación, y una nómina completa tarda unos 10 minutos (contando que más de la mitad del tiempo se lo come la base de datos con inserts y deletes)
La empresa editora nos ha dicho que quieren ir quitando COBOL como el core de la aplicación (porque nadie quiere desarrollar en ese lenguaje) pero ya asumen que de lo último (2030) que van a plantearse quitarlo es el batch de la nómina porque no encuentran nada tan rápido y eficiente
En definitiva, llevo 15 años oyendo que COBOL está muerto, y lo cierto es que antes acariciaré yo el trigo
#7 Es que habría que migrarlos, no "modernizarlos".
Simple cuestión de pasta
#14 Tengo un conocido que trabaja con mainframes y COBOL para banca en la City. Gana mucha pasta y no tiene hijos (sí homo), así que cada 3-4 años se pilla 6-12 meses sabáticos. Lleva 25 años así.
#36
Y lo de progamar todo sin estructuras de datos.
https://en.wikipedia.org/wiki/Jackson_structured_programming
Ironicamente esto de lo que se avisaba en 1975 lo estoy viendo en programas en python, que a la penya el gusta aplanar estructuras de datos. y pasar todos los parametros en un array. Verdadera POO Programacion orientada al ojete.
Basicamente yo me dedico a pasar programas de python a c# cuando el programador de python que creo el programa se va de la empresa y los developers de python que vienen despues no son capaces de mantenerlo.
#18 Doy fe
#c-39" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3887127/order/39">#39 Lo de que el lenguaje no el el problema no es cierto.Te puedo presentar un codigo que vale para python y c# y funciona de forma totalmente diferente ya que python intenta forzar que tenga sentido y en ese caso lo consideraba booleano.
El python que me suelen pasar a migrar a c#, despues de que sucesivos developers python que no fueron el orginal huyan de ese projecto es una mierda. En un lenguaje fuertemente typado es mas dificil hacer mierdas.
#52 Personalmente, y como viejuno que soy, le he cogido manía a las moderneces como Kubernetes, Terraform, Ansible, etc. Me parecen una mierdaza fuera de control.
#45 En efecto. Y con ampliación y reducción de recursos en caliente cuando no había virtualización siquiera.
#106 Estamos de acuerdo que C es el lenguaje de los machotes. Pero también que es infinitamente más difícil de mantener y que además acarrea graves problemas de seguridad de memoria (de ahí el auge de Rust). Python es todo lo contrario y a veces es una opción muchísimo más óptima (en términos empresariales).
Cada lenguaje tiene su ámbito y son muchas las variables en juego. Un buen arquitecto debe saber elegir la tecnología más adecuada para cada proyecto. No se puede usar un martillo para todo.
#62 Hercules MVS, gratuito, compiladores de Cobol y RPG, si quieres al más moderno, IBM tiene un emulador de z/OS la licencia se vende, creo que hay una edición de estudiantes, y si no, patapalo. Yo tengo instalado los dos emuladores.
#39 Un banco sí es algo especial. Para empezar, están sujetos a leyes muy particulares en cuanto a qué deben hacer en sus sistemas. Pero eso es lo de menos. Siempre tienes que cambiar 7 cosas más... Si quitas una carga COBOL de un mainframe, que lleva años funcionando perfectamente, es para bajarla a distribuidos porque pretendes reducir costes... y de poco te sirve bajar el aplicativo y dejarte arriba el IMS, el CICS o el DB2 para atacarlo por TCP/IP (con todos los MIPS de más que se llevan esos procesos de red == $$$$$). Al final, lo normal es que acabes con 20 máquinas Unix dándose backup unas a otras en las que las actualizaciones son auténticas pesadillas y, dónde antes tenías a 4 Ingenieros de Sistemas muy bien pagados, ahora tienes a 10 seniors, 20 juniors y un contrato AM de mantenimiento de software drenándote la cartera...
#55 un programador con experiencia, eso que dices lo tiene superado en 10 días. Y en ese tiempo incluyo aprender la sintaxis.
#122 Un 4341 aquí 😥
#36 yo he visto returns en mitad de una función. Y por debajo un centenar de líneas de código que no sabes si las dejaron por si acaso, o por pereza
#28 si estan encendidas y tienen dientes en la cadena …
#19 Ni siquiera necesitan pagar especialmente bien. Simplemente hacer una inversión y montar un equipo del tamaño que sea necesario y vaya migrando lo que hay, poniendo ese sistema en producción y haciendo espejo de todo lo que le pase al sistema principal. Hay varios casos de éxito por ahí de proyectos de este tipo.
El COBOL no es un lenguaje arcano. Es un coñazo, tiene sus trucos y demás. Pero no es el problema que te vas a encontrar cuando migres todo. De hecho estoy razonablemente seguro de que ChatGPT4 te puede generar código equivalente en Java de forma bastante acertada.
El problema es ese "bastante". Habrá ciertos corner cases en los que nadie habrá pensado y los requerimientos para el sistema llevarán décadas perdidos, por lo que tendrán que descubrirlos en el propio código "(¿Por qué a las cuentas bancarias que terminan en 4 se les aplican los intereses el día 2 en vez del 1?)". Eso requerirá de un equipo de desarrollo interno que conozca el negocio y que vayan documentando las cosas. Todavía hay una cantidad sorprendente de empresas que externalizan el 95% de su área de IT porque ellos "no se dedican a la informática" sin darse cuenta de que esa parte de IT es su negocio.
#42: Eso es lo que debería resumir la noticia.
"...es que así es más moderno y blablabla" ---> Palabrería de Power Point, no hacer caso.
#7 si funciona, no se toca
COBOL es un lenguaje diseñado para ser accesible a personas sin transfondo técnico. Que la gente no sepa COBOL nunca ha sido un problema. La pasta tampoco está en saber programar, está en el mantenimiento: depurar una cadena de llamadas entre decenas de módulos, optimizar procesos batch o la latencia online, etc. Y para esto hace falta saber de muchas cosas más que COBOL.
#3 Oye, llama a IBM a ver...
#47 Esas se copiaban de otro siempre, los había que ni cambiaban el AUTHOR,
#1 Exacto. Yo lo tengo oxidado, pero no me llevaría más de un mes ponerme al día
#63 Las has usado?
Por cierto que algo esté fuera de control o no no es responsabilidad de la tecnología
#58 Es que Python es "tan fàcil...".
#47 Eso se automatiza en C
#83 Sacto. Ahora "hace falta" un framework hasta para eso
#26 COBOL no supone "una manera de pensar diferente".
Cansinos. No podía cerrar el año sin que algún medio xataquero dijera una vez más lo de que no hay programadores de Cobol
Por cierto, amigos de webedia, les falta la noticia de "las ips están a punto de acabarse!!!1111oneone"
#33 Pues ese es el tema, que obvian todos estos pastiches de copia pega. El problema no es aprender Cobol, que lo aprende hasta un mono porque son 4 instrucciones contadas. El problema es conocer del negocio, las aplicaciones que están sobre Cobol, las estructuras de datos, cual es el flujo del dinero y por dónde va. Y eso no se aprende en 4 días, sino que se sabe cuando uno lleva en la empresa un porrón de años y se conoce todos los procesos y workflows. Pero eso no te lo va a contar ningún medio Xataka, claro, ellos ya están para otra cosa.
#26 Es sensacionalista como una casa y un clickbait de libro. Pero claro, la sacan cada 2x3 porque saben que alguien va a picar y porque no falta quien menee estas cosas. Van a tiro hecho.
#64 Tienes razón en su bajo rendimiento pero respecto al mantenimiento discrepo profundamente. ¡Todo lo contrario!
Python aunque es de tipado dinámico también es de tipado fuerte. Y es, sin lugar a dudas, el lenguaje más minimalista y legible de todos.
Por lo general, Python hace en 5 líneas lo que otros hacen en 10. Y está enfocado para no dar rienda suelta a la imaginación en las implementaciones. En Python las cosas solo se hacen de una manera (o al menos esa es la idea zen). Además obliga a intentar correctamente. ¿Qué más quieres?
#1 Correcto, yo lo abandone hace ya 4 años y salvo una subida acojonante de pasta no vuelvo a ese infernal entorno de desarrollo + el infernal trabajo para bancos.
#10 Recuerdo en un extinto banco Andorrano con relaciones por Madrid... que existía un programa básico que ya no tenían el código fuente.
#1 Venga, va el chiste sobre cóbol:
Fue introducido en su cámara criogénica, los técnicos ajustaron la fecha en la que despertaría, le administraron inyecciones para ralentizar su pulso al mínimo, y ya está. Lo siguiente que vio Jack fue una enorme y moderna habitación llena de gente excitadísima. Todos gritaban "¡No me lo puedo creer!", "¡Es un milagro!", "¡Está vivo!". Había cámaras (que no se parecían a ninguna que hubiese visto antes) y equipamiento que parecía sacado de una película de ciencia ficción.
Alguien que obviamente era un portavoz del grupo se adelantó. Jack no podía contener su entusiasmo. "¿Ya está?" preguntó. "¿Ya ha llegado el 2000? ¿Se han terminado todas las fiestas de cambio de milenio y todas las crisis?". El portavoz le explicó que había habido un problema con la programación del temporizador de la cámara criogénica de Jack y no había sido preparada para el año 2000. En realidad, habían pasado 8000 años, pero el portavoz le dijo a Jack que no debía enfadarse. Alguien MUY importante quería hablar con él en ese mismo momento. De repente, una pantalla del tamaño de una pared mostró la imagen de un hombre que se parecía mucho a Bill Gates. Era el Primer Ministro de la Tierra. Le dijo a Jack que no se enfadara, que ésta era una época magnífica para vivir. Había paz mundial y no había hambre; el programa espacial había continuado y ya existían colonias en la Luna y en Marte; la tecnología había avanzado hasta tal punto que todo el mundo tenía interfaces de realidad virtual que les permitían ponerse en contacto con cualquier otra persona en el planeta, o ver cualquier espectáculo, o escuchar música grabada en cualquier lugar. "Eso suena maravilloso," dijo Jack, "pero ¿por qué está todo el mundo tan interesado en mí?" "Bueno", dijo el Primer Ministro, "el año 10000 está a la vuelta de la esquina, y en tu currículum dice que sabes COBOL ...".
Sin C no existiría OBOL, Pasal ni Basi
#25 Yo tengo 45 tampoco me pongas más años que estos ya pesan
#26 Hace 20 años Coritel (de Accenture, ahora no sé cómo se llama) estaba formando programadores de COBOL en plan churrería. Un curso de un mes y a funcionar. El 90% caían rápido, eso sí.
#58 Python es el nuevo Basic. Lento y sin estructura, fácil de aprender, horrible de mantener.
#45 er... que un IBM 3090, he dicho.
#38 Te puedo asegurar que en los 90 (cuando me dedicaba al Cobol) trabajabamos con IBM 3090... del que incluso tuve que tocar el código máquina para un proyecto.
#29 En mi época era al contrario... si querías cobrar pasta debías salir del Cobol.
#80 Python es una calculadora programable muy potente (véase todo el uso en ML y demás) o un lenguaje de scripting moderno (es decir, alternativa a Bash scripting).
Usarlo para cualquier otra cosa es un tiro en el pie.
#80 Estoy de acuerdo con usted, es sólo que no me gusta esa forma de programar. No pretendo tener razón, pero cuando yo aprendí a programar algo (no mucho) lo que se usaba era C cuando uno quería "programar de verdad". Y es cierto que C es un infierno porque uno tiene que encargarse de casi todo, pero luego es tan rápido y eficiente que para mí compensa. En términos de coches Python es un cómodo Hyundai SUV automático, y C es un Ferrari GTO con la suspensión dura.
#93 Ya le digo que soy viejuno y sí, he usado algo de Kubernetes y Terraform. Soy de la vieja guardia y la filosofía de Terraform por ejemplo no me gusta, puede que sean manías mías, pero me he topado a veces con una sintaxis farragosa e ilógica que parecía parida con prisas en lugar de mantener una estructura intuitiva.
En otro orden de cosas, tampoco me gusta DevOps. Me parece un engendro mezclar desarrollo e infraestructura. Para proyectos pequeños está muy bien, pero en organizaciones grandes es un caos.
#52 #63 Estoy yo ahora hasta la cintura de mierda de K8S, Terraform... y no paro de pensar ¿qué vendrá después? ¿Viviré para verlo? al ritmo que va la informática supongo que si, espero no me toque la migración a la siguente moda.
#80 perdona, pero Python no tiene tipado fuerte, tiene duck typing.
Lo que existe es type hints, que son opcionales, y que puedes violar sin problema.