it-swarm.com.de

Warum die Verachtung für COBOL?

Wenn Leute COBOL erwähnen, wird es normalerweise entweder mit einem Schnauben oder einem Stöhnen aufgenommen. Ich weiß nicht viel über COBOL, aber ich habe einige darin geschriebene Programme gesehen. Ich kann sehen, dass es wortreich und für nicht eingeweihte Augen wie meine unverständlich ist. Aber sind wirklich nicht alle Programmiersprachen für einen Laien ein kompletter Kauderwelsch?

Ich verstehe, dass es funktioniert, gut funktioniert und in den Branchen, für die es entwickelt wurde, immer noch weit verbreitet ist. Sind das nicht die Markenzeichen einer guten Sprache? Was ist so schlimm an COBOL?

52
Barry Brown

COBOL war eine der ersten Sprachen, die ich gelernt habe - wenn Sie unzählige Versionen von Basic, drei oder vier Assembler-Sprachen und eine Variante von Forth ignorieren, dann war es in meinen ersten fünf und lernte gleichzeitig mit Pascal. IOW, ich antworte aus persönlicher Erfahrung mit der Sprache.

EDIT Ich sollte sagen uralt Erfahrung. Ich habe die Sprache nach Ende der 80er Jahre nie mehr benutzt, obwohl ich ein neues Buch gekauft habe (als Ersatz für das alte, das ich angewidert weggeworfen habe), damit ich mich auf etwas beziehen konnte, damit meine Horrorgeschichten nicht zu verzerrt werden. Aber ich habe keine Ahnung, wie sich die Sprache in den letzten 20 Jahren entwickelt hat.

Offensichtlich ist es für viele Menschen ist Nur diese "alte ist schlecht" -Ansicht, die Jonsca bereits beschrieben hat - und noch viel mehr eine Sache mit Pass-Me-Down-Einstellungen aus dritter Hand. Aber dem liegen echte Probleme zugrunde.

Zu wortreich zu sein ist ein echtes Problem - das Verständnis des Codes ist zu unübersichtlich. Dies ist bei weitem das größte Problem. Menschen, die die Aussagen MOVE, ADD und MULTIPLY usw. entsetzt betrachten, haben eine leicht übertriebene Ansicht davon, wahr - die Anweisung COMPUTE ist näher dran die Aufgaben in anderen Sprachen. Aber in all diesen Abteilungen und Abschnitten herrscht immer noch viel Unordnung. Eines der ersten Dinge, die ich in COBOL gelernt habe, war, immer zunächst eine Standardseite von A4-langem SKELETON.COB zu kopieren.

COBOL tut hat einige interessante Funktionen, aber diese Funktionen (z. B. das PIC -Ding) sind eher Dinge, die jetzt eher Teil des DBMS als der Programmiersprache sind, und das auch scheint mir normalerweise ein besserer Weg zu sein, diese Verantwortlichkeiten zu trennen. Außerdem verwenden einige Bibliotheken in anderen Sprachen etwas, das mit PIC vergleichbar ist (z. B. printf und scanf in der C-Standardbibliothek). Das Beste wurde wohl behalten, aber das Schlimmste fiel.

Außerdem gab es für jedes Nice-Feature mindestens ein unerträgliches. Egal wie trivial eine Schleife ist, Sie müssen den Körper beispielsweise in eine separate Prozedur verschieben. Das PERFORM ... UNTIL ... und ähnliche Anweisungen sind einzelne Anweisungen - keine Blockstrukturen. In gewisser Weise war COBOL ein Vorgeschmack auf strukturierte Programmierung, bevor die strukturierte Programmierung erfunden wurde - dort war a GO TO, aber von seiner Verwendung wurde abgeraten (zumindest als ich COBOL verwendet habe), aber insbesondere das Schleifen wurde einfach nicht so gut gehandhabt.

