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
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.
#17 documenque?
#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
#17 Yo me las he tenido que ver con los mortíferos PERFORM .... THRU
#17 el experto no documenta, que luego contratan monos para trabajar por 900 leuros y los echan
#5 no faltan programadores, falta dinero sobre la mesa .
#16 ¿No eran bien pagados los programadores de COBOL o me llevan engañando mucho tiempo?
#62 Pero como cada vez faltan mas, hace falta algo que aliente a la gente joven a formarse en cobol y eso es dinerito. Mucho dinerito.
#71 No, no es el dinerito. O no es solo el dinerito.
A la gente joven que sale de la universidad no le tira dedicarse a la informática del core de las empresas (por definición aburrido), le tira dedicarse a cosas más golosas, como juegos (en el mejor sentido, no solo en jugar), startups imaginativas donde inventar algo nuevo y demás.
En mi empresa lo estamos "disfrutando" un montón, aun pagando un sueldo competitivo con todas esas cosas y una aspiración de futuro.
#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.
#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.
#79 bueno cualquier mierdecilla con 1 año de experiencia que sepa negociar gana ya más que la media del país, eso hay mucha gente con carreras y masters que no lo va a conseguir en 10 años, por supuesto que me gustaría ganar más pero siendo realistas creo que esta bastante bien pagado en ciudades "grandes" y si con esta mierda se consigue implantar el teletrabajo y los puestos calientes ese dinero puede ser mucho más solo teniendo que ir a la "ciudad" un par de días a la semana
#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.
#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.
#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.
#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.
#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.
#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.
#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.
#43 Lo que hay que hacer es seguir formando a gente en Cobol (y en mainframe, y en ...).
IBM intenta informar y acercar el mainframe a los jóvenes (https://masterthemainframe.com/), falta que las universidades, FPs, academias, etc lo incluyan/mantengan en los planes.
#46 IBM es una empresa muy buena para unas cosas,y muy mala para otras, y formando gente es nefasta, eso si para esclavizarlos un 10/10.
#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.
#52 El tiempo nos dirá quien tiene la razón, de momento en New Jersey se están cagando en la puta de oros.
#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.
#54 No me refería a eso, me refería al mantenimiento de sistemas obsoletos los cuales las nuevas generaciones no quieren aprender.
#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.
#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.
#57 No trabajo en una cárnica. Cliente final. En "provincias" alcanzar 40K en cliente final ya es un hito.
#58 provincias es todo lo que no sea madrid y barcelona? conozco a gente cobrando cerca de eso sin mucha exp en cliente final, aunque todo depende de la provincia supongo.
#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.
#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.
#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.
#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.
#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.
#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.
#44 es que hay muy pocos sistemas transaccionales con millones de transacciones por segundo (igual ninguno). Y mucho menos en los bancos / aseguradoras / españoles. Dónde habrá seguro MySQL y sqlserver a cascoporro.
Al final se tiene que dividir el problema en partes más pequeñas para ser manejable, bien dividiendo por zonas geográficas, productos, o diferentes funcionalidades... Y cada una de estas partes se hará en el mejor de los casos en el mismo stack, pero hay que entender los grandes sistemas empresariales como un conjunto de subsistemas no como una mega aplicación en COBOL, dónde quedará el CORE de la app, pero el resto será en otras tecnologías.
En cuanto a la crítica de tecnologías no te digo más que hay muchas partes de Facebook hechas en PHP, no le veo que problema tiene.
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
#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.
#2 Has dicho "ano" ....
#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..
#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
#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
#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.
#37 El nick te lo pusiste pensando en el trabajo, supongo
¿Soñando con emular "Un día de furia"?
#59 La verdad que hay días que llego a la oficina con ganas de llevar un M16 y empezar a matar gente, no te lo voy a negar.
#67 Y esos son los días buenos
#30 y no te apetece emigrar a USA y cobrar un sueldo de 6 cifras?
#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
#14 yo trabajo en uno de los de escritorio q es tan estable q será de los últimos en migrarse... con suerte como tengo experiencia en web me moveré con el si no me acabo suicidando por los dichosos composites.
#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.
#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 La mayor parte de la Banca, en todo el mundo, sigue usando cobol: es robusto, fiable y a prueba de fallos.
#4 también los papiros pero han pasado muchos años. Hace tiempo que deberían haber sabido que iban a faltar programadores.
#5 Los papiros no son robustos, fiables y a prueba de fallos. COBOL sí.
#5 Todo depende de lo que quieran pagar. Si no encuentran programadores es porque no pagan suficiente. Tampoco encontrarían arquitectos, médicos, veterinarios, etc si les pagasen una mierda. Tampoco podrías comprar una barra de pan por 12 céntimos, como es lógico.
#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.
#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
#6 parte de que COBOL, si no recuerdo mal (lo estudié ara como 30 años), es muy estricto
#22 Mis hojos!
#61 y los mios, acabo de coger cáncer de retina
#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.
#39 cc -Wall -Werror -pedantic
#72 había leído -pandemic
#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...
#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.
#97 No, no se escribe en Java. Eclipse es un "editor" (perdonadme la aproximación) escrito en java, que se puede usar para escribir cualquier lenguaje usando los plugin adecuados.
Por ejemplo, yo lo usaba para escribir PHP. Y los ficheros generados, si quería, los podía mantener luego con el viejo y querido vi (vaaaaale, con el vim).
#6 "ya se le han detectado todos los bugs"
Coñe, por eso es fiable y "zero failure"
#4 Es como los aviones, incluso algunos modernos, usan procesadores 80286 de IBM porque son los que menos fallan.
#29 Los usan porque ya se saben todos los bugs conocidos, no porque fallen menos (una pequeña diferencia)
#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.
#38 Ahora no se como estaran, pero hasta hace unos años la nasa compraba estos procesadores en ebay.
#84 Joe, no sabía eso.
#84 Mis noticias era que estaban comprando los 386.
Para poder reemplazar los que se averiaban en las instalaciones realizadas.
Porque para lo que necesitaban hacer, eran mucho más que suficientemente potentes.
Y porque consumían muchísimo menos que uno moderno. Y eso en una nave espacial que se alimenta con placas es enormemente importante.
#38 tb hay q tener en cuenta q los micros viejos resisten mejor la radiación etc
#31 y por pasta, que mira la que ha liado el MAX de Boing por querer ahorrarse la certificación de nuevos componentes.
#92: No, por programar mal el MCAS y no decírselo a los pilotos (que el MCAS existe, ya no que falle).
El tipo de procesador en sí no es un problema, porque eso solo procesa lo que le digas.
#29 serán de Intel
#45 Otia. es cierto, no sé por qué puse IBM..
#29 Boeing seguro que si usa esos 286
#88 Ja ja ja, pillaron los que intel apartaba porque no pasaban el control de calidad
#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.
#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...
#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é.
#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.
#74 No creo que sea igual para nada porque no debería de requerir quitar cosas ni que los nuevos añadidos modifiquen u obliguen a modificar a un programa existente (o casi nada) manteniendo toda la compatibilidad. Por ejemplo Microsoft cogió su gwBasic (basica) y lo amplió con las estructuras etc del Algol (o copiando de este) haciendo un mix con el qbasic (quickbasic con el compilador y runtine) y funcionó... ma o menos
#85, pues te vale entonces el barco con alas. Puede funcionar... más o menos.
#87 No un barco con alas. Sino que puedas elegir si barco o avión para cada paquete que quieras transportar y te lo envíe por uno u otro
#89, eso ya existe. Se llama interoperabilidad. Y viene prácticamente de serie con lenguajes modernos.
#93 Pues eso. Ampliar de esa forma el COBOL sin perder capacidades ni compatibilidad adquirir de las nuevas con ampliaciones ¿no?
#96, mientras no lo tenga que hacer yo, ni en mi empresa, ni nadie a 100km de radio alrededor de donde esté yo, me parece bien.
#87 Pues si, y se llama Ekranoplano. https://es.wikipedia.org/wiki/Ekranoplano . No te lo tomes a mal, era por seguir el chiste.
#95, buena apreciación. De la misma época que COBOL, por cierto.
#155, muy flojillo tu comentario . #95 sí que dio en el clavo .
#74 C++ lleva unos 30 años actualizándose y el estándar de hoy parece un lenguaje completamente distinto al de entonces.
#74 Funcionan y se llaman hidroaviones
#47 En realidad eso ya se hace. El core de un banco suele correr con un planificador tipo ControlM y desde ahí se invocan jobs que a su vez llaman a programas en varios lenguajes. Comandos propios del OS, COBOL o Java por ejemplo. Y el online lo mismo, tienes tu CICS y desde ahi puedes llamar a todo tipo de programas.
#4 E inmantenible.
Prácticamente ningún programador joven quiere aprender COBOL.
#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.
#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.
#4 COBOL no es robusto, fiable ni a prueba de fallos. No más que cualquier otro lenguaje de hoy en día.
El uso extendido de COBOL en 2020 es por pura inercia:
- Hay demasiado código escrito en COBOL como para cambiarlo sin meterte en costes prohibitivos. El cambio va ocurriendo pero muy poco a poco, sobre todo en empresas muy grandes dónde el cambio es más lento.
- Los programadores de COBOL habitualmente sólo conocen COBOL, y no hay movimiento en el sector que obligue a las empresas a plantearse cambios.
#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.
#7 Y que pueda manejar índices de bases de datos casi infinitos.
#7
Y luego usar coma fija con dos decimales para todo.
#7 ¿fortram?
#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.
#48: ¿Fortram? Seguro que mola más que Forbus y Formonorail.
#7 R?
#68 #7 Numpy?
#86: Hasta que saquen "nombre de cierta serpiente constrictora" 4 y sea incompatible con 2 y 3. No doy nombres.
#1
No hay huevos.
Encima, deben tener un lío de dependencias entre sistemas que da miedo.
#1 la civilización moderna no es más que una farsa ridícula.
#1 piensas como informático y no como empresario.
Si el software funciona ¿Para que. As a rehacerlo con el coste que conlleva?
#12 porqué cada vez escasearan más el personal calificado ergo cada vez será más caro de mantener?
#23 ya, pero si piensas como empresario, o peor, como los ratas de los bancos, se trata de ir dándole patadas al problema hacia adelante, que ya le tocara a otro comerse el marrón cuando explote todo
#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!
#13 yo como informatico tengo la regla 0
"no dejes que algo deje de funcionar por no tocarlo"
#13 esa regla es de administración de sistemas, no de programación
#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.
#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.
#1 Hasta Arturito, R2D2, está programado en COBOL.
Y eso que vive en una galaxia muy, muy, muy, muy, muy, lejana.
#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.
#1 alguno me tomó por el pito del sereno cuando dije
...
soy-programador-estas-son-mis-razones-apostar-lenguaje-raro/c016#c-16
Soy programador y éstas son mis razones para apost...
xataka.com#1 relacionado: https://www.xataka.com/historia-tecnologica/este-programa-informatico-1958-sigue-usandose-hoy-dia-sustituirlo-seria-demasiado-caro-1
#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í..
#1 COBOL sigue estando en la banca en España
#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.
#1: ¿Y qué aportaría un lenguaje "moderno" respecto a uno que ha hecho un buen desempeño durante décadas?
A lo mejor el problema no es Cobol sino quienes se obsesionan por actualizar periódicamente cosas que no hay que actualizar, es como si tienes una máquina con tornillería Whitworth, la cambias a métrica, luego inventas otra rosca y la vuelves a cambiar, luego sacas otra con pasos ligeramente diferentes y no compatibles... y pretendes que las máquinas que usaran la primera se actualicen porque sí.
En mi opinión si Cobol era válido hace décadas, sigue siéndolo ahora, si lo han despreciado en ámbitos académicos es un problema de los ámbitos académicos, no de quienes implementaron un lenguaje que era, y sigue siendo, perfectamente válido.
A veces los que hacen los lenguajes de programación tienen una fuerte desconexión con la realidad, que a la mínima te sacan otro lenguaje (y pretenden que lo uses), te cogen un lenguaje y te sacan una segunda versión no compatible (no nombraré a cierta serpiente constrictora...), te cogen funciones y las marcan como "deprecated" porque ellos lo valen, y ala, te toca cambiar un código que hiciste y funcionaba perfectamente...
En programación se debería haber alcanzado hace cierto tiempo un grado de madurez técnica por el cual uno pueda usar una serie de herramientas, lenguajes y demás, y esté seguro de no tenerlos que cambiar al cabo de cierto tiempo, de la misma forma que si hace 30 años compras una máquina inglesa con rosca Withworth, aunque en España no se use mucho, puedes seguir poniéndola tornillos, y so hoy haces una máquina con rosca métrica, muy probablemente dentro de 200 años puedas seguir comprando tornillos para ella sin problema, y la Withworth posíblemente se pueda encontrar porque se usa en entornos anglosajones.
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).
#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.
Sabía que debía aprender COBOL, pero no bajo estás circunstancias...
Se esperan muchas bajas indefinidas.
Quizá lo difícil y costoso de cambiar sea el AS400
#80 es que el as400 nunca será reemplazado por nada, porque no hay nada como as400
COMOOOOOOORLLLL??
digo
COBOOOOOL?
Cobol es gran opción
La migración se puede llevar a cabo sin problemas. Yo he llevado a cabo varias de bancos y administración pública. Incluso partes de aplicaciones de farmacéuticas. Sólo tienes que pagar lo que vale a gente que somos profesionales. Buenos profesionales autónomos a 60 euros la hora.
No pasaba nada y salía el berzotas del Trump riéndose de la gente
¿Cuánto están dispuestos a pagar?
Estas discusiones de programadores siempre son la monda. Parecéis los aficionados al furbo. Arrogancia, mezquindad, barriobajeros...
Y yo con python