En el año 1959 el Departamento de Defensa de Estados Unidos junto con fabricantes tecnológicos de la época, crearon un lenguaje de programación, llamado COBOL...
#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.
#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.
#1 No solo eso. He conocido un konton de empresas que han ofrecido proyectos de migracion de servicios existentes a otros lenguajes. Son baratos? No. Es mas barato seguir manteniendo la mierda que hay? Si. Es un problema de dinero no es un problema de los "programadores".
#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.
#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.
#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.
#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.
#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.
Los sistemas Mainframe, ya sea con Cobol, con Fortran o con cualquier otro, llevan tantisimos años implantados y con un nivel de personalizacion tan enormes, que las migraciones son inviables tanto por tiempo como por coste.
#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.
#21 Como que casi no se usan¿ Si el 90% de las grandes corporaciones tienen instalaciones mainframes? Cuando ves tu bonito cajero con Windows o Linux y una pantalla de botones y colores, detrás, posiblemente este un z16 manejando las transacciones realizadas, y tiene un razón de ser, estabilidad.
#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 ...".
#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.
#77 Arquitectura prehistórica y nula, ole tus cordones, mira este video y me comentas que tiene de prehistórico y nulo el z/16 de IBM y luego vienes y me lo vuelves a contar.
Sistemas AS400, muchos años ha, si he tenido que toquetear alguno, y como digo... ninguna documentación dispuse en aquel momento (creo que se parece mucho a nula), y todo lo que fuese "modificar" algún cálculo que no fuese a un campo nuevo, estaba directamente prohibido. Con lo cual el número de versiones de un mismo cálculo, era como poco... grotesco, y ya no te digo, pretender saber "qué versión era la más correcta".
Te hablo de bastantes años, desconozco como hayan podido evolucionar aquellos sistemas de su momento... y obviamente, no me considero ni de lejos especialista en el tema. Simplemente probé aquellos caldos... y desestimé seguir evolucionando en aquel caos.
Por cierto, mis cordones, te saludan.. agradecidos de tu gesto... y si pones el enlace al vídeo igual me instruye y todo.
#124 y digo yo... qué cojones tendrá que ver el hardware, con la arquitectura de software? Quién dijo que las máquinas IBM hayan sido malas, cuando son tan cojonudas que incluso 50 años después, nadie se atreve a apagarlas?
a ver si el que no tiene ni idea.. y ya le valen sus cordones... vas a ser tú
Me temo que el viejuno, habla con alguien, que no tiene ni idea de lo que le comento.
Ay COBOL, COBOL, el lenguaje que mi profesor nos dijo en 2003 que llevaba 20 años muriendo...
Yo fui becario hace unos 12 años en una consultora IT para un banco en el equipo de desarrollo para los mainframes: COBOL, CISC, JCL, z/OS, y ya la media de edad era alta y las ganas por trabajar en eso bastante pocas.
Yo solo se que se acabará el mundo antes de que se acabe COBOL.
A ver, me puedo equivocar, pero al hablar de arquitectura no incluyo el desarrollo de software, lo relaciono más a la arquitectura de hardware, por esto te he contestado lo que te he contestado y si te sirve de aclaración tengo muchos conocimientos de arquitectura de desarrollo en entornos de miniordenadores y mainframes, llevo desde el 84 desarrollando para corporaciones, de un 4381 a un z/16, se de lo que hablo, posiblemente mejor que tú. Mainframes de 50 años deben quedar 4 o 5 funcionado, mas que nada porque un mainframe no se compra, se compra el derecho de uso y IBM los va renovando, por el mantenimiento, es más barato mantener un z/16 que un 3090, menos problemas de hardware, aunque no dudo que un 4381 siguiera funcionado bien y mayor velocidad de procesamiento y transaccionalidad, pero bueno. Me imagino que hablaras de documentación de la aplicación a modificar porque el As/400 tiene muchísima, y el problema de la documentación de software no tiene que ver ni con el entorno ni con el lenguaje, tiene que ver con las políticas de la empresa, si vas a tocar algo de SAP en Abap te aseguro que lo pasarás igual de mal, como con el 80% de las aplicaciones desarrolladas, mas que nada porque no te dan mucho tiempo a documentar, eso de que ahora se documenta más es una milonga.
#78 Hay muchos nichos enanísimos: profesionales que hablen dos lenguas dispares y minoritarias, expertos en un grupo muy específico de fertilizantes orgánicos, investigadores médicos con experiencia en el estudio de alguna enfermedad rara, etc, etc, etc. Los nichos enanos no suelen ser el problema, porque siempre hay algún friki que le gusta esas frikadas. Desde instalar SO antiguos de ordenadores en smartphones hasta hacer una lavadora a pedales. Hay gente para todo.
Al final todo se basa en lo mismo: quiero que hagas un trabajo altamente cualificado, pero no tan excitante a cambio de un salario de mierda, o unas condiciones de mierda o ambas cosas.
Si te pagaran un sueldazo tremendo. Ahora tu trabajo no se valora, se valora y se paga bien al CEO que se rasca los webos o la seta a dos manos.
#121 pues tienes razón, no permite mutar variables como en JS.
De todos modos, el duck typing es horrible para leer el código de otro i al de una una semana después de programarlo si no tiene type hints (y usas funciones, claro jaja)
Aún así sigo preferiendo leer código ajeno en Python que en cualquier otro lenguaje. Curiosamente, los lenguajes fuertemente tipados y estáticos no se caracterizan por facilitar está tarea.
Pero en realidad el problema no es tanto el lenguaje en el que se programa sino el programador. Desconozco los números pero me juego el cuello a qué el término clean code es ajeno a la inmensa mayoría.
Usarlo para cualquier otra cosa es un tiro en el pie.
Si buscas rendimiento no te va a valer. Pero si buscas estabilidad y mantenimiento, desde luego que sí.
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.
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.
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.
Lo que existe es type hints, que son opcionales, y que puedes violar sin problema.
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.
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.
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 ...".
stackoverflow.com/questions/11328920/is-python-strongly-typed
Sistemas AS400, muchos años ha, si he tenido que toquetear alguno, y como digo... ninguna documentación dispuse en aquel momento (creo que se parece mucho a nula), y todo lo que fuese "modificar" algún cálculo que no fuese a un campo nuevo, estaba directamente prohibido. Con lo cual el número de versiones de un mismo cálculo, era como poco... grotesco, y ya no te digo, pretender saber "qué versión era la más correcta".
Te hablo de bastantes años, desconozco como hayan podido evolucionar aquellos sistemas de su momento... y obviamente, no me considero ni de lejos especialista en el tema. Simplemente probé aquellos caldos... y desestimé seguir evolucionando en aquel caos.
Por cierto, mis cordones, te saludan.. agradecidos de tu gesto... y si pones el enlace al vídeo igual me instruye y todo.
Perdona. www.youtube.com/watch?v=ZDtaanCENbc&t=364s
Y el As/400
a ver si el que no tiene ni idea.. y ya le valen sus cordones... vas a ser tú
Me temo que el viejuno, habla con alguien, que no tiene ni idea de lo que le comento.
Yo fui becario hace unos 12 años en una consultora IT para un banco en el equipo de desarrollo para los mainframes: COBOL, CISC, JCL, z/OS, y ya la media de edad era alta y las ganas por trabajar en eso bastante pocas.
Yo solo se que se acabará el mundo antes de que se acabe COBOL.
Hola empresas, aquí alguien que sigue dándole al COBOL ( y mas cosas que os veo).
Otra vez que nos cuelan la nada como noticia.
Yo he visto:
If(true)
Mogollón de código
Else
Mogollón de código
Debe ser lo mismo, pereza.
Al final todo se basa en lo mismo: quiero que hagas un trabajo altamente cualificado, pero no tan excitante a cambio de un salario de mierda, o unas condiciones de mierda o ambas cosas.
Si te pagaran un sueldazo tremendo. Ahora tu trabajo no se valora, se valora y se paga bien al CEO que se rasca los webos o la seta a dos manos.
#FreeAssange
De todos modos, el duck typing es horrible para leer el código de otro i al de una una semana después de programarlo si no tiene type hints (y usas funciones, claro jaja)
Aún así sigo preferiendo leer código ajeno en Python que en cualquier otro lenguaje. Curiosamente, los lenguajes fuertemente tipados y estáticos no se caracterizan por facilitar está tarea.
Pero en realidad el problema no es tanto el lenguaje en el que se programa sino el programador. Desconozco los números pero me juego el cuello a qué el término clean code es ajeno a la inmensa mayoría.