El legendario lenguaje de programación COBOL acaba de cumplir 60 años, y es probable que cumpla otros 60 más

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.

[#6 kimbbo]

COBOL funciona y, además, lo hace muy bien para lo que se le necesita. No hay nada más rápido, optimizado, sencillo y fiable para procesos batch a grandísima escala.

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.

[#24 derivada]

#6 Te he votado positivo, porque entiendo el papel histórico del COBOL y de Grace Hopper como pionera a la que todos los niñatos que vienen a quejarse con tonterías le deben mucho.

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?

[#25 GanaderiaCuantica]

#24 Estoy de acuerdo en que es por lo último que dices. Ni por fiabilidad, ni rapidez, etc. , aunque fuese cierto.
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.

[#49 igcoca]

#25 Yo he trabajado en los ultimos años en varias migraciones. De RPG a COBOL....

[#114 EmuAGR]

#49 No me quiero ni imaginar lo que sería reescribir a COBOL el Skyrim.

[#61 derivada]

#25 yo he hecho durante años migraciones de mainframes enteros, con un alcance muy cerrado y con un equipo muy experto, y el cobol se iba a cobol. Nos llevamos bancos enteros a linux, con el db2 a oracle, arquitecturas distribuidas etc. Pero el cobol no se toca, se pasa de IBM a Micro Focus y ya cuesta mantener las particularidades de compatibilidad de cada casa.

[#64 llorencs]

#61 ¿Por qué Micro Focus en vez de seguir con IBM? Ofrece ventajas el Cobol de Micro sobre el de IBM?

[#67 derivada]

#64 que compila a Linux o windows, puedes dejar de pagar millonadas al año a IBM. Aunque micro focus no es barato, es un ahorro brutal.

[#28 llorencs]

#24 No se actualiza el lenguaje de COBOL para que de soporte paradigmas mas modernos?

[#42 Inutil]

#28 En su momento estuve investigando y había versiones de COBOL OO, pero no lo he visto funcionando en ningún sitio.

[#59 derivada]

#42 #28 si, hay OO en el estandar COBOL moderno, Micro Focus incluso te permite desplegar programas COBOL en una jvm o .net. Pero para hacer algo nuevo nadie se plantearía COBOL. Y si te atreves a modernizar el legacy, te vas bien a buscar máxima compatibilidad, en cuyo caso harás cobol2cobol manteniendo el estandar que ya tenias (nada de OO), o reescribes desde cero, en cuyo caso de nuevo no te plantearías cobol ni loco.

[#74 Inutil]

#59 eso es lo que quería decir, que la tecnología existe, pero nadie (que yo sepa) la usa en entornos reales.

[#43 Inutil]

#24 Empieza a haber projectos para sacar los mainframes de las grandes empresas y con ellos los sistemas programados en COBOL. Muchos de esos proyectos fallan por el gran desafío que representa, pero ya hay casos (pocos) de éxito en grandes corporaciones.

[#62 derivada]

#43 en España hace 10 años casi que no se hace algo grande que yo sepa. Los mainframes muy pequeños si van cayendo, y los de vendors obsoletos. Pero IBM ha vuelto a levantar la guardia y están que no hay quién les tosa ahora mismo.

[#73 Inutil]

#62 Lo último grande que se hizo en cobol (que yo sepa) fue lo de Infocaja implementando Alnova.

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.

[#79 derivada]

#73 por curiosidad, qué proyectos potentes?

[#53 ellapidario]

#24 COBOL fundamentalmente mueve de variable a variable o calcula datos. Y tiene pocas instrucciones más, para bucles, los condicionales y los de gestión de archivos, de db2, de cics y alguna cosa que vas a necesitar una vez al año.
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.

[#87 Radix2]

#53 discrepo, todo el backend bancario sigue siendo cobol y por tanto sigue habiendo mucho desarrollo en Cobol. Es cierto que no haces una nueva aplicación de ctas personales o préstamos, pero tienes muchos desarrollos sobre la aplicación existente.

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.

[#100 ellapidario]

#87 eso que dices yo lo llamo mantenimiento. Y da muchos menos desarrollos que hacer proyectos nuevos

[#86 Radix2]

#24 no sólo es caro y arriesgado hacer la migración, es que hace veinte años migrarías a C, hace diez a .net , ahora a algún framework de Java y dentro de cinco años quien sabe a qué.

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.

[#93 derivada]

#86 COBOL es legacy por definición, y justo has ido a poner ejemplos de lenguajes que están perfectamente vivos hoy. Hay opciones de sobra para migrar sin pillarte las manos.

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.

[#98 Radix2]

#93 es justo lo que te decía, donde estaran Java y Python dentro de 20 años? O Java 6 y Python lo que sea....
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

[#115 EmuAGR]

#93 ¿Migrar a Java? ¿A Java?

[#94 DabbaDoo]

#24 Venía a añadir esta información pero tú ya lo has hecho, muy bien explicado y muy completo, incluso mencionando la virtualización de MicroFocus.

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.

[#51 Conde_Lito]

#6 La premisa fundamental de cualquier empresa es "si algo funciona, no lo toques" de ahí que todas esas empresas dinosaurio sigan utilizando Cobol, el Corte Inglés si no me equivoco creo que también tiene gran parte de la programación en Cobol, toda la parte crítica del sistema que fue programado a finales de los 60, principios de los 70.

[#81 raul_lapeira]

#6 la mejor forma de soportar un sistema caduco que poco a poco va cayendo de produccion y sus trabajadores poco a poco acaban despedidos y obligados a reciclarse es usar palabras grandilocuentes como "es lo mas fiable en batch" o "vuestras vidas las sustenta cobol"... Que chorradas. Que leches tendra que ver el lenguaje con la fiabilidad de una operacion en batch... Eso depende de la calidad del codigo, de los datos, de la disponibilidad de los sistemas... El lenguaje importa poco en "la fiabilidad del batch"

[#88 Radix2]

#81 hay procesos COBOL que llevan 40 años funcionando y adaptándose a los cambios necesarios. Imagina que en vez de estar en Cobol ese proceso se hubiese hecho en Pascal, y los procesos de hace 30 años en Basic, y los de hace 25 en C y los de hace 10 en. Net y etc....

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

[#91 Desactivado]

#6 En la empresa que trabajo para un banco relativamente importante, ya está en fase de inicio un gran proyecto para migrar toda la parte de COBOL a java... y la primera fase de desarrollo parece viable.

[#99 Desactivado]

#6 A la hora de calcular un balance, donde se ponga un S9(9)99 que se quiten todos los floats del mundo.

[#9 ElPerroDeLosCinco]

Si lo hubiera sabido en su día, hubiera empezado a trabajar en COBOL y lo seguiría haciendo el resto de mi puta vida. Y me olvidaría de aprender cada año el nuevo lenguaje, framework o paradigma de moda.

[#10 ccguy]

#9 Transmites pasión...

[#26 GanaderiaCuantica]

#10elperrodeloscinco no es de los que pone en su CV "I am an enthusiast of new technologies and eager learner waiting for new challenges"

_{En inglés me hace más gracia leer esas cosas. No sé por qué...}

[#50 Desactivado]

#10 pasión por los 200.000€ anuales que en España cobran los pocos programadores de Cobol que quedan

[#52 ccguy]

#50 Suena creible.

[#63 bralmu]

#52 Es prehistórico en el sentido que solo se usa para mantener sistemas antiguos. No hay clases, no hay funciones, no hay variables locales, no hay IDE, no hay test automáticos, no hay excepciones, no hay control de versiones. Lo que en python es 1h de trabajo en cobol son 8h. Es un welcome to 1990 y está ligado a sistemas propietarios de IBM que parece que lo monta a mala leche para que no se escapen sus clientes.

[#65 llorencs]

#63 Mmm, ¿Por qué no puede haber control de versiones? El código no lo puedes meter en un Git/Mercurial, no? Como ha dicho@derivada hay implementaciones que son OO. ¿Y lo de variables locales? ¿En serio, no tienen locales? Todo son globales?

[#66 bralmu]

#65 Todo globales, se pica desde un editor en el propio terminal, 80 columnas por fila. ¿Integrarlo con Git/Mercurial para control de versiones? Supongo que existirá alguna solución propietaria y carísima para hacerlo. Pero que estemos en 2019 y no venga de serie esa posibilidad te da una idea de lo cerrada y cara que es IBM y lo ineficiente que es desarrollar en esta tecnología.

[#69 derivada]

#63 #66 estás exagerando un poco. Claro que hay IDEs, de pago y gratuitos, Eclipse mismamente. Control de versiones el que te implantes, que impedimento ves para usar git? IBM no impide hacer devops como harías con python o con cualquier otro lenguaje. (al fin y al cabo desplegar un programa COBOL solo requiere subir un fichero de texto a un servidor y compilarlo)

[#76 bralmu]

#69 A ver, no digo que sea imposible usar IDEs o Git y olvidarte de la pantalla negra. De hecho he visto una empresa donde usaban (parcialmente) Eclipse. Digo que montarlo es inusual y más costoso que con cualquier lenguaje/entorno moderno. Como instalar Doom en una impresora en vez de en un PC.
Que no es sudo apt install eclipse git y alegría al cuerpo.

[#90 Radix2]

#66 hay control de versiones, todo lo que quieras y más, hay proyectos en los que tienes las versiones de los 80 para comparar, nunca he estado en un proyecto donde no tuvieras gestión de versiones, solo que no son las habituales de java/python/etc.. .

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

[#97 bralmu]

#90 Sí, hay "control de versiones" de aquellos tiempos. Normalmente un programa solo lo puede modificar una persona y queda bloqueado hasta que termine todo su desarrollo. Hay un único entorno de desarrollo. No hay ramas. No hay merges. A veces solo puedes recuperar versiones de producción del programa la N-1 y la N-2. Cada vez que modificas el código lo llenas de comentarios guarros
*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.

[#60 Yomisma123]

#50 Para nada. Un prigranador Cobol cobra bien poco

[#78 Wayfarer]

#60 prigranador

¿Eso es una errata o has combinado apropósito pringao con programador?

[#83 ochoceros]

#60 #78 Pringramador, suena a becario en neolengua

[#89 Radix2]

#50 ojalá pero no,ni de coña . Fmdo: trabajador en Cobol desde 2001

Ni es ese sueldo ni quedamos pocos decenas de miles trabajamos cada día en Cobol en España

[#55 ElPerroDeLosCinco]

#10 Tuve pasión, te lo juro. Me encantaba programar. Pero 20 años trabajando en España en el sector matan la ilusión de cualquiera.

[#36 JungSpinoza]

#9

[#46 Desactivado]

#36 Si solo fuese el Front-end. El año que viene se producirá el "final de vida" de Java 8, que se podría decir que es la versión estandard de las aplicaciones java hoy en día, eso obligará a migrar a java 11 o 14 que incorpora un sistema de módulos que implica un cambio tan grande, que también obligará a actualizarse a nuevas versiones de librerías y herramientas (Y eso siendo optimistas y suponiendo que estas también migrarán y no se hayan quedado abandonadas)

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.

[#54 JungSpinoza]

#46 Ahh nada mejor que una migracion de base de datos relacional a NoSQL justo antes de navidad.

[#57 Desactivado]

#54 Bueno, yo hablaba de la replicación lógica de PostgreSQL , pero no quería aburrir a la gente con detalles técnicos.

[#38 almeriensis]

#9 Amén, hermano.

[#32 citizenx]

Cuando todos lo que critican a COBOL hoy hayan muerto, código COBOL seguirá ejecutándose en algún lugar.

[#18 sorecer]

#15 Es lo que me encantan del cobol. Aquí empieza, aquí termina. Compilando y te dice, aquí te falta un punto, tío. Recompila.

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

[#40 Tensk]

#18 Esto... si vamos a eso, más graciosete me parece a mí opinar sin saber de qué se habla. Puedes tener la opinión que quieras, pero no estoy opinando desde 2019. Mi primer contacto real con COBOL fue hace ahora 20 ó 21 años. Ya pensaba esto mismo entonces y lo sigo manteniendo.

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.

[#95 sorecer]

#40 Estas muy picado. Relajate un poco que ya es domngo. Aupa!! Por cierto, yo estudié ensamblador, cobol y pascal allá por los 90. Y Cobol era una maravilla.

[#96 Tensk]

#95 ¿Picado? ¿Te ha sentado mal el whisky de media mañana?

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".

[#102 Desactivado]

#40 LOGOL

[#3 tusitala]

"Grace Hopper" debe sonar algo así como saltamontes en inglés, ¿no?

[#4 Tensk]

#3 efectivamente, no anda muy lejos.

[#12 vacuonauta]

#3 saltia montes

[#22 Desactivado]

#3 En vez de saltamontes sería Salta Montse.

[#13 sorecer]

#5 Pues bastante más cariño le tengo a la procedure division que al push de mierda. Que el COBOL ES cansino? Si. y?? Tienes prisa?

[#15 Tensk]

#13 Yo no he defendido ninguno de ellos. Digo que para haber inventado COBOL, se podían haber dado un poco más de margen y hacer las cosas bien, no tener esas indicaciones sobre dónde empezar y terminar una línea, las division y todo eso.


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.

[#44 sisi]

#15 Dudo que así como estaban las cosas pudieran hacer algo mejor. Los compiladores modernos se basan en modelos matematicos que facilitan el trabajo. En una primera fase, llamada analisis lexico se utilizan unos objetos llamados automatas que reconocen las palabras clave. En una segunda fase llamada analisis sintatico , se utilizan otras estructuras algebraicas llamadas gramaticas que reconocen estructuras como los bucles de control, declaraciones de variables, estructuras anidadas, etc.
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.

[#71 Tensk]

#44 Gracias por la explicación, que igual profano le quedará un poco "ein?" pero yo te la he entendido. En tercero de carrera tuve una asignatura en la que una práctica consistía en programar un "parser" con el que a partir de la estructura de árbol guardada en un fichero, había que reconstruir el código fuente que lo generaba (o algo así, hace cerca de veinte años ya). Eso te dará una pista de lo que he estudiado, espero

[#84 Radix2]

#15 ten en cuenta la época, era uno de los primeros. Por ejemplo lo que comentas de las limitaciones de comienzo y fin de línea sabes por qué son? No se escribía el código en un fichero como ahora, se hacía en tarjetas perforadas y sé metían las tarjetas al compilador, empezar en la columna 8 es porque las siete primeras columnas de la tarjeta perforada tenían info de control y terminar el la 80 creo que era el máximo de columnas de la tj perforada.
Eso se ha mantenido para siempre y ahora puede parecer una limitación absurda, pero tiene un motivo

[#85 Tensk]

#84 Sí, sé de dónde vienen esas limitaciones. Eso no quita que sean un puñetero coñazo.

[#31 Tensk]

#21 Mi pregunta era porque si sabe algo, sabrá a qué me refiero (posiblemente). Si no sabe nada, me adapto para explicárselo. No voy a dar una explicación de algo tan técnico sin saber a quién se lo estoy diciendo.

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.

[#48 tednsi]

#31 Pues yo he programado profesionalmente, tanto en ensamblador como muchos años en Cobol y agradecería que lo explicaras.

[#68 Tensk]

#48 Mi más sentido pésame. En uno tienes que saber muy bien qué haces y es jodido descubrir errores. El otro es un coñazo.

[#109 maloconocido]

#48 no tiene ni idea de lo que está hablando

[#41 JungSpinoza]

#37 Yo tambien. Aqui esta la prueba grafica

[#72 muaddib76]

#37 yo lo sigo haciendo .
#41 yo me identifico más con un triceratops.

[#92 almeriensis]

#72 Pués nada, si tienes curro de sobra, un toquecito.

[#108 maloconocido]

#41 #72 dónde trabajáis?

[#39 pcmaster]

Mary Hawes estaba harta de programar en ensamblador...

¿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!

[#56 Desactivado]

#39 con un “haz lo que quieras, tú verás”, y no hay ordenador rebelde

[#2 CrudaVerdad]

Un caso ejemplar del dicho: el camino al infierno está pavimentado de buenas intenciones.

[#5 Tensk]

#2 algo así iba a decir. Salir de ensamblador para meterse en COBOL es como preguntar si prefieres silla eléctrica o guillotina.

[#7 kimbbo]

#5 ¿puedes explicar por qué?

[#11 Tensk]

#7 ¿Sabes algo de programación?

[#21 derivada]

#11 y tu?

[#16 Radix2]

#5 pues si puedo elegir prefiero la guillotina de calle, incluso ahora es un método rápido e indoloro de programar

[#19 Desactivado]

#5 Pues el COBOL es muy rígido y engorroso en cambio el ensamblador me encanta porque tienes control completo lo mismo que con C

[#20 Desactivado]

#19 lo cual , la rigidez, es precisamente la clave del éxito de Cobol en sistemas críticos que llevan decenas de años funcionando con mil cambios en los equipos de programadores.

[#35 Tensk]

#19 Con C no es que puedas controlar todo, es que debes controlar todo.

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.

[#30 Desactivado]

#5 conozco ambos y el cobol es un avance muy grande sobre ensamblador. La productividad del equipo de desarrollo aumentó mucho más de lo que puede aumentarla hoy en día cualquier nuevo lenguaje.
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á

[#33 Tensk]

#30 claro que fue por algo: porque no había otra cosa. Simple y llanamente por eso. Todo lo demás fueron "experimentos" hasta que salieron cosas más todoterreno como C tiempo después, pero para entonces COBOL ya era el monopolio de facto en bancos y similares.

[#45 gontxa]

#33 no. No es por eso.

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...

[#70 Tensk]

#45 Cobol tiene sus ventajas y es la herramienta habitual para esos entornos. No he dicho que sea ineficaz en ejecución. Digo que es un coñazo en codificación.

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.

[#23 josejon]

Críticas a Cobol. Parece que lo complicado daña a los débiles.
Las deficiencias no se critican, se solucionan. Y si no se puede se admite el fracaso.

[#105 Nova6K0]

#23 Normal es como comprar un mueble montado comparado con uno de IKEA que hay que montar. Que es lo que diferencia los lenguajes de alto nivel con los de medio (como el propio COBOL) o bajo nivel.

Salu2

[#34 meritonciokin]

Y todavía se ven ofertas de trabajo.

[#77 benjami]

COBOL = Completely Obsolete Business-Oriented Language

(El chiste se había hecho?)

[#58 capitansevilla]

Habláis del COBOL como si fuera un lenguaje prehistórico y lo cierto es que sigue evolucionando (la versión 6.2 salió en 2017).
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.

[#75 dani.oro.5]

#58 "si funciona bien para qué lo vas a tocar" es un antipatrón que produce deuda técnica.

[#80 llorencs]

#75 ¿Por qué es un antipatrón? A qué te refieres con deuda técnica? Si funciona y no requieren actualizaciones, por qué cambiarlo?

[#82 ochoceros]

#80 En desarrollo de software, la deuda técnica es lo que te va a costar arreglar los muertos que vas dejando por el camino, como eso que hiciste corriendo en el corazón de la aplicación con un Id integer, y no te acuerdas de ello hasta que paras la empresa porque has llegado al límite superior y hay que tocar miles de líneas, BBDD, etc... para corregirlo.

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!!!

[#14 Desactivado]

Lo mejor que hizo el profe de segundo de FP2 (lo que se conocía como "quinto de FP") fue pasar de Cobol y dar C

[#47 Zeioth]

Mas que legendario yo diría jurásico.

[#8 Desactivado]

Mis falanges recuerdan con dolor los dos años picando cobol...

[#17 Radix2]

#8 a mi me molestan más los entornos en los que tienes que andar pasando de teclado a ratón

[#1 gonas]

Que horror

[#29 JungSpinoza]

#1 podria ser peor, podrias tener que programar en el penultimo framework cool de javascript

Me pregunto cuantos aqui habran programado en COBOL. Yo todavia le tengo cariño

[#37 almeriensis]

#29 Yo he programado en Cobol. Orgulloso de ello.

[#107 maloconocido]

#37 y se puede saber el sitio?

[#104 colorincolorado]

#29 Yo programé en COBOL durante cinco años.

Pero lo mejor es que mi madre hizo un curso en los años 70 para aprender y no siguió en ello porque un iluminado le dijo que el COBOL estaba anticuado.

[#116 cadgz]

#29 yo estoy programando en cobol ;D

[#27 Loconozcoestuvealli]

Me gusta más su faceta musical.