Ontdek hoe het opgeslagen‑programma‑idee—vaak gekoppeld aan John von Neumann—herbruikbare software, algemene computers en modern programmeren mogelijk maakte.
In het hart van moderne informatica staat een eenvoudige vraag: wat maakte het mogelijk dat één machine veel verschillende taken kon uitvoeren zonder elke keer te worden herbouwd? Vroege elektronische computers konden snel rekenen, maar „de taak veranderen” betekende vaak de machine fysiek anders opzetten. Het opgeslagen‑programma‑idee is het kantelpunt dat computers echt programmeerbaar maakte.
Een computer met opgeslagen programma's bewaart de instructies voor een taak (het programma) in hetzelfde soort intern geheugen als de gegevens waarop het programma werkt. In plaats van hardware te herbedraden of panelen handmatig te herconfigureren, kun je een nieuwe set instructies in het geheugen laden en een andere taak starten.
Dat lijkt nu vanzelfsprekend, maar het was een ingrijpende verschuiving:
Het is niet alleen een historisch curiosum. Het opgeslagen‑programma‑concept legt uit waarom “software” bestaat als iets los van “hardware”, en waarom het updaten van een apparaat tegenwoordig nieuwe functies kan ontsluiten zonder de chips binnenin te veranderen.
In de volgende secties lopen we door het probleem waarmee vroege computers te kampen hadden, wat het opgeslagen‑programma‑principe veranderde, de mensen en documenten die het idee verduidelijkten (inclusief het beroemde EDVAC‑rapport), en hoe de term “von Neumann‑architectuur” een veelgebruikt ontwerp is gaan vertegenwoordigen.
Hoewel de naam van John von Neumann sterk geassocieerd wordt met opgeslagen‑programma‑computing, is de erkenning verdeeld over een bredere groep en periode. Veel onderzoekers kwamen tot vergelijkbare ideeën terwijl ze de eerste praktische elektronische computers bouwden. Dit artikel houdt die context in het oog, omdat begrijpen dat het een teaminspanning was helpt verklaren hoe het idee zich zo snel verspreidde en het standaardmodel werd voor de meeste volgende computers.
Voor het opgeslagen‑programma‑idee „draaiden” veel vroege computers niet op dezelfde manier software als we dat nu bedoelen. Ze konden indrukwekkend snel rekenen, maar vertellen wat te doen betekende vaak de machine zelf fysiek veranderen.
Een veelgebruikte aanpak was plugboards, patchkabels en schakelpanelen. Operators verbonden draden tussen stopcontacten, stelden rijen schakelaars in en pasten soms timing‑units aan zodat signalen in de juiste volgorde aankwamen. Het „programma” was geen bestand dat je laadde—het was een tijdelijke bedradingstekening.
Deze opzet werkte, maar had een verborgen kostenpost: elke nieuwe taak was een klein engineeringproject. Als je de bewerkingsvolgorde wilde veranderen (optellen, vermenigvuldigen, vergelijken, lus), moest je mogelijk tientallen of honderden verbindingen verplaatsen. Een enkele verkeerd geplaatste kabel kon subtiele fouten veroorzaken die moeilijk te diagnosticeren waren, omdat de logica verspreid zat over hardwareverbindingen in plaats van opgeschreven als leesbare stappen.
Het herconfigureren kon uren of dagen duren, vooral als de machine zorgvuldig moest worden uitgeschakeld, herbedraad en getest. Dat betekende beperkte flexibiliteit: deze machines werden vaak voor lange perioden voor één soort berekening ingepland omdat het wisselen van taak zo ingrijpend was.
Stel je een machine voor die is ingesteld om artillerie‑vuurtafels te berekenen—lange, repetitieve berekeningen met een vaste formule. Als onderzoekers vervolgens dezelfde machine een ander probleem wilden laten oplossen, zoals statistieken voor een volkstelling, was het geen snelle “bewerk het programma en draai het opnieuw”. De volgorde van operaties, tussenopslagstappen en voorwaardelijke controles konden allemaal verschillen, wat een volledige plugboard‑herontwerp en een nieuwe ronde verificatie vereiste.
Dit is de wereld waar de computer met opgeslagen programma's aan wilde ontsnappen.
Een computer met opgeslagen programma's is een machine waarbij de instructies (het programma) in hetzelfde werkgeheugen leven als de gegevens die het programma gebruikt. Met andere woorden: de computer behandelt “wat te doen” niet als iets gescheiden van “waarmee te werken is”—beide worden opgeslagen als bitpatronen in het geheugen.
Toen vroege computerpioniers het over geheugen hadden, bedoelden ze de snelle, direct bruikbare interne opslag van de computer—wat we nu het meest met RAM zouden associëren. Het is de plaats waar de processor snel kunt lezen en naar kunt schrijven terwijl hij draait.
Dat verschilt van langetermijnopslag zoals een harde schijf of SSD. Een schijf is prima om bestanden te bewaren als de stroom uit is, maar het is niet het onmiddellijke kladblok waar de processor voortdurend de volgende instructie ophaalt en tussenresultaten bijwerkt.
Zodra instructies in het geheugen staan, wordt het wisselen van taak dramatisch eenvoudiger: je kunt een nieuw programma in het geheugen laden en uitvoeren, zonder te herbouwen, te herbedraden of de hardware fysiek te reconfigureren. Dezelfde algemeen bruikbare machine kan ’s ochtends salarisadministratie doen en ’s middags ballistiekberekeningen—omdat het “hoe” van de taak simpelweg een andere set bits is die je kunt vervangen.
Stel je een keuken voor waar het recept en de ingrediënten samen in dezelfde voorraadkast worden bewaard. De kok (de processor) gaat herhaaldelijk naar de voorraadkast (geheugen) om de volgende receptstap (instructie) te lezen en ingrediënten (data) te pakken of bij te werken.
Wil je een ander gerecht maken? Je hoeft de keuken niet om te bouwen. Je verwisselt gewoon het recept—terwijl je dezelfde aanrecht, oven en gereedschappen gebruikt.
John von Neumann heeft de computer niet „uitgevonden”, en hij creëerde het opgeslagen‑programma‑idee niet helemaal alleen. Wat hij wel deed—op briljante wijze—was helpen een veelbelovend concept te vertalen naar een helder geformuleerd, breed gedeeld ontwerp waar andere ingenieurs en laboratoria op konden voortbouwen.
Von Neumann was nauw betrokken bij oorlogstijd‑ en naoorlogse computerprojecten, adviseerde teams en scherpt de logische structuur van vroege ontwerpen aan. Hij had een gave om complexe technische keuzes op een duidelijke, georganiseerde manier uit te leggen, en dat was belangrijk omdat de vroege elektronische computerwereld snel bewoog, met meerdere groepen die vergelijkbare problemen oplosten.
Nog belangrijker: hij schreef en verspreidde invloedrijke beschrijvingen van hoe een computer programinstructies in hetzelfde geheugen als data kon opslaan. Die duidelijke framing maakte het makkelijker voor anderen om het idee te bespreken, te onderwijzen en te repliceren.
Namen blijven vaak plakken bij niet de eerste persoon met een idee, maar bij de persoon wiens beschrijving het referentiepunt wordt. Von Neumann’s teksten werden veel gelezen, gekopieerd en geciteerd—dus latere lezers associeerden de organisatie met opgeslagen programma's natuurlijk met hem.
Die labelvorming vereenvoudigt ook de geschiedenis: het is makkelijker om “von Neumann‑architectuur” te zeggen dan alle bijdragers en rapporten op te sommen. Maar die afkorting kan vervagen wat er echt gebeurde.
Vroege elektronische computing was een samenwerkingsverband tussen wiskundigen, ingenieurs en programmeurs. Het opgeslagen‑programma‑concept rijpte via discussies, concepten, prototypes en revisies over teams heen. Von Neumann’s blijvende rol was het idee helpen kristalliseren en uitdragen—zonder te beweren dat hij het alleen bedacht had.
EDVAC (Electronic Discrete Variable Automatic Computer) was een van de vroege naoorlogse computerprojecten die verder wilden gaan dan „eenmalige” machines. Net zo belangrijk als het hardware‑werk was de beslissing om ontwerpideeën op te schrijven in een duidelijke, deelbare vorm. Computerbouw was toen nog experimentele engineering—kennis leefde in labdagboeken, vergaderingen en hoofden van een paar specialisten. Een rapport kon die verspreide inzichten veranderen in iets dat andere teams konden bespreken, bekritiseren en hergebruiken.
De First Draft of a Report on the EDVAC (vaak simpelweg het “EDVAC‑rapport” genoemd) legde in heldere, conceptuele termen het opgeslagen‑programma‑idee uit: een computer zou programinstructies in hetzelfde soort intern geheugen moeten bewaren als data. Dat geheugen is niet alleen een plek om getallen vast te houden tijdens een berekening—het bevat ook de stappen die de machine vertellen wat hij daarna moet doen.
Deze formulering laat een computer minder voelen als een vast apparaat en meer als een algemene machine die “herbestemd” kan worden door te veranderen wat er in het geheugen staat. Je herbedraad het systeem niet om van de ene taak naar de andere te schakelen; je laadt een andere volgorde instructies.
Naast het concept zelf hielp het rapport standaardiseren hoe mensen over computers spraken: geheugen, besturing, rekenwerk en in/uit als afzonderlijke functionele delen die samenwerkten. Een gedeelde woordenschat en een breed gelezen beschrijving legden niet alleen EDVAC uit—ze gaven het veld een gemeenschappelijk mentaal model om opgeslagen‑programma‑computers te bouwen, te vergelijken en te verbeteren.
Het is verleidelijk om te vragen “wie heeft de opgeslagen‑programmacomputer uitgevonden?” en een enkele naam te verwachten. Maar wetenschap en techniek werken zelden zo. Ideeën ontstaan vaak parallel, worden verfijnd door discussie en overtuigen pas echt als ze in werkende hardware worden aangetoond.
John von Neumann wordt sterk geassocieerd met het opgeslagen‑programma‑concept, maar het vroege werk omvatte veel mensen en groepen:
Een opgeslagen‑programmacomputer is geen enkele simpele ingeving. Het combineert (1) de conceptuele sprong dat instructies net als data in geheugen kunnen leven, (2) de engineering om betrouwbaar geheugen en besturingseenheden te bouwen, en (3) de programmeerpraktijken die het ontwerp bruikbaar maken. Verschillende mensen droegen bij aan verschillende onderdelen.
Een andere reden voor gedeelde erkenning: een idee voorstellen is niet hetzelfde als een machine bouwen die dag in dag uit werkt. Vroege rapporten en discussies maakten het concept duidelijker; vroege prototypes en productiesystemen bewezen dat het haalbaar was. Een zorgvuldige geschiedenis respecteert beide soorten bijdragen—zonder te vervallen in een simplistische ‘eerste uitvinder’‑uitspraak.
Als mensen “von Neumann‑architectuur” zeggen, doelen ze meestal op een simpel, veelgebruikt model van hoe een opgeslagen‑programma‑computer is georganiseerd. Het is geen merk of één historische machine—het is een handige aanduiding voor een basisplan dat in verschillende vormen in veel computers terugkomt.
Conceptueel ziet het plaatje er zo uit:
Het belangrijkste idee is dat de CPU geen aparte fysieke plek heeft voor “het programma” versus “de getallen”. Hij haalt alles wat hij nodig heeft uit het geheugen.
De CPU draait een programma door een lus te herhalen die vaak wordt beschreven als haal–decodeer–voer uit:
Deze beschrijving is vereenvoudigd, maar vat de kern: het programma is een reeks instructies in het geheugen, en de CPU loopt er stapsgewijs doorheen.
Het samenvoegen van instructies en data in hetzelfde geheugen maakt een computer op een heel praktische manier algemeen inzetbaar:
Dus “von Neumann‑architectuur” is het best te begrijpen als een afkorting voor het opgeslagen‑programma‑model met een CPU, gedeeld geheugen dat instructies en data bevat, en I/O—een idee dat sterk met von Neumann’s duidelijke uitleg geassocieerd is, ook al waren er meerdere bijdragers aan het vroege verhaal van opgeslagen programma's.
Mensen praten vaak over “von Neumann” en “Harvard” alsof het concurrerende filosofieën zijn. Het zijn in feite twee praktische manieren om programinstructies en data te rangschikken zodat de computer het kan ophalen.
In een von Neumann‑stijl ontwerp leven instructies en data in hetzelfde geheugen en reizen ze meestal over hetzelfde hoofdpad naar de CPU.
Dat is conceptueel eenvoudig: een programma is gewoon bytes in het geheugen, vlak naast de getallen, tekst en afbeeldingen waar het op werkt. Het maakt algemene computing ook heel direct—software kan worden geladen, veranderd en opgeslagen met dezelfde mechanismen als data.
De afruil: als instructies en data dezelfde “weg” delen, kunnen ze concurreren om bandbreedte. (Je hoort dit soms een “knelpunt” noemen, maar het kernidee is het delen van middelen.)
Een Harvard‑stijl aanpak houdt instructieopslag gescheiden van dataopslag, vaak met aparte paden voor elk.
Die scheiding kan het eenvoudiger maken om de volgende instructie te halen terwijl je ook data leest of schrijft—handig in kleine, voorspelbare systemen. Een eenvoudig voorbeeld zijn veel microcontrollers, waarbij programmacode in flash kan wonen en variabelen in RAM.
Moderne CPU's lijken voor software vaak “von Neumann” terwijl ze intern Harvard‑achtige ideeën gebruiken. Een veelvoorkomend voorbeeld is aparte instructie‑ en data‑caches (I‑cache en D‑cache). Voor jouw programma voelt het nog als één geheugen, maar de hardware kan code en data efficiënter ophalen.
Wat te onthouden: er is geen universele winnaar. Von Neumann benadrukt eenvoud en flexibiliteit; Harvard scheiding en doorvoer. Veel machines mixen beide om bruikbaarheid, kosten, energie en snelheid in balans te brengen.
Een computer met opgeslagen programma's laadt een set instructies uit geheugen, voert ze uit en kan later een andere set laden. Die verschuiving maakte software herbruikbaar en deelbaar: een programma kon eenmaal geschreven worden, worden opgeslagen, gekopieerd, verbeterd en verspreid zonder de hardware aan te raken.
Als het programma in geheugen leeft, kan dezelfde fysieke computer veel verschillende taken uitvoeren door simpelweg de instructies te verwisselen. Dat is wat ‘algemeen bruikbaar’ echt betekent: één machine, veel programma's. De computer wordt geen enkel workflowsysteem meer; hij wordt een platform.
Een herkenbaar modern voorbeeld is je laptop die e‑mail, games en spreadsheets draait. Onder de motorkap is het hetzelfde idee: de hardware blijft gelijk terwijl verschillende opgeslagen programma's worden geladen en uitgevoerd als je apps wisselt.
Zodra instructies in geheugen als data worden behandeld, wordt het praktisch om lagen software te bouwen die helpen bij het schrijven van software:
Deze tools veronderstellen dat programma's kunnen worden opgeslagen, verplaatst en gemanipuleerd als andere informatie. Dat is wat van software een ecosysteem maakte in plaats van een eenmalig artefact gebonden aan bedrading.
Een nuttige manier om de lange lijn te zien: opgeslagen programma's maakten compilers en OS'en mogelijk, die weer betere ontwikkeltools mogelijk maakten—en tegenwoordig zien we een nieuwe laag abstractie waarbij je een applicatie in natuurlijke taal kunt beschrijven en tools werkende code genereren. Bijvoorbeeld, Koder.ai is een vibe‑coding platform waar je web-, backend‑ of mobiele apps bouwt via een chatinterface, leunend op LLM's en een agent‑gebaseerde workflow om de weg van intentie (“wat moet het doen?”) naar uitvoerbare instructies (broncode die je kunt exporteren, deployen en terugzetten via snapshots) te versnellen.
Het resultaat is hetzelfde deugdzame cirkel: opgeslagen programma's maakten betere gereedschappen mogelijk, en betere gereedschappen maakten ambitieuzere programma's mogelijk—waardoor computers flexibele, algemeen inzetbare machines werden.
Het opgeslagen‑programma‑idee maakte computers flexibel, maar bracht ook een praktische beperking aan het licht waar ingenieurs nog steeds over praten: de “von Neumann‑bottleneck.” In alledaagse termen is het als een file op de weg tussen de CPU (de werker) en het geheugen (het magazijn).
In een typisch opgeslagen‑programma‑ontwerp wonen zowel instructies als data in het geheugen. De CPU haalt een instructie op, haalt vervolgens de benodigde data op en schrijft resultaten terug—vaak over dezelfde verbinding. Als die verbinding informatie niet snel genoeg kan verplaatsen, staat de CPU stil, zelfs als hij veel sneller zou kunnen rekenen.
Twee gerelateerde factoren bepalen dit knelpunt:
Een CPU kan miljarden bewerkingen per seconde uitvoeren, maar als het geheugen geen gestage stroom instructies en data levert, wordt de prestatie beperkt door de traagste stap: bytes in en uit krijgen.
Dit is een veelbesproken engineeringoverweging, en moderne computers gebruiken verschillende technieken om de impact te verminderen:
Deze benaderingen elimineren de onderliggende “weg” niet, maar helpen hem minder druk te maken—zodat de CPU meer kan werken en minder hoeft te wachten.
Het opgeslagen‑programma‑concept is geen museumstuk—het is hoe alledaagse computing flexibel blijft. Je apparaten hoeven niet te worden „herbedraad” om iets nieuws te doen; ze laden gewoon andere instructies in het geheugen en voeren die uit.
Op een telefoon zorgt het aantippen van een app‑icoon ervoor dat het besturingssysteem de code (instructies) van die app van opslag naar geheugen laadt, waarna de CPU deze uitvoert. Op een laptop gebeurt hetzelfde wanneer je een browser opent, een document bewerkt of een spel draait. Op servers is het nog zichtbaarder: de machine kan duizenden wisselende workloads draaien—webverzoeken, databasequeries, achtergrondtaken—zonder de hardware te veranderen.
Zelfs functies die we als “hardwareachtig” zien, worden vaak software‑gedefinieerd. Netwerkrouting, video‑decodering, fotoverbetering en energiebeheerbeleid worden regelmatig bijgewerkt via firmware en systeemsoftware—nieuwe instructies, hetzelfde apparaat.
Talen zoals Python en JavaScript draaien meestal via een interpreter of een virtuele machine. In plaats van dat de CPU direct je broncode uitvoert, wordt je programma vertaald naar een gestructureerde vorm (bytecode of interne instructies) die in geheugen wordt bewaard en stap voor stap wordt uitgevoerd. Java’s JVM, .NET, WebAssembly‑runtimes en browser JavaScript‑engines vertrouwen hier allemaal op: instructies worden datastructuren die de machine kan laden, verplaatsen en uitvoeren.
Omdat instructies gewoon informatie zijn, proberen aanvallen soms kwaadaardige code als data naar binnen te smokkelen—klassieke code‑injectie. Verdedigingen zoals geheugenbescherming, code‑signing en niet‑uitvoerbare geheugenregio's bestaan om te voorkomen dat onbetrouwbare data als uitvoerbare instructies wordt behandeld.
Dit alles brengt ons terug bij de kernbelofte van opgeslagen programma's: flexibiliteit via software—nieuw gedrag op dezelfde hardware.
Als je naar een computer kijkt (of een specificatie leest), helpen deze vragen om het basismodel te herkennen:
Als je meer achtergrondvriendelijke posts zoals deze wilt, blader dan door /blog.
Opmerking: Als je experimenteert met moderne manieren om “instructies” in draaiende systemen te veranderen—of dat nu door rechtstreeks code te schrijven is of via chatgestuurde bouwplatforms zoals Koder.ai—overweeg dan te documenteren wat je leert. Koder.ai biedt ook een earn‑credits‑programma voor gepubliceerde inhoud en verwijzingen, wat een praktische manier kan zijn om meer experimenten en tutorials te bekostigen.
Een computer met opgeslagen programma's bewaart programinstructies in hetzelfde interne geheugen dat gebruikt wordt voor de gegevens waarop die instructies werken. Om van taak te veranderen laad je een andere set instructies in het geheugen in plaats van de hardware te herbedraden of opnieuw te configureren.
Voor opgeslagen programma's werden veel machines effectief “geprogrammeerd” met plugboards, patchkabels en schakelinstellingen. Het veranderen van de volgorde van bewerkingen kon uren of dagen aan herbedrading en retesten vereisen, en één verkeerde verbinding kon moeilijk te vinden fouten introduceren.
In deze context betekent “geheugen” de snelle werkopslag van de computer (het meest vergelijkbaar met modern RAM) die de CPU voortdurend kan lezen en schrijven tijdens het draaien. Het verschilt van langetermijnopslag (zoals schijven/SSD's), die programma's en bestanden bewaart wanneer de stroom uit is.
Het EDVAC‑rapport beschreef helder de organisatie waarbij instructies en gegevens hetzelfde interne geheugen delen, en introduceerde een nuttig begrippenkader voor het praten over computeronderdelen (geheugen, besturing, rekenwerk, in/uit). Die helderheid hielp andere teams snel vergelijkbare systemen te bespreken en te bouwen.
Zijn naam bleef eraan kleven omdat zijn beschrijvingen breed werden verspreid en makkelijk te citeren waren, niet omdat hij de enige bijdrager was. Het opgeslagen‑programma‑idee ontstond binnen een bredere gemeenschap (ingenieurs, wiskundigen en vroege programmeurs) die rond dezelfde tijd aan soortgelijke problemen werkte.
“Von Neumann‑architectuur” verwijst meestal naar een model met:
Het is een handig leslabel voor de organisatie met opgeslagen programma's, niet een claim over één historisch apparaat of een enige uitvinder.
In een von Neumann‑stijl ontwerp delen instructies en data één geheugen (en meestal één pad naar de CPU). In een Harvard‑stijl ontwerp is de instructieopslag gescheiden van de dataopslag (vaak met aparte paden).
Veel moderne systemen combineren de twee—bijvoorbeeld één logisch geheugenmodel voor software, maar aparte instructie‑ en data‑caches intern.
De “von Neumann‑bottleneck” is de prestatiegrens die kan ontstaan wanneer CPU en geheugen een beperkt pad delen voor zowel instructies als data. Veelvoorkomende mitigaties zijn caches, prefetching, en parallelisme (zoals meerdere cores), die het wachten verminderen maar de onderliggende beperking niet volledig wegnemen.
Omdat programma's simpelweg informatie zijn die in geheugen geladen kan worden, kun je gedrag wijzigen door software te updaten in plaats van chips te veranderen. Daarom kan dezelfde telefoon of laptop meerdere apps draaien en kunnen firmware/OS‑updates functies toevoegen zonder de hardware opnieuw te ontwerpen.
Aangezien instructies in geheugen als data worden weergegeven, proberen aanvallers soms onbetrouwbare data als uitvoerbare code te laten behandelen (bijv. code‑injectie). Moderne verdedigingsmaatregelen omvatten geheugenbescherming (niet‑uitvoerbare regio's), code‑signing en andere controles die ‘data die je mag lezen’ scheiden van ‘code die je mag uitvoeren’.
