Extreme Enthusiasm

Summary: A canticle for Leibowitz by Walter Miller Jr. is a very good book. I often think about this story now that small and big countries are hot on nuclear weapons again.

E’ uno dei pochi romanzi di fantascienza che viene correntemente letto da non-appassionati di fantascienza. Scritto negli anni ’50, narra la storia di come la Chiesa Cattolica sopravvive, insieme a pochi scampoli di umanità, a una guerra atomica su larga scala. E’ una storia che mi torna in mente spesso, in questi tempi di tentazioni nucleari di Paesi piccoli e grandi.

Piergiuliano mi ha segnalato una Guida alla lettura in Italiano (attenzione: spoiler.)

Grande fondo di Magdi Allam sul Corriere di oggi.

La decisione americana di ripristinare le relazioni diplomatiche con
la Libia di Gheddafi … Con un brusco rimescolamento delle carte,
Bush ha sostanzialmente infranto il sogno di una rivoluzione democratica.

Tanto parlare della Guerra Al Terrore, e poi si fa la pace con il
terrorista Gheddafi, dittatore e sponsor della strage di Lockerbie.
Perché pace con Gheddafi e guerra con Saddam? Perché i princìpi si
possono invocare o ignorare secondo capriccio?

Just because computers were a liberating force in the past doesn’t mean they will be in the future. There is enormous political and economic power behind the idea that you shouldn’t truly own your computer or your software, despite having paid for it.

Bruce Scnheier, Everyone Wants to ‘Own’ Your PC

+5, Insightful. “Quando la tecnologia serve i suoi padroni, è
libertaria. Quando è progettata per servire qualcun altro, è
oppressiva.”

Ho appena finito di leggere Testing Extreme Programming di Lisa Crispin e Tip House.

Descrive il ruolo dei tester in un team XP. Si concentra quindi sugli acceptance tests. Per me gli AT erano un po’ misteriosi; sono riuscito a praticare bene gli unit test, ma gli AT li ho sempre un po’ trascurati. A volte con risultati disastrosi: una mia debacle è stata dovuta, fra l’altro, al fatto di non avere pronti degli AT che dimostravano che gli interventi tecnici fatti da qualcun’altro sul nostro progetto avevano distrutto 90% delle storie funzionanti. Ma sto divagando.

Il grosso del libro è discorsivo e spiega il ruolo del tester nelle varie fasi del progetto XP. La parte che per me è stata più utile sono invece i brevi capitoletti su come tecnicamente realizzare gli AT. Lo stile che viene presentato qui è assurdamente semplice, e per questo mi piace molto!

In pratica gli AT vengono realizzati con JUnit, con la differenza che si cerca di renderli il più possibile vicini al linguaggio del cliente, con cui sono espresse le user stories. Ho cercato di applicare questa lezione nel progettino che stiamo realizzando nell’XP user group di Milano.

Per esempio, la user story Pagina contenente le news ha un test di accettazione che dice, in italiano:

IF una news è presente nel sistema THEN appare nella pagina

Riscritto in JUnit diventa:

public void testIfInseritaThenAppare() {
  insertNews("Titolo", "Testo testo testo", 
             insertedToday(), expiresTomorrow());
  assertEquals(1, numberOfNewsInPublicPage());
  assertNewsPresent("Titolo", "Testo testo testo", 
                    insertedToday());
}

Forse si può migliorare ancora, ma mi sembra che il codice parli a sufficienza.

UPDATE: Gabriele (sempre lui!) mi ha segnalato questo articolo: Literate
Programming with jMock. Molto carino: presenta tecniche su come
rendere gli acceptance test sempre più parlante, sempre più
vicino a qualcosa che si legga come lingua naturale.

Non sono convintissimo che sia questo però quello che Knuth aveva in
mente quando parlava di literate programming. Lui si preoccupava
soprattutto di cose come il fatto che i commenti fossero dentro al
codice, piuttosto che essere il codice dentro a un documento
leggibile dagli esseri umani. Giustissimo! Ad esempio, anche se il
codice di un dato programma è scritto benissimo, in generale non è
chiaro da dove mi conviene iniziare a leggerlo. In literate
programming, l’autore prepara un percorso di lettura ideale, che non
necessariamente parte con il main.

L’ideale di codice parlante degli XPer invece è una cosa diversa.
Si tratta di limare e ripulire il codice fino a quando non
c’è bisogno di altri commenti. Il codice di Knuth non è
esattamente leggibile. Anche il linguaggio TeX, che Knuth ha
inventato, è molto poco leggibile. Credo che gli XPer facciano cose
che sono nello spirito di LP, ma molto diverse nell’esecuzione.

