Aufzeichnungen des Großvaters darüber, dass COBOL schon lange „tot“ sei
(wumpus-cave.net)- Ein im Juni 1992 in der Zeitschrift Technical Support erschienener Text erklärte bereits den Tod von COBOL, doch der Kernpunkt ist, dass die Sprache auch 30 Jahre später nicht vollständig verschwunden ist
- Modebegriffe aus jener Zeit wie 4GL hatten meist keine lange Lebensdauer, doch COBOL hielt sich länger als viele spätere Alternativen
- Der entscheidende Anlass, der COBOL weiter am Leben hielt, war das Y2K-Problem; die tatsächliche Reaktion darauf erforderte die Ausbildung einer neuen Generation von COBOL-Programmierern
- Eine Sprache mit einst großer installierter Basis kann eher einen langen Nachlauf behalten, in dem sie weiterbesteht, statt plötzlich zu verschwinden, weil weniger neue Lernende hinzukommen
- Der Großvater des Autors starb am 1. September 2024 im Alter von 91 Jahren; der Text überlagert persönliche Rückschau mit alten Technologieprognosen
Die Erklärung vom „toten COBOL“ erschien schon 1992
- Der Großvater des Autors veröffentlichte im Juni 1992 in der Zeitschrift Technical Support einen Text, der den Tod von COBOL verkündete
- In dem damaligen Text tauchen zeittypische Begriffe wie 4GL auf, und der Autor ergänzt, dass COBOL länger überlebt habe als ein beträchtlicher Teil der Beispielsliste für 4GLs auf Wikipedia
- Der Originaltext ist im NaSPA-Archiv erhalten: http://www.naspa.net/magazine/1992/t9206003.txt
- Der Text von 1992 unterscheidet verschiedene Bedeutungen des Wortes „dead“ und behandelt COBOL als eine Art Zombie: tot, aber nicht verschwunden
- Autocoder wird ebenfalls als Vorläufer von COBOL vorgestellt und als Vergleichsfall genannt: eine Sprache, die als tot gilt, von der aber noch Spuren geblieben sein könnten
Y2K bescherte COBOL ein langes Leben
- Ein großer Faktor, der den COBOL-Zombie weiter in Bewegung hielt, war das Y2K-Problem
- Damals war es ein großes Thema in den Nachrichten, und später sah es so aus, als wäre nichts passiert, tatsächlich war es jedoch ein gewaltiges Problem
- Im Zuge der Reaktion darauf musste eine neue Generation von COBOL-Programmierern ausgebildet werden
- Dieser Prozess könnte dazu beigetragen haben, COBOL länger am Leben zu halten
- Der Autor verwendet heute für Programmiersprachen kaum noch den Ausdruck dead
- Sprachen mit einst großer installierter Basis sterben nur schwer vollständig aus
- Stattdessen hinterlassen sie einen langen Nachlauf, in dem sie allmählich verblassen, weil neue Programmierer sie nicht mehr lernen
Eine Szene aus der Technikgeschichte, die in persönliche Rückschau übergeht
- Der Großvater des Autors starb am 1. September 2024 im Alter von 91 Jahren
- Offizielle Todesursache war eine Lungenentzündung
- Die Großmutter war im April desselben Jahres gestorben, und der Großvater hatte darum gebeten, keine Behandlung mehr zu erhalten
1 Kommentare
Meinungen auf Hacker News
Der Beitrag erwähnt 4GL – ein Begriff, den ich wirklich seit Ewigkeiten nicht mehr gehört habe.
Auch COBOL versprach, „wie von Menschen lesbare Sätze auszusehen, sodass man keine Programmierer mehr brauchen würde“; das ähnelt heutigen Low-Code-Plattformen oder von LLMs generiertem Code.
Das Problem ist, dass normale Menschen ein Problem meist nicht detailliert genug beschreiben und zerlegen können, damit eine funktionierende Lösung herauskommt. Wenn man diesen Prozess beherrscht, ist man am Ende eben doch Programmierer; und die zentrale Lehre aus COBOL ist, dass Programmierer nicht nur wegen der Computer-Interfaces oder der Sprachen gebraucht werden.
Es ging eher darum, dass jemand, der Geschäftsprozesse gut kennt, sie in COBOL übertragen kann, ohne viel darüber lernen zu müssen, wie Computer funktionieren – ähnlich wie Analysten oder Datenverantwortliche, die per SQL mit Datenbanken sprechen.
COBOL und 4GL dienten vor allem dem Aufbau von Geschäftsanwendungen wie Lohnabrechnung, Banking, Personalwesen und Lagerverwaltung, mit besonderem Fokus auf Batch-Verarbeitung, um wiederkehrende Massenvorgänge wie Abrechnungen zu reduzieren.
Weil sie aus einer Zeit ohne dedizierte DBMS stammen, sind Dateiorganisation und dateibezogene Verben sehr stark ausgeprägt; darin gibt es auch Parallelen zu heutigem SQL.
Selbst wenn ein LLM wie durch Magie eine Lösung erzeugt, wandert die Verantwortung dafür, das Problem knapp und präzise auszudrücken, nur eine Ebene nach oben.
Am Ende „programmiert“ man mit Prompts und prüft den formalisierten Output, den das LLM vorschlägt: Code. Die Art des Programmierens mag sich zu Prompt Engineering verschieben, aber die Notwendigkeit, Code als formale Sprache zu verstehen, bleibt bestehen.
Der Artikel sagt, 4GL sei Anfang der 1990er ein großer Hype gewesen, aber ich bezweifle, dass das auch außerhalb von Mainframes galt. Die 4GL-Bewegung war von Anfang an stark mainframe-orientiert, und Wikipedia nennt als frühes Ziel auch, die Zahl der für ein Programm nötigen Lochkarten zu reduzieren.
1992 gab es bereits Linux, an Python wurde gearbeitet, Perl wurde populär, und auch Haskell hatte schon frühe Versionen. Die technologische Front verlagerte sich von teuren Workstations zu Consumer-PCs, und Sprachdesigner hatten das 4GL-Konzept meiner Ansicht nach kaum bewusst im Blick, selbst wenn sie Dinge wie dBase, HyperTalk oder AppleScript bauten, die man im Ergebnis als 4GL betrachten kann.
Ich stimme zu, dass natürlichsprachlicher Text für die meisten Programmierzwecke eine schlechte Idee ist, glaube aber nicht, dass die 4GL-Bewegung nur deshalb gescheitert ist. Die meisten 4GL waren nicht einmal natürlichersprachlicher als COBOL, das eine 3GL ist.
Das größere Problem war, dass die 4GL-Bewegung nicht sauber definieren konnte, was die neue Generation eigentlich sein sollte und was daran nützlich wäre. 2GL brachte die Übersetzung von Assembly in Maschinencode, 3GL die revolutionäre Veränderung der Kompilierung; bei 4GL war die am ehesten definierbare Veränderung nur: „Lasst uns mehr Funktionen, die bisher in externen Routinen oder Bibliotheken steckten, direkt in die Sprache aufnehmen.“
Dieser Ansatz funktionierte gut bei domänenspezifischen Sprachen, weshalb erfolgreiche 4GL wie SQL, R und MATLAB entstanden. Die Idee einer universellen 4GL war dagegen meiner Ansicht nach dazu bestimmt, in einer übermäßig aufgeblähten Sprache zu enden.
Heute gibt es kaum noch Menschen, die so etwas können oder tun müssten.
In diesem Kontext denke ich an Scala. Wenn man sich ansieht, wie COBOL im Artikel beschrieben wird, halte ich auch Scala praktisch für ziemlich tot
Es gibt weiterhin viele Unternehmen und Services mit Kernkomponenten, die in Scala geschrieben sind, aber das Interesse bei neuen Projekten ist stark abgeflaut
2012–2014 hatte ich das Gefühl, auf HN ständig Artikel wie „X mit Scala machen“ zu sehen, heute sieht man das kaum noch. Das mag ein natürlicher und unvermeidlicher Prozess sein, aber es ist schade, weil Scala gute Eigenschaften hatte, die andere Mainstream-Sprachen bis heute nicht abdecken
Darunter sind auch Projekte, die für das Ökosystem des Unternehmens ziemlich wichtig sind, etwa Testsysteme, und die Engineers, die solche Systeme früher gebaut haben, sind heute größtenteils im höheren Management
Manche stehen weiterhin hinter der damaligen Technologiewahl, aber andere zeigen sich offener, wenn man ihnen die Gelegenheit zur Rückschau gibt. Insgesamt herrscht eher die Stimmung, dass man Scala nicht gewählt hätte, wenn es damals Kotlin gegeben hätte oder Swift für Backend-Services brauchbar gewesen wäre
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
Der anfängliche Hype ist abgeklungen, aber das ist in Ordnung. Jede Sprache hat Hype-Zyklen, und Prognosen liegen meist daneben. Mainstream-Programmiersprachen lassen sich heute nur schwer wie COBOL für tot erklären
Von Java hieß es seit 2001, es werde sterben, aber es hat die Dotcom-Blase, .NET, das P in LAMP, Ruby, JS und Go überstanden. Auch bei Python hieß es während der Umstellung auf Version 3, es werde sterben, weil Leute zu Ruby wechselten
Scala ist die weltweit beliebteste funktionale Programmiersprache, hat gute Tools und Libraries, und Scala 3 halte ich für ein hervorragendes Upgrade
Früher war es riesig und fühlte sich allgegenwärtig an, heute wird es zunehmend in Nischen gedrängt. Wie bei COBOL gibt es in der Praxis aber immer noch viel Perl-Code
Auch Jack Henry, SiriusXM, Starbucks, Disneys Streaming-Service und Capitol One haben in den letzten fünf Jahren bis heute neue Scala-Projekte im Service-Bereich, nicht in Data Science, gestartet
Natürlich gibt es noch mehr Teams, aber allein die bekannten Namen, die mir sofort einfallen, reichen aus, um es schwer als tot zu bezeichnen
Allerdings scheinen Framework-Jobs rund um Play und Akka sowie reine Spark-Arbeiten außerhalb von Airflow zurückzugehen. Das waren meiner Ansicht nach oft nur Framework-Jobs aus dem Scala-Ökosystem, bei denen Scala selbst eher nebensächlich war
Ich mag Scala, aber es war immer eine Randsprache, während COBOL wirklich überall war
Irgendwann sollte ich mich einmal hinsetzen und Legacy-Sprachen wie Fortran, COBOL, Ada und APL direkt ausprobieren
Ihre Popularität ist eindeutig gesunken, aber sie werden weiterhin an wichtigen Stellen eingesetzt
Gleichzeitig denke ich an die enorme Menge Java-Code. Java hat den Enterprise-Bereich, ob gut oder schlecht, fast verschlungen, und ich frage mich, ob es in 30–40 Jahren einen Grund geben wird, dass nur noch Rentner Java verwenden, um alte Banksysteme zu warten
Vermutlich auch daran, dass es riesige monolithische Codebasen oder Plattformen sind. Die Sprache ist nicht obskur oder schwierig, es gibt nur zu viel Code, dessen Struktur schwer zu erkennen ist
Ich glaube, es wird in den nächsten 100 Jahren etwa 0,05 % des Marktes halten
In den letzten Jahren wurde neuer Code allerdings größtenteils in Kotlin geschrieben
Ich habe auch persönlich eine Schwäche dafür; in den 90ern haben wir es in der Firma tatsächlich auf PCs eingesetzt. Es ging darum herauszufinden, wie man Daten hineinbekommt, und am Ende schrieb ich eine Routine, die Gleitkommazahlen wie Vektoren aus Einsen und Nullen behandelte und Bits änderte, um sie vom Microsoft-Format ins IEEE-Format zu konvertieren
Natürlich war das noch zu der Zeit, als ich eine Zwiebel am Gürtel trug
Für reine numerische Simulationen würde ich Fortran vermutlich C++ oder Python vorziehen. NumPy ausgenommen, wobei NumPy selbst am Ende ebenfalls auf Fortran und C++ beruht
Für die Carolina Code Conference 2025 werden weiterhin COBOL-Speaker gesucht
Besonders da GnuCOBOL kürzlich aktualisiert wurde, wollte ich schon seit einer Weile einen COBOL-Talk ins Programm aufnehmen
https://gnucobol.sourceforge.io/
https://carolina.codes
„Ich weiß nicht, wie die Sprache des Jahres 2000 aussehen wird, aber sie wird Fortran heißen.“ —Tony Hoare
COBOL kann man als lebendig ansehen, weil es sich über die Epochen hinweg immer weiter verändert hat. Modernes COBOL unterscheidet sich ziemlich von dem COBOL der 1950er, an das Menschen instinktiv denken, wenn sie den Namen hören
Das ist ungefähr so, als würde Java Algol-94 heißen und wir deshalb sagen, wir programmierten immer noch in Algol
MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.<https://dtss.dartmouth.edu/sciencearticle/index.html>
COBOL ist nicht tot, aber schwer zugänglich. Denn es gibt kaum Open-Source-Tools, die unter Linux nutzbar sind.
OCamlPro hat ein Projekt namens SuperBOL gestartet, um rund um den Open-Source-Compiler GnuCOBOL eine Open-Source-Umgebung aufzubauen. GnuCOBOL ist bereits ausgereift und wird auch in Unternehmen eingesetzt.
Es wurde bereits eine VSCode-Erweiterung mit LSP für COBOL veröffentlicht, die eine moderne IDE-Erfahrung bietet; je nach Kundenanforderungen wird auch an weiteren Tools gearbeitet.
COBOL kann man in ein, zwei Tagen lernen, und ich würde gern „langweilige“ COBOL-Arbeit machen, habe aber keine Mainframe-Erfahrung.
https://gnucobol.sourceforge.io/
https://cobolworx.com/pages/cobforgcc.html
Wie immer hängt eine solche Diskussion davon ab, wie man „tot“ und „lebendig“ definiert.
Wenn man eine Technologie als tot bezeichnen kann, sobald auf ihr keine neuen Geschäfte mehr aufgebaut werden, dann kann man COBOL durchaus als tot ansehen. Dasselbe gilt für IBM 390x, das oft gewissermaßen stellvertretend für COBOL steht, also die Z/OS-Plattform.
Wenn man dagegen sagt, dass etwas lebendig ist, solange es noch in Produktionsumgebungen genutzt wird, dann ist COBOL selbstverständlich lebendig – und sogar deutlich lebendiger als viele Technologien, die jünger sind als es selbst.
Das muss man allerdings nicht als Stärke von COBOL oder des Mainframe-Ökosystems verstehen. Organisationen neigen dazu, an dem festzuhalten, was anfangs gut funktioniert hat; bei Regierungen, Banken, Fluggesellschaften und ähnlichen frühen Trägern der Digitalisierung war diese erste Wahl eben meist ein IBM-Mainframe und die darauf laufende Software.
Unser Mainframe verarbeitet problemlos 100 Millionen Transaktionen pro Stunde. Zudem sind die meisten davon synchron, und jede Transaktion führt zu mehreren SQL-Transaktionen.
Eventual Consistency ist zwar ein Ansatz, passt aber sehr schlecht zum Finanzbereich und vermutlich auch zu Militär, Versicherungen, Medizin und Gesundheitswesen. Man kann Arbeit auch partitionieren, aber sobald Shard-Grenzen überschritten werden, entstehen Konsistenzprobleme.
COBOL ist noch nicht tot, bewegt sich aber langsam in diese Richtung. Ich kenne keine Bank, die nicht aktiv daran arbeitet, vom Mainframe wegzukommen. Trotzdem sagen die Prognosen, die ich gesehen habe, dass Mainframes und COBOL mindestens bis 2050 bleiben werden.
Das heißt, dass noch 26 Jahre lang COBOL-Code geschrieben wird. COBOL-Programmierer sind stark gefragt und werden in der Regel gut bezahlt; wer heute eine Karriere als COBOL-Programmierer beginnt, kann damit nahezu ein ganzes Arbeitsleben füllen.
Die Einstiegshürden waren schon immer extrem hoch, und die wichtigsten Kunden waren damals alte Versicherungen, Banken, Behörden und ähnliche Organisationen. Dass neue Unternehmen Computing betreiben konnten, wurde eher erst nach den Minicomputern möglich.
In diesem Sinne hat sich nicht viel geändert, und wenn man den Zielmarkt des Produkts betrachtet, halte ich „Wird es von neuen Unternehmen genutzt?“ nicht für ein geeignetes Kriterium, um über Leben oder Tod einer Plattform zu urteilen.
Neue Geschäftsbereiche oder interne Startup-Teams – etwa für eine neue Kategorie von Versicherungsprodukten – könnten Teile in COBOL schreiben, wenn sie in die übrigen Systeme der Bank integriert werden müssen.
Zumindest könnten sie, selbst wenn sie nicht direkt in COBOL schreiben, auf der bestehenden COBOL-Ausführungsinfrastruktur, also auf Z/OS, landen, weil kein Budget für ein neues x86-Rack und die Leute zu dessen Betrieb vorhanden ist.
Die Cloud ist der neue Mainframe, nur in einer schlechteren Version. Sie hat alle Nachteile, aber nicht den größten Vorteil.
Früher konnte man mit CICS sehr stabile und performante Services bauen und innerhalb derselben Transaktion andere Services aufrufen. Die Plattform übernahm komplexe Aufgaben wie die Wahrung der Datenintegrität.
Wenn man einmal AWS Lambda schreibt, das sich innerhalb derselben Transaktion gegenseitig aufruft, wird der Unterschied deutlich.
Und ich verstehe nicht, warum der Vergleichsmaßstab „AWS Lambda, das sich innerhalb derselben Transaktion gegenseitig aufruft“ sein soll. War ein Mainframe-Deployment für Entwickler so einfach wie eine
.zip-Datei mit Code an eine API zu werfen, für die man Zugriffsrechte bekommen hat?Manche verstehen das so, als würde ich COBOL gegenüber modernen Sprachen wählen oder bevorzugen, und kritisieren mich dafür; so ist es aber nicht gemeint. Ich habe nur eine Advocatus-Diaboli-Beobachtung von außerhalb des üblichen Rahmens gemacht.
Ironischerweise gab es mit COBOL bereits eine speichersichere und stabile Sprache, die leichter zu lesen und zu verstehen ist als Rust. Aber niemand will sie benutzen, also wurde sie zu einer „toten“ Sprache, während die Systeme, die die Moderne überhaupt ermöglichen, darauf laufen.
Vergleicht man zum Beispiel Rust- und COBOL-Code, der eine Zahl einliest und ausgibt, ob sie gerade oder ungerade ist, liest sich die COBOL-Seite direkter.
Ich weiß nicht, ob es dieselbe Performance liefert, ob es sich auf dieselbe Weise mit nativem Code anderer Sprachen integrieren lässt, ob es auf einem Modulsystem, das Komposition und Abwärtskompatibilität unterstützt, einen brauchbaren Paketmanager gibt, oder ob es Daten- und Fehlerformen so bequem ausdrücken kann wie Rusts algebraische Datentypen.
So wie es Gründe gibt, warum COBOL weiterhin genutzt wird, gibt es auch gute Gründe dafür, dass neue Sprachen entwickelt wurden.
Baut man ein tatsächlich lauffähiges COBOL-Programm mit dem nötigen Boilerplate, gibt es bei der Eingabe
abc„even“ und bei12„odd“ aus.Auch dass ausgerechnet die Rust-Syntax problematisiert wird, ist ungewöhnlich. Wie die meisten heutigen Sprachen hat Rust im Großen und Ganzen eine C-artige Syntax, mit ein paar OCaml-Elementen. Abseits der Syntax verfolgen Rust und COBOL sehr unterschiedliche Ziele, daher verschwindet Rusts Existenzberechtigung nicht mit „nehmen wir einfach COBOL“.
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
Dort taucht Code wie
ALLOCATE, das Setzen von Pointer-Adressen undFREEauf.Dieser Tweet hat auf merkwürdige Weise etwas.
https://x.com/grauhut/status/1000017084435312642
Übersetzt lautet er sinngemäß: „Beim Kunden COBOL gefunden. Alles gut. Ist ein Mainframe. Nichts Besonderes. Der letzte Kommentar war von 1985. Die Autorin war meine Mutter.“