AI en de toekomst van systeemprogrammering

C++
Kris van Rens kijkt naar de toekomst van systeemontwikkeling en hoe het geluk van ontwikkelaars een belangrijk aspect is van software engineering

Kunstmatige intelligentie in het algemeen en grote taalmodellen (LLM’s) in het bijzonder veranderen ontegenzeggelijk de manier waarop we werken en code schrijven. Vooral voor het leren, uitleggen, refactoren, documenteren en reviewen van code blijken ze erg nuttig te zijn.

Voor mij is het genereren van productiecode door een LLM in chatstijl echter nog steeds een twijfelgeval. De zorgvuldig ontworpen prompt voor een complexe, beperkte taak is vaak vele malen groter dan de resulterende code, waardoor ik de productiviteitswinst in twijfel trek. Soms betrap ik mezelf erop dat ik de prompt iteratief moet bevechten om de juiste code voor mij te genereren, om er vervolgens achter te komen dat de prompt terloops is vergeten om een van mijn eerdere vereisten te implementeren. Soms ook genereren de LLM’s code met ongeldige constructies: ze hallucineren antwoorden, steevast met veel zelfvertrouwen. Sterker nog, gezien de manier waarop LLM’s werken, kunnen de antwoorden compleet anders zijn elke keer dat je een soortgelijke vraag invoert of in ieder geval sterk afhankelijk zijn van de gegeven prompt.

OpenAI medeoprichter Andrej Karpathy verwoordde het goed: “In zekere zin is hallucinatie alles wat LLM’s doen. Het zijn droommachines.” Dit schijnbaar ‘zwarte magie’ gedrag van LLM’s is enigszins onverenigbaar met mijn innerlijke tech-gedreven drang om een deterministisch proces te volgen. Misschien komt het door mijn volslagen incompetentie in prompt engineering, maar van waar ik sta, ondanks de kracht van generatieve AI binnen handbereik, moeten we nog steeds absoluut begrijpen wat we doen in plaats van blindelings te vertrouwen op de juistheid van de code die door deze droommachines is gegenereerd. Het vreemde gevoel en de eigenaardigheid van LLM’s zullen in de toekomst waarschijnlijk slijten, maar ik wil nog steeds graag de code begrijpen die ik produceer en waar ik verantwoordelijk voor ben.

Waarschijnlijk zal AI in het algemeen een abstractieverschuiving mogelijk maken in toekomstige softwareontwikkeling, waardoor we op een hoger abstractieniveau kunnen ontwerpen dan we nu vaak doen. Dit zou op zijn beurt de noodzaak om handmatig code te schrijven kunnen verminderen. Toch zie ik niet in hoe het gebruik van gegenereerde code in productie goed zal werken zonder de correctheidsgaranties van rigoureus testen en formele verificatie – dit is niet de realiteit van vandaag.

''An aspect of software engineering where LLMs can make an overall positive difference is interpreting compiler feedback.''

Positief verschil

Een ander toepassingsgebied van LLM’s is in-line code voltooiing in een editor/IDE. Zelfs dit is voor mij geen onverdeeld succes. Meer dan eens ben ik overweldigd door de LLM-gebaseerde code completer die een multiline oplossing voorstelt van wat hij denkt dat ik wilde typen. In plaats van het code-idee direct uit mijn verbeelding te implementeren, lees ik een klodder gegenereerde suggestiecode en vraag ik me af wat het doet en waarom. Het is raak en mis met deze aanvullingen en ze zetten me vaak op het verkeerde been. Ik heb de laatste tijd geëxperimenteerd met ingebedde ontwikkeling voor microcontrollers en ik heb gemerkt dat vooral met code in deze context, de LLM-gebaseerde aanvulling gewoon gissingen doet, soms zelfs onbestaande GPIO (general-purpose IO) pinnummers verzint. Ik hou wel van de combinatie van code completion LLM’s met een AI-model dat editorbewegingen voorspelt voor refactoring. Refactoren zijn vaak reeksen van vergelijkbare kleine bewerkingen die de modellen goed kunnen voorspellen.

Een aspect van software-engineering waar LLM’s een algemeen positief verschil kunnen maken, is het interpreteren van compilerfeedback. C++ is bijvoorbeeld berucht om zijn moeilijk te lezen en vaak erg lange compilerfouten. De komst van concepten in C++20 zou hier voor een drastische verbetering moeten zorgen, maar ik heb het niet zien gebeuren. Misschien is dit nog werk in uitvoering, maar tot die tijd moeten we het doen met complexe en vaak lange foutmeldingen (soms zelfs honderden regels lang). Vanwege hun vermogen om compilerberichten te interpreteren of samen te vatten, gecombineerd met hun educatieve en generatieve functies, zijn LLM’s met een groot contextvenster geschikt om dergelijke feedback te verwerken, waardoor ze een geweldig hulpmiddel zijn voor C++ ontwikkelaars. Er is een enorme hoeveelheid reeds bestaande C++ code en documentatie om van te leren, wat een goede basis vormt voor het trainen van een LLM.

Andere nadelen van C++ zijn de steeds toenemende complexiteit van de taal en de neiging van de compiler om te vechten in plaats van te helpen. Effectief gebruik van LLM’s om deze problemen te bestrijden zou de taal op korte termijn kunnen redden. De evolutie van de C++-taal gaat langzaam, maar het potentieel van de tools is enorm. Gezien de enorme hoeveelheid bestaande C++ code die vandaag de dag in gebruik is, is de taal een blijvertje en elk hulpmiddel dat ontwikkelaars helpt ermee te werken wordt gewaardeerd.

''To me, writing code is a highly creative, educational and enjoyable activity.''

Ontwikkelaarsgeluk

Het gebruik van LLM’s voor het genereren van code neemt voor mij ook een deel van het plezier in programmeren weg. Voor mij is het schrijven van code een zeer creatieve, leerzame en plezierige bezigheid, waarbij ik al doende mijn vaardigheden aanscherp; door een magische doos het werk voor mij te laten doen, gaat deze ervaring tot op zekere hoogte verloren – zelfs het handmatig schrijven van de saaie stukken en de tests heeft enige leerzame waarde.

Collega-ontwikkelaar Ger Cloudt beweert in zijn werk over softwarekwaliteit dat organisatorische kwaliteit, waarvan ontwikkelaarsgeluk een onderdeel is, het halve verhaal is. Volgens hem is organisatorische kwaliteit de sleutel tot ontwerp-, code- en productkwaliteit. Natuurlijk, schone code en architectuur zijn belangrijk, maar zonder de juiste hulpmiddelen, mentaliteit, cultuur, opleiding enzovoort, zal het ontwikkelingsproces uiteindelijk tot stilstand komen.

