Ormai è persa nei meandri della memoria, non so dove l’abbia letta o come l’abbia formulata, non so la sua origine. Uno dei concetti che più ha influenzato il mio stile di programmazione attuale è riassunto nella frase:

Se stai scrivendo la stessa cosa due volte, c’è qualcosa di sbagliato

Il concetto è una estremizzazione utopica, ovviamente è impossibile applicarla nella sua totalità. La trovo però di particolare rilevanza per la sua portata estensiva su più livelli e per la sua leggera carica provocatrice.

Il concetto da cui nasce è che la programmazione, per sua stessa natura, è un algoritmo in grado di eseguire automaticamente processi ripetitivi e meccanici.
Sarebbe stupido se un programmatore lavorasse per automatizzare processi, e non riuscisse ad automatizzare il codice stesso che sta scrivendo. Non sarebbe un controsenso?

La portata di questa frase è notevole perché impone di riflettere sull’impatto globale che ogni singola riga di codice porta con sé: nell’istante in cui ci si accorge che si è appena scritto qualcosa che esiste con quello stesso significato altrove, immediatamente dovrebbe scattare una riflessione. Ci si dovrebbe chiedere a questo punto:

1. Posso accorpare le due righe di codice in una funzione richiamata nei due punti?
2. C’è una logica ad un livello superiore di astrazione che mi è sfuggita?
3. Ha senso farlo?

Le tre domande non sono banali, soprattutto se vi abituate a farvele in ogni istante. Derivano tutte dalla frase sopra riportata, esplicandone il significato simbolico.

La realizzazione di una funzione è già di per sé una forma di astrazione: il codice ‘grezzo‘ viene ‘promosso‘ e si astrae nella funzione corrispondente. Questo processo è più interessante di quello che può sembrare perché implica anche ottimizzazione: quali sono i parametri che tale funzione richiede per funzionare? Posso minimizzarli?
E’ interessante anche perché è indipendente dal paradigma di programmazione che si utilizza, che sia funzionale o a oggetti. Lo scopo è salire un gradino nella scala dell’astrazione, semplificando da quel momento in poi la scrittura di quel particolare codice.

La riflessione su una logica superiore di astrazione è egualmente importante, perché nel momento in cui ci si accorge che si sta replicando funzionalità (anche se il codice non è identico 1:1) è possibile che sia solo la punta di un concetto molto più ampio che potrebbe essere astratto e non solo di quella specifica funzionalità

Domandarsi infine se ha senso è rilevante perché rappresenta la possibilità di valutare possibili aspetti negativi dell’astrazione. A volte non ha davvero senso astrarre quel pezzo di codice. Altre volte i vantaggi apportati sarebbero minori degli svantaggi. Oppure si rischierebbe di rovinare una struttura semplice, elegante e leggibile. Soprattutto in quest’ultimo caso, ritengo che “una ripetizione” non sia sufficiente a giustificare il cambiamento.

Se notate quella banale frase che mi si fissò nella mente quasi 10 anni fa è analoga ai principi DRY (Don’t Repeat Yourself) e anche ad alcune parti della Extreme Programming.

Astraiamo? Già il fatto che questo concetto sia indipendente dallo stile di programmazione utilizzato è significativo, non è obbligatorio programmare a oggetti per farlo.
Astraiamo? Il concetto non è strettamente inerente alla programmazione! Potrei in questo senso citare Maeda e il concetto di Simplicity che porta con sé.
Astraiamo? Potremmo risalire e scoprire che per esempio la ripetizione meccanica è qualcosa di innaturale (i.e. Tempi Moderni). Il nostro organismo è una infinità di strati biologici con livelli di astrazione crescente.

Rivoluzione che in altri termini può essere pensata come un ritorno alle origini, ma standardizzato in formalismi: in fondo un eccellente artigiano sapeva già queste cose, senza saperle. Oggi si tenta di insegnarle, anche in vece della quantità di persone che bisogna addestrare in merito.

Tutto splendido, se pensate a quante volte avete bestemmiato davanti al manuale per programmare il videoregistratore o quante volte vi siete fermati davanti ad un messaggio di Windows che vi chiedeva “Sei sicuro? Annulla, Riprova, Tralascia”.

Ma nell’informatica vi è un aspetto che viene in apparenza completamente ignorato anche dalle persone di cui sopra: è vero che su un computer ci girano un sacco di programmi fatti per non tecnici, come ad esempio Word… ma d’altronde questi sono necessariamente realizzati da due altri strumenti: un editor e un linguaggio di programmazione.

Salvo pochissimi miglioramenti soprattutto avvenuti negli ultimi anni e comunque di importanza quasi del tutto marginale, gli sviluppatori ancora realizzano programmi fondamentalmente con degli editor testuali, scrivendo a mano del testo chiamato codice sorgente.

Gli Editor

Vorrei quindi pormi ad osservare l’usabilità di questa coppia di elementi. Partiamo osservando gli IDE (Integrated Development Environment) che vengono utilizzati per programmare. Lungi da me voler realizzare une recensione dei più famosi (cito giusto per conoscenza Visual Studio, Eclipse, Zend Studio) che porterebbe via molto tempo e spazio, vorrei però porre l’attenzione sul fatto che questi IDE non portano tanto miglioramenti alla scrittura, quanto a tutto il contesto di sviluppo (debuggers, database, wizards, object browsers, integrated documentation, …).

La mia analisi però vorrebbe concentrarsi solamente sull’editor, ovvero la finestra contenuta anche in ogni IDE che consente la scrittura del codice. Ad oggi, credo che gli unici miglioramenti significativi in questo ambito siano stati:

