Ogni volta che apro il mio IDE (Integrated Development Environment) avverto una sensazione di ordine e bellezza. Le righe di codice si dispongono sullo schermo con un ritmo visivo misurato, i caratteri si allineano perfettamente, e i colori del mio tema – un gioco di sfumature tra blu, verde e rosso – accompagnano il mio lavoro con un certo grado di intensità emotiva. Per chi programma, questo tipo di esperienza non è raro: l’estetica del codice è altresì parte integrante del processo tecnico-creativo. Tuttavia, a livello teorico il legame tra l’atto del programmare e la sua emotività estetica, o “emostetica”[1], resta un aspetto pressoché inesplorato, sicuramente più invisibile rispetto alla centralità delle questioni tecniche. E se la programmazione è spesso percepita come un’attività puramente logica, in questa sede si propone quanto in realtà quest’ultima coinvolga profondamente sensi e immaginazione – con un’ulteriore riflessione sullo “statuto ontologico” del codice stesso. Procedendo progressivamente sulla base di tre domande che ritengo fondamentali, non intendo dare alcuna risposta definitiva, bensì semplici spunti di riflessione.

 

Quanto del mondo digitale è progettato per ispirare, oltre che per servire?

Passando dai terminali a schermo nero con testo bianco agli IDE moderni completi di varie opzioni di personalizzazione, gli ambienti di sviluppo hanno subito nel corso del tempo un’evoluzione significativa. Negli anni ’70 e ’80, infatti, gli sviluppatori utilizzavano editor di testo basilari su terminali monocromatici; all’interno di questo contesto nacquero piattaforme come Emacs (1976) e Vim (1991) che, pur operando sempre in ambienti testuali, offrivano potenti funzionalità di modifica e personalizzazione attraverso script e macro. Definiti “ambienti operativi in miniatura” (Petzold, 1999), grazie alla loro estendibilità si trovano oggi nella terra di mezzo tra editor basilari e IDE, ed entrambi sono ideali per lavorare in ambienti con risorse limitate o su server remoti, in quanto incredibilmente leggeri in termini di risorse rispetto agli IDE moderni (si veda Visual Studio Code o PyCharm). Ad oggi, elementi apparentemente funzionali influenzano di fatto la percezione totale della programmazione, trasformandola in un’esperienza che trascende il puro tecnicismo. In questo contesto, il syntax highlighting (Bentley, 2006) è una delle caratteristiche più distintive degli ambienti di sviluppo moderni: attraverso l’utilizzo di colori diversi per distinguere elementi come parole chiave, stringhe, commenti e variabili (innegabilmente evidenziare la sintassi facilita la comprensione e velocizza il debug), questo strumento non solo migliora la leggibilità del codice, ma crea anche una sorta di linguaggio visivo che aiuta lə programmatorə a orientarsi e a ridurre gli errori. Ad esempio, i temi più popolari come Monokai, Solarized o Dracula sono progettati con una palette cromatica che mira a ridurre l’affaticamento visivo e a ottimizzare la concentrazione. 

Com’è noto, numerosi studi sulla percezione visiva e sul carico cognitivo confermano che i colori influenzano la nostra capacità di concentrazione (Wright, 1998). Toni morbidi e contrasti bilanciati migliorano la leggibilità e favoriscono uno stato mentale di flow, condizione in cui la mente è completamente immersa nel compito da svolgere; così, il syntax highlighting diventa un mezzo per creare un ambiente mentale ed emotivo ideale per la programmazione. Si potrebbe obiettare che questa crescente tendenza alla personalizzazione dell’interfaccia, a discapito della standardizzazione funzionale, possa innescare una perdita di efficienza a livello lavorativo, o che questo eccessivo riflesso di soggettività dellə programmatorə rispecchi una semplice — seppur pericolosa — volontà di umanizzare un ambiente di lavoro intrinsecamente freddo e astratto. 

