Pourquoi le mépris du COBOL? [fermé]

Lorsque les gens parlent de COBOL, il s’agit généralement d’un grognement ou d’un grognement. Je ne connais pas grand chose à propos de COBOL, mais j’ai vu quelques programmes écrits dedans. Je peux voir que c'est verbeux et inintelligible aux yeux non initiés comme le mien. Mais, vraiment, tous les langages de programmation ne sont-ils pas du charabia à un profane?

Je comprends que cela fonctionne, fonctionne bien et est encore largement utilisé dans les industries pour lesquelles il a été conçu. N'est-ce pas ce qui caractérise une bonne langue? Quel est le problème avec COBOL?

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.

Ayant passé la majeure partie de la journée à écrire du COBOL, je pense pouvoir vous donner quelques informations actuelles.

D'abord les MAUVAIS trucs: -

• Aucun appel de fonction. COBOL moderne a quelques fonctions intégrées, mais c’est un travail d’ingénierie sérieux pour écrire les vôtres.
• Aucun type de vérification sur les appels de sous-routine. Vous pouvez passer (ou ne pas passer) n'importe quoi sur un appel de sous-routine, le sous-programme appelé supposera allègrement avoir les paramètres corrects, et il n'existe aucun moyen de détecter les paramètres manquants ou non valides.
• Pas de bibliothèques. Aucun zéro zilch. Pas de bibliothèques standard, pas de bibliothèques facilement disponibles largement utilisées. Vous finissez par coder maintes et maintes fois les tâches de complot.
• Tout est mis en œuvre en tant que mot clé. Etant donné que les auteurs de langage n'ont pas le concept de bibliothèque, chaque nouvelle fonctionnalité est implémentée avec de nouveaux mots-clés, par exemple, prise en charge de PARSE et RENDER for XML.

Les incompris, c'est-à-dire les critiques adressées couramment à l'ancien et cher langage, qui sont invalides ou non pertinentes.

• Verbosité. Donc, vous tapez quelques caractères supplémentaires! Ce n'est pas un problème grave. Dans de nombreux cas, COBOL est moins détaillé que Java.

• "FICHIERS COBOL" Ce terme est fréquemment utilisé. COBOL n’existe pas, mais n’importe quel format de fichier et n’importe quelle organisation de fichiers.

• Pas de multi-threading. Dans les environnements où le COBOL est florissant, le multi-threading est généralement laissé aux conteneurs d'applications tels que CICS ou IMS, qui sont bons pour le faire, plutôt que les programmeurs qui ont tendance à être mauvais.

Et les bonnes choses - certains aspects de COBOL sont supérieurs aux autres langues: -

• Structures de données. COBOL utilise une syntaxe concise et flexible pour définir des structures de données complexes et des types de données impairs.
• Arithmétique décimale. Il a un support natif pour l'arithmétique décimale, c'est-à-dire l'arithmétique telle que comprise par les comptables, avec les arrondis appropriés, etc.
• Bouger avec le temps. Certains aspects de COBOL sont étonnamment modernes. Prise en charge XML intégrée, prise en charge de la programmation OO, possibilité d'utiliser des classes Java, etc.
• Intégration avec DB2, CICS, etc. Cela ne concerne que le système COBOL mainframe d’IBM (mais c’est de loin le plus gros bloc COBOL en cours d’exécution), mais l’intégration à DB2, CICS et d’autres environnements mainframe facilite le codage d’objets tels que la sauvegarde de bases de données. services Web que dans tout autre environnement.
• Manipulation de l'écran. La gestion standard des écrans telle qu’elle est mise en œuvre sur AS / 400 et MicroFocus Cobol est excellente.
• Performance. Les compilateurs COBOL produisent depuis de nombreuses années des exécutables très performants. Seuls C et Assembler natifs ont battu COBOL sur un ordinateur central IBM.

Donc, dans l’ensemble, il se débrouille assez bien pour un projet mis au point par un comité dans les années 50. Si une application existante est implémentée dans COBOL et effectue le travail, il n'y a aucune raison de la réécrire. Cependant, à moins d'une raison valable, je ne vois aucune justification pour que de nouveaux projets utilisent COBOL.

C'est probablement à Djikstra. Djikstra a déclaré que "l'utilisation de la COBOL paralyse l'esprit, son enseignement doit donc être considéré comme une infraction pénale." Le cobol était perçu comme naïf, non structuré et prolixe. Avec la possibilité d'auto-modifier le code (pratique déconseillée même parmi les programmeurs Cobol), il était considéré comme assez difficile à déboguer ou à suivre également.

Il y a aussi le problème de la grande incompatibilité entre les versions.

Je suggérerais de lire la section critique et défense de Wikipedia dans la langue - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

Son âge et son verbosité sont généralement les choses qui font que les gens gémissent à ce sujet.

