Plaidoyer pour COBOL

Peut-être de manière plutôt inattendue, le 14 mars de cette année, la liste de diffusion GCC a reçu une annonce concernant la sortie du tout premier frontal COBOL pour le compilateur GCC. Pour les non-initiés, COBOL a vu sa première version en 1959, ce qui en fait, avec 63 ans, l’un des plus anciens langages de programmation encore utilisé régulièrement. La raison de sa persistance est principalement due à sa concentration depuis le début en tant que langage spécifique à un domaine (DSL) orienté transaction.

Son acronyme signifie Common Business-Oriented Language, qui fait clairement référence au domaine qu’il cible. Même avec la norme COBOL 2014 actuelle, il s’agit toujours essentiellement du même langage principalement orienté transaction, tout en ajoutant la prise en charge des styles de programmation structurés, procéduraux et orientés objet. Dérivant l’essentiel de son cœur du langage FLOW-MATIC de Grace Hopper, il permet de décrire efficacement la logique métier telle qu’on la rencontrerait dans les institutions financières ou les entreprises, dans un anglais clair.

Contrairement à l’ancien projet GnuCOBOL – qui traduit COBOL en C – le nouveau projet frontal GCC-COBOL supprime cette étape intermédiaire et compile directement le code source COBOL en code binaire. Tout cela peut soulever la question de savoir pourquoi une année-homme entière a été investie dans cet effort pour une langue qui a été déclarée «morte» pendant probablement au moins la moitié de ses 63 ans d’existence.

Est-il judicieux d’apprendre ou même d’utiliser COBOL aujourd’hui ? Avons-nous besoin d’un nouveau compilateur COBOL ?

Obtenir la ligne de frappe

Un ordinateur central IBM 704 utilisé au NACA en 1957. (Crédit : NASA)
Un ordinateur central IBM 704 utilisé au NACA en 1957. (Crédit : NASA)

Pour comprendre pleinement d’où vient COBOL, nous devons remonter jusqu’aux années 1950. C’était encore de nombreuses années avant que les mini-ordinateurs comme le PDP-8, sans parler des ordinateurs personnels comme l’Apple I et les parents, ne deviennent une chose. De nos jours, les dinosaures rôdaient dans les profondeurs des universités et des entreprises, avec des mainframes de plus en plus transistorisés et des architectures système très disparates.

Même au sein d’une série de mainframes d’un seul fabricant, de telles différences existaient, par exemple les séries 700 et 7000 d’IBM. Étant donné que chaque ordinateur central devait être programmé pour l’usage auquel il était destiné, généralement des tâches scientifiques ou commerciales, et cela signifiait souvent que les logiciels des anciens ordinateurs centraux d’une entreprise ou d’une université ne fonctionneraient pas sur le matériel plus récent sans modifications ou réécriture, augmentant considérablement le coût. .

Même avant que COBOL n’entre en scène, ce problème a été reconnu par des personnes telles que John W. Backus de renommée BNF, qui a proposé le développement d’une alternative pratique au langage d’assemblage à ses supérieurs chez IBM à la fin de 1953. Cela a abouti au développement de le langage de programmation scientifique FORTRAN, ainsi que le langage de programmation mathématique LISP, tous deux ciblant initialement le mainframe scientifique IBM 704.

FORTRAN et d’autres langages de programmation de haut niveau offrent deux avantages par rapport à l’écriture de programmes dans le langage d’assemblage du mainframe : la portabilité et un développement efficace. Ce dernier est principalement dû à la possibilité d’utiliser des instructions singulières dans le langage de haut niveau qui se traduisent par un ensemble optimisé d’instructions d’assemblage pour le matériel, fournissant un système modulaire qui a permis aux scientifiques et à d’autres de créer leurs propres programmes dans le cadre de leurs recherches. , des études ou d’autres applications plutôt que d’apprendre l’architecture d’un mainframe spécifique.

La fonctionnalité de portabilité d’un langage de haut niveau a également permis aux scientifiques de partager des programmes FORTRAN avec d’autres, qui pourraient ensuite les exécuter sur les ordinateurs centraux de leur institut, quelle que soit l’architecture système de l’ordinateur central et d’autres détails matériels. Tout ce qu’il fallait, c’était un compilateur FORTRAN disponible.

Une console d'opérateur UNIVAC I au Museum of Science de Boston, États-Unis.
Une console d’opérateur UNIVAC I au Museum of Science de Boston, États-Unis.

