Actualidad y sociedad
383 meneos
2901 clics
El estado de New Jersey necesita urgentemente programadores de COBOL [EN]

El estado de New Jersey necesita urgentemente programadores de COBOL [EN]

Debido a la crisis sanitaria del COVID-19, el gobernador de New Jersey (USA) ha hecho un llamamiento para reclutar programadores de COBOL. Se necesitan con urgencia para mantener los sobrecargados sistemas de gestión de desempleo y en previsión a las posibles bajas de programadores, que en su mayoría son mayores de 50

| etiquetas: covid19 , cobol , new jersey
160 223 3 K 445
160 223 3 K 445
Comentarios destacados:                                  
#4 #1 La mayor parte de la Banca, en todo el mundo, sigue usando cobol: es robusto, fiable y a prueba de fallos.
«12
  1. 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 :troll:
  2. #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.
  3. #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..
  4. #1 La mayor parte de la Banca, en todo el mundo, sigue usando cobol: es robusto, fiable y a prueba de fallos.
  5. #4 también los papiros pero han pasado muchos años. Hace tiempo que deberían haber sabido que iban a faltar programadores.
  6. #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
  7. #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.
  8. Y yo con python
  9. #1

    No hay huevos.

    Encima, deben tener un lío de dependencias entre sistemas que da miedo.
  10. #1 la civilización moderna no es más que una farsa ridícula.
  11. #7 Y que pueda manejar índices de bases de datos casi infinitos.
  12. #1 piensas como informático y no como empresario.
    Si el software funciona ¿Para que. As a rehacerlo con el coste que conlleva?
  13. #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! :troll:
  14. #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
  15. #7

    Y luego usar coma fija con dos decimales para todo.
  16. #5 no faltan programadores, falta dinero sobre la mesa .
  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.
  18. #13 yo como informatico tengo la regla 0
    "no dejes que algo deje de funcionar por no tocarlo"
  19. #17 documenque?
  20. #17 Yo me las he tenido que ver con los mortíferos PERFORM .... THRU
  21. Sabía que debía aprender COBOL, pero no bajo estás circunstancias...
  22. #6 parte de que COBOL, si no recuerdo mal (lo estudié ara como 30 años), es muy estricto
  23. #12 porqué cada vez escasearan más el personal calificado ergo cada vez será más caro de mantener?
  24. #13 esa regla es de administración de sistemas, no de programación 8-D
  25. 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).
  26. A la mierda el karma, he votado antigua
  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.
  28. #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.
  29. #4 Es como los aviones, incluso algunos modernos, usan procesadores 80286 de IBM porque son los que menos fallan.
  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
  31. #29 Los usan porque ya se saben todos los bugs conocidos, no porque fallen menos (una pequeña diferencia)
  32. #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.
  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.
  34. ¿Cuánto están dispuestos a pagar?
  35. #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. #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.
  37. #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.
  38. #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.
  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.
  40. #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.
  41. #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.
  42. #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.
  43. #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.
  44. #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.

    Edit: Puse php por poner algo, yo soy de la vieja escuela: sólo Pascal Objects, C/C++ y, recientemente, C#, que estoy aprendiendo.
  45. #29 serán de Intel
  46. #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 (masterthemainframe.com/), falta que las universidades, FPs, academias, etc lo incluyan/mantengan en los planes.
  47. #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...
  48. #7 ¿fortram?
  49. #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.
  50. #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é.
  51. #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.
  52. #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.
  53. #52 El tiempo nos dirá quien tiene la razón, de momento en New Jersey se están cagando en la puta de oros.
  54. #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.
  55. #54 No me refería a eso, me refería al mantenimiento de sistemas obsoletos los cuales las nuevas generaciones no quieren aprender.
  56. #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.
  57. #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.
  58. #57 No trabajo en una cárnica. Cliente final. En "provincias" alcanzar 40K en cliente final ya es un hito.
  59. #37 El nick te lo pusiste pensando en el trabajo, supongo xD ¿Soñando con emular "Un día de furia"?
  60. Se esperan muchas bajas indefinidas.
  61. #22 Mis hojos!
  62. #16 ¿No eran bien pagados los programadores de COBOL o me llevan engañando mucho tiempo?
  63. #4 E inmantenible.

    Prácticamente ningún programador joven quiere aprender COBOL.
  64. Cobol es gran opción
  65. #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.
  66. #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. xD
  67. #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.
  68. #1 COBOL es extremadamente seguro y estable. Todos los bancos que yo sepa lo usan.
  69. #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.
  70. #39 cc -Wall -Werror -pedantic
  71. #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.

    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.
  72. #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.
  73. #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.
  74. #1 alguno me tomó por el pito del sereno cuando dije
    ...

    www.meneame.net/story/soy-programador-estas-son-mis-razones-apostar-le
  75. #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?
  76. COMOOOOOOORLLLL??

    digo

    COBOOOOOL?
  77. #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.
  78. Quizá lo difícil y costoso de cambiar sea el AS400
  79. #70 de los que están en España, creo que todos menos ING.
  80. #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í.. ;)
  81. #38 Ahora no se como estaran, pero hasta hace unos años la nasa compraba estos procesadores en ebay.
  82. #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
  83. #68 #7 Numpy?
  84. #85, pues te vale entonces el barco con alas. Puede funcionar... más o menos. :-P
  85. #29 Boeing seguro que si usa esos 286 :troll:
  86. #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
  87. 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.
  88. #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 ;)
  89. #31 y por pasta, que mira la que ha liado el MAX de Boing por querer ahorrarse la certificación de nuevos componentes.
  90. #89, eso ya existe. Se llama interoperabilidad. Y viene prácticamente de serie con lenguajes modernos.
  91. Estas discusiones de programadores siempre son la monda. Parecéis los aficionados al furbo. Arrogancia, mezquindad, barriobajeros...
  92. #87 Pues si, y se llama Ekranoplano. es.wikipedia.org/wiki/Ekranoplano . No te lo tomes a mal, era por seguir el chiste.
  93. #93 Pues eso. Ampliar de esa forma el COBOL sin perder capacidades ni compatibilidad adquirir de las nuevas con ampliaciones ¿no?
  94. #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.
  95. #95, buena apreciación. De la misma época que COBOL, por cierto.
  96. #61 y los mios, acabo de coger cáncer de retina xD
  97. No pasaba nada y salía el berzotas del Trump riéndose de la gente
«12
comentarios cerrados

menéame