- Un article publié dans le magazine Technical Support en juin 1992 proclamait déjà la mort de COBOL, mais l’essentiel est que, même 30 ans plus tard, ce langage n’a pas complètement disparu
- La plupart des mots à la mode de l’époque, comme les 4GL, n’ont pas duré, mais COBOL est resté en vie plus longtemps qu’un grand nombre d’alternatives arrivées plus tard
- Le facteur décisif qui a permis à COBOL de continuer à tourner a été le problème de l’an 2000 (Y2K), et la réponse réelle a nécessité de former une nouvelle génération de programmeurs COBOL
- Un langage qui a un jour disposé d’une grande base installée peut se maintenir non pas en disparaissant brusquement, mais en laissant une longue traîne à mesure que le nombre de nouveaux apprenants diminue
- Le grand-père de l’auteur est décédé le 1er septembre 2024 à l’âge de 91 ans, et le texte mêle souvenirs personnels et anciennes prédictions technologiques
La déclaration de « mort de COBOL » existait déjà en 1992
- Le grand-père de l’auteur a publié dans le magazine Technical Support de juin 1992 un texte annonçant la mort de COBOL
- Le texte de l’époque emploie des termes caractéristiques de son temps, comme 4GL, et l’auteur ajoute que COBOL a survécu plus longtemps qu’une bonne partie des exemples de 4GL listés sur Wikipedia
- Le texte original est conservé dans les archives de la NaSPA : http://www.naspa.net/magazine/1992/t9206003.txt
- Le texte de 1992 distingue plusieurs sens du mot « dead » et présente COBOL comme une sorte de zombie : mort, mais pas disparu
- Autocoder est aussi présenté comme un prédécesseur de COBOL, comparé comme exemple d’un langage considéré comme mort mais dont certaines traces peuvent subsister
La longue vie de COBOL prolongée par Y2K
- L’un des grands facteurs qui ont permis au zombie COBOL de continuer à avancer a été le problème de l’an 2000 (Y2K)
- Le sujet a fait les gros titres à l’époque et, même si l’on a ensuite eu l’impression qu’il ne s’était rien passé, c’était en réalité un problème gigantesque
- La réponse a nécessité de former une nouvelle génération de programmeurs COBOL
- Ce processus a pu contribuer à prolonger encore la durée de vie de COBOL
- L’auteur dit qu’il utilise désormais rarement le mot dead pour parler des langages de programmation
- Un langage qui a un jour bénéficié d’une grande base installée a du mal à mourir complètement
- À la place, il laisse une longue traîne en s’estompant peu à peu à mesure que les nouveaux programmeurs cessent de l’apprendre
Un moment de l’histoire technologique qui mène à un souvenir personnel
- Le grand-père de l’auteur est décédé le 1er septembre 2024 à l’âge de 91 ans
- La cause officielle du décès est une pneumonie
- La grand-mère est décédée en avril de la même année, et le grand-père avait demandé à ne pas recevoir de traitement
1 commentaires
Avis de Hacker News
L’article mentionne les 4GL ; cela faisait vraiment très longtemps que je n’avais pas entendu ce terme.
COBOL promettait lui aussi que, comme il « ressemblait à des phrases lisibles par des humains, on n’aurait plus besoin de programmeurs », ce qui rappelle les plateformes low-code ou le code généré par des LLM aujourd’hui.
Le problème, c’est qu’une personne ordinaire n’est généralement pas capable de décrire et de découper un problème avec assez de précision pour obtenir une solution qui fonctionne. Si elle parvient à mener ce processus, elle finit en fait par devenir programmeuse ; et la leçon essentielle de COBOL, c’est que la raison pour laquelle on a besoin de programmeurs ne tient pas seulement à l’interface de l’ordinateur ou au langage.
L’idée était plutôt de permettre à quelqu’un qui connaissait bien les processus métier de les transcrire en COBOL sans avoir à apprendre en détail le fonctionnement d’un ordinateur, un peu comme les analystes ou les responsables data qui dialoguent avec des bases de données en SQL.
COBOL et les 4GL avaient principalement pour objectif de construire des applications métier comme la paie, la banque, les RH ou la gestion des stocks, avec un accent particulier sur le traitement batch pour réduire les gros traitements répétitifs, notamment les rapprochements et calculs de règlement.
C’est un produit d’une époque où il n’existait pas de SGBD dédié ; l’organisation des fichiers et les verbes liés aux fichiers y sont donc très développés, avec certains aspects qui ressemblent au SQL d’aujourd’hui.
Même si un LLM génère magiquement une solution, la responsabilité de formuler le problème de manière concise et exacte ne fait que remonter d’un niveau.
Au bout du compte, on « programme » par prompt, puis on relit le résultat formalisé proposé par le LLM, c’est-à-dire le code. La nature de la programmation peut se transformer en prompt engineering, mais la nécessité de comprendre le code comme langage formel demeure.
L’article dit que les 4GL étaient très à la mode au début des années 1990, mais je doute que ce soit vrai en dehors des mainframes. Dès le départ, le mouvement 4GL était fortement orienté mainframe, et Wikipédia mentionne aussi, parmi ses objectifs initiaux, la réduction du nombre de cartes perforées nécessaires à un programme.
En 1992, Linux existait déjà, le travail sur Python était en cours, Perl gagnait en popularité et Haskell avait déjà une première version. La frontière technologique se déplaçait des stations de travail coûteuses vers les PC grand public, et je pense que les concepteurs de langages, même lorsqu’ils créaient des choses que l’on peut rétrospectivement considérer comme des 4GL — comme dBase, HyperTalk ou AppleScript — n’avaient pas particulièrement le concept de 4GL en tête.
Je suis d’accord pour dire que du texte ressemblant au langage naturel est une mauvaise idée pour la plupart des usages de programmation, mais je ne pense pas que ce soit la seule raison de l’échec du mouvement 4GL. La plupart des 4GL ne ressemblaient d’ailleurs pas davantage au langage naturel que COBOL, qui est un 3GL.
Le problème plus important, c’est que le mouvement 4GL n’a jamais vraiment su définir ce qu’était cette nouvelle génération, ni ce qui la rendait utile. Les 2GL ont apporté la traduction de l’assembleur vers le langage machine, les 3GL la rupture majeure de la compilation, mais, pour les 4GL, le seul changement à peu près définissable était quelque chose comme « intégrer davantage dans le langage des fonctionnalités qui se trouvaient auparavant dans des routines ou bibliothèques externes ».
Cette approche a bien fonctionné pour les langages spécifiques à un domaine, ce qui a donné des 4GL réussis comme SQL, R ou MATLAB. En revanche, l’idée d’un 4GL généraliste me semble avoir été vouée à produire des langages excessivement obèses.
Aujourd’hui, presque personne ne sait encore faire cela, ni n’a besoin de le faire.
Dans ce contexte, Scala me vient à l’esprit. À la façon dont l’article décrit COBOL, je pense que Scala est en pratique assez proche d’un langage mort.
Il y a encore beaucoup d’entreprises et de services qui ont des composants critiques écrits en Scala, mais l’intérêt pour les nouveaux projets s’est fortement éteint.
Entre 2012 et 2014, j’ai l’impression qu’on voyait sans arrêt sur HN des articles du genre « faire X en Scala », alors qu’aujourd’hui on n’en voit presque plus. C’est peut-être un phénomène naturel et inévitable, mais c’est dommage dans la mesure où Scala avait de bonnes idées que d’autres langages grand public n’ont toujours pas reprises.
Il y a même des projets assez importants pour l’écosystème interne, comme des systèmes de test, et les ingénieurs qui avaient créé ce genre de systèmes à l’époque sont aujourd’hui pour la plupart devenus cadres dirigeants.
Certains défendent encore les choix technologiques de l’époque, tandis que d’autres se montrent plus ouverts quand on leur donne l’occasion de prendre du recul. Globalement, l’ambiance est plutôt que si Kotlin avait existé à ce moment-là, ou si Swift avait été utilisable pour des services backend, ils n’auraient pas choisi Scala.
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
L’emballement initial est retombé, mais ce n’est pas grave. Tous les langages connaissent des cycles de hype, et les prédictions se trompent la plupart du temps. Les langages de programmation grand public sont désormais difficiles à tuer, comme COBOL.
On annonce la mort de Java depuis 2001, mais il a survécu à la bulle Internet, à .NET, au P de LAMP, à Ruby, à JS et à Go. On disait aussi que Python allait mourir lors du passage à la version 3, quand des gens partaient vers Ruby.
Scala est le langage de programmation fonctionnelle le plus populaire au monde, ses outils et bibliothèques sont bons, et Scala 3 me semble être une excellente mise à niveau.
Il a été énorme à une époque et donnait l’impression d’être partout, mais il est maintenant de plus en plus relégué à des niches. Comme COBOL, il reste encore beaucoup de code Perl en production dans le monde réel.
Jack Henry, SiriusXM, Starbucks, les services de streaming de Disney et Capitol One ont aussi créé, au cours des cinq dernières années et jusqu’à aujourd’hui, de nouveaux projets Scala côté services, pas en data science.
Il y a bien sûr beaucoup d’autres équipes, mais rien qu’avec les noms connus qui me viennent immédiatement à l’esprit, il est difficile de dire que le langage est mort.
En revanche, les postes liés aux frameworks centrés sur Play et Akka, ainsi que les jobs Spark pur hors Airflow, semblent diminuer. À mon avis, il s’agissait surtout de postes liés à des frameworks issus de l’écosystème Scala, où Scala lui-même était souvent secondaire.
J’aime Scala, mais cela a toujours été un langage de niche, tandis que COBOL était vraiment partout.
Un jour, je me dis qu’il faudra que je m’assoie pour essayer moi-même des langages legacy comme Fortran, COBOL, Ada ou APL.
Leur popularité a clairement baissé, mais ils restent utilisés dans des endroits importants.
En même temps, je pense aussi aux quantités énormes de code Java. Pour le meilleur ou pour le pire, Java a presque tout dévoré dans l’entreprise, et je me demande s’il y a une raison pour que, dans 30 ou 40 ans, seuls des retraités utilisent Java pour maintenir de vieux systèmes bancaires.
Le fait qu’il s’agisse d’énormes bases de code monolithiques ou de plateformes joue sans doute aussi. Le langage n’est pas ésotérique ni difficile ; il y a simplement trop de code dont la structure est difficile à discerner.
Je pense qu’il occupera encore environ 0,05 % du marché pendant les 100 prochaines années.
Cela dit, ces dernières années, la plupart du nouveau code est écrit en Kotlin.
Personnellement, j’y suis aussi attaché : dans les années 90, on l’utilisait réellement sur PC dans mon entreprise. Il s’agissait de comprendre comment y faire entrer les données, et j’ai fini par écrire une routine qui traitait les nombres à virgule flottante comme des vecteurs de 1 et de 0, en modifiant les bits pour les convertir du format Microsoft au format IEEE.
Bien sûr, c’était à l’époque où je portais un oignon à la ceinture.
Pour des simulations numériques pures, je pense que je préférerais Fortran à C++ ou Python. NumPy mis à part, bien sûr, puisque NumPy lui-même s’appuie au final sur Fortran et C++.
Pour la Carolina Code Conference 2025, nous cherchons toujours un intervenant COBOL.
En particulier depuis la récente mise à jour de GnuCOBOL, cela fait un moment que j’aimerais inclure une présentation sur COBOL.
https://gnucobol.sourceforge.io/
https://carolina.codes
« Je ne sais pas à quoi ressemblera le langage de l’an 2000, mais il s’appellera Fortran. » — Tony Hoare
On peut dire que COBOL est vivant parce qu’il a continué à évoluer à chaque époque. Le COBOL moderne est assez différent du COBOL des années 1950 que les gens imaginent instinctivement en entendant son nom.
C’est un peu comme si Java s’était appelé Algol-94, et que nous disions donc encore que nous programmons en Algol.
MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.<https://dtss.dartmouth.edu/sciencearticle/index.html>
COBOL n’est pas mort, mais il est difficile d’accès, car il existe très peu d’outils open source utilisables sous Linux.
Chez OCamlPro, nous avons lancé un projet appelé SuperBOL pour construire un environnement open source autour du compilateur open source GnuCOBOL. GnuCOBOL est déjà mature et utilisé en entreprise.
Nous avons déjà publié une extension VSCode intégrant un LSP pour COBOL, afin d’offrir une expérience d’IDE moderne, et nous travaillons aussi sur d’autres outils en fonction des besoins des clients.
On peut apprendre COBOL en un ou deux jours, et j’aimerais bien essayer ces tâches COBOL « ennuyeuses », mais je n’ai pas d’expérience mainframe.
https://gnucobol.sourceforge.io/
https://cobolworx.com/pages/cobforgcc.html
Comme toujours, ce genre de discussion dépend de la façon dont on définit « mort » et « vivant ».
Si l’on peut dire qu’une technologie est morte lorsque plus aucune nouvelle activité n’est construite dessus, alors on peut considérer que COBOL est mort. Il en va de même pour IBM 390x, c’est-à-dire la plateforme Z/OS, souvent utilisée comme métonymie de COBOL.
À l’inverse, si l’on considère qu’une technologie est vivante tant qu’elle est encore utilisée en production, alors COBOL est évidemment vivant, et bien plus vivant que beaucoup de technologies plus jeunes que lui.
Mais il n’est pas nécessaire d’y voir un avantage de COBOL ou de l’écosystème mainframe. Les organisations ont tendance à s’accrocher à ce qui a bien fonctionné au départ, et dans les secteurs qui ont été les pionniers de la numérisation — administrations, banques, compagnies aériennes — ce premier choix était généralement un mainframe IBM et les logiciels qui tournaient dessus.
Notre mainframe traite confortablement 100 millions de transactions par heure. En plus, la plupart sont synchrones, et chaque transaction déclenche plusieurs transactions SQL.
La cohérence éventuelle est une option, mais elle convient très mal à la finance, et c’est probablement aussi le cas dans le militaire, l’assurance, la médecine et la santé publique. On peut aussi partitionner le travail, mais des problèmes de cohérence apparaissent lorsqu’on franchit les limites de shards.
COBOL n’est pas encore mort, mais il s’en approche lentement. Je ne connais aucune banque qui ne travaille pas activement à sortir des mainframes. Cela dit, les prévisions que j’ai vues indiquent que les mainframes et COBOL resteront présents au moins jusqu’en 2050.
Autrement dit, cela signifie encore 26 ans de code COBOL. Les programmeurs COBOL sont très demandés et plutôt bien payés ; commencer aujourd’hui une carrière de programmeur COBOL peut donc encore remplir une période de travail proche d’une vie entière.
La barrière à l’entrée a toujours été extrêmement élevée, et les principaux clients de l’époque étaient déjà de vieilles compagnies d’assurance, des banques et des administrations. Ce n’est qu’avec l’arrivée des mini-ordinateurs qu’il est devenu plus réaliste pour de nouvelles entreprises de faire de l’informatique.
En ce sens, peu de choses ont vraiment changé, et si l’on tient compte du marché cible du produit, je ne pense pas que le critère « est-ce utilisé par de nouvelles entreprises ? » soit pertinent pour juger si une plateforme est vivante ou morte.
Une nouvelle division ou une équipe de startup interne, par exemple pour une nouvelle catégorie de produits d’assurance, peut devoir écrire une partie en COBOL pour s’intégrer au reste des systèmes de la banque.
À tout le moins, même si ce n’est pas écrit directement en COBOL, faute de budget pour acheter de nouveaux racks x86 et les personnes chargées de les gérer, cela peut être déployé sur l’infrastructure d’exécution COBOL existante, c’est-à-dire sur Z/OS.
Le cloud est le nouveau mainframe, mais en pire. Il en a tous les inconvénients sans en avoir le plus grand avantage.
Avant, avec CICS, on pouvait créer des services très stables et performants, et appeler d’autres services au sein de la même transaction. La plateforme gérait les choses complexes, comme le maintien de l’intégrité des données.
Essayez d’écrire des AWS Lambda qui s’appellent mutuellement dans la même transaction, et la différence devient évidente.
Et je ne vois pas pourquoi le point de comparaison serait « des AWS Lambda qui s’appellent mutuellement dans la même transaction ». Le déploiement sur mainframe était-il aussi simple que de lancer un
.zipcontenant du code vers une API à laquelle le développeur avait accès ?Certains interprètent cela comme si je choisissais ou préférais COBOL aux langages modernes, et me critiquent pour ça, mais ce n’est pas ce que je veux dire. Je fais seulement une observation à la façon de l’avocat du diable, en sortant du cadre
Ironiquement, il existait déjà avec COBOL un langage sûr du point de vue mémoire, stable, plus facile à lire et à comprendre que Rust. Mais comme personne ne veut l’utiliser, il est devenu un langage « mort », alors que les systèmes qui rendent possible le monde moderne tournent dessus
Par exemple, si l’on compare du code Rust et du code COBOL qui lisent un nombre et affichent s’il est pair ou impair, la version COBOL se lit plus directement
On ne sait pas s’il offre le même niveau de performances, s’il s’intègre de la même manière avec du code natif écrit dans d’autres langages, s’il dispose d’un gestionnaire de paquets utilisable au-dessus d’un système de modules favorisant la composition et la rétrocompatibilité, ou s’il permet d’exprimer facilement les formes des données et des erreurs comme les types de données algébriques de Rust
Tout comme il y a des raisons pour lesquelles COBOL est encore utilisé, il y a aussi de bonnes raisons pour lesquelles de nouveaux langages ont été créés
En réalité, si l’on ajoute le boilerplate nécessaire pour obtenir un programme COBOL exécutable, il affiche « even » avec l’entrée
abcet « odd » avec l’entrée12Il est aussi particulier de s’en prendre spécifiquement à la syntaxe de Rust. Comme la plupart des langages actuels, Rust a globalement une syntaxe de la famille C, avec quelques éléments d’OCaml. Au-delà de la syntaxe, Rust et COBOL ont des objectifs très différents, donc dire « utilisons simplement COBOL » ne fait pas disparaître la raison d’être de Rust
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
On y voit du code comme
ALLOCATE, la définition d’adresses de pointeurs etFREEJ’aime étrangement bien ce tweet
https://x.com/grauhut/status/1000017084435312642
En traduction, cela donne : « J’ai trouvé du COBOL chez un client. Ça va. C’est un mainframe. Rien de spécial. Le dernier commentaire datait de 1985. Son autrice était ma mère »