Warum die Verachtung für COBOL? [geschlossen]

52

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?

Barry Brown
quelle
8
COBOL ist in Ordnung, um hierarchische Datenbanken oder flache Dateien zu bearbeiten und Daten in große Nur-Text-Berichte auf einem riesigen Nadeldrucker zu pumpen. Heutzutage befinden sich die meisten Daten in RDBMS und die meisten Manager mögen hübsche Berichte. COBOL kommt damit einfach nicht so gut klar.
pdr
1
@ Steve314: Ja! Jene! Außer unsere waren Line Matrix, und ich hatte heute Morgen keinen Kaffee getrunken, als ich das geschrieben habe. - en.wikipedia.org/wiki/Line_matrix_printer
pdr
3
Ohne COBOL herausgreifen zu müssen, werden Sie, wenn Sie ein wenig suchen, feststellen, dass viele domänenspezifische Sprachen hier nicht sehr beliebt sind (gelinde gesagt). COBOL, Fortran, VB6, MATLAB ... alles sehr gute Sprachen, nur nicht gut zum Unterrichten der Informatik und ihrer Abstraktionen.
Rook
4
@Rook - zählen diese wirklich alle als domänenspezifische Sprachen? Sogar MATLAB, IIRC, ist immer noch in der Lage, universelle Programme zu erstellen. Ich dachte, DSL würde hauptsächlich auf Dinge wie Yacc, Lex usw. angewendet - Sprachen, die nur zu einer ziemlich engen Aufgabe fähig sind, was zu dem anderen gebräuchlichen Namen "kleine Sprachen" führt. Mir ist nie in den Sinn gekommen, dass COBOL, Fortran oder VB domänenspezifisch genannt werden könnten. Natürlich werden sie in der Regel in bestimmten Bereichen verwendet, aber ich dachte, sie würden immer noch als universelle Sprachen betrachtet.
Steve314
1
@ Steve314 - Ja, gut - wir können sagen, dass es zwei Seiten gibt. Man sagt die dom.spec. Bei den einen handelt es sich nur um die von Ihnen erwähnten, bei den anderen handelt es sich um eine allgemeinere Sichtweise und zählt auch bei der von mir erwähnten, wobei sie jedoch weiterhin in der Kategorie für allgemeine Zwecke bleiben. Aber praktisch überall dort, wo Sie Technik und Wissenschaft erwähnen. comp. Sie erhalten Fortran oder MATLAB, business ... COBOL ... verwenden die Terminologie, die Ihnen am logischsten erscheint. Ich benutze diese, weil ich finde, dass sie zu den meisten Leuten passt. In jedem Fall erhalten sie aus irgendeinem Grund einen angemessenen Anteil an Bashing von der cs-Community im Allgemeinen.
Rook

Antworten:

68

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.

Steve314
quelle
5
+1 Um zu wissen, wovon Sie sprechen. Ich wünschte, ich könnte dir noch +1 für JSP geben. Hast du jemals "Delta" benutzt? Es war ein Cobol-Generator, so dass Sie Ihre JSP in den Code schreiben konnten, ähnlich wie bei den Speicherdefinitionen (01 - 03 - 05), und dann Ihr Cobol in die Lücken schreiben konnten. Spaß und frustrierend wie die Hölle.
pdr
3
Wikipedia-Seite zu JSP - de.wikipedia.org/wiki/Jackson_Structured_Programming . Als ich es lernte, wurde alles auf Papier gemacht.
Steve314
1
Der Grund, warum das Sortieren als ein gelöstes Problem behandelt wurde, war, dass es war. Nach meiner Erinnerung hat COBOL wirklich davon abgeraten, mehr als ein oder zwei Datensätze gleichzeitig im Speicher zu haben (den aktuellen und möglicherweise den vorherigen Datensatz ). Sie sollten die Eingabedateien vor dem Lesen sortieren oder die Ausgabedatei nach dem Generieren mit dem mit dem Betriebssystem gelieferten Dienstprogramm sortieren.
7.
1
Ich habe ein paar Jahre lang COBOL gemacht (als Referenz, ich bin erst 26), und ich kann eine Sache für Sie klären. Sie müssen nicht mehr für jede Schleife Absätze definieren, sondern können sie jetzt mit PERFORM UNTILto END-PERFORM-Blöcken inline setzen . Ich hasse es wirklich, dass ich das weiß.
AgentConundrum
1
@ NealB Ich habe gerade den Punkt für ihn geklärt, da er zugibt, dass seine Erfahrung selbst nach COBOL-Maßstäben veraltet ist. Ich verstehe, was COBOL85 angeht, aber es gibt eine Menge alten Code, der entweder gestartet wurde, bevor er existierte, oder von Leuten geschrieben wurde, deren Köpfe in einer früheren Version stecken geblieben waren. Man kann wirklich nicht davon ausgehen, dass eine Codebasis bis zu 85 Standards hat, aber selbst wenn es so ist, ist es immer noch eine unangenehme Sprache. Ältere Programmierer gehen schneller in den Ruhestand als sie ersetzt werden, und nur sehr wenige neue Programmierer möchten in COBOL arbeiten. Ich weiß, ich würde das Zeug nicht noch einmal anfassen wollen.
AgentConundrum
43

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.

James Anderson
quelle
2
In meiner Antwort sage ich, dass COBOL für Datenstrukturen schlecht ist. Ist das ein Unterschied in der Bedeutung von "Datenstruktur"? Vielleicht sind die Tools für das Layout von Datensätzen hervorragend, aber COBOL ist immer noch die falsche Sprache für Binärbäume usw.? Oder war meine Erfahrung mit COBOL einfach zu alt oder auf andere Weise begrenzt? Schlüsselfrage - Hat COBOL Zeiger? (Besorgniserregenderweise schlägt ein schnelles Google ja vor, obwohl mein altes Buch nein vorschlägt). Ich würde es hassen, eine Antwort zurückzuziehen, die mir all diese schönen
Wiederholungspunkte einbrachte
3
Die Dezimalarithmetik hat einen Nachteil: Sie müssen genau sagen, wie viele Stellen Sie möchten. Ich erinnere mich, dass ich Fehler gefunden habe, als wir in einem Programm einer Gruppe zu wenige 9s in der PICKlausel hatten.
David Thornley
2
Mein (nicht informierter) Eindruck ist, dass COBOL besonders gut mit Daten in starren Datensätzen mit fester Größe umgehen kann. Nicht so gut vielleicht bei dynamischen Datenstrukturen. Korrigiere mich, wenn ich falsch liege.
Barry Brown
@ Steve314 - yep pointers kamen ungefähr 1985, waren aber etwas lahm, da man sie nur in der Linkage-Sektion einstellen konnte. In späteren Versionen konnten Sie auf alles verweisen.
James Anderson
1
@Structures - entspricht zwar nicht den Python-Standards in Bezug auf Hashes und Bäume usw. Es ist so gut wie C oder Java - es ist jedoch nicht so gut wie C ++ plus Boost oder Java sowie die Collections Library. Wieder einmal hat das Versagen, den Wert von Standardbibliotheken und -funktionen zu schätzen, die Sprache während ihres langen Lebens lahmgelegt.
James Anderson
27

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

Danny Staple
quelle
20
Eines Tages werden sie ein Gewölbe entdecken, das mit Code gefüllt ist, den Dijkstra in den von ihm angeprangerten Sprachen geschrieben hat.
Jonsca
7
@jonsca - Sie werden überrascht sein, was Sie für Geld tun.
JeffO
3
Inkompatible Versionen waren bis mindestens in die 70er Jahre des letzten Jahrhunderts üblich, und sogar in den 80er Jahren gab es Basic. Dijkstra machte seinen Standpunkt wahrscheinlich anhand eines Problems deutlich, das ich in meiner Antwort erwähnte - COBOL ist nicht gut für die Codierung von Datenstrukturen (oder soll es auch sein). Daher ist COBOL für einen bestimmten Wert von "Programmierunterricht" oder "Informatikunterricht" wirklich Gift. Natürlich , da COBOL nicht dafür gedacht ist, ist es ein ziemlich unfairer Anspruch - aber dann wieder, IIRC, war der Zusammenhang , dass einige Leute wurden diese Dinge mit COBOL zu lehren versuchen.
Steve314
2
Dijkstra <- ein Mann, der zu viel geredet hat ...
Rook
3
@Danny: COBOL wurde verachtet, lange bevor Dijkstra diese Zeile 1975 schrieb.
John R. Strohm
9

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.

Sean
quelle
Ich hatte gehört, dass jemand im Vorbeigehen Bankgeschäfte erwähnte, was der einzige Grund war, warum ich das erwähnte.
Jonsca
4
Ich habe 20 Jahre im Bankwesen gearbeitet, fast alles in COBOL. Ich nehme an, verschiedene Banken haben die Dinge auf unterschiedliche Weise getan.
TrueDub
Ich kenne mindestens ein großes ERP-System, das viel COBOL enthält (oder bis etwa 2007 hatte).
Alan B
2
Es war nicht IBM, die COBOL entworfen hat. Die Hauptinitiatoren waren die US Navy und UNIVAC.
James Anderson
8
"Das Hauptziel von IBM bei der Entwicklung von COBOL bestand darin," einem Bankmanager das Schreiben eines Programms zu ermöglichen "." Ein nobles Ziel, obwohl die große Mehrheit der mir bekannten Manager mir nicht einmal einfache Literatur für eine Website schreiben kann, geschweige denn COBOL schreiben.
maple_shaft
8

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.

