Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Nota: This feature may not be available in some browsers.
Estás usando un navegador desactualizado. Es posible que no muestre este u otros sitios web correctamente.
Debe actualizar o usar un navegador alternativo.
Debe actualizar o usar un navegador alternativo.
Anthropic se calza la ultima trinchera, cae COBOL
- Autor del tema Triffin’s dilemma
- Fecha de inicio
cortatijeras
Ignorador de foreras
- Desde
- 4 Ago 2018
- Mensajes
- 2.745
- Fruta
- 7.145
Tambien hay cobol para pc, pero no evolucionó lo suficiente y se quedo obsoleto, en los 80 y 90 era muy habitual ver programas de gestión en cobol en muchas empresas, y seguramente muchas aun lo usen, imagino que con el verifactu la mayoría desaparezcanPorque COBOL se tiene que liquidar en mainframes paco?
bigplac
Madmaxista
- Desde
- 28 Ago 2014
- Mensajes
- 2.639
- Fruta
- 7.991
No hay ninguna razon, cobol ejecuta hasta en una lavadora.Porque COBOL se tiene que liquidar en mainframes paco?
Se ejecuta en mainframe porque es lo mejor para su trabajo.
Tu puedes elegir montar un ordenador tocho (mainframe) o muchos pequeñitos. Cada cosa tiene consecuencias. Si la montas en ordenadores pequeñitos pues en cada paso tu aplicacion tiene que estar mandandose mensajitos entre cada ordenador, y al final se pierde mas tiempo pasandose mensajitos que trabajando
Si lo haces en un mainframe te quitas de en medio la guano de los mensajitos y lo haces todo de un tiron.
Un ejemplo, ¿que prefieres en las cajas de mercadona? un carrito con 50 productos, o 50 personas con un producto?
Porque esperar al carrito de los 50 productos es pesado pero solo paga una vez y se va, y las 50 personas con un producto, tienen que pasar los mismos 50 productos y ademas pagar 50 veces, un .
Pero claro, con el sistema de las 50 personas con un producto puedes abrir 10 cajas y con un unico carrito no.
No se si me he explicado.
hayapaz
Himbersor
- Desde
- 2 May 2022
- Mensajes
- 857
- Fruta
- 1.535
No hay ninguna razon, cobol ejecuta hasta en una lavadora.
Se ejecuta en mainframe porque es lo mejor para su trabajo.
Tu puedes elegir montar un ordenador tocho (mainframe) o muchos pequeñitos. Cada cosa tiene consecuencias. Si la montas en ordenadores pequeñitos pues en cada paso tu aplicacion tiene que estar mandandose mensajitos entre cada ordenador, y al final se pierde mas tiempo pasandose mensajitos que trabajando
Si lo haces en un mainframe te quitas de en medio la guano de los mensajitos y lo haces todo de un tiron.
Un ejemplo, ¿que prefieres en las cajas de mercadona? un carrito con 50 productos, o 50 personas con un producto?
Porque esperar al carrito de los 50 productos es pesado pero solo paga una vez y se va, y las 50 personas con un producto, tienen que pasar los mismos 50 productos y ademas pagar 50 veces, un .
Pero claro, con el sistema de las 50 personas con un producto puedes abrir 10 cajas y con un unico carrito no.
No se si me he explicado.
Tienes que estar registrado para ver este contenido
Ok
Tema IA, yo creo que la IA permite que COBOL siga viviendo, ya que ahora cualquier programador puede ejecutarlo.
hayapaz
Himbersor
- Desde
- 2 May 2022
- Mensajes
- 857
- Fruta
- 1.535
NarrativaEsa caida es porque la gente no entiende que para IBM esa noticia es insignificante, en todo caso buena.
Y en general para los programadores COBOL es una buena noticia, les puede facilitar mucho el trabajo pero NUNCA le sustituira.
El COBOL se sigue usando por ser lo mas eficiente y robusto. Y nadie va a cambiar/actualizar eso con una IA sin que haya un programador detras que lo revise a nivel como si lo hubiera programado el, y con todo el testeo posterior.
Usaran la IA para un cierto diseño de programacion, despues partiran ese diseño en mil trozos y cada trozo (con su prerequisitos) lo hara un programador.
En resumen, una facilidad o herramienta para el mundo COBOL que asegura aun mas su trabajo. De COBOL nunca ha habido ni habra paro, siempre faltan.
Antrophic y OpenIA están manejando la narrativa de la bolsa a golpe de talonario para que influencers y medios hagan noticias de la IA.
El agujero sigue, y lo siguen tapando con inversión circular.
MiNombreEsFantasma
Madmaxista
- Desde
- 20 Jul 2015
- Mensajes
- 7.197
- Fruta
- 17.699
Porque COBOL se tiene que liquidar en mainframes paco?
Es por ecosistema. Cuando pensamos en Cobol no tenemos que pensar en el lenguaje en sí, sino en el ecosistema que tiene a su alrededor, principalmente CISC, que es un gestor transaccional que lleva muchos años en el mercado y sobre el que se ejecutan la mayoría de aplicaciones realizadas en Cobol.
CISC se ejecuta sólo en Mainframes de IBM.
CISC es en sí mismo una metodología de trabajo, que se integra muy bien con el Mainframe y te da toda clase de servicios y herramientas. Al final al usar una cosa usas la otra, y viceversa.
La estructura de Cobol, aunque en teoría es un lenguaje de propósito general sin orientación a arquitectura alguna, está muy imbricada dentro de la forma en la que trata los datos los sistemas operativos de Mainframe de IBM. Por eso, fuera del Mainframe, no se usa mucho.
Realmente puedes ejecutarlo donde quieras. Pero su diseño rompe un poco con las arquitecturas y metodologías de tratamiento de datos en sistemas operativos que se usan en fruta general hoy en día, más orientadas a redes de máquinas de bajo coste y transacciones distribuidas.
Los Mainframe no son "Paco" como tal, se actualizan constantemente y en sus SO se incorporan todas las últimas tecnologías. El Hardware de un Mainframe es muy potente.
lum
Madmaxista
Hay otra gente que ya lo está explicando muy bien en este hilo, añadiré un poco más en ese sentido. Yo también opino que esto es humo "IA" con poca sustancia.
Dá igual que las modelos famosos generen código gramaticalmente correcto y que puedan traducir entre COBOL y otros lenguajes. Eso NO es el problema principal que tendría que resolver un banco para cambiar sus rutinas en un mainframe. Para nada. Y lo digo con bastante conocimiento de causa, porque trabajé más de dos años en un proyecto de migración del core de un banco (spoiler: dicho proyecto NO terminó en solamente dos años, ni mucho menos).
El problema es que en un banco uno se encuentra con literalmente MILES de programas. Unos se ejecutan diariamente a todas horas, otros mensualmente (simplificando), y otros con periodicidades distintas o de forma esporádica. Y algunos a lo mejor dejaron de usarse hace tiempo, pero es difícil estar seguro de que ya no cumplan ninguna función. Muchos de esos programas fueron escritos hace 10 o 20 años, actualizados por última vez hace años, algo que no es para nada frecuente en otros sectores. Esto tiene muchas implicaciones. Muchos de los autores de esos programas, ya no están, o están a otra cosa y ni se acuerdan de la problemática en la que trabajaron en aquella época (o no en detalle). Muchos de estos programas son lógica de negocio con la que no se puede jugar sin entender. Esto es, un programador sin experiencia en la problemática concreta, no puede entender bien cuál es el funcionamiento correcto del programa. Y en el propio banco puede no haber nadie, o muy poca gente, que pueda ayudar a resolver dudas al respecto. Incluso si la hay, y continua trabajando allí todavía, esa gente tienen otras tareas.
Traducir todos esos programas automáticamente, se puede hacer sin "IA". Ello NO es el problema. El problema es que uno tiene que asegurarse, que los miles de programas que ya funcionan, siguen funcionando. Esto tiene muchas complicaciones, que son la verdadera complicación de la migración. En esencia, es muy difícil verificar que el programa traducido a un lenguaje y entorno distinto, tenga exactamente el mismo comportamiento que el original. Más todavía cuando hay relaciones muy complejas a veces difíciles siquiera de detectar entre los resultados del procesamiento de distintos programas.
Y me estoy saltando problemas finos que los veteranos se pueden imaginar. O sea la cantidad de truquitos y guano varias que hay en el código de los programas originales, retorciendo al máximo las posibilidades del lenguaje y el entorno disponibles. El copy/paste de estos truquillos con distintas variaciones. Etc.
Los modelos de LLM son completamente inútiles para esto que estoy comentando someramente que es la gran dificultad, o sea la validación y ajuste fino de los programas traducidos para que en su conjunto hagan lo mismo que el conjunto de los programas originales. Que es lo complicado y lo que lleva muchísimo tiempo puesto que hay que hacerlo de forma escalonada y con una enorme planificación y con sistemas de detección de fallos y backup pogre en la migración. Y una monitorización con expertos, durante toda la migración.
Lo que los modelos de LLM pueden hacer, ya se puede hacer sin ellos, y de forma más fiable. Esto es, con una transpilador adaptado a las necesidades del entorno. Pero claro esto es un trabajo fino que require de gente que al menos haya estudiado/trabajado en serio teoría de lenguajes y/o compiladores. Nada que no se pueda encontrar por ahí de todas formas.
Dá igual que las modelos famosos generen código gramaticalmente correcto y que puedan traducir entre COBOL y otros lenguajes. Eso NO es el problema principal que tendría que resolver un banco para cambiar sus rutinas en un mainframe. Para nada. Y lo digo con bastante conocimiento de causa, porque trabajé más de dos años en un proyecto de migración del core de un banco (spoiler: dicho proyecto NO terminó en solamente dos años, ni mucho menos).
El problema es que en un banco uno se encuentra con literalmente MILES de programas. Unos se ejecutan diariamente a todas horas, otros mensualmente (simplificando), y otros con periodicidades distintas o de forma esporádica. Y algunos a lo mejor dejaron de usarse hace tiempo, pero es difícil estar seguro de que ya no cumplan ninguna función. Muchos de esos programas fueron escritos hace 10 o 20 años, actualizados por última vez hace años, algo que no es para nada frecuente en otros sectores. Esto tiene muchas implicaciones. Muchos de los autores de esos programas, ya no están, o están a otra cosa y ni se acuerdan de la problemática en la que trabajaron en aquella época (o no en detalle). Muchos de estos programas son lógica de negocio con la que no se puede jugar sin entender. Esto es, un programador sin experiencia en la problemática concreta, no puede entender bien cuál es el funcionamiento correcto del programa. Y en el propio banco puede no haber nadie, o muy poca gente, que pueda ayudar a resolver dudas al respecto. Incluso si la hay, y continua trabajando allí todavía, esa gente tienen otras tareas.
Traducir todos esos programas automáticamente, se puede hacer sin "IA". Ello NO es el problema. El problema es que uno tiene que asegurarse, que los miles de programas que ya funcionan, siguen funcionando. Esto tiene muchas complicaciones, que son la verdadera complicación de la migración. En esencia, es muy difícil verificar que el programa traducido a un lenguaje y entorno distinto, tenga exactamente el mismo comportamiento que el original. Más todavía cuando hay relaciones muy complejas a veces difíciles siquiera de detectar entre los resultados del procesamiento de distintos programas.
Y me estoy saltando problemas finos que los veteranos se pueden imaginar. O sea la cantidad de truquitos y guano varias que hay en el código de los programas originales, retorciendo al máximo las posibilidades del lenguaje y el entorno disponibles. El copy/paste de estos truquillos con distintas variaciones. Etc.
Los modelos de LLM son completamente inútiles para esto que estoy comentando someramente que es la gran dificultad, o sea la validación y ajuste fino de los programas traducidos para que en su conjunto hagan lo mismo que el conjunto de los programas originales. Que es lo complicado y lo que lleva muchísimo tiempo puesto que hay que hacerlo de forma escalonada y con una enorme planificación y con sistemas de detección de fallos y backup pogre en la migración. Y una monitorización con expertos, durante toda la migración.
Lo que los modelos de LLM pueden hacer, ya se puede hacer sin ellos, y de forma más fiable. Esto es, con una transpilador adaptado a las necesidades del entorno. Pero claro esto es un trabajo fino que require de gente que al menos haya estudiado/trabajado en serio teoría de lenguajes y/o compiladores. Nada que no se pueda encontrar por ahí de todas formas.
hayapaz
Himbersor
- Desde
- 2 May 2022
- Mensajes
- 857
- Fruta
- 1.535
Yo creo que esto de la IA hará que la vida de COBOL sea más frugal. Ahora un programador puede ponerse a desarrollar en COBOL rápido gracias a la IA y a sus explicaciones de cómo funciona.Hay otra gente que ya lo está explicando muy bien en este hilo, añadiré un poco más en ese sentido. Yo también opino que esto es humo "IA" con poca sustancia.
Dá igual que las modelos famosos generen código gramaticalmente correcto y que puedan traducir entre COBOL y otros lenguajes. Eso NO es el problema principal que tendría que resolver un banco para cambiar sus rutinas en un mainframe. Para nada. Y lo digo con bastante conocimiento de causa, porque trabajé más de dos años en un proyecto de migración del core de un banco (spoiler: dicho proyecto NO terminó en solamente dos años, ni mucho menos).
El problema es que en un banco uno se encuentra con literalmente MILES de programas. Unos se ejecutan diariamente a todas horas, otros mensualmente (simplificando), y otros con periodicidades distintas o de forma esporádica. Y algunos a lo mejor dejaron de usarse hace tiempo, pero es difícil estar seguro de que ya no cumplan ninguna función. Muchos de esos programas fueron escritos hace 10 o 20 años, actualizados por última vez hace años, algo que no es para nada frecuente en otros sectores. Esto tiene muchas implicaciones. Muchos de los autores de esos programas, ya no están, o están a otra cosa y ni se acuerdan de la problemática en la que trabajaron en aquella época (o no en detalle). Muchos de estos programas son lógica de negocio con la que no se puede jugar sin entender. Esto es, un programador sin experiencia en la problemática concreta, no puede entender bien cuál es el funcionamiento correcto del programa. Y en el propio banco puede no haber nadie, o muy poca gente, que pueda ayudar a resolver dudas al respecto. Incluso si la hay, y continua trabajando allí todavía, esa gente tienen otras tareas.
Traducir todos esos programas automáticamente, se puede hacer sin "IA". Ello NO es el problema. El problema es que uno tiene que asegurarse, que los miles de programas que ya funcionan, siguen funcionando. Esto tiene muchas complicaciones, que son la verdadera complicación de la migración. En esencia, es muy difícil verificar que el programa traducido a un lenguaje y entorno distinto, tenga exactamente el mismo comportamiento que el original. Más todavía cuando hay relaciones muy complejas a veces difíciles siquiera de detectar entre los resultados del procesamiento de distintos programas.
Y me estoy saltando problemas finos que los veteranos se pueden imaginar. O sea la cantidad de truquitos y guano varias que hay en el código de los programas originales, retorciendo al máximo las posibilidades del lenguaje y el entorno disponibles. El copy/paste de estos truquillos con distintas variaciones. Etc.
Los modelos de LLM son completamente inútiles para esto que estoy comentando someramente que es la gran dificultad, o sea la validación y ajuste fino de los programas traducidos para que en su conjunto hagan lo mismo que el conjunto de los programas originales. Que es lo complicado y lo que lleva muchísimo tiempo puesto que hay que hacerlo de forma escalonada y con una enorme planificación y con sistemas de detección de fallos y backup pogre en la migración. Y una monitorización con expertos, durante toda la migración.
Lo que los modelos de LLM pueden hacer, ya se puede hacer sin ellos, y de forma más fiable. Esto es, con una transpilador adaptado a las necesidades del entorno. Pero claro esto es un trabajo fino que require de gente que al menos haya estudiado/trabajado en serio teoría de lenguajes y/o compiladores. Nada que no se pueda encontrar por ahí de todas formas.
Antes de la IA había que encontrar al programador COBOL para que meta mano, hoy en día un programador competente puede meterse con COBOL en una décima parte del tiempo.
Yo mismo me he puesto a entrenar redes neuronales con tensor, algo que llevaba años pendiente porque era muy vago, pero ahora con la IA te resuelve todas las dudas, te explica todo, vas muy rápido.
simontemplario
Madmaxista
Para Desarrollar de cero puede ayudar, acelerar o mejorar. Cambiar millones de líneas de código, con sus funcionalidades y sus relaciones entre decenas, centenas o miles de programas, subprogramas, rutinas, bbdds y las modificaciones históricas que ellos contienen. Unos en estructurado, otros en top-bottom, performs o gotos… mucho me parece para que lo haga un LLM sin supervisión ni palos.
Me suena más a narrativa con vista a la bolsa.
Me suena más a narrativa con vista a la bolsa.
OYeah
Madmaxista
- Desde
- 16 Nov 2017
- Mensajes
- 43.727
- Fruta
- 72.090
No se va a hacer así.
Se va a empezar de cero.
CBDC.
Y es lógico porque el empastre enorme que se ha creado con IBM y COBOL y sus mainframes y la progenitora que los parió no tiene ningún sentido y es peligrosísimo. ¿Desde cuándo se sustenta toda la economía global en una sola empresa y en un determinado hardware? ¿Estamos locos?
Se va a empezar de cero.
CBDC.
Y es lógico porque el empastre enorme que se ha creado con IBM y COBOL y sus mainframes y la progenitora que los parió no tiene ningún sentido y es peligrosísimo. ¿Desde cuándo se sustenta toda la economía global en una sola empresa y en un determinado hardware? ¿Estamos locos?
entropico
Madmaxista
- Desde
- 6 Ene 2007
- Mensajes
- 2.446
- Fruta
- 4.138
Yo no me preocuparía por eso, porque esto ocurrirá el próximo año, no este. (y asi recursivamente)Quien ha tenido la oportunidad de usar las últimas versiones de IA, reconoce su potencial, y eso que todavía está en pañales. Apostar contra esta tecnología es como ir contra la revolución industrial. El tiempo os dejará retratados...
entropico
Madmaxista
- Desde
- 6 Ene 2007
- Mensajes
- 2.446
- Fruta
- 4.138
Esto tiene sentido, pero van a tener que colgar a la fuerza a los bancos.No se va a hacer así.
Se va a empezar de cero.
CBDC.
Y es lógico porque el empastre enorme que se ha creado con IBM y COBOL y sus mainframes y la progenitora que los parió no tiene ningún sentido y es peligrosísimo. ¿Desde cuándo se sustenta toda la economía global en una sola empresa y en un determinado hardware? ¿Estamos locos?
Al final será alguna empresa de informática grande que por fuerza bruta desbanque a la banca, y eso es muuucha fuerza bruta.
Como hizo Amazon con el hosting por ejemplo, pura fuerza bruto de su AWS. Y ahora le llaman cloud
Coronel Kurtz
Será en Octubre
No es necesario nada.
Esta todo virtualizado.
Es COBOL+SQL+VMS.
Los problemas vienen con el Java en la parte de cara al usuario.
Que se lo acabaran trinc, por eso están dando tanto por pandero con el Rust.
Y acabaran en PHP.
Todo esto es el producto favorito y mas rentable de todo lo que rodea a la informática, el humo.
PD: GnuCOBOL permite pasar de COBOL a C.
Esta todo virtualizado.
Es COBOL+SQL+VMS.
Los problemas vienen con el Java en la parte de cara al usuario.
Que se lo acabaran trinc, por eso están dando tanto por pandero con el Rust.
Y acabaran en PHP.
Todo esto es el producto favorito y mas rentable de todo lo que rodea a la informática, el humo.
PD: GnuCOBOL permite pasar de COBOL a C.
Florecilla Silvestre
Madmaxista
- Desde
- 23 Mar 2010
- Mensajes
- 16.091
- Fruta
- 16.619
Este trozo de respuesta me trae dos recuerdos. El primero es de un forero que hablando de ofertas de trabajo de Python dijo que tienen todas el mismo truco. Que Python para genética, para webs, análisis de datos, IA ... significaba Python (10%) y luego saber de genética, webs, análisis de datos o IA (el 90% restante). El otro recuerdo es el de una pequeña empresa que sufrió una filtración de su base de código. Se reunieron de emergencia para decidir cómo responder. Acordaron seguir adelante porque el código no era verdaderamente su producto. Sí: lo picaban como fieras pero el núcleo de todo estaba en sus cabecitas y en el hecho de que lo entendían. El programa era una expresión formal de ese conocimientoMuchos de estos programas son lógica de negocio con la que no se puede jugar sin entender. Esto es, un programador sin experiencia en la problemática concreta, no puede entender bien cuál es el funcionamiento correcto del programa.
W.Morgan
Catdalf el Sarracena
- Desde
- 2 Jul 2019
- Mensajes
- 9.531
- Fruta
- 21.309
Contrataran a alguna consultora que tendrá algun programador que mas o menos sepa cobol pero que hará todo con claude, basicamente. O sea, lo que se está haciendo ya con el resto de lenguajes de alto nivel.Es cierto que las entidades financieras casi todas utilizan COBOL, eso si, no sé yo si estarán dispuestas a que experiente con sus datos una IA.
hayapaz
Himbersor
- Desde
- 2 May 2022
- Mensajes
- 857
- Fruta
- 1.535
No se va a hacer así.
Se va a empezar de cero.
CBDC.
Y es lógico porque el empastre enorme que se ha creado con IBM y COBOL y sus mainframes y la progenitora que los parió no tiene ningún sentido y es peligrosísimo. ¿Desde cuándo se sustenta toda la economía global en una sola empresa y en un determinado hardware? ¿Estamos locos
Ya lo han explicado inútil, lee el hilo
simontemplario
Madmaxista
No conoces mucho el funcionamiento de lo que comentas. Aparte de que es el único sistema nunca hackeado.No se va a hacer así.
Se va a empezar de cero.
CBDC.
Y es lógico porque el empastre enorme que se ha creado con IBM y COBOL y sus mainframes y la progenitora que los parió no tiene ningún sentido y es peligrosísimo. ¿Desde cuándo se sustenta toda la economía global en una sola empresa y en un determinado hardware? ¿Estamos locos?
¡Ains, que los MIPS son muy caros! Una vez tus guano estén en mamazon, glogle y demás, te van a dejar procesar a tarifa plana alopécicophone… ni la excusa de los mips, la favorita de los CEOs, CIOs y demás gilipilers con ínfulas sostiene el cambio.
En cualquier caso me la pela, yo ya compro latunes que viene la IA.
OYeah
Madmaxista
- Desde
- 16 Nov 2017
- Mensajes
- 43.727
- Fruta
- 72.090
Ya lo han explicado inútil, lee el hilo
Al ignore.
No conoces mucho el funcionamiento de lo que comentas. Aparte de que es el único sistema nunca hackeado.
¡Ains, que los MIPS son muy caros! Una vez tus guano estén en mamazon, glogle y demás, te van a dejar procesar a tarifa plana alopécicophone… ni la excusa de los mips, la favorita de los CEOs, CIOs y demás gilipilers con ínfulas sostiene el cambio.
En cualquier caso me la pela, yo ya compro latunes que viene la IA.
Y a mamarla.
Ale, circulando. Yo tonterias y y egos ya los justos.
simontemplario
Madmaxista
Yo no te he contestado con ego ni similar. Te he contestado en base a lo que tú has puesto, lo mismo sí y no lo has expresado de forma que se entienda (o al menos para mí).Al ignore.
Y a mamarla.
Ale, circulando. Yo tonterias y y egos ya los justos.
El segundo párrafo aunque lo parezca no habla de ti sino de lo que me encuentro hace ya 30 años casi.
El 3º es ironía