Programmering i absolut binär
De första programmerarna skrev i absolut binär: varje instruktion & varje adress i rå binära siffror. En enda instruktion kunde se ut som 01100101 00001010 — instruktionskod & minnesadress i binär.
Spagettikod-problemet
När ett fel krävde att en ny instruktion infogades, ställdes programmerare inför ett dilemma. Att infoga på plats betydde att varje efterföljande instruktionsadress skiftade med ett — vilket krävde att programmeraren uppdaterade varje adressreferens i hela programmet. Katastrofalt.
Lösningen: ersätt instruktionen strax före insättningspunkten med ett hopp till tomt minne. På denna tomma plats: skriv den överskrivna instruktionen, lägg till de nya instruktionerna, hoppa sedan tillbaka. När fel dök upp i korrigeringarna tillämpade man samma trick igen med annat tomt minne.
Resultatet: körvägen genom programmet hoppade till till synes slumpmässiga platser. Hamming kallade detta 'en burk spagetti'. Kontrollflödesvägen, ritad på papper, såg ut exakt som trasslig spagetti.
Flygtvägar
Två omedelbara förbättringar: oktala notation (gruppera binära siffror i uppsättningar om 3) och hexadecimal (grupper om 4, med A–F för värden över 9). Dessa reducerade skrivfel men löste inte det grundläggande adressproblemet.
Symbolisk assembly (t.ex. IBMs SAP — Symbolic Assembly Program — och SOAP — Symbolic Optimizing Assembly Program på IBM 650) tillät programmerare att skriva instruktionsnamn (ADD, MOVE) och symboliska adressetiketter istället för binär. Assemblern översatte till binär vid indatningstillfället och hanterade automatiskt adresstilldelningar.
SOAP utförde ytterligare en optimering: det ordnade instruktioner på den roterande trumman så att nästa instruktion anlände till läshuvudet precis när den föregående slutfördes — kodning med minimal latens. SOAP kompilerade till och med sig själv: program A bearbetad som data för att producera B, B kördes på A för att mäta hur mycket själv-kompilering förbättrade det.
Bibliotek & flybar kod
Hamming noterade att idén om återanvändbar programvara (matematiska bibliotek) kom mycket tidigt — Babbage hade redan tänkt på det. Problemet: ett bibliotek med absoluta adresser krävde att varje rutin ockuperade samma minnesplatser varje gång det användes. När det totala biblioteket växte för stort konkurerade program om samma adresser.
Lösningen: flybar kod. Assemblern genererar instruktioner som refererar till minnet relativt — förskjutningar från en basadress — snarare än absoluta adresser. En länkare löser de slutliga adresserna vid laddningstillfället.
Von Neumanns opublicerade rapporter (vitt spridda) beskrev nödvändiga programmeringstekniker. Den första publicerade programmeringsboken (Wilkes, Wheeler & Gill, EDSAC, 1951) kodifierade dessa tekniker.
Språkdesignens förgrening
FORTRAN (1957, IBM) och ALGOL (1958, internationell kommitté) representerar två designfilosofier som producerade radikalt olika resultat.
FORTRAN
John Backus ledde FORTRAN (FORmula TRANslation) projektet på IBM. Designmålet: göra språket lätt för vetenskapsmän & ingenjörer att använda. FORTRAN accepterade matematisk notation som kändes naturlig för dess användare: A = B + C * D snarare än ADD B, C; STORE T; MULTIPLY T, D; STORE A.
FORTRAN överlevde 60+ år. Det förblir i aktiv användning inom vetenskaplig databehandling, fluidynamik, klimatmodellering & beräkningsbaserad fysik. Hamming noterade denna hållbarhet som bevis på framgångsrik design.
ALGOL
ALGOL (ALGOrithmic Language) designades av en kommitté av logiker & dataloger som strävade efter matematisk rigor: ett logiskt rent, formellt definierbara språk. Backus-Naur Form (BNF) notation för att beskriva grammatik uppfanns för att specificera ALGOL.
ALGOL misslyckades i praktiken. Trots dess logiska elegans & sitt enorma inflytande på efterföljande språkdesign (Pascal, C, & nästan alla moderna språk nedstammar från ALGOLs grammatikbegreppet), aldrig ALGOL självt inte var allmänt distribuerad. Hammings dom: logiskt designat, mänskligt oanvändbart.
Språkhierarkin
Hamming beskrev lagering av kompilator/tolk: ett program kan läsa ett språk på högre nivå & översätta det till ett på lägre nivå. Stapla dessa lager — varje översätter en nivå nedåt. Högst upp: ett domänspecifikt språk som experter inom ett område (biologi, finansiering, fysik) skriver naturligt. Längst ned: maskinens kod. Varje övergång är en kompilator eller tolk.
Hammings fyra språkdesignkriterier
Hamming destillerade lärdomen från FORTRAN vs ALGOL till fyra kriterier för ett framgångsrikt programmeringsspråk:
1. Lätt att lära — en nybörjare kan bli produktiv snabbt
2. Lätt att använda — rutinuppgifter kräver minimal ceremoni
3. Lätt att felsöka — fel producerar meningsfulla, lättlokaliserbara meddelanden
4. Lätt att använda subroutiner — återanvändning & abstraktion kräver inte enorm ansträngning
Han gjorde en strukturell observation: människans språk innehåller cirka 60% redundans; skrivet språk cirka 40%. Låga redundansspråk (som APL) producerar eleganta enradare som experter finner vackra & nybörjare finner ogenomskinliga — & som innehåller omöjliga att detektera fel när en enda karaktär ändrar betydelse.
Implikationen: ett språk designat för logisk elegans optimerar för fel läsare. Programmeraren är mänsklig; människor behöver redundans för att fånga fel & kommunicera avsikt.
Psykologisk vs logisk språkdesign
Hamming återvände till FORTRAN/ALGOL kontrasten som en läxa i institutionell & mänsklig dynamik, inte bara språkdesign.
FORTRAN designades psykologiskt — för människorna som skulle använda det, specifikt vetenskapsmän som tänkte i matematisk notation. ALGOL designades logiskt — för formell korrekthet & teoretisk elegans.
Paradoxen Hamming identifierade: ett logiskt korrekt språk som människor motstår misslyckas; ett pragmatiskt designat språk som människor antar lyckas, även om det är logiskt rörigare.
Han citerade APL som extremfallet: logiskt elegant, uttrycksbart på en rad, med sin egen speciella teckensats. Experter älskade det. Normala programmerare tyckte det var oläsligt. En enda teckenändring kunde tyst omvandla ett programs betydelse. APL har ett litet dedikerat samhälle & nästan noll mainstream-användning.
Argumentet om mänsklig redundans: talat språk är ~60% redundant (upprepad kontext, förtydligande ord, förutsägbar struktur). Skrivet språk ~40% redundant. Denna redundans tjänar feldetektering — människor är opålitliga, så språk utvecklades för att bära tillräcklig upprepad information för att fånga & korrigera fel. Ett lågt-redundansspråk tar bort detta skyddsnät.
Kompilatorhierarkin
Hamming beskrev lagering av kompilator/tolk: ett program kan läsa ett språk på högre nivå & översätta det till ett på lägre nivå. Stapla dessa lager — varje översätter en nivå nedåt. Högst upp: ett domänspecifikt språk som experter inom ett område (biologi, finansiering, fysik) skriver naturligt. Längst ned: maskinens kod. Varje övergång är en kompilator eller tolk.
Förutsägelse av språköverlevnad
År 1993 hade Hamming sett många språk lyckas & misslyckas. FORTRAN (1957) överlevde. ALGOL (1958) misslyckades. COBOL (1959) överlevde decennier inom företagsdata. LISP (1958) överlevde i AI-forskning. PL/I (1964) försökte förena allt & misslyckades.
Det återkommande mönstret
Hammings programvaruhistorikapiters innehåller en återkommande struktur:
1. En smärtsam begränsning existerar (absoluta adresser, binär notation, omöjlig att underhålla kod)
2. Någon uppfinner ett abstraktionslager som döljer begränsningen
3. Abstraktionen möjliggör ny skala, vilket skapar nya smärtsamma begränsningar
4. Upprepa
Binär → oktal/hexadecimal → symbolisk assembly → FORTRAN → strukturerad programmering → objektorienterade språk → domänspecifika språk. Varje lager löser föregångarens mest akuta smärta samtidigt som det introducerar en ny klass problem.
Spagettikodproblemet (absoluta adresser) ledde till symbolisk assembly. Stora assemblyprograms ledde till FORTRAN. Stora FORTRAN-program ledde till strukturerad programmering & sedan objekt-orientering. Hammings föreläsning slutade innan dessa senare övergångar, men mönstret fortsätter.
Hans läxa för ingenjörer: du löser alltid smärtan exponerad av den tidigare abstraktionen. Förståelse av lagret du för närvarande är på kräver att veta varför lagret under det existerar.