[BP21k] Garbage Collection – Note sull’estetica della Programmazione (Bauhaus Programming)

La “qualità del software”, definita nei voluminosi standard ingegneristici dell’ISO (ad es. ISO 9126), ha un insieme vasto di proprietà che vanno dalle caratteristiche operazionali di efficienza e funzionalità, ma anche di affidabilità e di usabilità, a quelle di gestione successiva del progetto come, appunto, la manutenibilità e la portabilità.

Gran parte del lavoro di un informatico, molta parte del suo curriculum professionale e la sua pratica quotidiana, si sofferma in essenza solo sulle prime due caratteristiche. Ottenere codice funzionante e occuparsi di questioni di ottimizzazione ed efficienza dei programmi sembra essere il costante obiettivo di ogni progetto di programmazione. Anche l’insegnamento della “scienza dei computer” relega tutto il resto o a branche specifiche e non comuni o addirittura ne delega l’apprendimento all’autonoma scoperta del programmatore. Questo addirittura aggravato dall’approccio materialistico dei corsi universitari di Ingegneria del Software che ‘stressano’ le qualità scientifiche più misurabili della programmazione come scienza, estendendone la portata fino alla definizione formale, ma senza occuparsi della programmazione vera e propria, o facendolo con una sorta di fastidio neppure ben celato.

L’impegno dei corsi di Ingegneria del Software si traduce troppo spesso nell’esasperata affermazione di modelli formali di specifica e progettazione, quasi mai rispondenti alle esigenze né dei programmatori, né delle aziende di dimensione compatibile con quelle sul mercato, e sicuramente non della situazione socio-politica europea. Adattibili forse ad una applicazione nelle poche grandi realtà di sviluppo concentrate. Queste conoscenze, non affatto disprezzabili, sembrano però maggiormente funzionali ad una parcellizzazione non più realistica del lavoro informatico e quindi, “venduti” quali strumenti per un migliore inserimento lavorativo del programmatore, ne candidano piuttosto all’esclusione dalla pratica.

Nel mondo reale però, nella disequazione tra Arte e Scienza, il primo termine continua ad avere molto maggiore appeal anche grazie alla straordinaria affermazione degli approcci “a codice aperto” (non necessariamente liberi, si pensi allo Shared Source di Microsoft o alla tradizione ben viva negli Unix proprietari, nei sistemi mainframe IBM, o anche nella programmazione con Matlab di fornire all’utente tutto il codice sorgente, senza per questo abbandonare il controllo stretto sull’utilizzazione economica del codice).

Infinti sono i richiami alla “Arte della Programmazione”, dai classici libri di Donald Knuth sulla realizzazione degli algoritmi, alla recente pubblicazione di “Art of Unix Programming” di Eric S. Raymond, principale animatore culturale dell’approccio commerciale Open-Source, passando per l’infinita teoria di Arti, della compilazione, del debugging, senza dimenticare l’infinita teoria dei “Manuali di Stile”, o le Style Guidelines, ecc. ecc.

Questa serie di interventi vuole affrontare il problema delle qualità estetiche della programmazione. Abituati alle roboanti meraviglie offerte dai produttori di strumenti di programmazione che promettono di fare sempre di più con meno impegno, molti professionisti del settore considerano poco importanti e superflue queste considerazioni. D’altronde è chiaro: un “bel programma” non funzionante non ha alcuna qualità.

Eppure il legame tra la qualità estetica di un programma e la sua funzionalità potrebbe non essere cosí labile come sembra a prima vista se, e tale è la tesi di questo lavoro, il successo attuale della programmazione è essenzialmente un successo di estetica.

La ‘bellezza’ è connaturata a tutta quella serie di proprietà non funzionali del software che sono solitamente trascurate, e le ricette che l’Ingegneria del Software o le tradizioni della buona programmazione offrono ai programmatori spesso non sono altro che ‘pensieri artistici’ trasposti nel campo della produzione del codice.

Vedremo quindi in queste pagine, tecniche banali e faremo semplici e pratiche considerazioni per migliorare lo “stile di programmazione”, consapevoli che sempre di più, la disponibilità di codice sorgente, sia esso coperto da licenze libere, che da licenze non libere ma di pubblica consultazione, come la Shared Source di Microsoft, espone il codice al “pubblico ludibrio” e racconta del suo autore o della sua organizzazione ancor di più di quanto non faccia l’esecuzione o la facciata esterna di un programma.

Un giorno forse i codici sorgenti saranno tutti disponibili e le qualità estetiche di un programma, la leggibilità dei commenti, la coordinazione del testo, e la strutturazione complessiva del progetto potranno essere un elemento discriminante nel confronto e nella selezione del software tanto quanto oggi lo sono la robustezza e la funzionalità. Allora forse esisterà una poetica formalizzata, di scuola, della produzione informatica. Oggi tutto questo va proposto come un tentativo e il relativo errore in un pericoloso equilibrismo tra la storia delle arti applicate e la pratica della programmazione moderna.

Al lettore il giudizio sull’adeguatezza di questo lavoro.

Roma, 10 Marzo 2002

Categories: Computer Society, programming, Scritture

Leave a Reply

Your email address will not be published. Required fields are marked *