← Tutti gli episodi
Copertina di Compilare o interpretare?
Stagione 67 · Episodio 006

Compilare o interpretare?

21 settembre 2026 5:16
0:00 5:16

Ciao, e benvenuto nella sesta puntata della sessantasettesima stagione. Finora ho parlato del compilatore come se ci fosse un solo modo di far girare il codice: tradurlo tutto prima, e poi eseguirlo. Ma non è l'unico modo, e forse non è nemmeno quello che usi ogni giorno. Oggi allarghiamo lo sguardo su tutto lo spettro: compilare, interpretare, e la via di mezzo che oggi domina.

Partiamo dalla prima strada, quella classica: compilare tutto prima. Prendi il tuo codice, lo dai al compilatore, e lui traduce l'intero programma nelle istruzioni della macchina, in anticipo, una volta per tutte. Alla fine hai un file eseguibile, autonomo, che gira da solo, senza bisogno del compilatore. È la via dei linguaggi che producono un programma pronto da distribuire. Il vantaggio è che, quando parte, è veloce: tutto il lavoro di traduzione è già stato fatto. Lo svantaggio è che devi aspettare la compilazione prima di poter provare qualsiasi cosa, e quel programma è legato alla macchina per cui l'hai compilato.

Vediamo la seconda strada, quella opposta: interpretare. Qui non c'è una traduzione anticipata. C'è un altro programma, l'interprete, che prende il tuo codice e lo esegue direttamente, leggendolo e mettendolo in atto man mano, riga dopo riga, mentre il programma gira. È la via di molti linguaggi comodi e flessibili, quelli in cui scrivi e provi subito, senza attese. Il vantaggio è proprio questo: nessuna compilazione da aspettare, e lo stesso codice gira ovunque ci sia l'interprete giusto. Lo svantaggio è la velocità: tradurre e decidere al volo, ogni volta, costa, e in genere un programma interpretato è più lento di uno compilato in anticipo.

Voglio che tu senta bene questa differenza con un'immagine di traduzione, perché è perfetta. Compilare tutto prima è come tradurre un libro intero, stamparlo, e distribuirlo: dopo, chiunque lo legge nella sua lingua, in fretta, senza più bisogno del traduttore. Interpretare è come avere un interprete umano accanto che ti traduce a voce, frase per frase, mentre l'oratore parla: comodissimo, immediato, ma ogni frase va ritradotta ogni volta, e a ogni nuovo ascoltatore si ricomincia. Due modi opposti, ognuno con il suo prezzo e il suo vantaggio.

Vediamo ora la via di mezzo, quella che oggi fa girare gran parte del software che usi: compilare al volo, mentre il programma gira. All'inizio il codice viene interpretato, per partire subito. Ma un componente intelligente osserva il programma mentre lavora, e nota quali parti vengono eseguite di continuo, i punti caldi. Quelle parti, e solo quelle, le compila al volo in codice macchina veloce, mentre tutto il resto continua a girare. Così ottieni il meglio dei due mondi: la partenza rapida dell'interprete, e la velocità del compilato proprio dove serve di più. È l'interprete simultaneo che, sentendo ripetere sempre le stesse frasi, le impara a memoria e da lì in poi le traduce all'istante.

Voglio che tu colga perché questo spiega il tuo lavoro di tutti i giorni. Spiega perché certi linguaggi ti danno un programma unico da mettere sul server e via, mentre altri hanno bisogno del loro ambiente installato per girare. Spiega perché alcuni partono in un lampo ma restano modesti in velocità, e altri sono lenti al primo istante e poi diventano rapidissimi quando si scaldano. Spiega perché lo stesso identico linguaggio, con motori diversi, può comportarsi in modo molto diverso. Non è caos: è che ognuno ha scelto un punto diverso su questo spettro, secondo cosa gli serviva.

Ecco la cosa importante da fissare, così eviti un malinteso comune. Compilato e interpretato non sono due caselle nettamente separate, in cui infilare i linguaggi. Sono due estremi di una linea continua, e quasi tutto, oggi, sta da qualche parte nel mezzo. Il confine tra tradurre prima e tradurre durante si è fatto sfumato, mobile. La domanda giusta non è più questo linguaggio è compilato o interpretato, ma dove si colloca su quello spettro, e con quali compromessi. È una lente più fine, e più vera, per capire perché gli strumenti si comportano come si comportano.

Resta la lezione di fondo, la solita di questo podcast. Non esiste il modo giusto in assoluto: esistono compromessi diversi per bisogni diversi. Chi vuole velocità di partenza sceglie da una parte, chi vuole massime prestazioni a regime dall'altra, chi vuole flessibilità e comodità da un'altra ancora. Conoscere lo spettro non serve a decretare un vincitore, ma a capire, davanti a uno strumento, quali compromessi ha scelto, e se sono quelli giusti per te.

Per oggi ci fermiamo qui. Abbiamo aperto tutto lo spettro tra compilare e interpretare. La prima strada, compilare tutto prima: un eseguibile autonomo e veloce, ma con l'attesa della compilazione e il legame alla macchina. La seconda, interpretare: nessuna attesa e codice che gira ovunque ci sia l'interprete, ma in genere più lento. E la via di mezzo che oggi domina: compilare al volo i punti caldi mentre il programma gira, per avere partenza rapida e velocità dove serve. Come tradurre un libro e stamparlo, tradurre a voce frase per frase, o l'interprete simultaneo che impara le frasi ricorrenti. Non due caselle, ma una linea continua. La lezione: non esiste il modo giusto in assoluto, solo compromessi diversi per bisogni diversi. Nella prossima puntata: il compilatore come primo maestro. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.