Tendances radar à surveiller: mai 2020 – O’Reilly – O’Reilly Radar

Nous avons tous vu que le monde (enfin, les gouvernements, en particulier les gouvernements des États, pour ne rien dire des banques) hurle pour les programmeurs COBOL – un cri qui monte à peu près tous les cinq ans. Nous traversons d’une manière ou d’une autre la crise actuelle, puis les gens oublient que cela a toujours été un problème. Il est temps de demander ce qu’est réellement la crise et pourquoi elle continue de revenir.

COBOL est l’un des premiers langages de programmation; il a été inventé en 1960 et a pris de l’importance assez rapidement en tant que langage nécessitant un minimum de compétences en programmation. (De vrais programmeurs ont écrit FORTRAN.) Ce n’est pas ainsi que les inventeurs de COBOL l’ont dit, mais c’est dans une certaine mesure ce qu’ils voulaient dire: un langage qui était censé être facile à apprendre pour les programmeurs, et qui pourrait également être compris par les hommes d’affaires. Il suffit de regarder ce que COBOL signifie: «Common Business-Oriented Language». Un langage de programmation pour les entreprises.

Apprenez plus vite. Creusez plus profondément. Voir plus loin.

L’influence de COBOL s’est estompée dans les années 80, et maintenant, il y a des milliards de lignes de code dans les gouvernements, les banques, les entreprises et ailleurs remplissant des fonctions commerciales essentielles sans personne pour les maintenir. Les programmeurs COBOL ont vieilli et ont pris leur retraite, et personne n’est venu après.

À quoi ressemble la langue? J’ai eu l’occasion de regarder le code COBOL, et ma réaction n’a pas été ce à quoi je m’attendais. Il ne ressemble à aucune langue «moderne». Mais ce n’est pas une étrange antiquité des jours avant que les gens sachent comment concevoir des langues décentes. COBOL est un langage bien pensé spécifique au domaine. C’est un langage commercial qui utilise le langage des hommes d’affaires. Vous vous souvenez quand les rubis étaient fiers de pouvoir écrire des déclarations qui ressemblaient à un anglais idiomatique? Et qu’ils pourraient utiliser la métaprogrammation pour créer des langages spécifiques à un domaine qui utilisent les vocabulaires et les concepts de différents domaines d’application? Ce n’était pas une mince affaire. Et COBOL l’a fait 40 ans auparavant.

Comme d’autres langages utiles, COBOL n’a jamais disparu; mais il a eu étonnamment peu d’influence sur le développement des langages informatiques, et cela donne l’impression qu’il est mort. Dans 10 Most (ly) Dead Influential Programming Languages, Hillel Wayne soutient que COBOL a eu peu d’influence sur le développement des langages de programmation car il venait du monde des affaires, et les universitaires ne s’y intéressaient pas – pour les universitaires, ce «n’était pas vaut la peine de prêter attention.  » Qui veut de toute façon écrire du code lisible par les banquiers et les hommes d’affaires? L’attrait de parler un langage secret que personne d’autre ne comprenait était toujours attrayant pour les programmeurs.

COBOL a néanmoins fait un certain nombre d’innovations importantes. Il avait un concept d’enregistrements (comme des lignes dans une base de données), qui était lié à un concept de structures hiérarchiques, dans l’attente de structures C et peut-être même d’objets. Et il a un générateur de rapports – si cela ne semble pas intéressant, rappelez-vous que l’une des premières applications de Perl était la génération de rapports. Et qu’un autre langage précoce presque oublié, RPG, a été inventé uniquement pour générer des rapports. Les rapports ne sont pas glamour, mais ils sont importants.

Syntaxiquement, COBOL a posé une très bonne question: pourquoi devons-nous utiliser le langage bâtard des mathématiques pour déplacer de l’argent en disant quelque chose comme «total = total + dépôt»? Ne serait-il pas plus naturel de DÉPLACER des montants d’un compte à un autre? Ne soyez pas trop excité. MOVE ressemble à une proto-transaction, mais ce n’est pas le cas; c’est juste une mission. Cependant, si vous pensez à déplacer de l’argent plutôt qu’à l’affecter à une variable, ces pensées vous mèneront à des opérations transactionnelles atomiques le plus tôt possible.