Tatsächlich war die Sprache, die ich verwendet habe nach COBOL, die mich am meisten daran erinnerte, ... dBase. Wie in Ashton-Tate dBase III +. Heutzutage erinnern sich die Menschen eher an all die jetzt toten oder sterbenden Klone (Clipper, FoxPro usw.), die zum generischen Namen xBase geführt haben - und es gibt immer noch einen lebenden Nachkommen in xHarbour. Der Punkt ist, dass dies Datenbanksprachen waren, aber nichts wie SQL.

Selbst dann, wenn every COBOL-Programm, das auf einer bestimmten Datenbank ausgeführt wird, eine Kopie der Spezifikation dieser Datenbank enthalten muss (und die Kopien möglicherweise inkonsistent werden), ist dies in nicht wirklich der Fall xBase, in der die Datenbank ihre eigene Struktur kennt.

Wenn man das berücksichtigt, ist COBOL nicht so schrecklich, wenn man es so akzeptiert, wie es ist. Aber was es ist nicht ist eine Sprache zum Schreiben von Datenstrukturen. Dies mag der Grund sein, warum COBOL in den Zeiten der heiligen Kriege zwischen C und Pascal viel gelitten hat - beide Seiten waren sich einig, dass COBOL nicht gut war, um den Binärbaum noch einmal neu zu erfinden.

Oh - und eine Sache, die ich nie vergessen werde, ist, wie mein erstes COBOL-Lehrbuch den Befehl SORT nicht beschrieb und sagte, dass er außerhalb des Rahmens des Buches lag - anscheinend konnte entweder der Autor die Idee des Sortierens nicht bewältigen oder erachtete sie als mehr, als die winzigen Köpfe der COBOL-Studenten bewältigen konnten [siehe Bearbeiten am Ende]. So etwas machte es sehr schwierig, COBOL ernst zu nehmen.

Ein merkwürdiger Aspekt davon war Jackson Structured Programming, das ich ungefähr zur gleichen Zeit lernen musste, und zwar speziell für die Verwendung mit COBOL. Ein Teil davon bestand darin, ein Strukturdiagramm für die Eingabe, dann ein Strukturdiagramm für die Ausgabe und dann das Zwischenstrukturdiagramm für den Code zu zeichnen. Es wurde eindeutig erwartet, dass das Sortieren ein bereits gelöstes Problem ist - auf diese Weise konnte kein Sortieralgorithmus abgeleitet werden. Es war also seltsam, von dem empfohlenen Lehrbuch zu erfahren, dass das gesamte Konzept des Sortierens über meinen kleinen Verstand hinausging, während mir gleichzeitig etwa ein Dutzend verschiedene Sortieralgorithmen beigebracht wurden und wie man sie in Pascal implementiert.

Die Probleme, mit denen JSP umgehen kann, sind wahrscheinlich ein guter Leitfaden für die Dinge, die COBOL relativ gut kann. Aber selbst dann bedeutet das nicht unbedingt, dass entweder JSP oder COBOL gute Möglichkeiten sind, um diese Probleme zu lösen.


EDIT am 30. Juli 2014

Ich habe gerade einen Reputationsschub bekommen, der mich daran erinnert, dass es hier ist. Zufällig kann ich jetzt aufgrund eines von Nostalgie geprägten alten Büchersammelns einen Punkt korrigieren, indem ich den Befehl SORT schreibe.

Das Buch, das ich ursprünglich als empfohlenen Text beim Erlernen von COBOL verwendet habe, war "Methodical Programming in COBOL" von Ray Welland. Dies gilt nicht für COBOL 85 (obwohl es eine spätere Ausgabe "Methodical Programming in COBOL-85" gab, die ich noch nie gesehen habe).

