COBOL er programmeringssprogenes asbest

 

COBOL er programmeringssprogenes asbest

Tidligt i Covid-19-pandemien kom guvernøren i New Jersey med en usædvanlig indrømmelse: Staten var løbet tør for COBOL-udviklere. Delstatens systemer til arbejdsløshedsunderstøttelse var skrevet i det 60 år gamle programmeringssprog og skulle opdateres for at kunne håndtere hundredtusindvis af ansøgninger. Problemet var bare, at få af statens ansatte vidste, hvordan man gjorde det.

Og krisen rakte langt ud over New Jersey, som blot var én af mange stater, der var afhængige af disse tunge systemer. Ifølge et groft skøn kostede ineffektiviteten i COBOL den amerikanske økonomi omkring 105 milliarder dollars i BNP i 2020.

Man kunne tro, at New Jersey derefter ville have udskiftet systemet – og at Covid var COBOLs sidste krampetrækning. Men sådan gik det ikke helt. Delstatens nye arbejdsløshedssystem fik ganske vist flere forbedringer for brugerne, men i baggrunden var det stadig afhængigt af en mainframe, der kører det gamle sprog.

COBOL – en forkortelse for Common Business-Oriented Language – er faktisk det mest udbredte programmeringssprog i historien. Af de omkring 300 milliarder linjer kode, der var skrevet frem til år 2000, var cirka 80 procent skrevet i COBOL. Det er stadig i omfattende brug og understøtter mange offentlige systemer, såsom kørekortsregistre og arbejdsløshedsforsikring. På en almindelig dag håndterer COBOL-systemer finansielle transaktioner til en værdi af omkring 3 billioner dollars.

Jeg tænker på COBOL som en slags digital asbest: engang næsten overalt, og nu utroligt – og farligt – svært at fjerne.

COBOL blev først foreslået i 1959 af en komité bestående af store dele af den amerikanske computerindustri, herunder Grace Hopper. Målet var at skabe “specifikationer for et fælles forretningssprog til automatiske digitale computere” for at løse et voksende problem: de høje omkostninger ved programmering. Dengang blev programmer skrevet specifikt til bestemte maskiner, og hvis man ville køre dem på en anden maskine, krævede det næsten en fuldstændig omskrivning. Komitéen henvendte sig til det amerikanske forsvarsministerium, som begejstret støttede projektet.

COBOLs design adskilte sig både dengang og nu fra andre programmeringssprog. Det var tænkt som et sprog skrevet i almindeligt engelsk, så selv personer uden programmeringserfaring kunne bruge det. Symbolsk matematisk notation blev først tilføjet efter længere diskussion. De fleste versioner af COBOL tillader brug af hundreder af ord – som “is”, “then” og “to” – for at gøre koden mere læsbar. Til sammenligning tillader Java kun 68 reserverede ord.

Nogle mente endda, at COBOL var tænkt som en erstatning for programmører, som i 1960’erne havde en næsten elitær status i mange virksomheder. De var mestre i en teknologi, som de fleste mennesker knap nok forstod. COBOLs designere håbede også, at sproget kunne generere sin egen dokumentation, så udviklere kunne spare tid og gøre programmer lettere at vedligeholde på længere sigt.

Men hvad vil det egentlig sige, at kode er “læsbar”? Programmer er ikke bøger eller artikler; de er betingede sæt af instruktioner. COBOL kunne godt gøre en enkelt linje kode forståelig, men når programmer voksede til tusindvis af linjer, brød den fordel sammen. Det er lidt som en IKEA-samlevejledning: Hvert trin er enkelt, men på en eller anden måde ender det hele stadig med ikke at passe sammen.

Derudover blev COBOL implementeret med en logik, som mange udviklere kom til at afsky: GO TO-instruktionen, en ubetinget forgrening, der sender programmet springende fra ét sted til et andet. Resultatet blev det, udviklere kalder “spaghettikode” – kode så sammenfiltret, at ideen om selvforklarende programmer nærmest blev irrelevant.

Mange dataloger havde problemer med COBOL allerede fra starten. Edsger Dijkstra hadede det berømt og sagde:

“Brugen af COBOL lammer sindet; derfor bør undervisning i det betragtes som en kriminel handling.”

Dijkstra hadede også GO TO-instruktionen, fordi den gjorde programmer næsten umulige at forstå. Der var også en vis snobberi i kritikken: COBOL blev ofte set ned på som et rent praktisk sprog, der blot løste kedelige problemer.

Jean Sammet, en af de oprindelige designere, så det anderledes. Sproget havde blot den svære opgave at repræsentere komplicerede ting, såsom socialforsikringssystemer. Som en anden forsvarer skrev:
“Desværre findes der alt for mange forretningsprogrammer skrevet af programmører, der aldrig har fået ordentlig undervisning i struktureret COBOL.”

God COBOL kunne faktisk være selvforklarende – men meget afhængte af den enkelte programmør. Matematikeren Fred Gruenberger fra Rand Corporation formulerede det sådan:

“COBOL i hænderne på en mester er et smukt og meget kraftfuldt værktøj.
COBOL i hænderne på en lavtuddannet kontorist et sted vil være et frygteligt rod.”

Alt dette forhindrede naturligvis ikke COBOL i at blive udbredt. At det amerikanske forsvarsministerium krævede COBOL-kompilatorer i de fleste maskiner, det bestilte, hjalp bestemt også. Ingen computerproducent midt under den kolde krig ønskede at gå glip af føderale kontrakter.

I sidste ende lykkedes COBOL med to af sine vigtigste mål: Det var maskinuafhængigt og kunne spredes hurtigt. Og fordi sproget brugte fastpunktsaritmetik i stedet for flydende tal, blev det særligt velegnet til finansielle applikationer – hvilket er grunden til, at det stadig er overalt i finanssektoren.

Men som New Jersey oplevede i 2020, er det svært at opdatere COBOL til den moderne verden. Sammet indrømmede senere en væsentlig designfejl: Manglen på parametrisering. Programmer blev ganske vist opdelt i moduler, men de kunne ikke sende data til hinanden. I stedet måtte de dele alt, hvilket betød, at ændringer ét sted kunne påvirke hele programmet – eller få millioner af dollars til at forsvinde på et øjeblik. Eller stoppe folks sociale ydelser.

I dag forsøger virksomheder som IBM at sælge værktøjer til at konvertere COBOL-kode ved hjælp af generativ AI. På et tidspunkt lovede Elon Musks DOGE-projekt at omskrive Social Security-administrationens kodebase på få måneder ved hjælp af et sådant værktøj – men projektet ser ud til at være gået i stå.

Problemet er, at en simpel konvertering fra COBOL til for eksempel Java ofte skaber noget, man kunne kalde “JOBOL” – en forvirrende blanding, der efterligner COBOLs struktur uden at bevare sprogets læsbarhed.

Jeg er ikke overbevist af mange af disse AI-værktøjer. Ligesom COBOL lover de en strømlinet effektivitet, hvor alle kan være med. Men vi har jo set, hvordan det gik sidst.