Ciao, e benvenuto nella settima puntata della ventesima stagione. Nella scorsa puntata abbiamo scoperto un modo di pensare i programmi, quello a oggetti. Oggi ne scopriamo un altro, diverso e per certi versi opposto, che nasce da radici antiche, addirittura matematiche, e che dopo anni in disparte è tornato prepotentemente di moda. È l'idea di pensare in funzioni. Un modo di programmare che mette al centro la trasformazione dei dati invece delle cose che cambiano, e che ci insegna qualcosa di profondo su cosa rende un programma facile o difficile da capire.
Partiamo da un concetto che percorre tutta la programmazione e che qui viene messo in discussione: lo stato che cambia. Nella maggior parte dei programmi, ci sono dei dati che vengono modificati continuamente nel tempo: un valore che aumenta, una lista a cui si aggiungono elementi, un oggetto il cui contenuto muta passo dopo passo. Il programma procede cambiando lo stato delle cose, modificandole sul posto. È il modo più naturale e diffuso di pensare: le cose hanno uno stato, e il programma lo cambia man mano. Ma questo cambiamento continuo, come vedremo, ha un costo nascosto in termini di comprensibilità.
L'idea del pensare in funzioni propone qualcosa di radicalmente diverso: invece di modificare le cose sul posto, pensa in termini di funzioni che trasformano ingressi in uscite, come le funzioni della matematica. Cosa significa? Una funzione matematica prende dei valori in ingresso e produce un risultato, senza cambiare nulla nel mondo: dai gli stessi ingressi, ottieni sempre la stessa uscita, e null'altro accade. Non modifica variabili, non altera lo stato: prende, calcola, restituisce. Programmare in funzioni significa costruire il programma come una catena di queste trasformazioni pure, che prendono dati e ne producono di nuovi, invece di modificare i dati esistenti sul posto.
Voglio spiegarti perché questo modo, apparentemente più astratto, abbia in realtà un grande vantaggio pratico, perché è il cuore della puntata. Il problema dello stato che cambia è che rende difficile ragionare sul programma. Se un dato può essere modificato da tante parti diverse, in momenti diversi, per capire cosa vale in un certo punto devi ricostruire tutta la storia di chi l'ha cambiato e quando: un incubo. Le funzioni pure, invece, che non cambiano nulla e dipendono solo dai loro ingressi, sono facilissime da capire in isolamento: guardi cosa entra, sai cosa esce, sempre, senza sorprese nascoste. Eliminare o ridurre lo stato che cambia rende il programma più prevedibile e più facile da ragionare, pezzo per pezzo.
C'è un secondo vantaggio potente, che riprende un tema di altre stagioni, ed è particolarmente attuale: le funzioni pure vanno d'accordo con il fare tante cose insieme. Ricordi la difficoltà della concorrenza, di tanti che modificano gli stessi dati contemporaneamente, con il rischio di pestarsi i piedi? Gran parte di quella difficoltà nasce proprio dallo stato condiviso che cambia. Ma se ti basi su funzioni pure, che non modificano nulla ma solo trasformano ingressi in uscite, allora tante di esse possono lavorare contemporaneamente senza pestarsi i piedi, perché non c'è uno stato condiviso mutevole da rovinare. In un mondo dove far girare tante cose in parallelo è sempre più importante, questo pregio del pensiero in funzioni è diventato molto prezioso.
Voglio soffermarmi su un punto che trovo affascinante nella storia di questa idea: non è affatto nuova. Il pensiero in funzioni affonda le radici in idee matematiche antiche, ed è presente fin dai primi decenni dell'informatica, in uno dei linguaggi più antichi. Per lungo tempo è rimasto un po' in disparte, considerato elegante ma di nicchia, mentre altri modi dominavano. Ma negli ultimi tempi è tornato prepotentemente alla ribalta, proprio perché i suoi pregi, la facilità di ragionamento e l'affinità con il parallelismo, sono diventati sempre più importanti. È un bell'esempio di come, in informatica, le idee non muoiono: restano latenti, e tornano quando il momento è maturo e i loro vantaggi diventano cruciali.
Voglio trarre da questa e dalla scorsa puntata una lezione più ampia, perché è il senso di questa parte della stagione. Abbiamo visto due modi molto diversi di pensare i programmi: a oggetti e a funzioni. Non sono l'uno giusto e l'altro sbagliato: sono lenti diverse, modi diversi di organizzare il pensiero, ciascuno che illumina bene certi problemi e meno bene altri. Un linguaggio, e un modo di pensare, non è solo un mezzo per dire alla macchina cosa fare: è uno strumento di pensiero, che ti offre certi concetti con cui ragionare e ti orienta a vedere i problemi in un certo modo. Conoscere modi di pensare diversi ti rende un programmatore più ricco, capace di scegliere la lente giusta per ogni problema.
Per oggi ci fermiamo qui. Il pensiero in funzioni propone di costruire i programmi non modificando le cose sul posto, ma come catene di funzioni pure che trasformano ingressi in uscite, come in matematica, senza cambiare nulla. Il vantaggio è duplice: programmi più facili da capire, perché senza lo stato mutevole che complica il ragionamento, e più adatti a far girare tante cose insieme, perché senza stato condiviso da rovinare. È un'idea antica, tornata di moda quando i suoi pregi sono diventati cruciali. E ci insegna che i modi di pensare i programmi sono lenti diverse, strumenti di pensiero. Nella prossima puntata affrontiamo la moltitudine di linguaggi e la ricerca di un terreno comune. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.