Il fatto ha guadagnato per breve tempo le prime pagine dei giornali: forse fino a 270 donne potrebbero negli anni scorsi aver perso la vita a causa di un bug nell’algoritmo di un programma del National Health Service britannico, che ha omesso di inviare a moltissime l’invito a sottoporsi alla periodica analisi mammografica. In un periodo in cui si moltiplicano gli allarmi riguardo ai mali indotti dalla pervasività dell’informatica, una notizia come questa era destinata ad avere eco. Un’eco giustificata?
Gli errori tecnici che uccidono o quasi
In un certo senso no. Anzitutto, bisogna dire che episodi di questo tipo sono ben noti a chiunque si occupi di sicurezza del software: errori disastrosi sono sempre in agguato. Soli pochi giorni prima del lancio dell’Apollo 11 ci si accorse che il software di bordo aveva un segno sbagliato, che attribuiva alla luna una forza non attrattiva ma repulsiva: se una tazzina di caffè in meno avesse reso un paio di occhi meno attenti, piuttosto che l’uomo sulla Luna avremmo avuto l’uomo perduto a morire nello spazio, e la storia sarebbe stata diversa.
Margaret Hamilton, la responsabile informatica dell’Apollo 11, considerò poi missione della propria vita elaborare le strategie di controllo della correttezza dei programmi: comprensibile. Ma altre volte la tazzina di caffè effettivamente è mancata ed enormi danni sono seguiti: qualche anno prima il Mariner 1 diretto verso Venere cambiò la rotta prevista e venne distrutto 5 minuti dopo il lancio a causa di un «trattino mancante» (così si raccontò) nel software di bordo: non si perse nessuna vita umana, ma si mandarono in fumo quasi 20 milioni di dollari dell’epoca.
Altri casi celebri riguardano in maniera diretta la medicina: tra il 1985 e il 1987 almeno tre morti furono causate dal software difettoso di una macchina per la radioterapia, il Therac-25, che somministrò una radiazione cento volte superiore rispetto a quella prevista. È dunque solo uno tra i tanti il caso in questione della Gran Bretagna, peraltro difficile da quantificare. C’è inoltre da considerare l’effetto «cane che morde l’uomo»: se un evento come questo fa notizia, è appunto perché è un’eccezione rispetto alla norma di programmi che funzionano bene e portano avanti la stragrande maggioranza delle faccende del nostro mondo moderno. Nessun allarme dunque, anzi la conferma che le cose in genere vanno bene.
Il bug hunting salva la vita
Ciononostante, la notizia merita qualche riflessione in più. Che l’individuazione e la rimozione dei bug faccia parte della normale procedura di preparazione di un programma è un luogo comune universalmente condiviso. È noto che questa terminologia venne messa in uso dall’informatica americana Grace Hopper, la quale risolse un problema di funzionamento di un computer scovando appunto un insetto, un bug, che si era infelicemente intrufolato nel computer falsando un contatto. Ecco, la capacità di condurre felicemente in porto queste cacce, a volte difficili e misteriose, deve far parte del corredo di competenze di ogni buon programmatore. Anzi, se ci si proponesse di scrivere la storia delle novità via via introdotte per alleviare questo problema, in realtà si avrebbe una storia quasi completa dei linguaggi di programmazione: linguaggi di alto livello, programmazione strutturata, programmazione ad oggetti, literate programming, design by contract: in misura diversa sono stati tutti modi, di maggiore o minore successo, per favorire anche la scrittura di programmi privi di bug.
I bug sono un male necessario?
Che però la presenza di bug e il conseguente debugging sia una sorte inevitabile può essere contestato. Lo contestava per esempio Edsger Dijkstra, che negli anni 70, quando l’idea era diventata onnipresente, scriveva con il suo consueto fare sbrigativo che c’è un modo semplicissimo per evitare il debugging: basta non introdurre bug. Anzi, il primo passo sarebbe eliminare questa fuorviante metafora e chiamare le cose con il loro nome: i cosiddetti bug non sono misteriosi insetti che si sono intrufolati nella tua opera, ma semplicemente «errori» che tu hai commesso: «Se in fisica c’è qualcosa che non capisci, ti puoi sempre nascondere dietro le insondabili profondità della natura. Puoi sempre dare la colpa a Dio. Non sei stato tu a fare le cose così complicate.
Ma se il tuo programma non funziona, non c’è nessuno dietro cui ti puoi nascondere. Non ti puoi nascondere dietro una natura ostinata. Uno zero è uno zero, un uno è un uno. Se non funziona, sei tu che hai sbagliato». Anche per questo a suo parere l’informatica è da considerare una branca della matematica. Esattamente come in questa, di ogni programma va quindi dimostrata la correttezza, in maniera più o meno formale. Ciò non ha niente a che fare con il «provarlo» su un computer: in questo modo al massimo si potrà vedere che vi sono degli errori, ma non si potrà mai controllare che essi non vi siano. E, tanto per coerenza, da un certo momento in poi non toccò più un computer e non lo faceva più toccare ai propri studenti. (Come? Semplice: basta assegnare i compiti in un linguaggio di programmazione per il quale non è mai esistito un interprete e che quindi non possono essere provati, perlomeno direttamente, in nessun computer. I suoi libri di testo sono così, vedere per credere!)
Si può sostenere che questa radicalità sia esagerata. Non si può però negare che essa abbia portato almeno qualche frutto: il successo pressoché universale della «programmazione strutturata», che prima abbiamo citato tra le strategie per ridurre la probabilità di errori, si deve soprattutto a lui (ricordo chiaramente quando da ragazzino, pur non conoscendo ovviamente il nome di Dijkstra, mi convertii ad uno stile di programmazione strutturata!). Ma soprattutto non si può negare che ancor oggi i suoi avvertimenti debbano essere presi sul serio. Mi pare infatti che ai motivi che egli vedeva come cause di inquinamento della purezza matematica dell’informatica se ne sia aggiunto un altro, dal versante pedagogico: l’idea cioè secondo cui proprio il luogo comune sui bug sia pedagogicamente importante.
Così per esempio riteneva Seymour Papert, l’influente promotore del LOGO e dell’informatica come ambiente educativo: proprio quest’ultimo, sosteneva, aiuta a liberarsi dall’idea che esistano «errori»: no, ci sono solo bug da correggere, e questo vale per ogni disciplina. Siamo sicuri che per voler superare l’angoscia della matita blu non si vada troppo in là e non si trasmetta l’idea che in fondo è inevitabile che ci siano errori, e che questi non siano responsabilità di nessuno? Sbagliando si impara, diceva l’antica saggezza: ma questo suppone appunto che sia ben chiara l’idea che noi siamo in grado di fare o di non fare errori. Se la preoccupazione sembra eccessiva, si comincino a contare le volte in cui nel linguaggio comune e nei mezzi di comunicazione di massa si parla di «computer che sbagliano», «computer che si confondono», «computer che interpretano», e così via. I titoli dei giornali sul deprecabile episodio in Gran Bretagna hanno parlato di «errore del computer», «falla del computer», «colpa di un algoritmo», «meccanismo inceppato». Più o meno come parlare di «errore del volante» per un incidente stradale.
Archiviare definitivamente questo linguaggio animistico certamente sarebbe utile e aiuterebbe, se non a convertirsi all’intransigenza matematica di Dijkstra, almeno a non ritenere gli errori nel software un brutto tiro del destino. Aiuterebbe quindi ad allocare tempo e risorse per permettere lo sviluppo di programmi corretti e a chiedere sempre che questi rispondano a quelle esigenze di semplicità e pubblicità che, aumentando la trasparenza del codice e il numero di occhi che possono controllare, forse aumenterebbero anche la probabilità di eliminare eventuali errori.
