Ciao, e benvenuto nell'ottava puntata della sessantottesima stagione. Fin qui abbiamo costruito uno strumento di pensiero: stato, passo, regole, i modi in cui un'esecuzione può finire bene o male, i tipi come promessa. Ora scendiamo con i piedi per terra e facciamo la domanda più concreta di tutte. A cosa serve davvero, nel mondo reale, definire con precisione come si esegue un programma? Le risposte sono quattro, e le tocchi più spesso di quanto pensi.
Partiamo dalla prima: definire un linguaggio senza ambiguità. Quando qualcuno progetta un nuovo linguaggio, deve scrivere da qualche parte cosa significa ogni sua costruzione. Non a parole vaghe, che ognuno interpreta a modo suo, ma in modo che due persone diverse, leggendo la stessa specifica, capiscano la stessa cosa; e descrivere come si esegue ogni costruzione, passo per passo, è il modo più preciso di dirlo. La semantica diventa il regolamento ufficiale su cui tutti concordano. È la differenza tra un linguaggio con un comportamento definito e uno che fa quel che capita. E, come abbiamo visto, dove la specifica tace nascono i guai.
Vediamo la seconda, e forse la più vicina a te: costruire un interprete, o una macchina che esegua il linguaggio. Chiunque abbia mai scritto un interprete, un piccolo valutatore di espressioni, un motore che legge comandi e li esegue, ha fatto una cosa precisa: ha implementato una semantica operazionale, magari senza chiamarla così. Quel codice che guarda la situazione, decide il prossimo passo e lo compie è esattamente l'arbitro col regolamento di cui parlavamo. Le regole di esecuzione, sulla carta, e l'interprete, nel codice, sono la stessa cosa vista da due lati. Scrivere un interprete è tradurre un regolamento in un meccanismo che lo applica.
Nota quanto è concreto questo, se hai mai lavorato con certi strumenti. Le macchine virtuali su cui girano tanti linguaggi moderni sono, nel cuore, una semantica operazionale resa esecutiva: fanno avanzare un programma in forma intermedia, un'istruzione alla volta, secondo regole precise. E c'è un caso che abbiamo già incontrato, quella tecnologia pensata per far girare codice veloce nel browser: è uno dei rari linguaggi nati con una semantica formale completa fin dall'inizio, non un ripensamento ma le fondamenta. Prima definire come si esegue, poi costruire la macchina che obbedisce.
Voglio mostrarti la terza, che è la più ambiziosa: dimostrare che qualcosa è corretto. Se hai una definizione precisa di cosa fa un programma, puoi dimostrare, con rigore matematico, che fa proprio quello che deve: non testarlo su qualche caso e sperare, ma dimostrarlo per tutti i casi possibili. Ed è qui che si chiude un cerchio con la stagione scorsa. Ricordi la promessa del compilatore, che traduce preservando il significato? Quella promessa, per essere davvero garantita, ha bisogno di una definizione precisa di significato da preservare. Esistono compilatori di cui è stato dimostrato, formalmente, che la traduzione conserva la semantica originale: non ci fidiamo perché passano i test, sappiamo che sono corretti perché è stato provato.
C'è la quarta, ed è quella che usi ogni singolo giorno, quasi senza saperlo: ragionare sul codice. Il modello di stato e passo è lo strumento con cui capisci un programma nuovo, prevedi cosa farà un cambiamento, trovi dove nasce un bug. Ogni volta che ti chiedi cosa succederebbe se qui il valore fosse diverso, o segui mentalmente il flusso per capire un errore, stai usando la semantica operazionale come attrezzo quotidiano. Non serve che sia formale: serve che sia chiara. Ed è la più diffusa di tutte le applicazioni, perché non richiede di scrivere nulla, solo di pensare bene. È lo stesso attrezzo delle altre tre, usato a mente invece che sulla carta.
Ecco l'immagine che tiene insieme le quattro cose: un unico manuale di regole, scritto una volta con cura, da cui nascono tre discendenti. L'arbitro che fa rispettare le regole durante la partita, cioè l'interprete o la macchina. Le dimostrazioni su cosa la partita non potrà mai fare, cioè la verifica. E la capacità dei giocatori di prevedere le mosse senza rileggere il regolamento ogni istante, cioè il tuo ragionamento allenato. Un solo documento preciso alla radice, e tutto il resto fiorisce da lì.
Resta la lezione di fondo, e vale in ogni mestiere. Una definizione precisa non è burocrazia: è la radice da cui si ramifica tutto il lavoro serio. Puoi costruire strumenti affidabili, dimostrare proprietà, ragionare con sicurezza, solo se hai messo per iscritto, senza ambiguità, cosa significano le cose. Dove la definizione è vaga, tutto ciò che ci costruisci sopra eredita quella vaghezza. Dove è precisa, ci puoi appoggiare un intero edificio.
Per oggi ci fermiamo qui. Abbiamo tirato le somme sul lato pratico: a cosa serve definire con precisione come si esegue un programma. Primo, a definire un linguaggio senza ambiguità, con una specifica su cui tutti concordano. Secondo, a costruire un interprete o una macchina: chi scrive un interprete implementa una semantica operazionale, magari senza chiamarla così, e le macchine virtuali ne sono la prova. Terzo, a dimostrare che qualcosa è corretto, incluso che un compilatore preserva il significato: e qui si chiude il cerchio con la stagione scorsa. Quarto, a ragionare sul codice ogni giorno, con il modello di stato e passo. Un unico manuale di regole alla radice, e da lì l'arbitro, le dimostrazioni, il tuo intuito allenato. La lezione: una definizione precisa è la radice da cui si ramifica tutto il lavoro serio. Nella prossima puntata: quanta teoria ti serve. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.