Extreme Enthusiasm

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.

Ho disabilitato i commenti… non ho tempo di correre dietro a questo deficiente che mi spamma il blog. Spero di riuscire a integrare Typo, perché non ho voglia/tempo di reimplementarmi dei meccanismi antispam efficaci.

]]>

All’ultimo meeting dell’XP User Group di Milano, o meglio dopo il meeting, alla pizzeria cinese, Gabriele ha fatto un discorso importante. Alla domanda

Quando parlo di fare i test, mi obiettano che senza test si va più veloci

G. ha detto

E’ vero che inizialmente, senza i test, vai più veloce. Ma il momento iniziale è anche quello in cui andrai alla velocità massima; da quel momento in poi la tua velocità non può che diminuire. Invece, nei progetti che fanno bene il test-driven development, io ho proprio osservato che con il tempo si va sempre più veloci. Il TDD ti dà la possibilià di diventare sempre più bravo a lavorare con i test e con la tua base di codice, così che implementare nuove cose diventa più facile, non più difficile, con il passare del tempo.

Questo è quello che ricordo; sicuramente le parole non sono proprio quelle ma volevo salvare il succo di questo discorso di Gabriele perché è molto importante. Se non si cede al “lato oscuro”, che consiste nel dimenticarsi di fare refactoring (il ciclo di TDD prevede di scrivere un test, farlo passare, e poi rifattorizzare tutto il sistema) allora la velocità aumenterà con il tempo.

AGGIORNAMENTO: l’argomento dalla viva voce di Gabriele

Quest’estate a Varese organizzeremo una Scuola Estiva sui Metodi Agili (di
cui Extreme Programming è uno dei primi e più diffusi). L’argomento è per me
appassionante: gli agilisti hanno rivoluzionato la maniera di sviluppare. O
per lo meno, hanno spiegato e sistematizzato una serie di pratiche che i
migliori programmatori almeno in parte conoscevano. Però il fatto di
sistematizzare e spiegare ed organizzare i principi, valori e le pratiche
(Beck) produce un risultato che è molto, ma molto più della somma delle parti.

Il seminario che terrò l’undici aprile introdurrà l’argomento; ma alla
scuola interverranno docenti che la sanno molto più lunga di me. Tutti i
dettagli sono su http://essap.dicom.uninsubria.it/. La pagina è in inglese, come d’altronde sarà la scuola.

Spero che ci siano iscritti dell’Insubria e da altre Università italiane ed europee; sarebbe così anche una maniera per stringere contatti e conoscenze e, speriamo, amicizie.

]]>

“Source” si pronuncia “sòrs”, come “force”

“Header” si pronuncia “heder”, come “head”

“talk” si pronuncia “tòk”: la “l” non si sente, la “o” è come in “force”.
Stesso per “walk”, che si prouncia “uòk”.

Questa presumo interessi solo gli appassionati di giochi di ruolo: “sword”
si pronuncia “sòrd”, come “force” e come “source”. La “w” non si sente.

:-)

]]>

Leggi ad personam, riforma Moratti, epurazione dei giornalisti, bavaglio alla satira, condoni edilizi e fiscali, debito pubblico al 110% del PIL, riforma elettorale, “devolution”, ponte sullo stretto, tagli alla ricerca… Credo che a pensarci non si riesca a finire di elencare i disastri. Ha ragione Sartori (Corriere di oggi); anche se Prodirutellifassino non mi convincono, vale lo stesso la pena di punire chi ha tanto sfasciato. Voterò centrosinistra.

E avranno ragione di prendermi in giro gli amici che sanno come ho votato la volta scorsa. Avevate ragione, e io avevo torto.

]]>

L’ 11 aprile alle 16:00, terrò un seminario su “Introduzione a Extreme Programming” per gli studenti dell’Università dell’Insubria.

Per chi: studenti della specialistica e della triennale. Per chiunque sia interessato.

Sommario: parleremo delle pratiche di XP, e dei principi e dei valori
da cui discendono. Introdurremo il planning game e il test-driven
development, che sono due fra le più rappresentative delle pratiche
della Programmazione Estrema; vedremo che l’efficacia delle pratiche è
maggiore quando vengono applicate insieme, perché si supportano l’una
con l’altra. Accenneremo al fatto XP non è un processo codificato
nella pietra, ma che le pratiche possono essere modificate e adattate
in risposta alle diverse situazioni; in questo ci vengono in aiuto i
principi e i valori di XP.