Una seconda questione centrale è quella del font. La maggior parte dellə programmatorə personalizza il proprio IDE con un font monospace, in cui ogni carattere occupa lo stesso spazio. Questa caratteristica è essenziale per mantenere allineamenti precisi e favorire la leggibilità, ma non solo: anche in questo caso possiamo considerare che l’impatto del font vada oltre la pura funzionalità. Infatti, la tipografia del codice contribuisce a creare un ritmo visivo che è, di per sé, un’esperienza estetica. Font come Fira Code, JetBrains Mono o Source Code Pro sono apprezzati non solo per la loro chiarezza, ma anche per il loro design. Le linee pulite e le proporzioni armoniose creano un senso di ordine che rispecchia la prima essenza del codice: una struttura logica che si manifesta attraverso simboli visivi. Il font diventa, in ultima analisi, un ponte tra l’astrazione del linguaggio-macchina e l’umanità di chi scrive. Lentamente la linea di demarcazione tra le due entità si assottiglia.

L’IDE dunque non è solo uno strumento, ma innanzitutto uno spazio in cui lə programmatorə trascorrono lunghe ore; allora diventa chiaro come la sua progettazione influenzi profondamente l’esperienza di utilizzo. La disposizione dei pannelli, le transizioni visive, la scorrevolezza del cursore: si potrebbe concludere che l’interfaccia si presenti come una vera e propria estensione del corpo dellə programmatorə, in quanto riflesso di tendenze culturali e tecnologiche personali. Ogni IDE è, in fondo, un piccolo mondo virtuale costruito per soddisfare le esigenze dell’utentə. Così l’enfasi attuale sulla personalizzazione è il segno di un’evoluzione che mira a trasformare la programmazione in un’esperienza in cui l’efficienza non è separata dalla bellezza, concetto già presente nel famoso Zen di Python, una raccolta di diciannove principi guida[2] nella “ricerca della bellezza” nel codice creata da Tim Peters nel 1999. Alcuni di questi riportano diciture come: “Beautiful is better than ugly”, “Simple is better than complex”, “Readability counts” [3] (e il codice che si allinea a questi principi viene spesso definito “pythonic”).

 

Gli strumenti tecnologici sono una finestra sul possibile?

Il codice può essere considerato una forma di composizione. In particolare, il movimento del creative coding[4] esplora il potenziale estetico e creativo del software, e in questo senso l’utilizzo dei linguaggi di programmazione è applicato principalmente per creare arte visiva, musica, installazioni etc. Framework come Processing, p5.js e OpenFramework sono stati progettati proprio per assecondare questa finalità. Artistə e sviluppatorə hanno creato visualizzazioni generative che trasformano algoritmi in opere d’arte, o installazioni sonore che reagiscono agli input degli utenti: basti pensare a Unnumbered Sparks di Aaron Koblin e Janet Echelman, magma scultoreo fluttuante presentato a Vancouver nel 2014, composto da fibre ottiche luminose il cui comportamento viene controllato in tempo reale dallə visitatorə attraverso i loro smartphone (tramite tecnologie come WebGL e HTML5). Al di là del suo aspetto decisamente kitsch, questo esperimento amplia la nozione di “bellezza” nel codice fino a includere l’espressione individuale e l’interazione socio-sensoriale. Non è un caso che lə programmatorə più accanitə si impegnino sinceramente nel creare il codice più bello possibile, più pulito possibile, più efficace possibile. E non è nemmeno un caso che alcuni metodi o funzioni integrate – nel caso specifico del linguaggio Python – abbiano nomi insoliti ed evocativi, che potrebbero ricordare l’inizio di una partita di Dungeon & Dragons: _init_, frozenset( ), eval( ), raise. Queste nomenclature, al di là della loro funzione tecnica, risuonano con una carica narrativa che sembra umanizzare il linguaggio della macchina facendolo scivolare verso l’immaginario umano.

