Seguro que muchos los conocéis de oídas. Son lenguajes de programación con solera, más de la generación de nuestros padres (e incluso abuelos) que de nuestra generación. COBOL se creó en 1959. Fortran, en 1957. Delphi, mucho más moderno, es de 1995. Todos ellos fueron muy populares en su día, pero lo más importante: siguen siendo críticos en diversos escenarios hoy en día.
#9#3 El mayor problema de los sistemas programados en COBOL, Natural y demás lenguajes para mainframe (telefónicas, banca, Renfe...) no es la complejidad del lenguaje, ya que son muy sencillos. El problema es mantener lo que existe. Suele haber muy poca documentación, los nombres de los módulos no suelen ser nada descriptivos y muchas veces los algoritmos son muy enrevesados, cuesta entenderlo.
Una de las razones es porque los viejos rockeros que los mantienen suelen saber únicamente de mainframes, y siempre temen que les sustituyan por alguien más joven y barato. Así que no optimizan código, no documentan y les sienta como una patada que les preguntes cosas.
Otra de las razones es que hace 30 años el software de facturaba por número de líneas codificadas, así que no es nada raro ver cosas como esta (y las he visto):
A=B
C=B
A=C
Y sí, aún se usa mucho software programado hace 30 años. Sobre todo porque son módulos críticos.
#18 Comprender ciertos códigos, formas, métodos de programación nadie dijo que fuera fácil, pero tampoco es para tanto. Además hay alternativas, si hay un función enrevesada a no más poder, pues seguramente sea mejor y más rápido reescribirla y punto, no tratar de entenderla.
Lo de que no "hay quien programe en ellos" es una falacia, por que si a una empresa le interesa solo tiene que pillar a un programador y que se ponga a ello, sepa COBOL o no.
Conozco un caso así que estuvo un año un programador para aprender el API y integración de una aplicación compleja para hacer un modulo también complejo (ya de por si con experiencia no le iba a ser fácil), y la empresa le pago gustosamente por que encontrar a alguien con experiencia los había contados y en grandes firmas, con toda probabilidad le salia bastante más barato pagar ese más largo desarrollo por que conllevaba aprendizaje que robar un programador con experiencia de alguna de esas firmas que se lo hiciera quizás en 1/3 del tiempo.
Sobretodo temas importantes y críticos, menos llorar y más pagar para que se formen y adquieran esa experiencia.
Ves ofertas de trabajo y las empresas quieren que ya sepas programar en mil cosas muy diferentes y tengas experiencia en todas ellas, un absurdo, que dejen de llorar y que contraten a gente sin tantas mierdas, con interés en solventar los problemas y aprender y que se formen en las necesidades de la empresa.
Sobre el código, si en treinta años ese código sigue así es que el problema no es el código si no el responsable de informática de esa empresa.
#22 No es tan fácil. No digo que no se pueda, pero sabrás por experiencia que no es lo mismo formarse en una tecnología que pegarse luego con ella, día a día. Si tengo que tocar el módulo principal de mi sistema de facturación, prefiero que lo haga alguien con experiencia. Puedo perder mucho dinero si comete algún error.
En cuanto a tu último párrafo, si yo soy el jefe de proyecto de, pongamos, las cuatro aplicaciones críticas de Telefónica, y me viene un programador diciendo que un módulo es complicado y que quiere reprogramarlo, las risas se iban a escuchar en toda la planta. Nadie se va a arriesgar a cambiar algo tan crítico y que funciona. Si doy el visto bueno y ese programador comete un error, la cabeza que rueda es la mía. https://m.xataka.com/historia-tecnologica/este-programa-informatico-de-1958-sigue-usandose-hoy-en-dia-sustituirlo-seria-demasiado-caro
#25 Eso sera si eres un mal programador o con costumbres bastante malas. Ya es bastante criticable hacer cambios sobre algo que conoces en producción (que todos lo hacemos o lo hemos tenido que hacer) como para aprender haciendo practicas sobre un sistema en producción, o meter algo no suficientemente probado (segun lo critico que sea) en una copia espejo en el principal.
En este caso te merecías ser lapidado.
Sobre mi ultimo párrafo observa que no he dicho programador si no responsable de programación, que si no quedaba claro me refería al jefe del proyecto.
Si no evolucionas el codigo o tienes paralelamente en modo prioridad baja en recamara esa posibilidad luego cuando se te junte, y los problemas de incompatibilidades y demás vienen los lloros.
Pues bien, según el artículo de marras, ese programa es tan complejo y crucial que sigue funcionando hoy en día de la misma forma que hace 60 años. Se supone que sustituirlo sería demasiado costoso. El programa de marras se llama “Mechanization of Contract Administration Services” (MOCAS) se escribió dos años antes de que COBOL estuviese aprobado como lenguaje, inclusive. En un principio el programa requería de tarjetas perforadas porque no había terminales como las que ahora existen.
Sin embargo, con los años el sistema se adaptó a los monitores de fósforo verde “óptico”, los cuales pueden verse en terminales de las aerolíneas en los aeropuertos, por ejemplo. Hoy MOCAS se ha hecho más utilizable pues se ha conectado a una aplicación web. De acuerdo con lo que dice el artículo, se gestionan 1.3 billones (en español) de dólares y 340 mil contratos. El servidor en el que se ejecuta actualmente es un servidor IBM 2098 E-10 de 2008 con 8 GB de RAM de proceso es de 398 MIPS (millions of instructions per second).
Pero pensemos, ¿puede ser cierta semejante historia? Suena fascinante y mediáticamente muy atractiva una narración al respecto, pero pensemos: ¿Podía un sistema que se escribió en 1958, para una computadora que difícilmente podría tener 1 Megabyte de memoria (y créanme, estoy exagerando) ser tan complejo y manejar esa cantidad de datos? Vamos, que ni siquiera las cintas magnéticas, que era uno de los dispositivos más usados podían siquiera guardar cantidades de datos que hoy nos parecen ridículas (20 Megabytes).
Pero supongamos que el programa se “actualizó” para que corriera en una máquina con 8GB, cuestión que para los estándares actuales es una computadora pequeña en el mejor de los casos. Pero además, si tomamos en cuenta que es un programa del gobierno estadounidense, que gasta además muchos miles de millones para mandar naves al espacio profundo, ¿no podría invertir en una computadora muy rápida para este crítico programa? ¿Cuánto es costoso en términos de gobierno? ¿No quiere Trump poner un muro que costaría 20 mil millones de dólares? ¿Podría costar un programa de computadora, por más crítico que sea, semejante cantidad?
Por otra parte, pensemos si de verdad sería muy costoso sustituir este programa. Facebook tiene 1000 millones de usuarios y maneja no sé cuantos terabytes por mes. En esencia la red social es un manejador de una base de datos en donde hay un número enorme de interrelaciones entre los registros.
Youtube gestiona miles de millones de videos por día ¿Y alguien dice que sería muy costoso reemplazar un sistema que maneja unos 350 mil contratos? ¿Es que no existe grupo de programadores que pudiesen escribir en uno de los tantos lenguajes modernos una versión que sustituyera una viejísima versión de 1958? Vamos, todo el artículo cae en una fantasía digna de estos sitios de noticias falsas como El Deforma, pero en este caso no lo es, es un artículo serio aparentemente. En el fondo artículos así desinforman y mitifican el cómputo. Ridículo asunto, a todo esto.
#22 Quizás tampoco puedas reescribirla si no sabes qué hace y menos aún si no sabes qué debería hacer. En el peor de los casos ni siquiera será una función (en un sentido matemático) sino que hace cosas que no debería hacer entre medias. Solo quería decir lo obvio, no siempre será tan fácil.
En cualquier caso muchas veces es mejor y fiable empezar de 0, sobretodo con temas antiguos, testearlo, probarlo y actualizarlo, han tenido años para hacerlo.
Por muy critico que sea en algún momento hay que dar el paso, por que te puede saltar también un problema critico que nadie sepa arreglar. Sin prisas, trabajando paralelamente a otros proyectos ya que el otro funciona y probarlo con tiempo y tiempo de mil maneras, pero tener ese cartucho.
El si funciona no lo toques suele ser un buen dicho, pero todo tiene puntualizaciones. Y 20 años con el mismo codigo sin tocarlo y sin preparar una alternativa por que funciona al final va a acarrear más problemas si o si.
#18 En definitiva, lo que hay es mucho morro y todo se resume en:
1º No quieren pagar un profesional experimentado, que ya por edad y fijación laboral para traerlo van a tener que soltar una buena pasta
2º No quieren contratar a un joven o no tan joven y que se forme para el trabajo que necesitan.
Luego sacan una noticia así esperando que algunos jóvenes se formen en casa en unos lenguajes poco usados esperando encontrar algun trabajo en ese nicho, para ellos ahorrarse
la pasta de la formación, y luego evidentemente para pagarles una mierda por que son jóvenes.
Esta es la mentalidad cárnica en españa, sobretodo en programación, eso no pasa en otras profesiones, un mecanico aprende en el trabajo y lo forman, y si hay que reparar un motor antiguo el tiene conocimientos de mecanica de motores como un programador de programación, y si hay que meterse en motor antiguo que funciona de diferente forma o es un fiasco de diseño pues que vea como funciona y aprenda sus debilidades y si es posible que las corrija.
¡Qué dilema!
- Ser un programador senior, experto en Java, C++, implementación Web, ASP, .NET orientado a objetos, Cloud programingn, etc. y cobrar 800€/mes en una cárnica (y gracias porque "en la puerta hay una docena esperando por un puesto")
- O ser un viejo rockero experto en Cobol por 100€/hora.
#7 he oido varias veces la misma historia de gente que cuando le preguntan si sabe COBOL responde que no (mintiendo) porque quiere evitar que le encasillen en proyectos "legacy" y ya no salir de ahí nunca más
#c-26" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2766172/order/26">#26 Yo he programado en Delphi, C++ (Borland, MS y QT), C# (en MS y algo en Linux con mono) y Java
El más complejo era C++ (por lo enredado del lenguaje a veces) . Pero en cuanto a jerarquía de clases se daban la mano Delphi y C++ (en el caso de C++ Builder era la misma). El más productivo con diferencia era Delphi (y el más fiable...).
Java ... pues como siempre un burro con la F de Ferrari en la frente.
COBOL y Delphi puede, pero Fortran ni de broma, más bien ha quedado reducido a un dominio específico, el de aplicaciones matemáticas, pero sigue siendo usado y desarrollado, hasta lenguajes más "modernos" creados para el mismo dominio como R tienen partes hechas en Fortran.
Yo he programado en Fortran, Ada, Pascal y Prolog. En Cobol ni idea (aunque he ayudado a detectar errores a desarrolladores) pero si en Assembler de Mainframe.
Soy un dinosaurio, lo sé.
#16 Fortran no (es facilon), Cobol ni idea, delphi si tiene mas calado. Al ser orientado a objeto y muy extensible (vcl) el problema puede no estar en el lenguaje en sí si no en los objetos del programa o vcls (que había cada engendro...).
#20 Fortran reconozco que es el que menos conozco, pero no me pareció complicadísimo. Es un lenguaje imperativo de alto nivel que no parece entrañar especial complicación, pero insisto, reconozco que lo conozco menos. Cobol sí lo conozco es muy fácil como lenguaje y Delphi es parecido a Pascal; no tiene nada especialmente difícil.
#23 recuerdo que trabajé con eso hace mucho tiempo, aunque a nivel muy básico. Seguramente tengas razón, pero tampoco creo que sea una complicación extrema. Dudo muchísimo que sea más complicado programar en Delphi que en C++, por ejemplo.
Pues ni que fuera tan difícil. Delphi estaba bien hice algún programa sencillo en su momento y Fortran no hace muchos años adapté a C parte del código de una librería hecha en Fortran y no se puede decir que sea algo raro. Pero como cualquier otro lenguaje.
En el mismo grupo está el RPG. No son lenguajes complicados, porque tienen un reducido numero de instrucciones. Hacen muy bien el trabajo, aunque hoy en día ha otras herramientas que pueden hacer la misma función. El problema es que como dice el artículo cada vez quedan menos programadores para mantener lo que ahora está en marcha y nadie tiene interés en formarse en algo que que desconocen. Y además está el tema de que a las universidades Microsoft regala licencias de sus productos y en la "otra parte", IBM p.e., nunca se le ha ocurrido de de regalar licencias para fomentar su divulgación.
En multitud de administraciones, bancos y en empresas hay un montón de lineas de código que corren en estos lenguajes en procesos críticos, aunque la fachada visible sea Net, Java, etc.
El que esté dispuesto, tendrá trabajo asegurado para mantener, implementar nuevas funciones o sencillamente para migrar a otras plataformas.
Comentarios
Sera que no hay ningún joven al que pagarle 900€ para programe en ellos.
Esa generación aun sigue viva, lo que igual no te cobra una mierda.
En cualquier caso cualquier programador con un poco de experiencia variada se adapta a cualquier otro lenguaje sin mucha dificultad.
Personalmente tengo programado/modificado cosas en lenguajes que no conozco con muy poco dias de adaptación hasta hacerlo con cierta fluidez.
#3 Efectivamente. No veo el problema. Aunque COBOL es "algo diferente" tampoco es LISP.
#9 #3 El mayor problema de los sistemas programados en COBOL, Natural y demás lenguajes para mainframe (telefónicas, banca, Renfe...) no es la complejidad del lenguaje, ya que son muy sencillos. El problema es mantener lo que existe. Suele haber muy poca documentación, los nombres de los módulos no suelen ser nada descriptivos y muchas veces los algoritmos son muy enrevesados, cuesta entenderlo.
Una de las razones es porque los viejos rockeros que los mantienen suelen saber únicamente de mainframes, y siempre temen que les sustituyan por alguien más joven y barato. Así que no optimizan código, no documentan y les sienta como una patada que les preguntes cosas.
Otra de las razones es que hace 30 años el software de facturaba por número de líneas codificadas, así que no es nada raro ver cosas como esta (y las he visto):
A=B
C=B
A=C
Y sí, aún se usa mucho software programado hace 30 años. Sobre todo porque son módulos críticos.
#18 Comprender ciertos códigos, formas, métodos de programación nadie dijo que fuera fácil, pero tampoco es para tanto. Además hay alternativas, si hay un función enrevesada a no más poder, pues seguramente sea mejor y más rápido reescribirla y punto, no tratar de entenderla.
Lo de que no "hay quien programe en ellos" es una falacia, por que si a una empresa le interesa solo tiene que pillar a un programador y que se ponga a ello, sepa COBOL o no.
Conozco un caso así que estuvo un año un programador para aprender el API y integración de una aplicación compleja para hacer un modulo también complejo (ya de por si con experiencia no le iba a ser fácil), y la empresa le pago gustosamente por que encontrar a alguien con experiencia los había contados y en grandes firmas, con toda probabilidad le salia bastante más barato pagar ese más largo desarrollo por que conllevaba aprendizaje que robar un programador con experiencia de alguna de esas firmas que se lo hiciera quizás en 1/3 del tiempo.
Sobretodo temas importantes y críticos, menos llorar y más pagar para que se formen y adquieran esa experiencia.
Ves ofertas de trabajo y las empresas quieren que ya sepas programar en mil cosas muy diferentes y tengas experiencia en todas ellas, un absurdo, que dejen de llorar y que contraten a gente sin tantas mierdas, con interés en solventar los problemas y aprender y que se formen en las necesidades de la empresa.
Sobre el código, si en treinta años ese código sigue así es que el problema no es el código si no el responsable de informática de esa empresa.
#22 No es tan fácil. No digo que no se pueda, pero sabrás por experiencia que no es lo mismo formarse en una tecnología que pegarse luego con ella, día a día. Si tengo que tocar el módulo principal de mi sistema de facturación, prefiero que lo haga alguien con experiencia. Puedo perder mucho dinero si comete algún error.
En cuanto a tu último párrafo, si yo soy el jefe de proyecto de, pongamos, las cuatro aplicaciones críticas de Telefónica, y me viene un programador diciendo que un módulo es complicado y que quiere reprogramarlo, las risas se iban a escuchar en toda la planta. Nadie se va a arriesgar a cambiar algo tan crítico y que funciona. Si doy el visto bueno y ese programador comete un error, la cabeza que rueda es la mía.
https://m.xataka.com/historia-tecnologica/este-programa-informatico-de-1958-sigue-usandose-hoy-en-dia-sustituirlo-seria-demasiado-caro
#25 Eso sera si eres un mal programador o con costumbres bastante malas. Ya es bastante criticable hacer cambios sobre algo que conoces en producción (que todos lo hacemos o lo hemos tenido que hacer) como para aprender haciendo practicas sobre un sistema en producción, o meter algo no suficientemente probado (segun lo critico que sea) en una copia espejo en el principal.
En este caso te merecías ser lapidado.
Sobre mi ultimo párrafo observa que no he dicho programador si no responsable de programación, que si no quedaba claro me refería al jefe del proyecto.
Si no evolucionas el codigo o tienes paralelamente en modo prioridad baja en recamara esa posibilidad luego cuando se te junte, y los problemas de incompatibilidades y demás vienen los lloros.
https://www.unocero.com/2017/02/28/un-mito-absurdo-de-la-ingenieria-de-software/
Copio y pego parte:
Pues bien, según el artículo de marras, ese programa es tan complejo y crucial que sigue funcionando hoy en día de la misma forma que hace 60 años. Se supone que sustituirlo sería demasiado costoso. El programa de marras se llama “Mechanization of Contract Administration Services” (MOCAS) se escribió dos años antes de que COBOL estuviese aprobado como lenguaje, inclusive. En un principio el programa requería de tarjetas perforadas porque no había terminales como las que ahora existen.
Sin embargo, con los años el sistema se adaptó a los monitores de fósforo verde “óptico”, los cuales pueden verse en terminales de las aerolíneas en los aeropuertos, por ejemplo. Hoy MOCAS se ha hecho más utilizable pues se ha conectado a una aplicación web. De acuerdo con lo que dice el artículo, se gestionan 1.3 billones (en español) de dólares y 340 mil contratos. El servidor en el que se ejecuta actualmente es un servidor IBM 2098 E-10 de 2008 con 8 GB de RAM de proceso es de 398 MIPS (millions of instructions per second).
Pero pensemos, ¿puede ser cierta semejante historia? Suena fascinante y mediáticamente muy atractiva una narración al respecto, pero pensemos: ¿Podía un sistema que se escribió en 1958, para una computadora que difícilmente podría tener 1 Megabyte de memoria (y créanme, estoy exagerando) ser tan complejo y manejar esa cantidad de datos? Vamos, que ni siquiera las cintas magnéticas, que era uno de los dispositivos más usados podían siquiera guardar cantidades de datos que hoy nos parecen ridículas (20 Megabytes).
Pero supongamos que el programa se “actualizó” para que corriera en una máquina con 8GB, cuestión que para los estándares actuales es una computadora pequeña en el mejor de los casos. Pero además, si tomamos en cuenta que es un programa del gobierno estadounidense, que gasta además muchos miles de millones para mandar naves al espacio profundo, ¿no podría invertir en una computadora muy rápida para este crítico programa? ¿Cuánto es costoso en términos de gobierno? ¿No quiere Trump poner un muro que costaría 20 mil millones de dólares? ¿Podría costar un programa de computadora, por más crítico que sea, semejante cantidad?
Por otra parte, pensemos si de verdad sería muy costoso sustituir este programa. Facebook tiene 1000 millones de usuarios y maneja no sé cuantos terabytes por mes. En esencia la red social es un manejador de una base de datos en donde hay un número enorme de interrelaciones entre los registros.
Youtube gestiona miles de millones de videos por día ¿Y alguien dice que sería muy costoso reemplazar un sistema que maneja unos 350 mil contratos? ¿Es que no existe grupo de programadores que pudiesen escribir en uno de los tantos lenguajes modernos una versión que sustituyera una viejísima versión de 1958? Vamos, todo el artículo cae en una fantasía digna de estos sitios de noticias falsas como El Deforma, pero en este caso no lo es, es un artículo serio aparentemente. En el fondo artículos así desinforman y mitifican el cómputo. Ridículo asunto, a todo esto.
#22 Quizás tampoco puedas reescribirla si no sabes qué hace y menos aún si no sabes qué debería hacer. En el peor de los casos ni siquiera será una función (en un sentido matemático) sino que hace cosas que no debería hacer entre medias. Solo quería decir lo obvio, no siempre será tan fácil.
#30 Nunca dije que fuera fácil pero se puede.
En cualquier caso muchas veces es mejor y fiable empezar de 0, sobretodo con temas antiguos, testearlo, probarlo y actualizarlo, han tenido años para hacerlo.
Por muy critico que sea en algún momento hay que dar el paso, por que te puede saltar también un problema critico que nadie sepa arreglar. Sin prisas, trabajando paralelamente a otros proyectos ya que el otro funciona y probarlo con tiempo y tiempo de mil maneras, pero tener ese cartucho.
El si funciona no lo toques suele ser un buen dicho, pero todo tiene puntualizaciones. Y 20 años con el mismo codigo sin tocarlo y sin preparar una alternativa por que funciona al final va a acarrear más problemas si o si.
#34 creo que no eres consciente del impacto de meter mano en esos entornos
#36 Entornos considerablemente más complejos hay gente metiendo la mano hoy en dia que un programa de 1956 que corria en ordenador tan limitado.
#18 En definitiva, lo que hay es mucho morro y todo se resume en:
1º No quieren pagar un profesional experimentado, que ya por edad y fijación laboral para traerlo van a tener que soltar una buena pasta
2º No quieren contratar a un joven o no tan joven y que se forme para el trabajo que necesitan.
Luego sacan una noticia así esperando que algunos jóvenes se formen en casa en unos lenguajes poco usados esperando encontrar algun trabajo en ese nicho, para ellos ahorrarse
la pasta de la formación, y luego evidentemente para pagarles una mierda por que son jóvenes.
Esta es la mentalidad cárnica en españa, sobretodo en programación, eso no pasa en otras profesiones, un mecanico aprende en el trabajo y lo forman, y si hay que reparar un motor antiguo el tiene conocimientos de mecanica de motores como un programador de programación, y si hay que meterse en motor antiguo que funciona de diferente forma o es un fiasco de diseño pues que vea como funciona y aprenda sus debilidades y si es posible que las corrija.
No hay más historia, lo que hay es mucho cuento.
#3 Te equivocas. Se por experiencia que hay empresas que pagan UNA PASTA por profesionales con experiencia en Cobol.
#12 ¿en serio tienes tantos problemas para comprender lo que has leído?
#15 Y no esperes que entienda el código de otros mejor, no me extraña que prefieran mantener sus sistemas.
#31 jaja se me paso ese ZAS
¡Qué dilema!
- Ser un programador senior, experto en Java, C++, implementación Web, ASP, .NET orientado a objetos, Cloud programingn, etc. y cobrar 800€/mes en una cárnica (y gracias porque "en la puerta hay una docena esperando por un puesto")
- O ser un viejo rockero experto en Cobol por 100€/hora.
Normal que todos prefieran la primera opción ¿no?
#7 he oido varias veces la misma historia de gente que cuando le preguntan si sabe COBOL responde que no (mintiendo) porque quiere evitar que le encasillen en proyectos "legacy" y ya no salir de ahí nunca más
#10 cierto.... conozco a varios que les ha pasado... pero no quieren cambiar de empleo porque cobran más trabajando en Cobol que en otras cosas.
#7 ya estamos con la llorera de siempre.
Si cobras 800€ es que eres malo malo malo y te valoras cero.
Y Cobol en mainframes.
Delphi no es un lenguaje, es un IDE para programar en Object Pascal.
#19 Pero con apis propias que hay que conocer
Fortran se usa mucho en matemáticas.
#1 Y en ingeniería, en física... yo mismo lo uso e Intel saca sus compiladores y librerías MKL para C/C++ y Fortran.
#c-26" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2766172/order/26">#26 Yo he programado en Delphi, C++ (Borland, MS y QT), C# (en MS y algo en Linux con mono) y Java
El más complejo era C++ (por lo enredado del lenguaje a veces) . Pero en cuanto a jerarquía de clases se daban la mano Delphi y C++ (en el caso de C++ Builder era la misma). El más productivo con diferencia era Delphi (y el más fiable...).
Java ... pues como siempre un burro con la F de Ferrari en la frente.
Los grandes códigos de simulación del ITER están en Fortran.
COBOL y Delphi puede, pero Fortran ni de broma, más bien ha quedado reducido a un dominio específico, el de aplicaciones matemáticas, pero sigue siendo usado y desarrollado, hasta lenguajes más "modernos" creados para el mismo dominio como R tienen partes hechas en Fortran.
Yo he programado en Fortran, Ada, Pascal y Prolog. En Cobol ni idea (aunque he ayudado a detectar errores a desarrolladores) pero si en Assembler de Mainframe.
Soy un dinosaurio, lo sé.
La web de contactos "Adopta un tío" está programada en Fortran.
Editado.
Pues yo podría programar en ellos. No son lenguajes muy complejos y los utilicé en la universidad.
#16 Fortran no (es facilon), Cobol ni idea, delphi si tiene mas calado. Al ser orientado a objeto y muy extensible (vcl) el problema puede no estar en el lenguaje en sí si no en los objetos del programa o vcls (que había cada engendro...).
#20 Fortran reconozco que es el que menos conozco, pero no me pareció complicadísimo. Es un lenguaje imperativo de alto nivel que no parece entrañar especial complicación, pero insisto, reconozco que lo conozco menos. Cobol sí lo conozco es muy fácil como lenguaje y Delphi es parecido a Pascal; no tiene nada especialmente difícil.
#21 Delphi el problema no es Pascal, es la jerarquía de clases (grande de narices) que tenía (y los objetos habituales externos, como las rx...).
#23 recuerdo que trabajé con eso hace mucho tiempo, aunque a nivel muy básico. Seguramente tengas razón, pero tampoco creo que sea una complicación extrema. Dudo muchísimo que sea más complicado programar en Delphi que en C++, por ejemplo.
Pues ni que fuera tan difícil. Delphi estaba bien hice algún programa sencillo en su momento y Fortran no hace muchos años adapté a C parte del código de una librería hecha en Fortran y no se puede decir que sea algo raro. Pero como cualquier otro lenguaje.
Y el PL1? Es que nadie piensa en el PL1?
Modula2
En el mismo grupo está el RPG. No son lenguajes complicados, porque tienen un reducido numero de instrucciones. Hacen muy bien el trabajo, aunque hoy en día ha otras herramientas que pueden hacer la misma función. El problema es que como dice el artículo cada vez quedan menos programadores para mantener lo que ahora está en marcha y nadie tiene interés en formarse en algo que que desconocen. Y además está el tema de que a las universidades Microsoft regala licencias de sus productos y en la "otra parte", IBM p.e., nunca se le ha ocurrido de de regalar licencias para fomentar su divulgación.
En multitud de administraciones, bancos y en empresas hay un montón de lineas de código que corren en estos lenguajes en procesos críticos, aunque la fachada visible sea Net, Java, etc.
El que esté dispuesto, tendrá trabajo asegurado para mantener, implementar nuevas funciones o sencillamente para migrar a otras plataformas.