06 aug. 2025·8 min
John Backus & FORTRAN: språket som gjorde att mjukvara kunde skala
John Backus ledde FORTRAN på IBM och visade att högnivåkod kan köras snabbt—det ökade produktiviteten och hjälpte mjukvaran växa till en riktig industri.
John Backus ledde FORTRAN på IBM och visade att högnivåkod kan köras snabbt—det ökade produktiviteten och hjälpte mjukvaran växa till en riktig industri.
I början av 1950-talet var datorer sällsynta, dyra maskiner som användes av regeringar, universitet och stora företag. De var kraftfulla för sin tid—men att programmera dem gick smärtsamt långsamt. Många program skrevs direkt i maskinkod eller assembler, där varje instruktion måste matcha hårdvarans lilla uppsättning operationer. En liten ändring i en formel kunde innebära att man skrev om långa kodstycken, och ett enda misstag kunde krascha ett helt körning efter timmar av väntan.
John Backus var ingenjör på IBM som redan hade sett hur mycket tid som gick åt till låg-nivåprogrammering. Han ledde ett litet team som försökte något radikalt: låt programmerare skriva matematik-tunga instruktioner i en form närmare hur de tänkte om problemen, och låt en kompilator översätta det till snabb maskinkod.
Projektet blev FORTRAN (kort för "Formula Translation"), riktat mot IBMs vetenskapliga kunder—människor som gjorde numeriskt arbete, inte administrativt pappersarbete. Löftet var enkelt: skriv mindre kod, få färre buggar och kör ändå effektivt på maskiner som IBM 704.
På den tiden trodde många programmerare att högnivåspråk var en lyx. De antog att allt som kändes "engelskliknande" skulle köra avsevärt långsammare än noggrant handtrimmad assembler—för långsamt för att motivera bekvämligheten. Med datorer som kostade förmögenheter och beräkningstid hårt ransonerad var prestanda inte ett "trevligt att ha"; det var hela poängen.
Så FORTRAN var inte bara en ny syntax. Det var en satsning på att automatisering kunde matcha expertkunskap: att en kompilator kunde producera kod bra nog för att vinna förtroende från forskare och ingenjörer som brydde sig om varje cykel.
Berättelsen om FORTRAN är delvis tekniskt genombrott, delvis kulturförändring. Nästa steg ser vi på hur programmering kändes innan högnivåspråk, hur Backus team byggde en kompilator som kunde konkurrera med handskriven kod, och varför den framgången förändrade ekonomin i mjukvaruutveckling—mönster som moderna team fortfarande förlitar sig på idag.
Före FORTRAN betydde "programmera" oftast att skriva instruktioner i datorns eget vokabulär—eller något bara marginellt vänligare.
Tidiga datorer exekverade maskinkod: numeriska opkoder och minnesadresser. Eftersom det var nästintill omöjligt att hantera i större omfattning använde programmerare assembler, som ersatte många siffror med korta mnemoniker. Men assembler var fortfarande ett tunt lager ovanpå hårdvaran. Du beskrev inte vad du ville ha i matematiska termer—du stavade ut hur det skulle göras steg för steg, register för register.
För en vetenskaplig beräkning kunde det innebära manuell hantering av loopar, minneslayout och mellanliggande värden. Även en liten ändring i en formel kunde kräva omskrivning av flera delar av programmet eftersom allt var sammankopplat genom adresser och hopp.
Assemblerprogrammering var långsam och ömtålig. Vanliga problem inkluderade:
Forskare och ingenjörer körde inte bara en beräkning—de förfinade modeller, körde om simuleringar och utforskade "tänk om"-scenarier. När varje uppdatering betydde dagar eller veckor av omskrivning och testning, bromsade experimenterandet in.
Här blev en ny kostnad tydlig: programmerartid. Hårdvara var dyr, men det var också skickliga människor. I mitten av 1950-talet var flaskhalsen ofta inte maskinens hastighet—det var hur lång tid det tog människor att få maskinen att göra användbart arbete på ett tillförlitligt sätt.
John Backus började inte som en förutbestämd "datorpionjär." Efter en ombytlig tidig karriär och tid i amerikanska armén hamnade han på IBM i början av 1950-talet, när datorer fortfarande var sällsynta och mestadels programmerades för hand. Backus utmärkte sig snabbt för två saker: en praktisk otålighet inför tråkigt arbete och en talang för att organisera ambitiösa ingenjörsinsatser.
IBM hade ett problem och en möjlighet samlade i en maskin: IBM 704. Den var kraftfull för sin tid och designad med funktioner som betydde mycket för matematiktunga uppgifter (som flyttalsaritmetik). Men tekniska och vetenskapliga kunder—ingenjörer, forskare, statliga laboratorier—lade enorm tid på att skriva och felsöka assembler. Om programmeringen förblev lika långsam skulle även en utmärkt dator stå underutnyttjad.
IBMs satsning var enkel att beskriva men riskfylld att försöka: gör 704 enklare att programmera utan att ge upp hastighet.
Backus ledde ett team som betraktade FORTRAN som två oupplösliga projekt: ett språk människor kunde skriva, och en kompilator som kunde översätta det till snabb maskinkod. Den andra halvan var den verkliga satsningen. Många experter trodde att "automatisk programmering" alltid skulle vara för ineffektiv för att ersätta handtrimmat assembler.
Ett högnivåspråk var inte bara "trevlig syntax." Det betydde att skriva formler, loopar och strukturerade instruktioner närmare matematiken och logiken i ett problem—och sedan lita på att kompilatorn producerade kod som kunde konkurrera med vad en skicklig programmerare skulle göra för hand. Det var detta förtroende IBM och Backus försökte vinna.
FORTRANs kärnlöfte var enkelt men radikalt: istället för att berätta för maskinen hur varje litet steg skulle gå till kunde du skriva satser som såg mycket närmare ut som matematiken du redan använde.
En ingenjör kunde skriva något i stil med "beräkna den här formeln för många värden" istället för att manuellt stava ut sekvensen av laddningar, additioner, lagringar och hopp som assembler krävde. Hoppet var att programmering kunde bli mer som att uttrycka en idé—och mindre som att koppla ihop en kontrollpanel med ord.
FORTRAN körde inte direkt på maskinen. Ett separat program—kompilatorn—översatte FORTRAN-källkod till maskinens egna låg-nivåinstruktioner.
Du kan tänka på det som en skicklig tolk: du skriver på ett språk människor kan läsa; kompilatorn skriver om det till ett språk som IBM 704 kan exekvera.
Backus team siktade på en ovanlig kombination:
Den sista punkten spelade roll. FORTRAN försökte inte vara allt för alla—det var menat att få riktiga beräkningar gjorda med färre misstag.
Skeptiken var intensiv. Många programmerare trodde att prestanda krävde total kontroll, och att "automatisk" översättning skulle vara slösaktig. Andra var oroliga för felsökning: om kompilatorn genererade de slutliga instruktionerna, hur skulle man veta vad maskinen verkligen gjorde?
FORTRANs första användare var ingenjörer och forskare—människor med ekvationer att köra, modeller att testa och resultat att leverera. För dem var löftet inte uppseendeväckande; det var tid sparad, färre överföringsfel och program som kunde delas och underhållas av fler än en liten prästskap av assembler-experter.
FORTRAN var inte bara ett nytt sätt att skriva program—det krävde ett nytt sätt att översätta dem. Den uppgiften föll på kompilatorn, och dess framgång skulle avgöra om FORTRAN blev en revolution eller en parentes.
Tänk på en kompilator som en mycket skicklig tolk vid ett tekniskt möte. Du talar i klara, högnivåmeningar ("beräkna den här ekvationen, upprepa för varje värde"), men publiken förstår bara ett strikt, låg-nivå vokabulär. En medioker tolk kan översätta betydelsen korrekt men klumpigt—långsam, omständlig och full av kringgående vägar. En stor tolk bevarar både betydelsen och effektiviteten, och levererar något publiken omedelbart kan agera på.
FORTRAN behövde den stora tolken.
Tidiga programmerare valde inte FORTRAN för skönhet eller komfort. De valde det bara om det kunde betala sin hyra: färre kodtimmar utan straff i körtid. På dyra maskiner som IBM 704 var slösad CPU-tid slösade pengar—och i vetenskapligt arbete kunde långsam kod innebära att resultat kom för sent för att vara användbara.
Så den verkliga produkten var inte språkstandarden; det var kompilatorns output. Om det kompilerade programmet körde nästan lika snabbt som handskriven assembler kunde teamen motivera bytet. Om det inte gjorde det skulle de överge FORTRAN oavsett hur "trevligt" det såg ut.
FORTRANs säljpunkt—att skriva matematik som matematik—gjorde också kompilering svår. Kompilatorn behövde:
Många ingenjörer antog att högnivåkod per definition måste vara långsammare. Backus team behövde motbevisa det med bevis: kompilerade program som var konkurrenskraftiga, förutsägbara och pålitliga. Utan den prestandakredibiliteten skulle FORTRAN ses som en akademisk bekvämlighet—inte ett verktyg för verkligt arbete.
FORTRANs stora löfte var inte bara att det lät dig skriva kod snabbare—det var att det kompilerade programmet fortfarande kunde köra snabbt. Det spelade roll eftersom tidiga användare inte var hobbyister; det var ingenjörer och forskare som mätte värde i maskintimmar och levererade resultat.
Optimering är när kompilatorn gör extra arbete så att du slipper. Du skriver klara, matematik-liknande satser, och kompilatorn skriver tyst om dem till en version som använder färre instruktioner, färre minnesåtkomster och mindre tid på IBM 704.
Viktigt är att målet inte var att vara "smart"—det var att vara förutsägbart effektiv så att folk kunde lita på att skriva i FORTRAN inte skulle straffa dem med långsamma program.
FORTRAN-kompilatorn tillämpade förbättringar som motsvarar vardaglig intuition:
Inget av detta krävde att programmerare tänkte på instruktions-timing eller minnesadresser—ändå var det exakt de detaljerna assemblerprogrammerare brydde sig om.
Assembler hade ett starkt argument: "Jag kan alltid göra det snabbare för hand." Tidiga skeptiker antog att ett högnivåspråk skulle producera klumpig, slösaktig maskinkod.
Backus team behandlade den skepsisen som ett produktkrav. Optimering var inte en trevlig-funktion; det var beviset på att abstraktion inte innebar att ge upp prestanda.
När ryktet spred sig att FORTRAN-program kunde konkurrera med handskriven assembler i hastighet för många verkliga arbetsbelastningar, accelererade antagandet. Kompilatorn blev en slags betrodd medarbetare: skriv avsikten tydligt, låt kompilatorn svettas över detaljerna och få ändå resultat som respekterade hårdvaran.
FORTRAN var inte bara "trevligare" än assembler. Det paketerade några praktiska idéer som direkt motsvarade forskarnas och ingenjörernas dagliga arbete: upprepa en beräkning, återanvänd en metod och lagra många tal på ett förutsägbart sätt.
Vetenskapliga program är fulla av "gör detta N gånger"-uppgifter: summera mätningar, stega i tid, iterera mot en lösning eller köra samma ekvation över många datapunkter. I assembler innebar upprepning ofta handskriven hopp-logik—lätt att göra fel och svår att läsa senare.
FORTRANs DO-loop gjorde avsikten uppenbar:
SUM = 0.0
DO 10 I = 1, 100
SUM = SUM + X(I)
10 CONTINUE
I stället för att hantera flera hopp och räknare manuellt kunde programmerare ange intervallet och fokusera på formeln.
Ingenjörsarbete upprepar sig: multiplicera matriser, konvertera enheter, utvärdera ett polynom, läsa ett standardformat. Subrutiner lät team skriva en betrodd rutin och anropa den från många ställen. Det minskade copy‑paste-programmering—ett av de snabbaste sätten att sprida misstag.
Lika viktigt var att subrutiner uppmuntrade att dela upp ett stort program i mindre delar som folk kunde granska, testa och förbättra oberoende.
Mätningar, vektorer, tabeller, nät och matriser är centrala i vetenskaplig beräkning. Arrayer gav programmerare ett direkt sätt att representera den strukturen i stället för att jonglera många separata variabler eller göra manuell adressaritmetik i minnet.
Assembler-dominerat styrflöde förlitade sig på många konditionella och okonditionella hopp. En enda felaktig mål-etikett kunde tyst bryta resultat. Genom att erbjuda strukturerade konstruktioner som loopar och namngivna subrutiner minskade FORTRAN behovet av intrasslad hopp-logik—vilket gjorde program enklare att verifiera och mindre ömtåliga vid förändring.
FORTRAN var inte bara en smart idé i ett labb—det blev brett framgångsrikt eftersom det användes upprepade gånger av människor som löste dyra, tidskritiska problem. Ett språk kan beundras (och till och med påverka) utan att förändra vardagsarbetet. FORTRAN förändrade vardagsarbetet eftersom team litade på det tillräckligt för att satsa verkliga deadlines och budgetar.
Tidiga användare var grupper som levde och dog av beräkningar: rymdprogram, fysiklaboratorier, väder- och klimatarbete, och ingenjörsgrupper som gjorde strukturella och elektriska beräkningar. Det var inte lekexempel. Det var arbetsbelastningar där en liten förbättring i produktivitet betydde fler experiment, fler designiterationer och färre fel gömda i handtrimmad assembler.
FORTRAN passade särskilt bra eftersom dess kärnfunktioner matchade problemens form: arrayer för matriser och nät, loopar för upprepade numeriska steg och subrutiner för att organisera matematiktät kod i hanterbara delar.
Assemblerprogram var tätt kopplade till specifika maskiner och skrivna i en stil som var svår för utomstående att läsa eller modifiera. FORTRAN gjorde inte program omedelbart portabla över alla datorer, men det gjorde dem mer begripliga. Det gjorde det praktiskt att sprida kod inom en organisation—och så småningom mellan organisationer—utan att ursprungsförfattaren behövde "översätta" varje detalj.
När programmerare kunde uttrycka beräkningar på en högre nivå blev det meningsfullt att behålla ett bibliotek av betrodda rutiner. Team kunde återanvända numeriska metoder, in-/ut-mönster och domänspecifik kod med mindre rädsla för att en liten ändring skulle bryta allt. Denna förändring—kod som en tillgång värd att underhålla och återanvända—hjälpte till att föra programmering från ett enstaka hantverk mot upprepningsbart arbete.
FORTRAN gjorde inte bara programmerare lyckligare—det förändrade ekonomin i att skriva mjukvara. Före det innebar nästan varje nytt vetenskapligt eller tekniskt problem veckors handtrimmat assemblerarbete. Det arbetet var dyrt, svårt att verifiera och starkt knutet till en maskin och en specialist. Ett högnivåspråk gjorde en annan modell möjlig: skriv avsikten en gång, låt en kompilator sköta de knotiga detaljerna.
När ett team kunde leverera fungerande program snabbare kunde det anta projekt som tidigare varit orealistiska: större simuleringar, längre analyser och fler revisioner efterhand som kraven utvecklades. Detta spelar roll eftersom de flesta verkliga projekt inte är "skriv-det-en-gång"—det är ändringsförfrågningar, buggfixar och prestandajusteringar. FORTRAN minskade kostnaden för all kontinuerlig iteration.
FORTRAN uppmuntrade också en rolluppdelning:
Denna arbetsdelning skalar: i stället för att varje projekt var beroende av ett fåtal sällsynta assembler"trollkarlar" kunde fler människor bidra, granska och underhålla program.
När ett språk blir gemensam infrastruktur börjar mjukvara ses som något du kan paketera och sälja. FORTRAN påskyndade tillväxten av återanvändbara bibliotek, utbildningsmaterial och standardiserade kodningspraxis. Företag kunde motivera investeringar i verktyg och team eftersom produkten inte var låst till ett enda kundjobb—den kunde anpassas, stödjas och förbättras över många kunder och projekt.
Med andra ord bidrog FORTRAN till att flytta programmering från ett hantverk per maskin till en industri byggd på upprepbara metoder och återanvändbar mjukvara.
FORTRAN gjorde inte bara en maskin lättare att programmera. Det etablerade förväntningar om vad programmeringsspråk bör göra—och vad kompilatorer kunde göra—i en tid då båda idéerna fortfarande var kontroversiella.
En viktig lärdom från FORTRANs framgång är att språkdesign och kompilatordesign är oskiljaktiga. Tidiga kritiker tvivlade inte bara på "engelsklik" kod; de tvivlade på att en kompilator kunde översätta den till effektiva maskininstruktioner. FORTRAN-teamets svar—att investera tungt i kompilering och optimering—ekar i senare språkprojekt.
Denna inställning syns i den långvariga tron att bättre kompilatortekniker öppnar för bättre språk: säkrare abstraktioner, tydligare syntax och högre produktivitet utan att offra prestanda. Många senare system—från vetenskapliga språk till mainstream-språk—lånar idén att kompilatorn ansvarar för det hårda arbete som programmerare tidigare gjorde manuellt.
FORTRAN normaliserade idén att en kompilator bör producera konkurrenskraftig kod, särskilt för numeriska arbetsbelastningar. Även om inte varje senare språk jagade samma prestandamål förändrades baslinjen: högnivå behövde inte betyda långsamt.
Det här skiftet drev kompilatorforskning och -praxis mot optimeringstekniker (som loopanalys, omorganisering av beräkningar och registerhantering) som blev standardämnen i kompilatorkonstruktion under följande decennier.
Tidiga FORTRAN var tätt knutet till IBM-hårdvara, och portabilitet var inte huvudpoängen i början. Men när FORTRAN spreds mellan institutioner och maskiner blev kostnaden för att skriva om vetenskaplig kod uppenbar. Med tiden krediteras FORTRAN som en av de stora krafterna som drev industrin mot språksstandardisering.
Resultatet var inte omedelbart och inte perfekt—men det hjälpte sätta ett prejudikat: språk som lever längre än en leverantör eller datorgeneration behöver stabila definitioner, inte bara bra implementationer.
FORTRAN löste ett plågsamt problem—att skriva komplexa beräkningar utan att drunkna i assembler—men det gjorde inte programmering "lätt." Tidiga användare upptäckte att ett högnivåspråk kunde ta bort en uppsättning huvudvärk och samtidigt avslöja nya.
FORTRANs rykte för hastighet kom med kompromisser i hur kod såg ut och hur folk skrev den. Program formades ofta runt vad kompilatorn kunde optimera, inte vad som var mest läsbart.
Ett konkret exempel: en forskare kunde dela upp en klar beräkning i flera steg eller omsortera satser bara för att det körde snabbare så. Resultatet kunde bli kod som presterade väl men var svårare för en ny kollega att följa.
FORTRAN hyllas ofta för att hjälpa program flytta mellan maskiner, men i början hade "portabel" fortfarande en asterisk. Datorer skiljde sig i ordstorlek, in-/ut-enheter och till och med grundläggande numeriskt beteende. Team behöll ibland separata versioner av samma program för olika system eller lade in maskinspecifika delar när de behövde särskilda funktioner.
Ett enkelt exempel: att läsa data från hålkort, band eller en skrivarliknande enhet kunde kräva olika hantering även om matematiken var identisk.
FORTRAN byggdes för vetenskaplig beräkning, inte för allt. Det gav inte starka verktyg för att organisera mycket stora kodbaser som senare språk skulle göra. Felsökning kunde fortfarande vara långsam och frustrerande, och tidiga kompilatorer gav ibland kryptiska fel som kändes som "tillbaka till assembler", bara med annan terminologi.
FORTRAN väckte diskussioner som moderna team fortfarande känner igen: ska utvecklare prioritera maximal hastighet eller tydligare kod och högre nivå-abstraktioner? Det bästa svaret berodde då—och beror fortfarande—på sammanhanget.
FORTRAN bevisade att abstraktion kan löna sig, men den lärde också ut en varaktig läxa: varje bekvämlighetsskikt har gropar, och team måste besluta vilka kompromisser de kan leva med.
FORTRAN lyckades eftersom det behandlade utvecklartid som en begränsad resurs. Backus och IBM uppfann inte bara trevligare syntax—de visade att investering i verktyg kan öppna upp helt nya klasser av mjukvara.
FORTRANs budskap var enkelt: skriv färre rader, leverera fler korrekta program. Moderna team återupprepar detta ständigt. En vecka som används till att bygga ett säkrare API, en tydligare modulgräns eller ett skript som automatiserar ett plågsamt arbetsflöde ger ofta mer värde än att klämma ur 3% i en het loop som kanske inte spelar roll.
Folk tvivlade på FORTRAN eftersom abstraktion kändes som att ge upp kontroll. Kompilatorn ändrade det genom att leverera hastighet nära handskriven assembler.
Den moderna motsvarigheten är förtroende för ramverk, hanterade runtime-miljöer och molntjänster—men det förtroendet förtjänas, inte antas. När en abstraktion går sönder drar team sig tillbaka till "manuell läge". Motgiften är densamma som 1957: mätbar prestanda, transparent beteende och förutsägbara felbeteenden.
FORTRAN var inte bara ett språk—det var en kompilatorinsats som gjorde högnivåprogrammering möjlig i skala. Dagens motsvarigheter är:
Det finns också en nyare kategori verktyg som ekar den ursprungliga FORTRAN-satsningen: att använda automation för att flytta arbete från människohänder till ett "kompilator-liknande" system. Plattformar som Koder.ai driver denna idé längre genom att låta team beskriva vad de vill i chatten och låta ett agentbaserat system generera och iterera riktiga applikationer (till exempel React för webben, Go + PostgreSQL för backend och Flutter för mobil). I praktiken syftar funktioner som planeringsläge, snapshots och rollback till att erbjuda samma sak som FORTRAN behövde bevisa: högre nivå-avsikt utan att tappa operativ kontroll.
Bra verktyg förhindrar inte bara buggar; de ökar också ambitionen. De låter team bygga större system med mindre personal.
Backus varaktiga inverkan är idén att mjukvara skalar när systemet runt koden—språk, kompilator och praxis—hjälper människor att arbeta snabbare och med större trygghet. Det är fortfarande spelplanen för moderna ingenjörsteam.
FORTRAN spelade roll eftersom det minskade den mänskliga kostnaden för programmering utan att kräva en stor prestandapåverkan.
En kompilator är ett program som översätter mänskligt skrivna källkod till de låg-nivåinstruktioner en viss maskin kan köra.
I FORTRANs fall hade kompilatorn två viktiga uppgifter:
Huvudinvändningen mot högnivåspråk var hastighet. Om kompilerad FORTRAN körde mycket långsammare än assembler kunde inte vetenskapliga och tekniska team motivera bekvämligheten.
FORTRANs spridning hängde på att kompilatorn bevisade att den kunde producera konkurrenskraftig maskinkod, inte bara "körbar" kod.
Typiska optimeringar inkluderade praktiska, mekaniska förbättringar som:
FORTRAN gjorde kärnmönster i numeriska uppgifter lätta att uttrycka:
DO-loopar för upprepade beräkningar över intervall.Tillsammans minskade dessa konstruktioner "mystiska hopp" och manuell adressaritmetik—två vanliga felkällor i assembler.
Inte omedelbart, och inte perfekt. Tidig FORTRAN minskade mänskliga omskrivningskostnader och förbättrade läsbarheten, men verklig portabilitet begränsades av:
Med tiden gjorde pressen att flytta vetenskaplig kod mellan maskiner standardisering oundviklig.
Det förändrade ekonomin:
Med andra ord bidrog FORTRAN till att flytta programmering från ett hantverk per maskin till en industri baserad på återupprepbara metoder och återanvändbar mjukvara.
Flera kompromisser blev synliga i praktiken:
Det löste en stor flaskhals, men det eliminerade inte komplexitet.
Kärnlektion: att investera i verktyg kan låsa upp skala.
Praktiska råd:
Det används fortfarande mycket inom vetenskaplig och numerisk beräkning, särskilt där mogna, validerade bibliotek och långlivade kodbaser spelar roll.
Om du lär dig FORTRAN av historiska eller praktiska skäl:
Detta var precis de knep assemblerprogrammerare förlitade sig på—nu automatiserade.