Cosa intendeva Alan Perlis riguardo ai modi di scrivere programmi senza errori? [chiuso]

C'è una citazione di Alan J. Perlis che dice:

Esistono due modi per scrivere programmi senza errori; funziona solo il terzo.

Di recente ho sentito questa citazione dal mio amico e non sono riuscito a capire il significato più profondo dietro di essa.

Di cosa parla Perlis qui?

Significa che non ci sono davvero programmi senza errori. Una citazione profonda sui modi per evitare errori con un errore stesso è una parodia.

Non esiste una terza via.

Non è possibile scrivere programmi senza errori

Risponderò con un'altra citazione ...

Uno strano gioco. La sola mossa vincente è non giocare.

;-)

Come molte altre risposte hanno già sottolineato, 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 limite. Nella prima affermazione, definisce l'universo o "elenco" con solo due possibilità o elementi. Eppure nella seconda affermazione, fa riferimento a un terzo. Il che è assurdo! Anche illegale! Un terzo elemento con un limite di due elementi è esso stesso un errore.

Veramente profondo in quanto la citazione è in grado di dimostrare la vera essenza a cui si riferisce.

Ciò significa che tutti i programmi non banali avranno bug. È solo un modo divertente di dire che non c'è modo di scrivere un programma privo di errori.

È possibile scrivere programmi senza errori, anche non banali, e persino dimostrarli corretti. Prendi in considerazione, ad esempio, lingue come Coq, Epigram o Agda in cui ciò viene fatto.

Il problema di arresto 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 al mondo. Quelli che conoscono il binario e quelli che non lo sanno.

Potrebbe anche essere un gioco sul fatto che a volte le liste sono 0 indicizzate. $ var = array ('First', 'Second', 'Third'); E puoi accedere a questo elenco come tale: $ var [0] = 'First' $ var [1] = 'Second' $ var [2] = 'Third'

Quindi l'indice letterale dell'array 2 punta all'indice "Terzo".

Questo è già spiegato in altre parole, ma non così chiaramente come penso che dovrebbe essere. Significa semplicemente che proverai entrambi i modi, avranno errori e infine risolverai i tuoi bug e avrai un programma privo di errori. Confronta con un'altra citazione:

L'unico modo in cui si verificano errori in un programma è di essere inserito dall'autore. Non sono noti altri meccanismi. I programmi non possono acquisire bug restando in giro con altri programmi difettosi. --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 citazione che mio padre usa per dirmi quando faccio delle scuse. Il detto tende ad andare come: "Ci sono 3 lati di una storia. Il loro lato, il tuo lato e il lato giusto / vero / corretto".

Mettendo questo in contesto con lo sviluppo (ed essendo un tester software del prof.), Direi che poiché ci sono così tanti modi per codificare qualcosa, sarebbe logico andare con "Ci sono 3 lati della codifica. Il tuo codice, il loro codice e il codice Refactored. "

Penso che ciò sia dovuto al fatto che programmatori / sviluppatori tendono a refactoring una volta che il prodotto sta diventando stabile, il che è per lo più troppo tardi, ma il più delle volte il refactor viene fatto per migliorare qualcosa che tu e il tuo amico non avete fatto così bene in primo luogo.

Spero che sia di aiuto.

Penso, tecnicamente parlando, che potresti scrivere un programma non banale privo di errori, ma a causa del problema Halting è impossibile dimostrare che è privo di errori. Quindi, si deve lavorare supponendo che tutti i programmi abbiano dei bug poiché è impossibile provare il contrario.

http://en.wikipedia.org/wiki/Halting_problem

Aggiornamento: puoi provare che un particolare algoritmo restituirà le risposte giuste, ma non è la stessa cosa che dimostrare che è totalmente corretto. http://en.wikipedia.org/wiki/Correctness_(computer_science )

Tuttavia, il mio punto era che la citazione si riferisce al fatto che si deve presumere che un programma abbia sempre dei bug e che cerchi di spiegare perché sia ​​così. http://en.wikipedia.org/wiki/Software_bug#Bug_management

Come ulteriore intuizione, i "due modi" potrebbero essere un riferimento a questa citazione di Tony Hoare :

Esistono due modi per costruire un progetto software: un modo è renderlo così semplice che non ci siano ovviamente carenze e l'altro è renderlo così complicato che non ci sono carenze evidenti. Il primo metodo è molto più difficile. Richiede la stessa abilità, devozione, intuizione e persino ispirazione della scoperta delle semplici leggi fisiche che sono alla base dei complessi fenomeni della natura.

Medita un po 'su questo e vedrai che sta dicendo la stessa cosa: se il tuo software non è banale, ha dei bug (ma complicalo abbastanza e non saranno ovvi bug).