Il me semble rappeler que lors de la conception de COBOL, le principal objectif d’IBM était de "permettre à un directeur de banque d’écrire un programme". Cet objectif a évidemment eu un impact profond sur la façon dont le langage a été conçu et il a maintenant évolué.

Apparemment, il y a plus de COBOL dans la nature que n'importe quelle autre langue. Cependant, après avoir travaillé dans l'informatique pendant près de 20 ans (15 dans le secteur bancaire), je n'ai jamais rencontré un seul système qui y soit implémenté.

Quel est le problème avec COBOL?

Rien.

Je pense que les gens ont une idée préconçue que vieux est mauvais, "le plus récent est le meilleur". Il est encore très utilisé et je suis sûr que le travail de maintenance du code sera suffisant pendant encore un demi-siècle.

En 1997, le groupe Gartner signalait que 80% de l'activité mondiale était réalisée en COBOL avec plus de 200 milliards de lignes de code existantes et environ 5 milliards de lignes de nouveau code par an. (via wikipedia )

En codage, il faut toujours choisir le meilleur outil pour le travail, et avec certaines industries qui sont mariées à certains matériels, la langue est optimale. Je n'ai jamais travaillé dans le secteur bancaire, où j'avais entendu dire que c'était populaire, mais la réponse de Sean indique que ce n'est pas le cas.

Si l'ancien code présente un problème, tant que vous pouvez insérer une interface utilisateur ou une interface Web devant lui, la plupart des utilisateurs ne verront même pas la différence.

Les gens n'aiment pas COBOL parce que son application est limitée. Il a été conçu pour les systèmes commerciaux, financiers et administratifs des entreprises et des gouvernements.

Qu'est-ce que tous ont en commun? Les données. Des tas de données.

Devinez qui a été conçu pour traiter les données et avoir beaucoup de fichiers pour le petit-déjeuner? Pouvez-vous dire langue commerciale axée sur les affaires ?

Il y a 50 ans, COBOL était ce qu'il y a de mieux pour les grandes entreprises qui doivent gérer beaucoup de données. Il existe aujourd'hui de meilleurs moyens de gérer un grand volume de données, de sorte que COBOL n'est plus pertinent. Ou est-ce?

Considérons les gouvernements. Quelles données un gouvernement doit-il suivre? Identifiants personnels, certificats de naissance, dossiers médicaux, taxes (oh ... oui ... taxes), etc. Et ils doivent conserver ces informations indéfiniment, aujourd'hui et il y a 50 ans également.

Les gens ont également mentionné les banques dans certaines des réponses et, de fait, les banques sont de gros utilisateurs de COBOL. Pourquoi? car contrairement à d’autres types de sociétés, les banques ont généralement une histoire. Certains existent depuis des centaines d'années ( comme celui-ci par exemple ).

Cela signifie que certaines données de 50 ans doivent encore être ici, aujourd'hui, le 7 octobre 2011. Nous avons maintenant SQL Server et C # ou Oracle et Java, mais il y a 50 ans, il y avait du COBOL et des fichiers.

Au fil du temps, les données pour les gouvernements et les banques ont augmenté de plus en plus et il était de plus en plus coûteux de migrer les systèmes. Ce qui signifie qu'ils doivent rester en mode COBOL et être constamment maintenus et évoluer à mesure que les affaires évoluent. Certaines banques migrent lentement tandis que d'autres collent simplement une interface Web 2.0 agréable devant le grand système (c # et Java sont les plus utilisés). Pouvez-vous dire le code hérité? (COBOL va de pair avec les codes (extrêmes) hérités, dont certains ont été touchés par de nombreuses personnes au cours de décennies d'existence - une autre chose que les programmeurs n'aiment pas: D).

Et maintenant vous avez un créneau d'activité. COBOL a maintenant une application limitée et votre expérience en est affectée .

Et les gens qui entrent dans COBOL finissent par découvrir que vous faites la même chose encore et encore, année après année, et au moment où ils se réveillent, ils ne sont plus compétitifs sur le marché car les utilisateurs veulent maintenant PHP, Java, C #. , REST, jQuery et seules les banques recherchent des personnes COBOL.

À ce stade, la demande est inférieure à l'offre et ceux qui ne le font pas doivent passer à autre chose. Et ils doivent commencer en tant que juniors, car COBOL est vraiment paralysé (croyez-le, le copier-coller est le principal style de développement de COBOL et explique sa grande productivité) et maintenant ils maudissent le jour où ils ont ramassé COBOL et ne l'ont pas fait. ne perdez aucune occasion de raconter leurs histoires d'horreur à ce sujet :). Mais vous pouvez raconter ces histoires à propos de toute langue de péter ancienne qui n'est plus en demande de nos jours, mais vous êtes la personne malheureuse coincée avec elle. O bien ...

PS et COBOL sont mauvais pour toutes les autres raisons mentionnées par les autres :)

PS2. In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.Vraiment? Et comment le jour a-t-il mesuré cela? Sont-ils allés faire toutes les compagnies dans le mot et leur demander combien de lignes de COBOL ont-ils ou quoi?