Ricordo una discussione che ebbi con Yuri Gurevich a proposito della linea di ricerca che seguivo, ai tempi in cui ero studente di dottorato. Lui mi attaccava dicendo che il mio lavoro sulla derivazione di programmi non valeva nulla, in quanto non è possibile definire il successo. Gurevich era particolarmente veemente nei suoi attacchi in quanto apparteneva a una parrocchia di ricerca diversa; in sostanza non apprezzava la tradizione di Dijkstra quanto l’apprezzo io. Gli tenni testa (di fronte agli altri studenti di dottorato che ci osservavano un po’ stupiti, non capendo il perché dell’animata, per quanto civilissima, diatriba.) Ma in sostanza sulla sua obiezione “non puoi definire il successo, quindi anything goes” non gli seppi dare, credo, una buona risposta.

Una discussione che c’è stata in pizzeria ieri sera, dopo la riunione del gruppo di Extreme Programming, mi ha fatto venire in mente argomenti che avrei potuto opporre, ancora più validi. Gabriele mi ha detto: “e i letterati, come fanno a stabilire il successo? Non fanno anche loro ricerca?”

Pensiamo un’attimo a tutte le cose che hanno senso e importanza in informatica, anche se non si riesce bene a quantificare questa importanza. L’eleganza e l’espressività di un linguaggio di programmazione, ad esempio. Ho conosciuto persone che mi hanno detto “ho fatto la tesi sul progetto di linguaggi di programmazione, ma non mi occupo più di quelle cose, perché il valore di un linguaggio di programmazione è una questione di giudizio soggettivo”.

La informatica, intesa come scienza, ci dice che possiamo scrivere qualsiasi programma usando qualsiasi formalismo, comprese le famose macchine di Turing. E’ un fatto scientifico. E’ un fatto altrettanto vero e tangibile, però, che nella realtà non possiamo scrivere programmi significativi nel linguaggio delle macchine di Turing, e infatti nessuno lo fa. La dimensione dei programmi, sia applicativi che di sistema, aumenta in termini di linee di codice di circa un ordine di grandezza ogni decennio. Come è possibile ciò? Dipende forse dal fatto che i linguaggi di programmazione effettivamente migliorano… E’ un fatto che Java è un linguaggio di programmazione migliore di C per scrivere i programmi gestionali. E’ un fatto che Java 1.5 è un linguaggio migliore, per molti versi, di Java 1.4. Come puoi provarlo? Io lo posso argomentare; ma non in maniera precisa, quantitativa.

I letterati possono senz’altro stabilire il successo, ovvero il valore, di un’opera d’arte. Ci potranno essere opinioni divergenti su alcune cose; correnti di pensiero. Strawinsky piuttosto che Brahms. Haskell piuttosto che Smalltalk. Gli argomenti pro e contro possono essere molto tecnici! E anche molto soggettivi. In nessun caso però si riesce a stabilire numericamente una superiorità.

Quindi in sostanza, occuparsi in accademia di argomenti come l’eleganza di un linguaggio di programmazione, o l’eleganza di uno stile di derivazione di algoritmi è estremamente frustrante, perché la comunità scientifica si aspetta da te che tu possa fornire una misura oggettiva del progresso che il tuo lavoro costituisce rispetto al passato. Questo conduce gran parte della ricerca in informatica ad occuparsi di questioni essenzialmente irrilevanti, tipo migliorare di un epsilon la complessità asintotica di un algoritmo che nessuno userà mai, che risolve un problema che nessuno ha bisogno di risolvere. Tipo l’ubriaco che cerca le sue chiavi sotto il lampione, perché almeno sotto il lampione c’è luce.

Ci sono tanti problemi difficili e rilevanti in informatica che non ammettono una misura matematica di successo. Iniziamo ad accettare il fatto che il valore di molte cose può essere discusso in termini di eleganza e bellezza. Un esempio: il kernel di Linux pare bellissimo a taluni, orrido a talaltri, ma Torvalds ha sempre detto che il suo principale criterio per selezionare i collaboratori è il buon gusto dal punto di vista tecnico.

As to how to solve the complexity problem, so far the real solution has been good taste.

… I mean a lot of patches end up getting rejected because they’re ugly. And a lot of patches end up getting accepted because they clean up certain things.

… the maintainers were having nightmares with ifdefs, and saying “I can’t manage this any more, so we need to clean it up.” And people did. Good taste. Ifdefs are bad. Fix them. Not, “Okay, let’s have tools that verify that we use them correctly.” See? That’s the difference.