Perché pensiamo come programmiamo: la fine dell’oggetto e l’illusione della mente modulare

C’è un’idea tanto affascinante quanto scomoda, espressa con lucidità e ironia da Marco Giancotti in un recente post (Aether Mug Subscribe newsletter.): forse gli ingegneri del software, nel tentativo di costruire programmi più intelligenti, hanno finito per scoprire un modo di rappresentare la mente umana. L’intuizione nasce dal parallelo tra il Unified Modeling Language e i meccanismi del pensiero: come se il nostro cervello ragionasse in diagrammi UML, con classi, relazioni e astrazioni. È un’immagine irresistibile, perché ci restituisce una verità troppo spesso ignorata: non programmiamo solo le macchine, programmiamo anche noi stessi.

La programmazione a oggetti nacque per mettere ordine nel caos del codice procedurale, quello fatto di sequenze e istruzioni che si incastravano come fili di spaghetti. Poi arrivò la rivoluzione: creare oggetti, entità con proprietà e comportamenti, capaci di agire, comunicare, interagire. Un modo di pensare più umano, più narrativo, più intuitivo. Come racconta Giancotti, passare da “aggiungi X a Y” a “usa il metodo aggiungi dell’oggetto carrello” fu una svolta semantica prima che tecnica. L’oggetto diventava un simbolo mentale, un frammento di mondo codificato.

E qui scatta la magia: la programmazione a oggetti ha funzionato perché riflette la nostra architettura cognitiva. Noi non vediamo processi, vediamo cose. Non percepiamo flussi di informazione, ma entità discrete, dotate di identità e di confini. È il modo in cui il cervello riduce la complessità della realtà, come se ogni classe fosse un concetto mentale e ogni istanza un’esperienza. Il linguaggio, che chiama “persona”, “albero”, “nemico”, ciò che in realtà è un campo di relazioni e mutazioni, è la prima forma di programmazione a oggetti mai inventata.

La filosofia di OOP seduce perché ci illude di poter mappare la complessità del mondo con la semplicità di una gerarchia. Ci piace pensare che esistano super-classi e sotto-classi, concetti generali e derivazioni specifiche, in una genealogia perfetta delle idee. È l’eco della tassonomia aristotelica travestita da architettura software. Ma, come sottolinea Giancotti, questa visione entra in crisi non appena le astrazioni si moltiplicano. L’albero genealogico delle classi diventa una giungla logica, e la promessa di ordine si trasforma in labirinto. A quel punto la mente si ribella: il paradigma che sembrava naturale diventa una gabbia.

La programmazione funzionale appare allora come un antidoto. Non più oggetti che fanno cose, ma funzioni che trasformano dati. È un modo di pensare il software — e la realtà — come un flusso continuo di trasformazioni, dove tutto cambia e nulla possiede un’identità stabile. È un’idea quasi eraclitea, perfettamente coerente con la fisica contemporanea e con la visione sistemica delle reti. Ogni funzione è un piccolo motore di cambiamento, e il programma intero è una pipeline di metamorfosi.

Eppure, come confessa lo stesso Giancotti, questo paradigma resta ostico. È troppo alieno rispetto al nostro modo di pensare. Noi non vediamo funzioni, vediamo oggetti. Non riconosciamo il mondo come flusso, ma come sequenza di entità distinte. È un limite biologico, non solo culturale. Il cervello umano è un compilatore obsoleto, ottimizzato per sopravvivere nella savana più che per comprendere l’entropia dell’universo.

La programmazione funzionale funziona — ironia del linguaggio — proprio perché è meno antropocentrica. È una descrizione più fedele della realtà, ma meno compatibile con la mente che la osserva. Nel mondo tutto scorre, ma la mente blocca, incapsula, chiude in classi e oggetti ciò che dovrebbe restare in movimento. In questo senso, OOP non è solo un paradigma tecnico: è una forma di psicologia cognitiva applicata. È la proiezione del nostro bisogno di stabilità in un universo che non ne offre.

Quando Giancotti scrive che “gli ingegneri, nel cercare di costruire programmi migliori, hanno scoperto un modo ideale per rappresentare la mente umana”, coglie la contraddizione essenziale del pensiero tecnologico. Il codice, come la mente, oscilla tra il desiderio di ordine e la resa al caos. L’oggetto è il nostro compromesso: un piccolo pezzo di realtà che finge di essere autonomo, ma vive solo nelle relazioni che lo attraversano. Come noi.

Ciò che rende questo parallelo così affascinante è che si estende ben oltre il software. Pensiamo in modo object-oriented anche nella politica, nell’economia, nella comunicazione. Creiamo classi concettuali e istanze narrative per semplificare ciò che non comprendiamo. Parliamo di “mercati”, “aziende”, “utenti” come se fossero entità monolitiche, dimenticando che sono reti di processi, differenze, flussi. È lo stesso errore cognitivo che porta i programmatori a confondere l’astrazione con la realtà.

La programmazione funzionale, con la sua ossessione per le trasformazioni pure e l’assenza di stato, è invece più vicina al modo in cui operano i sistemi complessi. È il linguaggio naturale delle AI generative, che apprendono relazioni e non categorie, pattern e non oggetti. Il modello linguistico non “pensa” a una persona, ma elabora vettori di significato che si trasformano continuamente. In un certo senso, l’intelligenza artificiale è la vendetta della programmazione funzionale contro la mente umana.

Ma ecco il paradosso: per spiegare la programmazione funzionale usiamo ancora metafore a oggetti. Parliamo di “funzioni”, “dati”, “flussi” come se fossero cose. Il nostro linguaggio è irrimediabilmente orientato agli oggetti, anche quando tenta di superare se stesso. È come voler spiegare la fluidità del tempo con fotografie statiche. Non c’è scampo: ogni volta che cerchiamo di rappresentare il movimento, lo congeliamo.

Forse, come suggerisce implicitamente Giancotti, l’unico modo per uscire da questa illusione è accettarla. Accettare che nessun paradigma potrà mai rappresentare perfettamente la realtà, così come nessun modello mentale potrà mai essere neutro. L’ingegnere deve convivere con la tensione tra precisione e intuizione, tra la freddezza della funzione e il calore dell’oggetto. La mente deve accettare che pensa male, ma pensa abbastanza bene da funzionare.

È curioso che, dopo decenni di teorie, linguaggi e metodologie, la lezione più profonda venga da un semplice confronto fra UML e il pensiero umano. Il diagramma delle classi è, in fondo, una mappa della nostra psiche: le linee d’ereditarietà come genealogie concettuali, gli attributi come tratti di personalità, i metodi come comportamenti sociali. Non è solo un modello del codice, ma un autoritratto in forma algoritmica.

Forse il futuro non sarà né oggettuale né funzionale, ma ibrido, come sempre. Una mente capace di modellare oggetti e trasformazioni, concetti e flussi, secondo la necessità del contesto. Un pensiero che impari a vedere negli oggetti la finzione utile che sono, e nei processi la realtà che li attraversa.

La verità, come spesso accade, è che non smetteremo mai di programmare come pensiamo. E forse non è un male. Perché ogni bug del nostro codice mentale è anche una traccia di umanità, una prova del fatto che, pur circondati da astrazioni e algoritmi, restiamo esseri imperfetti che cercano disperatamente di mettere ordine nel caos.

(Citazione e ispirazione: Marco Giancotti, “A couple of weeks ago I shared an attempt at visualizing framings and models…”, pubblicato su Aether Mug) Subscribe to this newsletter.