Warum die Verachtung für COBOL? [geschlossen]

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

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 Kennzeichen einer guten Sprache? Was ist so schlimm an COBOL?

COBOL war eine der ersten Sprachen, die ich gelernt habe. Wenn Sie unzählige Versionen von Basic, drei oder vier Assemblersprachen und eine Variante von Forth ignorieren, war es eine meiner ersten fünf Sprachen und wurde gleichzeitig mit Pascal gelernt. IOW, ich antworte aus persönlicher Erfahrung mit der Sprache.

EDIT Ich sollte alte Erfahrung sagen . 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 angeworfen habe), damit ich mich auf etwas beziehen kann, 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 für viele Menschen, es ist nur , dass sehen „alt schlecht ist“ , dass jonsca bereits beschrieben hat - und auch viel mehr ein dritte Hand Pass-me-down Haltung Sache. Aber es gibt echte Probleme, die dem zugrunde liegen.

Zu wortreich zu sein ist ein echtes Problem - es gibt zu viel Unordnung im Verständnis des Codes. Dies ist bei weitem das größte Problem. Personen , die sich dem Blick MOVE, ADDund MULTIPLYusw. Aussagen entsetzt haben eine etwas übertriebene Sichts dieser Tatsache wahr - die COMPUTEErklärung zu den Aufgaben in anderen Sprachen näher ist. Aber in all diesen Abteilungen und Abteilungen herrscht immer noch viel Durcheinander. Eines der ersten Dinge, die ich in COBOL gelernt habe, war, immer eine A4-Standardseite mit SKELETON.COB zu kopieren.

COBOL hat einige interessante Funktionen, aber diese Funktionen (z. B. das PICDing) sind in der Regel eher Teil des DBMS als der Programmiersprache, und dies scheint mir normalerweise ein besserer Weg zu sein, diese Verantwortlichkeiten zu trennen. Außerdem verwenden einige Bibliotheken in anderen Sprachen etwas Vergleichbares PIC(z. B. printf und scanf in der C-Standardbibliothek). Wahrscheinlich wurde das Beste behalten, aber das Schlimmste ist gefallen.

Außerdem gab es für jedes nette Feature mindestens ein unerträgliches. Egal wie trivial eine Schleife ist, Sie müssen zum Beispiel den Körper in eine separate Prozedur verschieben. Die 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 - es gab eine GO TO, aber von deren Verwendung wurde abgeraten (zumindest, als ich COBOL verwendet habe), aber insbesondere das Schleifen wurde nicht so gut gehandhabt.

Tatsächlich war die Sprache, die ich nach COBOL am meisten erinnerte, ... dBase. Wie in Ashton-Tate dBase III +. Heutzutage erinnern sich die Leute eher an all die jetzt toten oder sterbenden Klone (Clipper, FoxPro usw.), die zu dem 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 jedes COBOL-Programm, das mit einer bestimmten Datenbank arbeitet, eine Kopie der Spezifikation dieser Datenbank enthalten muss (und die Kopien möglicherweise inkonsistent sind), ist dies in xBase nicht wirklich der Fall, wenn die Datenbank ihre eigene Struktur kennt.

Unter Berücksichtigung dessen ist COBOL also nicht so schrecklich, wenn Sie es als das akzeptieren, was es ist. Was es aber nicht ist, ist eine Sprache zum Schreiben von Datenstrukturen. Das mag der Grund sein, warum COBOL in der Zeit 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 SORTBefehl nicht beschrieb und sagte, dass er außerhalb des Geltungsbereichs des Buches lag - anscheinend konnte entweder der Autor die Idee des Sortierens nicht bewältigen oder hielt es für mehr, als die kleinen Köpfe der COBOL-Studenten verkraften konnten [siehe Bearbeiten am Ende]. So etwas machte es sehr schwer, COBOL ernst zu nehmen.

Ein merkwürdiger Aspekt dabei 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 war das Zeichnen eines Strukturdiagramms für die Eingabe, dann eines Strukturdiagramms für die Ausgabe und dann des dazwischen liegenden Strukturdiagramms für den Code. Die Sortierung sollte eindeutig ein bereits gelöstes Problem sein - Sie konnten auf diese Weise keinen Sortieralgorithmus ableiten. So war es seltsam, von dem empfohlenen Lehrbuch erzählt zu werden, dass das gesamte Konzept des Sortierens über meinen kleinen Verstand hinausging und gleichzeitig so etwas wie ein Dutzend verschiedener Sortieralgorithmen und deren Implementierung in Pascal unterrichtet wurde.

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

