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

29

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?

ykombinator
la source
1
vous vous rendez également compte de l'erreur de cette parodie, car il est possible d'écrire des programmes non triviaux sans erreur, cela prend juste de la discipline.
1
Ce type de question est actuellement en discussion sur notre site de méta-discussion .
1
lecture recommandée: Discutez de ce $ {blog}
gnat

Réponses:

41

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.

Jesse C. Slicer
la source
3
Alan Perlis avait certainement un sens aux mots.
Frank Shearar
2
C'est la "parodie" qui est importante dans le sens de cette citation.
Adam Harte
60

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

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


la source
37

Je répondrai avec une autre citation ...

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

;-)

Austin Salonen
la source
5
+1 pour la référence des jeux de guerre!
Jason
Lien xkcd obligatoire suivant: xkcd.com/601
Baelnorn
14

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.

Mark Canlas
la source
Il existe un moyen de prouver qu'un programme se comporte comme spécifié. Cela est utilisé par exemple pour les installations nucléaires ...
1
@ Thorbjørn Ravn Andersen, tel que spécifié ne signifie pas qu'il est sans erreur.
CaffGeek
5

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.

dsimcha
la source
5

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 .

Tony Morris
la source
Revenez plus loin, à l'équipe de Don Good à l'UT Austin, et à leur travail dans les années 1970 et au début des années 1980 avec le Gypsy Verification Environment. Ils ont démontré que le code sans erreur était possible, en fournissant un modulateur de flux de messages sans erreur à la Marine. La suite de tests d'acceptation a été développée par un groupe complètement différent. Lorsque le MFM a vu la suite de tests d'acceptation, pour la première fois, au test d'acceptation, il a réussi, sans écarts, ni dérogations, ni «oui mais».
John R. Strohm
3

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.


la source
... et ceux qui commencent l'indexation à zéro
2

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.

Mark C
la source
1

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.


la source
1

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

Booji Boy
la source
1
comme l'a dit Tony Morris, il est possible de prouver qu'un programme particulier est correct. Il est impossible d'écrire un programme qui peut en général prouver que tout programme qui est correct, est correct.
Max Strini
-1

À 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 ).

Doval
la source
cela ne répond pas à la question posée
moucher
@gnat Je ne vois pas comment ça ne marche pas - c'est juste là dans le deuxième paragraphe. Peut-être que le libellé n'était pas clair, mais quand j'ai dit "dire la même chose", je voulais dire "dire la même chose qu'Alan Perlis". Autrement dit, la citation de Perlis est probablement une parodie humoristique de Hoare.
Doval