LLM’s helpen ongetwijfeld op het gebied van tools en opleiding, maar er komt meer kijken bij programmeren dan alleen code produceren als een robot. Een deel van het ambacht van software engineering – zoals bij elk ambacht – is het ervaren van plezier en trots in je werk en de resultaten die je produceert. Ik vind het maar raar, maar het geeft me enorm veel voldoening om met mijn eigen handen mooie code te maken.

De staat van Roest opnieuw bekeken

C++
Eind 2022 schreef Kris van Rens over de opkomst van de programmeertaal Rust, grotendeels in dezelfde toepassingsruimte die gedomineerd wordt door C en C++. Is het traditionele landschap van systeemprogrammering echt veranderd of was het allemaal veel gedoe om niets?

Volgens de Tiobe-index staat Python eenzaam aan de top van “populairste programmeertalen”, met een score van 23 procent. Het wordt gevolgd door C++ (10 procent), Java (ook 10 procent) en C (9 procent). De index probeert inzicht te krijgen in waar mensen naar zoeken in zoekmachines, waarbij de veronderstelling is dat dit een maatstaf is voor populariteit. Als relatief jonge taal scoort Rust de 14e plaats met iets meer dan 1 procent.

In een afsluitende samenvatting schrijft Tiobe CEO Paul Jansen over Rust dat “de steile leercurve er helaas nooit voor zal zorgen dat het de lingua franca van de gewone programmeur wordt.” Het noemen van de steile leercurve van een taal als barrière om een groot succes te worden voelt enigszins dubieus vanuit het perspectief van hoe populair C++ is in combinatie met de complexiteit op schaal. Ik denk ook dat het overschatten en benadrukken van een leercurve voor een taal ontwikkelaars tekort doet – veel bedrijven die Rust in productie nemen hebben al laten zien dat het heel goed te doen is.

''When it comes to learning in general, I always tend to keep a positive attitude: people are much more capable than we might think.''

Unieke prestatie

In de afgelopen jaren heeft Rust zich gevestigd als een waardig alternatief op het gebied van productie-grade systeemprogrammering. Het laat met succes zien hoe een taal tegelijkertijd modern, performant en veilig kan zijn. De taal komt elke zes weken uit, dus er is altijd wel iets nieuws – we zijn nu bij v1.85 op het moment van schrijven. Nieuwe functies worden gelanceerd wanneer ze klaar zijn en de meeste taal- of bibliotheekwijzigingen zijn meer fragmentarisch.

Naarmate Rust volwassener wordt, neemt de populariteit en het gebruik ervan geleidelijk toe. De risicofactor om Rust te kiezen als productietaal is uitgewerkt, zoals blijkt uit de vele bedrijven die erover rapporteren. Google heeft delen van Android herschreven in Rust voor een betere beveiliging, Microsoft herschrijft kernbibliotheken van Windows in Rust en Amazon gebruikt Rust al lange tijd in zijn AWS-infrastructuur.

Een andere unieke prestatie die het vermelden waard is, is dat Rust deel uitmaakt van de mainline Linux kernel naast C. Het moet gezegd worden dat de inspanningen om de ondersteuning voor Rust uit te breiden over kernelsubsystemen niet zonder slag of stoot gaan, maar er wordt vooruitgang geboekt met de zegen van Linus Torvalds. Het zal erg interessant zijn om te zien hoe dit experiment zich verder zal ontwikkelen.

''One of my main observations is that switching back from Rust to C++ makes me feel as if I’m being flung back into the dark ages of systems software development.''

Gelukkige ontwikkelaars

De afgelopen jaren heb ik Rust intensief gebruikt naast C++. Een van mijn belangrijkste observaties is dat het terugschakelen van Rust naar C++ me het gevoel geeft dat ik teruggeworpen word in de donkere eeuwen van systeemsoftwareontwikkeling. Dit klinkt misschien hard, maar eerlijk gezegd, zelfs als ik de nieuwste versie C++23 gebruik, voelen de meeste codeertaken moeizaam en beperkt vergeleken met hoe ze zouden zijn in Rust. In het begin miste ik soms de mogelijkheid om geschreven code direct te correleren aan machinecode zoals in C++, maar dit is in 99 procent van de gevallen strikt onnodig en moderne compilers zijn sowieso veel bekwamer in optimalisatie dan mensen.

Als het aankomt op het tooling ecosysteem en integratie, is Rust van een heel ander niveau en veel meer op de hoogte van de webontwikkelingswereld van vandaag. Waar de C++ taal en compiler me vaak tegenwerken om dingen goed te krijgen, lijken de strengheid, het type systeem, de gezonde defaults en de borrow checker van Rust me op een natuurlijke manier naar de juiste ontwerpbeslissingen te leiden – contend vs guide. Wanneer mijn Rust code succesvol bouwt en de testen slagen, kan ik het project verlaten met het geruststellende gevoel dat de software niet zal crashen tijdens runtime en dat de code niet gemakkelijk gebroken kan worden door een collega. Ook de Rust macro systemen en het uitstekende kwaliteit pakket ecosysteem met bibliotheken en plugin gereedschappen voor het bouwsysteem maken een groot verschil in productiviteit.

Deze en andere aspecten maken Rust erg prettig om mee te werken. Ze maken ontwikkelaars gelukkig. Er is een reden waarom het Stack Overflow ontwikkelaarsonderzoek Rust al negen jaar op rij als de meest gewenste programmeertaal laat zien.

Dividenden

Rust is zeer geschikt voor productiegebruik, zelfs in kritieke systemen die veiligheidscertificaten vereisen (bijvoorbeeld door gebruik te maken van de Ferrocene toolchain). Ik zie de adoptie ervan als een logische stap om nu al te genieten van de voordelen van geheugenveiligheid, hoge productiviteit en meer geluk voor ontwikkelaars, in plaats van te wachten tot de huidige set tools op snelheid is met de rest van de wereld. Voeg daar de kruisbestuiving aan toe om een betere ontwikkelaar te worden in elke andere programmeertaal door een nieuwe te leren.

Als het gaat om leren in het algemeen, heb ik altijd de neiging om positief te blijven: mensen zijn veel bekwamer dan we misschien denken. Ja, de leercurve voor Rust is steiler dan die van de meeste andere talen, maar het is de moeite waard en het loont op de lange termijn. Ik zou elke dag van de week een steile leercurve en meer gezonde en strikte taalregels en garanties verkiezen boven een leven met bugs in de geheugenveiligheid van software.

“Berekeningen die je in vijf minuten zou moeten kunnen maken op een bierviltje.”

