John Backus leidde FORTRAN bij IBM en bewees dat hoog-niveau code toch snel kon draaien—wat productiviteit verhoogde en hielp software uitgroeien tot een echte industrie.
Begin jaren 1950 waren computers zeldzame, dure machines die door overheden, universiteiten en grote bedrijven werden gebruikt. Ze waren krachtig voor hun tijd—maar programmeren was pijnlijk traag. Veel programma's werden direct in machinetaal of assembly geschreven, waarbij elke instructie moest passen bij de kleine set hardware-operaties. Een kleine wijziging in een formule kon betekenen dat grote stukken code herschreven moesten worden, en één fout kon na uren wachten een hele run laten crashen.
John Backus was een ingenieur bij IBM die al had gezien hoeveel tijd verloren ging aan laag-niveau coderen. Hij leidde een klein team dat iets radicaals probeerde: laat programmeurs wiskundige instructies schrijven in een vorm dichter bij hoe ze over problemen dachten, en laat een compiler dat vertalen naar snelle machinetaal.
Het project werd FORTRAN (kort voor “Formula Translation”), gericht op IBM’s wetenschappelijke klanten—mensen die numeriek werk deden, geen administratieve verwerking. De belofte was simpel: schrijf minder code, maak minder bugs en draai nog steeds efficiënt op machines zoals de IBM 704.
Destijds dachten veel programmeurs dat hogere talen een luxe waren. Men ging ervan uit dat alles wat "in menselijke taal" leek veel langzamer zou draaien dan zorgvuldig geoptimaliseerde assembly—te langzaam om het gemak te rechtvaardigen. Met computers die fortuinen kostten en rekentijd strikt beperkt, was prestaties geen "nice to have". Het was het hele punt.
Dus FORTRAN was niet alleen nieuwe syntaxis. Het was een weddenschap dat automatisering het vakmanschap van experts kon evenaren: dat een compiler code kon produceren die goed genoeg was om vertrouwen te winnen bij wetenschappers en ingenieurs die om elke cyclus gaven.
Het verhaal van FORTRAN is deels technische doorbraak, deels cultuurverschuiving. Vervolgens kijken we naar hoe programmeren voelde vóór hogere talen, hoe Backus’ team een compiler bouwde die het kon opnemen tegen handgeschreven code, en waarom dat succes de economie van software veranderde—en patronen zette die moderne teams nog steeds gebruiken.
Voor FORTRAN betekende "programmeren" meestal het schrijven van instructies in de eigen vocabulaire van de computer—of iets slechts iets vriendelijkers.
Vroege computers voerden machinetaal uit: numerieke opcodes en geheugenadressen. Omdat dat op schaal bijna onwerkbaar was, gebruikten programmeurs assembly, die veel nummers verving door korte mnemonics. Maar assembly bleef een dunne laag bovenop de hardware. Je beschreef niet wat je wilde in wiskundige termen—je schreef hoe het stap voor stap moest gebeuren, register voor register.
Voor een wetenschappelijke berekening kon dat betekenen dat je lussen, geheugenindeling en tussenwaarden handmatig beheerde. Zelfs een kleine wijziging in een formule kon meerdere delen van het programma laten herschrijven omdat alles via adressen en sprongen met elkaar verbonden was.
Assembly-programmering was traag en fragiel. Veelvoorkomende problemen waren:
Wetenschappers en ingenieurs draaiden niet slechts één berekening—ze verfijnden modellen, herhaalden simulaties en onderzochten "wat als"-scenario's. Als elke update dagen of weken coderen en testen betekende, vertraagde experimenteren tot een slakkengang.
Hier ontstond een nieuwe soort kost: programmeurtijd. Hardware was duur, maar dat waren ook bekwame mensen. Midden jaren 1950 lag de bottleneck niet altijd bij de machinesnelheid—het was hoe lang mensen nodig hadden om de machine betrouwbaar nuttig werk te laten doen.
John Backus begon niet als een voorbestemde "computerpionier." Na een rusteloze vroege carrière en tijd in het Amerikaanse leger, belandde hij begin jaren 1950 bij IBM, toen computers nog zeldzaam waren en meestal met de hand geprogrammeerd werden. Backus viel snel op door twee dingen: een praktische ongeduld met saai werk en talent voor het organiseren van ambitieuze technische projecten.
IBM had een probleem en een kans in één machine: de IBM 704. Hij was krachtig voor zijn tijd en ontworpen met features die belangrijk waren voor wiskundig werk (zoals floating-point rekenkunde). Maar technische en wetenschappelijke klanten—ingenieurs, onderzoekers, overheidslaboratoria—besteedden enorme tijd aan schrijven en debuggen in assembly. Als programmeren zo langzaam bleef, zou zelfs een geweldige computer onderbenut blijven.
IBM’s weddenschap was eenvoudig te formuleren en riskant om te proberen: maak de 704 eenvoudiger te programmeren zonder snelheid op te geven.
Backus leidde een team dat FORTRAN als twee onafscheidelijke projecten behandelde: een taal die mensen konden schrijven en een compiler die dat naar snelle machinetaal kon vertalen. Dat tweede deel was de echte weddenschap. Veel experts geloofden dat "automatisch programmeren" altijd te inefficiënt zou blijven om handgetunede assembly te vervangen.
Een hoog-niveautaal was niet alleen "mooie syntaxis." Het betekende formules, lussen en gestructureerde instructies schrijven die dichter bij de wiskunde en logica van een probleem stonden—en dan de compiler vertrouwen om code te produceren die kon concurreren met wat een vaardige programmeur met de hand zou maken. Dat vertrouwen probeerden IBM en Backus te verdienen.
De kernbelofte van FORTRAN was simpel maar radicaal: in plaats van de machine elk klein stapje te vertellen, kon je statements schrijven die veel dichter bij de wiskunde stonden die je al gebruikte.
Een ingenieur kon schrijven: "bereken deze formule voor veel waarden", in plaats van handmatig de reeks loads, adds, stores en jumps te spellen die assembly vereiste. De hoop was dat programmeren meer op het uitdrukken van een idee ging lijken—en minder op het bedraden van een paneel met woorden.
FORTRAN draaide niet direct op de computer. Een apart programma—de compiler—vertaalde FORTRAN-broncode naar de laag-niveau instructies van de machine.
Je kunt het zien als een bekwame vertaler: jij schrijft in een taal die mensen kunnen lezen; de compiler herschrijft het in een taal die de IBM 704 kan uitvoeren.
Backus’ team streefde naar een zeldzame combinatie:
Dat laatste punt was belangrijk. FORTRAN probeerde niet alles voor iedereen te zijn—het was bedoeld om echte berekeningen met minder fouten te doen.
De scepsis was intens. Veel programmeurs geloofden dat prestaties totale controle vereisten en dat "automatische" vertaling verspilling zou zijn. Anderen maakten zich zorgen over debuggen: als de compiler de uiteindelijke instructies genereerde, hoe wist je wat de machine echt deed?
FORTRAN’s eerste gebruikers waren ingenieurs en wetenschappers—mensen met vergelijkingen om uit te voeren, modellen om te testen en resultaten te produceren. Voor hen was de belofte geen nieuwigheid; het was tijdsbesparing, minder transcriptiefouten en programma's die door meer mensen te onderhouden en delen waren dan door een klein priesterhood van assembly-experts.
FORTRAN was niet alleen een nieuwe manier om programma's te schrijven—het vroeg om een nieuwe manier om ze te vertalen. Die vertaaltaak viel toe aan de compiler, en het succes ervan zou bepalen of FORTRAN een revolutie of een voetnoot werd.
Denk aan een compiler als een zeer bekwame tolk bij een technische vergadering. Je spreekt in heldere, hoog-niveau zinnen ("bereken deze vergelijking, herhaal voor elke waarde"), maar het publiek begrijpt alleen een star, laag-niveau vocabulaire. Een middelmatige tolk vertaalt misschien de bedoeling correct maar onhandig—traag, omslachtig en vol omwegen. Een goede tolk behoudt zowel betekenis als efficiëntie, en levert iets dat het publiek direct kan uitvoeren.
FORTRAN had die geweldige tolk nodig.
Vroege programmeurs kozen FORTRAN niet omwille van schoonheid of comfort. Ze kozen het alleen als het zijn waarde kon bewijzen: minder uren coderen zonder een runtime-straf. Op dure machines als de IBM 704 was verspilde CPU-tijd weggegooid geld—en in wetenschappelijk werk kon langzame code betekenen dat resultaten te laat kwamen.
Dus het echte product was niet de taalstandaard; het was de output van de compiler. Als het gecompileerde programma bijna even snel draaide als handgeschreven assembly, konden teams de overstap verantwoorden. Zo niet, dan zouden ze FORTRAN verlaten ongeacht hoe "mooi" het leek.
Het verkoopargument van FORTRAN—wiskunde schrijven als wiskunde—maakte compilatie ook moeilijk. De compiler moest:
Veel ingenieurs gingen ervan uit dat hoog-niveau code per definitie traag moest zijn. Backus’ team moest die aanname met bewijs tegenspreken: gecompileerde programma's die concurrerend, voorspelbaar en betrouwbaar waren. Zonder die prestatiegeloofwaardigheid zou FORTRAN gezien worden als academisch gemak—niet als een gereedschap voor echt werk.
De grote belofte van FORTRAN was niet alleen dat het sneller liet schrijven—het was dat het gecompileerde programma nog steeds snel kon draaien. Dat mattered omdat vroege gebruikers geen hobbyisten waren; het waren ingenieurs en wetenschappers die waarde in machine-uren en geleverde resultaten maten.
Optimalisatie is het extra werk dat de compiler voor je doet zodat jij dat niet hoeft te doen. Je schrijft duidelijke, wiskundige statements en de compiler herschrijft ze stilletjes naar een versie die minder instructies, minder geheugenaccessen en minder tijd op de IBM 704 gebruikt.
Belangrijk: het doel was niet "slim doen" maar voorspelbaar efficiënt zijn—zodat mensen erop konden vertrouwen dat FORTRAN niet bestrafte met trage programma's.
De FORTRAN-compiler paste verbeteringen toe die aansluiten bij de alledaagse intuïtie:
Niets van dit vroeg dat programmeurs over instructietiming of geheugenadressen dachten—en toch waren het precies de details waar assembly-programmeurs om gaven.
Assembly had een sterk argument: "Ik kan het altijd sneller maken met de hand." Vroege sceptici dachten dat een hoog-niveautaal logge, verspilde machinetaal zou produceren.
Backus’ team behandelde die scepsis als producteis. Optimalisatie was geen aardigheidje; het was het bewijs dat abstractie niet betekende dat je prestaties opgaf.
Toen het rondging dat FORTRAN-programma's in veel reële workloads konden concurreren met handgeschreven assembly, versneldde de adoptie. De compiler werd een soort vertrouwde teamgenoot: schrijf de intentie duidelijk, laat de compiler het zware werk doen en krijg toch resultaten die de hardware respecteerden.
FORTRAN was niet alleen "aangenamer" dan assembly. Het bracht praktische ideeën die direct aansloten op het dagelijkse werk van wetenschappers en ingenieurs: herhaal een berekening, hergebruik een methode en sla veel getallen op op een voorspelbare manier.
Wetenschappelijke programma's zitten vol taken van het type "doe dit N keer": meetwaarden optellen, in de tijd stappen, itereren naar een oplossing of dezelfde vergelijking over veel datapunten toepassen. In assembly betekende herhaling vaak handgeschreven spronglogica—makkelijk fout te doen en later moeilijk leesbaar.
FORTRAN’s DO-lus maakte die intentie duidelijk:
SUM = 0.0
DO 10 I = 1, 100
SUM = SUM + X(I)
10 CONTINUE
In plaats van meerdere sprongen en tellers handmatig te beheren, konden programmeurs het bereik opgeven en zich op de formule concentreren.
Engineeringwerk herhaalt zich: matrixvermenigvuldiging, eenheden omzetten, een veelterm evalueren, een standaard dataformaat inlezen. Subroutines lieten teams één vertrouwde routine schrijven en die op veel plaatsen aanroepen. Dat verminderde copy‑paste-programmering—een van de snelste manieren om fouten te verspreiden.
Net zo belangrijk: subroutines moedigden aan een groot programma op te splitsen in kleinere delen die mensen onafhankelijk konden beoordelen, testen en verbeteren.
Metingen, vectoren, tabellen, rasters en matrices zijn centraal in wetenschappelijk rekenen. Arrays gaven programmeurs een directe manier om die structuur te representeren, in plaats van veel losse variabelen te beheren of handmatige adresarithmetiek in geheugen te doen.
Assembly-intensieve controleflow vertrouwde op veel conditionele en onvoorwaardelijke sprongen. Eén verkeerd doellabel kon stilletjes resultaten breken. Door gestructureerde constructies zoals lussen en benoemde subroutines aan te bieden, verminderde FORTRAN de behoefte aan verwarde spronglogica—waardoor programma's makkelijker te verifiëren en minder kwetsbaar werden voor veranderingen.
FORTRAN was niet alleen een slim idee uit een lab—het werd breed succesvol omdat mensen het herhaaldelijk gebruikten om dure, tijdkritische problemen op te lossen. Een taal kan bewonderd en invloedrijk zijn zonder het dagelijkse werk te veranderen. FORTRAN veranderde het dagelijkse werk omdat teams erop durfden te wedden voor echte deadlines en budgetten.
Vroege koplopers waren groepen die van berekeningen afhankelijk waren: ruimtevaartprogramma's, fysicalabs, weers- en klimaatonderzoek en technische afdelingen die structurele en elektrische berekeningen deden. Dit waren geen speelgoedvoorbeelden. Het waren workloads waarbij een kleine productiviteitsverbetering meer experimenten, meer ontwerpsiteraties en minder verborgen fouten in handgetunede assembly mogelijk maakte.
FORTRAN paste goed omdat de kernfeatures aansloten bij de probleemvorm: arrays voor matrices en rasters, lussen voor herhaalde numerieke stappen en subroutines om wiskundige code beheersbaar te organiseren.
Assemblyprogramma's waren sterk gekoppeld aan specifieke machines en in een stijl geschreven die outsiders moeilijk konden lezen of aanpassen. FORTRAN maakte programma's niet per se onmiddellijk draagbaar over alle computers, maar het maakte ze wel begrijpelijker. Daardoor werd het praktisch om code binnen een organisatie—en steeds vaker tussen organisaties—te verspreiden zonder dat de oorspronkelijke auteur elk detail hoefde te "vertalen".
Zodra programmeurs berekeningen op een hoger niveau konden uitdrukken, werd het zinvol om een bibliotheek met vertrouwde routines bij te houden. Teams konden numerieke methoden, I/O-patronen en domeinspecifieke berekeningen hergebruiken zonder vrees dat één regel aanpassen alles zou breken. Die verschuiving—code als een asset die het waard is te onderhouden en hergebruiken—helpte programmeren veranderen van ambacht naar herhaalbaar werk.
FORTRAN maakte programmeurs niet alleen gelukkiger—het veranderde de economie van software schrijven. Voorheen betekende elk nieuw wetenschappelijk of technisch probleem vaak weken werk in handgetunede assembly. Dat werk was duur, moeilijk te verifiëren en sterk gebonden aan één machine en één specialist. Een hoog-niveautaal maakte een ander model mogelijk: schrijf de intentie één keer en laat een compiler de ruwe details afhandelen.
Als een team sneller werkende programma's kon leveren, kon het projecten proberen die eerder onrealistisch waren: grotere simulaties, langere analyses en frequentere revisies naarmate eisen evolueerden. Dit is belangrijk omdat echt werk zelden "schrijf het één keer" is—het zijn wijzigingsverzoeken, bugfixes en prestatietuning. FORTRAN verlaagde de kosten van al die doorlopende iteratie.
FORTRAN moedigde ook een splitsing van rollen aan:
Die rolverdeling schaalt: in plaats van dat elk project afhankelijk was van enkele zeldzame assembly-"tovernaars", konden meer mensen bijdragen, reviewen en onderhouden.
Zodra een taal gedeelde infrastructuur werd, begon software op iets te lijken dat je kon verpakken en verkopen. FORTRAN versnelde de groei van herbruikbare bibliotheken, trainingsmateriaal en gestandaardiseerde praktijken. Bedrijven konden investeren in tools en teams rechtvaardigen omdat de output niet vastzat aan een enkele klus—hij kon worden aangepast, ondersteund en verbeterd voor meerdere klanten en projecten.
Met andere woorden: FORTRAN hielp programmeren verschuiven van ambacht-per-machine naar een industrie gebaseerd op herhaalbare methoden en herbruikbare software.
FORTRAN maakte niet alleen één machine gemakkelijker te programmeren. Het vestigde verwachtingen over wat programmeertalen moeten doen—en wat compilers kunnen doen—op een moment dat beide ideeën nog controversieel waren.
Een belangrijke les uit FORTRAN’s succes is dat taalontwerp en compilerontwerp onafscheidelijk zijn. Vroege critici twijfelden niet alleen aan "menselijke-taal" code; ze betwijfelden of een compiler het efficiënt in machinetaal kon omzetten. Het antwoord van het FORTRAN-team—zwaar investeren in compilatie en optimalisatie—echoot in latere taalprojecten.
Die denkwijze zie je terug in het geloof dat betere compilatietechnieken betere talen mogelijk maken: veiligere abstracties, duidelijkere syntaxis en hogere productiviteit zonder prestaties op te geven. Veel latere systemen—van wetenschappelijke talen tot mainstreamtalen—namen het idee over dat de compiler het zware werk doet dat programmeurs vroeger manueel deden.
FORTRAN maakte de notie normaal dat een compiler concurrerende code moet produceren, zeker voor numerieke workloads. Hoewel niet elke latere taal dezelfde prestatiedoelen nastreefde, veranderde de basisverwachting: hoog-niveau hoefde niet traag te betekenen.
Dit verlegde compileronderzoek en -praktijk naar optimalisatietechnieken (zoals lusanalyse, herordenen van berekeningen en registerbeheer) die decennialang standaardonderwerpen in compilerbouw werden.
Vroege FORTRAN was nauw verbonden met IBM-hardware en draagbaarheid was in het begin geen hoofdargument. Maar naarmate FORTRAN zich verspreidde, werd de kost van het herschrijven van wetenschappelijke code duidelijk. Historisch gezien wordt FORTRAN gezien als een belangrijke drijfveer richting taalstandaardisatie.
Het resultaat was niet meteen en niet perfect—maar het legde een precedent: talen die langer meegaan dan één leverancier of machinegeneratie hebben stabiele definities nodig, niet alleen goede implementaties.
FORTRAN loste een pijnlijk probleem op—complexe berekeningen schrijven zonder in assembly te verdrinken—maar het maakte programmeren niet magisch "makkelijk". Vroege gebruikers ontdekten dat een hoog-niveau taal één set problemen kon wegnemen en nieuwe blootleggen.
FORTRAN’s reputatie voor snelheid had trade-offs in hoe code eruitzag en hoe mensen schreven. Programma's werden vaak gevormd rond wat de compiler kon optimaliseren, niet wat het meest leesbaar was.
Een voorbeeld: een wetenschapper kon een duidelijke berekening opsplitsen of statements herschikken simpelweg omdat het sneller draaide. Het resultaat kon code zijn die goed presteerde maar lastiger was voor een nieuwe collega om te volgen.
FORTRAN wordt vaak geprezen voor het helpen verplaatsen van programma's tussen machines, maar in het begin was "draagbaar" met een sterretje. Computers verschilden in woordlengte, I/O-apparaten en zelfs basis numeriek gedrag. Teams hielden soms aparte versies van hetzelfde programma voor verschillende systemen of voegden machine-specifieke onderdelen toe wanneer ze speciale features nodig hadden.
Een simpel voorbeeld: data inlezen van kaarten, tape of printer-achtige apparaten kon anders vereisen, zelfs als de wiskunde identiek was.
FORTRAN was gebouwd voor wetenschappelijke computing, niet voor alles. Het bood niet sterke hulpmiddelen om zeer grote codebases te organiseren zoals latere talen dat deden. Debuggen kon nog steeds traag en frustrerend zijn, en vroege compilers produceerden soms cryptische fouten die aanvoelden als "terug naar assembly", alleen met andere bewoording.
FORTRAN veroorzaakte discussies die moderne teams nog steeds herkennen: moeten ontwikkelaars maximale snelheid nastreven, of duidelijkere code en hogere abstracties? Het beste antwoord hing toen af van de context—en dat geldt nog steeds.
FORTRAN bewees dat abstractie zich kon uitbetalen, maar het leerde ook een blijvende les: elke laag gemak heeft randen, en teams moeten beslissen welke afwegingen ze accepteren.
FORTRAN slaagde omdat het ontwikkeluren als de schaarse hulpbron behandelde. Backus en IBM verzonnen niet alleen mooiere syntaxis—ze bewezen dat investeren in tools hele nieuwe klassen software mogelijk maakt.
FORTRAN’s pitch was simpel: schrijf minder regels, lever meer correcte programma's. Moderne teams leren dit steeds opnieuw. Een week besteed aan een veiliger API, duidelijkere modulegrenzen of een script dat een pijnlijke workflow automatiseert, betaalt zich vaak terug meer dan het optimaliseren van een hot loop met 3% winst die misschien niet eens belangrijk is.
Mensen twijfelden aan FORTRAN omdat abstractie voelde als controle opgeven. De compiler verdiende dat vertrouwen door prestaties te leveren die dicht bij handgeschreven assembly lagen.
De moderne versie is vertrouwen in frameworks, managed runtimes en clouddiensten—maar dat vertrouwen moet verdiend worden. Wanneer een abstractie faalt, stappen teams terug naar de manuele modus. Het tegengif is hetzelfde als in 1957: meetbare prestaties, transparant gedrag en voorspelbare faalwijzen.
FORTRAN was niet alleen een taal—het was een compilatorinspanning die hoog-niveau programmeren schaalbaar maakte. Hedendaagse equivalente voorbeelden zijn:
Er is ook een nieuwere categorie tooling die de oorspronkelijke FORTRAN-weddenschap weerspiegelt: automatisering waarmee werk van mensen naar een "compiler-achtige" laag wordt verplaatst. Vibe-coding platforms zoals Koder.ai voeren dit idee verder uit door teams te laten beschrijven wat ze willen in chat, waarna een agent-gebaseerd systeem echte applicaties genereert en erop iterereert (bijv. React op het web, Go + PostgreSQL op de backend en Flutter voor mobiel). In de praktijk proberen features als planningsmodus, snapshots en rollback hetzelfde te bieden als FORTRAN moest bewijzen: intentie op een hoger niveau, zonder operationele controle te verliezen.
Goede tools voorkomen niet alleen bugs; ze vergroten ambitie. Ze laten teams grotere systemen bouwen met kleinere teams.
Backus’ blijvende impact is het idee dat software schaalbaar wordt wanneer het systeem rond de code—taal, compiler en werkwijzen—mensen helpt sneller en met meer vertrouwen te werken. Dat is nog steeds het speelboek voor moderne engineeringteams.
FORTRAN was belangrijk omdat het de menselijke kosten van programmeren verminderde zonder een groot runtime-straf te vragen.
Een compiler is een programma dat door mensen geschreven broncode vertaalt naar de laag-niveau instructies die een specifieke machine kan uitvoeren.
In het geval van FORTRAN moest de compiler twee taken goed doen:
Omdat het hoofdbezwaar tegen hogere talen snelheid was. Als gecompileerde FORTRAN veel langzamer draaide dan assembly, konden wetenschappelijke en technische teams het gemak niet rechtvaardigen.
De adoptie van FORTRAN hing af van het bewijs dat de compiler concurrerende machinetaal produceerde, niet alleen "werkende" code.
Typische optimalisaties waren praktische mechanische verbeteringen zoals:
Dit waren precies de trucs waarop assembly-programmeurs vertrouwden—nu geautomatiseerd.
FORTRAN maakte kernpatronen voor numerieke rekenwerk eenvoudig uit te drukken:
DO-lussen voor herhaalde berekeningen over reeksen.Samen verminderden deze features "mystery jumps" en handmatige adresberekeningen—twee veelvoorkomende foutbronnen in assembly.
Niet meteen, en niet perfect. Vroege FORTRAN verminderde de menselijke herschrijvingskosten en verbeterde de leesbaarheid, maar echte draagbaarheid werd beperkt door:
In de loop van de tijd dwong de druk om wetenschappelijke code tussen machines te verplaatsen de industrie richting standaardisatie.
Het veranderde de economie:
Met andere woorden: FORTRAN hielp programmeren verschuiven van ambacht per machine naar een industrie gebaseerd op herhaalbare methoden en herbruikbare software.
Enkele afwegingen kwamen in de praktijk naar voren:
Het loste een groot knelpunt op, maar elimineerde complexiteit niet.
De kernles is dat investeren in tooling schaal mogelijk maakt.
Praktische lessen:
Het wordt nog steeds veel gebruikt in wetenschappelijke en numerieke computing, vooral waar volwassen, gevalideerde bibliotheken en langlevende codebases belangrijk zijn.
Als je het wilt leren om historische of praktische redenen: