Mary Hawes estaba harta de programar en ensamblador, así que logró organizar una reunión con académicos, fabricantes y usuarios de ordenadores y propuso una idea genial: "¿Qué tal si creamos un lenguaje de programación más fácil de entender y usar que el ensamblador?" La respuesta de aquel comité fue un rotundo sí, y fue entonces cuando Grace Hopper, que ya había trabajado un un protolenguaje llamado FLOW-MATIC, acabó formando parte fundamental de la creación de COBOL, el lenguaje de programación procedural que se ha convertido en una leyenda.
|
etiquetas: cobol , desarrollo , computación 
Vuestras vidas las sustenta cobol. Prácticamente todas las empresas del ibex y otras muchas, administraciones públicas, empresas de alimentación, seguros, automóviles....etc, todas tienen COBOL a funcionando por debajo.
COBOL es el antihype de la informática. Si algo funciona, funciona bien, es escalable, sencillo, robusto y no falla.......no lo cambies.
Vuestras vidas las sustenta cobol. Prácticamente todas las empresas del ibex y otras muchas, administraciones públicas, empresas de alimentación, seguros, automóviles....etc, todas tienen COBOL a funcionando por debajo.
COBOL es el antihype de la informática. Si algo funciona, funciona bien, es escalable, sencillo, robusto y no falla.......no lo cambies.
No se trata de tener prisa, se trata de ser productivo y no tener ganas de sacar la recortada. Fijo que los asesinatos masivos en oficinas en USA son por programar en COBOL.
Por otro lado, lo de que se podían haber dado tiempo y hacerlo mejor, es graciosete decirlo desde el 2019 repantingado. En los 60-70 cambiar de ensamblado a Cobol, fue una brecha.
Para recortada, cada vez que tenía que construir y destruir objetos en su momento o la primera vez que ví el garbage collector de JAVA. La recortada como las opiniones y los culos; todo el mundo tiene uno
Las deficiencias no se critican, se solucionan. Y si no se puede se admite el fracaso.
Dicho esto, COBOL es o muy lento, o muy caro (pero locura de caro), tienes que elegir. Es sin duda fiable, porque es sota, caballo o rey, pero es inoptimizable, porque es sota caballo o rey. Cosas imprescindibles en procesamiento batch a gran escala que cobol no soporta ni remotamente: procesamiento en paralelo y vectorización de operaciones. Es como el niño de karate kid: leer registro, escribir registro. Python con numpy se ventila en segundos ( y en 10 lineas de código) lo que cobol puede tardar horas en procesar (o minutos, pagando a IBM).
Las empresas no mantienen cobol porque sea eficiente o fiable. Lo mantienen porque el coste y el riesgo de migrarse a otra solución es incalculable (no de grande, sino de que literalmente no hay manera de estimarlo), y nadie quiere ponerle la cola al burro. ¿Para qué voy a jugarme mi puesto de CTO si pagando una millonada a IBM (o a Micro Focus, que licencia por cpu) todo funciona perfectamente y quedo de puta madre?
Lo que menos interesa a un grupo de directivos es complicarse la vida e invertir pasta para cambiar algo que funciona a no ser que les traiga un beneficio claro en sus bolsillos.
Habiendo trabajado en migraciones de hardware y software que no tienen nada que ver, y que son en un ámbito más pequeño (relativamente hablando), y sabiendo la de problemas que surgen, no me quiero ni imaginar lo que sería sustituir todas las soluciones en Cobol de bancos y otras empresas por algo más nuevo.
En inglés me hace más gracia leer esas cosas. No sé por qué...
Me pregunto cuantos aqui habran programado en COBOL. Yo todavia le tengo cariño
Entiendo que critiques que el lenguaje es muy cuadriculado con las divisiones o te parezca anticuado, pero acabó liderando el mercado frente a otros lenguajes de su tiempo, y eso por algo será
En cuanto a tu pregunta, no ejerzo como programador y, de hecho, hace años, lustros, que no escribo una línea de código. Pero en la facultad las primeras dos asignaturas que aprobé fueron las de programación. Las últimas las de electrónica.
La ventaja de COBOL es precisamente que hace muy bien aquello para lo que fue diseñado.
Pero es un coñazo del copón.
¿Un lenguaje de programación diseñado por una mujer? ¡Ahora me explico por qué en COBOL hay que hablar tanto para decir tan poco!
Pero incluso en la segunda mitad de los 80, cuando me empezó a interesar la programación y empecé a ver qué había (hablo de hace 30 años para un chico de pueblo en "provincias") y vi código en COBOL, BASIC y hasta LOGOL y FORTRAN, COBOL me parecía extremadamente complicado, hasta FORTRAN, que es de la familia como quien dice, era más sencillo.
Así que mi opinión tiene 20 años de primera mano, 30 desde que tuve noticias pero sin codificar.
Por cierto, cualquier compilador de tres al cuarto te dice si te falta una coma. Aunque luego no sea eso.
La teoria de las gramaticas te ayuda, no solo como analizar el lenguaje, sino tambien a delimitar como debe ser para que su desarrollo sea mas facil.
Hoy en dia hay herramientas software que te permite construir los automatas y las gramaticas muy rapidamente. Tu dices como quieres el lenguaje, la herramienta te lo valida y te crea un esquema basico que te sirve de base para poder desarrollar el compilador.
Cuando desarrollaron el Cobol, sabian como desarrollar automatas, ya que son basicos para el funcionamente del hardware. Con eso desarrollaron el lenguage. La teoria de gramaticas vino despues.
No hay nada más robusto, fiable y eficiente para gestionar información de sistemas transaccionales como el Cobol.
¿Que podrías hacer lo mismo con C o con otro lenguaje? Si, claro, ¡y con Pascal! Pero prepárate a soltar la talegada en horas de desarrollo y en máquinas y cruza los dedos para que no pete una transacción crítica para la empresa.
Y no es monopolio de los bancos. Cualquier gran empresa que genere y procese gran cantidad de datos de sus clientes lo usa; bancos, telefónicas, empresas de suministros, etc...
Y bueno, podría poner también ejemplos de servidores de base de datos que al incorporar nuevas mejoras que no existen en otros, empujan a migrar con lo que supone de tener que actualizar procedimientos almacenados o muchas veces incluso sentencias SQL.
Pretender optimizar eso es como optimizar ensamblador, absurdo.
Los grandes procesados de datos se hacen en JCL, que es el lenguaje de procesado de datos masivos.
De hecho suele haber muchos mas programas COBOL asociados a parte online que a procesos batch. No hay casi nada que puedas hacer en COBOL que no te de un Sort de jcl.
Y una prueba bastante fehaciente es que bancos que han querido migrar de COBOL a otra cosa han desaparecido antes que el lenguaje.
Pero COBOL está desapareciendo ya que los nuevos procesos van prácticamente asociados al online y a big data, y ninguno de ellos usa COBOL. Es decir, COBOL no está siendo sustituido por otra tecnología, a pesar de lo caro que es pagar a IBM, si no por que la banca clásica ya no desarrolla apenas nada.
El problema es la cantidad de código antiquisimo que ni Dios se atreve a tocar (aunque si funciona bien desde hace décadas, para qué lo vas a tocar) y sobre todo, el precio del Mainframe. IBM sabe que tiene a sus clientes pillados por los huevos y cobra auténticas barbaridades por ello.
Y no he dicho que los bancos tengan el monopolio de Cobol. He dicho que Cobol tiene el monopolio (o por ahí) en bancos y otros sitios.
#41 yo me identifico más con un triceratops.
Pero hay algunos proyectos potentes en marcha para migrar el core bancario en alguna entidad bancaria y sacarlo del mainframe. Al final IBM bajará precios para poder competir con el resto de plataformas. Pero aguantará todo lo que pueda.
Que no es sudo apt install eclipse git y alegría al cuerpo.
(El chiste se había hecho?)
¿Eso es una errata o has combinado apropósito pringao con programador?
Así que, de cierta manera, se puede entender el concepto de #75 como lo que están pagando y sufriendo de más las empresas por mantener código en COBOL; pocos desarrolladores serios, hardware caro, código de difícil migración, documentación no adecuada para implementar una migración, etc...
改善 FTW!!!
Eso se ha mantenido para siempre y ahora puede parecer una limitación absurda, pero tiene un motivo
En 20 años en el sector se ha cambiado el lenguaje de la capa de presentación varias veces, pero el backend sigue en Cobol y es una gran ventaja que no cambie con las "modas" porque sino tendrías una mezcla de tecnologías imposible de mantener y necesitarías personal de mantenimiento que conozca bien muchos lenguajes en lugar de alguien que domine COBOL y JCL.
Las cosas que no son core como aplicaciones de Big data, etc si se hacen en otros lenguajes pero todo los que debominas como banca clásica que yo he llamado core bancario supone muchísimas horas de desarrollo al año.
No es que otros lenguajes no sean igual de fiables, es que no puedes cambiar de lenguaje cada poco porque para mantener una aplicación como préstamos que tiene desarrollos hechos a lo largo de 40 años es más funcional hacerlo con un equipo que sabe cobol que con un equipo que controle 10 lenguajes
Ni es ese sueldo ni quedamos pocos decenas de miles trabajamos cada día en Cobol en España
Hace más de 30 que no se programa en el terminal, lo confundes con el emulador de 3270, emula el comportamiento de terminal pero no es el terminal, y puedes programar en lo que quieras/te dejen. Si ves el menú de notepad++ veras la opción de cobol
Desde hace 15 años la migración más segura es a java, pero es difícil. Quien lo hiciera está hoy mucho mejor que si hubiera mantenido COBOL. Y hoy yo migraría a Python sin duda, aunque aún no hay muchos desarrolladores en España.
Desde luego que estos sistemas legacy siguen existiendo porque nadie quiere jugársela a cambiar algo que "funciona", entre comillas porque en la era de las transacciones online tener una latencia tan alta o nula escalabilidad (a un coste asumible claro) no es funcionar muy bien que digamos.
Es domingo pero eso lo escribí ayer. Y en absoluto "muy picado", eso es interpretación tuya. Errónea.
Yo aprendí esos mismos lenguajes, y unos cuantos más, por esa época. Y de todos ellos es COBOL, sin duda alguna, del que menos líneas escribí.
Aunque no lo viese en mucha profundidad, uno que sí me moló un puñado fue OCaml. Cuando cambias el chip de "procedural" a "funcional" es como tener una "revelación".
*Modificación X1234 dd/mm/aaaa Inicio/fin
Al final encuentras fuentes con más comentarios y código asteriscado que código vivo, cuando eso debería delegarse al control de versiones.
O guardan un numero de versión en el margen derecho del fuente con lo cual sabes cuál es la ultima versión que ha tocado una línea pero ni idea de las anteriores versiones que tocaron la línea. Y cualquiera puede borrar ese historico editando el propio fuente.
Sí, es un emulador del terminal. Un emulador que corre sobre Windows/Linux con una resolución de 43 filas por 80 columnas y ahí analizas código, picas código, ejecutas SQL... si tienes suerte el cliente te proporcionará alguna herramienta de este siglo para consular la base de datos y si tienes mucha suerte un IDE de este siglo para programar. Porque a fin de cuentas la filosofía es "si algo funciona no lo cambies", son sistemas críticos de la empresa y lo más importante es que sea robusto y fiable.
He estado en proyectos con un framework de Java que ya nadie mantiene por ser muy antiguo pero que el banco tiene que mantener sin apoyo de nadie porque tienen mucho código de hace quince años que no pueden migrar sin gastarse un dineral. Y claro, cuando contratas a alguien, o ha trabajado ya contigo o tiene que aprenderlo... Y no preguntes en stackoverflow