precisiemachinebouw
Erik Manders en Marc Vermeulen nemen een leidende rol op zich in de training“Design Principles for Precision Engineering”(DPPE). Het duo neemt het stokje over van Huub Janssen, die zeven jaar lang het gezicht van de opleiding was. Deel twee van een tweedelige serie: training, trends en trainers.

Als het gaat om kennisdeling binnen de regio Eindhoven, geldt de opleiding“Design Principles for Precision Engineering” (DPPE) als een van de kroonjuwelen. De opleiding is in de jaren tachtig ontstaan binnen het Philips Center for Manufacturing Technology (CFT), waar de gerenommeerde professor Wim van der Hoek de basis legde met zijn constructieprincipes. Figuren als Rien Koster, Piet van Rens, Herman Soemers, Nick Rosielle, Dannis Brouwer en Hans Vermeulen bouwden erop voort.

De huidige DPPE-opleiding, die wordt aangeboden door Mechatronics Academy (MA) via het High Tech Institute, wordt ondersteund door meerdere experts. De hoofdrolspelers onder hen hebben de speciale taak om de trends in de industrie in de gaten te houden. “Onze hoofdrolspelers signaleren trends, nieuwe onderwerpen en best practices in precisietechnologie”, zegt Adrian Rankers, partner bij Mechatronics Academy en verantwoordelijk voor de DPPE-training.

Gevraagd naar zijn ‘vingerafdrukken’ op de DPPE-opleiding, verwijst Janssen naar zijn grote inspirator, Wim van der Hoek. “Ik ben geen docent en ook geen professor met lange verhalen. Ik hou ervan om een casus neer te leggen, er samen aan te werken en er dan over te discussiëren. Met Van der Hoek zaten we rond een groot wit vel papier en dan werden de problemen op tafel gelegd.”

Virtueel spelen

Janssen zegt dat hij als hoofdrolspeler de DPPE-training vorm kon geven. Hij koos ervoor om deelnemers meer praktijkopdrachten te geven en die casussen in de klas te bespreken. Rankers: “,,Meteen vanaf de eerste ochtend. Nadat we het concept virtual play hebben uitgelegd, vragen we de deelnemers ermee aan de slag te gaan.” Janssen: “Iedereen denkt na onze uitleg: Ik heb het door. Maar als ze de eerste schetsen op papier zetten, blijkt het nog niet zo eenvoudig. Daar gaat het om: want als ze zelf gaan rekenen, blijft het echt hangen.”

Op de laatste dag van de opleiding krijgen de deelnemers de opdracht om in groepjes van vier een optische microscoop te ontwerpen. Janssen: “Ze krijgen de specificaties: de positioneertafel met een slag van enkele millimeters, een specifieke resolutie, stabiliteit binnen een tiende van een micrometer in een minuut, etc. Alles wat in dit geval aan de orde komt, is in de dagen ervoor al besproken: plasticiteit, wrijving, thermisch centrum en meer.”

Vermeulen: “Het leuke is dat mensen moeten samenwerken, anders redden ze het niet.”

Janssen: “We schuiven vier tafels bij elkaar en ze moeten echt met z’n vieren als team werken. Dan zie je sommige mensen grijpen naar superstabiele Zerodur of elektromagnetische geleiding of een luchtlager, en iemand anders zegt: ‘Denk ook aan het kostenaspect.'”

'With Wim van der Hoek, we would all sit around a large white sheet of paper, and then the problems would be laid on the table.''

Niet gemakkelijk

Deelnemers ervaren de moeilijkheidsgraad heel verschillend, ongeacht hun opleidingsachtergrond, merkt Janssen op: “Het hangt af van hun voorkennis, maar het is voor iedereen een uitdaging. Mensen zijn bijna altijd hoog opgeleid, maar als ze met een ontwerp moeten komen, weten ze vaak niet of ze het van links of rechts moeten benaderen.”

Hij gelooft echter dat het geen raketwetenschap is. “Het is niet ingewikkeld. Het gaat om berekeningen die je in vijf minuten op een bierviltje zou moeten kunnen doen.”

Alle vier zijn ze het erover eens dat het gaat om gevoel krijgen voor het materiaal. “Je moet het ook kunnen kwantificeren, snel kunnen berekenen,” benadrukt Vermeulen.

Janssen biedt een eenvoudig gedachte-experiment aan: “Neem twee elastiekjes. Houd ze parallel en trek eraan. Knoop ze dan in serie en trek opnieuw. Wat is het verschil? Wat gebeurt er? Waar moet je het hardst aan trekken om ze een paar centimeter uit te rekken? Niet iedereen begrijpt dat intuïtief.”

Rankers: “Het is een combinatie van creativiteit en analytisch vermogen. Je moet iets bedenken en dan wat ruwe berekeningen maken om te zien hoe het uitpakt. Sommige mensen benaderen het analytisch, anderen kunnen fantastisch construeren. Ze weten misschien niet precies waarom het werkt, maar ze hebben er een goed gevoel voor.”

Rekentools

Creativiteit en ontwerpintuïtie kunnen niet worden vervangen door rekentools, daar zijn ze het allemaal over eens. “Je kunt een computer de berekeningen laten doen,” zegt Janssen, “maar dan moet je het nog steeds beoordelen. Wat als het niet klopt? Er zijn duizenden parameters die je kunt aanpassen. Het gaat om gevoel voor constructie, weten waar de pijnpunten zitten. Daar heb je geen rekenprogramma voor nodig.”

''For every design question, you must go all the way back to the beginning, keep your feet on the ground, and start simple.''

Manders: “We praten over het spreekwoordelijke bierviltje omdat je in een paar minuten een eerste schets of berekening wilt maken. Als je een computer laat rekenen, ben je dagen bezig. Het bouwen van een eerste model kost veel tijd. Maar een goede constructeur kan die berekening in een paar minuten op papier zetten. Als je daarna een uur bezig bent, heb je een goed gevoel welke kant het op gaat. Ik denk dat dat de kern is van de cursus constructieprincipe: eenvoudige berekeningen, niet te ingewikkeld, een richting kiezen en kijken waar het heen gaat.”

Wit vel papier

Manders merkt op dat zeer analytische mensen vaak bang zijn om de eerste regels op een leeg vel papier te zetten. Om met een concept te beginnen. “Vaak zijn ze zo gefocust op de details dat ze meteen vastlopen. Creatieven beginnen te tekenen en zien wel waar het heen gaat.”

Voor Manders is training een manier om verbonden te blijven met de bouwsector. “In mijn carrière heb ik me uitgebreid naar meer gebieden, ook in de richting van mechatronica. Maar mijn ankerpunt is fijnmechanica. Door opleidingen te volgen, kan ik mijn kennis verdiepen en mensen vertellen over de basis. Het scherpt mijzelf ook. Constructieprincipes op net iets andere manieren uitleggen helpt me in mijn coachende baan.”