kindall kommentiert unten: "Sie sollten die Eingabedateien vor dem Lesen sortieren oder die Ausgabedatei nach dem Generieren mit dem mit dem Betriebssystem gelieferten Sortierdienstprogramm sortieren." In meiner Antwort darauf habe ich den Punkt "Mit dem Betriebssystem gekommen" verpasst. Kindall schlug etwas vor, das der Unix-Philosophie AFAICT ähnelt: COBOL wurde für die Bits verwendet, für die es gut ist, Betriebssystem-Dienstprogramme wie ein Sortierdienstprogramm, das für einige andere Dinge verwendet wird, und vermutlich die Verwendung einer Batch-/Scripting-/Shell-Sprache, um die Bits zusammenzukleben. Dies ist in einer alten Welt, in der interaktive Software selten oder gar nicht vorhanden war, viel sinnvoller, sodass Sie ohnehin Stapel von Arbeiten (daher "Stapelsprache") einreichen würden.

Das Folgende wird ab Seite 165-166 von "Methodische Programmierung in COBOL" zitiert ...

Die Verwendung geordneter serieller Dateien impliziert, dass es notwendig ist, Datensätze innerhalb einer Datei in einer bestimmten Reihenfolge nach Schlüssel zu sortieren. Die meisten größeren Computersysteme verfügen über ein Sortierdienstprogramm, das eine Datei nach Position, Typ und Größe der einzelnen Datenelemente sortiert, die den Schlüssel bilden.

Es gibt auch eine Möglichkeit, Datensätze innerhalb eines COBOL-Programms zu sortieren. Dies würde jedoch aus zwei Gründen den Rahmen dieses Buches sprengen:

(a) Die Schnittstelle zum Betriebssystem ist oft recht komplex und variiert von System zu System.

(b) Das Sortiermodul ist ein optionaler Bestandteil von ANS '74 COBOL und kann möglicherweise nicht in COBOL-Systemen für kleinere Computer implementiert werden.

Daher wird davon ausgegangen, dass Einrichtungen zum Sortieren von Dateien in einer bestimmten Reihenfolge vorhanden sind, und das Problem der Aktualisierung solcher Dateien wird berücksichtigt.

Kurz gesagt, alles ist richtig - die Annahme war, dass das Sortieren normalerweise außerhalb von COBOL erfolgen würde. Möglicherweise gab es sogar eine echte Rechtfertigung dafür, das Sortieren für kleine Computer um 1974 aus einer Programmiersprache auszuschließen.

Was ich oben gesagt habe, war im Grunde das, was man nach ungefähr 20 Jahren bekommt, wenn man nicht in der Lage ist, Fakten zu überprüfen, weil man das Buch weggeworfen hat.

Ich möchte jedoch noch darauf hinweisen, dass ich COBOL aus diesem empfohlenen Buch, das 1988 und 1989 den Standard von 1974 (nicht den Standard von 1985) abdeckte, offiziell studiert habe. Die dritte Ausgabe von "COBOL for Students" (Parkin, Yorke, Barnes) - Die erste Ausgabe über COBOL 85 wurde erst 1990 veröffentlicht. Ich bin nicht sicher, aber ich denke, die COBOL 85-Ausgabe von "Methodical Programming" wurde erst 1994 veröffentlicht.

Aber das bedeutet nicht unbedingt, dass die COBOL-Welt ihre Füße schleppt - na ja, sowieso nicht so viel. Die Übernahme neuer Standards braucht Zeit für jede Sprache, auch jetzt noch.

68
Steve314

Nachdem ich den größten Teil des heutigen Tages damit verbracht habe, COBOL zu schreiben, denke ich, dass ich einen aktuellen Input geben kann.

Zuerst das SCHLECHTE Zeug: -

  • Keine Funktionsaufrufe. Modernes COBOL hat einige eingebaute Funktionen, aber es ist eine ernsthafte technische Aufgabe, eigene zu schreiben.
  • Keine Typprüfung bei Unterprogrammaufrufen. Sie können bei einem Unterprogrammaufruf alles übergeben (oder nicht übergeben), das aufgerufene Unterprogramm geht munter davon aus, dass es die richtigen Parameter hat, und es gibt keine Möglichkeit, fehlende oder ungültige Parameter zu erkennen.
  • Keine Bibliotheken. Keine Null zilch. Keine Standardbibliotheken, keine weit verbreiteten, leicht verfügbaren Bibliotheken. Am Ende codieren Sie Commomplace-Aufgaben immer wieder von Hand.
  • Alles ist als Schlüsselwort implementiert. Da die Sprachautoren nicht das Konzept einer Bibliothek haben, wird jedes neue Feature mit neuen Schlüsselwörtern implementiert, z. PARSE und RENDER für XML-Unterstützung.

