Le langage de développement, signifiant « Common Business Oriented Language », a été créé spécifiquement pour les programmes de gestion. Il fête aujourd'hui ses 60 ans.
Le projet a été initié dans le cadre d’une demande du Pentagone : développer un langage indépendant des constructeurs pour les logiciels au sein des administrations. Il fut largement influencé par FLOW-MATIC et COMTRAN.
Moins de six mois ont été nécessaires à sa création, une rapidité qui, couplée à la vision de l’époque, lui ont valu quelques interprétations peu flatteuses de son acronyme, comme « Compiles Only Because Of Luck ».
Le langage est cependant toujours vivant. Comme beaucoup d’autres, il a évolué par étapes majeures. Après la mouture initiale de 1968, d’autres sortent en 74, 85 et 89. C’est cette dernière qui marque un tournant, l’ANSI et l’ISO se penchant sur son cas.
La dernière version date de 2014 et est estampillée ISO/IEC 1989:2014. Les concepts centraux du langage ont évolué avec le temps pour se moderniser. En 2002 avaient ainsi été introduite la programmation orientée objet, accompagnée notamment de l’Unicode et du XML.
Cobol est encore surtout utilisé dans les banques. Bill Curtis, directeur du CISQ (Consortium for IT Software Quality) et l’un des créateurs du CMM (Capability maturity model), indiquait encore en 2013 que le Cobol présentait d’indéniables atouts en sécurité et performances.
Commentaires (44)
#1
Je suis curieux, en quoi Cobol présente “d’indéniables atouts en sécurité et performances” ? C’est un fantasme de développeurs Cobol ou ça correspond à une certaine réalité ?
#2
COBOL étant très bordé, on ne peut faire tout et n’importe quoi avec notamment côté système.
C’est dans ce sens qu’il s’est exprimé je pense.
#3
Pour la sécurité : c’est pas un Jean-Kevin qui vient de lire un tuto sur le SDZ sur comment écrire un hello world en python qui code en Cobol.
" />
Pour la performance : vu le niveau du langage, plus bas, il faut taper dans la langage machine.
#4
#5
#6
On ressort la blague : dans un lointain futur, un humain est sorti de stase cryogénique et se voit dire “Bonjour. Nous sommes en 9999. Vous connaissez le COBOL ?”.
#7
Sur la sécurité je ne sais pas, mais sur les perfs, les quelques banques qui ont migré leur code en java ont généralement eu une inflation considérable de leur infra à service rendu équivalent. Genre doublement du nb de serveurs voire pire…
#8
Il y a des chances que ce soit en effet le plus vieux encore utilisé en effet.
Historiquement, c’est l’un des premier avec une volonté de faire un langage générique à toutes les machines avec une porté autre que purement R&D et avec un consortium derrière qui en avait l’utilité. Son but était d’être utilisé, il est orientés pour automatisé la gestion de données dans une entreprises ou une administration (le B de COBOL est pour Business).
#9
C’est aussi un langage dans lequel 889 + 122 peut faire 011 si on taille les zones trop petites, sans compter les pertes de signe si on oublie de signer une zone, etc … quant aux dates, c’est juste l’enfer, rien n’existe…. Pipoux : 10 ans de Cobol, 2 ans de Pacbase
#10
ha ouai. Autant coder en assembleur donc
" />
#11
Comme quoi c’est dans les vieux pots qu’on fait les meilleures soupes ^^
#12
Ca doit être ultra chiant a coder quand on a pris l’habitude des langages de haut niveau.
En tout cas, chapeau, parce que 60 ans en informatique, c’est impressionnant !
#13
#14
Comme dit plus haut, c’est sans doute plus sécurisé parce que personne n’y comprend rien et que les hackers n’ont pas envie de se prendre la tête avec un truc pareil
" />
#15
D’un côté certains organismes tentent de quitter Cobol pour des solutions plus pérennes (et lisibles), souvent Java, parfois (rarement) .NET ou Erlang, de l’autre tu as trois des quatre plus grosses banques de France qui ne jurent que par IBM pour une grosse partie de leur SI et qui investissent durablement dans COBOL… Alors que les performances sont pas si exceptionnelles que ça, que le code est trop complexe pour ce que c’est, et que tu as des limitations totalement débiles (pipoux en a cité quelques unes).
Je pense pas que ce soit le prix de la migration qui soit si prohibitif que ça (chez nous on a calculé que la migration prendrait 10 ans si on faisait ça au fur à mesure des projets), c’est vraiment des décisions de commerciaux qui insistent pour avoir du Cobol et des technos IBM ou Oracle.
#16
#17
C’est surtout plus sécurisé parce que ça tourne majoritairement sur des gros système qui sont peu exposés aux accès Internet, que c’est assez verbeux et facilement compréhensible parce que voulu d’origine assez abordable par les néophytes car conçu à une époque ou l’informatique était du domaine scientifique et non popularisé comme aujourd’hui.
Et tout reste incompréhensible à qui ne s’intéresse pas.
Par ailleurs, le hacking à l’époque se faisait en assembleur…
#18
#19
Je crois que tu t’engage un peu là…
Compte tenu des traitements monolithiques que ces boites ont à gérer, les mainframes leur offre la puissance et la prévisibilité nécessaire.
Je ne pense pas qu’une architecture plus éclatée leur permettrait de tenir leurs engagements fonctionnels.
Il n’y a plus que le cœur du business qui tourne sur ces plateformes le reste est effectivement passé sur d’autres architectures et sont alimentés par les données traitées en central.
#20
Une horreur pour moi le Cobol. J’ai été amené à réécrire (toujours en Cobol) un programme écrit dans les années 80 dans une de mes missions quand je bossais en SSII dans la finance. Et j’ai du l’interfacer avec de nouveaux programmes en C++ et proC, des années après, je suis encore traumatisé
" />.
Même si je n’adhère pas à ce langage disons spécial, il faut savoir que dans les banques sur les mainframes, Il y a beaucoup de programmes qui reposent sur du Cobol, très souvent interconnectés, sur lesquels d’autres solutions sont connectés (et parfois même, dépendants de sociétés tierces, anciennes reposant sur des solutions en Cobol).
Migrer ces solutions qui fonctionnent correctement vers d’autres langages pourrait s’avérer très coûteux et très risqué (on est au cœur du système).
J’ai travaillé au début des années 2000 sur un projet de ce type de migration vers C dans un établissement bancaire. Malgré des mois de dev, et toute un équipe, à la fin du dev, les tests n’ont pas été concluants, et le projet abandonné .
#21
Bah quant tu vois que le support de python 2 devait se terminer en 2015 mais il a été finalement repoussée de cinq années par la PSF. La PSF avait ensuite demandé aux développeurs et aux entreprises qui utilisaient toujours Python 2 de passer à Python 3, mais jusque là, plusieurs entreprises ont encore des projets sous Python 2.
Là il doit se terminer en janvier 2020 mais selon eFinancialCareers, beaucoup d’entreprises comme JPMorgan ne seront pas prêtes à temps “….à l’heure actuelle, la plateforme de trading Athena de JPMorgan est toujours pilotée par Python 2.7.”
Bref python 2 est encore largement utilisé dans le secteur financier et les banques ne sont pas toujours les plus rapides à s’adapter.
Goldman Sachs utilise Python 3.6 dans son package de finances quantitatives qui est open source, mais la banque invite toujours les étudiants à passer les tests Hackerrank en Python 2.
Bref, il semblerait que les banques sont toujours à la traîne lorsqu’il s’agit de migrer d’une technologie à une autre.
#22
La question est le COBOL nous survivra-t-il ?
" />
Conçu par deux femmes.
COBOL turns 60: Why it will outlive us all
#23
#24
Pour bosser dans une banque, un des avantages important du COBOL c’est sa stabilité inégalable. Pas dans le sens “je plante peu”, mais dans le sens “peu d’update des libaries, des API etc…”.
Un projet bancaire, ça peut mettre 6 mois pour être décidé, 6 mois pour les specs, 2 ans de dev et 20 ans de prod. Vous imaginez ça sur le monde web ou linux ou les frameworks changent tous les 3 mois et il faut migrer ou tout réécrire à chaque fois ?
#25
#26
#27
Pas du tout : je code tous les jours dans 2 langages.
" />.
Un du moment (30% de mon temps) et l’autre en BASIC
Bon des fois j’intervertis les instructions, mais globalement, ça va.
Je fais ça depuis 20 ans, je programme depuis 40 ans (j’ai commencé en langage machine à 13 ans).
#28
#29
Chez certains, il y a encore de l’assembleur mainframe qui tourne :-p
#30
Je travaille dans une de ces grandes banques
" /> Chez nous aussi le SI gravite autour d’une base COBOL pour les traitements, mais je pense sincèrement qu’on a les compétences pour réaliser une migration petit à petit (on fait évoluer une partie ? -> on migre). Et les estimations que j’ai vu étaient pas déconnantes (elles ne concernait que la partie banque, pas la partie assurance). Notre SI est plutôt bien découpé, et on peut tout à fait proposer des interfaces modernes aux développeurs plus haut niveau (IHM, filiales, applications, etc.) dont on enlève ensuite la base COBOL en toute transparence.
Je vois le COBOL comme un risque majeur dans les années à venir pour 1) trouver des développeurs qui veulent utiliser cette techno de merde et 2) perdre petit à petit les développeurs existants qui connaissent le fonctionnel et le technique. Mais les grands patrons sont full IBM, malgré toutes les remontées des équipes techniques.
#31
#32
D’aprèshttps://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b , le COBOL est tout aussi mauvais que les autres languages pour le calcul sur les réels, sauf qu’il n’utilise pas le FPU, car faisant obligatoirement du calcul en virgule fixe.
#33
Non, ce n’est pas la seule solution. Voir plus haut pour des pistes.
En gros, on calcule sur des nombres entiers et on place la virgule toujours au même endroit, d’où le nom virgule fixe. Et effectivement, les nombres sont plutôt codés en BCD.
#34
#35
#36
Le COBOL et son fils spirituel, l’ABAP de SAP…
Vos commentaires sur la résistance au changement dans la banque, j’ai les mêmes au quotidien sur mes projets SAP.
#37
Dans ce cas, les 2⁄3 expérimentés de la boite n’étaient pas naïfs et avait surtout flairé le pigeon à qui refourguer le bébé (ils connaissaient le merdier, c’était eux qui le géraient et ça ne les enchantait pas vraiment de faire la migration eux même), il ont fait en sorte de blinder le contrat (je les vois tellement géré ça avec une fausse candeur) pour qu’il n’y ait pas de surprises avec un grand sourire aux lèvres (“Hahaha ! Les cons !”). Bon, du coup le prestataire a bien eu mal au cul (comme j’ai dit, il me semble que c’était Oracle directement, ça reste donc assez relatif).
#38
Le côté chiant de tout ça, c’est quand toi tu es au milieu d’une guerre de bistouquette et que tu leur demande à un moment : “sinon, on fait quoi pour avancer ?”
Moi ça me dérange pas d’être payé à rien foutre, mais j’ai parfois l’impression d’être le seul à voir l’intérêt du client là où lui-même en a rien à cirer de jeter sa thune par la fenêtre.
#39
#40
#41
#42
Étrange qu’IBM propose maintenant des machines capables de traiter jusqu’à 1000 milliards de transactions par jour, non ?
https://www.lemondeinformatique.fr/actualites/lire-avec-le-z15-ibm-renforce-la-p…
#43
#44
BASIC, tu appelles ca un language évolué ? C’est un trol rassure moi !