Webografia: www.extremeprogramming.org

]]>

Tim Case scrive:

… I’m happy to report that the I’ve moved well beyond the Rails learning curve, and into the world of Rails nirvana. I’m doing things now about a billion times faster than when I first started and it feels really, really, really good. The thing that first got me into Ruby is when programmers described it as a language that made it really fun to program in, and right now I have to say between Ruby and Rails I’m having the most fun I’ve ever had as a developer. If you’re still learning Rails and finding that things take longer than you expected while you are learning don’t worry just give it time and eventually it will come. Rails is amazing but even the amazing takes a bit of time to grasp.

Rails è divertente! Ruby è divertente! Anche se all’inizio si fa un po’ fatica ad “entrarci”.

Jim Weirich nella sua presentazione di Rails mostra una slide che dice

Rails maximizes programmer …

(pausa ad effetto; qualcuno bisbiglia ‘productivity’ )

… happiness!

Chad Fowler, autore di “My job went to India and all I got is this lousy book”, intervistato da Geoffrey Grossenbach sul Ruby On Rails podcast:

Geoffrey: One of the big things people are excited about with Rails is it’s making possible for small teams to produce really killer web sites that would have previously taken ten or twenty programmers, and… definitely in India many programmers are put on different jobs. Do you think Rails is a threat in general worldwide for programmers, because a lot fewer programmers are needed, or is this an opportunity for people to take advantage of?

Chad: I think it’s an opportunity for great programmers. Rails is not the first technology to come along to help people to be more productive; I mean, look back at the first online store, created by a programmer’s company, written in Lisp, using continuations and all kinds of advanced features. They were able to do things like change the running application on the fly … There are some ultra-productive technologies available and they have been for a long time, to develop this kind of things with small teams. But what you won’t find is the mediocre programmers, that really our industry is rampant with right now. You won’t find them developing killer web sites with small teams, whether they’re using Rails, J2EE or PHP. What you will find is the remarkable programmers, using a remarkable technology, to do remarkable things. And I don’t believe that represents a threat in terms of the job market. Because what we’re talking about is a very special, focused group of people; a very small percentage of the programmers available.

Gente, sentire queste cose fa venir voglia di fare. Let’s make a difference!

]]>

Krzysztof R. Apt ha scritto un bel necrologio per Edsger W. Dijkstra. E’ molto completo nella descrizione sia degli enormi contributi scientifici

In a one-page paper from 1965 he introduced the ‘mutual exclusion problem’ for n processes and discussed a solution to it. It was probably the first published concurrent algorithm.

che della sua personalità

In writing his elegance was unmatched. He could write about formal issues in the form of an essay, with hardly any formulas. His paper Cooperating sequential processes is perhaps the best example. Similarly, he was able to discuss (one shold rather say, derive) intricate algorithms in distributed computing in a seemingly informal way, in plain prose, with just a few simple formulas. He wrote his articles in a unique style characterised by conciseness, economy of argument and clarity of exposition. Each sentence was carefully chiselled. Each paragraph was striking.

Come risuona questa eco nel ricordo delle poche occasioni in cui l’ho visto. Come apprezzo e ammiro questa concisione e precisione, per usare le parole di Roland Backhouse.

La concisione è potere, dice Richard Gabriel riferendosi alla programmazione. Non posso che essere d’accordo. Il momento più bello è quando l’astrazione giusta fa “click” nella tua mente, e puoi cancellare pagine e pagine di codice: David Heinemeier Hansson. Due citazioni di due hacker. Dijkstra disprezzava sommamente gli hacker. Eppure alla fine l’estetica spartana e cristallina di Ruby on Rails ha qualcosa degli articoli brevi ed icastici di Dijkstra.

Fra le molte citazioni gettonate di Dijkstra c’è Program testing can be used to show the presence of bugs, but never to show their absence! Dijkstra non usava mai i computer. Disprezzava l’idea di “testare” i programmi. Eppure … sono convinto che la disciplina del Test-driven development ha qualche cosa della discipline of programming di Dijkstra. I programmi che si ottengono hanno la stessa qualità di essere super-concisi ed essenziali. Quella stessa qualità che ammiravo nei programmi ottenuti per derivazione dalle specifiche.

