The Old Intense Minimalism

Usabilità del Codice, o “Quante righe di codice per una iterazione”

Usabilità, user interaction, user experience. Tutte parole che in quest’ultimo periodo si sentono sempre più spesso all’interno dei gruppi di lavoro almeno per quanto riguarda l’informatica. Fortunatamente. Nomi ormai famosi costituiscono gli evangelizzatori di quella che si può chiamare una rivoluzione: Jakob Nielsen, Donald Norman, Jef Raskin (giusto per citarne alcuni, se pensate me ne sia scordato qualcuno segnalatemelo pure).

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.