Bien sûr, COBOL n’offre pas beaucoup. Alors que COBOL a été mis à jour avec la plupart des fonctionnalités que vous attendez dans un langage moderne (depuis 2002, il est même orienté objet), COBOL a tendance à conduire à un code spaghetti et à des monolithes très maladroits. C’est la programmation des années 60 pour vous. GOTO était une partie essentielle de chaque langage de programmation (même C a une instruction goto). La modularisation n’était pas bien comprise, voire pas du tout. Bibliothèques? Les premières versions de COBOL n’avaient pas de bibliothèque standard, encore moins de bibliothèques définies par l’utilisateur. Cadres Web? Tu ne veux pas savoir. Microservices? Oublie.

Alors, où en sommes-nous maintenant, avec nos milliards de lignes de COBOL qui gèrent les gouvernements et les finances du monde? Je doute qu’il reste de nombreux mainframes des années 1960, mais il y a beaucoup d’émulations de mainframes des années 1960 exécutant COBOL dans le cloud beaucoup plus rapidement que le matériel sur lequel il fonctionnait initialement. Et c’est une stratégie que j’ai vue pour maintenir COBOL: laissez-la telle quelle, exécutez-la sur un émulateur, enveloppez-la dans un microservice écrit dans un langage « moderne » et espérez que vous n’aurez jamais à y toucher. Cela fait gagner du temps, mais même si «l’espoir» peut résoudre le problème immédiat, c’est une mauvaise stratégie à long terme.

Le vrai problème n’est pas seulement le manque de programmeurs parlant couramment un langage qui n’est plus populaire. Il y a aussi des problèmes culturels qui doivent être traités – et qui ont des solutions qui vont au-delà de «former un nouveau lot de programmeurs COBOL». Premièrement, l’une des victimes des «guerres de langues» des années 90 et 00 est que nous avons un nombre croissant de programmeurs qui s’identifient à une seule langue: ce sont des programmeurs JavaScript, ou des programmeurs Java, ou des programmeurs Python, ou des Rubyists. Les conseils de Dave Thomas et Andy Hunt pour apprendre un nouveau langage de programmation chaque année sont tout aussi valables qu’ils l’étaient lorsqu’ils ont écrit pour la première fois. Le programmeur pragmatique; mais cela passe malheureusement inaperçu. Pour être un bon programmeur, vous devez vous exposer à de nouvelles idées, à de nouvelles façons de penser les problèmes et, dans le cas de COBOL, à de vieilles idées. Les programmeurs qui ne peuvent pas être sortis de leur zone de confort ne vont pas apprendre le COBOL; mais à long terme, ils se révéleront moins précieux, quelle que soit la langue moderne qu’ils connaissent.

Deuxièmement, la programmation COBOL nécessite une compréhension de la programmation d’entreprise. Quelle que soit la langue, c’est une spécialité de plus en plus rare. Comment gérez-vous les quantités financières, comme les dollars et les cents? Si vous dites «virgule flottante», allez à l’arrière de la classe. Les erreurs d’arrondi vous tueront. Si vous dites «utilisez des entiers et divisez par 100», ce n’est pas beaucoup mieux. Le problème fondamental est que les nombres binaires ne sont pas bons pour représenter des valeurs décimales décimales. Mais c’est une tradition que la plupart des programmeurs actuels n’ont jamais apprise. (Et nous n’avons même pas commencé à penser aux conversions de devises.)

Troisièmement, les décisions d’ingénierie prises dans les années 60, 70 et même 80 ne sont pas les décisions que nous prendrions aujourd’hui. L’ingénierie était certainement valable pour l’époque, mais les ingénieurs modernes ne comprennent souvent pas pourquoi. J’ai entendu de nombreux programmeurs contemporains parler du problème de l’an 2000 (représentant des années dans les années 1900 avec deux chiffres) comme une «dette technique». Cela représente une mauvaise compréhension des problèmes rencontrés par les programmeurs d’origine. Dans un environnement où les données étaient entrées sur des cartes perforées de 80 colonnes, la sauvegarde de 2 caractères était une grosse affaire. Dans un environnement où les plus grands ordinateurs avaient des mémoires mesurées en kilo-octets (et un petit nombre de K à cela), sauver 2 caractères était une grosse affaire. Ce n’est pas une ingénierie qui doit être répliquée, mais elle doit être comprise.

