Discussion:Cobol

message: " l'incapacité de définir des variables locales, des fonctions récursives et d'allouer de la mémoire dynamiquement. Son manque de support de la programmation orientée objet est compréhensible, puisque le concept était inconnu à cette époque."
De fait, des fonctions récursives sont possibles avec des programmes  inclus, et la programmation avec des objets est standardisé avec la version 2002 et est implementé par plusieurs compilers. 
--80.128.254.84 7 sep 2004 à 16:05 (CEST)
replies: text: Cela a été corrigé dans des changements récents. CaféBuzz (discuter) 20 février 2022 à 12:13 (CET)

text: Elle l'est dans la version actuelle. CaféBuzz (discuter) 20 février 2022 à 12:13 (CET)

text: Il a été pris la décision (voir plus bas) d'appliquer les règles usuelles concernant les acronymes (majuscule à la première lettre seulement pour un terme de 5 caractères), l'usage en français n'étant semble-t-il pas tranché dans ce cas précis. CaféBuzz (discuter) 20 février 2022 à 12:13 (CET)

message: Le premier paragraphe mentionne le COBOL 2003 qui ne fait pas partie de la liste des standards COBOL. C'est une typo à remplacer par COBOL 2002. Caplan  A+ 22 avril 2007 à 01:48(CET)
: Cela n'est plus le cas dans la version actuelle. CaféBuzz (discuter) 20 février 2022 à 12:11 (CET)
thread_title:  Typo, 2002 plutôt que 2003

message: " Plus sérieusement, ce qui est communément admis, c'est que les outils cobol actuels sont utiles pour conserver les applications existantes. Cet argument est discutable du fait des tarifs démentiels pratiqués par le fournisseur institutionnel, et aussi du fait que la maintenance et l'évolution d'applications coûte de plus en plus cher. Pratiquement à chaque occasion, refaire coûte moins cher sur le long terme. "
Cette affimation est tout aussi discutable que l'argument qu'elle est censée réfuter. Son auteur ne démontre rien, ni ne cite aucune étude économique précise qui pourrait en renforcer la crédibilité.
:Réponse à la phrase précédente : Il n'y a rien à démontrer, le problème de la tarification des outils cobol est une réalité, et le reste de l'argumentation est basé sur 15 ans d'expérience comme consultant chez Microfocus et comme directeur technique pour Acucorp. Le rythme constant avec lequel les développeurs abandonnent le langage cobol est un fait.
:
:J'ajouterais que le passage ou "cobol présente d'excellentes performances pour les traitements par lot et qu'on n'a pas fait mieux depuis" est au mieux très ingénu.
:
::Réponse à la phrase précédente : le fait d'avoir travaillé chez Microfocus / Acucorp ne me semble pas être un gage évident d'une parfaite objectivité économique. J'ajouterais que, dans l'environnement hyper concurentiel que sont les technologies de l'IT, je ne sais pas ce qu'est un "fournisseur institutionnel".
::
:::Note ajoutée en réponse à la réponse : le "fournisseur institutionnel" est le seul fournisseur restant, qui fournit 99,9% des licences, et qui est en situation de monopole :-( Par ailleurs, vous avez raison, je ne suis pas forcément évidemment objectif. Et d'ailleurs ces considérations ne sont évidentes que pour ceux qui signent des bons de commande année après année.
:::Mon intervention initiale était motivée uniquement pour tempérer l'affirmation qui dit que le cobol est le plus performant. Ceci était peut-être vrai il y a 30 ans, à l'époque où Microfocus produisait un générateur optimiseur très bien fait. De nos jours, les optimiseurs des compilateurs C font bien mieux. C'est ce qui a d'ailleurs permis à Acucorp de rattraper Microfocus il y a une dizaine d'années sur le terrain de la rapidité, le cobol acucorp étant écrit en langage C. Les deux fournisseurs ne font plus qu'un depuis déjà plusieurs années, le cobol ne progresse plus depuis cinq ou six ans, et d'autres langages sont passés devant en termes de performances. Qui songerait sérieusement à l'utiliser aujourd'hui pour développer une nouvelle application ? Un programmeur qui ne connaîtrait que cela, et qui refuserait de se remettre en question...
:::
::::Voir ma réponse ci-dessus (#« À ce jour, il n'existe pas de langage qui pourrait le remplacer »): tout est discutable, mais pas sur la base d'argumentations personnelles. Apportez des sources. CaféBuzz (discuter) 20 février 2022 à 12:11 (CET)
thread_title:  Un argument discutable ... 

message: Ce langage ayant été conçu aux débuts de l'informatique, sa relative complexité rebute nombre de programmeurs de notre époque, ce qui lui a valu deux interprétations ironiques de son acronyme : Compiles Only Because Of Luck (fonctionne uniquement par chance) et Completly Obsolete Business Oriented Language (Langage orienté gestion complètement obsolète)
 => je ne suis personnellement d'accord ni avec les traductions (dont le texte original me parait pertinent) ni d'accord avec le sens que l'on donne à ces propos (du point de vue de mon utilisation professionnelle).
Ce qui rebute c'est (encore une fois un point de vue personnel qui peut se débattre) :
 1) lenteur de développement : ce n'est pas un langage rapide à utiliser, les variables sont globales, etc
 2) les possibles erreurs qui ne sont pas détectées à la compilation (notamment les erreurs de type de données la gestion des comp-3 par exemple etc)
 3) les rapport d'erreurs en cas d'abend qui peuvent s'avérer imbouffables
 4) On passe trop de temps à tenter se focaliser sur le code plutôt que sur le fonctionnel
