In dit artikel betoogt de auteur dat het creëren van een succesvol alternatief voor de C-programmeertaal een enorme uitdaging is. Ondanks de opkomst van talen zoals Zig, Odin en Rust, blijft C dominant door verschillende factoren:
- De Toolchain: De enorme hoeveelheid volwassen instrumenten voor statische analyse en debugging is moeilijk te overtreffen.
- Risico's van nieuwe talen: Onzekerheden over bugs, semantische wijzigingen en de langetermijnonderhoudbaarheid schrikken bedrijven af.
- Menselijk kapitaal: Er is een veel grotere pool van ervaren C-ontwikkelaars beschikbaar.
- Interoperabiliteit: De C-ABI dient als de universele standaard voor communicatie tussen verschillende talen.
De auteur stelt dat 'schijnvoordelen' zoals een betere syntaxis of een lichte stijging in productiviteit onvoldoende zijn voor grootschalige adoptie. Voor een taal om C echt te kunnen vervangen, zijn 'killer features' nodig — unieke, onmisbare functionaliteiten die C niet kan bieden — of een sterke koppeling aan een specifiek, populair framework of product.
Het pleidooi tegen een C-alternatief
Net als verschillende anderen ben ik bezig met het schrijven van een alternatief voor de C-programmeertaal (voor wie deze blog volgt, is dat geen nieuws). Mijn taal, C3, is relatief nieuw, maar er zijn anderen: Zig, Odin, Jai en oudere talen zoals eC. Als we kijken naar alternatieven voor C++, zien we talen als D, Rust, Nim, Crystal, Beef, Carbon en anderen.
Maar is het wel mogelijk om C te vervangen? Laten we een aantal argumenten tegen deze gedachte overwegen.
1. De C-toolchain
De C-taal bestaat niet alleen uit de taal zelf, maar uit alle ontwikkelaarsinstrumenten die voor deze taal zijn gebouwd. Wilt u statische analyse uitvoeren op uw broncode? Daar wordt enorm veel aan gewerkt voor C. Hulpmiddelen voor het detecteren van geheugenlekken, data races en andere bugs? Die zijn er in overvloed, zelfs als uw nieuwe taal betere ingebouwde tooling heeft.
Wanneer u zich richt op een obscure hardware-architectuur, is de kans groot dat er vanuit gegaan wordt dat u C gebruikt. De status van C als de lingua franca van de huidige informatica maakt het zeer waardevol om tools voor te schrijven, waardoor het aanbod enorm is.
Als iemand een werkende toolchain heeft staan, waarom zou diegene dan het risico nemen om van taal over te stappen? Een "betere C" moet een aanzienlijke productiviteitswinst opleveren om de tijd die nodig is voor het opzetten van een nieuwe toolchain te rechtvaardigen — mits dat überhaupt mogelijk is.
2. De onzekerheden van een nieuwe taal
Voordat een taal volwassen is, is de kans groot dat er bugs in zitten en dat de taal significant kan veranderen om problemen met de semantiek op te lossen. En is de taal wel wat er beloofd wordt? Misschien wordt er gesproken over "geweldige compileertijden" of "sneller dan C", maar deze doelen blijken vaak moeilijk haalbaar zodra de taal een volledige set functionaliteiten krijgt.
En hoe zit het met de maintainers? Natuurlijk kan een open-source taal geforkt worden, maar ik betwijfel of veel bedrijven geïnteresseerd zijn in het gebruik van een taal die ze op termijn gedwongen zijn zelf te onderhouden. Inzetten op een nieuwe taal is een groot risico.
3. De taal is mogelijk simpelweg niet goed genoeg
Pakt de taal de werkelijke pijnpunten van C wel aan? Het blijkt dat mensen het niet altijd eens zijn over wat die pijnpunten precies zijn. Geheugenallocatie en de omgang met arrays en strings zijn vaak lastig, maar met de juiste bibliotheken en een degelijke geheugenstrategie kan dit worden geminimaliseerd. Als een taal problemen oplost waar gevorderde gebruikers zich eigenlijk geen zorgen over maken, is de werkelijke waarde veel lager dan verwacht.
Erger nog: wat als de taal cruciale functies weglaat die wel in C aanwezig zijn? Functies waar gevorderde C-programmeurs op vertrouwen? Dit risico neemt toe als de ontwerper van de taal niet veel ervaring heeft met C, maar voortkomt uit C++, Java, etc.
4. Gebrek aan ervaren ontwikkelaars
Een nieuwe taal heeft van nature een veel kleinere pool van ervaren ontwikkelaars. Voor elk middelgroot tot groot bedrijf is dat een enorm probleem. Hoe meer ontwikkelaars er beschikbaar zijn voor een bedrijf, hoe beter. Bovendien weet een bedrijf wel hoe het C-ontwikkelaars moet werven, maar niet hoe het dat moet doen voor een nieuwe, onbekende taal.
5. De C-ABI als standaard voor interoperabiliteit
Als een taal niet eenvoudig C-code kan aanroepen — of zelf door C-code kan worden aangeroepen — moet iedereen die de taal gebruikt extra werk verrichten voor vrijwel elke interfacing met externe code. Dit is potentieel een enorm nadeel.
---
Waarom "Beter X" niet relevant is
Bovenstaande zijn de nadelen van het niet kiezen voor C; deze moeten worden gecompenseerd door de voordelen van het alternatief. Echter, taalontwerpers overschatten vaak hoe groot de voordelen van hun extra "functies" zijn. Hier zijn enkele veelvoorkomende "schijnvoordelen":
Betere syntaxis
Een "betere syntaxis" dan C is grotendeels subjectief. Een andere syntaxis is bovendien een groot nadeel: u kunt geen code uit C kopiëren en moet mogelijk elke regel herschrijven. Geen enkel bedrijf zal een taal adopteren enkel omdat de syntaxis iets beter is dan die van C.
Veiliger dan C
Van elk C-alternatief wordt verwacht dat het qua prestaties op hetzelfde niveau zit als C. Het probleem is dat C praktisch geen controles uitvoert. Elke veiligheidscontrole die in een concurrerende taal wordt ingebouwd, heeft een kostprijs in runtime, wat vaak onacceptabel is. Dit leidt vaak tot een strategie waarbij controles alleen in een "veilige" modus actief zijn, terwijl de "snelle" modus net zo onveilig is als C.
Er zijn enkele uitzonderingen: foreach voorkomt dat men handmatig boundary-checks moet toevoegen en is dus automatisch veiliger. Op dezelfde manier helpen slices bij het schrijven van controles in vergelijking met "pointer + len" (of erger: null-terminated arrays).
Productiviteit van de programmeur
Bijna elke taal claimt een "hogere productiviteit voor de programmeur". Voor een bedrijf is dit echter meestal niet relevant. De reden is dat het eigenlijke programmeren niet de grootste tijdverslinder is. In een zakelijke context kost het meeste tijd om uit te zoeken wat de taak precies inhoudt. Een productiviteitsboost van 10% of 20% zal daarom nauwelijks merkbaar zijn. Zelfs een verdubbeling van de productiviteit is geen garantie voor succes.
---
Wat is wél relevant?
Als deze zaken niet tellen, wat dan wel? Voor een bedrijf gaat het erom of de taal, ondanks de nadelen, de bottom-line kan verbeteren: "Is dit waardevol genoeg om de nadelen te compenseren?"
Wat helpt dan wel? "Killer features": unieke verkoopargumenten die C niet kan bieden. Kijk naar Java; toen dit werd uitgebracht, bood het functies die de meeste concurrerende talen niet hadden:
- Objectgeoriënteerd programmeren (OO), op een nette manier uitgevoerd (OO was destijds erg populair).
- Threading direct uit de doos (ongebruikelijk in die tijd).
- "Write once, run anywhere".
- Code uitvoeren in de browser.
- Ingebouwde Garbage Collection.
- Netwerkprogrammering.
- Een goede standaardbibliotheek.
- Gratis te gebruiken.
Dat zijn niet één, maar acht killer features. Hoeveel van deze unieke verkoopargumenten hebben de C-alternatieven? In ieder geval minder dan Java destijds.
De volgende killer feature
Mijn stelling is dat talen vaak adoptie vinden door de enige taal te zijn die nodig is om iets specifieks te gebruiken: Dart voor Flutter, JS voor scripting in de browser, Java voor applets, ObjC voor Mac- en iOS-apps. Zelfs als deze monopolies in de loop der tijd verdwijnen, zorgt het ervoor dat de taal bekend wordt en gebruikt wordt.
Er zijn ook voorbeelden waarbij frameworks populair genoeg waren om talen een boost te geven; Ruby en Python zijn daar goede voorbeelden van. Kijkend naar onze voorbeeldtalen lijkt de strategie van Jai om een game-engine mee te leveren daarom goed: iedereen die de engine gebruikt, moet Jai leren. Als de engine goed genoeg is, zullen mensen dus ook de taal leren.
Maar afgezien van Jai: streeft enig ander C-alternatief er echt naar om killer features te hebben? En zo niet, hoe bewijst het dan dat de overstap van C de moeite waard is? Dat kan het niet.
Conclusie
Het idee van "bouw het en ze zullen wel komen" is verleidelijk, maar er is eerlijk gezegd weinig reden om C los te laten, tenzij het alternatief belangrijke unieke functies en/of producten heeft die C niet kan evenaren.
Hoewel populariteit en enthousiasme helpen, kunnen ze bewezen waarde niet vervangen. Uiteindelijk is het enige dat telt of het gebruik van een taal meer tastbare waarde oplevert voor ontwikkelaars dan C, voor ten minste een groot deel van de toepassingen waar C voor gebruikt wordt. Hoewel ontwikkelaars enthousiast kunnen zijn over nieuwe talen, vertaalt dat enthousiasme zich niet automatisch naar zakelijke waarde.
Kortom: hoe spannend dat C-alternatief er ook uit mag zien, de kans is groot dat het zal falen.
Het pleidooi tegen een C-alternatief
Net als verschillende anderen ben ik bezig met het schrijven van een alternatief voor de C-programmeertaal (voor wie deze blog volgt, is dat geen nieuws). Mijn taal, C3, is relatief nieuw, maar er zijn anderen: Zig, Odin, Jai en oudere talen zoals eC. Als we kijken naar alternatieven voor C++, zien we talen als D, Rust, Nim, Crystal, Beef, Carbon en anderen.
Maar is het wel mogelijk om C te vervangen? Laten we een aantal argumenten tegen deze gedachte overwegen.
1. De C-toolchain
De C-taal bestaat niet alleen uit de taal zelf, maar uit alle ontwikkelaarsinstrumenten die voor deze taal zijn gebouwd. Wilt u statische analyse uitvoeren op uw broncode? Daar wordt enorm veel aan gewerkt voor C. Hulpmiddelen voor het detecteren van geheugenlekken, data races en andere bugs? Die zijn er in overvloed, zelfs als uw nieuwe taal betere ingebouwde tooling heeft.
Wanneer u zich richt op een obscure hardware-architectuur, is de kans groot dat er vanuit gegaan wordt dat u C gebruikt. De status van C als de lingua franca van de huidige informatica maakt het zeer waardevol om tools voor te schrijven, waardoor het aanbod enorm is.
Als iemand een werkende toolchain heeft staan, waarom zou diegene dan het risico nemen om van taal over te stappen? Een "betere C" moet een aanzienlijke productiviteitswinst opleveren om de tijd die nodig is voor het opzetten van een nieuwe toolchain te rechtvaardigen — mits dat überhaupt mogelijk is.
2. De onzekerheden van een nieuwe taal
Voordat een taal volwassen is, is de kans groot dat er bugs in zitten en dat de taal significant kan veranderen om problemen met de semantiek op te lossen. En is de taal wel wat er beloofd wordt? Misschien wordt er gesproken over "geweldige compileertijden" of "sneller dan C", maar deze doelen blijken vaak moeilijk haalbaar zodra de taal een volledige set functionaliteiten krijgt.
En hoe zit het met de maintainers? Natuurlijk kan een open-source taal geforkt worden, maar ik betwijfel of veel bedrijven geïnteresseerd zijn in het gebruik van een taal die ze op termijn gedwongen zijn zelf te onderhouden. Inzetten op een nieuwe taal is een groot risico.
3. De taal is mogelijk simpelweg niet goed genoeg
Pakt de taal de werkelijke pijnpunten van C wel aan? Het blijkt dat mensen het niet altijd eens zijn over wat die pijnpunten precies zijn. Geheugenallocatie en de omgang met arrays en strings zijn vaak lastig, maar met de juiste bibliotheken en een degelijke geheugenstrategie kan dit worden geminimaliseerd. Als een taal problemen oplost waar gevorderde gebruikers zich eigenlijk geen zorgen over maken, is de werkelijke waarde veel lager dan verwacht.
Erger nog: wat als de taal cruciale functies weglaat die wel in C aanwezig zijn? Functies waar gevorderde C-programmeurs op vertrouwen? Dit risico neemt toe als de ontwerper van de taal niet veel ervaring heeft met C, maar voortkomt uit C++, Java, etc.
4. Gebrek aan ervaren ontwikkelaars
Een nieuwe taal heeft van nature een veel kleinere pool van ervaren ontwikkelaars. Voor elk middelgroot tot groot bedrijf is dat een enorm probleem. Hoe meer ontwikkelaars er beschikbaar zijn voor een bedrijf, hoe beter. Bovendien weet een bedrijf wel hoe het C-ontwikkelaars moet werven, maar niet hoe het dat moet doen voor een nieuwe, onbekende taal.
5. De C-ABI als standaard voor interoperabiliteit
Als een taal niet eenvoudig C-code kan aanroepen — of zelf door C-code kan worden aangeroepen — moet iedereen die de taal gebruikt extra werk verrichten voor vrijwel elke interfacing met externe code. Dit is potentieel een enorm nadeel.
---
Waarom "Beter X" niet relevant is
Bovenstaande zijn de nadelen van het niet kiezen voor C; deze moeten worden gecompenseerd door de voordelen van het alternatief. Echter, taalontwerpers overschatten vaak hoe groot de voordelen van hun extra "functies" zijn. Hier zijn enkele veelvoorkomende "schijnvoordelen":
Betere syntaxis
Een "betere syntaxis" dan C is grotendeels subjectief. Een andere syntaxis is bovendien een groot nadeel: u kunt geen code uit C kopiëren en moet mogelijk elke regel herschrijven. Geen enkel bedrijf zal een taal adopteren enkel omdat de syntaxis iets beter is dan die van C.
Veiliger dan C
Van elk C-alternatief wordt verwacht dat het qua prestaties op hetzelfde niveau zit als C. Het probleem is dat C praktisch geen controles uitvoert. Elke veiligheidscontrole die in een concurrerende taal wordt ingebouwd, heeft een kostprijs in runtime, wat vaak onacceptabel is. Dit leidt vaak tot een strategie waarbij controles alleen in een "veilige" modus actief zijn, terwijl de "snelle" modus net zo onveilig is als C.
Er zijn enkele uitzonderingen: foreach voorkomt dat men handmatig boundary-checks moet toevoegen en is dus automatisch veiliger. Op dezelfde manier helpen slices bij het schrijven van controles in vergelijking met "pointer + len" (of erger: null-terminated arrays).
Productiviteit van de programmeur
Bijna elke taal claimt een "hogere productiviteit voor de programmeur". Voor een bedrijf is dit echter meestal niet relevant. De reden is dat het eigenlijke programmeren niet de grootste tijdverslinder is. In een zakelijke context kost het meeste tijd om uit te zoeken wat de taak precies inhoudt. Een productiviteitsboost van 10% of 20% zal daarom nauwelijks merkbaar zijn. Zelfs een verdubbeling van de productiviteit is geen garantie voor succes.
---
Wat is wél relevant?
Als deze zaken niet tellen, wat dan wel? Voor een bedrijf gaat het erom of de taal, ondanks de nadelen, de bottom-line kan verbeteren: "Is dit waardevol genoeg om de nadelen te compenseren?"
Wat helpt dan wel? "Killer features": unieke verkoopargumenten die C niet kan bieden. Kijk naar Java; toen dit werd uitgebracht, bood het functies die de meeste concurrerende talen niet hadden:
- Objectgeoriënteerd programmeren (OO), op een nette manier uitgevoerd (OO was destijds erg populair).
- Threading direct uit de doos (ongebruikelijk in die tijd).
- "Write once, run anywhere".
- Code uitvoeren in de browser.
- Ingebouwde Garbage Collection.
- Netwerkprogrammering.
- Een goede standaardbibliotheek.
- Gratis te gebruiken.
Dat zijn niet één, maar acht killer features. Hoeveel van deze unieke verkoopargumenten hebben de C-alternatieven? In ieder geval minder dan Java destijds.
De volgende killer feature
Mijn stelling is dat talen vaak adoptie vinden door de enige taal te zijn die nodig is om iets specifieks te gebruiken: Dart voor Flutter, JS voor scripting in de browser, Java voor applets, ObjC voor Mac- en iOS-apps. Zelfs als deze monopolies in de loop der tijd verdwijnen, zorgt het ervoor dat de taal bekend wordt en gebruikt wordt.
Er zijn ook voorbeelden waarbij frameworks populair genoeg waren om talen een boost te geven; Ruby en Python zijn daar goede voorbeelden van. Kijkend naar onze voorbeeldtalen lijkt de strategie van Jai om een game-engine mee te leveren daarom goed: iedereen die de engine gebruikt, moet Jai leren. Als de engine goed genoeg is, zullen mensen dus ook de taal leren.
Maar afgezien van Jai: streeft enig ander C-alternatief er echt naar om killer features te hebben? En zo niet, hoe bewijst het dan dat de overstap van C de moeite waard is? Dat kan het niet.
Conclusie
Het idee van "bouw het en ze zullen wel komen" is verleidelijk, maar er is eerlijk gezegd weinig reden om C los te laten, tenzij het alternatief belangrijke unieke functies en/of producten heeft die C niet kan evenaren.
Hoewel populariteit en enthousiasme helpen, kunnen ze bewezen waarde niet vervangen. Uiteindelijk is het enige dat telt of het gebruik van een taal meer tastbare waarde oplevert voor ontwikkelaars dan C, voor ten minste een groot deel van de toepassingen waar C voor gebruikt wordt. Hoewel ontwikkelaars enthousiast kunnen zijn over nieuwe talen, vertaalt dat enthousiasme zich niet automatisch naar zakelijke waarde.
Kortom: hoe spannend dat C-alternatief er ook uit mag zien, de kans is groot dat het zal falen.
Groetjes,