El registro del abuelo que decía que COBOL llevaba mucho tiempo “muerto”
(wumpus-cave.net)- Un texto publicado en la revista Technical Support en junio de 1992 ya declaraba la muerte de COBOL, pero el punto central es que, incluso 30 años después, el lenguaje no ha desaparecido por completo
- La mayoría de las palabras de moda de la época, como 4GL, no duraron mucho, pero COBOL terminó resistiendo más que muchas alternativas posteriores
- El factor decisivo que mantuvo a COBOL en funcionamiento fue el problema del Y2K, y la respuesta real requirió formar a una nueva generación de programadores de COBOL
- Un lenguaje que alguna vez tuvo una gran base instalada puede mantenerse, en lugar de desaparecer de golpe, dejando una larga cola en la que disminuyen los nuevos aprendices
- El abuelo del autor falleció el 1 de septiembre de 2024 a los 91 años, y el texto entrelaza un recuerdo personal con viejas predicciones tecnológicas
La declaración de “COBOL muerto” ya había aparecido en 1992
- El abuelo del autor publicó en junio de 1992, en la revista Technical Support, un texto que declaraba la muerte de COBOL
- En ese texto aparecían términos de época como 4GL, y el autor añade que COBOL sobrevivió más que muchos de los ejemplos de 4GL listados en Wikipedia
- El texto original se conserva en el archivo de NaSPA: http://www.naspa.net/magazine/1992/t9206003.txt
- El texto de 1992 distingue los matices de la palabra “dead” y trata a COBOL como una especie de zombi: muerto, pero no desaparecido
- Autocoder también se presenta como precursor de COBOL, y se compara como un caso de lenguaje considerado muerto, aunque aún pueda dejar algunos rastros
La larga vida de COBOL impulsada por el Y2K
- Un gran factor que mantuvo en movimiento al zombi de COBOL fue el problema del Y2K
- En su momento ocupó mucho espacio en las noticias y luego pareció que no había pasado nada, pero en realidad fue un problema enorme
- Durante la respuesta fue necesario entrenar a una nueva generación de programadores de COBOL
- Ese proceso pudo haber contribuido a que COBOL se mantuviera por más tiempo
- El autor dice que ahora ya no usa mucho la expresión dead para los lenguajes de programación
- Un lenguaje que alguna vez tuvo una gran base instalada difícilmente muere por completo
- En cambio, deja una larga cola en la que los nuevos programadores dejan de aprenderlo y poco a poco se va desvaneciendo
Un episodio de la historia tecnológica que desemboca en un recuerdo personal
- El abuelo del autor falleció el 1 de septiembre de 2024 a los 91 años
- La causa oficial fue neumonía
- La abuela había fallecido en abril de ese mismo año, y el abuelo pidió no recibir tratamiento
1 comentarios
Comentarios en Hacker News
El texto menciona 4GL, un término que de verdad no escuchaba desde hace muchísimo tiempo
COBOL también prometía que, al “parecerse a oraciones legibles por humanos”, ya no harían falta programadores, y eso se parece a las plataformas de low-code de hoy o al código generado por LLM
El problema es que la gente común normalmente no puede describir y descomponer un problema con suficiente detalle como para que salga una solución funcional. Si logras hacer ese proceso, al final te conviertes en programador, y la lección central de COBOL es que la razón por la que se necesitan programadores no se debe solo a la interfaz o al lenguaje de la computadora
Se parecía más a intentar que alguien que conoce muy bien los procesos de negocio pudiera pasarlos a COBOL sin tener que aprender demasiado sobre cómo funciona una computadora, y en eso se parece a analistas o responsables de datos que interactúan con bases de datos usando SQL
COBOL y los 4GL estaban orientados principalmente a construir aplicaciones de negocio como nómina, banca, recursos humanos e inventario, con especial foco en el procesamiento por lotes para reducir tareas repetitivas y masivas, como la conciliación
Son producto de una época en la que no existían DBMS dedicados, así que la organización de archivos y los verbos relacionados con archivos estaban muy desarrollados, y en eso también se parecen al SQL actual
Incluso si el LLM generara soluciones como por arte de magia, la responsabilidad de expresar el problema de forma concisa y precisa solo se trasladaría hacia arriba
Al final, se “programa” con prompts, y luego se revisa el código, que es el resultado estructurado que propone el LLM. La naturaleza de programar puede cambiar hacia la ingeniería de prompts, pero la necesidad de entender código como lenguaje formal sigue ahí
El texto dice que a inicios de los 90 los 4GL estaban de súper moda, pero dudo que eso fuera cierto fuera del mainframe. El movimiento 4GL fue desde el principio fuertemente orientado al mainframe, y hasta Wikipedia menciona como objetivo inicial reducir la cantidad de tarjetas perforadas necesarias para un programa
Para 1992 ya existía Linux, Python ya estaba en desarrollo, Perl estaba ganando popularidad y Haskell ya tenía versiones iniciales. La frontera tecnológica se estaba moviendo de las costosas workstation a las PC de consumo, y creo que los diseñadores de lenguajes, incluso cuando creaban cosas que en retrospectiva podrían verse como 4GL, como dBase, HyperTalk o AppleScript, no tenían muy presente el concepto de 4GL
Estoy de acuerdo en que un texto parecido al lenguaje natural es una mala idea para la mayoría de los usos de programación, pero no creo que esa sea la única razón por la que fracasó el movimiento 4GL. La mayoría de los 4GL ni siquiera se parecían más al lenguaje natural que COBOL, que era 3GL
El problema mayor fue que el movimiento 4GL nunca logró definir bien qué era la nueva generación ni qué la hacía útil. Los 2GL trajeron el cambio revolucionario de traducir ensamblador a lenguaje máquina, y los 3GL, la compilación; en los 4GL, el único cambio más o menos definible era algo como “meter dentro del lenguaje más funciones que antes estaban en rutinas externas o bibliotecas”
Ese enfoque funcionó bien en lenguajes específicos de dominio, y por eso aparecieron 4GL exitosos como SQL, R y MATLAB. En cambio, la idea de un 4GL de propósito general parecía condenada a terminar en un lenguaje excesivamente inflado
Hoy casi no existe gente que pueda o deba hacer algo así
En este contexto, me viene a la mente Scala. Por cómo el artículo describe a COBOL, creo que Scala también está, en la práctica, bastante cerca de estar muerto
Todavía hay muchas empresas y servicios con componentes centrales escritos en Scala, pero el interés por usarlo en proyectos nuevos se apagó bastante
Entre 2012 y 2014 sentía que en HN veía constantemente posts de “hacer X con Scala”, pero ahora casi no aparecen. Puede ser algo natural e inevitable, pero igual da pena porque Scala tenía varias virtudes que otros lenguajes principales todavía no han logrado cubrir
Incluso hay proyectos bastante importantes para el ecosistema de la empresa, como sistemas de testing, y muchos de los ingenieros que construyeron esos sistemas en su momento ahora son directivos de alto nivel
Hay quienes todavía respaldan esa elección técnica, pero si se les diera la oportunidad de volver a decidir, algunos tendrían una postura más abierta. En general, el ambiente es que si en ese momento hubiera existido Kotlin o si Swift hubiera sido viable para servicios backend, probablemente no habrían elegido Scala
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
El sobrecalentamiento inicial ya pasó, pero está bien. Todos los lenguajes tienen su ciclo de hype y las predicciones casi siempre fallan. Hoy en día es difícil que un lenguaje de programación principal muera como COBOL
Llevan diciendo que Java muere desde 2001, pero sobrevivió a la burbuja puntocom, .NET, la P de LAMP, Ruby, JS y Go. También dijeron que Python iba a morir durante la transición a la versión 3, cuando la gente se estaba pasando a Ruby
Scala es el lenguaje de programación funcional más popular del mundo, tiene buenas herramientas y bibliotecas, y Scala 3 me parece una gran actualización
En algún momento fue enorme y parecía estar en todas partes, pero ahora cada vez queda más relegado a nichos. Como COBOL, todavía queda mucho código Perl en uso real
Jack Henry, SiriusXM, Starbucks, el servicio de streaming de Disney y Capitol One también han estado haciendo proyectos nuevos en Scala en áreas de servicios, no de ciencia de datos, durante los últimos cinco años y hasta hoy
Claro que hay más equipos, pero incluso nombrando solo algunos lugares conocidos que se me vienen de inmediato, cuesta decir que está muerto
Eso sí, parece que están bajando los trabajos relacionados con frameworks centrados en Play y Akka, así como los trabajos de Spark puro que no usan Airflow. Creo que muchos de esos puestos eran de frameworks nacidos del ecosistema Scala, donde Scala mismo muchas veces era algo secundario
Me gusta Scala, pero siempre fue un lenguaje de nicho, mientras que COBOL de verdad estaba en todas partes
Algún día me gustaría sentarme y meterle mano directamente a lenguajes legacy como Fortran, COBOL, Ada y APL
Su popularidad claramente cayó, pero todavía se usan en lugares importantes
Al mismo tiempo, pienso en la enorme cantidad de código Java que existe. Para bien o para mal, Java prácticamente se comió el mundo corporativo, y me pregunto si dentro de 30 o 40 años habrá jubilados usando Java solo para mantener viejos sistemas bancarios
También puede ser por el hecho de que se trata de una base de código o una plataforma monolítica gigantesca. No es que el lenguaje sea arcano o difícil; simplemente hay demasiado código cuya estructura no se ve con claridad
Me imagino que seguirá ocupando algo así como el 0.05% del mercado durante los próximos 100 años
Eso sí, la mayor parte del código nuevo en los últimos años se ha escrito en Kotlin
En lo personal también le tengo cariño: en los 90 lo usé realmente en el trabajo, en una PC. La tarea era averiguar cómo meter datos, y al final escribí una rutina que trataba números de punto flotante como vectores de unos y ceros, cambiando bits para convertir del formato de Microsoft al formato IEEE
Claro, esto fue en la época en que uno llevaba una cebolla en el cinturón
Si fuera a hacer simulaciones numéricas puras, probablemente preferiría Fortran antes que C++ o Python. Excepto por NumPy, claro, aunque el propio NumPy al final también depende de Fortran y C++
En la Carolina Code Conference 2025 todavía están buscando ponentes de COBOL
Sobre todo ahora que GnuCOBOL tuvo una actualización reciente, desde hace tiempo querían incluir una charla sobre COBOL
https://gnucobol.sourceforge.io/
https://carolina.codes
“No sé cómo será el lenguaje del año 2000, pero se llamará Fortran.” —Tony Hoare
Se puede decir que COBOL está vivo porque ha seguido cambiando en cada época. El COBOL moderno es bastante distinto del COBOL de los años 50 que la gente imagina instintivamente al oír ese nombre
Es como si Java se hubiera llamado Algol-94 y por eso dijéramos que todavía programamos en Algol
MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.<https://dtss.dartmouth.edu/sciencearticle/index.html>
COBOL no está muerto, pero es difícil acceder a él. La razón es que casi no hay herramientas de código abierto que se puedan usar en Linux
En OCamlPro iniciaron un proyecto llamado SuperBOL para crear un entorno open source centrado en el compilador open source GnuCOBOL. GnuCOBOL ya es maduro y también se usa en empresas
Ya publicaron una extensión de VSCode con LSP para COBOL, ofreciendo una experiencia moderna de IDE, y según las necesidades de los clientes también están trabajando en otras herramientas
COBOL se puede aprender en uno o dos días, y hay gente que quiere probar ese trabajo “aburrido” de COBOL, pero no tiene experiencia con mainframes
https://gnucobol.sourceforge.io/
https://cobolworx.com/pages/cobforgcc.html
Como siempre, este tipo de discusión depende de cómo se defina “muerto” y “vivo”
Si se puede decir que una tecnología está muerta cuando ya no se construyen nuevos negocios sobre ella, entonces no sería incorrecto decir que COBOL está muerto. Lo mismo aplica a la plataforma IBM 390x, es decir, Z/OS, que normalmente se usa como representación indirecta de COBOL
Por otro lado, si se considera viva mientras siga usándose en entornos de operación, entonces COBOL claramente sigue vivo, y mucho más que muchas tecnologías más jóvenes que él
Aun así, no hace falta tomar eso como una ventaja de COBOL o del ecosistema mainframe. Las organizaciones tienden a aferrarse a lo primero que funcionó bien, y en lugares como gobiernos, bancos y aerolíneas, que fueron protagonistas de la digitalización inicial, esa primera elección solía ser simplemente los mainframes de IBM y el software que corría sobre ellos
Nuestro mainframe procesa sin problemas 100 millones de transacciones por hora. Además, la mayoría son síncronas, y cada transacción lleva a varias transacciones SQL
La consistencia eventual también es una opción, pero encaja muy mal con el sector financiero, y probablemente también con defensa, seguros, medicina y salud pública. El trabajo puede dividirse en particiones, pero aparecen problemas de consistencia al cruzar los límites entre shards
COBOL todavía no está muerto, pero va lentamente hacia allá. No conozco ningún banco que no esté trabajando activamente para salir del mainframe. Aun así, la mayoría de las estimaciones dicen que los mainframes y COBOL seguirán existiendo al menos hasta 2050
Es decir, todavía se escribirá código COBOL durante los próximos 26 años. Los programadores de COBOL siguen teniendo alta demanda y buena paga, así que incluso si alguien empieza ahora una carrera como programador COBOL, podría cubrir un período laboral casi equivalente a toda una vida
La barrera de entrada siempre fue extremadamente alta, y en esa época los principales clientes también eran aseguradoras antiguas, bancos y gobiernos. Que una empresa nueva pudiera hacer computación fue algo más propio de la era posterior a las minicomputadoras
En ese sentido, no ha cambiado mucho, y considerando el mercado objetivo del producto, no me parece adecuado usar como criterio de vida o muerte de la plataforma si “la usan nuevos negocios”
Incluso una nueva unidad de negocio o un equipo interno tipo startup, por ejemplo para una nueva categoría de producto de seguros, podría escribir parte de eso en COBOL si necesita integrarse con el resto de los sistemas del banco
Como mínimo, aunque no se escriba directamente en COBOL, podría desplegarse sobre la infraestructura de ejecución COBOL existente, es decir sobre Z/OS, porque no hay presupuesto para comprar nuevos racks x86 y contratar gente que los administre
La nube es el nuevo mainframe, pero en una versión peor. Tiene todas las desventajas, pero no la mayor ventaja
Antes se podían construir servicios muy estables y de muy buen rendimiento con CICS, y llamar a otros servicios dentro de la misma transacción. La plataforma se encargaba de cosas complejas como mantener la integridad de los datos
Si intentas escribir AWS Lambda que se llamen entre sí dentro de la misma transacción, la diferencia se nota
Y no entiendo por qué el punto de comparación es “AWS Lambda llamándose entre sí dentro de la misma transacción”. ¿El despliegue en mainframe también era tan simple como lanzarle un
.zipcon código a una API a la que los desarrolladores tuvieran acceso?Algunas personas lo toman como si yo estuviera eligiendo o prefiriendo COBOL por encima de los lenguajes modernos y lo critican, pero no es esa la idea. Solo fue una observación de abogado del diablo vista desde fuera de lo convencional
Irónicamente, COBOL ya era un lenguaje seguro en memoria y estable, más fácil de leer y entender que Rust. Pero como nadie quiere usarlo, terminó siendo un lenguaje “muerto”, y aun así los sistemas que hicieron posible la modernidad corren sobre él
Por ejemplo, si comparas código en Rust y en COBOL que recibe un número e imprime si es par o impar, el de COBOL se lee de forma más directa
No sé si ofrece el mismo nivel de rendimiento, si se integra con código nativo de otros lenguajes de la misma manera, si tiene un gestor de paquetes usable sobre un sistema de módulos que ayude a la composición y la compatibilidad hacia atrás, o si puede expresar cómodamente la forma de los datos y de los errores como los tipos de datos algebraicos de Rust
Así como hay razones por las que COBOL se sigue usando, también hay buenas razones por las que se crearon lenguajes nuevos
De hecho, si le agregas el boilerplate necesario para hacer un programa COBOL ejecutable, termina imprimiendo “even” con la entrada
abcy “odd” con la entrada12También es raro cuestionar específicamente la sintaxis de Rust. Como la mayoría de los lenguajes de hoy, Rust usa en general una sintaxis de la familia de C con un poco de OCaml mezclado. Más allá de la sintaxis, Rust y COBOL tienen objetivos muy distintos, así que la razón de existir de Rust no desaparece con un “simplemente usemos COBOL”
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
Aparecen cosas como
ALLOCATE, asignación de direcciones de puntero yFREEEste tuit me gusta de una forma curiosa
https://x.com/grauhut/status/1000017084435312642
Traducido, dice: “Encontré COBOL en un cliente. Está bien. Es un mainframe. No tiene nada especial. El último comentario era de 1985. La autora era mi madre”