:Voir ma réponse ci-dessus (#« À ce jour, il n'existe pas de langage qui pourrait le remplacer ») ): il faut apporter des sources. CaféBuzz (discuter) 20 février 2022 à 12:11 (CET)
thread_title:  Histoire et spécifications 

message: * Demandé par : Gkml (discuter) le 7 mars 2019 à 15:28 (CET)
replies: text: Cordialement, Prométhée (discuter) 14 mars 2019 à 19:32 (CET)
thread_title:  {{Demande de renommage/Titre|COBOL|Cobol}} 

message: === The following were general enhancements: ===
* An asynchronous messaging facility using the SEND statement and RECEIVE statement
* Boolean exclusive or operators
* Boolean shifting operators
* COBOL words may now be 63 characters long
* The PERFORM CONTINUE statement has been enhanced to specify a time period for pausing the program
* A DELETE FILE statement
* A nonfatal EC-I-O-WARNING exception condition to handle warnings for successful input-output statements
* EXTERNAL attributes checking between programs
* Infinite loop for the PERFORM statement using the UNTIL EXIT phrase— Inline exception handling using the exception-checking format of the PERFORM statement
* An Enhanced INSPECT statement to inspect backwards
* Line Sequential file organization
* The SET statement has been enhanced to allow the setting of the length of a dynamic length elementary item
* Alternate key suppression on indexed files using the SUPPRESS WHEN phrase of the ALTERNATE RECORD KEY clause
* An optional Commit and rollback processing facility using the COMMIT statement and ROLLBACK statement
* Unsigned Packed-Decimal items defined by the NO SIGN phrase of the USAGE clause
* User-defined PICTURE clause editing using the EDITING phrase of the PICTURE clause
* VALUE clause enhancements and changes for numeric-edited items
* Type declarations may now be external items
=== The following intrinsic functions were added or enhanced: ===
* BASECONVERT function
* CONCAT function
* CONVERT function
* EXCEPTION-FILE function and EXCEPTION-FILE-N function
* FIND-STRING function
* MODULE-NAME function
* SMALLEST-ALGEBRAIC function
* SUBSTITUTE function
* TRIM function
=== Additional compiler directives were added: ===
* COBOL-WORDS directive
* DISPLAY directive
* FLAG-14 directive
* POP directive
* PUSH directive
* REF-MOD-ZERO-LENGTH directive
McShark (discuter) 20 novembre 2023 à 12:04 (CET)
thread_title:  The main changes are as follows: 

message: * COBOL-WORDS directive
* DISPLAY directive
* FLAG-14 directive
* POP directive
* PUSH directive
* REF-MOD-ZERO-LENGTH directive
McShark (discuter) 20 novembre 2023 à 12:04 (CET)
thread_title:  Additional compiler directives were added: