Ciao, e benvenuto nella seconda puntata della sessantottesima stagione. Abbiamo detto che il significato di un programma è la sua esecuzione, quel film che scorre quando lo mettiamo in moto. Oggi guardiamo quel film al rallentatore, un fotogramma alla volta, e scopriamo di cosa è fatto. Perché ogni esecuzione, per quanto complessa, si regge su due sole idee: uno stato, e un passo.
Partiamo dalla prima, lo stato. In ogni istante dell'esecuzione, il programma si trova in una certa situazione. Alcune variabili hanno certi valori. Sei arrivato a un certo punto del codice, e non oltre. C'è forse qualcosa in attesa, un file aperto, una posizione in una lista. Tutto questo insieme, la fotografia completa di dove sei in questo preciso momento, è lo stato. Non un dettaglio: tutto ciò che serve sapere per poter continuare. Se qualcuno ti desse quella fotografia, potresti riprendere l'esecuzione da lì, senza sapere nient'altro del passato. Il passato conta solo per quanto ha lasciato in traccia nello stato di adesso.
Vediamo la seconda idea, il passo. L'esecuzione non salta dallo stato iniziale a quello finale in un colpo. Avanza per piccoli scatti: da uno stato al successivo, poi a quello dopo, e così via. Ogni scatto è un passo: una singola trasformazione che porta da una situazione a quella immediatamente seguente. Esegui questa operazione, e lo stato cambia leggermente. Poi la prossima, e cambia ancora. Un'esecuzione, vista da vicino, non è altro che una catena di stati, legati l'uno all'altro da un passo per volta. E il bello è che ogni passo, preso da solo, è quasi sempre semplice: è la loro somma a fare le cose grandi.
Metti insieme le due idee, ed ecco il modello che regge tutta la stagione. Un'esecuzione è una sequenza di fotografie, dallo stato di partenza a quello di arrivo, dove ogni fotografia è collegata alla successiva da un singolo passo. Sapere cosa fa un programma vuol dire sapere due cose: come è fatta ogni fotografia, e qual è la regola che ti porta da una alla prossima. Nient'altro. Tutta la complessità del comportamento nasce dal ripetere questo gesto minuscolo, uno stato e un passo, migliaia o milioni di volte.
C'è un'immagine perfetta per tutto questo, e viene dai giochi. Pensa a una partita a scacchi. In ogni momento, la partita è in una certa posizione: dove sta ogni pezzo sulla scacchiera, e di chi è il turno. Quella posizione è lo stato: la fotografia completa della partita in quell'istante. Non ti serve sapere come ci siete arrivati; guardando la scacchiera, sai tutto ciò che conta per proseguire. E una mossa è il passo: trasforma quella posizione in un'altra, quella immediatamente seguente. Una partita è esattamente questo: una sequenza di posizioni, legate da una mossa alla volta.
Nota quanto è potente questa lente, perché ti serve ovunque. Vale per una partita a scacchi, ma anche per il programma che stai scrivendo adesso. La fotografia sono le tue variabili e il punto in cui sei arrivato; la mossa è la prossima riga che viene eseguita. Vale persino per la macchina fisica di cui parlammo tempo fa: il processore, in fondo, non fa altro che questo, prende un'istruzione, cambia leggermente il suo stato interno, e passa alla successiva. Stato e passo, stato e passo. È lo scheletro nascosto sotto qualsiasi cosa venga eseguita, dal più piccolo calcolo al più grande sistema.
Voglio mostrarti perché questo cambia il modo in cui fai debug. Quando un programma si comporta male, il problema è sempre in uno di due posti: o una fotografia è sbagliata, cioè una variabile ha un valore che non ti aspettavi, oppure un passo è sbagliato, cioè da una situazione corretta il codice fa la mossa sbagliata. Un buon debugger è esattamente uno strumento per fermare il film, guardare la fotografia in quel punto, e poi far avanzare di un passo per vedere cosa cambia. Non stai facendo stregoneria: stai ispezionando stati e osservando passi, uno alla volta, proprio come impone questa lente.
Resta la lezione di fondo, e va oltre il codice. Di fronte a qualcosa che evolve nel tempo e sembra complicato, la domanda giusta è quasi sempre la stessa, doppia: qual è lo stato adesso, e qual è la regola che lo fa cambiare? Se sai rispondere a queste due, hai capito il sistema, qualunque esso sia. La complessità che ci spaventa, quasi sempre, non è nel singolo passo, che è banale: è nel numero enorme di passi. Ma la forma di ognuno resta semplice, ed è lì che si trova la presa.
Per oggi ci fermiamo qui. Abbiamo scomposto l'esecuzione nei suoi due mattoni. Lo stato: la fotografia completa di dove sei in un istante, tutto ciò che serve per continuare, senza dover sapere il passato. Il passo: la singola trasformazione che ti porta da una fotografia alla successiva. Un'esecuzione è una sequenza di stati legati da un passo alla volta, e tutta la complessità nasce dal ripetere quel gesto minuscolo tante volte. Come una partita a scacchi: la posizione è lo stato, la mossa è il passo. Questa lente vale per il tuo codice, per il processore, per il debug: cerca la fotografia sbagliata o il passo sbagliato. La lezione: davanti a un sistema che evolve, chiediti qual è lo stato ora e quale regola lo fa cambiare. Nella prossima puntata: le regole del gioco. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.