Pourquoi mépriser COBOL?
Lorsque les gens mentionnent COBOL, il est généralement rencontré un grognement ou un grognement. Je ne connais pas grand-chose à COBOL, mais j'ai vu des programmes écrits dedans. Je peux voir que c'est verbeux, et pour des yeux non initiés comme le mien, inintelligible. Mais, vraiment, tous les langages de programmation ne sont-ils pas du charabia complet pour un profane?
Je comprends que cela fonctionne, fonctionne bien et est toujours largement utilisé dans les industries pour lesquelles il a été conçu. N'est-ce pas là la marque d'une bonne langue? Qu'est-ce qui est si mauvais avec COBOL?
COBOL a été l'une des premières langues que j'ai apprises - si vous ignorez d'innombrables versions de Basic, trois ou quatre langages d'assembleur et une variante de Forth, alors c'était dans mes cinq premières, et apprises en même temps que Pascal. IOW, je réponds par expérience personnelle en utilisant la langue.
MODIFIER Je devrais dire ancienne expérience . Je n'ai jamais utilisé la langue après 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 à faire pour que mes histoires d'horreur ne soient pas trop déformées. Mais je ne sais pas comment la langue a évolué au moins au cours des 20 dernières années.
De toute évidence, pour beaucoup de gens, c'est juste que "l'ancien est mauvais" que jonsca a déjà décrit - et aussi beaucoup plus une passe de troisième main - chose d'attitudes déprimantes. Mais il y a de vrais problèmes sous-jacents.
Être trop verbeux est un vrai problème - il y a trop d'encombrement dans la façon de comprendre le code. C'est de loin le plus gros problème. Les personnes qui regardent avec horreur les instructions MOVE, ADD et MULTIPLY etc ont une vue légèrement exagérée, c'est vrai - l'instruction COMPUTE est plus proche de les missions dans d'autres langues. Mais il y a encore beaucoup d'encombrement dans toutes ces divisions et sections. L'une des premières choses que j'ai apprises dans COBOL était de toujours commencer par copier un SKELETON.COB standard d'une page A4.
COBOL possède certaines fonctionnalités intéressantes, mais ces fonctionnalités (par exemple, la chose PIC) ont tendance à être des choses qui font désormais plus partie de la Le SGBD plutôt que le langage de programmation, et cela me semble généralement être une meilleure façon de séparer ces responsabilités. De plus, 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 chuté.
De plus, pour chaque fonctionnalité de Nice, il y en avait au moins une intolérable. Par exemple, quelle que soit la banalité d'une boucle, vous devez déplacer le corps dans une procédure distincte. Le PERFORM ... UNTIL ... et les instructions similaires sont des instructions simples - pas des structures de blocs. Dans un sens, COBOL était un avant-goût de la programmation structurée d'avant la programmation structurée a été inventée - il y avait un GO TO, mais son utilisation a été découragée (du moins lorsque j'ai utilisé COBOL), mais le bouclage en particulier n'était tout simplement pas bien géré.
En fait, le langage que j'ai utilisé après COBOL qui m'a le plus rappelé é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 y a toujours un descendant vivant dans xHarbour. Le fait est que ce sont des langages de base de données, mais rien de tel que SQL.
Même dans ce cas, où chaque programme COBOL fonctionnant sur une base de données particulière doit inclure une copie des spécifications de cette base de données (et les copies pourraient finir par être incohérentes) , ce n'est pas vraiment le cas dans xBase où la base de données sait que c'est sa propre structure.
En tenant compte de cela, alors, COBOL n'est pas si terrible si vous l'acceptez pour ce qu'il est. Mais ce qu'il n'est pas est un langage pour écrire des structures de données. C'est peut-être la raison pour laquelle COBOL a beaucoup souffert à l'époque des guerres saintes C contre Pascal - les deux parties pourraient convenir que COBOL n'était pas bon pour réinventer l'arbre binaire.
Oh - et une chose que je n'oublierai jamais, c'est que mon premier manuel COBOL n'a pas décrit la commande SORT, disant qu'elle sortait du cadre du livre - apparemment, soit l'auteur ne pouvait pas faire face à l'idée de trier, soit il considérait que c'était plus que ce que les petits esprits des étudiants de COBOL pouvaient faire face [voir modifier à la fin]. Ce genre de chose rendait très difficile de prendre COBOL au sérieux.
Un aspect étrange de cela était la programmation structurée Jackson, que j'ai également été forcé d'apprendre à peu près au même moment, et spécifiquement 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 devait clairement être un problème déjà résolu - vous ne pouviez pas dériver un algorithme de tri de cette manière. Il était donc étrange que le manuel recommandé me dise que le concept de tri était au-delà de mon petit esprit, tout en apprenant quelque chose comme une douzaine d'algorithmes de tri différents et comment les implémenter en Pascal.
Les problèmes que JSP peut gérer sont probablement un bon guide pour les choses 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.
MODIFIER le 30 juillet 2014
Je viens de recevoir un coup de pouce de réputation, me rappelant que c'est ici. En fait, en raison de la collecte de livres anciens alimentés par la nostalgie, je peux maintenant corriger un point WRT la commande SORT.
Le livre que j'ai utilisé à l'origine comme texte recommandé lors de l'apprentissage du COBOL était "Programmation méthodique en COBOL" par Ray Welland. Cela ne couvre pas COBOL 85 (bien qu'il y ait eu une édition ultérieure "Programmation méthodique dans COBOL-85" que je n'ai encore jamais vue).
veuillez commenter ci-dessous "Vous étiez censé 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 raté le point "est venu avec le système d'exploitation". Kindall suggérait quelque chose apparenté à la philosophie Unix AFAICT, avec COBOL utilisé pour les bits pour lesquels il est bon, des utilitaires de système d'exploitation tels qu'un utilitaire de tri utilisé pour d'autres choses, et probablement en utilisant un langage batch/script/Shell pour coller les bits ensemble. Cela a beaucoup plus de sens dans un monde ancien où les logiciels interactifs étaient rares ou inexistants, de sorte que vous soumettriez de toute façon des lots de travaux (d'où le "langage de lots").
Ce qui suit est extrait de la page 165-166 de "Programmation méthodique en COBOL" ...
L'utilisation de fichiers série ordonnés implique qu'il est nécessaire d'avoir un moyen de trier les enregistrements d'un fichier dans un ordre spécifié par clé. La plupart des grands systèmes informatiques 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 formant la clé.
Il existe également une fonction de tri des 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 est une partie facultative du COBOL ANS '74 et peut ne pas être implémenté dans les systèmes COBOL pour les petits ordinateurs.
Par conséquent, on supposera que des installations existent pour trier les fichiers dans un ordre spécifié et le problème de la mise à jour de ces fichiers sera considéré.
En bref, kindall est correct - l'hypothèse était que le tri se faisait généralement en dehors de COBOL. Il pourrait même y avoir une réelle justification à l'exclusion du tri d'un langage de programmation vers 1974 pour les petits ordinateurs.
Ce que j'ai dit ci-dessus, c'est essentiellement ce que vous obtenez après environ 20 ans de ne pas pouvoir vérifier les faits en jetant le livre.
Je dois cependant souligner que j'ai étudié formellement COBOL à partir de ce livre recommandé qui couvrait la norme de 1974 (pas la norme de 1985) en 1988 et 1989. La troisième édition de "COBOL pour les étudiants" (Parkin, Yorke, Barnes) - la première édition couvrant COBOL 85 - n'a été publiée qu'en 1990. Je ne suis pas certain, mais je pense que l'édition COBOL 85 de "Programmation méthodique" 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 n'importe quelle langue, même maintenant.
Ayant passé la majeure partie de la journée à écrire du COBOL, je pense que je peux vous donner des informations actuelles.
D'abord les trucs MAUVAIS: -
- Aucun appel de fonction. COBOL moderne a des fonctions intégrées mais c'est un travail d'ingénierie sérieux pour écrire le vôtre.
- Aucune vérification de type sur les appels de sous-programme. Vous pouvez transmettre (ou ne pas transmettre) quoi que ce soit lors d'un appel de sous-programme, le sous-programme appelé supposera allègrement qu'il a les paramètres corrects et il n'y a aucun moyen de détecter des paramètres manquants ou invalides.
- 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 des tâches de complétion manuellement à plusieurs reprises.
- Tout est implémenté en tant que mot-clé. Parce que les auteurs du langage n'ont pas le concept d'une bibliothèque, chaque nouvelle fonctionnalité finit par être implémentée avec de nouveaux mots clés, par exemple PARSE et RENDER pour le support XML.
Les malentendus, c'est-à-dire les critiques communément dirigées contre la chère vieille langue qui sont invalides ou non pertinentes.
Verbosité. Vous tapez donc quelques caractères supplémentaires! Ce n'est pas un problème grave. Dans de nombreux cas, COBOL est moins verbeux que Java.
"FICHIERS COBOL" Vous voyez ce terme beaucoup tourné autour. Il n'y a rien de tel que COBOL peut gérer à peu près n'importe quel format de fichier et à peu près n'importe quelle organisation de fichiers.
- Pas de multi-threading. Dans les environnements où COBOL prospère, le multithread est généralement laissé à des conteneurs d'application comme CICS ou IMS qui sont bons dans ce domaine, plutôt que des programmeurs qui ont tendance à être mauvais dans ce domaine.
Et les bonnes choses - certains aspects de COBOL sont supérieurs aux autres langues: -
- Structures de données. COBOL a 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 un arrondi approprié, etc.
- Bouger avec le Times. Certains aspects de COBOL sont étonnamment modernes. Prise en charge XML intégrée, prise en charge de la programmation OO, la possibilité d'utiliser Java classes, etc.
- Intégration avec DB2, CICS, etc. Cela ne s'applique qu'au COBOL mainframe d'IBM (mais c'est de loin le plus gros morceau de COBOL encore en cours d'exécution) mais l'intégration avec DB2, CICS et d'autres environnements mainframe facilite le codage de choses comme la base de données sauvegardée services Web que dans tout autre environnement.
- Manipulation d'écran. La gestion d'écran standard telle qu'implémentée sur AS/400 et MicroFocus Cobol est excellente.
- Performance. Depuis de nombreuses années, les compilateurs COBOL produisent des exécutables à très hautes performances. Seuls le C natif et l'assembleur natif ont battu COBOL sur un ordinateur central IBM.
Donc, dans l'ensemble, il se débrouille très bien pour quelque chose qui a été mis sur pied par un comité dans les années 1950. Si une application existante est implémentée dans COBOL et fait le travail, il n'y a aucune raison de la réécrire. Cependant, à moins qu'il n'y ait une très bonne raison, je ne vois aucune justification pour que de nouveaux projets utilisent COBOL.
C'est probablement à Djikstra. Djikstra a déclaré que "l'utilisation du COBOL paralyse l'esprit; son enseignement devrait donc être considéré comme une infraction pénale". Cobol était considéré comme naïf, non structuré et bavard. Avec la possibilité d'auto-altération du code (une pratique découragée même parmi les programmeurs Cobol), il a été considéré comme assez difficile à déboguer ou à suivre également.
Ensuite, il y a aussi la question de la grande incompatibilité entre les versions.
Je suggère de lire la section critique et défense de Wikipedia pour la langue - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense
C'est l'âge et la verbosité sont généralement les choses qui font gémir les gens à ce sujet.
Il me semble que l'objectif principal d'IBM lors de la conception de COBOL é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 maintenant il a évolué.
Apparemment, il y a plus de COBOL dans la nature que toute 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 était implémenté.
Qu'est-ce qui est si mauvais avec COBOL?
Rien.
Je pense que les gens ont une idée préconçue que l'ancien est mauvais, "le plus récent est le meilleur". Il est toujours très utilisé, et je suis sûr qu'il y aura suffisamment de travaux de maintenance sur le code pour un autre demi-siècle.
En 1997, le groupe Gartner a signalé que 80% des activités mondiales fonctionnaient sur 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 sélectionner le meilleur outil pour le travail, et avec certaines industries 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.
S'il y a un problème avec le code hérité qui a l'air ancien, tant que vous pouvez gifler une interface utilisateur ou une interface Web devant lui, la plupart des utilisateurs ne sauront même pas la différence.
Les gens n'aiment pas COBOL car 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 tout cela a en commun? Données. Beaucoup, beaucoup de données.
Devinez qui a été conçu pour croquer les données et avoir beaucoup de fichiers pour le petit déjeuner? Pouvez-vous dire COmmon Business-Oriented Language?
Il y a 50 ans, COBOL était la meilleure solution pour les grandes organisations avec beaucoup de données à gérer. Aujourd'hui, il existe de meilleures façons de gérer un grand volume de données, de sorte que COBOL n'est plus pertinent. Ou est-ce?
Prenons les gouvernements. Quelles données un gouvernement doit-il suivre? Identifiants de personnes, 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, en effet, les banques sont de grands utilisateurs de COBOL. Pourquoi? car contrairement aux autres types d'entreprises, 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 toujours être ici avec nous, 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 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 a été de plus en plus coûteux de migrer les systèmes. Ce qui signifie qu'ils doivent rester dans COBOL et être constamment maintenus et évolués à mesure que les affaires évoluent. Certaines banques migrent lentement tandis que d'autres collent simplement une interface Nice Web2.0 devant le mainframe (c # et Java sont les plus utilisés). Pouvez-vous dire du code hérité? (COBOL va de pair avec le code hérité (extrême), certains qui ont été touchés par de nombreuses personnes au cours des 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 est affectée.
Et les gens qui entrent dans COBOL découvrent finalement que vous faites la même chose encore et encore et encore, année après 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 gens 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 font pas la coupe doivent passer à autre chose. Et ils doivent commencer en tant que juniors car COBOL paralyse vraiment l'esprit (croyez que ce n'est pas le copier-coller est le principal style de développement de COBOL et représente une grande et grande productivité) et maintenant ils maudissent le jour où ils ont ramassé COBOL et ne perdez aucune occasion de raconter leurs histoires d'horreur à ce sujet :). Mais vous pourriez raconter ces histoires à propos de n'importe quel vieux langage de pet qui n'est plus en demande ces jours-ci, mais vous êtes la personne malheureuse coincée avec elle. Eh bien ...
P.S. et COBOL est mauvais pour toutes les autres raisons mentionnées par les autres :)
P.S.2.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? Est-ce qu'ils sont allés faire toutes les entreprises de la Parole et leur ont demandé combien de lignes de COBOL ont-ils ou quoi?
Deux fonctionnalités.
L'instruction ALTER est un mal pur. Bien que rarement utilisé dans les applications COBOL plus modernes, il a été largement utilisé dans les "temps anciens" car il était plus efficace que la structure équivalente "IF-GOTO". Lorsque les ordinateurs n'avaient que 32 Ko de RAM, chaque instruction importait. Il a modifié une instruction GOTO pour avoir une destination différente.
Cela a rendu le code opaque car le code lui-même était avec état.
La clause REDEFINES dans une structure de données (comme le
unionen 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 trivialement par les données; seule une lecture approfondie de la logique du programme pourrait déterminer ce qui signifie des deux interprétations alternatives des octets.Cela a rendu de nombreuses structures de données opaques car les données ne peuvent pas être comprises sans le code.
La lisibilité de la syntaxe de type anglais a été mise en échec par ces deux constructions.
[J'ai été averti par des modérateurs que les réponses courtes sont dédaigneuses 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.]
Je programme en COBOL depuis plusieurs bonnes années. Sa syntaxe est simple par rapport aux langages d'aujourd'hui et vous n'avez pas besoin de beaucoup de théorie pour apprendre à démarrer. COBOL a très bien fonctionné avec IBM CICS (un système de gestion des transactions en ligne) et le programmeur doit noter le code pour faire passer le nombre d'applications des utilisateurs de 1 à plusieurs milliers. CICS a fourni une interface graphique basée sur des caractères qui fonctionnait avec un écran comme unité d'affichage (pas de fenêtre). Vous pouvez afficher des graphiques à l'aide de (IBM GDDM) sur le mainframe. COBOL peut communiquer avec des fichiers indexés (VSAM et ISAM) ainsi qu'avec DB2 (relationnel basé sur SQL) et également IMS. COBOL/CICS est un environnement très robuste et vous pouvez l'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, etc.
Le problème avec COBOL est un mauvais marketing qui conduit au manque d'intérêt des tiers pour développer des outils et des environnements de programmation pour cela. En outre, son manque de prise en charge de l'interface de type Windows a entraîné une baisse de sa popularité après 1993. Le coût du mainframe a conduit les clients à rechercher des alternatives et des compilateurs pour COBOL étaient disponibles sous UNIX et DOS. Le langage C a attiré beaucoup de lumière car il a pu être plus portable et avait un accès direct aux fonctions du système d'exploitation, ce que COBOL avait très peu.
Des langages comme VB, DBase, FoxPro et Clipper avaient de meilleurs moyens d'accéder aux "bases de données" sur le PC que le COBOL comparable sur DOS, donc COBOL a perdu. CICS n'a pas été rendu bon marché sous DOS ou UNIX pendant longtemps, donc sa valeur n'était pas présente dans ces environnements.
Aujourd'hui, COBOL est pris en charge avec .NET mais je suppose qu'il a perdu la bataille sur toutes les plates-formes, sauf le mainframe (et éventuellement AS/400) où il est toujours là en raison du grand nombre d'applications critiques qui dépendent entièrement de il.
Hé, je suis allé à l'université 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 "Bonjour tout le monde!" à COBOL, il y a probablement plus de cinquante lignes, dont 95% sont nécessaires. Ce n'est tout simplement pas une langue très élégante ou attrayante. Il a également été conçu pour gérer les problèmes d'hier et ne se prête pas vraiment aux paradigmes de développement développés après 1970 environ. 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 au format fixe avec 5M de transactions ATM et effectuez un ajustement de solde simple pour chacune), mais combien de développeurs font encore ce genre de choses? Et beaucoup de systèmes utilisent XML ou JSON de nos jours, je détesterais penser à essayer d'analyser quelque chose comme ça avec COBOL (en fait, je détesterais penser à analyser en général en COBOL!)