BEARBEITEN am 30. Juli 2014

Ich habe gerade einen Reputationsschub bekommen, der mich daran erinnert, dass es hier ist. Wie es passiert, kann ich jetzt aufgrund von nostalgischem Buchsammeln einen Punkt für den SORTBefehl korrigieren .

Das Buch, das ich ursprünglich als empfohlenen Text beim Lernen 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).

Kommentar darunter: "Sie sollten die Eingabedateien sortieren, bevor Sie sie lesen, oder die Ausgabedatei nach dem Generieren sortieren, indem Sie das mit dem Betriebssystem gelieferte Dienstprogramm sort verwenden." In meiner Antwort darauf habe ich den Punkt "Mit dem Betriebssystem gekommen" verpasst. Kindall schlug etwas vor, das der Unix-Philosophie AFAICT ähnelte, wobei COBOL für die Bits verwendet wurde, für die es gut ist, OS-Dienstprogramme, wie ein Sortierdienstprogramm, das für einige andere Dinge verwendet wird, und vermutlich eine Stapel- / Skript- / Shell-Sprache, um die Bits zusammenzukleben. Dies ist in einer antiken Welt, in der interaktive Software selten oder gar nicht vorhanden war, viel sinnvoller, sodass Sie ohnehin Stapel von Arbeiten einreichen würden (daher "Stapelsprache").

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

Die Verwendung von geordneten seriellen Dateien setzt voraus, dass die Datensätze in einer Datei in einer bestimmten Reihenfolge nach Schlüssel sortiert werden können. Die meisten größeren Computersysteme verfügen über ein Sortierdienstprogramm, das eine Datei anhand der Position, des Typs und der 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 häufig 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 des Aktualisierens solcher Dateien wird in Betracht gezogen.

Kurz gesagt, irgendwie ist es richtig - die Annahme war, dass das Sortieren normalerweise außerhalb von COBOL erfolgen würde. Es mag sogar eine echte Rechtfertigung dafür gegeben haben, um 1974 das Sortieren von kleinen Computern aus einer Programmiersprache auszuschließen.

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

Ich möchte jedoch noch darauf hinweisen, dass ich COBOL formell anhand dieses empfohlenen Buches studiert habe, das die Norm von 1974 (nicht die Norm von 1985) in den Jahren 1988 und 1989 abdeckte. Die dritte Ausgabe von "COBOL for Students" (Parkin, Yorke, Barnes) - Die erste Ausgabe von 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 muss nicht unbedingt bedeuten, dass die COBOL-Welt auf den Beinen ist - na ja, sowieso nicht so sehr. Die Übernahme neuer Standards braucht Zeit für jede Sprache, auch jetzt noch.

Nachdem ich den größten Teil des heutigen Tages damit verbracht habe, COBOL zu schreiben, denke ich, dass ich einige aktuelle Beiträge liefern kann.

Zuerst das SCHLECHTE: -

• Keine Funktionsaufrufe. Modernes COBOL hat einige eingebaute Funktionen, aber es ist eine ernstzunehmende Aufgabe, eigene Funktionen zu schreiben.
• Keine Typprüfung bei Unterprogrammaufrufen. Sie können bei einem Unterprogrammaufruf alles übergeben (oder nicht übergeben), das aufgerufene Unterprogramm geht 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 über das Konzept einer Bibliothek verfügen, wird jedes neue Feature mit neuen Schlüsselwörtern implementiert, z. B. PARSE und RENDER für XML-Unterstützung.

Das Missverständnis, dh die Kritikpunkte, die allgemein gegen die liebe alte Sprache gerichtet sind und die 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-DATEIEN" Sie sehen diesen Begriff häufig. Es gibt nicht nur das COBOL mit jedem Dateiformat und jeder Dateiorganisation umgehen kann.