Ma per quanto sembri un atto di dominio e comprensione, la programmazione è intrinsecamente legata al mistero di ciò che accade sotto la rappresentazione del sistema. Anche lə programmatorə più espertə lavorano entro limiti di conoscenza: ciò che scrivono viene infatti trasformato, eseguito e reinterpretato da processi che non sono sempre pienamente visibili o controllabili, e questo introduce una tensione tra il controllo che si cerca di esercitare e l’opacità del sistema stesso, una scatola nera (black box) dove input e output sono chiari, ma il processo interno rimane solo parzialmente decifrabile. Quando programmiamo, crediamo di dare istruzioni precise alla macchina, ma la realtà è che il sistema opera in strati di astrazione: il linguaggio alto-livello viene compilato in codice macchina, il quale poi viene eseguito da hardware il cui funzionamento è, a sua volta, una scatola nera. Questo significa che, anche se costruiamo il codice come un’architettura logica, di fatto ci affidiamo al sistema per eseguire correttamente il nostro intento. I bug sono un momento di incontro diretto con questa opacità: quando il codice non funziona come previsto siamo costretti a scendere di livello, esplorando i dettagli invisibili o impliciti del sistema. È un promemoria costante del fatto che all’interno dei sistemi sono presenti algoritmi generativi, metodi di apprendimento automatico, semplici interazioni tra moduli software che possono produrre risultati alquanto inattesi. Questo fa sembrare la macchina qualcosa di più di un semplice esecutorə, e il suo risultato qualcosa di più di un prodotto funzionale. 

 

Il significato risiede solo nell’esecuzione?

L’umanizzazione del codice rischia di oscurare una verità fondamentale: il codice non ha bisogno di essere antropomorfizzato per avere dignità. Trovando supporto nell’OOO – Ontologia Orientata agli Oggetti (Harman, 2018), possiamo interpretare il codice come qualcosa che esiste per sé stesso, indipendentemente dalla relazione con l’umano, allo stesso modo di qualsiasi altro oggetto non riducibile alla sua relazione con altri oggetti o soggetti. Nel contesto della programmazione, l’interfaccia è un actant, un attore-non-umano che non è mai neutrale in sé ma viene costantemente modellato dal modo in cui viene utilizzato: non è l’interfaccia in quanto tale a essere antropomorfizzata, ma il nostro approccio a essa che la carica di significati culturali, emotivi, estetici; anche se questo non significa che l’interfaccia sia passiva, ma che al contrario partecipi attivamente all’interazione, condizionando il modo di lavorare, pensare e creare. Questa distinzione è importante perché ci aiuta a vedere il codice e l’interfaccia come qualcosa di più di un’estensione dell’umano. Quando programmiamo e personalizziamo la nostra esperienza, non stiamo semplicemente “umanizzando” le macchine, ma partecipando a un processo in cui creiamo connessioni tra diversi livelli di realtà: il linguaggio umano, il linguaggio del codice, il linguaggio macchina. La programmazione diventa così un dialogo tra entità diverse, in cui ogni parte ha una sua specificità e contribuisce al risultato finale senza essere ridotta o appiattita. 

In definitiva, il codice non si risolve come un ponte tra l’intenzione e il risultato. La programmazione non è solo una questione di output; forse il codice non ha bisogno di un significato ulteriore per giustificare la propria bellezza. E se fosse meno comando e più gesto? In fondo, programmare significa creare strutture che non esistono in Natura, dare forma a qualcosa attraverso un linguaggio scritto per essere eseguito e interpretato, pur mantenendo un margine di imprevedibilità che ricorda quanto il sistema conservi sempre una sua autonomia. Il senso della programmazione si trova nell’oscillazione continua tra il rigore e l’evocazione, e in questa tensione si trova la sua vera bellezza.

Note

[1] Neologismo creato da me.

[2] La lista di Peters lasciò aperto un ventesimo principio da riempire, “for Guido to fill in”, riferendosi a Guido van Rossum, l’autore originale del linguaggio Python. Il posto vacante non venne mai riempito.

[3] Lo Zen di Python si trova contenuto nella Python mailing List del 1999.

[4] Che ha assunto la sua forma più riconoscibile dagli anni 2000.

 

Bibliografia

Bentley, J (2006), Programming Pearls, Dorling Kindersley, Londra.

Harman, G. (2018), Object-Oriented Ontology: A New Theory of Everything, Pelican Publishing, New Orleans.

Petzold, C. (2000), Code: The Hidden Language of Computer Hardware and Software, Microsoft Press, Washington DC.

 

Bio 

Lucrezia Zucconi (Firenze, 1998) vive e lavora a Bologna, dove ha terminato gli studi in Scienze filosofiche. Attualmente si occupa di temi di ricerca quali Natura e nuove tecnologie, con un focus particolare sulle intelligenze artificiali generative. È editor per il magazine berlinese Giri Journal e co-fondatrice dell’associazione culturale GINKGO. In parallelo gestisce un archivio digitale ibrido e open source dal nome cursedinfo.