Het artikel analyseert waarom bepaalde programmeertalen overleven terwijl andere verdwijnen. De centrale these is dat sociale en economische factoren zwaarder wegen dan puur technische verdiensten. De auteur stelt dat programmeren drie rollen combineert: een beroeping, een kunst en een baan.
Er wordt een cruciaal onderscheid gemaakt tussen twee soorten moeilijkheid:
- Wrijving (friction): Onnodige complexiteit of starre structuren die het werk bemoeilijken zonder rendement (bijv. Ada, COBOL), wat uiteindelijk leidt tot het uitsterven van de taal.
- De moeilijkheid van de viool: Een veeleisende maar belonende leercurve waarbij de uitdaging juist onderdeel is van de aantrekkingskracht (bijv. C++, Rust).
Aan de hand van een analogie met muziek (de sampler versus het echte instrument) concludeert de auteur dat talen niet verliezen door benchmarks, maar door het verliezen van mensen. Een taal overleeft enkel als hij het creatieve proces werkbaar en 'leuk' houdt.
Omdat het niet leuk genoeg is
Dat citaat vormt in feite de kern van dit artikel. Het is verrassend dat deze conclusie zo diep in de tekst begraven ligt; wellicht is het lastig om dit als leidende these te presenteren, omdat we de waarheid liever niet zo bot horen. Maar het is waar: de adoptie van een taal is niet puur technisch, maar een samenspel tussen techniek en menselijke factoren.
Alles in de twee delen voorafgaand aan dat citaat dient als bewijsmateriaal voor dit sentiment. De serie sorteert talen op resultaat: onsterfelijk, respectabel of gefaald. De interessantere sortering is echter op basis van de oorzaak van het overlijden. Deze oorzaken komen voort uit een simpele observatie die Peyton Jones samenvat en Oram omcirkelt: programmeren wordt gedaan door mensen, en voor die mensen is het tegelijkertijd drie dingen: een beroeping, een kunst en een baan.
Een taal dient iemand die al deze drie rollen vervult. Een taal of tool die een van deze drie onnodig moeilijk maakt, zal niet overleven op het moment dat er een alternatief beschikbaar komt.
- Een beroeping (vocation) is een roeping waar de wereld toevallig voor betaalt: iets wat iemand sowieso zou doen, met of zonder salarisstrook.
- Een kunst (art) is iets wat iemand doet uit liefde en (hopelijk) vaardigheid.
- Een baan (job) is het dagelijkse werk; hetgeen iemand doet om te kunnen eten, tv te kijken en een dak boven het hoofd te hebben.
Muzikanten leven elke werkdag met deze drievoudige identiteit: de coverset is de baan, de eigen composities zijn de kunst, en de beroeping is wat hen elke dag een instrument in de handen geeft, of ze nu geboekt zijn of niet. Programmeurs ervaren dit ook; we benoemen het alleen minder vaak hardop.
Als je de "lijken" op deze manier sorteert, ontstaat er een duidelijk beeld.
Waarom talen falen
Sommige talen faalden als baan: standaard Pascal werd geleverd zonder een bruikbaar string-type en Tcl kon programma's boven een bepaald gewicht niet dragen, waardoor het dagelijkse werk zwaarder was dan nodig.
Sommige faalden als kunst: Ada en PL/I werden voor programmeurs gekozen in plaats van door hen; het waren talen van mandaat, en niemand heeft ooit van een opgelegd mandaat gehouden.
Sommige faalden als beroeping: de arbeidsmarkt van Perl trok weg naar Python en kwam niet terug, en Haskell stelde zich beroemd genoeg ten doel om succes tegen elke prijs te vermijden—een doel dat het ook bereikte.
Verschillende ziekten, maar één pathologie: in elk geval maakte iemand een van de drie assen onnodig moeilijk, waardoor de mensen waarop de taal leunde vertrokken naar waar het makkelijker, leuker of werkbaarder was.
De anomalieën en overlevers
De stelling dat een taal die het leven moeilijk maakt niet overleeft zodra er een vervanger is, verklaart elke anomalie in de lijst van Oram.
JavaScript faalt als kunst voor een groot deel van de mensen die het schrijven, maar overleeft desondanks omdat het de belangrijkste algemene taal voor browsers blijft. Objective-C was onhandig als zowel kunst als baan, maar bloeide vijftien jaar lang omdat het de enige deur was naar het meest lucratieve ontwikkelaars-ecosysteem ooit gebouwd. Op het moment dat Swift verscheen, verdampte Objective-C en overleeft het nu slechts als een schaduw in zijn opvolger.
COBOL overleeft omdat vervanging te moeilijk en duur is—iets wat sommige bedrijven beginnen in te zien. Als zij slagen in hun vervangingsslag, is COBOL waarschijnlijk weg: het is een taal die 100% van de tijd werkt, maar waar het programmeren slechts voor ongeveer 1% leuk is. Ada overleeft vandaag de dag op plekken waar certificeringsregimes het vrijwel onvervangbaar hebben gemaakt. De moeilijkheidsgraad ervan is als een ontruimingsbevel dat klaar ligt; het wordt bezorgd op de dag dat er een alternatief verschijnt, en niet één dag eerder.
Twee soorten moeilijkheid
Dit brengt ons bij C++, die moeilijk én onsterfelijk is, wat in strijd lijkt met de bovenstaande redenering. Ook Rust is per ontwerp moeilijk, maar stijgt in populariteit. Het cruciale punt is dat er twee soorten moeilijkheid zijn.
De eerste soort is de moeilijkheid van de viool: precies, veeleisend, en gekozen omdat het precies en veeleisend is. Mensen doen aan codegolf in C++ als sport. Mensen schrijven essays over de dag dat de borrow checker eindelijk "klikte", vergelijkbaar met hoe strijkers praten over de dag dat vibrato geen strijd meer was. Moeilijkheid op zich is niet fataal; moeilijkheid zonder voldoende rendement is dat wel. C++ en Rust bieden dat rendement, net als de viool.
De andere soort is wrijving (friction): het compliance-apparaat van Ada, de ontbrekende onderdelen van standaard Pascal, of de precieze maar starre structurele syntax van COBOL die in werkelijkheid nauwelijks programmastructuur creëert. Niemand heeft ooit een essay geschreven over de dag dat de papierwinkel van Ada "klikte". Die moeilijkheid raakt alle drie de assen (baan, kunst, beroeping) zonder daar iets tegenover te stellen. In enquêtes worden Ada en C++ beide als "moeilijke talen" bestempeld, maar Ada sterft uit als standaardtaal terwijl C++ overleeft, omdat de "moeilijke" delen zich op verschillende assen bevinden.
De positie van Java
En waar is Java in dit geheel? Java is niet zo moeilijk als C++ of Rust, dus heeft het hun specifieke verdediging niet nodig. Op dit moment is het een soort onsterfelijk door een combinatie van nut en plezier, waarbij veel passie is teruggekeerd in het ecosysteem dankzij recente verbeteringen in packaging en features. Maar dat is een persoonlijke beslissing van de programmeur; ik denk dat we veilig kunnen stellen dat Java nog niet sterft, al is het lastig te zeggen waarom of wanneer. Ik leef zelf dagelijks in "Java-land", dus ik ben bevooroordeeld.
De analogie met muziek en code
Om terug te keren naar muziek: een moderne sampler kan elke noot en nuance van een viool reproduceren. Het is een encyclopedie van technieken en articulaties. Maar om de sampler dit daadwerkelijk te laten doen, is vaak meer werk nodig dan het simpelweg spelen van de viool zelf. De technische capaciteit was nooit de kwestie; het blijkt dat de beste manier om het geluid van een gespeelde viool te krijgen, daadwerkelijk de viool spelen is.
Dit is ook waarom code bestaat: een programma is een compacte specificatie voor gedrag, en gedrag beschrijven in proza kost meer moeite dan de notatie die speciaal voor dat werk is gebouwd.
Ik kan een computer gitaar voor me laten spelen, en ik kan het precies zo laten klinken als ikzelf speel—ik ken mijn eigen voorkeuren en accenten immers. Ik kan mijn spel gebaar voor gebaar, noot voor noot repliceren. Maar het is niet leuk. Helemaal niet. Het resultaat is prima, maar het doen is weg, en het doen was juist het punt. Er zit geen leven in, zelfs niet als ik randomisatie toevoeg of mijn eigen timing gebruik. Dit faalt langs dezelfde drie assen als alles wat we tot nu toe hebben besproken.
Voor degene die alleen de noten wil, wint de sampler de "baan" volledig; hij speelt nooit een verkeerde noot op het verkeerde moment. Maar voor de speler faalt het, omdat het aansturen van de machine meer kost dan het spelen zelf, en omdat het de "kunst" totaal niet raakt. Daarom grijp ik nog steeds naar de gitaar als ik gitaar in een track wil. De keuze is het punt.
De wet die programmeertalen sorteert, geldt ook voor hun opvolgers. Er is geen speciale uitzondering nodig... of toegestaan.
Dus: waarom stijgen en vallen programmeertalen? Peyton Jones zei het al. Talen verliezen niet door benchmark-gevechten; ze verliezen mensen. Ze stijgen wanneer ze de beroeping, de kunst en de baan lichter maken, en ze vallen op de dag dat iets anders hetzelfde gewicht kan dragen. Want op dat moment is de enige vraag die overblijft: is het leuk?
***
Een zijstap over Pascal: De term "mislukte start" is enigszins misleidend. Het commerciële leven van Pascal eindigde niet in het klaslokaal; het verplaatste zich naar Borland, waar Turbo Pascal en later Delphi meer dan een decennium lang de PC-ontwikkeling domineerden. De auteur van Turbo Pascal was Anders Hejlsberg, die daarna Delphi, C# en TypeScript bouwde. Tegelijkertijd liep de lijn van Wirth via Oberon naar Go (via zijn student Robert Griesemer). Pascal is niet zozeer gevallen als gemetaboliseerd, wat aansluit bij Oram's observatie dat sommige talen winnen door invloed in plaats van adoptie. Bovendien: ik hield van Pascal.
Voetnoten
- Dit werd enigszins verergerd door Larry Wall die besloot dat de doelpalen verschoven moesten worden: Perl bracht twee decennia door in afwachting van "Perl 6, elk moment kunnen we beginnen", waardoor Perl 6 uiteindelijk een volledig andere taal werd (Raku). Parrot, de VM die bedoeld was om het te dragen, stierf terwijl hij wachtte. Gebruikt iemand Raku eigenlijk wel? Ik moest zelfs opzoeken hoe het heette.
- Dit is onfair, en ik weet het! Het was "success-at-all-costs vermijden" in de zin van prioriteit, niet per se falen. Het betekende dat Haskell design-idiomen had die men niet bereid was op te offeren, enkel om populairder te worden.
- Vraag Java maar eens over talen die in de browser draaien! ... Doe het alleen niet in de browser, want Java draait daar niet native; je hebt een runtime zoals CheerpJ nodig of een compile-to-WebAssembly toolchain.
- Ada is fascinerend. Het is krachtig en verplicht in sommige omgevingen vanwege veiligheid en precisie. Maar ik heb nooit gewild dat ik het schreef, en de Ada-programmeurs die ik ken beschrijven het als een vereiste van de industrie eerder dan een keuze. Rust vervult dezelfde eisen minstens zo goed, maar mensen zijn gepassioneerd over het gebruik ervan. Niemand hoefde een inkooprichtlijn te schrijven om de borrow checker te realiseren. Ada verdiende zijn niche door dictaat; Rust verdient diezelfde niche door voorkeur.
- Ik probeerde onlangs weer wat Pascal te schrijven en het wasst echt amusement hoe veel ik was vergeten—en hoeveel van de moeilijkheden van Pascal waren opgelost door bedrijven als Borland die het bruikbaar probeerden te maken.
- Dit is absoluut waar. Veel elektronische muziek is gebouwd rond het repliceren van technieken uit menselijke handen in hardware: aftertouch, X-Y controllers, breath controllers, etc. Alles om te doen wat een goedkope gitaar in de handen van een redelijk bekwame gitarist kan doen.
- Dit is overigens waarom zoveel programma's worstelen: ze drukken specificaties uit die uiteindelijk onduidelijk zijn.
- De wet van Betteridge stelt dat elke kop die eindigt op een vraagteken beantwoord kan worden met "nee". De titel van Oram is een vraag. De titel van dit stuk is het antwoord. Titels zijn voor mensen; ik heb het gecheckt bij de persoon in mijn spiegel, en hij was het ermee eens.
Omdat het niet leuk genoeg is
Dat citaat vormt in feite de kern van dit artikel. Het is verrassend dat deze conclusie zo diep in de tekst begraven ligt; wellicht is het lastig om dit als leidende these te presenteren, omdat we de waarheid liever niet zo bot horen. Maar het is waar: de adoptie van een taal is niet puur technisch, maar een samenspel tussen techniek en menselijke factoren.
Alles in de twee delen voorafgaand aan dat citaat dient als bewijsmateriaal voor dit sentiment. De serie sorteert talen op resultaat: onsterfelijk, respectabel of gefaald. De interessantere sortering is echter op basis van de oorzaak van het overlijden. Deze oorzaken komen voort uit een simpele observatie die Peyton Jones samenvat en Oram omcirkelt: programmeren wordt gedaan door mensen, en voor die mensen is het tegelijkertijd drie dingen: een beroeping, een kunst en een baan.
Een taal dient iemand die al deze drie rollen vervult. Een taal of tool die een van deze drie onnodig moeilijk maakt, zal niet overleven op het moment dat er een alternatief beschikbaar komt.
- Een beroeping (vocation) is een roeping waar de wereld toevallig voor betaalt: iets wat iemand sowieso zou doen, met of zonder salarisstrook.
- Een kunst (art) is iets wat iemand doet uit liefde en (hopelijk) vaardigheid.
- Een baan (job) is het dagelijkse werk; hetgeen iemand doet om te kunnen eten, tv te kijken en een dak boven het hoofd te hebben.
Muzikanten leven elke werkdag met deze drievoudige identiteit: de coverset is de baan, de eigen composities zijn de kunst, en de beroeping is wat hen elke dag een instrument in de handen geeft, of ze nu geboekt zijn of niet. Programmeurs ervaren dit ook; we benoemen het alleen minder vaak hardop.
Als je de "lijken" op deze manier sorteert, ontstaat er een duidelijk beeld.
Waarom talen falen
Sommige talen faalden als baan: standaard Pascal werd geleverd zonder een bruikbaar string-type en Tcl kon programma's boven een bepaald gewicht niet dragen, waardoor het dagelijkse werk zwaarder was dan nodig.
Sommige faalden als kunst: Ada en PL/I werden voor programmeurs gekozen in plaats van door hen; het waren talen van mandaat, en niemand heeft ooit van een opgelegd mandaat gehouden.
Sommige faalden als beroeping: de arbeidsmarkt van Perl trok weg naar Python en kwam niet terug, en Haskell stelde zich beroemd genoeg ten doel om succes tegen elke prijs te vermijden—een doel dat het ook bereikte.
Verschillende ziekten, maar één pathologie: in elk geval maakte iemand een van de drie assen onnodig moeilijk, waardoor de mensen waarop de taal leunde vertrokken naar waar het makkelijker, leuker of werkbaarder was.
De anomalieën en overlevers
De stelling dat een taal die het leven moeilijk maakt niet overleeft zodra er een vervanger is, verklaart elke anomalie in de lijst van Oram.
JavaScript faalt als kunst voor een groot deel van de mensen die het schrijven, maar overleeft desondanks omdat het de belangrijkste algemene taal voor browsers blijft. Objective-C was onhandig als zowel kunst als baan, maar bloeide vijftien jaar lang omdat het de enige deur was naar het meest lucratieve ontwikkelaars-ecosysteem ooit gebouwd. Op het moment dat Swift verscheen, verdampte Objective-C en overleeft het nu slechts als een schaduw in zijn opvolger.
COBOL overleeft omdat vervanging te moeilijk en duur is—iets wat sommige bedrijven beginnen in te zien. Als zij slagen in hun vervangingsslag, is COBOL waarschijnlijk weg: het is een taal die 100% van de tijd werkt, maar waar het programmeren slechts voor ongeveer 1% leuk is. Ada overleeft vandaag de dag op plekken waar certificeringsregimes het vrijwel onvervangbaar hebben gemaakt. De moeilijkheidsgraad ervan is als een ontruimingsbevel dat klaar ligt; het wordt bezorgd op de dag dat er een alternatief verschijnt, en niet één dag eerder.
Twee soorten moeilijkheid
Dit brengt ons bij C++, die moeilijk én onsterfelijk is, wat in strijd lijkt met de bovenstaande redenering. Ook Rust is per ontwerp moeilijk, maar stijgt in populariteit. Het cruciale punt is dat er twee soorten moeilijkheid zijn.
De eerste soort is de moeilijkheid van de viool: precies, veeleisend, en gekozen omdat het precies en veeleisend is. Mensen doen aan codegolf in C++ als sport. Mensen schrijven essays over de dag dat de borrow checker eindelijk "klikte", vergelijkbaar met hoe strijkers praten over de dag dat vibrato geen strijd meer was. Moeilijkheid op zich is niet fataal; moeilijkheid zonder voldoende rendement is dat wel. C++ en Rust bieden dat rendement, net als de viool.
De andere soort is wrijving (friction): het compliance-apparaat van Ada, de ontbrekende onderdelen van standaard Pascal, of de precieze maar starre structurele syntax van COBOL die in werkelijkheid nauwelijks programmastructuur creëert. Niemand heeft ooit een essay geschreven over de dag dat de papierwinkel van Ada "klikte". Die moeilijkheid raakt alle drie de assen (baan, kunst, beroeping) zonder daar iets tegenover te stellen. In enquêtes worden Ada en C++ beide als "moeilijke talen" bestempeld, maar Ada sterft uit als standaardtaal terwijl C++ overleeft, omdat de "moeilijke" delen zich op verschillende assen bevinden.
De positie van Java
En waar is Java in dit geheel? Java is niet zo moeilijk als C++ of Rust, dus heeft het hun specifieke verdediging niet nodig. Op dit moment is het een soort onsterfelijk door een combinatie van nut en plezier, waarbij veel passie is teruggekeerd in het ecosysteem dankzij recente verbeteringen in packaging en features. Maar dat is een persoonlijke beslissing van de programmeur; ik denk dat we veilig kunnen stellen dat Java nog niet sterft, al is het lastig te zeggen waarom of wanneer. Ik leef zelf dagelijks in "Java-land", dus ik ben bevooroordeeld.
De analogie met muziek en code
Om terug te keren naar muziek: een moderne sampler kan elke noot en nuance van een viool reproduceren. Het is een encyclopedie van technieken en articulaties. Maar om de sampler dit daadwerkelijk te laten doen, is vaak meer werk nodig dan het simpelweg spelen van de viool zelf. De technische capaciteit was nooit de kwestie; het blijkt dat de beste manier om het geluid van een gespeelde viool te krijgen, daadwerkelijk de viool spelen is.
Dit is ook waarom code bestaat: een programma is een compacte specificatie voor gedrag, en gedrag beschrijven in proza kost meer moeite dan de notatie die speciaal voor dat werk is gebouwd.
Ik kan een computer gitaar voor me laten spelen, en ik kan het precies zo laten klinken als ikzelf speel—ik ken mijn eigen voorkeuren en accenten immers. Ik kan mijn spel gebaar voor gebaar, noot voor noot repliceren. Maar het is niet leuk. Helemaal niet. Het resultaat is prima, maar het doen is weg, en het doen was juist het punt. Er zit geen leven in, zelfs niet als ik randomisatie toevoeg of mijn eigen timing gebruik. Dit faalt langs dezelfde drie assen als alles wat we tot nu toe hebben besproken.
Voor degene die alleen de noten wil, wint de sampler de "baan" volledig; hij speelt nooit een verkeerde noot op het verkeerde moment. Maar voor de speler faalt het, omdat het aansturen van de machine meer kost dan het spelen zelf, en omdat het de "kunst" totaal niet raakt. Daarom grijp ik nog steeds naar de gitaar als ik gitaar in een track wil. De keuze is het punt.
De wet die programmeertalen sorteert, geldt ook voor hun opvolgers. Er is geen speciale uitzondering nodig... of toegestaan.
Dus: waarom stijgen en vallen programmeertalen? Peyton Jones zei het al. Talen verliezen niet door benchmark-gevechten; ze verliezen mensen. Ze stijgen wanneer ze de beroeping, de kunst en de baan lichter maken, en ze vallen op de dag dat iets anders hetzelfde gewicht kan dragen. Want op dat moment is de enige vraag die overblijft: is het leuk?
***
Een zijstap over Pascal: De term "mislukte start" is enigszins misleidend. Het commerciële leven van Pascal eindigde niet in het klaslokaal; het verplaatste zich naar Borland, waar Turbo Pascal en later Delphi meer dan een decennium lang de PC-ontwikkeling domineerden. De auteur van Turbo Pascal was Anders Hejlsberg, die daarna Delphi, C# en TypeScript bouwde. Tegelijkertijd liep de lijn van Wirth via Oberon naar Go (via zijn student Robert Griesemer). Pascal is niet zozeer gevallen als gemetaboliseerd, wat aansluit bij Oram's observatie dat sommige talen winnen door invloed in plaats van adoptie. Bovendien: ik hield van Pascal.
Voetnoten
- Dit werd enigszins verergerd door Larry Wall die besloot dat de doelpalen verschoven moesten worden: Perl bracht twee decennia door in afwachting van "Perl 6, elk moment kunnen we beginnen", waardoor Perl 6 uiteindelijk een volledig andere taal werd (Raku). Parrot, de VM die bedoeld was om het te dragen, stierf terwijl hij wachtte. Gebruikt iemand Raku eigenlijk wel? Ik moest zelfs opzoeken hoe het heette.
- Dit is onfair, en ik weet het! Het was "success-at-all-costs vermijden" in de zin van prioriteit, niet per se falen. Het betekende dat Haskell design-idiomen had die men niet bereid was op te offeren, enkel om populairder te worden.
- Vraag Java maar eens over talen die in de browser draaien! ... Doe het alleen niet in de browser, want Java draait daar niet native; je hebt een runtime zoals CheerpJ nodig of een compile-to-WebAssembly toolchain.
- Ada is fascinerend. Het is krachtig en verplicht in sommige omgevingen vanwege veiligheid en precisie. Maar ik heb nooit gewild dat ik het schreef, en de Ada-programmeurs die ik ken beschrijven het als een vereiste van de industrie eerder dan een keuze. Rust vervult dezelfde eisen minstens zo goed, maar mensen zijn gepassioneerd over het gebruik ervan. Niemand hoefde een inkooprichtlijn te schrijven om de borrow checker te realiseren. Ada verdiende zijn niche door dictaat; Rust verdient diezelfde niche door voorkeur.
- Ik probeerde onlangs weer wat Pascal te schrijven en het wasst echt amusement hoe veel ik was vergeten—en hoeveel van de moeilijkheden van Pascal waren opgelost door bedrijven als Borland die het bruikbaar probeerden te maken.
- Dit is absoluut waar. Veel elektronische muziek is gebouwd rond het repliceren van technieken uit menselijke handen in hardware: aftertouch, X-Y controllers, breath controllers, etc. Alles om te doen wat een goedkope gitaar in de handen van een redelijk bekwame gitarist kan doen.
- Dit is overigens waarom zoveel programma's worstelen: ze drukken specificaties uit die uiteindelijk onduidelijk zijn.
- De wet van Betteridge stelt dat elke kop die eindigt op een vraagteken beantwoord kan worden met "nee". De titel van Oram is een vraag. De titel van dit stuk is het antwoord. Titels zijn voor mensen; ik heb het gecheckt bij de persoon in mijn spiegel, en hij was het ermee eens.
Groetjes,