Das Missverstandene, d. H. Jene Kritikpunkte, die gewöhnlich gegen die liebe alte Sprache gerichtet sind und ungültig oder irrelevant sind.

  • Ausführlichkeit. Sie geben also ein paar zusätzliche Zeichen ein! Es ist kein ernstes Problem. In vielen Fällen ist COBOL weniger ausführlich als Java.

  • "COBOL FILES" Sie sehen, dass dieser Begriff viel verbreitet ist. Es gibt keine solche Sache, nur dass COBOL nahezu jedes Dateiformat und nahezu jede Dateiorganisation verarbeiten kann.

  • Kein Multithreading. In Umgebungen, in denen COBOL erfolgreich ist, wird Multithreading normalerweise Anwendungscontainern wie CICS oder IMS) überlassen, die eher gut darin sind als Programmierern, die dazu neigen, schlecht darin zu sein.

Und das Gute - einige Aspekte von COBOL sind anderen Sprachen überlegen: -

  • Datenstrukturen. COBOL verfügt über eine übersichtliche und flexible Syntax zum Definieren komplexer Datenstrukturen und ungerader Datentypen.
  • Dezimalarithmetik. Es hat native Unterstützung für Dezimalarithmetik, d. H. Arithmetik, wie sie von Buchhaltern verstanden wird, mit korrekter Rundung usw.
  • Mit der Zeit gehen. Einige Aspekte von COBOL sind überraschend modern. Eingebaute XML-Unterstützung, Unterstützung für OO Programmierung, die Fähigkeit zur Verwendung von Java Klassen usw.).
  • Integration mit DB2, CICS usw. Dies gilt nur für IBMs Mainframe-COBOL (dies ist jedoch bei weitem der größte Teil von COBOL, der noch ausgeführt wird). Die Integration in DB2, CICS und andere Mainframe-Umgebungen erleichtert jedoch das Codieren von Dingen wie datenbankgestützt Webdienste als in jeder anderen Umgebung.
  • Bildschirmhandhabung. Die auf AS/400 und MicroFocus Cobol implementierte Standard-Bildschirmhandhabung ist ausgezeichnet.
  • Performance. Seit vielen Jahren produzieren COBOL-Compiler ausführbare Dateien mit sehr hoher Leistung. Nur natives C und natives Assembler schlagen COBOL auf einem IBM-Mainframe.

Alles in allem ist es also ziemlich gut für etwas, das in den 1950er Jahren von einem Komitee zusammengestellt wurde. Wenn eine vorhandene Anwendung in COBOL implementiert ist und die Aufgabe ausführt, gibt es keinen Grund, sie neu zu schreiben. Wenn es jedoch keinen wirklich guten Grund gibt, sehe ich keine Rechtfertigung für die Verwendung von COBOL durch neue Projekte.

43
James Anderson

Dies liegt wahrscheinlich an Djikstra. Djikstra erklärte: "Die Verwendung von COBOL lähmt den Geist. Seine Lehre sollte daher als Straftat angesehen werden." Cobol wurde als naiv, unstrukturiert und wortreich angesehen. Mit der Fähigkeit, Code selbst zu ändern (eine Praxis, die selbst unter Cobol-Programmierern nicht empfohlen wird), wurde es als ziemlich schwierig angesehen, sie zu debuggen oder zu befolgen.

Dann gibt es auch die Frage der großen Inkompatibilität zwischen den Versionen.

Ich würde vorschlagen, den Abschnitt Kritik und Verteidigung in Wikipedia für die Sprache zu lesen - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