Alors que FORTRAN et LISP se concentraient sur la facilité de programmation dans les domaines scientifiques, les entreprises avaient des besoins très différents. Les entreprises opèrent selon des ensembles stricts de règles, de procédures qui doivent être suivies pour transformer des intrants tels que des transactions et des flux de revenus en paies et déclarations trimestrielles, conformément aux règles établies par le bureau des impôts et d’autres instances officielles. Transformer ces règles métier écrites en quelque chose qui fonctionnait exactement de la même manière sur un mainframe était un défi important. C’est là que le langage FLOW-MATIC de Grace Hopper, anciennement Business Language 0, ou B-0, a fourni une solution ciblant l’UNIVAC I, le premier ordinateur professionnel dédié au monde.

Les expériences de Grace Hopper ont indiqué que l’utilisation de mots en anglais clair était de loin préférée par les entreprises, plutôt que des symboles et des notations mathématiques. Le rôle de Mme Hopper en tant que conseillère technique auprès du comité CODASYL qui a créé la première norme COBOL a été une reconnaissance à la fois du succès de FLOW-MATIC et de l’expertise de Mme Hopper sur le sujet. Comme elle le dira plus tard dans une interview en 1980, COBOL 60 est à 95 % FLOW-MATIC. Les 5% restants provenaient de langages concurrents – comme le langage COMTRAN d’IBM – qui avaient des idées similaires, mais une implémentation très différente.

Fait intéressant, une caractéristique de COBOL avant la norme de 2002 était son style de codage basé sur des colonnes, qui découle de l’utilisation de cartes perforées à 80 colonnes. Cela nous amène aux nombreuses mises à jour de fonctionnalités de la norme COBOL au fil des décennies.

Normes de leur temps

Un formulaire de codage IBM COBOL des années 1960.
Un formulaire de codage IBM COBOL des années 1960.

Un aspect intéressant des langages particulièrement spécifiques à un domaine est qu’ils reflètent l’état dudit domaine ainsi que celui de la technologie à ce moment-là. Lorsque COBOL a été mis en service dans les années 1960, la programmation n’était pas effectuée directement sur le système informatique, mais généralement avec le code fourni à l’ordinateur central sous la forme de cartes perforées ou, si vous aviez de la chance, d’une bande magnétique. Dans les années 1960, cela signifiait que «l’exécution d’un programme» impliquait de remettre une pile de cartes perforées ou un formulaire de codage spécial aux personnes qui se disputaient l’ordinateur central, qui exécuteraient le programme pour vous et vous remettraient les résultats.

Ces étapes intermédiaires signifiaient une complexité supplémentaire lors du développement de nouveaux programmes COBOL, et le style basé sur des colonnes était également la seule option avec la mise à jour COBOL-85. Cependant, avec la prochaine mise à jour standard en 2002, de nombreuses modifications ont été apportées, notamment la suppression de l’alignement basé sur les colonnes, en adoptant un code de forme libre. Cette mise à jour a également ajouté une programmation orientée objet et d’autres fonctionnalités, y compris plus de types de données aux représentations de chaînes et de données numériques auparavant quelque peu limitées.

Ce qui est resté inchangé, c’est le manque de blocs de code de COBOL. Au lieu de cela, la source COBOL est divisée en quatre divisions :

  • Service d’identification
  • Pôle Environnement
  • Division des données
  • Division de la procédure

La division d’identification spécifie le nom et les méta-informations sur le programme, en plus des spécifications de classe et d’interface. La division environnement spécifie toutes les fonctionnalités du programme qui dépendent du système qui l’exécute, telles que les fichiers et les jeux de caractères. La division de données est utilisée pour déclarer des variables et des paramètres. La division procédure contient les instructions du programme. Enfin, chaque division est subdivisée en sections composées chacune de paragraphes.

Un mainframe IBM z14 de 2017, basé sur IBM z/Architecture CISC ISA.
Un mainframe IBM z14 de 2017, basé sur IBM z/Architecture CISC ISA.

Avec la dernière mise à jour COBOL de 2014, le format de type à virgule flottante a été remplacé par IEEE 754, afin d’améliorer encore son interopérabilité avec les formats de données. Pourtant, comme Charles R. Martin l’a souligné dans The Overflow dans sa solide introduction à COBOL, la bonne comparaison de COBOL serait avec un autre langage spécifique à un domaine comme SQL (introduit en 1974). On pourrait également ajouter PostScript, Fortran ou Lisp à cette comparaison.

Bien qu’il soit techniquement possible d’utiliser SQL et PostScript pour la programmation régulière et d’émuler les fonctionnalités du DSL dans un langage de programmation (système) générique, cela n’est ni rapide ni une utilisation efficace de son temps. Tout cela illustre plutôt la raison d’être pour ces DSL : rendre la programmation dans un domaine spécifique aussi efficace et directe que possible.