Quatrièmement, les anciens logiciels d’entreprise étaient monolithiques – et monolithiques dans un sens très profond. Il tendait à modéliser des formulaires que les humains remplissaient et qui ne pouvaient pas être soumis tant que le formulaire n’était pas rempli. Il n’y a souvent aucun moyen de sauvegarder votre travail, car – pourquoi en auriez-vous besoin? Vous êtes allé au bureau du chômage en personne; vous partez lorsque vous remettez la demande à la personne derrière le bureau. Un formulaire incomplet va dans la corbeille; pourquoi y gaspiller un stockage précieux? Mettre une interface Web devant ces monolithes conduit à un résultat prévisible: des formulaires longs et complexes qui peuvent prendre des heures à remplir et qui sont presque inutilisables sur le Web moderne. En créant GetCalFresh, une application simplifiée d’aide alimentaire en Californie, Code for America a constaté que l’ancien formulaire prenait une heure à remplir, mais les candidats comptaient souvent sur des ordinateurs publics dans des bibliothèques qui n’autorisaient pas les sessions de plus d’une demi-heure. Les formulaires incomplets n’ayant pu être enregistrés, il était impossible pour les candidats de terminer leur candidature. Déplacer une application COBOL vers un émulateur, l’exécuter dans le cloud et pirater ensemble une interface Web ne résoudra pas de tels problèmes. La bonne nouvelle est que c’est l’occasion de repenser votre service et de le rendre plus efficace. La mauvaise nouvelle, c’est que ce n’est pas une solution miracle.

Alors, de quoi a-t-on besoin? Oui, nous avons besoin de plus de personnes qui connaissent et comprennent les programmes COBOL. Il y a beaucoup de vieux code qui doit être maintenu, pur et simple. Mais cela va plus loin. COBOL n’est qu’un autre langage de programmation; si nous voulons maintenir (ou remplacer) ce logiciel, nous avons besoin de programmeurs qui comprennent les décisions d’ingénierie qui ont fait du logiciel ce qu’il est. Nous avons également besoin d’ingénieurs et de gestionnaires prêts à examiner notre situation actuelle – par exemple, l’énorme flambée des demandes de chômage – et à penser au-delà de la solution à court terme. Que faut-il pour réinventer les systèmes actuels, plutôt que de simplement les remplacer? Comment peuvent-ils devenir plus centrés sur l’humain? Peuvent-ils être repensés pour correspondre à la façon dont nous vivons et travaillons actuellement? Mettre un front-end Web sur un processus commercial monolithique des années 1950 est la voie de l’échec.

C’est la nouvelle génération de programmeurs COBOL dont nous avons besoin: des gens pour faire le travail fastidieux et peu glorieux de réinventer, de réingénierie et d’automatiser les applications gouvernementales, les applications commerciales, et bien plus encore. Réimaginer ces processus est un travail créatif, mais il nécessite un autre type de créativité que la mise en œuvre d’un nouveau site Web. J’ai déjà écrit sur la distinction entre la programmation en col bleu et en col blanc. COBOL est très, très col bleu. Et très, très important. Chaque fois que le cri des programmeurs COBOL monte, nous nous embrouillons; cette fois, nous devrions faire quelque chose de mieux.

L’avenir de la programmation est de ré-comprendre le passé et de le réinventer pour relever nos défis actuels.

Aider le gouvernement à traverser cette crise.
Nous offrons un accès gratuit à l’apprentissage en ligne O’Reilly à toute personne qui travaille pour une agence du gouvernement américain pour obtenir l’apprentissage dont vous avez besoin, car votre agence répond à une demande sans précédent.

Vous aimerez aussi...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *