Qu'est-ce que Alan Perlis signifie en ce qui concerne les façons d'écrire des programmes sans erreur? [fermé]
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Il y a une citation par Alan J. Perlis qui dit:
Il y a deux façons d'écrire des programmes sans erreur; seulement la troisième œuvres.
J'ai récemment entendu cette citation de mon ami, et était incapable de comprendre le sens profond derrière elle.
Qu'est-ce que Perlis parle ici?
La solution
Il signifie qu'il ya vraiment pas programmes sans erreur. Une citation profonde sur les façons d'éviter les erreurs avec une erreur elle-même est la parodie.
Autres conseils
Il n'y a pas de troisième voie.
Il n'y a aucun moyen d'écrire des programmes sans erreur
Je vais répondre avec une autre citation ...
Un jeu étrange. Le seul coup gagnant est de ne pas jouer.
; -)
Comme beaucoup d'autres réponses ont déjà souligné, il n'y a aucun moyen d'écrire un programme sans erreur .
Mais ce que je voudrais souligner est le potentiel méta nature de la citation. Il est essentiellement hors d'erreur de limites. Dans la première déclaration, il définit l'univers ou « liste » ne comportant que deux possibilités ou éléments. Pourtant, dans la deuxième déclaration, il fait référence à un tiers. Ce qui est absurde! Illégale même! Un troisième élément donné une limite de deux élément lui-même est une erreur.
En vérité profonde que la citation est en mesure de démontrer l'essence à laquelle il fait référence.
Cela signifie que tous les programmes non triviales auront des bugs. Il est juste une drôle de façon 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 triviales et même les sont corrects. Considérons par exemple, des langues comme Coq, épigramme ou Agda où cela se fait.
Le les états que arrêt ce n'est pas possible de le faire pour le programme général .
Cela me rappelle un nerd chemise que j'ai vu: Il y a 10 types de personnes dans le monde. Ceux qui connaissent binaire et ceux qui ne le font pas.
Il pourrait aussi être un jeu sur le fait que les listes sont parfois de 0 indexées. $ Var = array ( 'First', 'Second', 'troisième'); Et vous pouvez accéder à cette liste en tant que tels: $ Var [0] = 'First' $ Var [1] = 'Second' $ Var [2] = 'Troisième'
l'indice de tableau littéral 2 points à l'indice "troisième".
Ceci est déjà expliqué dans d'autres termes, mais pas aussi clairement que je pense qu'il devrait être. Cela signifie simplement que vous allez essayer les deux sens, ils auront des erreurs, et enfin vous fixerez vos bogues et ont un programme sans erreur. Comparer avec une autre citation:
La seule façon que des erreurs se produisent dans un programme en étant mis là par l'auteur. Pas d'autres mécanismes sont connus. Les programmes ne peuvent pas acquérir des bugs par assis autour avec d'autres programmes buggy. Mills --Harlan
(Sinon, vous pouvez lire ce que Pierre a dit (que je pense est un étirement). (La troisième voie, qui n'existe pas dans le domaine, les travaux.) Comme je l'ai dit, il est aa étirement, mais vrai.
Ceci est la même citation mon utilisation de papa pour me dire quand je fais des excuses. Le dicton a tendance à aller comme:. «Il y a 3 côtés à une histoire de leur côté, de votre côté, et le côté droit / vrai / correct »
La mise en contexte avec le développement (et d'être un testeur de logiciels par le prof.), Je dirais car il y a tellement de façons de quelque chose de code, il serait logique d'aller avec « Il y a 3 côtés au codage. Votre code, leur le code et le code refactorisé. "
Je pense que cela est parce que les programmeurs / développeurs ont tendance à refactor une fois que le produit devient stable qui est la plupart du temps trop tard, mais la plupart du temps, le refactoring est fait pour améliorer quelque chose que vous et mon pote n'avez pas fait si bien dans le premier lieu.
Hope this helps.
Je pense que, techniquement parlant, que vous pouvez écrire un programme sans erreur non négligeable, mais en raison du problème d'arrêt, il est impossible de prouver que son erreur. Donc, il faut travailler dans 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 un algorithme particulier retourne les bonnes réponses, mais ce n'est pas la même chose que de prouver qu'il est tout à fait correct. http://en.wikipedia.org/wiki/Correctness_(computer_science )
Cependant, mon point est que la citation fait référence au fait que l'on doit supposer un programme a toujours des bugs et d'essayer d'expliquer pourquoi tel est le cas. http://en.wikipedia.org/wiki/Software_bug#Bug_management
Comme un meilleur aperçu, « deux voies » pourrait être une référence à cette citation par Tony Hoare :
Il y a deux façons de construire une conception logicielle: Une façon est de le rendre si simple qu'il n'y a évidemment aucune lacune, et l'autre est de le rendre si compliqué qu'il n'y a pas de lacunes évidentes. La première méthode est bien plus difficile. Il exige la même compétence, le dévouement, la perspicacité, et même l'inspiration que la découverte des lois physiques simples qui sous-tendent les phénomènes complexes de la nature.
Méditez sur ce un peu et vous verrez qu'il dit la même chose: si votre logiciel est non trivial, il a des bugs (mais compliquez assez et ils ne seront pas évident insectes).