Ce point est assez succinctement illustré par le Program Language One (PL/I) d’IBM – introduit en 1964 – qui est un langage de programmation générique destiné à rivaliser avec tout, du FORTRAN au COBOL, mais qui n’a finalement réussi à surpasser aucun de ceux-ci. , sans que ni les programmeurs FORTRAN ni COBOL ne soient convaincus des mérites du PL/I pour y passer.

Il est important de réaliser que vous n’écrivez pas de systèmes d’exploitation et de traitements de texte dans aucun de ces DSL. Ce manque de généricité réduit à la fois leur complexité, et c’est aussi pourquoi nous devrions les juger uniquement sur leurs mérites en tant que DSL pour leur domaine prévu.

Le bon outil

Un aspect intéressant de COBOL était que le comité qui l’avait produit n’était pas composé d’informaticiens, mais plutôt de personnes appartenant au monde des affaires, fortement motivées par les besoins de fabricants comme IBM, RCA, Sylvania, General Electric, Philco et National Cash Register, pour qui une bonne expérience des propriétaires d’entreprise et des agences gouvernementales avec lesquelles ils faisaient affaire était primordiale.

En conséquence, tout comme la façon dont SQL est façonné par la nécessité de définir efficacement les requêtes de base de données et connexes, COBOL a également été façonné au fil des décennies par la nécessité de faire fonctionner les transactions commerciales et la gestion en douceur. Aujourd’hui encore, une grande partie des transactions bancaires et boursières dans le monde est gérée par des mainframes exécutant du code écrit en COBOL, en grande partie en raison de décennies de raffinement du langage pour supprimer les ambiguïtés et d’autres problèmes qui pourraient entraîner des bogues très coûteux.

Comme l’ont montré les tentatives de portage d’applications métier écrites en COBOL, le problème avec le déplacement des instructions d’un DSL vers un langage générique est que ce dernier n’a aucune des hypothèses, des protections et des fonctionnalités qui sont la raison même pour laquelle les DSL ont été créés en premier lieu. . Plus un langage est générique, plus les conséquences involontaires d’une instruction peuvent se produire, ce qui signifie qu’au lieu du portage textuel d’une instruction COBOL ou FORTRAN (ou SQL), vous devez également garder à l’esprit toutes les vérifications, limitations et sécurités de la langue d’origine et de les reproduire.

En fin de compte, toute tentative de portage d’un tel code dans un langage générique entraînera inévitablement la réplication du DSL dans le langage cible, mais avec une probabilité beaucoup plus élevée de bogues pour diverses raisons. C’est-à-dire que si un langage de programmation générique peut implémenter les mêmes fonctionnalités que ces DSL, la vraie question est de savoir si cela est vraiment souhaitable. En particulier lorsque le coût des temps d’arrêt et des erreurs tend à se mesurer en millions de dollars par seconde, comme dans le système financier d’un pays.

L’attrait d’un DSL ici est donc qu’il évite de nombreux cas et problèmes potentiels en n’implémentant tout simplement pas les fonctionnalités qui permettraient ces problèmes.

Où GCC-COBOL s’intègre

Il y a encore aujourd’hui un manque cruel de développeurs COBOL, même si la demande est forte. Bien que GCC-COBOL ne soit – comme GnuCOBOL – pas un compilateur officiellement validé qui serait accepté n’importe où près d’un mainframe fonctionnant sous IBM z/OS dans un institut financier, il offre cependant le rôle inestimable de permettre un accès facile à une chaîne d’outils COBOL. Cela permet ensuite aux amateurs et aux étudiants de se développer en COBOL, que ce soit pour le plaisir ou pour une carrière potentielle.

Une entreprise pourrait également utiliser une telle chaîne d’outils open source pour remplacer les anciennes applications Java ou similaires de traitement de la paie par COBOL, sans avoir à investir dans des chaînes d’outils propriétaires et des écosystèmes associés. Selon le développeur derrière GCC-COBOL dans l’annonce de la liste de diffusion, c’est l’un des objectifs : permettre aux applications COBOL mainframe de fonctionner sur des systèmes Linux.

Bien que les institutions financières soient encore très susceptibles de sauter sur un mainframe système IBM Z (le « Z » signifie « Zero Downtime ») et un contrat de service à toute épreuve associé, il est bon de voir un DSL aussi important devenir plus facilement accessible à tous, avec sans attaches.