En el año 1959 el Departamento de Defensa de Estados Unidos junto con fabricantes tecnológicos de la época, crearon un lenguaje de programación, llamado COBOL...
#121 pues tienes razón, no permite mutar variables como en JS.
De todos modos, el duck typing es horrible para leer el código de otro i al de una una semana después de programarlo si no tiene type hints (y usas funciones, claro jaja)
Migrar código de hace sesenta años de una forma de pensar diferente como Cobol es tan caro que seguramente estén contratando y formando programadores en ese lenguaje.
Si es caro de migrar y tiene sesenta años, no es la aplicación de sastrerías martinez. Es una empresa donde hay dinero. ¿Para qué migrar cuando puedes contratar gente o incluso formarles?
No, la verdad es que no me acabo de creer la noticia.
#19 No es eso. El tema es que los sistemas en COBOL, son nichos muy pequeños.
Son programas que llevan tiempo sin recibir actualizaciones, al menos en sus capas más interiores. Llevan decadas contratando desarrolladores para llevar algunas funcionalidades a otros entornos. Pero eso es la periferia del programa. El núcleo no se toca y si en algún momento alguien decide una partida presupuestaria para hacer cambios será un sprint enormey largo para migrar a C++, Java o alguna cosa más moderna lo que hay e independizarlo del mainframe y su ecosistema: CICS, MQSeries, DB2,ME series. En algún momento parecía que esas tecnologías emergerían en UNIX. De hecho están soportadas en AIX, pero sigue siendo ser cauitivo de IBM, de su hierro y de su sistema operativo.
Yo no puedo hablar por los demás, pero no tengo ganas de ponerme a destinar como funciona un sistema arcano para re implementarlo en una arquitectura moderna, porque no es nada estimulante.
Un banco no entiende por qué tiene que pagar otro desarrolló para tardar años en tener que ya hace lo mismo que hace el programa que tiene y que está amortizado. El jefe de sistemas si lo entiende, pero los responsables de negocio no quieren pasar por ahí.
Conón profesional no tengo ganas de formarme para un proyecto que es un nicho diminuto y que parece que va a ser cancelado en cualquier momento. O no se o tenemos éxito y finaliza y tampoco nos necesitan.
#34 Cuidadin con cobol que tiene truquitos de sintaxis y cosas raras.
Eestoy pensando como las condiciones de los batch de MSDOS que tiene que tener el expacio e indexado justo que sino lo les gusta, y no recibes ningun error solo que nunca se da la condicion.
#1 Esque la lógica de las aplicaciones en COBOL (que la sintaxis la lee casi hasta un niño), no tiene nada que ver con cualquier metodología de progamación actual.
Verás, la mayoría de veces programar tiene más de entender el negocio que estás programando y los fundamentos de su CORE que de saber poner ifs, loops o return. Al fin y al cabo, un lenguaje de programación, es un idioma, que se puede comparar a ladrillos... y en cambio, con ese mismo ladrillo, lo mismo construyes una mansión, una catedral, una casa en el bosque o un rascacielos.
Pues aquí lo mismo... esto va de "arquitectura", y la arquitectura de aplicaciones implementadas en COBOL aparte de prehistóricas y nula documentación... en un mundo financiero que permite pràcticamente ningún error... es terrible, letal, poner a alguien que no comprende las repercusiones de poner o no un 0 o un null en un campo... puede cambiar absolutamente todo y tardar meses en poder depurar dónde està el error.
Vamos, es un problema de prehistoria funcionando en el siglo XXI, nadie se atreve a apagar dichos servidores, porque no hay equivalente que los reemplace, y a su vez, necesitan adaptar los cambios que imponen las legislaciones y leyes... en fin, un caos.
#1 Si quisieran pagar bien a un desarrollador bueno para que primero aprenda Cobol a un nivel de experto (un añito o dos como mínimo trabajando a saco), luego aprenda la aplicación sobre la que tiene que trabajar (a lo mejor medio año más), y luego haga los cambios que se necesitasen con todas las pruebas necesarias para asegurarse de que todo está bien y de que ningún banco va a petar...
Antes que eso preferirían pagar a un buen desarrollador de <lenguaje moderno> que reescribiera la aplicación desde cero.
Cualquiera de las dos opciones es mucho dinero que prefieren quedarse para bonuses de esos.
#1 No solo eso. He conocido un konton de empresas que han ofrecido proyectos de migracion de servicios existentes a otros lenguajes. Son baratos? No. Es mas barato seguir manteniendo la mierda que hay? Si. Es un problema de dinero no es un problema de los "programadores".
#21 Como que casi no se usan¿ Si el 90% de las grandes corporaciones tienen instalaciones mainframes? Cuando ves tu bonito cajero con Windows o Linux y una pantalla de botones y colores, detrás, posiblemente este un z16 manejando las transacciones realizadas, y tiene un razón de ser, estabilidad.
#77 Arquitectura prehistórica y nula, ole tus cordones, mira este video y me comentas que tiene de prehistórico y nulo el z/16 de IBM y luego vienes y me lo vuelves a contar.
Sistemas AS400, muchos años ha, si he tenido que toquetear alguno, y como digo... ninguna documentación dispuse en aquel momento (creo que se parece mucho a nula), y todo lo que fuese "modificar" algún cálculo que no fuese a un campo nuevo, estaba directamente prohibido. Con lo cual el número de versiones de un mismo cálculo, era como poco... grotesco, y ya no te digo, pretender saber "qué versión era la más correcta".
Te hablo de bastantes años, desconozco como hayan podido evolucionar aquellos sistemas de su momento... y obviamente, no me considero ni de lejos especialista en el tema. Simplemente probé aquellos caldos... y desestimé seguir evolucionando en aquel caos.
Por cierto, mis cordones, te saludan.. agradecidos de tu gesto... y si pones el enlace al vídeo igual me instruye y todo.
#124 y digo yo... qué cojones tendrá que ver el hardware, con la arquitectura de software? Quién dijo que las máquinas IBM hayan sido malas, cuando son tan cojonudas que incluso 50 años después, nadie se atreve a apagarlas?
a ver si el que no tiene ni idea.. y ya le valen sus cordones... vas a ser tú
Me temo que el viejuno, habla con alguien, que no tiene ni idea de lo que le comento.
A ver, me puedo equivocar, pero al hablar de arquitectura no incluyo el desarrollo de software, lo relaciono más a la arquitectura de hardware, por esto te he contestado lo que te he contestado y si te sirve de aclaración tengo muchos conocimientos de arquitectura de desarrollo en entornos de miniordenadores y mainframes, llevo desde el 84 desarrollando para corporaciones, de un 4381 a un z/16, se de lo que hablo, posiblemente mejor que tú. Mainframes de 50 años deben quedar 4 o 5 funcionado, mas que nada porque un mainframe no se compra, se compra el derecho de uso y IBM los va renovando, por el mantenimiento, es más barato mantener un z/16 que un 3090, menos problemas de hardware, aunque no dudo que un 4381 siguiera funcionado bien y mayor velocidad de procesamiento y transaccionalidad, pero bueno. Me imagino que hablaras de documentación de la aplicación a modificar porque el As/400 tiene muchísima, y el problema de la documentación de software no tiene que ver ni con el entorno ni con el lenguaje, tiene que ver con las políticas de la empresa, si vas a tocar algo de SAP en Abap te aseguro que lo pasarás igual de mal, como con el 80% de las aplicaciones desarrolladas, mas que nada porque no te dan mucho tiempo a documentar, eso de que ahora se documenta más es una milonga.
#78 Hay muchos nichos enanísimos: profesionales que hablen dos lenguas dispares y minoritarias, expertos en un grupo muy específico de fertilizantes orgánicos, investigadores médicos con experiencia en el estudio de alguna enfermedad rara, etc, etc, etc. Los nichos enanos no suelen ser el problema, porque siempre hay algún friki que le gusta esas frikadas. Desde instalar SO antiguos de ordenadores en smartphones hasta hacer una lavadora a pedales. Hay gente para todo.
Al final todo se basa en lo mismo: quiero que hagas un trabajo altamente cualificado, pero no tan excitante a cambio de un salario de mierda, o unas condiciones de mierda o ambas cosas.
Si te pagaran un sueldazo tremendo. Ahora tu trabajo no se valora, se valora y se paga bien al CEO que se rasca los webos o la seta a dos manos.
Aún así sigo preferiendo leer código ajeno en Python que en cualquier otro lenguaje. Curiosamente, los lenguajes fuertemente tipados y estáticos no se caracterizan por facilitar está tarea.
Pero en realidad el problema no es tanto el lenguaje en el que se programa sino el programador. Desconozco los números pero me juego el cuello a qué el término clean code es ajeno a la inmensa mayoría.
#1 En realidad hay montones de desarrolladores de COBOL. Estos artículos están escritos desde el más absoluto desconocimiento de la materia.
Las grandes consultoras (NTT Data, SopraSteria, Accenture, etc) lanzan periódicamente programas de becas pagadas (unos 1000 EUR/mes durante 9 meses) en los que te enseñan desde cero a programar en COBOL y mainframe. Al finalizar, salvo que seas un cazurro absoluto, suelen ofrecerte quedarte en plantilla. Obviamente, no se empieza cobrando sueldo forocochero pero se evoluciona rápido y se puede alcanzar un sueldo bastante bastante decente en un par de años. Teniendo en cuenta que aceptan a cualquiera (recuerdo ingenieros industriales, químicos, licenciados en Historia y hasta abogados), están dando una oportunidad para iniciarse en IT a gente que de otra manera no tendría entrada fácil.
Los sistemas Mainframe, ya sea con Cobol, con Fortran o con cualquier otro, llevan tantisimos años implantados y con un nivel de personalizacion tan enormes, que las migraciones son inviables tanto por tiempo como por coste.
Ay COBOL, COBOL, el lenguaje que mi profesor nos dijo en 2003 que llevaba 20 años muriendo...
Yo fui becario hace unos 12 años en una consultora IT para un banco en el equipo de desarrollo para los mainframes: COBOL, CISC, JCL, z/OS, y ya la media de edad era alta y las ganas por trabajar en eso bastante pocas.
Yo solo se que se acabará el mundo antes de que se acabe COBOL.
Otra vez que nos cuelan la nada como noticia.
De todos modos, el duck typing es horrible para leer el código de otro i al de una una semana después de programarlo si no tiene type hints (y usas funciones, claro jaja)
Migrar código de hace sesenta años de una forma de pensar diferente como Cobol es tan caro que seguramente estén contratando y formando programadores en ese lenguaje.
Si es caro de migrar y tiene sesenta años, no es la aplicación de sastrerías martinez. Es una empresa donde hay dinero. ¿Para qué migrar cuando puedes contratar gente o incluso formarles?
No, la verdad es que no me acabo de creer la noticia.
Son programas que llevan tiempo sin recibir actualizaciones, al menos en sus capas más interiores. Llevan decadas contratando desarrolladores para llevar algunas funcionalidades a otros entornos. Pero eso es la periferia del programa. El núcleo no se toca y si en algún momento alguien decide una partida presupuestaria para hacer cambios será un sprint enormey largo para migrar a C++, Java o alguna cosa más moderna lo que hay e independizarlo del mainframe y su ecosistema: CICS, MQSeries, DB2,ME series. En algún momento parecía que esas tecnologías emergerían en UNIX. De hecho están soportadas en AIX, pero sigue siendo ser cauitivo de IBM, de su hierro y de su sistema operativo.
Yo no puedo hablar por los demás, pero no tengo ganas de ponerme a destinar como funciona un sistema arcano para re implementarlo en una arquitectura moderna, porque no es nada estimulante.
Un banco no entiende por qué tiene que pagar otro desarrolló para tardar años en tener que ya hace lo mismo que hace el programa que tiene y que está amortizado. El jefe de sistemas si lo entiende, pero los responsables de negocio no quieren pasar por ahí.
Conón profesional no tengo ganas de formarme para un proyecto que es un nicho diminuto y que parece que va a ser cancelado en cualquier momento. O no se o tenemos éxito y finaliza y tampoco nos necesitan.
Hola empresas, aquí alguien que sigue dándole al COBOL ( y mas cosas que os veo).
Eestoy pensando como las condiciones de los batch de MSDOS que tiene que tener el expacio e indexado justo que sino lo les gusta, y no recibes ningun error solo que nunca se da la condicion.
Y si no los hay, tranquilo que surgirán como generación espontánea. Es un problema de salario.
Verás, la mayoría de veces programar tiene más de entender el negocio que estás programando y los fundamentos de su CORE que de saber poner ifs, loops o return. Al fin y al cabo, un lenguaje de programación, es un idioma, que se puede comparar a ladrillos... y en cambio, con ese mismo ladrillo, lo mismo construyes una mansión, una catedral, una casa en el bosque o un rascacielos.
Pues aquí lo mismo... esto va de "arquitectura", y la arquitectura de aplicaciones implementadas en COBOL aparte de prehistóricas y nula documentación... en un mundo financiero que permite pràcticamente ningún error... es terrible, letal, poner a alguien que no comprende las repercusiones de poner o no un 0 o un null en un campo... puede cambiar absolutamente todo y tardar meses en poder depurar dónde està el error.
Vamos, es un problema de prehistoria funcionando en el siglo XXI, nadie se atreve a apagar dichos servidores, porque no hay equivalente que los reemplace, y a su vez, necesitan adaptar los cambios que imponen las legislaciones y leyes... en fin, un caos.
Antes que eso preferirían pagar a un buen desarrollador de <lenguaje moderno> que reescribiera la aplicación desde cero.
Cualquiera de las dos opciones es mucho dinero que prefieren quedarse para bonuses de esos.
Si buscas rendimiento no te va a valer. Pero si buscas estabilidad y mantenimiento, desde luego que sí.
stackoverflow.com/questions/11328920/is-python-strongly-typed
Sistemas AS400, muchos años ha, si he tenido que toquetear alguno, y como digo... ninguna documentación dispuse en aquel momento (creo que se parece mucho a nula), y todo lo que fuese "modificar" algún cálculo que no fuese a un campo nuevo, estaba directamente prohibido. Con lo cual el número de versiones de un mismo cálculo, era como poco... grotesco, y ya no te digo, pretender saber "qué versión era la más correcta".
Te hablo de bastantes años, desconozco como hayan podido evolucionar aquellos sistemas de su momento... y obviamente, no me considero ni de lejos especialista en el tema. Simplemente probé aquellos caldos... y desestimé seguir evolucionando en aquel caos.
Por cierto, mis cordones, te saludan.. agradecidos de tu gesto... y si pones el enlace al vídeo igual me instruye y todo.
Perdona. www.youtube.com/watch?v=ZDtaanCENbc&t=364s
Y el As/400
a ver si el que no tiene ni idea.. y ya le valen sus cordones... vas a ser tú
Me temo que el viejuno, habla con alguien, que no tiene ni idea de lo que le comento.
Yo he visto:
If(true)
Mogollón de código
Else
Mogollón de código
Debe ser lo mismo, pereza.
Al final todo se basa en lo mismo: quiero que hagas un trabajo altamente cualificado, pero no tan excitante a cambio de un salario de mierda, o unas condiciones de mierda o ambas cosas.
Si te pagaran un sueldazo tremendo. Ahora tu trabajo no se valora, se valora y se paga bien al CEO que se rasca los webos o la seta a dos manos.
#FreeAssange
Aún así sigo preferiendo leer código ajeno en Python que en cualquier otro lenguaje. Curiosamente, los lenguajes fuertemente tipados y estáticos no se caracterizan por facilitar está tarea.
Pero en realidad el problema no es tanto el lenguaje en el que se programa sino el programador. Desconozco los números pero me juego el cuello a qué el término clean code es ajeno a la inmensa mayoría.
Las grandes consultoras (NTT Data, SopraSteria, Accenture, etc) lanzan periódicamente programas de becas pagadas (unos 1000 EUR/mes durante 9 meses) en los que te enseñan desde cero a programar en COBOL y mainframe. Al finalizar, salvo que seas un cazurro absoluto, suelen ofrecerte quedarte en plantilla. Obviamente, no se empieza cobrando sueldo forocochero pero se evoluciona rápido y se puede alcanzar un sueldo bastante bastante decente en un par de años. Teniendo en cuenta que aceptan a cualquiera (recuerdo ingenieros industriales, químicos, licenciados en Historia y hasta abogados), están dando una oportunidad para iniciarse en IT a gente que de otra manera no tendría entrada fácil.
Yo fui becario hace unos 12 años en una consultora IT para un banco en el equipo de desarrollo para los mainframes: COBOL, CISC, JCL, z/OS, y ya la media de edad era alta y las ganas por trabajar en eso bastante pocas.
Yo solo se que se acabará el mundo antes de que se acabe COBOL.