Tijdens de training leert hij vaak nieuwe dingen. “Dan krijg ik vragen die me echt aan het denken zetten. Als het echt moeilijk is, kom ik er buiten de cursus op terug. Dan puzzel ik het thuis uit en maak ik een back-up dia voor de volgende keer.”

Vermeulen zegt dat hij veel voldoening haalt uit het opleiden van een nieuwe generatie technici. “Dat geeft me energie. Voor de huidige groei in hightech is het ook nodig om kennis te delen. Dat geldt voor ASML, maar ook voor VDL en andere toeleveranciers. Als we onze kennis niet doorgeven, lopen we allemaal tegen een muur.”

''We could emphasize considering the costs of production methods more.''

Tevredenheid

Janssen merkt op dat een zekere vooringenomenheid of zelfgenoegzaamheid vaak voorkomt bij ontwerpers. “Als er veel ASML-deelnemers in de klas zitten, halen ze meteen een magnetisch lager tevoorschijn als we vragen om wrijvingsloze beweging. Maar in sommige gevallen volstaan een luchtlager of twee rollen. Ik overdrijf, maar ontwerpers hebben soms een vooroordeel vanwege hun eigen ervaring of werkomgeving. Bij elke ontwerpvraag moeten ze echt terug naar de basis, met de voeten op de grond, en eenvoudig beginnen.”

Vermeulen: “De eenvoudigste oplossing is meestal de beste. Veel ontwerpers zijn niet zo opgeleid. Ik zie vaak kopieergedrag. Maar de ontwerpkeuze die ze hun buurman zien maken, is niet noodzakelijk de beste oplossing voor hun eigen probleem. Je kunt prima een stalen plaat gebruiken in plaats van een complexe bladveer. Het werkt beide kanten op, maar als je voor de dure optie kiest, kun je daar maar beter een goede reden voor hebben.”

Kwart

“Het is altijd leuk om te zien hoe Marc begint”, zegt Rankers over Vermeulens aanpak in de training. “Als hij het over luchtlagers heeft, vraagt hij de deelnemers of ze die gebruiken, wat hun grootste uitdaging is, waar ze tegen problemen aanlopen. In een kwartiertje verdiept hij zich in het onderwerp en weet hij wat hen bekend voorkomt. Wie weet veel, wie weet niets of wie gaat er binnenkort mee werken in een project.”

Vermeulen: “In mijn voorbeschouwing neem ik het hele materiaal door zonder er diep in te duiken. Dat proces geeft me energie. Eigenlijk is de hele klas gemotiveerd, maar de uitdaging is om ze er in het begin echt bij te betrekken. Je kent elkaar nog niet. Maar ik wil ze als het ware kunnen lezen, om ze erbij te betrekken. Ze moeten gretig zijn, op het puntje van hun stoel zitten.”

Het gaat dus niet om de dia’s, benadrukt Vermeulen nogmaals. “Het gaat erom dat deelnemers met hun eigen vragen komen. Ze hebben allemaal bepaalde dingen in hun hoofd en vragen zich af hoe ze dat voor elkaar kunnen krijgen.” Dat is de reden voor de uitgebreide vragenronde aan het begin. “Ik vraag naar de verschillende thema’s die ze tegenkomen. Vervolgens gebruik ik dat als raamwerk. Als er een slide over een door hen genoemd onderwerp komt, ga ik daar een beetje op in. Dat maakt het voor hen veel gemakkelijker om te volgen. Ze blijven gefocust.”

Basistraining

DPPE is een basistraining. Manders en Vermeulen verwachten geen grote veranderingen in de behandelde stof, al zien ze wel mogelijkheden om de inhoud actueler te maken.

Deelnemers moeten echter nog steeds fundamentele kennis en principes leren. Janssen over stijfheid, speling en wrijving – de onderwerpen die hij onderwijst: “Ik besteed daar anderhalve dag aan, maar het zijn drie cruciale dingen. Als je deze niet begrijpt, zul je nooit een goede ontwerper worden. Dat is de basis.” Concepten als passieve demping komen even ter sprake, maar dat is een complex onderwerp. Geen wonder dat Mechatronics Academy daar een aparte driedaagse training voor aanbiedt.

Het onderwerp “vrijheidsgraden” dat Manders onderwijst is een ander fundamenteel element. “Dat kost gewoon wat tijd. Je moet er doorheen”, zegt Manders.

Vermeulen: “Dan komt de vertaling naar hardware. Als deelnemers eenmaal bekend zijn met vonkerosie, moeten ze de creativiteit hebben om in sommige gevallen naar goedkopere oplossingen te grijpen. We zouden meer nadruk kunnen leggen op het kritisch beoordelen van de kosten van de productiemethode. Als je met vonkerosie in één systeem een mate van vrijheid krijgt, moet je de volgende keer niet automatisch naar die dure productiemethode grijpen. We zouden ons meer kunnen verdiepen in die vertaling naar hardware. Ook daar is het goed om eenvoud na te streven.”

''The core is simple calculations, not too complicated, choose a direction and see where it leads.''

Overgedetermineerd

Wim van der Hoek keek trouwens ook kritisch naar de kosten. Rankers: “Een mooie uitspraak van hem was dat veel kosten in de assemblage worden veroorzaakt doordat dingen te gedetermineerd zijn.”

De termen “bepaald” of “overdetermineerd” in precisieconstructies verwijzen hier in wezen naar: Een star lichaam heeft zes vrijheidsgraden (3 translaties en 3 rotaties) die zijn positie en oriëntatie volledig bepalen. Als je dat object in één richting wilt bewegen met een actuator, moet je de andere vrijheidsgraden vastzetten met een rollager, luchtlager of bladveerconfiguratie.

Als je als ontwerper een configuratie van beperkingen kiest die meer dan vijf vrijheidsgraden vastlegt, kunnen de beperkingen elkaar verstoren. Rankers: “Dat heet statisch overdetermineerd, en je kunt geluk hebben als het werkt, zolang alles maar netjes uitgelijnd is. De mensen die dat doen hebben ‘gouden handen’, zoals Wim van der Hoek het uitdrukte. Maar de nette uitlijning kan niet veranderen, zoals bij thermische uitzettingsverschillen.” Vooral de gradiënten en verschillen in uitzetting van verschillende componenten spelen een grote rol.

Rankers: “Het is natuurlijk onmogelijk om alles perfect op elkaar af te stemmen. Het verandert ook na verloop van tijd tijdens het gebruik. Dus ontstaan er interne krachten binnen het object dat je wilde vasthouden of positioneren door het ‘vechten’ tussen de beperkingen. Als dat object een delicaat stukje optica is dat niet mag vervormen, heb je een groot probleem. Dat betekent dat je overdeterminatie moet vermijden in ultraprecieze machines.”