• Kein Multithreading. In Umgebungen, in denen COBOL erfolgreich ist, wird Multithreading normalerweise Anwendungscontainern wie CICS oder IMS überlassen, die darin gut sind, und nicht 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 präzise und flexible Syntax zum Definieren komplexer Datenstrukturen und ungerader Datentypen.
• Dezimalarithmetik. Es bietet native Unterstützung für Dezimalarithmetik, dh 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, Verwendung von Java-Klassen usw.
• Integration mit DB2, CICS usw. Dies gilt nur für IBMs Mainframe-COBOL (dies ist jedoch der mit Abstand größte Teil von COBOL, der noch ausgeführt wird). Die Integration in DB2, CICS und andere Mainframe-Umgebungen erleichtert jedoch das Codieren von Objekten wie datenbankgesicherten Umgebungen Web-Services als in jeder anderen Umgebung.
• Bildschirmhandhabung. Die auf AS / 400 und MicroFocus Cobol implementierte Standard-Bildschirmbedienung ist ausgezeichnet.
• Performance. COBOL-Compiler produzieren seit vielen Jahren sehr leistungsfähige ausführbare Dateien. Nur Native C und Native Assembler schlagen COBOL auf einem IBM-Mainframe.

Alles in allem ist es also recht gut für etwas, das in den 1950er Jahren von einem Komitee zusammengestellt wurde. Wenn eine vorhandene Anwendung in COBOL implementiert ist und den Job ausführt, gibt es keinen Grund, sie neu zu schreiben. Allerdings sehe ich keine Rechtfertigung für die Verwendung von COBOL in neuen Projekten, es sei denn, es gibt einen wirklich guten Grund.

Dies liegt wahrscheinlich an Djikstra. Djikstra erklärte, dass "die Verwendung von COBOL den Verstand lähmt; seine Unterweisung sollte daher als Straftat angesehen werden." Cobol wurde als naiv, unstrukturiert und wortreich angesehen. Die Fähigkeit, Code selbst zu ändern (eine Übung, von der selbst Cobol-Programmierer abgeraten haben), wurde als ziemlich schwierig angesehen, Fehler zu beheben oder auch 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

Es ist Alter und Ausführlichkeit sind in der Regel die Dinge, die die Leute darüber stöhnen.

Ich erinnere mich, dass das Hauptziel von IBM bei der Entwicklung 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 jetzt hat sie sich weiterentwickelt.

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

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 ist immer noch sehr viel im Einsatz und ich bin mir sicher, dass für ein weiteres halbes Jahrhundert genügend Wartungsarbeiten an Code durchgeführt werden müssen.

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

Beim Codieren muss man immer das beste Werkzeug für den Job auswählen, 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 veraltet aussehendem Legacy-Code gibt, werden die meisten Benutzer den Unterschied nicht einmal bemerken, solange Sie eine Benutzeroberfläche oder ein Webinterface davor platzieren können.

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 alle gemeinsam? Daten. Viele, viele Daten.

Ratet mal, wer wurde entwickelt, um Daten zu brechen 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? Personalausweise, Geburtsurkunden, Krankenakten, Steuern (oh ... ja ... Steuern) usw. usw. Und diese Informationen müssen sie heute und vor 50 Jahren auch auf unbestimmte Zeit aufbewahren.

