.jpg)
L'idea è partire dai requisiti che un tipo deve soddisfare, cioè dal comportamento e dalle operazioni richieste, e solo dopo definire o scegliere tipi che rispettino quei vincoli. Per l'utilizzatore non dovrebbe essere importante sapere se qualcosa sia una classe, una gerarchia con funzioni virtuali od altro: se soddisfa i vincoli espressi dal concept, allora è sufficiente.
Ha però precisato che non si tratta di un processo puramente astratto ed unidirezionale. Per costruire un buon concept spesso serve partire da uno o più tipi concreti, così da capire quali requisiti siano davvero necessari.
Le interfacce virtuali non scompaiono: restano utili quando servono vincoli ulteriori, per esempio legati ad ABI stabili o a forme specifiche di polimorfismo a tempo di esecuzione. Dove possibile, Stroustrup sembra preferire che il progetto parta dai concetti e dai vincoli semantici, non dalla meccanica dell'implementazione.
Parlando dei Bell Labs, Stroustrup ha descritto quell'ambiente come un luogo straordinario, unico al mondo e ha osservato che oggi non esiste più nulla di simile. Il centro di ricerca in informatica contava, ad un dato momento, circa sessanta persone, tra cui quattro membri della National Academy of Engineering: una concentrazione impressionante di talento, competenza e conoscenza.
Uno degli aspetti che ricorda con più piacere era l'apertura dell'ambiente: si poteva entrare nell'ufficio di qualcuno e discutere direttamente con un esperto mondiale del tema che interessava in quel momento. Molto del suo lavoro, racconta, è stato fatto sulle lavagne di altre persone.
Stroustrup ha poi espresso rammarico per la fine dei Bell Labs così come li aveva conosciuti: secondo lui fu una grande perdita di talento e competenze, qualcosa che non sarebbe dovuto accadere.
Tra gli aneddoti, ha ricordato un episodio con Rob Pike e Ken Thompson, che prepararono una dimostrazione per Arno Penzias, allora alla guida della ricerca dei Bell Labs e premio Nobel. Lo accompagnarono attraverso i corridoi per mostrargli grafica, giochi e tecnologie sperimentali. Una volta arrivati davanti al terminale finale, Penzias si aspettava di vedere qualche complesso calcolo od una simulazione scientifica. Invece, vide un'immagine di se stesso ripreso di spalle mentre entrava nella stanza.
L'episodio serve a Stroustrup per descrivere il clima del posto: un ambiente molto collegiale, in cui si poteva anche scherzare con persone di altissimo livello, purché con rispetto. Era un luogo che aiutava le persone a crescere. Arrivando lì, racconta, bastava leggere i nomi sulle porte per pensare di dover fare qualcosa di davvero notevole per meritare di appartenere a quel gruppo. La sindrome dell'impostore, conclude, non era affatto rara.
L'episodio viene raccontato anche da Rob Pike.
Di fronte all'ipotesi di riprogettare il C++ "con il senno di poi", Stroustrup ha richiamato il classico "problema della macchina del tempo". È facile, oggi, immaginare consigli da dare al passato; molto più difficile è capire se, all'epoca, quei consigli sarebbero stati davvero utilizzabili.
Il punto centrale è che molte scelte di C e C++ furono condizionate dai limiti tecnici del tempo. Stroustrup ricorda di aver iniziato a lavorare su una macchina con 128 KB di memoria dati; Dennis Ritchie, per il primo C, aveva a disposizione ancora meno: circa 48 KB di memoria totale. Con vincoli di questo tipo, anche la complessità del parser, dell'analisi statica e delle regole del linguaggio doveva essere contenuta.
Una delle cose che Stroustrup avrebbe voluto migliorare è la sintassi. La famosa sintassi inside out di C e C++ (vedi, per esempio, The Clockwise/Spiral Rule) deriva anche dal fatto che Ritchie non voleva inserire due analizzatori sintattici separati nella memoria disponibile: per questo espressioni e dichiarazioni finirono per condividere parte della grammatica. È una scelta che da allora ha reso possibile scrivere dichiarazioni molto complesse, ma anche difficili da leggere; Stroustrup osserva, con una certa ironia, che non bisognerebbe essere troppo orgogliosi di saper scrivere una funzione che restituisce un puntatore a funzione senza usare un `typedef`.
C'è però una cosa che, secondo lui, avrebbe potuto capire e implementare anche allora... se qualcuno gliel'avesse spiegata nel modo giusto: i `concepts`.
Secondo Stroustrup, i `template` senza vincoli rendono il linguaggio più complicato, più difficile da usare e persino più difficile da implementare, perché i controlli devono essere distribuiti "ovunque". Se qualcuno fosse tornato indietro nel tempo, nel periodo in cui lavorava sui template, e gli avesse spiegato chiaramente l'idea di funzioni valutate a tempo di compilazione che prendono tipi come argomenti, probabilmente sarebbe stato difficile convincerlo subito, ma aveva già le conoscenze necessarie per comprenderla.
In questo senso, i concept sono una delle poche cose per cui una macchina del tempo avrebbe davvero aiutato: introdurli prima avrebbe semplificato l'implementazione dei template e si sarebbe adattato meglio al suo modo di pensare.
Poi ha contestualizzato le critiche storiche: quando Torvalds espresse le sue posizioni più dure, nel 1996, anche Stroustrup non riteneva il compilatore C++ di GCC sufficientemente maturo. Se la critica fosse stata "quel compilatore non è all'altezza per scrivere un sistema operativo", Stroustrup avrebbe potuto concordare.
Il problema è che la critica andava oltre lo strumento specifico e diventava un giudizio sul linguaggio e sulle persone che lo usavano. Su questo Stroustrup non è d'accordo: C++ non era il linguaggio più facile né il più economico da adottare e non aveva un grande apparato di marketing a sostenerlo. Eppure è arrivato ad avere milioni di utenti. Non è plausibile, osserva, pensare che fossero tutti stupidi.
In sintesi, Stroustrup distingue tra una critica tecnica, che può essere fondata, per esempio sulla qualità degli strumenti disponibili in un certo periodo ed una critica generalizzata al linguaggio ed alla comunità, che considera semplicemente sbagliata.
Il tema della sicurezza ha portato anche all'invito del governo statunitense, nel 2024, ad abbandonare il C++ per ragioni di sicurezza. Stroustrup ha osservato che quella posizione si è già fatta più specifica e meno semplicistica. Non si tratterebbe più di una condanna generica di "C/C++", ma di un'analisi più dettagliata delle pratiche che causano problemi.
Il punto, quindi, non è negare l'esistenza dei problemi, ma distinguerne le cause. Per Stroustrup, la risposta non dovrebbe essere abbandonare C++, ma eliminare progressivamente le pratiche insicure: profili più restrittivi del linguaggio, librerie hardened, controlli sugli accessi fuori range e strumenti migliori possono ridurre molto il rischio.
Ha citato anche il fatto che oggi esistono librerie hardened disponibili da realtà come Google, Apple e Microsoft, che possono introdurre controlli aggiuntivi, per esempio sui limiti degli array o dei container. Qui emerge un altro problema: molte di queste soluzioni, quando rilevano una violazione, terminano il programma.
Per alcune applicazioni questo è accettabile: in un grande data center, se un processo termina, il carico può essere spostato altrove. Nei sistemi embedded, real time o safety critical la situazione è diversa. Se un singolo processore controlla qualcosa di vitale, non si può semplicemente terminare il programma al primo errore.
Stroustrup cita l'esempio di un controller dell'ossigeno in un sistema subacqueo: se c'è una violazione di un'asserzione, terminare il software potrebbe essere l'errore fatale. In questi contesti servono strategie di gestione dell'errore più sofisticate: contenere il problema, portare il sistema in uno stato sicuro, ripristinare o reinizializzare dove possibile.
Il tema centrale, ancora una volta, è che non tutti i domini sono uguali. La sicurezza del software non si ottiene solo cambiando linguaggio, ma capendo quali errori si vogliono prevenire, quali vincoli ha il sistema e quale comportamento è accettabile quando qualcosa va storto.
Il rischio è che molti studenti si abituino a pensare che efficienza, manutenibilità, garanzie e comprensione di ciò che accade "sotto" siano problemi di qualcun altro. Python può essere uno strumento utile, ma sotto Python serve comunque qualcuno che costruisca sistemi efficienti. Se si usa Python direttamente, invece di usarlo come interfaccia verso codice più efficiente scritto per esempio in C++, i costi in termini di prestazioni ed energia possono diventare molto elevati.
Stroustrup osserva anche che chi inizia solo con Python spesso incontra difficoltà quando arriva ad algoritmi, strutture dati e programmazione di sistema: nei programmi Python di grandi dimensioni emergono problemi seri di manutenibilità.
Più in generale la questione riguarda l'educazione informatica. Secondo Stroustrup è un errore trattare computer science, informatica applicata ed alfabetizzazione digitale come se fossero la stessa cosa. Chi deve costruire sistemi safety critical od infrastrutture fondamentali ha bisogno di una formazione diversa da chi deve sviluppare piccole applicazioni web. Non dovrebbero avere lo stesso curriculum, gli stessi esercizi, né gli stessi criteri di valutazione.
Per rispondere al problema, Stroustrup propone quindi di distinguere meglio i percorsi formativi. Vorrebbe vedere informatici con una mentalità ingegneristica, formati su linguaggi compilati, sistemi, costruzione di software, manutenibilità, prestazioni, affidabilità e processi per garantirle.
In questo quadro colloca anche il suo lavoro su C++: non come alternativa diretta a Python, ma come linguaggio pensato per ingegneri ben formati che devono costruire software efficiente, affidabile e mantenibile.