Vermeulen: “Dus als je het zo ontwerpt dat het beter gedetermineerd is, is het gemakkelijker te monteren en dat geeft je een brug naar de kosten.”

Rankers merkt ook op dat het kostenaspect meer aandacht moet krijgen dan voorheen. Hij denkt dat gastsprekers de training kunnen verrijken met praktijkvoorbeelden. Voorbeelden laten zien van betaalbare en dure versies. Vermeulen geeft meteen een voorbeeld waarbij je een lens moet geleiden. “Als je een normale lineaire geleider maakt, zakt de lens een beetje op de nanometerschaal. Dat kun je compenseren met een tweede geleider, maar dan is de oplossing misschien wel twee keer zo duur en twee keer zo complex. Is dat echt nodig? Dus als ontwerper kun je de optica-ingenieur uitdagen: ‘Je wilt het perfect maken, maar dat kost veel geld. We moeten op deze dingen letten.'”

Dit artikel is geschreven door René Raaijmakers, tech-redacteur van Bits&Chips.

Recommendation by former participants

By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 9.5 out of 10.

De magie van Precisietechniek

precisiemachinebouw
Erik Manders en Marc Vermeulen nemen een leidende rol op zich in de opleiding “Design Principles for Precision Engineering” (DPPE). Het duo neemt het stokje over van Huub Janssen, die zeven jaar de leiding had. Deel één van een tweedelige serie: trends in constructieprincipes.

Precisietechnologie is geen vaststaand concept; deze gereedschapskist voor hightech ingenieurs evolueert in de loop van de tijd. Om hier inzicht in te krijgen nodigde High Tech Systems magazine Huub Janssen, Erik Manders, Adrian Rankers en Marc Vermeulen uit voor een gesprek over de wereld van precisie, de veranderende trends en eisen in hightech en hoe het is om in dit vakgebied te werken. In het tweede deel gaan we dieper in op de impact hiervan op de Design Principles for Precision Engineering (DPPE) training.

Manders en Vermeulen zijn net als Janssen al tientallen jaren actief in de hightech, al verschillen hun rollen en interesses. Janssen is eigenaar van een hightech ingenieursbureau en was zeven jaar lang het boegbeeld van de DPPE-opleiding. Het nieuwe duo dat de grote lijnen uitzet werkt nu bij ASML, Manders als Principal Systems Architect voor Mechatronics en Vermeulen als Principal Mechanical System Architect. Adrian Rankers, voorheen werkzaam als Head of Mechatronics Research bij Philips CFT, is nu partner bij Mechatronics Academy (MA) en verantwoordelijk voor de DPPE-opleiding die MA aanbiedt via het High Tech Institute.

 

“Dertig jaar geleden was het positioneren op de micrometer een vakgebied van een andere planeet”, zei Janssen in 2019 toen hij het gezicht werd van de DPPE. Toen hij halverwege de jaren tachtig afstudeerde, werkten ontwerpers nog met micrometers. “In de loop der jaren is dit verschoven naar nanometers”, constateert hij vandaag.

Sinds het begin van de jaren negentig ontwikkelt hij met zijn bedrijf JPE mechatronische modules voor hightech, wetenschappelijke instrumenten voor onderzoek en meer recentelijk systemen voor kwantumcomputers. “Als je nu met die natuurkundigen praat, hebben ze het zonder blikken of blozen over picometers. Voor mij voelt dat bijna filosofisch aan.”

Erik Manders en Marc Vermeulen zijn als trainers al jaren betrokken bij de training Design Principles for Precision Engineering. De training is oorspronkelijk ontwikkeld bij het Philips Center for Manufacturing Technology (CFT), waar beiden hun carrière zijn begonnen. Vermeulen maakt al enkele jaren deel uit van een groep DPPE-trainers van Mechatronics Academy. Manders gaf de cursus jarenlang samen met Herman Soemers bij Philips Engineering Services, totdat de mechatronicagroep van deze activiteit in 2023 werd overgedragen aan ASML.

Niet eenvoudig

Het concept precisietechnologie is moeilijk te definiëren. Het is een gereedschapskist die ontwerpers veel ruimte biedt voor creativiteit. Geef tien ontwerpers hetzelfde probleem en je krijgt verschillende oplossingen die variëren in richting en detail. De ontwerpbenadering verschilt sterk afhankelijk van de toepassing, maar is ook onderhevig aan trends en veranderende vereisten. Over een paar jaar kunnen de vereisten en benaderingen nauwelijks veranderen, maar kijk tien jaar vooruit en de ontwerpen en methoden die worden gebruikt om ze te realiseren, kunnen totaal anders zijn.

''You keep running into new physical phenomena that previously had no influence and suddenly appear.''

Interferometerophanging

Er is geen heilige graal of universele ontwerpregel in precisietechnologie. Best practices verschillen per markt, systeem of toepassing. Huub Janssen ontdekte dit toen hij net van school kwam bij ASML. “In het begin leerde ik van Wim van der Hoek om iets statisch bepaald te bouwen”, zegt hij. “Maar bij ASML ontdekte ik dat deze aanpak niet altijd werkte. Voor de PAS2500 waferstepper ontwikkelden we in eerste instantie een nieuwe interferometerophanging om de positie van de tafel in de x- en y-richting te meten. Dit ontwerp volgde de principes van Van der Hoek, met elastische elementen enzovoort. Maar toen we het testten, ontdekten we dat er geen demping was. Het is reproduceerbaar, maar alles bleef trillen. Het was een ramp. Ik leerde dat je bepaalde constructieprincipes van Van der Hoek niet zomaar overal kunt toepassen; je moet weten wanneer je ze moet gebruiken.”

Toenemende eisen

De steeds hogere eisen voor precisie beïnvloeden de ontwerpkeuzes sterk. Vermeulen legt uit: “Met toenemende nauwkeurigheid neemt de complexiteit toe. Elke keer moet je het probleem een beetje verder afpellen. Je stuit voortdurend op nieuwe fysische fenomenen die er eerder niet toe deden, maar nu wel een impact hebben. Je moet dan tot de kern komen: wat gebeurt hier fysisch?”

Vermeulen geeft als voorbeeld de toepassing van passieve demping op de korte slag wafertrap van lithografische scanners. ‘Dat was een behoorlijke horde die we rond 2015 moesten nemen, want wat je ontwerpt moet voorspelbaar zijn. Als je denkt in termen van stijfheid en massa, is dat nog steeds mogelijk. Maar in het begin wisten we niet hoe een demper zich zou gedragen.

