lunedì 30 settembre 2013

Bug-free software

Quando si scrive un programma per computer si può incorrere in due tipi di errori: quelli di sintassi e quelli logici. I primi vengono rilevati direttamente dal compilatore poichè quest'ultimo (si tratta di un altro programma) non riesce ad applicare le sue regole di traduzione in codice eseguibile dalla macchina. I secondi invece vengono regolarmente tradotti dal compilatore ma portano a comportamenti non previsti e in particolare molti di essi possono portare ad una interruzione imprevista o ad uno stallo del processo di calcolo. Un esempio di un errore di sintassi potrebbe essere una parentesi aperta in un punto del codice e mai chiusa, oppure semplicemente una parole chiave del linguaggio scritta male. Un esempio di errore logico potrebbe essere una divisione per zero o l'ingresso in un ciclo di calcolo infinito. Molti errori logici si rivelano solo con particolari dati in ingresso al programma.

Anni fa mi è capitato di sentire più di una volta l'espressione categorica "non esistono programmi senza errori", oppure "non è possibile scrivere programmi che siano esenti da qualsiasi errore", "scrivere software senza bug è impossibile". Ma non è chiaro cosa questo voglia significare. Voglio dire: è chiaro che è possibile scrivere programmi esenti da errori, cioè programmi il cui comportamento è esattamente quello previsto. Non saranno particolarmente interessanti ma si possono scrivere. Dunque queste frasi o non hanno senso oppure il loro senso va precisato in qualche modo (ma rimane il fatto che sia io a non aver mai capito bene la questione, o che non ci abbia mai riflettuto abbastanza, almeno fino a questo momento).

Credo di aver trovato questa precisazione in un libro letto recentemente, o perlomeno certe osservazioni del libro mi sono suonate come precisazioni interessanti di questa idea vaga persa nella mia memoria, che quindi mi è apparsa come una specie di detto popolare con un qualche fondamento (del tipo "rosso di sera bel tempo si spera").

La precisazione è la seguente: "non può esistere un programma (un algoritmo) che sia sempre in grado di decidere se, dato un certo programma con certi dati in ingresso, quest'ultimo andrà in crash o in hang per qualche errore oppure no, per qualunque programma fornito". In altre parole sebbene esistano programmi che aiutano più o meno efficacemente il programmatore a fare il cosiddetto "debugging" di un suo programma, o più in generale il testing, questa attività rimane in parte legata all'abilità dello stesso programmatore, non potendo essere completamente automatizzata attraverso un qualche algoritmo efficiente al 100%. Terminata una fase di test nessuno mi assicura, per quanto il lavoro possa essere stato accurato, che il mio programma sia stato emendato completamente da tutti i suoi possibili errori. Si tratta di un risultato di carattere generale che ricorda molto da vicino il famoso "problema dell'arresto" il quale, detto in breve, afferma che stabilire se l'esecuzione di un programma termina a fronte di un input arbitrario e' un problema indecidibile (Alan Turing, 1936).

Quindi è possibilissimo scrivere software senza bug, quello che è impossibile è avere un procedimento generale (magari di tipo algoritmico) in grado di dimostrarcelo per qualunque software.

Nota: devo ammettere che, con il senno di poi, se si cerca un po' meglio in rete si trova spesso la frase, enunciata a volte come un principio della programmazione, che dice: "è impossibile dimostrare l'assenza di bug in un programma"; inoltre nella trattazione del problema generale del testing si incontra inevitabilmente la famosa tesi di Dijkstra: "Testing shows the presence, not the absence of bugs" (Dijkstra, 1969).

Nota2: se si scrive un programma che fa uso ad esempio di una procedura di calcolo che non è quella voluta dal programmatore (che dunque avrà sbagliato a scriverla) ma che appare del tutto legittima sono in presenza di un bug oppure semplicemente di un altro programma? Dal punto di vista teorico sembrerebbe essere semplicemente un diverso programma (a cui non posso applicare il risultato della teoria). Dal punto di vista pratico è certamente un bug che in qualche fase di testing dovrà essere messo in evidenza.

2 commenti:

Andrea C ha detto...

L'ennesima dimostrazione della non sostituibilità dell'essere umano. Nel senso che anche nella realizzazione di errori, il comportamento lineare del cervello umano non è nemmeno lontanamente riproducibile da una macchina. Ma è vero anche il contrario: non c'è macchina che non si comporti come "dettato" da un essere umano e che quindi ne rispecchi la volontà.
Per cui la differenza è il "solito" libero arbitrio. Cosa è errato ? Cosa è voluto ? Cosa è voluto ed errato ? Il giudizio umano è l'ultima ratio che crea la realtà a suo piacimento. Anche questo commento ha un senso: per chi lo legge, per chi lo scrive, per il pc che lo "trasporta", per chi non lo conosce, per chi non vuole leggerlo, ecc ecc. Arriviamo quindi al fattore che fa la differenza tra giudizio e oggetto : il tempo. L'ultimo punto di vista critico è il tempo. Ma il tempo cos'è ? Perchè esiste ? Nel momento in cui lo scrivo già non ha più lo stesso senso. Si torna ciclicamente all'inizio del tuo articolo: la domanda in sé, rappresenta un valore solo per sé stessa; chi la legge, chi non la legge, chi la leggerà e non, tutti sono mossi dal tempo che dà un senso all'oggetto e ne riflette (in maniera non uniforme) il giudizio, traslato ora dalla volontà, ora da altri fattori che il tempo potrà creare. E' possibile la creazione di un software senza bug ? La domanda potrebbe essere più corretta : Quando è (sarà/è stato)possibile creare un software senza bug ? La risposta è (ovviamente) : 42 !

Rodolfo Trippetti ha detto...

Urca!