Portada
mis comunidades
otras secciones
![El estado de New Jersey necesita urgentemente programadores de COBOL [EN]](https://cdn.mnmstatic.net/cache/32/1a/media_thumb_2x-link-3283668.jpeg?1586092026)
#17:
El problema no es el Cobol. Un programador sério lo aprende en una tarde. El problema es entender un aplicativo desarrollado y documentado con mentalidad de los años 60.
#27:
#23 Eso no es problema del lenguaje, es problema de los planes de estudio de las carreras, que deberían incluir cosas antiguas porque siguen siendo de utilidad.
Pero tal y como dicen un programador bueno aprende Cobol en dos patadas.
Yo di Cobol en la carrera, a un nivel muy básico, y no es difícil como lenguaje.
De hecho en programación la dificultad no suele estar en el lenguaje sino en el algoritmo.
Algunos lenguajes facilitan cierto tipo de algoritmos y por eso es importante escoger el lenguaje en función de la necesidad.
Hay lenguajes pensados para tratar datos, otros para operar a nivel HW, otros por su tipado hacen más difícil cometer errores, y otros que dan más libertad para hacer lo que quieras.
El lenguaje es una herramienta, y cada herramienta está enfocada a una necesidad.
Un lenguaje moderno puede ser un destornillador eléctrico multifunción con muchos cabezales, pero igual tu necesidad es clavar clavos. Con tu destornillador eléctrico podrás clavarlos a lo bruto, pero quedarán peor que con un martillo.
Pero tal y como dicen un programador bueno aprende Cobol en dos patadas.
Yo di Cobol en la carrera, a un nivel muy básico, y no es difícil como lenguaje.
De hecho en programación la dificultad no suele estar en el lenguaje sino en el algoritmo.
Algunos lenguajes facilitan cierto tipo de algoritmos y por eso es importante escoger el lenguaje en función de la necesidad.
Hay lenguajes pensados para tratar datos, otros para operar a nivel HW, otros por su tipado hacen más difícil cometer errores, y otros que dan más libertad para hacer lo que quieras.
El lenguaje es una herramienta, y cada herramienta está enfocada a una necesidad.
Un lenguaje moderno puede ser un destornillador eléctrico multifunción con muchos cabezales, pero igual tu necesidad es clavar clavos. Con tu destornillador eléctrico podrás clavarlos a lo bruto, pero quedarán peor que con un martillo.
#134:
#30 yo mantengo código "viejo" (unos 15 años tiene) y a la vez hacemos nuevo te aseguro que tendrán el mismo problema en otros 15 años, cuando pido tiempo pa documentar siempre dicen "bueno eso ya cuando no corra prisa" ¿conocéis algún trabajo de informática en el que algo no corra prisa? Pues eso
#39:
#6 Nada es cero fallos pero COBOL es muy estricto en todo: en el manejo de tipos, en la declaración de variables, en la estructura de datos, en la estructura de código.
Esto hace que filtre muchísimos errores en tiempo de compilación. Pocos lenguajes hay tan fiables. Cuando consigues hacer el ejecutable, si falla algo será porque esta mal diseñado el procedimiento, pero el programa ni se va a colgar ni va a hacer cosas raras ni nada que no hubiera previsto el programador.
Ademas es muy facil de mantener, puedes leer el codigo y saber lo que hace aunque no tenga comentarios. Tiene un lenguaje más parecido al humano que al de la máquina.
Esto hace que filtre muchísimos errores en tiempo de compilación. Pocos lenguajes hay tan fiables. Cuando consigues hacer el ejecutable, si falla algo será porque esta mal diseñado el procedimiento, pero el programa ni se va a colgar ni va a hacer cosas raras ni nada que no hubiera previsto el programador.
Ademas es muy facil de mantener, puedes leer el codigo y saber lo que hace aunque no tenga comentarios. Tiene un lenguaje más parecido al humano que al de la máquina.
#36:
#35 Vuelves a comparar a posta cosas diferentes.
¿Mi negocio depende de que mi móvil tenga batería, o de que reciba mails?
En el primer caso además tengo opciones, puedo pillar un móvil que no se agote la batería o puedo asegurarme de tener siempre el cargador y un enchufe cerca.
Por otro lado si fuese tema de pasta no entiendo que los bancos paguen millonadas a IBM por los mainframe y el DB2, o a Oracle, pudiendo usar MariaDB o Postgre.
En su negocio lo crítico es la integridad y validez del dato (aunque estar sin web les haga palmar pasta) y por lo tanto toman medidas distintas que otros casos donde la criticidad es el aplicativo por encima del dato.
¿Mi negocio depende de que mi móvil tenga batería, o de que reciba mails?
En el primer caso además tengo opciones, puedo pillar un móvil que no se agote la batería o puedo asegurarme de tener siempre el cargador y un enchufe cerca.
Por otro lado si fuese tema de pasta no entiendo que los bancos paguen millonadas a IBM por los mainframe y el DB2, o a Oracle, pudiendo usar MariaDB o Postgre.
En su negocio lo crítico es la integridad y validez del dato (aunque estar sin web les haga palmar pasta) y por lo tanto toman medidas distintas que otros casos donde la criticidad es el aplicativo por encima del dato.
#33:
#28 Amazon y Google probablemente no traten con datos estructurados con las mismas necesidades que un banco, una aseguradora o las líneas aéreas. Comparas necesidades distintas, y requisitos de fiabilidad diferentes.
¿Que durante una consulta Google no consigue hacer un barrido de todas las webs, o no siempre responde igual? Pues no pasa nada, pero ese no es el nivel de exigencia para otros negocios.
Y las peticiones que reciben no son transacciones en el sentido que se da para los mainframe, son peticiones web y no tienen por qué ser atómicas ni tienen por qué atenderse en orden estricto.
Comparas cosas distintas.
¿Que durante una consulta Google no consigue hacer un barrido de todas las webs, o no siempre responde igual? Pues no pasa nada, pero ese no es el nivel de exigencia para otros negocios.
Y las peticiones que reciben no son transacciones en el sentido que se da para los mainframe, son peticiones web y no tienen por qué ser atómicas ni tienen por qué atenderse en orden estricto.
Comparas cosas distintas.
#30:
#14 sabe de que habla
Mi último proyecto en cobol fue actualizar una app de una compañía fabricante de cacharros que vuelan para prolongar su vida útil.
El resultado. Tras 6 meses de proyecto, conocía yo más los entresijos y las tripas de su aplicativo que sus ingenieros
Por supuesto, app ochentera, cero documentación disponible
Mi último proyecto en cobol fue actualizar una app de una compañía fabricante de cacharros que vuelan para prolongar su vida útil.
El resultado. Tras 6 meses de proyecto, conocía yo más los entresijos y las tripas de su aplicativo que sus ingenieros
Por supuesto, app ochentera, cero documentación disponible
#44:
#c-32" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/32">#32 Hombre, no me imagino al Banco de Santander, por poner un ejemplo, trabajando con bases de datos MySQL o SQLSever y código php ejecutando millones de transacciones por segundo, la verdad, no.
editado:
Puse php por poner algo, yo soy de la vieja escuela: sólo Pascal Objects, C/C++ y, recientemente, C#, que estoy aprendiendo.
Comentarios
#1 La mayor parte de la Banca, en todo el mundo, sigue usando cobol: es robusto, fiable y a prueba de fallos.
#3 Trabajo en un proyecto que está migrando un sistema crítico para la empresa, de aplicaciones de escritorio a un entorno 100% web, mientras se amplia y mantiene el viejo.
Es un sinvivir
#4 Bueno... eso del. Zero failure..
Falla, como todo sw, lo que pasa es que a un programa que lleva corriendo 30 años, ya se le han detectado todos los bugs
#1 Es que cuesta.. Un sistema crítico, rehacerlo de 0,..cuando a la vez tienes que mantener el antuguo que sigue vivo...
Y además suelen ser sistemas muy entrelazados con otros, con interfaces sin documentar..
El problema no es el Cobol. Un programador sério lo aprende en una tarde. El problema es entender un aplicativo desarrollado y documentado con mentalidad de los años 60.
#5 no faltan programadores, falta dinero sobre la mesa .
#23 Eso no es problema del lenguaje, es problema de los planes de estudio de las carreras, que deberían incluir cosas antiguas porque siguen siendo de utilidad.
Pero tal y como dicen un programador bueno aprende Cobol en dos patadas.
Yo di Cobol en la carrera, a un nivel muy básico, y no es difícil como lenguaje.
De hecho en programación la dificultad no suele estar en el lenguaje sino en el algoritmo.
Algunos lenguajes facilitan cierto tipo de algoritmos y por eso es importante escoger el lenguaje en función de la necesidad.
Hay lenguajes pensados para tratar datos, otros para operar a nivel HW, otros por su tipado hacen más difícil cometer errores, y otros que dan más libertad para hacer lo que quieras.
El lenguaje es una herramienta, y cada herramienta está enfocada a una necesidad.
Un lenguaje moderno puede ser un destornillador eléctrico multifunción con muchos cabezales, pero igual tu necesidad es clavar clavos. Con tu destornillador eléctrico podrás clavarlos a lo bruto, pero quedarán peor que con un martillo.
#17 documenque?
#1 Busca un lenguaje de programación que maneje de serie números decimales de precisión arbitraria de a un nivel siquiera similar a COBOL.
#1 Eso incumpliría la regla número 1 de programación que ha sido utilizada por los mayores expertos en la materia:
si funciona, no lo toques!
#1
No hay huevos.
Encima, deben tener un lío de dependencias entre sistemas que da miedo.
#4 también los papiros pero han pasado muchos años. Hace tiempo que deberían haber sabido que iban a faltar programadores.
#14 sabe de que habla
Mi último proyecto en cobol fue actualizar una app de una compañía fabricante de cacharros que vuelan para prolongar su vida útil.
El resultado. Tras 6 meses de proyecto, conocía yo más los entresijos y las tripas de su aplicativo que sus ingenieros
Por supuesto, app ochentera, cero documentación disponible
#28 Amazon y Google probablemente no traten con datos estructurados con las mismas necesidades que un banco, una aseguradora o las líneas aéreas. Comparas necesidades distintas, y requisitos de fiabilidad diferentes.
¿Que durante una consulta Google no consigue hacer un barrido de todas las webs, o no siempre responde igual? Pues no pasa nada, pero ese no es el nivel de exigencia para otros negocios.
Y las peticiones que reciben no son transacciones en el sentido que se da para los mainframe, son peticiones web y no tienen por qué ser atómicas ni tienen por qué atenderse en orden estricto.
Comparas cosas distintas.
#35 Vuelves a comparar a posta cosas diferentes.
¿Mi negocio depende de que mi móvil tenga batería, o de que reciba mails?
En el primer caso además tengo opciones, puedo pillar un móvil que no se agote la batería o puedo asegurarme de tener siempre el cargador y un enchufe cerca.
Por otro lado si fuese tema de pasta no entiendo que los bancos paguen millonadas a IBM por los mainframe y el DB2, o a Oracle, pudiendo usar MariaDB o Postgre.
En su negocio lo crítico es la integridad y validez del dato (aunque estar sin web les haga palmar pasta) y por lo tanto toman medidas distintas que otros casos donde la criticidad es el aplicativo por encima del dato.
#6 Nada es cero fallos pero COBOL es muy estricto en todo: en el manejo de tipos, en la declaración de variables, en la estructura de datos, en la estructura de código.
Esto hace que filtre muchísimos errores en tiempo de compilación. Pocos lenguajes hay tan fiables. Cuando consigues hacer el ejecutable, si falla algo será porque esta mal diseñado el procedimiento, pero el programa ni se va a colgar ni va a hacer cosas raras ni nada que no hubiera previsto el programador.
Ademas es muy facil de mantener, puedes leer el codigo y saber lo que hace aunque no tenga comentarios. Tiene un lenguaje más parecido al humano que al de la máquina.
#c-32" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3283668/order/32">#32 Hombre, no me imagino al Banco de Santander, por poner un ejemplo, trabajando con bases de datos MySQL o SQLSever y código php ejecutando millones de transacciones por segundo, la verdad, no.
#30 Nosotros llevamos 1.5 años. Perdemos más tiempo en desarrollar programas que sincronicen ambos sistemas que en desarrollar el nuevo y como tu dices, se yo mas del "core" del negocio, que la gente que lleva trabajando 20 años.
No han tenido tiempo para pasar todo a un lenguaje más actual, no sé, c++, que tiene como 30 años o más. Y de aquellos barros...
COBOL, el lenguaje del futuro en 1959
#7 Y que pueda manejar índices de bases de datos casi infinitos.
#5 Los papiros no son robustos, fiables y a prueba de fallos. COBOL sí.
#1 Eso vale dinero, y los usanos no les gusta que el estado les robe su dinero en forma de impuestos es es de putos rojos comunistas.
#22 Mis hojos!
#30 yo mantengo código "viejo" (unos 15 años tiene) y a la vez hacemos nuevo te aseguro que tendrán el mismo problema en otros 15 años, cuando pido tiempo pa documentar siempre dicen "bueno eso ya cuando no corra prisa" ¿conocéis algún trabajo de informática en el que algo no corra prisa? Pues eso
#6 "ya se le han detectado todos los bugs"
Coñe, por eso es fiable y "zero failure"
#7
Y luego usar coma fija con dos decimales para todo.
A la mierda el karma, he votado antigua
No es solo que “si funciona no lo toques”, es que tampoco tiene sentido cambiarlo por otra cosa que va a funcionar peor solo porque sea más moderna.
Cobol hace lo que hace mejor que cualquier otro lenguaje en fiabilidad, eficiencia y estabilidad, y está completamente integrado en su ecosistema (servidores mainframe, BBDD, gestores de transacciones, etc).
No sentido cambiarlo si no es para mejorar, y ahora mismo no hay nada mejor en muchos casos, y suelen ser sitios donde el volumen de datos y transacciones a tratar es brutal (conozco sitios donde se ha quitado con éxito, pero no entran dentro de lo que llamo volumen brutal).
#4 Como lo son 100 millones de lenguajes que no dan ganas de suicidarse para programarlos.
Aquí lo que prima es, con Cobol funciona, y mientras se pueda mantener el coste es bajo.
Rehacerlo y que alguien la cague cuesta millones, por tanto, si algun dia nadie usa COBOL sera un problema de la banca de mañana.
#38 tb hay q tener en cuenta q los micros viejos resisten mejor la radiación etc
#6 parte de que COBOL, si no recuerdo mal (lo estudié ara como 30 años), es muy estricto
#41 Ya te digo que no son patada hacia delante, si el cambio les pudiese suponer ahorro a largo plazo ya te digo que se lo plantearían, sobre todo los bancos grandes.
Doy soporte a un par de entidades bancarias pequeñas (muy pequeñas) que miran la pela, y que las inversiones se analizan teniendo en cuenta los costes a años vista (no cambian ni un firewall fortigate pequeño si no es a 5 años), y ahí siguen con el cobol a pesar de la pasta que les cuesta en licencias, soporte, subcontratas, etc.
Si pudiesen migrar ya lo habrían hecho, el retorno de la inversión sería de 5 años o menos en costes de licencias y operativos.
#53 El tiempo ya me ha dado la razón. Ese software lleva 40 años funcionando.
¿firmas tu un software que dure lo mismo sin fallos?
PD: si pone dinero NJ no le faltarán candidatos para trabajar.
#57 comp.lang.cobol quiza en usenet. No lo digo de broma, otros subgrupos como comp.lang.c y comp.lang.c.moderated lo siguen petando. Preguntas y responden.
https://news.eternal-september.org, tu cliente favorito (Pan/XNews/Slrn)... y a tirar millas. No, evita Google Groups, tienen un ban masivo a esa mierda para evitar SPAM e imbeciles.
#47, eso es como si en el mundo del transporte pretendieras actualizar un barco de vela del siglo XVI a avión de pasajeros actual. Tienes dos opciones: 1) mejoras el barco de vela a barco con motor: sigues teniendo un barco. 2) Eliminas por completo el barco y creas el avión: entonces no actualizas, simplemente copias o coges algo que ya existe.
Si lo que sugieres es ponerle dos alas al barco, te puedes imaginar lo que pasaría.
#55 Eso de que las generaciones actuales no quieren aprender es muy discutible.
La inmensa mayoría de informáticos/programadores trabajan en lo que encuentran, no en lo que quieren (al menos en España), si tu pones dinero sobre la mesa, con planes de carrera, te llegarán buenos programadores dispuestos a programar cobol 8h (o 7h) por un buen sueldo. Incluso 5h y luego 3h en proyectos en otras tecnologías.
Si me ponene 50K en remoto, mañana estoy picando Cobol.
#3 Un lenguaje feo y antiguo sumado a sistemas críticos poco documentados ¿Acaso es necesario algo más para espantar a cualquier persona que sepa programar por muy bien que le paguen?
#1 piensas como informático y no como empresario.
Si el software funciona ¿Para que. As a rehacerlo con el coste que conlleva?
#29 Los usan porque ya se saben todos los bugs conocidos, no porque fallen menos (una pequeña diferencia)
#62 lo serían en otra época, ahora no te creas, salario medio. Al fin y al cabo las consultoras hacen cursos de formación para gente que entra nueva, y por lo menos en España hay muchísima gente que trabaja en COBOL, y como para muchos es un primer empleo, si no se mueven, no cobran mucho, y como hay tanta oferta de programadores, tampoco ofrecen maravillas.
#13 esa regla es de administración de sistemas, no de programación
#72 había leído -pandemic
#79 luego meten a licenciados en historia a programar en cobol (que no te creas, tiene su gracia la ironía) y sale lo que sale...
Algún día se darán cuenta de que pagar programadores al peso al final no es la mejor estrategia.
#42 Creo que no me he explicado bien en mi comentarios anteriores, el problema no es solo la pasta, es la fiabilidad, tienes algo que funciona testeado durante X años, cambiarlo es un riesgo muy elevado, asi que simplemente alargamos lo inevitable, cuando el mundillo de COBOL se jubile y los que estan aprendiendo en las carnicas esos lenguajes tomen el mando, sera tarde para llevarse las manos a la cabeza.
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3283668/order/1">#1 los bancos que son los que más material en COBOL tienen por lo visto ya lo han intentado, pero terminaron dándose cuenta de que es aún mucho más caro que pagarle un pastizal a los cuatro que aun trabajan con ese lenguaje, y que además portar todo a C++ con calidad no puedes contratar a las cárnicas habituales ya que se necesitan principalmente programadores con experiencia ya que los juniors de los que se nutren esas cárnicas como les pongas a trabajar en C o C++ te arman un estropicio, así que lo que hacen es crear algunos modulillos en C#(.NET) y Java (no les pongas lenguajes más complejos a los mocosos de hoy en día porque no saben gestionar los recursos y a muchos les explota la cabeza si tienen que tratar con eso, aunque sea a costa de perder mucha eficiencia y optimización) que se comunican con su viejo código COBOL que es como una caja negra que ni ellos mismos saben cómo funciona, pero les funciona Básicamente, los bancos son unos ratas como para gastar lo que hace falta en modernizarse.. hasta el otro día seguían usando Windows XP en los cajeros, y supongo que aún habrá muchos que seguirán así..
#4 Lo que ocurre que el coste de migrar toda la informática de un banco de una plataforma a otra que no tiene nada que es costosísimo.
Se puede hacer y algún banco que otro lo hizo, pero el número de aplicaciones que hay que convertir es inmenso, y dar el salto de un sistema al otro sin detener el funcionamiento es una locura.
Software AG se encargó de pasar la informática del banco Espirito Santo desde una plataforma IMB a una tipo UNIX. De esto hace ya bastantes años.
Sabía que debía aprender COBOL, pero no bajo estás circunstancias...
#12 porqué cada vez escasearan más el personal calificado ergo cada vez será más caro de mantener?
#39 cc -Wall -Werror -pedantic
#120 Para sumar, restar, multiplicar y dividir que es para lo que se usan....no, ninguna mejora.
A mi me encanta que sigan los lenguajes como el Cobol. Es bonito. Llevo oyendo eso de que va a desaparecer 25 años y si me sale una oferta la de programador Cobol y me paguen 40.000€/año la cogeré. Menos dolores de cabeza.
#31 y por pasta, que mira la que ha liado el MAX de Boing por querer ahorrarse la certificación de nuevos componentes.
#86 #68 #48
Fortran es casi tan arcaico que COBOL, estamos en la misma.
numpy es una extensión del lenguaje, hacemos trampas
R, tal vez se le acerque, pero desconozo que tal funciona como lenguaje "normal" imperativo que acceda a bd, cosa que COBOL no hace del todo mal.
#74 C++ lleva unos 30 años actualizándose y el estándar de hoy parece un lenguaje completamente distinto al de entonces.
#c-4" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3283668/order/4">#4 cobol es un lenguaje anticuado. Si quieres comparalo con C. Como ha evolucionado/mutado en C++ o C#. Cobol sigue igual es lento de programar y no tiene estructuras de datos avanzadas.
Y eso que es robusto... un lenguaje que no evoluciona tiene fallostanto en al arquitectura de diseño seguro. Como pasa en C con las asignaciones en la pila de memoria.
#4 Me hizo recordar que fui a un banco diciendo que mi saldo no cuadraba. La que me atendió no me creía, hasta que con calculadora en mano le mostré que tomando el saldo antiguo y sumando los ingresos y restando los egresos del reporte que había sacado del "robusto, fiable y a prueba de fallos" software bancario en verdad no cuadraba. Con el tiempo lo arreglaron. No soy cliente asiduo de bancos, ni de productos financieros, pero me he topado con algunos errores. Conclusión: Ten bien guardados los extractos y certificados.
#c-25" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3283668/order/25">#25 Asi que amazon y google funcionan con cobol...de lo que se entera uno , oiga.
Yo sufri un par de años con cobol antes de pasar al delphi , durante el cambio de siglo, y ni jarto vino vuelvo a aquel cenagal. Ya he pasado por tantas cosas que ahora ya pienso retirarme con el c# y algo de python... a no ser que go y rust al final consigan ser de adopcion mayoritaria, cosa que de momento dudo.
#4 Es como los aviones, incluso algunos modernos, usan procesadores 80286 de IBM porque son los que menos fallan.
#4 Una pregunta o idea. ¿Y si en lugar de pensar en cambiar a otros sistemas se cambia el COBOL? el último estándar es de 2014 ¿Correcto? y si se mantiene la compatibilidad pero se le añaden otras capacidades propias de otras cosas más modernas de forma que pueda seguir leyendo con seguridad lo que no se quiere cambiar pero se puedan llamar procedimientos en lenguaje más moderno y con más capacidades ampliándolo.? Puede ser un lio terrible si no se distingue bien y debería de diseñarse un camino pero tal vez... Y no haría falta migrar todo...
#5 Mi estimado.Tal vez no lo sepa pero los papiros a través de la moderna técnica de los palimpsesto ya desde el siglo VI ,producto de la crisis del papiro, se reconvirtieron a través de técnicas de borrado por raspado y regrabado.
De hecho esta exitosa técnica unido al pergamino y la vitela garantizaron el registro portable de los eventos durante miles de años hasta que un diabólico invento chino llamado actualmente PAPEL allá por el siglo VIII empezó la invasión de Europa.
El golpe de gracia lo dieron esos hijos del diablo, los arabes, que en la localidad de játiva construyeren una fabrica de papel en el año de nuestro señor 1056.
Si estudiamos la etimología de la diabolica palabra "PAPEL" vemos con profundo horror que viene del catalán PAPER.
Todo esto demuestra un milenario complot Chino-Arabe-Catalan, seguramente no ajeno a la ausencia de programadores de COBOL.
#2 Has dicho "ano" ....
#87 Pues si, y se llama Ekranoplano. https://es.wikipedia.org/wiki/Ekranoplano . No te lo tomes a mal, era por seguir el chiste.
#33 Que los bancos y aseguradoras usen mainframes, COBOL y DB2 es más un lock-in que se sacó de la manga IBM que una utilidad real hoy en día. Si hoy tuvieras que iniciar cualquier servicio de esos desde cero jamás escogerías esas tecnologías así que decir que son las mejores que puedes usar para construirlo no es verdad, el problema es que si quieres salir ahora tienes que pagar el precio de ese lock-in de 50 años, eso no pasa con otros lenguajes, por ejemplo Fortran siendo de la misma época sigue teniendo aplicaciones perfectamente válidas hoy en día en matemáticas y simulaciones físicas.
Y el número de transacciones también es otra farsa, si fuera así las bolsas usuarían COBOL y mainframes, pero no lo hacen porque hay mejores soluciones para alto volumen de transacciones y baja latencia, y antes de eso tampoco lo hacían usaban cosas como SPARC, y no creo que nadie niegue que una orden en bolsa requiere mucha más precisión y velocidad que cualquier otra transacción que te puedas imaginar.
Además de eso en todos los bancos que he trabajado siempre acaban teniendo sistemas de reconciliación de la parra para todo porque salen errores cada dos por tres en las transacciones entre ellos de todo tipo.
#35 no todo se arregla con dinero, son sistemas que han evolucionado durante décadas, con millones de líneas de código, y que siguen evolucionando.
Para poder migrar todo, tienes que replicar toda esa funcionalidad que ha tardado décadas en hacerse, pero eso no es todo, mientras haces eso, la funcionalidad ha seguido evolucionando, es una carrera de fondo.
#29 serán de Intel
#56 Ya trabaje con esas tecnologias, COBOL, Lotus Notes y mierdas del estilo, y al final he acabado abrazando el odiado Java.
No merece la pena lo que te paguen por esas tecnologías, es pegarse hostias contra un muro durante X horas, sin información, sin comunidad, tu un manual de mierda es lo único que tienes a mano.
Por cierto por 50k en remoto te pones a programar muchas cosas que no generen esa frustración, deberías de dejar el sector de las cárnicas.
#6 lo que pasa es que a un programa que lleva corriendo 30 años... 30 años??
Espero que seas mejor programando (o lo que sea que hagas para vivir) que contando los años que han pasado desde 1960.
"...la realidad es que casi todos los sistemas que requieren gran capacidad de procesamiento por lotes (Batch), tanto las entidades bancarias como otras grandes empresas con sistemas mainframes utilizan COBOL. Esto permite garantizar la compatibilidad de los sistemas antiguos con los más modernos, así como tener la seguridad de que el lenguaje es perfectamente estable y probado".
En lo de la duda acerca del Zero Failure; estoy de acuerdo contigo. Porque, si bien al IDE original es muy posible que ya se le hayan encontrado todos los bugs; como se siguen escribiendo sobre 5.000 millones de líneas de código en COBOL cada año (algunas en una cosa que se llama Eclipse... que hace tiempo que no veo, pero que se que se sigue usando...); para mantener la retrocompatibilidad con otros programas más antiguos que corren en mainframes, siempre pueden aparecer nuevos bugs.
Sobre todo si esas nuevas líneas anuales las introducen desde Eclipse o NETCobol... donde casi seguro están escribiendo en Java.
#158 En efecto, las 2 ciudades-provincia que acaparan el trabajo IT.
#13 yo como informatico tengo la regla 0
"no dejes que algo deje de funcionar por no tocarlo"
#27 El problema es tener una mierda arcaica por no querer gastarte dinero.
Tu tienes un nokia6310 que no fallaba o un smartphone que apenas le dura un día la bateria? no hay mas preguntas señoria.
#36 Respecto al comentario de los telefonos, con COBOL quieres recibir llamadas y tener una alta disponibildiad del servicio, con un smartphone puedes hacer mil cosas, la alta disponibilidad es secundaria, por cierto podrías pillar un cargador portatil, pero asegurarte siempre de tener un enchufe cerca... lo veo jodido.
Los bancos pagan millonadas a lo que saben que funciona, DB2 es una mierda mas grande que mi cabezón, pero en ciertos sistemas es muy arriesgado el cambio, por eso van a ir pegando patadas hacia delante hasta que la cosa no aguante mas.
Respecto al tema de la pasta, muchas empresas se gastan casi todo el presupuesto del departamento de IT en licencias como las de SAP, porque al final sabes que no falla, aunque la UX sea una mierda, y sea carisimo de mantener.
#47 Por ejemplo, eliminar el espaciado. Las etiquetas de las divisiones son bastante descriptivas para el compilador y, de ser al caso, añadir en el lenguaje etiquetas que sustituyan las tabulaciones obligatorias. Ya soporta clases, hasta dónde yo sé.
#1 Hasta Arturito, R2D2, está programado en COBOL.
Y eso que vive en una galaxia muy, muy, muy, muy, muy, lejana.
Este cómic siempre me da ganas de aprender Cobol
#1 Es mejor estar callado....
Bancos, seguros,... fueron los pioneros y programaron en Cobol que es un lenguaje sencillo y muy estable, no falla. Sustituir millones de lineas de codigo supondria mucho dinero, para no obtener ninguna mejora.
Y me parece muy bien que le paguen un paston a la gente de Cobol y luego tengamos gente con .NET o java cobrando 900 euros.
#39 El mejor lenguaje para gestión empresarial nunca inventado y nunca inventable.
Aunque sea prehistórico y aunque todos lo estemos abandonando precísamente por eso.
No se le da bien hacer cositas monas en un móvil, pero para llevar una contabilidad o una gestión de pedidos...
#1 Todos los que saben COBOL están en el grupo de riesgo, por decirlo de alguna manera, pero vamos... no del grupo de los que se van al paro precisamente, los que quedan cobran una pasta.
#35 Es arcaica porque tu lo dices.
Soluciona un problema: Si
Cuesta menos mantenerlo que hacerlo de 0: Si
Mejora algo la tecnología actual: No.
#19 un jefe de proyecto me dijo una vez que documentar el código era contraproducente porque probablemente ese código hacía cualquier cosa menos lo que decía el comentario
#1 la civilización moderna no es más que una farsa ridícula.
#1 Pues cuando te enteres que tu dinero en el banco está gestionado por programas en Cobol vas a flipar.
Migrar un programa con varios millones de lineas de código en el que el más mínimo bug te puede hacer perder muuucho dinero te hace plantearte si realmente necesitas migrar un código que funciona bien desde hace décadas.
#27 "Eso no es problema del lenguaje, es problema de los planes de estudio de las carreras, que deberían incluir cosas antiguas porque siguen siendo de utilidad"
Cuidado, porque si miras un plan de estudios actual de cualquier ingeniería informática, de software, de teleco, etc. te darás cuenta de que C y C++ se siguen dando por muy antiguos que sean, ya que aportan unas enseñanzas que COBOL no lo hace.
Por otra parte, el hecho de que sean necesarios programadores de COBOL para momentos puntuales y empresas puntales no es como para que ahora en las universidades o en los ciclos formativos tengan que volver a enseñarlo de nuevo, más aún a sabiendas de que conociendo otros lenguajes como C o Java puedes aprender rápidamente. Otro cantar sería con Haskell, Lisp, y por el estilo.
#38 Ahora no se como estaran, pero hasta hace unos años la nasa compraba estos procesadores en ebay.
#14 ¿Han actualizado el esquema de la base de datos? Porque si es así, es el infierno sobre la tierra, porque hay que hacer la tarea más penosa en informática: la migración de datos.
#17 Yo me las he tenido que ver con los mortíferos PERFORM .... THRU
#37 El nick te lo pusiste pensando en el trabajo, supongo
¿Soñando con emular "Un día de furia"?
#4 E inmantenible.
Prácticamente ningún programador joven quiere aprender COBOL.
#7 R?
#68 #7 Numpy?
#17 el experto no documenta, que luego contratan monos para trabajar por 900 leuros y los echan
#143 Premio!!
Lo mejor es que la gentuza que pensó eso a abandonó el barco hace tiempo.
#31 O sea, son más fiables, por X razones, pero son más fiables.
De todos modos hablo de la fiabilidad de la arquitectura, este micro salió en el 82, dudo que los aviones de ahora usen micros fabricados en los 80, pero usan la misma arquitectura, que es más fiable porque es mas simple su fabricación, 134.000 transistores del 286, frente a los 2600 millones del i9, uno está fabricado en 14nm y el otro 90nm.
EN los 80 fabricar en 90nm tendría su complejidad, pero ahora mismo no. De ahí su uso en sistemas que tienen que ser 100% fiables.
#1 COBOL es extremadamente seguro y estable. Todos los bancos que yo sepa lo usan.
#70 de los que están en España, creo que todos menos ING.
#84 Joe, no sabía eso.
#80 es que el as400 nunca será reemplazado por nada, porque no hay nada como as400
#149 Fortran... Perdón por los dedazos
#7 ¿fortram?
#164 Disculpa, no quería pareces maleducado y lo fui. Si deseas seguir con el hilo, gustosamente debatiré -o investigaremos los dos -- lo que gustes. Vuelvo a repetir: perdón si te sentiste molesto con mi respuesta, tendrías todo el derecho del mundo a estarlo porque fui manejé el asunto con bastante torpeza.
#173 De hecho creo que saliste defendiendo COBOL porque yo no fui capaz de explicarme bien así que no te disculpes.
No quise decir que ese lenguaje no sea robusto o fiable. Quise decir que el resto de lenguajes mainstream para transacciones de negocios o cualquier otra operación que requiera asincronía, concurrencia etc son tan fiables como COBOL, y por lo tanto si COBOL sigue utilizándose masivamente en lugar de lenguajes más jóvenes (en los que da gusto programar, no como en COBOL) entonces probablemente los tiros vienen por otro lado y no por fiabilidad (por pura inercia como comentaba antes en este hilo).
#36 Y hablando de pasta, las licencias de Cobol (Microfocus casi seguro) tampoco son baratas.
Me hace gracia por otro lado que hables de pasta habiendo puesto de ejemplo a Google y Facebook, que tomaron las decisiones que tomaron justamente porque empezaron sin un duro...
Y oye, que justamente por haber tenido que empezar sin pasta escogieron componentes estándar y baratos, y es lo que luego ha propiciado que se desarrolle toda una infraestructura distribuida del copon.