Zou het verouderen? Kruipen? Dat moesten we volledig begrijpen. Dat betekende dat we moesten modelleren hoe demping de dynamica beïnvloedt. In het begin lukte dat niet, maar toen we het eindelijk goed hadden, konden we de metingen en het model op elkaar afstemmen. Pas toen we er redelijk zeker van waren dat we het begrepen, konden we de volgende stap zetten. Als je dit niet goed doet, blijft het giswerk, kun je het gedrag niet goed voorspellen en kom je later voor verrassingen te staan.

Een ander voorbeeld zijn problemen die kunnen ontstaan bij het verhogen van de productiviteit. Vooral met watergekoelde componenten is het een uitdaging om dit onder controle te houden. Iedereen kent het knappen van de waterleiding als je snel een kraan dichtdraait. Op dezelfde manier creëert versnelling drukgolven in systemen met waterkoeling. ‘Die golven moet je dempen, want drukpulsen veroorzaken vervorming’, zegt Vermeulen, ‘je moet begrijpen hoe dat werkt.’

Manders voegt hieraan toe: “Op een micrometerschaal zou je dit niet merken, maar op een nanometerschaal vervormt zelfs een glazen blok als de druk verandert. Dit is een fysiek probleem op systeemniveau.”

Eenvoud

De belangrijkste benadering is het streven naar eenvoud. Dit leidt tot robuuste en kosteneffectieve constructies. Maar er is nog een belangrijke reden om dingen eenvoudig te houden. Als een gekozen oplossing eenmaal is ingebed in een product, zullen ontwerpers die erop voortbouwen dat subsysteem niet snel veranderen. “Als je kiest voor complexiteit, zul je die nooit kunnen verwijderen,” vat Rankers samen. “Als je eenvoud niet vanaf het begin afdwingt, zul je ermee blijven worstelen. Het zal aan je blijven knagen.”

Janssen: “Als het werkt, durft niemand eraan te komen. Als je reserves inbouwt, zal niemand later voorstellen om ze te verwijderen. Want iedereen zal tegenspreken: ‘Weet je zeker dat het dan nog werkt? Je kunt wel raden wat de uitkomst zal zijn.'”

Vermeulen: “Precies. Niemand durft terug te gaan. Je begint met een ontwerp, zet een proefopstelling op en als het zich min of meer bewezen heeft, ga je ermee door.”

Manders: “Je moet complexe aanpassingen of kalibraties vermijden, want die gaan nooit meer weg. Het projectteam dat daarna komt, zal zeggen: ‘We kopiëren dit gewoon omdat het werkt. We doen het op dezelfde manier.'”

Dit zijn moeilijke beslissingen, zegt Janssen. Ontwerpkeuzes kunnen sterk variëren en zijn afhankelijk van de toepassing en de markt. “Voor halfgeleiderapparatuur wil je alles honderd keer opnieuw berekenen voordat je de machine bouwt. Ontwerpers kunnen enige reserve inbouwen om de constructie te laten werken. Maar kleine marges in verschillende budgetten maken een oplossing soms onmogelijk of te ingewikkeld. Soms moet je echt alles uit de kast halen om dat laatste beetje precisie te bereiken. Maar als het eenmaal klaar is, kun je niet meer terug.”

Bij zijn bedrijf JPE moedigt Janssen zijn ontwerpers aan om soms meer risico’s te nemen. “Het kan vaak goedkoper. Iets wat dunner en iets minder stijf is, kan sneller en goedkoper worden afgewerkt. Maar je moet het echt durven.”

Manders: “Maar soms kost reserve bijna niets. Door slim te ontwerpen kan vaak nauwkeurigheid worden bereikt zonder veel extra productiestappen te doorlopen. Bijvoorbeeld door slim te kijken of je meerdere vlakken in één opstelling kunt frezen en gebruik kunt maken van de zeer nauwkeurige freesmachines van tegenwoordig. Het is in ieder geval belangrijk om er gevoel voor te ontwikkelen.”

''The process of creating a design is magical. You just can’t design the more complex modules alone.''

Systeemarchitect

Manders begon bij Philips CFT als ontwerper. De laatste jaren had hij een meer coachende rol als systeemarchitect op de mechatronica-afdeling van Philips Engineering Services, dat in 2023 overgaat in ASML, en werkte hij met een team van zo’n honderd collega’s en technici bij leveranciers. “Ja, dan heb je veel reviews.”

Hij ziet zijn rol als “het overzicht bewaren tussen de disciplines”. “Ik probeer het cement tussen de stenen te zijn. Uiteindelijk moet het functioneren. Dat is het spel.”

Twintig ballen

Janssen koos ervoor om al vroeg in zijn carrière een eigen bedrijf te beginnen, Janssen Precision Engineering, later JPE. Manders en Vermeulen werken daarentegen in een grotere organisatie waar ze moeten afstemmen met veel collega’s en leveranciers. “Ik moet twintig ballen in de lucht houden met uitdagende techniek,” beschrijft Janssen, die zijn baan ook als hobby ziet. “Ondertussen moet ik kijken naar wat de markt nodig heeft. We zijn geen groot bedrijf, maar we hebben wereldwijd een grote impact.”

Hoe is het in een veel grotere organisatie als ASML? Vermeulen zegt: “Iemand die net in dienst is gekomen, werkt aan een heel klein onderdeel. De uitdaging is om hen te helpen begrijpen hoe hun bijdrage past in het grotere geheel.”

Manders voegt eraan toe: “Duizenden mensen werken aan onze machines. Je kunt het als nieuwkomer niet meteen bevatten. De complexiteit is overweldigend.”

De oprichters van ASML hadden volgens Manders het voordeel dat ze met eenvoudigere apparaten begonnen. “Die konden ze beter begrijpen en dat was hun ankerpunt toen de machines complexer werden. Mensen die er later bij komen, kunnen niet meteen het hele plaatje zien. Mensen die pas beginnen met werken, zien in het begin door de bomen het bos niet meer. Ze moeten erin groeien en gaandeweg de context ontdekken.”

Geleider

In zo’n groot team heeft iedereen zijn rol. “Wat de servologen en stromingsdynamica-experts in mijn team berekenen, zou ik zelf niet kunnen”, zegt Manders, die zichzelf meer als dirigent ziet. “Ik probeer minder ervaren collega’s richting en gevoel voor de context te geven. Waarom doen we dit? Waar gaan we naartoe? Je probeert het team samen te laten spelen en iets moois te laten creëren. Maar een goed orkest speelt in wezen op zichzelf.”

Rankers voegt eraan toe: “In je eentje kun je deze complexe modules niet tot een goed einde brengen. Het is als een voetbalteam. De coach scoort ook geen doelpunten.”

Vermeulen erkent dit. “Ik ben verantwoordelijk voor de technologie, maar ook voor hoe we samenwerken. Dat is waarschijnlijk de helft van mijn tijd: leiding geven. Je hebt invloed op hoe het team samenwerkt. Als systeemarchitect breng je alles samen en geef je richting. Je vraagt je experts wat vanuit hun perspectief de beste oplossing is en dat leidt tot een gebalanceerd ontwerp. Er kunnen honderd of honderdvijftig mensen in een team zitten, maar het gaat erom hoe ze samenwerken.”

''The most important approach is to strive for simplicity.''

Grote projecten

Manders vindt het jammer dat hij niet meer zelf bouwt, maar hij vindt zijn huidige rol net zo uitdagend. “Nu ben ik er meer op gericht om alles in balans te houden en systeemkeuzes te maken bij grote projecten.”

Vermeulen ziet deze rol als een coach. “Het gaat over uitzoomen en inzoomen. Het grote geheel in de gaten houden.”

Manders legt uit: “Veel één-op-één gesprekken, hurken naast collega’s, brainstormen over waar we naartoe moeten. Soms moet je uitzoomen en je realiseren dat je op het verkeerde spoor zit. De aanpak moet helemaal veranderen.”

Manders noemt dit “de charme van het ontwerpen”. “Alle afwegingen die je maakt met je team leiden tot iets moois als het goed gedaan wordt. Het is spannend om het als architect vanaf de zijkant te zien groeien. Soms komen mensen met heel verrassende ideeën bij de koffieautomaat. Het proces van het maken van een ontwerp is magisch. De complexere modules kun je niet alleen ontwerpen.”

Vermeulen voegt eraan toe: “Eén plus één is drie. De ene persoon zegt iets, waardoor een ander op een idee komt. Een derde komt dan met iets verrassends, enzovoort.”

Janssen concludeert: “Maar uiteindelijk moet iemand een richting kiezen.”

Dit artikel is geschreven door René Raaijmakers, tech-redacteur van Bits&Chips.

Recommendation by former participants

By the end of the training participants are asked to fill out an evaluation form. To the question: 'Would you recommend this training to others?' they responded with a 9.5 out of 10.

Beruchte softwarefouten

Gratis webinar over het gebruik van AI voor het genereren van code

Gratis webinar

Op 20 mei 2025, van 15.00 – 16.00 uur, organiseert High Tech Institute een gratis webinar over beruchte softwarefouten. Het webinar wordt gepresenteerd door Ger Cloudt, trainer van de nieuwe cursussen“Softwarekwaliteit voor engineers” en“Softwarekwaliteit begrijpen voor managers” en auteur van het boek “Wat is softwarekwaliteit?”.

Doel
Besef je wel hoezeer onze maatschappij afhankelijk is van software? Heb je ooit nagedacht over de rol van software in je persoonlijke leven? Een goede blik op je directe omgeving zal je ervan overtuigen dat software alomtegenwoordig is. Je smartphone wordt bestuurd door software, je computer wordt bestuurd door software, je stofzuiger wordt bestuurd door software, je televisie wordt bestuurd door software, je auto wordt bestuurd door software. Kun je je een apparaat voorstellen dat niet op de een of andere manier door software wordt beïnvloed? Wat als de kwaliteit van die software minder is? Laten we in deze sessie eens kijken naar drie totaal verschillende beruchte softwarefouten!

Doelgroep
Iedereen die geïnteresseerd is in wat er mis kan gaan in software.

Programma

  • Wat is softwarekwaliteit?
  • De verdwijning van de Mars Climate Orbiter
  • Onbedoelde versnelling waardoor een persoon overlijdt
  • Crowdstrike-update legt luchthavens, treinstations, ziekenhuizen en meer plat
  • Conclusie

Trainer
Ger Cloudt

 

De staat van C++ opnieuw bekeken

C++
Eind 2022 schreef Kris van Rens over de staat van C++ op dat moment en de uitdagers. Een vervolg na nog eens twee jaar.

In 2022 trok Google, uit onvrede met het evolutieproces van C++, een aanzienlijk deel van zijn middelen terug uit het werk aan C++ en de Clang compiler front-end. Als alternatief werd het langetermijnproject Carbon aangekondigd, een opvolgertaal die nauw kan samenwerken met C++. Dit en de daaropvolgende gebeurtenissen vormden een keerpunt voor C++, omdat het ernstige kritiek te verduren kreeg vanwege de opgebouwde technische schuld en het relatief trage ontwikkelingstempo. Vanaf dat moment leek het erop dat iedereen een (sterke) mening had en deze luid verkondigde – de hoeveelheid kritiek kon niet langer worden genegeerd door het C++ comité.

Een ander aspect van C++ dat onder vuur ligt is het gebrek aan geheugenveiligheid. Geheugenveiligheid in een programmeertaal verwijst naar de mogelijkheid om fouten te voorkomen of op te vangen die gerelateerd zijn aan onjuiste geheugentoegang, zoals buffer overflows, use-after-free bugs of bungelende pointers, door ingebouwde functies en garanties in de taal zelf. Dit kan worden uitgebreid naar algemene taalveiligheid waarbij alle ongedefinieerd gedrag en ongespecificeerde semantiek uit de taal wordt geëlimineerd. Taalveiligheid is een concept gedefinieerd op een spectrum in plaats van een binaire eigenschap; sommige talen zijn veiliger dan andere. Voorbeelden van talen die als veilig worden beschouwd en nog steeds relatief low-level zijn Swift, Ada en Rust.

Na de intense spreekwoordelijke hitte van de zomer van 2022, zette een reeks klappen in verschillende vormen van openbare adviezen over geheugenveiligheid zowel C als C++ expliciet in slecht daglicht. Eind 2022 kwam eerst de NSA met een witboek waarin ons werd aangespoord om af te stappen van C en C++. Daarna begon CISA (de Amerikaanse Cybersecurity Infrastructure Security Agency) te pleiten voor een routekaart voor geheugenveiligheid. In 2023 en 2024 verkondigden zelfs het Witte Huis en US Consumer Report dat we geheugenveiligheid serieuzer dan ooit moeten nemen en moeten overstappen op geheugenveilige talen. Er waren nog veel meer gebeurtenissen, maar het volstaat te zeggen dat ze allemaal niet onopgemerkt zijn gebleven voor de C++-commissie.

''C is quite a simple language; it’s easy to learn and get started with. However, it’s very hard to become advanced and proficient at it at scale.''

