Aujourd'hui, nous publions la deuxième partie de la traduction de matériel sur les mathématiques, sur COBOL, et pourquoi cette langue est toujours vivante.
→
La première partieRatio de récidive de Müller et COBOL
Voyons comment COBOL gère la relation de récurrence de Müller. Voici un programme COBOL qui implémente la relation de récurrence que nous étudions.
IDENTIFICATION DIVISION. PROGRAM-ID. muller. AUTHOR. Marianne Bellotti. DATA DIVISION. WORKING-STORAGE SECTION. 01 X1 PIC 9(3)V9(15) VALUE 4.25. 01 X2 PIC 9(3)V9(15) VALUE 4. 01 N PIC 9(2) VALUE 20. 01 Y PIC 9(3)V9(15) VALUE ZEROS. 01 I PIC 9(2) VALUES ZEROS. PROCEDURE DIVISION. PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. STOP RUN.
Si c'est la première fois que vous voyez un programme écrit en COBOL, clarifions tout de suite certaines choses. Premièrement, il s'agit du COBOL dit de «forme libre», qui a été introduit en 2002 afin de rapprocher COBOL de la structure des langages modernes. Traditionnellement, le code COBOL a une largeur fixe lorsque certaines entités sont placées dans certaines colonnes. L'idée de considérer le code sous la forme d'une structure dans laquelle les lignes et les colonnes sont mises en évidence peut sembler étrange, mais une telle structure de code était destinée à simuler le formatage des cartes perforées. À l'époque de COBOL, les programmes ont été créés de cette façon. Une carte perforée a 80 colonnes - certaines colonnes sont pour certaines données. La même approche est traditionnelle pour COBOL.
La chose la plus importante dans ce code, qui attire peut-être le plus l'attention, est la façon dont les variables sont déclarées ici:
01 X2 PIC 9(3)V9(15) VALUE 4.
Le code
01 au début de la ligne est appelé le numéro de niveau. Il indique à COBOL que nous déclarons une nouvelle variable. COBOL vous permet de lier ou de grouper des variables (un exemple classique est une adresse qui peut inclure les noms de la rue, de la ville et du pays en tant que variables distinctes), par conséquent, dans ce cas, le numéro de niveau devient important.
X2 est le nom de la variable - tout est assez simple. À la fin, il existe une construction qui définit la valeur initiale de la variable, qui ressemble à "
VALUE 4. " Le point à la fin n'est pas une faute de frappe. C'est un moyen de terminer les lignes dans COBOL.
Maintenant, nous devons seulement considérer ce qui est au milieu de la ligne - la construction du
PIC 9(3)V9(15) .
PIC est un peu un opérateur pour décrire un type de données de caractère. Il peut stocker des valeurs alphanumériques. Il peut même stocker des nombres décimaux. COBOL est un langage avec un typage statique strict et avec une caractéristique inhabituelle, qui est que la plupart des types COBOL sont beaucoup plus flexibles que les types dans d'autres langues. De plus, lors de la déclaration de variables, vous devez spécifier le nombre de caractères qu'elles peuvent contenir. Dans notre cas, c'est le nombre entre parenthèses. La construction de
PIC 9(3) signifie qu'une variable peut stocker trois caractères, qui sont des nombres (indiqués par le nombre
9 ).
Par conséquent, la construction
9(3)V9(15) doit être lue comme suit: «3 chiffres, suivis d'un point décimal (v), suivis de 15 autres chiffres.»
Voici les résultats de ce programme:
01|004.470588235294118 02|004.644736842105272 03|004.770538243626253 04|004.855700712593068 05|004.910847499165008 06|004.945537405797454 07|004.966962615594416 08|004.980046382396752 09|004.987993122733704 10|004.993044417666328 11|005.001145954388894 12|005.107165361144283 13|007.147823677868234 14|035.069409660592417 15|090.744337001124836 16|099.490073035205414 17|099.974374743980031 18|099.998718461941870 19|099.999935923870551 20|099.999996796239314
Cela s'est produit en utilisant des nombres qui ont 15 décimales. Si nous changeons les propriétés des variables
X1 ,
X2 et
Y en
PIC9(3)V9(25) , alors nous pouvons passer:
01|004.4705882352941176470588236 02|004.6447368421052631578947385 03|004.7705382436260623229462114 04|004.8557007125890736342050246 05|004.9108474990827932004556769 06|004.9455374041239167250872200 07|004.9669625817627006050563544 08|004.9800457013556312889833307 09|004.9879794484783948244551363 10|004.9927702880621195047924520 11|004.9956558915076636302013455 12|004.9973912684019537143684268 13|004.9984339443572195941803341 14|004.9990600802214771851068183 15|004.9994361021888778909361376 16|004.9996648253090127504521620 17|004.9998629291504492286728625 18|005.0011987392925953357360627 19|005.0263326115282889612747162 20|005.5253038494467588243232985
Différents mainframes offrent différentes limites supérieures pour les types de données COBOL. Chez IBM (au moins - dans mon cas), c'est 18 chiffres. MicroFocus a 38 chiffres.
Combien coûte la précision?
Tout ce dont nous venons de parler vise à montrer que COBOL n'effectue pas les calculs mieux que d'autres langages de programmation plus courants. En raison de restrictions sur la taille des nombres à virgule fixe, COBOL peut en fait être inférieur aux langues qui donnent au développeur plus de contrôle sur ce qui se passe.
Mais il y a une caractéristique. Le fait est que Python (et Java) n'a pas de support intégré pour les nombres à virgule fixe. Et dans COBOL, ce support est.
Pour effectuer des calculs à virgule fixe en Python, j'ai dû importer le module
Decimal . Si vous avez déjà travaillé avec un projet qui a tout un tas de commandes d'importation, vous devez savoir que chacune de ces commandes a un certain «prix». Dans des langages comme Java (à savoir, ce langage est généralement considéré par ceux qui vont se débarrasser de COBOL) le "prix" d'une bibliothèque appropriée peut être considérablement
plus élevé . En fait, il s'agit plutôt de savoir si le «coût» de l'importation des bibliothèques joue un rôle dans votre projet. Pour de nombreux programmeurs, penser à l'impact sur les performances des commandes d'importation est le summum de l'optimisation prématurée.
Mais les programmeurs COBOL travaillent généralement sur des systèmes qui doivent traiter des millions, voire des milliards d'opérations par seconde, en le faisant de manière précise et fiable. Et, malheureusement, il est très difficile de donner un argument convaincant pour COBOL ou contre lui pour un tel scénario, car il s'agit en fait d'un domaine d'innombrables variations. La prise en charge des points fixes intégrée à COBOL est-elle un facteur déterminant dans le choix d'une langue pour résoudre de tels problèmes? Ou peut-être que les problèmes correspondants peuvent être résolus en choisissant la bonne combinaison de processeur, mémoire, système d'exploitation? Ou, peut-être, pour résoudre des problèmes de calculs rapides, précis et fiables, vous devez recourir à "danser avec un tambourin"? Peut-être - nous limiterons le raisonnement? Nous les réduirons à trouver une réponse à une question comme «Quel est le meilleur - COBOL ou Java si vous utilisez le même matériel?». Mais même ainsi, il nous sera difficile d'évaluer comment les lacunes de chacune des langues affecteront les performances au moment où le système commencera à effectuer les milliards d'opérations par seconde susmentionnées. Par conséquent, nous pouvons seulement dire que le même COBOL et Java ne sont que des langages très différents.
Voici ce qu'ils écrivent à ce sujet
ici , en explorant les performances du code Java traduit à partir du code COBOL.
COBOL est un langage compilé qui utilise une pile qui prend en charge les pointeurs et les jointures. La conversion de type ne crée pas de charge sur le système pendant l'exécution du programme. Il n'y a aucune planification ou conversion de type pendant l'exécution du programme. Le code Java, en revanche, s'exécute dans une machine virtuelle. Il utilise un groupe et ne prend pas en charge les jointures. La conversion de type met une pression sur le système pendant l'exécution du programme. Java utilise la répartition dynamique et l'inférence de type au moment de l'exécution. Bien qu'il soit possible de minimiser la quantité d'utilisation de ces fonctionnalités, cela conduit généralement au fait que le code est plus ou moins "différent" du code Java ordinaire. Lorsqu'ils étudient les résultats de la traduction de code Java à partir de COBOL, ils se plaignent généralement que le code est illisible et non pris en charge. Cela annule la plupart des objectifs de passer de COBOL à Java.
Avant de décider d'écarter ces considérations avec la phrase «Oui, mais c'est Java, et Java n'est pas non plus un cadeau» - rappelez-vous ceci: la plupart des langages de programmation modernes n'ont absolument aucun support intégré pour les calculs à virgule fixe. (Je pense qu'il serait plus correct de dire qu'aucune des langues modernes ne prend en charge cela, mais je ne peux pas le vérifier de manière fiable.) Bien sûr, vous pouvez choisir une autre langue qui a son propre ensemble d'avantages et d'inconvénients, mais si la précision est nécessaire dans les calculs avec un point fixe, et si vous pensez qu'une petite perte de performances lors de l'importation d'une bibliothèque qui implémente de tels calculs peut vous blesser, cela signifie que vous avez la seule option - COBOL.
C'est pourquoi la soi-disant «modernisation» est si complexe: elle dépend de nombreux facteurs. Certaines organisations recevront des résultats tangibles d'investissements dans la modification de la plate-forme logicielle, tandis que d'autres constateront qu'elles ont perdu quelque chose d'important en échange d '«améliorations» qui, en fait, ne s'améliorent pas beaucoup. Si une organisation est une grande institution financière qui traite des millions de transactions chaque seconde et a besoin d'une précision décimale des calculs, alors, il sera moins cher de former des spécialistes à travailler avec COBOL que de payer les ressources et la productivité pour migrer vers une langue plus populaire. Après tout, la popularité est temporaire.
Résumé
Par conséquent, en expliquant pourquoi tant d'organisations utilisent encore COBOL, vous devez comprendre que la tâche de traitement des programmes est différente de la tâche de création de programmes. Les programmeurs qui ont créé la solution ont eu l'avantage de sa mise en œuvre progressive. Les applications s'efforcent généralement de se rapprocher le plus possible des limites des capacités prises en charge par leurs technologies. Le dilemme concernant la migration de COBOL n'est pas une question de passage d'une langue à une autre. C'est la tâche de passer d'un paradigme à un autre. Les limites de Java ou Python sous Linux ne sont pas du tout les mêmes que celles de COBOL sur le mainframe. Dans certains cas, les applications COBOL sont capables de ce que les langages modernes ne peuvent pas. Dans de tels cas, l'utilisation de COBOL sur un ordinateur central moderne s'avérera en fait une solution moins coûteuse, productive et précise.
Chers lecteurs! Pensez-vous que COBOL est vraiment une langue qui, dans certaines situations, s'avère vraiment meilleure que les langues plus modernes?