27
Danny Staple

Alter und Ausführlichkeit sind normalerweise die Dinge, die die Leute dazu bringen, darüber zu stöhnen.

Ich erinnere mich, dass das Hauptziel von IBM beim Entwurf von COBOL darin bestand, "einem Bankmanager das Schreiben eines Programms zu ermöglichen". Dieses Ziel hatte offensichtlich einen tiefgreifenden Einfluss auf die Art und Weise, wie die Sprache entworfen wurde, und es entwickelte sich nun weiter.

Anscheinend gibt es in freier Wildbahn mehr COBOL als in jeder anderen Sprache. Nachdem ich fast 20 Jahre in der IT gearbeitet habe (15 Jahre im Bankwesen), bin ich jedoch nie auf ein einziges System gestoßen, das darin implementiert wurde.

9
Sean

Was ist so schlimm an COBOL?

Nichts.

Ich denke, die Leute haben eine vorgefasste Vorstellung, dass alt schlecht ist, "das Neueste ist das Beste". Es wird immer noch sehr häufig verwendet, und ich bin sicher, dass für ein weiteres halbes Jahrhundert genügend Wartungsarbeiten am Code durchgeführt werden.

1997 berichtete die Gartner Group, dass 80% des weltweiten Geschäfts mit COBOL mit über 200 Milliarden existierenden Codezeilen und geschätzten 5 Milliarden Zeilen neuen Codes pro Jahr betrieben wurden. (via wikipedia )

Beim Codieren muss immer das beste Werkzeug für den Job ausgewählt werden, und bei bestimmten Branchen, die mit bestimmter Hardware verheiratet sind, ist die Sprache optimal. Ich habe noch nie im Bankwesen gearbeitet, wo ich gehört hatte, dass es beliebt ist, aber Seans Antwort zeigt, dass dies nicht der Fall ist.

Wenn es ein Problem mit altem Code gibt, der alt aussieht, solange Sie eine Benutzeroberfläche oder eine Weboberfläche davor schlagen können, werden die meisten Benutzer den Unterschied nicht einmal kennen.

8
jonsca

Menschen mögen COBOL nicht, weil es nur eine begrenzte Anwendung hat. Es wurde für Geschäfts-, Finanz- und Verwaltungssysteme für Unternehmen und Regierungen entwickelt.

Was haben all diese gemeinsam? Daten. Viele, viele Daten.

Ratet mal, wer entwickelt wurde, um Daten zu verarbeiten und viele Dateien zum Frühstück zu haben? Können Sie COmmon Business-Oriented Language sagen?

Vor 50 Jahren war COBOL das Beste für große Unternehmen mit vielen zu verwaltenden Daten. Heutzutage gibt es bessere Möglichkeiten, ein großes Datenvolumen zu verwalten, sodass COBOL nicht mehr relevant ist. Oder ist es?

Betrachten wir die Regierungen. Welche Daten muss eine Regierung nachverfolgen? Personenausweise, Geburtsurkunden, Krankenakten, Steuern (oh ... ja ... Steuern) usw. usw. Und sie müssen diese Informationen heute und vor 50 Jahren auf unbestimmte Zeit aufbewahren.

In einigen Antworten wurden auch Banken genannt, und in der Tat sind Banken starke Nutzer von COBOL. Warum? denn im Gegensatz zu anderen Arten von Unternehmen haben Banken normalerweise eine Geschichte. Einige existieren seit Hunderten von Jahren ( wie dieses zum Beispiel ).

Das bedeutet, dass einige Daten aus 50 Jahren noch heute, am 7. Oktober 2011, bei uns sein müssen. Jetzt haben wir SQL Server und C # oder Oracle und Java, aber vor 50 Jahren gab es COBOL und Dateien.