Deux caractéristiques

• La déclaration ALTER est un pur mal. Bien que rarement utilisé dans les applications COBOL plus modernes, il était très utilisé autrefois, car il était plus efficace que la structure équivalente "IF-GOTO". Lorsque les ordinateurs ne disposaient que de 32 Ko de RAM, chaque instruction comptait. Il a modifié une instruction GOTO pour avoir une destination différente.

  Cela a rendu un code opaque parce que le code lui-même était dynamique.

• La clause REDEFINES dans une structure de données (comme uniondans C) est un problème perpétuel. Le terme "union libre" - c'est-à-dire des structures de données superposées sans discriminateur - est un moyen de résumer le problème. Deux alias REDEFINES ne peuvent pas être distingués de manière triviale par les données; seule une lecture approfondie de la logique du programme pourrait déterminer le sens des deux interprétations alternatives des octets.

  Cela a rendu de nombreuses structures de données opaques, car les données ne peuvent être comprises sans le code.

La lisibilité de la syntaxe de type anglais a été mise en échec par ces deux constructions.

[Les modérateurs m'ont averti que les réponses courtes ne tiennent pas compte de votre question importante et intéressante. Si vous trouvez cela dédaigneux, vous pouvez demander des détails. Ou marquez-le pour que les modérateurs puissent le supprimer.]

J'ai programmé en COBOL pendant plusieurs bonnes années. Sa syntaxe est simple comparée aux langues actuelles et vous n'avez pas besoin de beaucoup de théorie pour apprendre à vous lancer. COBOL a très bien fonctionné avec le CICS d’IBM (un système de gestion de transactions en ligne) et le programmeur doit noter dans le code afin d’augmenter le nombre d’applications de 1 à plusieurs milliers d’applications. CICS a fourni une interface graphique basée sur les caractères qui utilisait un écran comme unité d'affichage (pas de fenêtre). Vous pouvez afficher des graphiques à l’aide de (IBM GDDM) sur l’ordinateur central. COBOL peut parler aux fichiers indexés (VSAM et ISAM), ainsi qu’à DB2 (relationnel basé sur SQL) et à IMS. COBOL / CICS est un environnement très robuste que vous pourrez apprendre en quelques semaines. Cela signifie que vous vous concentrez sur l'entreprise et non sur la technologie. Vous travaillez donc 7 heures sur 8 sur le codage et non sur l'apprentissage de MVM, JavaScript et autres.

Le problème avec COBOL est un mauvais marketing qui conduit à un manque d'intérêt de la part de tiers pour développer des outils et des environnements de programmation pour cela. En outre, son manque de prise en charge de l'interface semblable à Windows a entraîné une baisse de sa popularité après 1993. Le coût des ordinateurs centraux a incité les clients à rechercher des alternatives et des compilateurs pour COBOL disponibles sous UNIX et DOS. Le langage C a tiré la majeure partie de la lumière, car il a pu être plus portable et avoir un accès direct aux fonctions du système d’exploitation, ce que COBOL ne possédait que très peu.

Des langages tels que VB, DBase, FoxPro et Clipper offraient de meilleurs moyens d’accéder aux «bases de données» sur le PC que le COBOL comparable sur DOS, de sorte que COBOL était perdu. CICS n’a pas été rendu bon marché sous DOS ou UNIX pendant longtemps, et sa valeur n’est donc pas présente sur ces environnements.

Aujourd'hui, COBOL est pris en charge avec .NET, mais j'imagine qu'il a perdu la bataille sur toutes les plateformes, à l'exception de l'ordinateur central (et peut-être de l'AS / 400), où il est toujours présent, en raison du grand nombre d'applications critiques qui dépendent entièrement il.

Hé, je suis allé à la fac au début des années 80 et les gens méprisaient COBOL, même à l'époque. Je pense que le plus gros problème est sa verbosité - un simple "Hello, world!" En COBOL, il y a probablement plus de cinquante lignes, dont 95% sont requises. Ce n'est tout simplement pas une langue très élégante ou attrayante. Il a également été conçu pour traiter les problèmes d'hier et ne se prête pas vraiment aux paradigmes de développement développés après 1970 environ. C'est un assez bon langage de génération de rapports - tant que vos rapports sont des colonnes sans fin de nombres avec en-têtes et pieds de page. Si vous voulez coller un graphique ou un logo quelque part, oubliez-le. Je pense que c'est toujours le langage le plus rapide pour les tâches de type "traitement de données" (prenez un fichier de format fixe avec 5 transactions ATM et effectuez un simple ajustement de solde pour chacune d'elles), mais combien de développeurs font ce genre de choses plus? Et beaucoup de systèmes utilisent XML ou JSON de nos jours, je détesterais penser à essayer d'analyser COBOL avec une méthode similaire (en fait, je détesterais penser à une analyse syntaxique en général en COBOL!)