jonsca
quelle
1
Sprachen sind für Benutzer?
JeffO
16
"Codezeilen" sind keine gute sprachübergreifende Maßnahme. COBOL ist notorisch wortreich. Diese 5 Milliarden Codezeilen pro Jahr entsprechen wahrscheinlich siebzehn regulären Ausdrücken;)
MSalters
3
Manchmal ist COBOL das richtige Werkzeug für den Job - oft nicht. Das Schwierige ist, die Leute dazu zu bringen, den Unterschied zu erkennen.
TrueDub
1
Ganz richtig, @TrueDub. Mein Satz klang ein bisschen verkäuflich, sollte es aber nicht sein.
Jonsca
3
@TrueDub: Wenn COBOL das richtige Werkzeug für einen Job ist, möchte ich diesen Job nicht machen, solange ich Alternativen habe. Es gibt viel interessantere Jobs, für die ich gut bezahlt werden kann.
David Thornley
5

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?


quelle
4

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.]

S.Lott
quelle
Ich erinnere mich an keine davon - entweder an Verdrängung oder ich habe sie nie gelernt. Eine schnelle Suche zeigt mir, dass ich mit Sicherheit einverstanden bin, dass dies ALTERböse ist, aber diese Funktion wird selten, wenn überhaupt, verwendet, und ist daher kein Grund, COBOL zu hassen. Da bin ich mir allerdings nicht so sicher REDEFINES. Wenn unionich es mit vergleiche , denke ich ein bisschen freundlicher darüber nach - aber vielleicht ist es in der Datenverarbeitung keine so gute Idee, was in einer einfachen Sprache für Bit-Fiddling und Datenstruktur-Handling in Ordnung ist.
Steve314
Manchmal erscheinen mir deine Antworten als abweisend, aber diese ist einfach nutzlos. Ich weiß nicht, ob Sie versuchen, hier zu helfen, aber es schlecht machen, oder ob Sie nur mit sich selbst sprechen. Ich könnte Sie fragen, was Sie mit "rein böse" meinen, aber das Schöne an den oben genannten guten Antworten ist, dass ich kein Gespräch beginnen muss, um etwas zu lernen.
Eric Wilson
@EricWilson: Danke, dass du meine Antwort so gründlich abgelehnt hast. Das half mir zu verstehen, was noch hinzugefügt werden musste.
S.Lott
1
@Eric - das Problem ALTERist, dass es gotos umleitet. Erstens bedeutet das, dass Sie gotos verwenden - an sich denke ich nicht, dass das böse ist, aber in den meisten Sprachen ist es eine ungewöhnliche Spezialsache. Zweitens bedeutet das, dass die Gotos irgendwo anders hingehen, als wo sie sagen, dass sie hingehen werden - und das ist einfach furchterregend. Ich bin nicht wirklich davon überzeugt, dass dies selbstmodifizierender Code ist, aber er wird so beschrieben, wie ich ihn gesehen habe. Wenn ich ihn als modifizierende Sprungbefehlsziele in Assembler betrachte, wird erklärt, warum.
Steve314
@ S.Lott Danke für deine Ergänzungen (du auch @ Steve314), ich habe etwas Interessantes gelernt und meine Abstimmung rückgängig gemacht.
Eric Wilson
3

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.

Keine Chance
quelle
"mangelnde Unterstützung für Windows-ähnliche Benutzeroberfläche" .... was ist mit netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview
JoelFan
@JoelFan danke für deinen Kommentar. Sie haben Recht, dass es heute bessere Tools für COBOL gibt, aber ich denke, dass sie alle zu spät angekommen sind. Mein Punkt bezüglich mangelnder Unterstützung der Windows-Oberfläche war Anfang der 90er Jahre, als nur Micro Focus der einzige Player auf dem Markt war.
NoChance
2

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!).

TMN
quelle
1
"Hallo Welt" braucht wie viele Zeilen? Analysieren / Generieren von XML - ist jetzt in die Sprache integriert. Vielleicht sollten Sie Ihre Wissensbasis aktualisieren. Diese Antwort gehört zur Ära von COBOL in den 1960er Jahren.
NealB
Interessant. Ich musste seit fast einem Jahrzehnt nicht mehr mit COBOL zusammenarbeiten, aber als ich es das letzte Mal sah, wurde es so geschrieben, wie ich es in Erinnerung hatte: IDENTIFICATION DIVISION, WORKING-STORAGE SECTION und so weiter. Ich denke, all diese "erforderlichen Kommentare" (AUTHOR, DATE-WRITTEN, SOURCE-COMPUTER, OBJECT-COMPUTER) sind jetzt optional. XML-Parsing sieht nicht so beeindruckend aus - Sie müssen die Datenteilung so strukturieren, dass sie die Dateistruktur widerspiegelt. Es gibt keine Verarbeitung im SAX- oder DOM-Stil. Gut zu wissen, dass es dort ist.
TMN