Le COBOL a été l’une des premières langues que j’ai apprises. Si vous ignorez les innombrables versions de Basic, trois ou quatre langues d’assembleur et une variante de Forth, c’est alors dans mes cinq premières langues et apprises en même temps que Pascal. IOW, je réponds par expérience personnelle en utilisant la langue.
EDIT Je devrais dire une expérience ancienne . Je n'ai jamais utilisé ce langage à la fin des années 80, bien que j'aie acheté un nouveau livre (pour remplacer l'ancien que j'ai jeté avec dégoût) afin d'avoir quelque chose à consulter pour que mes histoires d'horreur ne soient pas trop déformées. Mais je ne sais pas du tout comment la langue a évolué au moins au cours des 20 dernières années.
Il est évident que , pour beaucoup de gens, il est juste que « vieux est mauvais » avis que jonsca a déjà décrit - et aussi beaucoup plus d' un tiers à la main passe-moi vers le bas chose attitudes. Mais il y a de vrais problèmes sous-jacents.
Être trop verbeux est un problème réel - il y a trop de fouillis dans la manière de comprendre le code. C'est de loin le plus gros problème. Les gens qui regardent le MOVE, ADDet MULTIPLYetc déclarations dans l' horreur ont une vue un peu exagéré de cela, vrai - la COMPUTEdéclaration est plus proche des affectations dans d' autres langues. Mais il y a encore beaucoup d'encombrement dans toutes ces divisions et sections. Une des premières choses que j'ai apprises dans COBOL a été de toujours commencer par copier une page standard de SKELETON.COB de format A4.
COBOL fait avoir des caractéristiques intéressantes, mais ces caractéristiques (par exemple , la PICchose) ont tendance à être des choses qui sont maintenant plus partie du SGBD plutôt que le langage de programmation, et qui me semble généralement être une meilleure façon de séparer les responsabilités. En outre, certaines bibliothèques dans d'autres langues utilisent quelque chose de comparable à PIC(par exemple, printf et scanf dans la bibliothèque standard C). On peut soutenir que le meilleur a été conservé, mais le pire a été abandonné.
En outre, pour chaque fonctionnalité intéressante, il en existait au moins une intolérable. Par exemple, même si la boucle est triviale, vous devez déplacer le corps dans une procédure distincte. Les PERFORM ... UNTIL ...instructions similaires et similaires sont des instructions uniques - et non des structures de bloc. En un sens, COBOL était un avant-goût de la programmation structurée antérieure à l’invention de la programmation structurée - il en existait un GO TO, mais son utilisation était découragée (du moins lorsque j’utilisais COBOL), mais la boucle en particulier n’était tout simplement pas aussi bien gérée.
En fait, le langage que j'ai utilisé après COBOL et qui me le rappelait le plus était ... dBase. Comme dans Ashton-Tate dBase III +. De nos jours, les gens sont plus susceptibles de se souvenir de tous les clones maintenant morts ou mourants (Clipper, FoxPro, etc.) qui ont conduit au nom générique xBase - et il existe toujours un descendant vivant à xHarbour. Le fait est que c'étaient des langages de base de données, mais rien à voir avec SQL.
Même dans ce cas, lorsque chaque programme COBOL opérant sur une base de données particulière doit inclure une copie de la spécification de cette base de données (et que les copies peuvent finir par être incohérentes), ce n'est pas vraiment le cas dans xBase où la base de données connaît sa propre structure.
En prenant cela en compte, COBOL n’est pas si terrible si vous l’acceptez tel qu’il est. Mais ce qu’il n’est pas, c’est un langage pour écrire des structures de données. C’est peut-être pour cela que COBOL a beaucoup souffert à l’époque des guerres saintes C-Pascal - les deux parties pourraient convenir que COBOL n’était pas bon pour réinventer l’arbre binaire une fois encore.
Oh, et une chose que je n'oublierai jamais, c'est que mon premier manuel COBOL n'a pas décrit la SORTcommande, disant que cela sortait du cadre du livre. Apparemment, soit l'auteur ne pouvait pas gérer l'idée de trier, ou considérait que c’était plus que ce que les étudiants de COBOL pouvaient gérer [voir éditer à la fin]. Ce genre de choses rendait très difficile la prise au sérieux de COBOL.
Un aspect étrange de ceci était Jackson Structured Programming, que j’ai aussi été forcé d’apprendre à peu près à la même époque, et spécialement pour une utilisation avec COBOL. Une partie de cela consistait à dessiner un diagramme de structure pour l'entrée, puis un diagramme de structure pour la sortie, puis à dessiner le diagramme de structure intermédiaire pour le code. Le tri était clairement censé être un problème déjà résolu - vous ne pouvez pas déduire un algorithme de tri de cette manière. Il était donc curieux que le texte recommandé recommande de ne pas me préoccuper de tout le concept de tri, tout en apprenant à la fois une douzaine d’algorithmes de tri et leur implémentation en Pascal.
Les problèmes que JSP peut gérer sont probablement un bon guide pour les tâches que COBOL peut faire relativement bien. Mais même dans ce cas, cela ne signifie pas nécessairement que JSP ou COBOL sont de bons moyens de gérer ces problèmes.
EDIT le 30 juillet 2014
Je viens de recevoir un coup de pouce pour ma réputation, me rappelant que c'est ici. Il se trouve que, grâce à une collection de livres anciens alimentés par la nostalgie, je peux maintenant corriger un point en ordonnant à la SORTcommande.
Le livre que j'ai utilisé à l'origine comme texte recommandé lors de l'apprentissage du COBOL était "Programmical Method in in COBOL" de Ray Welland. Cela ne couvre pas COBOL 85 (bien qu'il y ait eu une édition ultérieure "Programmation méthodique en COBOL-85" que je n'ai encore jamais vue).
kindall a commenté ci-dessous "Vous deviez trier les fichiers d'entrée avant de les lire, ou trier le fichier de sortie après l'avoir généré, à l'aide de l'utilitaire de tri fourni avec le système d'exploitation". De ma réponse à cela, j'ai manqué le point "est venu avec l'OS". Kindall suggérait quelque chose qui ressemblait à la philosophie Unix AFAICT, avec COBOL utilisé pour les bits pour lesquels il était bon, des utilitaires de système d'exploitation tels qu'un utilitaire de tri utilisé pour certaines autres choses, et utilisant vraisemblablement un langage batch / scripting / shell pour coller les bits ensemble. Cela a beaucoup plus de sens dans un monde ancien où les logiciels interactifs étaient rares à inexistants, de sorte que vous soumettriez de toute façon des lots de travaux (d'où le "langage de traitement par lots").
Ce qui suit est cité des pages 165-166 de "Programmation méthodique en COBOL" ...
L'utilisation de fichiers série ordonnés implique qu'il soit nécessaire de disposer d'un moyen de trier les enregistrements d'un fichier dans un ordre spécifié par clé. La plupart des systèmes informatiques plus grands ont un utilitaire de tri qui triera un fichier en fonction de la position, du type et de la taille de chacun des éléments de données constituant la clé.
Il existe également une possibilité de trier les enregistrements à partir d'un programme COBOL, mais cela dépasse le cadre de ce livre pour deux raisons:
(a) l'interface avec le système d'exploitation est souvent assez complexe et varie d'un système à l'autre,
(b) le module de tri fait partie intégrante de ANS '74 COBOL et peut ne pas être implémenté dans les systèmes COBOL pour les ordinateurs plus petits.
Par conséquent, on supposera qu'il existe des possibilités de trier les fichiers dans un ordre spécifié et que le problème de la mise à jour de tels fichiers sera pris en compte.
En bref, kindall est correct - l’hypothèse était que le tri aurait généralement lieu en dehors de COBOL. Il peut même y avoir eu une réelle justification à exclure le tri d’un langage de programmation vers 1974 pour les petits ordinateurs.
Ce que j'ai dit ci-dessus était essentiellement ce que vous obtenez après environ 20 ans de ne pas être en mesure de vérifier les faits en raison de jeter le livre.
Je tiens toutefois à souligner que j’ai formellement étudié le COBOL à partir de ce livre recommandé couvrant la norme de 1974 (et non la norme de 1985) en 1988 et 1989. La troisième édition de "COBOL for Students" (Parkin, Yorke, Barnes) - la première édition couvrant COBOL 85 - n'a été publiée qu'en 1990. Je n'en suis pas certaine, mais je pense que l'édition COBOL 85 de "Methodical Programming" n'a été publiée qu'en 1994.
Mais cela ne représente pas nécessairement le monde COBOL qui traîne les pieds - enfin, pas tant que ça de toute façon. L'adoption de nouvelles normes prend du temps pour toutes les langues, même maintenant.