C'è una citazione di Alan J. Perlis che dice:
There are two ways to write error-free programs; only the third one works.
Recentemente ho ascoltato questa citazione dal mio amico, e non sono stato in grado di capire il significato più profondo dietro di esso.
Di che cosa parla Perlis qui?
Significa che ci sono veramente no programmi privi di errori. Una profonda citazione sui modi per evitare errori con un errore in sé è parodia.
Non esiste una terza via.
There is no way to write error-free programs
Risponderò con un'altra citazione ...
A strange game. The only winning move is not to play.
; -)
Come hanno già indicato molte altre risposte, non c'è modo di scrivere un programma privo di errori .
Ma quello che vorrei sottolineare è la potenziale meta-natura della citazione. È essenzialmente un errore fuori dai limiti. Nella prima affermazione, definisce l'universo o "elenco" che ha solo due possibilità o elementi. Eppure nella seconda affermazione, fa riferimento a un terzo. Che è assurdo! Anche illegale! Un terzo elemento dato un limite di due elementi è di per sé un errore.
Veramente profondo in quanto la citazione è in grado di dimostrare l'essenza stessa a cui si riferisce.
Ciò significa che tutti i programmi non banali avranno bug. È solo un modo divertente per dire che non c'è modo di scrivere un programma privo di errori.
È possibile scrivere programmi privi di errori, anche quelli non banali e persino dimostrarli corretti. Prendi in considerazione, ad esempio, le lingue come Coq, Epigram o Agda dove questo è fatto.
Il problema di interruzione afferma che non è possibile farlo per il programma generale .
Questo mi ricorda una maglietta da nerd che ho visto: Ci sono 10 tipi di persone nel mondo. Quelli che conoscono il binario e quelli che non lo fanno.
Potrebbe anche essere un gioco sul fatto che a volte gli elenchi sono 0 indicizzati. $ var = array ('Primo', 'Secondo', 'Terzo'); E puoi accedere a questo elenco in quanto tale: $ var [0] = 'Primo' $ var [1] = 'Second' $ var [2] = 'Terzo'
Quindi l'indice dell'array letterale 2 punta all'indice "Third".
Questo è già spiegato in altre parole, ma non così chiaramente come penso che dovrebbe essere. Significa semplicemente che cercherete in entrambi i modi, avranno degli errori, e alla fine risolvete i vostri bug e avete un programma privo di errori. Confronta con un'altra citazione:
The only way for errors to occur in a program is by being put there by the author. No other mechanisms are known. Programs can't acquire bugs by sitting around with other buggy programs. --Harlan Mills
(In alternativa, potresti leggere questo come ha detto Pierre (che penso sia un tratto). (Il terzo modo, che non esiste nel dominio, funziona). Come ho detto, è un tratto, ma vero.
Questa è la stessa frase che mio padre usa per dirmi quando faccio scuse. Il detto tende a dire: "Ci sono 3 lati di una storia: il loro lato, il tuo lato e il lato destro / vero / corretto".
Mettendo questo in contesto con lo sviluppo (ed essendo un tester del software del prof.), direi che ci sono tanti modi per codificare qualcosa che avrebbe senso andare con "Ci sono 3 lati per la codifica. codice e il codice refactored. "
Penso che questo sia dovuto al fatto che i programmatori / sviluppatori tendono a rifattorizzare una volta che il prodotto si sta stabilizzando, che è troppo tardi, ma la maggior parte delle volte il refactoring è fatto per migliorare qualcosa che tu e il tuo amico non avete fatto bene nel primo posto.
Spero che questo aiuti.
Penso, tecnicamente parlando, che potresti scrivere un programma non banale privo di errori, ma a causa del problema dell'arresto è impossibile dimostrare che è privo di errori. Quindi, si deve lavorare partendo dal presupposto che tutti i programmi hanno dei bachi poiché è impossibile provare il contrario.
Aggiornamento: Puoi dimostrare che un particolare algoritmo restituirà le risposte giuste, ma non è la stessa cosa che provare che è completamente corretto. link )
Tuttavia, il mio punto era che la citazione si riferisce al fatto che si deve supporre che un programma abbia sempre bug e cerchi di spiegare perché questo è il caso. link
Come ulteriore intuizione, i "due modi" potrebbero essere un riferimento a questa citazione di Tony Hoare :
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature.
Meditali un po 'e vedrai che sta dicendo la stessa cosa: se il tuo software non è banale, ha dei bug (ma lo complicano abbastanza e non saranno ovvi bug).
Leggi altre domande sui tag bug quotations