Que voulait dire Alan Perlis concernant les façons d'écrire des programmes sans erreur? [fermé]

Il y a une citation d' Alan J. Perlis qui dit:

Il existe deux façons d'écrire des programmes sans erreur; seul le troisième fonctionne.

J'ai récemment entendu cette citation de mon ami et je n'ai pas pu comprendre le sens profond qui se cache derrière.

De quoi parle Perlis ici?

Cela signifie qu'il n'y a vraiment aucun programme sans erreur. Une citation profonde sur les moyens d'éviter les erreurs avec une erreur elle-même est la parodie.

Il n'y a pas de troisième voie.

Il n'y a aucun moyen d'écrire des programmes sans erreur

Je répondrai avec une autre citation ...

Un jeu étrange. Le seul coup gagnant est de ne pas jouer.

;-)

Comme de nombreuses autres réponses l'ont déjà souligné, il n'y a aucun moyen d'écrire un programme sans erreur .

Mais ce que je voudrais souligner, c'est la méta-nature potentielle de la citation. C'est essentiellement une erreur hors limites. Dans la première déclaration, il définit l'univers ou la "liste" n'ayant que deux possibilités ou éléments. Pourtant, dans la deuxième déclaration, il fait référence à une troisième. C'est absurde! Illégal même! Un troisième élément étant donné une frontière à deux éléments est lui-même une erreur.

Vraiment profond en ce que la citation est capable de démontrer l'essence même à laquelle elle se réfère.

Cela signifie que tous les programmes non triviaux auront des bogues. C'est juste une façon amusante de dire qu'il n'y a aucun moyen d'écrire un programme sans erreur.

Il est possible d'écrire des programmes sans erreur, même non triviaux, et même de prouver qu'ils sont corrects. Prenons par exemple des langages comme Coq, Epigram ou Agda où cela se fait.

Le problème d'arrêt indique qu'il n'est pas possible de le faire pour le programme général .

Cela me rappelle une chemise nerd que j'ai vue: Il existe 10 types de personnes dans le monde. Ceux qui connaissent le binaire et ceux qui ne le savent pas.

Cela pourrait également être un jeu sur le fait que parfois les listes sont indexées à 0. $ var = array ('First', 'Second', 'Third'); Et vous pouvez accéder à cette liste en tant que telle: $ var [0] = 'First' $ var [1] = 'Second' $ var [2] = 'Third'

L'index littéral du tableau 2 pointe donc vers le "troisième" index.

Cela est déjà expliqué en d'autres termes, mais pas aussi clairement que je pense que cela devrait l'être. Cela signifie simplement que vous essaierez des deux façons, ils auront des erreurs, et enfin vous corrigerez vos bugs et aurez un programme sans erreur. Comparez avec une autre citation:

Le seul moyen pour que des erreurs se produisent dans un programme est d'y être mis par l'auteur. Aucun autre mécanisme n'est connu. Les programmes ne peuvent pas acquérir de bugs en restant assis avec d'autres programmes buggy. --Harlan Mills

(Alternativement, vous pouvez lire ceci comme Pierre l'a dit (ce qui, je pense, est un tronçon). (La troisième façon, qui n'existe pas dans le domaine, fonctionne.) Comme je l'ai dit, c'est un tronçon, mais vrai.

C'est la même citation que mon père utilise pour me dire quand je fais des excuses. Le dicton a tendance à dire: "Il y a 3 côtés dans une histoire. Leur côté, votre côté et le côté droit / vrai / correct".

En mettant cela en contexte avec le développement (et en étant un testeur de logiciels par le prof.), Je dirais qu'il y a tellement de façons de coder quelque chose qu'il serait logique d'aller avec "Il y a 3 côtés au codage. Votre code, leur code et le code refactorisé. "

Je pense que c'est parce que les programmeurs / développeurs ont tendance à refactoriser une fois que le produit est stable, ce qui est généralement trop tard, mais la plupart du temps, le refactor est fait pour améliorer quelque chose que vous et votre copain n'avez pas si bien fait en premier lieu.

J'espère que cela t'aides.

Je pense, techniquement parlant, que vous pourriez écrire un programme non trivial sans erreur, mais en raison du problème d'arrêt, il est impossible de prouver qu'il est sans erreur. Donc, on doit travailler sous l'hypothèse que tous les programmes ont des bugs car il est impossible de prouver le contraire.

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

Mise à jour: Vous pouvez prouver qu'un algorithme particulier renverra les bonnes réponses, mais ce n'est pas la même chose que de prouver qu'il est totalement correct. http://en.wikipedia.org/wiki/Correctness_(computer_science )

Cependant, mon point était que la citation fait référence au fait que l'on doit supposer qu'un programme a toujours des bogues et essayer d'expliquer pourquoi c'est le cas. http://en.wikipedia.org/wiki/Software_bug#Bug_management

À titre d'information supplémentaire, les «deux façons» pourraient être une référence à cette citation de Tony Hoare :

Il y a deux façons de construire une conception logicielle: l'une consiste à la rendre si simple qu'il n'y a évidemment pas de déficiences, et l'autre consiste à la rendre si compliquée qu'il n'y a pas de déficiences évidentes. La première méthode est bien plus difficile. Elle exige la même habileté, dévouement, perspicacité et même inspiration que la découverte des simples lois physiques qui sous-tendent les phénomènes complexes de la nature.

Méditez un peu et vous verrez qu'il dit la même chose: si votre logiciel n'est pas trivial, il a des bugs (mais compliquez-le suffisamment et ce ne seront pas des bugs évidents ).