Ciao, e benvenuto nella sesta puntata della ventiseiesima stagione. Nella scorsa puntata ho anticipato un fatto imbarazzante, e oggi lo affronto a viso aperto, con l'onestà di sempre: Python è lento. È forse la sua debolezza più nota e più criticata. Eppure, come vedremo, questo linguaggio lento domina proprio i campi che richiedono i calcoli più enormi. Come è possibile? La risposta è astuta, e riprende il ruolo di collante che abbiamo appena visto. Oggi affrontiamo il compromesso della velocità: lento ma astuto.
Partiamo dall'ammettere onestamente il difetto, perché è reale. Sì, Python è lento. Se prendi un compito di puro calcolo e lo fai fare a Python riga per riga, è parecchio più lento dei linguaggi veloci come Go. Il motivo riprende cose che abbiamo visto sui linguaggi. Python è interpretato, non compilato una volta in anticipo, il che comporta un costo continuo mentre gira. Ed è flessibile, dinamico, non irreggimentato in strutture rigide che permettono al computer di ottimizzare al massimo. Queste scelte, che rendono Python comodo e flessibile da scrivere, hanno un prezzo in velocità. La sua comodità e la sua lentezza vengono dalla stessa radice: la flessibilità.
Voglio farti sentire quanto questo suoni imbarazzante, per poi risolverlo, perché il paradosso è forte. Pensa: i campi che oggi richiedono i calcoli più mostruosi, più pesanti, più affamati di velocità, sono l'analisi di enormi quantità di dati e, soprattutto, l'intelligenza artificiale, che macina numeri in quantità sbalorditive. E indovina qual è il linguaggio dominante proprio in questi campi? Python, il linguaggio lento. È un paradosso apparente che grida una domanda: come diavolo può il linguaggio lento essere il re dei calcoli più pesanti del mondo? Sembra assurdo, contraddittorio. Eppure è così, ed è vero. La spiegazione di questo paradosso è una delle cose più illuminanti da capire su Python.
Ed ecco la risoluzione del paradosso, che riprende in pieno la puntata scorsa, e voglio che la afferri bene. Il trucco è che, quando si fa quel lavoro pesante, Python non lo fa lui. Come abbiamo visto, Python fa il direttore d'orchestra: orchestra strumenti potenti, scritti in linguaggi velocissimi, costruiti apposta per macinare numeri alla massima velocità. Quando serve fare i calcoli enormi, Python li affida a questi strumenti fulminei, che li eseguono a velocità piena, e lui si limita a dirigerli, a dire cosa fare e a mettere insieme i risultati. Quindi la lentezza di Python non conta, perché la parte lenta, quella che scrive lui, è solo la direzione, l'orchestrazione, che è leggera; la parte pesante, i calcoli, la fanno gli strumenti veloci. Il lento dirige i veloci.
Voglio farti apprezzare l'astuzia profonda di questo, perché è geniale. Python è lento proprio dove non conta, nella parte di coordinamento, che è leggera e non ha bisogno di velocità, e delega la velocità proprio dove conta, nel calcolo pesante, agli strumenti fatti apposta. È come un direttore d'orchestra che magari non sa suonare velocissimo nessuno strumento, ma non gli serve: il suo compito è dirigere, e i musicisti virtuosi suonano al posto suo. La lentezza di Python è irrilevante nel ruolo che svolge, perché in quel ruolo non deve essere veloce lui. È un modo astuto di aggirare completamente il proprio difetto: non lo risolve, lo rende irrilevante spostando il lavoro pesante altrove. Lento sì, ma astuto.
Voglio collegare questo al confronto con Go, perché illumina benissimo il senso dei compromessi. Ricordi Go, ossessionato dalla velocità? Go e Python fanno scelte opposte. Go sacrifica un po' di comodità per essere velocissimo lui stesso. Python sacrifica la propria velocità per essere comodissimo, e recupera la velocità delegandola ad altri strumenti. Due compromessi opposti, entrambi validi, per esigenze diverse. Se hai bisogno di un unico programma che sia velocissimo di suo, Go è magnifico. Se hai bisogno di orchestrare comodamente strumenti potenti, con codice leggibile, Python è magnifico. Nessuno è meglio in assoluto: sono due risposte opposte alla tensione tra comodità e velocità, ciascuna astuta a modo suo.
Voglio darti una prospettiva onesta ed equilibrata, per chiudere, perché il trucco non è magia assoluta. Il ruolo di collante risolve brillantemente il problema della velocità nei casi tipici di Python, come i dati e l'intelligenza artificiale, dove il lavoro pesante può essere delegato a strumenti veloci. Ma non lo risolve sempre: se hai un compito in cui il lavoro pesante è proprio il codice che scrivi tu in Python, e non puoi delegarlo, allora la sua lentezza si sente eccome. Quindi la lentezza di Python è irrilevante in molti casi, grazie al ruolo di collante, ma reale in altri, dove va tenuta in conto. Come sempre, la verità è sfumata: Python è lento ma astuto, e sapere quando l'astuzia basta e quando no è ciò che distingue chi lo usa bene.
Per oggi ci fermiamo qui. Python ha una debolezza reale: è lento, perché interpretato e flessibile, con la comodità e la lentezza che vengono dalla stessa radice. Eppure domina i campi dei calcoli più pesanti, come l'intelligenza artificiale: un paradosso apparente. La risoluzione è astuta: Python non fa lui il lavoro pesante, lo orchestra, affidandolo a strumenti velocissimi, come un direttore che dirige musicisti virtuosi. È lento dove non conta, il coordinamento, e delega la velocità dove conta, il calcolo. Non risolve il difetto, lo rende irrilevante. È il compromesso opposto a Go, ed entrambi sono validi. Con onestà: l'astuzia basta spesso, ma non sempre. Nella prossima puntata vediamo la sua ricchezza pronta: le batterie e l'immenso magazzino. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.