Ciao, e benvenuto nella quinta puntata della ventiquattresima stagione. Nella scorsa puntata abbiamo capito il pensiero asincrono: non aspettare, ma dire cosa fare quando qualcosa sarà pronto. È un modello potente, ma nei primi tempi di Node scriverlo era, francamente, doloroso. Oggi raccontiamo una storia bellissima di evoluzione, di una comunità che, anno dopo anno, ha reso questo modo di scrivere sempre più sereno e leggibile, passando da un vero e proprio inferno a qualcosa di quasi piacevole. È la storia di come si è addomesticato l'asincrono, ed è istruttiva ben oltre Node.
Partiamo dal primo modo, quello degli inizi, che funzionava ma aveva un difetto crescente. All'inizio, per dire cosa fare quando qualcosa sarà pronto, si usava passare un'istruzione, un pezzo di codice, che sarebbe stato eseguito al completamento. Fin qui, semplice. Il problema nasceva quando dovevi concatenare più cose asincrone in fila: fai questa cosa, e quando è pronta fai quest'altra, e quando anche quella è pronta fai la terza, e così via. Ogni passo asincrono andava annidato dentro l'istruzione del precedente, creando strutture sempre più profonde e rientrate, un annidamento dentro l'altro, come scatole cinesi. Con tanti passi, il codice diventava un intrico illeggibile di livelli sempre più profondi.
Questo problema aveva un nome pittoresco e azzeccato, che voglio dirti: l'inferno delle istruzioni annidate. Immagina un codice che rientra sempre di più verso destra, livello dopo livello, un annidamento profondissimo, fino a diventare una piramide storta e ingestibile. Seguire il filo di cosa succede in quel groviglio era un incubo: dovevi districarti tra livelli su livelli di annidamento, perdendoti facilmente. Era un codice difficile da leggere, da capire, da correggere. Il pensiero asincrono era potente, ma il modo di scriverlo, agli inizi, produceva questi mostri annidati che scoraggiavano e facevano disperare. Serviva chiaramente qualcosa di meglio.
Ed ecco il primo grande passo avanti, un'idea elegante per domare l'annidamento: la promessa. Invece di annidare istruzioni dentro istruzioni, si introdusse l'idea di un oggetto speciale che rappresenta un risultato che arriverà in futuro, una specie di segnaposto per qualcosa che non è ancora pronto ma lo sarà. Lo chiamarono, con un nome evocativo, una promessa: la promessa di un risultato futuro. La cosa bella è che queste promesse si potevano concatenare in modo pulito, una dopo l'altra, in fila, invece che annidate una dentro l'altra. Fai questo, poi questo, poi questo, in una catena lineare e leggibile, invece della piramide storta. La promessa ha trasformato l'annidamento profondo in una catena ordinata.
Voglio farti apprezzare il salto di qualità, perché è notevole. Con le promesse, il codice asincrono, che prima era una piramide di annidamenti illeggibile, diventava una sequenza lineare di passi concatenati, molto più facile da seguire. Potevi leggere fai questo, poi quello, poi quell'altro, dall'alto in basso, come una sequenza chiara, pur mantenendo tutta l'efficienza dell'asincrono sotto. Era un enorme miglioramento di leggibilità e di serenità nello scrivere. La comunità aveva trovato un modo per rendere l'asincrono, potente ma scomodo, molto più maneggevole. Ma la strada verso la serenità non era ancora finita: c'era un ultimo, bellissimo passo da fare.
Ed ecco l'ultimo passo, quello che ha portato la vera serenità, e che è quasi magico. Si introdusse un modo di scrivere il codice asincrono che lo fa apparire quasi identico a quello sincrono, normale, sequenziale. Con questo modo, puoi scrivere fai questo, aspetta il risultato, poi fai quello con il risultato, in una sequenza dall'alto in basso che si legge esattamente come il codice normale a cui siamo abituati, semplice e naturale. Ma, e qui sta la magia, sotto le apparenze quel codice resta asincrono: non blocca davvero il lavoratore, continua a permettere al ciclo degli eventi di servire altri clienti durante le attese. Hai la leggibilità del codice sincrono, semplice e naturale, con l'efficienza dell'asincrono sotto. Il meglio dei due mondi.
Voglio farti riflettere sul senso di questa storia, perché è istruttiva e riprende temi del podcast. Abbiamo assistito a un'evoluzione: un modello potente ma inizialmente scomodo, l'asincrono, che una comunità ha progressivamente reso più maneggevole, passo dopo passo, dall'inferno annidato, alle promesse concatenate, fino alla serenità del codice che sembra sincrono ma è asincrono. È un esempio perfetto di come la tecnologia migliori: non con un colpo di genio unico, ma con un'iterazione paziente, un miglioramento dopo l'altro, guidato dal dolore reale degli utenti e dal desiderio di fare meglio. Ricordi il ciclo di miglioramento continuo dell'Agile? Eccolo, applicato all'evoluzione di un modo di programmare. La tecnologia buona spesso si affina così, per gradi.
Per oggi ci fermiamo qui. Il pensiero asincrono è potente, ma nei primi tempi scriverlo era doloroso: concatenare più passi produceva un annidamento profondo e illeggibile, il famoso inferno delle istruzioni annidate. La comunità l'ha addomesticato per gradi. Prima con le promesse, oggetti che rappresentano un risultato futuro e si concatenano in una catena ordinata invece che annidata. Poi con un modo di scrivere l'asincrono che sembra sincrono, semplice e sequenziale da leggere, ma resta efficiente sotto: il meglio dei due mondi. È una bella storia di miglioramento iterativo, guidato dal dolore reale, come tanti che abbiamo incontrato. Nella prossima puntata affrontiamo con onestà la forza e il limite del filo singolo. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.