Mit der Zeit wurden die Daten für Regierungen und Banken immer größer und die Migration der Systeme wurde immer teurer. Das heißt, sie müssen in COBOL bleiben und im Zuge der Geschäftsentwicklung konstant gewartet und weiterentwickelt werden. Einige Banken migrieren langsam, während andere einfach eine Nice Web2.0-Schnittstelle vor den Mainframe stellen (c # und Java werden am häufigsten verwendet). Können Sie Legacy-Code sagen? (COBOL geht Hand in Hand mit (extremem) Legacy-Code, von dem einige über Jahrzehnte hinweg von vielen Menschen berührt wurden - eine andere Sache, die wir Programmierer nicht mögen: D) .

Und jetzt haben Sie eine Nische der Aktivität. COBOL hat jetzt eine begrenzte Anwendung und Ihre Erfahrung ist betroffen .

Und Leute, die in COBOL einsteigen, stellen schließlich fest, dass Sie Jahr für Jahr immer wieder dasselbe tun und bis sie aufwachen , sind sie auf dem Markt nicht mehr wettbewerbsfähig , weil die Leute jetzt PHP, Java, C #, REST, jQuery wollen und nur Banken nach COBOL-Leuten suchen.

Zu diesem Zeitpunkt ist die Nachfrage niedriger als das Angebot, und diejenigen, die den Schnitt nicht machen, müssen zu etwas anderem übergehen. Und sie müssen als Junioren anfangen, da COBOL den Verstand wirklich verkrüppelt (glauben Sie, dass Copy-Paste nicht der Hauptentwicklungsstil in COBOL ist und für seine große Produktivität verantwortlich ist), und jetzt fluchen sie an dem Tag, an dem sie COBOL abgeholt haben und keine Gelegenheit verlieren, ihre Horrorgeschichten darüber zu erzählen :). Aber Sie könnten diese Geschichten über jede alte Furzsprache erzählen, die heutzutage nicht mehr gefragt ist, aber Sie sind die unglückliche Person, die daran festhält. Ach ja...

P.S. und COBOL ist aus all den anderen von den anderen genannten Gründen schlecht :)

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. Ja wirklich? Und wie hat der Tag das gemessen? Haben sie jede Firma im Wort gemacht und sie gefragt, wie viele COBOL-Zeilen sie haben oder was?

5
user7197

Zwei Funktionen.

  • Die ALTER-Aussage ist rein böse. Während es in moderneren COBOL-Anwendungen selten verwendet wurde, wurde es in den "alten Tagen" stark verwendet, da es effizienter war als die äquivalente "IF-GOTO" -Struktur. Wenn Computer nur 32 KB RAM hatten, war jeder Befehl wichtig. Eine GOTO-Anweisung wurde geändert, um ein anderes Ziel zu haben.

    Dies machte einen Code undurchsichtig, da der Code selbst zustandsbehaftet war.

  • Die REDEFINES-Klausel in einer Datenstruktur (wie die union in C) ist ein fortwährendes Problem. Der Begriff "freie Vereinigung" - d. H. Überlagerte Datenstrukturen ohne Diskriminator - ist eine Möglichkeit, das Problem zusammenzufassen. Zwei REDEFINES-Aliase können durch die Daten nicht trivial unterschieden werden. Nur ein umfassendes Lesen der Programmlogik konnte das Bedeutung der beiden alternativen Interpretationen der Bytes bestimmen.

    Dies machte viele Datenstrukturen undurchsichtig, da die Daten ohne den Code nicht verstanden werden können.

Die Lesbarkeit der englischsprachigen Syntax wurde durch diese beiden Konstrukte beeinträchtigt.

[Ich wurde von Moderatoren gewarnt, dass kurze Antworten Ihre wichtige und interessante Frage ablehnen. Wenn Sie dies abweisend finden, können Sie nach Details fragen. Oder kennzeichnen Sie es, damit die Moderatoren es löschen können.]

4
S.Lott