1. Le inline code suggestions, ovvero delle finestrelle che si aprono mentre si scrive il codice contenenti le varie possibilità disponibili a riguardo di quello che si sta scrivendo (es. scrivendo Form1., dopo il punto appariva una finestrella sotto la riga di testo che mostrava tutti gli attributi, le funzioni e gli oggetti disponibili sul Form1). Prima apparizione mainstream credo in Visual Basic 4, nel 1995.
2. I foldable blocks, ovvero la possibilità di “chiudere” un blocco di codice in modo che appaia solamente la sua prima riga (es. chiudere una funzione mostra la dichiarazione della funzione e dei puntini che indicano che vi è altro). Prima apparizione mainstream credo in Visual Studio .Net, nel 2002.

Ad oggi credo che l’editor per programmatori più usabile in assoluto sia TextMate. Si, prendetemi pure per un Mac Fanatic ma è un editor solamente per Mac. Se avete capito che non sono un Mac Fanatic, vi verrà il dubbio che forse non è un caso che tale editor (peraltro, recentissimo come sviluppo) esista proprio su Mac.

Evitando ancora una recensione di questo software e rimanendo in tema, è abbastanza evidente come praticamente nessuno abbia mai pensato in modo continuo e coerente su come migliorare l’usabilità degli editor testuali: ad oggi un IDE è fatto “da ingegneri per ingegneri”, ovvero l’importante è avere una feature, non come questa viene resa disponibile.

Il Linguaggio

Esistono una quantità enorme di linguaggi di programmazione. Volendomi soffermare ad enumerare solamente quelli che ho avuto modo di conoscere personalmente, la lista è già parecchio lunga: Basic, Pascal, C, C++, Visual Basic, ObjectiveC, Assembly, Lisp, Prolog, C#, Perl, PHP, JavaScript, Python, Ruby, Java, …sicuramente ne ho scordati alcuni.

Perché esistono tanti linguaggi? Perché i creatori di ciascuno pensavano, in un modo o nell’altro, di realizzare un linguaggio “migliore” oppure “più adatto ad uno scopo specifico”. Queste sono a mio avviso le due cause primarie, ma cosa rende un linguaggio “migliore”? cosa lo rende “più adatto”?

La motivazione alla base dell’evoluzione dei linguaggi è quella di rendere più semplice la scrittura di un buon programma allo sviluppatore. Come potete notare anche questa definizione senza pretese va a scontrarsi contro una serie apparentemente infinita di domande: cosa significa “rendere più semplice”? cosa definisce un “buon programma”?

Qui si rischia di cadere in una spirale di definizioni, pignolerie e vere e proprie filosofie, cosa che vorrei evitare. Personalmente mi accontento di dire che:

• Rendere più semplice la scrittura di un programma significa diminuire il tempo necessario per la stesura di un ipotetico programma a parità di funzionalità.
• Un buon programma è invece un programma veloce, stabile e che soddisfa le necessità dell’utente, rimanendo però facilmente manutenibile dall’autore.

Qualcuno più, qualcuno meno, conosco tutti i linguaggi sopra elencati. Recentemente mi è capitato di dover realizzare una cosa semplicissima con PHP, JavaScript, Python e Ruby così a memoria, ma questa volta in Java.

Ovvero, realizzare un array associativo (hash). Per chi non lo sapesse, significa creare un elenco di elementi, ognuno dei quali è identificato da una etichetta.

Vediamo quindi nei linguaggi qui citati come si esegue il terzetto dichiarazione + inserimento + iterazione:

PHP

$array = array();
$array['saluto'] = "Ciao!";
foreach ($array as $key => $value) {
...$key...$value...
}

JavaScript

var a = new Array();
a['saluto'] = "Ciao!";
for (var key in a) {
...key...a[key]...
}

Python

a = {}
a['saluto'] = "Ciao!"
for key, value in a.iteritems():
...key...value...

Ruby

a = {}
a['saluto'] = "Ciao!"
a.each { |key, value|
...key...value...
}

Java

Map a = HashMap();
a.put("saluto", "Ciao!");
for (Iterator iter = map.entrySet().iterator(); iter.hasNext();)
{
Map.Entry entry = (Map.Entry)iter.next();
String key = (String)entry.getKey();
String value = (String)entry.getValue();
...key...value...
}

Notate differenze?

Una obiezione che mi si potrebbe fare è che sto confrontando un linguaggio fortemente tipizzato (ovvero, la dichiarazione delle classi è obbligatoria) con linguaggi non tipizzati o debolmente tali.

L’obiezione è naturalmente valida per quanto riguarda la lunghezza delle linee di codice, non per la quantità di istruzioni, ed è egualmente notabile come il comando “for” per la sintassi Java impacchetti due istruzioni in una sola riga e non sia egualmente un costrutto nativo.

Aggiungiamo che le iterazioni sono un elemento piuttosto importante ed utilizzato nei linguaggi di programmazione e capiamo rapidamente come Java, per quanto sia un linguaggio valido, non è stato studiato minimamente per essere piacevole a scriversi.

Al contrario, questo risulta essere uno dei primi obiettivi di Python, linguaggio che segue una filosofia piuttosto distintiva, che al punto 7 cita: “Readability counts.“.

La domanda sulla quale vorrei fare riflettere ora è: quanto credete sia manutenibile un codice come quello che si è costretti a scrivere con Java, rispetto ad un equivalente teorico di Python? (Nota: dico teorico perché i due linguaggi non coprono esattamente gli stessi ambiti di sviluppo, per quanto alcuni si sovrappongano).

E questa non è questione di “cosa consente di fare il linguaggio” o di “Java però è stato fatto per consentire una maggiore scalabilità”, è pura questione di usabilità del codice, o per usare un neologismo inglese, quella che chiamo code usability.

Mi sto dilungando troppo, interrompo qui questa prima dissertazione che mi pare di aver comunque messo sufficiente carne al fuoco.