COBOL reste-t-il plus pertinent que Java ?

L’héritage du COBOL

Pourquoi pensons-nous que le COBOL est mort, alors que pourtant, il existe encore plus de lignes de COBOL que de n’importe quel autre langage ?

COBOL, Common Business Oriented Langage, n’a jamais été considéré comme un langage à la pointe de l’innovation, excepté pour un aspect : sa capacité à décrire les choses très clairement et précisément. Cela est dû à son design dont une base était d’en faire un langage qui se rapproche de la langue anglaise naturelle.

Les types de données étaient alloués de façon statiques et spécifiquement. Si vous souhaitiez un nombre à virgule flottante, avec 7 décimales, vous le décriviez ainsi : PIC 999V9999999. Le concept de base est de décrire exactement ce qu’on souhaite et c’est ce qui est exactement retourné.

Dans cette même logique, le code était simple. Vous décrivez le programme en termes de procédures ou paragraphes. Le code exécutable était aussi simple.

001000* THIS IS A COBOL COMMENT

001010* LOTS OF REALLY VERBOSE STUFF HERE...

001020     ADD LINE1 LINE2 LINE3 LINE4 GIVING SUB-TOTAL.

001030     MULTIPLY SUB-TOTAL BY TAX-RATE GIVING TAX.

001040     ADD SUB_TOTAL TAX GIVING TOTAL.

001050* MORE REALLY VERBOSE STUFF HERE.

Vous pouvez également utiliser une méthode moins scolaire pour calculer le total, même en COBOL. Le langage offre des expressions avancées comme COMPUTE.

La puissance du langage COBOL

Rappelez-vous : COBOL est un Common Business Oriented Language. C’était avant le Big Data, avant la data science,  et le Machine Learning s’apparentait à de la magie.

COBOL a été conçu pour fournir de la puissance de traitement aux entreprises. Cela signifie pouvoir expliquer les  choses à une époque où  le système le plus complexe était des machines mécaniques à additionner.

Pour ces personnes, il était aisé de lire des descriptions, formulées simplement, spécifiant ce que cela devait produire – ajouter cela pour avoir tel résultat, multiplier ce nombre par un autre puis ajouter tel chiffre donne ce résultat.

Mais aujourd’hui, le contexte est différent. Les personnes sont habituées aux ordinateurs, leurs smartphones délivrent plus de puissance et ont plus de mémoires que les plus puissants des  mainframes de l’époque. Cela a forgé une certaine confiance  dans la puissance de la machine.

Les gens sont aussi habitués à ne pas disposer des mêmes capacités de contrôle qu’auparavant.  J’ai dû  par exemple expliquer à deux sénateurs comment certaines lignes spécifiques de COBOL définissaient les règles fiscales. Aujourd’hui, je n’aurai plus à leur montrer le code. Tout le monde est suffisamment proche des concepts de la programmation.

Les problèmes à résoudre sont aussi différents. Dans les années 80, le code était conçu autour des traitements en mode batch. Les  systèmes accumulaient les modifications sur une période données  (généralement sur une journée) et mettaient en place chacune de ces modifications lors d’une seule exécution.

Aujourd’hui, les systèmes répondent à des centaines de milliers de transactions en temps réel. Les émetteurs de cartes de crédit peuvent par exemple identifier en quelques secondes une utilisation frauduleuse d’une carte, envoyer une  notification à un utilisateur dont la carte a pu être voler. Les applications de trading doivent aussi réagir en l’espace d’une milliseconde, et appliquer des algorithmes complexes pour prendre des décisions.

Je peux comprendre que COBOL soit apprécié pour sa simplicité à coder certains de ces algorithmes. Mais je doute qu’il soit adapté pour traduire les plus complexes. Ils demandent de l’abstraction que COBOL peine à fournir.

Vous pouvez toujours  voir cela en action. Il suffit de regarder votre compte en banque. Les mises à jour sont souvent opérées autour de minuit. Cette mécanique rappelle les vieux programmes COBOL.

Mon idée première était de comparer Java  à Cobol – Java est aujourd’hui un langage de 20 ans -, pensant qu’il devenait archaïque. Mais ce ne sont pas les indexes 32 bits qui font ou défont un langage. La façon dont le langage représente et simplifie un problème est sa fondation.

COBOL a souffert avec le temps car les développeurs souhaitaient ,et avaient besoin de pouvoir écrire du code concis pour exprimer des concepts très complexes. Java en a aussi souffert – c’est pour cela que Scala et Kotlin notamment ont monté en régime. Java est bien plus concis que COBOL, mais comparé à Scala et Kotlin, il est bien  plus périphrastique.

Toutefois, Java, aussi verbeux soit-il, n’est pas si expressif.  D’une part , il a certes gagné en fonctionnalités (comme les expressions lambda) qui permettent de réduire cette verbosité tout en ajoutant d’autres fonctions. D’autre part, il s’agit d’un langage orienté objet depuis le début ; ce qui en fait une passerelle adéquate entre le fonctionnel et l’objet.

COBOL quant à lui s’est quelque peu fané, car le langage n’a jamais été conçu pour prendre en compte des problèmes auxquels sont aujourd’hui confrontées les entreprises.   

Traduit et adapté par la rédaction