Ich habe mehrere gute Jahre in COBOL programmiert. Die Syntax ist im Vergleich zu den heutigen Sprachen einfach und Sie müssen nicht viel Theorie lernen, um loszulegen. COBOL hat sehr gut mit IBMs CICS (einem Online-Transaktionsmanagementsystem) zusammengearbeitet, und der Programmierer muss im Code Notizen machen, um die Anwendungsanzahl der Benutzer von 1 auf mehrere Tausend zu skalieren. CICS stellte eine zeichenbasierte Benutzeroberfläche zur Verfügung, die mit einem Bildschirm als Anzeigeeinheit (keine Fenster) arbeitete. Sie können Diagramme mit (GDDM von IBM) auf dem Mainframe anzeigen. COBOL kann sowohl mit indizierten Dateien (VSAM und ISAM) als auch mit DB2 (SQL based relational) und IMS kommunizieren. COBOL/CICS ist eine sehr robuste Umgebung, die Sie in wenigen Wochen erlernen können. Das bedeutet, dass Sie sich auf das Geschäft konzentrieren, nicht auf die Technologie. Sie arbeiten also 7 von 8 Stunden an der Codierung, ohne MVM, JavaScript und dergleichen zu lernen.

Das Problem bei COBOL ist schlechtes Marketing, das dazu führt, dass Dritte kein Interesse daran haben, Tools und Programmierumgebungen dafür zu entwickeln. Aufgrund der mangelnden Unterstützung für Windows-ähnliche Benutzeroberflächen ging die Popularität nach 1993 zurück. Die Mainframe-Kosten führten dazu, dass Kunden nach Alternativen und Compilern für COBOL suchten, die unter UNIX und DOS verfügbar waren. Die C-Sprache zog viel Licht ins Dunkel, da sie portabler sein konnte und direkten Zugriff auf Betriebssystemfunktionen hatte, von denen COBOL nur sehr wenig hatte.

Sprachen wie VB, DBase, FoxPro und Clipper hatten bessere Möglichkeiten, auf 'Datenbanken' auf dem PC zuzugreifen als das vergleichbare COBOL unter DOS, sodass COBOL verloren ging. CICS wurde unter DOS oder UNIX lange Zeit nicht billig gemacht, daher war sein Wert in diesen Umgebungen nicht vorhanden.

Heute wird COBOL mit .NET unterstützt, aber ich denke, dass es den Kampf auf allen Plattformen außer dem Mainframe (und möglicherweise AS/400) verloren hat, auf dem es aufgrund der großen Anzahl geschäftskritischer Anwendungen, die vollständig abhängig sind, immer noch vorhanden ist es.

3
NoChance

Heh, ich bin in den frühen 80ern aufs College gegangen, und die Leute haben COBOL schon damals verachtet. Ich denke, das größte Problem ist seine Ausführlichkeit - ein einfaches "Hallo Welt!" in COBOL sind wahrscheinlich über fünfzig Zeilen, von denen 95% Boilerplate benötigt werden. Es ist einfach keine sehr elegante oder attraktive Sprache. Es wurde auch entwickelt, um die Probleme von gestern zu lösen, und eignet sich nicht wirklich für Entwicklungsparadigmen, die nach etwa 1970 entwickelt wurden. Es ist eine ziemlich gute Sprache für die Berichterstellung - solange Ihre Berichte endlose Spalten mit Zahlen in Kopf- und Fußzeilen sind. Wenn Sie irgendwo ein Diagramm oder ein Logo einfügen möchten, vergessen Sie es. Ich denke, es ist immer noch die schnellste Sprache für Aufgaben vom Typ "Datenverarbeitung" (nehmen Sie eine Datei mit festem Format mit 5 Millionen Geldautomaten-Transaktionen und nehmen Sie für jede eine einfache Balance-Anpassung vor), aber wie viele Entwickler machen solche Dinge noch? Und viele Systeme verwenden heutzutage XML oder JSON. Ich würde es hassen, darüber nachzudenken, so etwas mit COBOL zu analysieren (eigentlich würde ich es hassen, über das Parsen im Allgemeinen in COBOL nachzudenken!).

2
TMN