Toegegeven, sommige van de pogingen van de C++ commissieleden om de aanvallen van het publiek te weerleggen kwamen een beetje minachtend over, waarbij geheugenveiligheid vaak bijna werd gebagatelliseerd als “slechts één van de vele potentiële softwareproblemen”. Dit klinkt voor mij heel erg als een logische denkfout. Natuurlijk kunnen er veel dingen fout gaan en een veilige taal is geen wondermiddel. De eisen voor softwareontwikkeling zijn echter drastisch veranderd in de afgelopen veertig jaar en tegenwoordig is geheugenveiligheid een opgelost probleem voor veel andere talen die bruikbaar zijn in hetzelfde toepassingsdomein. Officieel heeft ISO werkgroep 21 (WG21) studiegroep 23 (SG23) opgericht voor “Veiligheid en beveiliging”, met de taak om de beste manieren te vinden om van C++ een veiligere taal te maken en tegelijkertijd de andere beperkingen zoals achterwaartse compatibiliteit te behouden – niet zo eenvoudig.

Onmiskenbare kloof

Ik heb de afgelopen decennia met verschillende programmeertalen tegelijk in productie gewerkt. Wat me echt opvalt aan al mijn ervaringen met C en C++ is de enorme cognitieve belasting die ze op ontwikkelaars leggen.

C is een vrij eenvoudige taal; het is makkelijk te leren en om mee te beginnen. Het is echter erg moeilijk om er op grote schaal geavanceerd en bedreven in te worden. Als eenvoudige taal dwingt het je om veel belangrijke foutgevoelige engineeringtaken zoals geheugenbeheer en goede foutafhandeling handmatig uit te voeren – hoofdaspecten van betrouwbare, bugvrije software. Er is veel controle op laag niveau, ja, maar de ceremonie en cognitieve last om dingen goed te krijgen is gewoon onthutsend.

Hetzelfde geldt grotendeels voor C++. Het maakt dingen wel beter door je te ondersteunen bij het schrijven van correcte code, bijvoorbeeld met de standaardbibliotheek met slimme pointers voor geheugenbeheer. De vrachtwagenladingen taalcomplexiteit maken het echter ook moeilijk om het correct op schaal te gebruiken.

Bovendien hebben al deze aspecten van het coderen in C en C++ geen garantie dat de dingen betrouwbaar zijn na compilatie. Dit dwingt ontwikkelaars om best practices te bestuderen, compiler sanitizers en static analyzers te gebruiken en hun toevlucht te nemen tot uitgebreide tests, alleen maar om er zeker van te zijn dat alles in orde is. Natuurlijk zouden de meeste van deze activiteiten deel moeten uitmaken van elke gezonde mindset van softwareontwikkelaars, maar het is pijnlijk om te beseffen dat C en C++ de vereiste om dit werk te doen overdragen aan de ontwikkelaar, in plaats van het direct in de taal aan te pakken. Het ontwikkelen van een taal is, net als elke andere technische uitdaging, een eindeloze opeenvolging van afwegingen, dat is zeker, maar er is een onmiskenbaar gat tussen de mogelijkheden van de ‘oude talen’ en de behoeften op het gebied van softwareontwikkeling op dit moment. Andere, nieuwere talen laten zien dat het mogelijk is om aan deze eisen te voldoen terwijl het prestatiepotentieel behouden blijft.

''New features improve the language but also inherently increase the already quite substantial complexity, while all the old footguns and dangers like undefined behavior are still there.''

Jaren weg

De meeste programmeertalen worden in de loop der tijd voortdurend verbeterd. Als je echter in de C-wereld zit, zal er waarschijnlijk weinig tot niets veranderen. Voor veel projecten vandaag de dag is het daarom niet de juiste taalkeuze als je ook maar enige taalveiligheid wilt. Er zijn alternatieven beschikbaar die beter geschikt zijn voor het doel – als dit mogelijk is gezien de beperkingen en voorkeuren van uw project.

Voor C++ is het een ander verhaal. WG21 bereidt zich nu voor op de release van C++26, die enorme mogelijkheden gaat bieden, waaronder (hoogstwaarschijnlijk) contracten, executors en zelfs statische reflectie. Game-changers zeker, maar vooral gericht op het toepassingspotentieel van de taal of, in het geval van contracten, het verbeteren van de veiligheid en correctheid, maar nog steeds ten koste van de handmatige arbeid van de ontwikkelaar die het gebruikt.

Nieuwe functies verbeteren de taal, maar vergroten inherent ook de toch al aanzienlijke complexiteit, terwijl alle oude voetzoekers en gevaren zoals ongedefinieerd gedrag er nog steeds zijn. Het onderwijzen van C++ aan beginners als trainer blijft, voor een deel, een oefening in het wegsturen van de valkuilen – niet echt een natuurlijke, handige manier om te onderwijzen of te leren.

Het ‘parallelle universum’ van de taal Circle C++ laat zien hoe de ogenschijnlijk verstopte syntaxis en taaldefinitie van C++ toch in staat is om veel andere geweldige functies in te bouwen, zoals echte enumerators, pattern matching, statische reflectie en zelfs een borrow checker. Helaas is deze opmerkelijke eenmansshow van Sean Baxter niet gestandaardiseerd in C++ (en vice versa). De kans is klein dat een van deze uitstekende functies binnenkort in het officiële C++ terecht zal komen.

Baxter heeft ook een “Safe C++” voorstel, gepresenteerd aan de Safety and Security studiegroep in november vorig jaar. Hierin stelt hij voor om C++ uit te breiden met een “rigoureus veilige subset” van de taal die dezelfde veiligheidsgaranties biedt als de Rust borrow checker doet. Ik juich de inspanning toe, maar de tijd zal leren of, en in welke vorm, dit voorstel zijn weg zal vinden door het vaak schijnbaar trage C++ taalontwikkelingsproces. Het ontwerp van C++26 is grotendeels naar elkaar toegegroeid en C++29 is nog een paar jaar verwijderd. Tel daarbij op de implementatie/industrialisatie tijd van deze spec versies voordat ze echt op onze virtuele werkbanken landen, en het zou wel eens een decennium vanaf nu kunnen worden – als we geluk hebben.

Groenere weiden

Maar niet alles is verloren. De C++ commissie doet geweldig werk om de taal vooruit te helpen en de huidige staat van de taal en het ecosysteem is beter dan ooit. Het is alleen zo dat de kloof tussen wat C++ vandaag de dag kan bieden in vergelijking met wat mogelijk is gebleken op het gebied van veiligheid van systeemprogrammering en geïntegreerde tooling enorm is.

Als ik een paar jaar vooruit kijk, zie ik dit gat nog niet gedicht worden. Ondertussen staan talen als Rust en Swift niet stil. Er is veel momentum en toewijding voor C++ in de wereld, waardoor de industrie eraan vasthoudt, maar hoe lang kan het de technologiekloof in stand houden voordat industrieën of applicatiedomeinen overstappen op groenere weiden?