In einigen Antworten wurden auch Banken genannt, und in der Tat nutzen Banken COBOL in hohem Maße. Warum? Denn im Gegensatz zu anderen Unternehmenstypen haben Banken in der Regel eine Geschichte. Einige existieren seit Hunderten von Jahren ( wie diese 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 Behörden und Banken immer größer und die Migration der Systeme immer teurer. Das heißt, sie müssen in COBOL bleiben und während der Geschäftsentwicklung ständig gewartet und weiterentwickelt werden. Einige Banken migrieren langsam, während andere einfach eine schöne Web2.0-Oberfläche vor den Mainframe kleben (meistens werden C # und Java verwendet). Können Sie Legacy-Code sagen? (COBOL geht Hand in Hand mit (extremem) Legacy-Code, der über Jahrzehnte von vielen Menschen berührt wurde - eine andere Sache, die wir Programmierer nicht mögen: D).

Und jetzt haben Sie eine Nische der Tätigkeit. COBOL kann nur begrenzt angewendet werden, und Ihre Erfahrung ist davon betroffen .

Und Menschen, die sich mit COBOL beschäftigen, stellen schließlich fest, dass Sie Jahr für Jahr immer wieder dasselbe tun, und wenn sie aufwachen, sind sie auf dem Markt nicht mehr wettbewerbsfähig, weil die Leute jetzt PHP, Java, C # wollen. , REST, jQuery und nur Banken suchen COBOL-Mitarbeiter.

Zu diesem Zeitpunkt ist die Nachfrage geringer als das Angebot, und diejenigen, die es nicht schaffen, müssen zu etwas anderem übergehen. Und sie müssen als Junioren anfangen, da COBOL wirklich den Verstand lähmt (glauben Sie, dass nicht Kopieren-Einfügen der Hauptentwicklungsstil in COBOL ist und für die große Produktivität des Unternehmens verantwortlich ist), und jetzt verfluchen sie den Tag, an dem sie sich für COBOL entschieden und sich entschieden haben. keine Gelegenheit verpassen, 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...

PS und COBOL sind aus allen anderen von den anderen genannten Gründen schlecht :)

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

Zwei Merkmale.

• Die ALTER-Anweisung ist rein böse. Während es in moderneren COBOL-Anwendungen selten verwendet wurde, wurde es in den "alten Tagen" häufig verwendet, da es effizienter war als die entsprechende "IF-GOTO" -Struktur. Wenn Computer nur 32 KB RAM hatten, zählte jeder Befehl. Es hat eine GOTO-Anweisung 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 unionin C) ist ein fortwährendes Problem. Der Begriff "freie Union" - dh überlagerte Datenstrukturen ohne Diskriminator - ist eine Möglichkeit, das Problem zusammenzufassen. Zwei REDEFINES-Aliase können anhand der Daten nicht trivial unterschieden werden. Nur ein umfassendes Lesen der Programmlogik kann die 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 englischen 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 ablehnend finden, könnten Sie nach Einzelheiten fragen. Oder markieren Sie es, damit die Moderatoren es löschen können.]

Ich habe mehrere gute Jahre in COBOL programmiert. Die Syntax ist im Vergleich zu den heutigen Sprachen einfach und man braucht nicht viel Theorie, um zu lernen, wie man loslegt. COBOL hat sehr gut mit IBMs CICS (einem Online-Transaktionsmanagementsystem) zusammengearbeitet, und der Programmierer muss den Code notieren, um die Anwendungsanzahl der Benutzer von 1 auf mehrere Tausend zu skalieren. CICS lieferte eine zeichenbasierte GUI, die mit einem Bildschirm als Anzeigeeinheit (ohne Fenster) arbeitete. Sie können Diagramme mit (IBMs GDDM) auf dem Mainframe anzeigen. COBOL kann sowohl mit indizierten Dateien (VSAM und ISAM) als auch mit DB2 (SQL-basiert relational) und auch mit 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 zu mangelndem Interesse von Dritten an der Entwicklung von Tools und Programmierumgebungen für COBOL führt. Auch die mangelnde Unterstützung von Windows-ähnlichen Benutzeroberflächen führte nach 1993 zu einer Abnahme der Popularität. Die Kunden, die nach Alternativen und Compilern für COBOL suchten, waren für UNIX und DOS verfügbar. Die C-Sprache hat viel Licht ins Dunkel gebracht, da sie portabler sein und direkten Zugriff auf OS-Funktionen haben konnte, wovon COBOL 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, sodass sein Wert in diesen Umgebungen nicht vorhanden war.

Heutzutage wird COBOL mit .NET unterstützt, aber ich vermute, dass es den Kampf auf allen Plattformen verloren hat, mit Ausnahme des Mainframes (und möglicherweise AS / 400), auf denen es immer noch verfügbar ist, da eine Vielzahl von geschäftskritischen Anwendungen vollständig von .NET abhängig ist es.

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 ist wahrscheinlich über fünfzig Zeilen, von denen 95% Boilerplate erforderlich sind. Es ist einfach keine sehr elegante oder attraktive Sprache. Es wurde auch entwickelt, um die Probleme von gestern zu bewältigen, und eignet sich nicht wirklich für Entwicklungsparadigmen, die nach 1970 entwickelt wurden. Es ist eine ziemlich gute Berichterstellungssprache - solange Ihre Berichte endlose Spalten von Zahlen mit Kopf- und Fußzeilen sind. Wenn Sie irgendwo eine Grafik 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 führen Sie für jede eine einfache Balance-Anpassung durch). Aber wie viele Entwickler machen so etwas noch? Und viele Systeme verwenden heutzutage XML oder JSON. Ich würde gerne versuchen, so etwas mit COBOL zu analysieren (eigentlich würde ich gerne über das Parsen in COBOL nachdenken!).