Aneddoto: in un qualche momento degli anni novanta c’era un lungo dibattito su comp.lang.c.moderated su come risolvere il seguente problema: dato un array di interi, trovare la sottosequenza la cui somma è massima. La soluzione “forza bruta” è ovvia e richiede tempo quadratico; si voleva una soluzione più efficiente. Pagine e pagine di codice e ragionamenti confusi volavano nel newsgroup, fino a quando non intervenni io. Il problema in questione è uno degli esercizi standard che si usano nella program derivation. La soluzione lineare si calcola facilmente, e consiste in tre righe di codice. Il mio post è stato l’ultimo del thread :)

]]>

L’articolo
è del ’94. La tesi, in breve, è che non è praticamente possibile rendere
trasparente (invisibile) la differenza fra oggetti locali e remoti, in un
sistema di programmazione ad oggetti. La qual cosa, detta così, può anche
apparire ovvia; ma in quegli anni si faceva un gran parlare di DCOM, Corba,
RMI, EJB e altri sistemi che promettevano al programmatore di “sviluppare
un’applicazione ad oggetti, e preoccuparsi dopo di come distribuire gli
oggetti su diverse macchine.”

Il tono dell’articolo è accademico-scassapalle. Ciononostante hanno ragione. Alcune degli argomenti che citano sono abbastanza banali; altri un po’ meno, soprattutto quello che dicono dei fallimenti parziali.

Quali sono, dunque, i motivi per cui un oggetto remoto non può essere trattato come un’oggetto locale?

1. Latenza. L’invocazione di un metodo locale costa pochissimo, invocare un metodo remoto no. Finchè si tratta di invocarlo una volta è un conto, ma in pratica un sistema distribuito deve essere progettato per minimizzare il numero di network round-trip (chiamate remote). Questo dovrebbe essere abbastanza ovvio.
2. Modello della memoria. Chiamare un metodo significa passare parametri, e magari ricevere dei risultati. Se questi dati sono value objects (semplici strutture dati autocontenute) non c’è nessun problema. Ma se contengono risorse a strutture date esterne, tipo connessioni a database o a file aperti, questi oggetti non si possono serializzare. Così come sono problematiche strutture dati che contengono puntatori ad altre zone di memoria. Anche questo mi pare abbastanza ovvio.
3. Fallimenti parziali. Quando una chiamata remota fallisce, non è dato sapere se il fallimento è totale o parziale. Per esempio: supponiamo di avere una chiamata remota il cui effetto è aggiungere un record ad un database. Se invoco questo metodo, e dopo un po’ di tempo non ho avuto risposta, i casi sono due: o la chiamata è andata persa, e il record non è stato aggiunto; oppure la risposta è andata persa, e il record è stato aggiunto. Il mio problema è che non posso sapere in quale dei due casi mi trovo.

Quest’ultimo caso è il più difficile e interessante. Così su due piedi, l’unica cosa che posso fare è attendere fino a un certo tempo e poi arrendermi. Ma non so se il record è stato aggiunto o no. Tutto quello che posso fare è aspettare un po’ e provare ad aggiungerlo di nuovo, correndo il rischio di aggiungere il record due volte!

La soluzione è semplice, mi dirai. Basta interrogare il server per sapere se il record è stato aggiunto. Oppure aggiungere un identificatore alla mia richiesta; ad esempio, se ho ricevuto una timeout sulla richiesta n. 456, riprovo a mandare la richiesta 456. Il server può così distinguere il caso di una richiesta che ha già visto, nel qual caso la ignora.

Aha! Ma in entrambi i casi, abbiamo modificato l’interfaccia remota per tenere conto del fatto che l’invocazione è, appunto remota.
Nel caso di una invocazione locale non abbiamo i fallimenti parziali: se la mia richiesta di aggiungere un record fallisce, lo so e basta.

Qui sta il succo dell’articolo: per progettare un interfaccia da usare in remoto, occorrono accorgimenti specifici per il caso remoto. Il che può apparire ovvio, detto così! Ma quando ci si prova, è difficile tenere conto dei fallimenti parziali che possiamo avere in un sistema distribuito.

Tutto sommato, è valsa la pena di leggerlo.

PS. Jim Waldo, uno degli autori di “A Note” e in seguito inventore di Jini, tiene un corso ad Harvard la cui pagina è una bella bibliografia di articoli sui sistemi distribuiti

]]>