di un programmatore della vecchia guardia
Quaranta anni di codice, e non mi sono ancora convertito
Sono entrato nel mondo della programmazione alla fine degli anni ’80. BASIC prima, poi dBASE IV, Clipper, QBasic, Turbo Pascal, Visual Basic, Visual FoxPro, Python, Qt. Una carriera che ha attraversato ere geologiche dell’informatica, quando ancora i programmi si compilavano in pochi secondi su macchine con pochi megabyte di RAM e dovevi sapere esattamente cosa stava facendo il tuo codice, istruzione per istruzione.
Ho realizzato la gestione dei componenti elettronici per l’INFN di Padova, il sistema degli iscritti per l’Ordine dei Geologi, le scuole polo per il Ministero della Pubblica Istruzione, una cartella clinica per la colonproctologia citata su una prestigiosa rivista medica americana, una piattaforma per la gestione parallela e conforme delle visure camerali di Infocamere, software per il recupero crediti, gestionali massivi con magazzino e fatturazione, la gestione di processi legali complessi. Ho lavorato come sistemista Linux e come perito nei tribunali.
Tutto questo, con una mente procedurale.
Il mio rifiuto (quasi costituzionale) della OOP
Non ho mai amato la programmazione orientata agli oggetti. Lo dico senza vergogna e con piena consapevolezza di cosa significhi.
La OOP ha senso. Ha senso profondo nel nucleo del software: i kernel, la glibc, i compilatori, le librerie di sistema. Quando scrivi codice che deve essere riusato da milioni di programmi diversi, l’incapsulamento e l’ereditarietà sono strumenti potenti e coerenti. Non lo metto in discussione.
Ma per decine di migliaia di righe di codice applicativo? Per una gestione commerciale, un sistema di recupero crediti, un’interfaccia con PostgreSQL? Ho sempre trovato la OOP un livello di indirezione in più che non mi aggiungeva nulla, anzi mi toglieva la chiarezza del flusso.
Il mio stile è sempre stato preciso: flusso lineare, pochi salti, variabili globali dove servono, sottoprocedure solo quando necessario, codice scritto come si parla — fluido, leggibile, quasi chilometrico nella sua linearità. Invoco gli oggetti delle librerie, certo — ma non ne produco di miei se posso evitarlo. È una posizione coerente: consumo la OOP, non la produco.
Me ne sono reso conto in modo brutale quando mi sono confrontato con due colleghi molto più bravi di me nei loro rispettivi territori: uno sviluppatore Java puro e uno Qt. In quei paradigmi, con quella potenza OOP nelle loro mani, non avevo scampo. Lo riconosco senza riserve. La OOP nelle mani giuste è una cosa straordinaria. Ma nelle mie mani, con il mio modo di pensare, non lo è mai stata.
Python: procedurale nel 2026, ha ancora senso?
Me lo sono chiesto spesso. La risposta, dopo riflessione, è sì — con piena dignità.
Python è uno dei pochissimi linguaggi moderni che non ti obbliga alla OOP. Guido van Rossum ha sempre resistito ai dogmatismi puristi, e si vede. Puoi scrivere 50.000 righe senza una classe tua e il programma non solo funziona — funziona bene.
Il mio Python assomiglia molto al mio Turbo Pascal: variabili globali, flusso lineare, librerie usate come strumenti. E questo stile è perfettamente a casa in tutto il mondo dell’analisi dati e della ricerca scientifica. NumPy, pandas, SQLAlchemy usati in modo procedurale sono la norma nei laboratori di tutto il mondo. Non è un difetto — è una scelta consapevole.
Dove il procedurale regge benissimo in Python:
- Elaborazioni massive su dati strutturati
- Interfaccia con PostgreSQL — il procedurale e l’SQL pensano allo stesso modo: trasformazioni sequenziali su insiemi
- Automazioni, ETL, batch processing
- Script che devono essere letti e modificati da chi non è uno specialista OOP
Dove inizia a cedere, sopra certe soglie:
- Quando lo stesso “oggetto concettuale” deve attraversare decine di funzioni con stato mutevole — le variabili globali diventano pericolose
- Quando il codice lo toccano più persone — la OOP è anche una convenzione sociale, non solo tecnica
- Interfacce grafiche complesse — Qt lo dimostra impietosamente
Ma attenzione: le soglie che conosco io sono molto alte. Decine di migliaia di righe, complessità reale, dati veri. Non i tutorial da 200 righe con cui molti “esperti” OOP misurano il mondo.
Il vero problema: la complessità accidentale
Fred Brooks la chiamò così nel 1986, nel suo saggio No Silver Bullet: complessità accidentale.
La complessità essenziale è quella del problema che devi risolvere. Tracciare i componenti dell’INFN. Gestire gli iscritti all’ordine. Recuperare un credito. È la complessità che giustifica il tuo lavoro e la tua parcella.
La complessità accidentale è tutto il resto. Ed è lì che il mondo moderno è diventato un incubo.
Considera uno scenario concreto: devi salvare un dato in un database PostgreSQL da un’applicazione web su Linux. Il problema essenziale è banale — cinque righe di SQL. La complessità accidentale che ti si para davanti è questa:
Problema reale: salvare un record nel database
Complessità accidentale:
├── PostgreSQL 15 vs 16: pg_hba.conf si comporta diversamente
├── OpenSSL 1.1 vs 3.x: handshake TLS cambiato
├── Apache: mod_wsgi vs mod_php vs FastCGI — ognuno un universo
├── Python: dipendenze che confliggono con quelle di sistema
├── SSH: comportamenti diversi su kernel diversi
└── La distro: Debian 11, 12, Ubuntu 22.04, 24.04…
Chi lavorava negli anni ’80 e ’90 su ambienti coerenti — Clipper su DOS, Turbo Pascal su DOS — non aveva questo. Compilavi, giravi. Il problema era il tuo problema, non l’ecosistema intorno al tuo problema.
Il web ha reso tutto questo esponenzialmente peggiore. È cresciuto per accrezione caotica, non per design: HTML per i documenti statici, JavaScript aggiunto come rattoppo interattivo, CSS come strato separato, PHP come colla server-side, JSON come sostituto di XML che era già un compromesso, e poi framework sopra framework per nascondere il disastro sottostante. Sei linguaggi che fanno cose che un unico ambiente coerente avrebbe potuto fare meglio.
Delphi con le VCL era architetturalmente più pulito di qualsiasi stack web moderno. Non è nostalgia — è vero.
E poi c’è Android. com.example.android.bluetoothadvertisements. Quella stringa dice tutto: sei entrato in un ecosistema proprietario con strati di astrazione che devi accettare per fede. Non capisci — ti adatti. È l’opposto dell’approccio che ho sempre avuto: capire fino al ferro.
L’IA come livello di astrazione finalmente utile
Qui arriva il rovesciamento che non mi aspettavo.
Ho sempre diffidato delle astrazioni che non capivo. La OOP la capisco ma non mi appartiene. Il web lo capisco ma lo trovo caotico. Gli ecosistemi mobile li capisco ma li rifiuto per principio.
Ma Claude — e gli strumenti di IA generativa in generale — rappresentano un tipo di astrazione diverso. Non mi nascondono la complessità accidentale: me la navigano.
La differenza è sottile ma fondamentale. Quando uso un framework che astrae Apache, non capisco più cosa sta facendo Apache. Quando chiedo a Claude “ho PostgreSQL 15 su Ubuntu 22.04 con Apache 2.4, come configuro la connessione dal modulo Python?”, ottengo una risposta che tiene conto di tutte le specificità di quell’ambiente preciso — incluse le trappole che solo chi ha già sbattuto la testa conosce.
L’IA non sostituisce la comprensione. La amplifica.
E qui emerge qualcosa che quasi nessuno dice: l’IA non è uno strumento per i principianti che non sanno programmare. È uno strumento che restituisce produttività ai veterani esperti.
Un principiante che usa Claude produce codice che non capisce. Può funzionare, ma è fragile — al primo errore non sa dove mettere le mani.
Un veterano che usa Claude sa esattamente cosa vuole, sa riconoscere se la risposta è corretta o sbagliata, sa fare le domande giuste. Io so cosa deve fare il mio programma. So come deve interagire con PostgreSQL. So cosa mi aspetto dalla gestione della memoria. Non so a memoria la sintassi esatta di mod_wsgi su questa versione di Apache — ma so valutare se quello che Claude mi dà è sensato.
È la differenza tra un chirurgo esperto che usa uno strumento nuovo e un ragazzo che impugna un bisturi per la prima volta.
Un livello unificato e astratto: la visione
L’idea che mi affascina, e che sto esplorando, è questa: usare l’IA come livello di programmazione unificato sopra il caos frammentato degli ecosistemi moderni.
Invece di diventare uno specialista di HTML, CSS, JavaScript, PHP, Apache, PostgreSQL, OpenSSL, SSH e le loro infinite combinazioni di versioni — mantengo la mia logica ad alto livello, procedurale, chiara, e uso Claude come traduttore verso gli strati sottostanti.
Non è pigrizia. È ingegneria del software applicata alla complessità accidentale: la incapsulo nello strumento giusto e mi concentro sul problema essenziale.
Il mio codice Python resta procedurale, lineare, leggibile. La logica di business è mia, chiara, controllata. Le traduzioni verso il web, verso le API, verso le configurazioni di sistema — le gestisco con un interlocutore che conosce quegli ecosistemi meglio di quanto li conoscessi io quando li usavo ogni giorno.
Conclusione: i paradigmi non muoiono, si specializzano
Dopo quaranta anni ho imparato una cosa: i dogmi nella programmazione sono quasi sempre sbagliati.
La OOP non è superiore al procedurale. Il procedurale non è superiore alla OOP. Sono strumenti diversi per problemi diversi, nelle mani di menti diverse.
Quello che è cambiato — e che l’IA accelera — è la possibilità di scegliere il proprio paradigma di pensiero senza essere penalizzati dall’ecosistema tecnologico che lo circonda.
Per decenni, per lavorare sul web dovevi pensare come il web: frammentato, stratificato, incoerente. Per lavorare su Android dovevi pensare come Android: incapsulato, gerarchico, proprietario.
Oggi posso pensare come ho sempre pensato — lineare, procedurale, con la chiarezza di chi ha scritto un CAD proiettivo geometrico in Turbo Pascal come tesi — e usare l’IA per tradurre quella chiarezza verso qualsiasi ecosistema mi serva.
Non so se questa è la risposta definitiva. So che è la più onesta che ho trovato finora.
Scritto in collaborazione con Claude (Anthropic) — non per nascondere la complessità, ma per navigarla insieme.