Discussion :

[Guesset]

Bonjour Bktero,

L'efficacité (comprendre "performances d'exécution" ici) ne peut pas être le seul critère pour choisir un langage de programmation.

L'efficacité n'est pas le seul critère mais lorsque les autres exigences sont satisfaites il est le critère discriminant : vitesse, dimensionnement des équipements, consommation d'énergie. Il me semble qu'il faut avoir, surtout aujourd'hui, de très bonnes raisons pour négliger le "green IT".

...je crois qu'en 2022, trouver des développeurs.ses COBOL commence à être un sacré challenge. Ce seul argument peut justifier un changement de technologie.

Le problème n'est pas la nécessité du remplaçant nécessaire au COBOL mais de choisir un interprété pour faire un travail de back office.

Salut

[Sve@r]

Bonjour SVE,

Hey

Je ne savais pas mais je suis assez surpris qu'on remplace un langage compilé par un langage interprété qui même avec toutes les techniques de caches, JIT et autres, restera moins efficace ce qui veut dire plus lent et consommateur de ressources qu'un langage compilé ...en back office, là où œuvre COBOL, me laisse perplexe.

Bon, je ne bosse pas au TP mais je bosse dans un truc analogue et voilà comment j'imagine le truc : de gros traitements batch qui se déroulent la nuit, qui prennent des datas dans un format X et qui l'écrivent dans un format Y pour les mettre à dispositions d'autres entités (c'est ce qui se passe chez-moi). Et pour ce travail, je ne suis pas certain que la rapidité soit un critère fondamental (et en plus le COBOL a beau être compilé, ce n'est pas non plus le plus vif des langages). Plus la remarque de Bktero sur la difficulté de trouver aujourd'hui des dev COBOL en activité et ceci peut en arriver à expliquer ainsi cela...

Le problème n'est pas la nécessité du remplaçant nécessaire au COBOL mais de choisir un interprété pour faire un travail de back office.

C'est vrai que Python est interprété mais ça a été fait de façon un peu réfléchie. Le source est quand-même traduit en bytecode et c'est ce bytecode qui est ensuite exécuté. Plus l'inclusion de bibliothèques qui, comme tu l'as si bien dit, sont souvent écrites en C/C++ et ça donne un résultat pas dégueu (surtout pour faire le travail que je viens de décrire)...

[Guesset]

Rebonjour SVE,

...voilà comment j'imagine le truc : de gros traitements batch qui se déroulent la nuit, qui prennent des datas dans une format X et qui l'écrivent dans un format Y pour les mettre à dispositions d'autres entités (c'est ce qui se passe chez-moi). Et pour ce travail, je ne suis pas certain que la rapidité soit un critère fondamental (et en plus le COBOL a beau être compilé, ce n'est pas non plus le plus vif des langages). Plus la remarque de Bktero sur la difficulté de trouver aujourd'hui des dev COBOL en activité et ceci peut en arriver à expliquer ainsi cela...

Oui les batches de nuit forment le gros des jobs COBOL même s'il existe des moteurs transactionnels, la grande majorité a cédé la place depuis longtemps. Je ne sais pas où tu travailles mais j'ai vu des batches qui prenaient de plus en plus de temps et commençaient à donner des sueurs froides à l'exploitation quand le moindre problème se traduisait par un weekend chargé parce la moindre reprise ne pouvait plus être jouée dans la nuit - remarque, ce n'était pas du COBOL .

Tu as raison, COBOL n'est pas un foudre de guerre surtout si on le compare à des langages plus récents, mais dans son seul domaine de prédilection, il n'est pas ridicule.

Je ne pense pas qu'il faille garder COBOL. J'émet seulement un avis mitigé sur le remplaçant choisi. Je suis un râleur alors je râle

Salut