Alan Perlis는 오류없는 프로그램 작성 방법에 대해 무엇을 의미 했습니까? [닫은]

Alan J. Perlis 의 인용문 은 다음과 같습니다.

오류없는 프로그램을 작성하는 두 가지 방법이 있습니다. 세 번째 것만 작동합니다.

나는 최근에 내 친구로부터이 인용문을 들었고 그 뒤의 더 깊은 의미를 이해할 수 없었다.

Perlis는 여기서 무엇을 이야기하고 있습니까?

실제로 오류가없는 프로그램 이 없음을 의미 합니다. 오류 자체로 오류를 피하는 방법에 대한 깊은 인용은 패러디입니다.

세번째 방법은 없습니다.

오류없는 프로그램을 작성할 수있는 방법이 없습니다

나는 다른 인용으로 대답 할 것이다 ...

이상한 게임. 유일한 승리의 움직임은 플레이하지 않는 것입니다.

;-)

다른 많은 답변이 이미 지적했듯이 오류없는 프로그램을 작성할 수있는 방법이 없습니다 .

그러나 내가 지적하고자하는 것은 인용의 잠재적 메타 특성입니다. 본질적으로 범위를 벗어난 오류입니다. 첫 번째 진술에서, 그는 두 가지 가능성 또는 요소만을 갖는 우주 또는 "목록"을 정의한다. 그러나 두 번째 진술에서 그는 세 번째 진술을 언급합니다. 터무니없는 것입니다! 심지어 불법입니다! 두 요소 경계가 주어진 세 번째 요소는 자체 오류입니다.

인용문이 인용하는 본질을 입증 할 수 있다는 점에서 진정으로 심오합니다.

이는 모든 사소한 프로그램에 버그가 있음을 의미합니다. 오류없는 프로그램을 작성할 방법이 없다고 말하는 재미있는 방법입니다.

사소하지 않은 프로그램이라도 오류가없는 프로그램을 작성하고 심지어 올바른 것으로 입증 할 수 있습니다. 이를 수행하는 Coq, Epigram 또는 Agda와 같은 언어를 예로 들어 보겠습니다.

정지 문제 는이 작업을 수행 할 수 없습니다한다고 일반적으로 프로그램 .

이것은 내가 본 괴상한 셔츠를 떠올리게한다. 세상에는 10 가지 유형의 사람들이있다. 바이너리를 아는 사람들과 모르는 사람들.

때로는 목록이 0 인덱싱된다는 사실에 대한 연극 일 수도 있습니다. $ var = array ( 'First', 'Second', 'Third'); 그리고 당신은이리스트에 접근 할 수 있습니다 : $ var [0] = 'First'$ var [1] = 'Second'$ var [2] = 'Third'

따라서 리터럴 배열 인덱스 2는 "Third"인덱스를 가리 킵니다.

이것은 이미 다른 말로 설명되어 있지만, 생각보다 명확하지는 않습니다. 그것은 단순히 두 가지 방법 모두를 시도하고 오류가 있음을 의미하며, 마침내 버그를 수정하고 오류가없는 프로그램을 갖게됩니다. 다른 인용문과 비교하십시오.

프로그램에서 오류가 발생하는 유일한 방법은 작성자가 작성하는 것입니다. 다른 메커니즘은 알려져 있지 않습니다. 프로그램은 다른 버그가있는 프로그램과 함께 앉아 버그를 얻을 수 없습니다. -할란 밀스

(또는 Pierre가 말한대로 이것을 읽을 수 있습니다 (스트레치라고 생각합니다). (도메인에 존재하지 않는 세 번째 방법은 효과가 있습니다.) 내가 말했듯이, 그것은 스트레치이지만 사실입니다.

이것은 내가 변명 할 때 아빠가 나에게 말하는 것과 같은 인용문입니다. "이야기에는 3면이 있습니다. 그들의 측면, 당신의 측면 및 오른쪽 / 진정한 / 올바른 측면".

이것을 개발과 관련하여 (그리고 교수의 소프트웨어 테스터로) 맥락에 놓으면서, "코딩에는 3 가지 측면이 있습니다. 코드, 코드 및 코드 리팩토링 된 코드 "

제품이 안정되면 프로그래머 / 개발자가 리팩터링하는 경향이 있기 때문입니다. 대부분 너무 늦었지만 리팩터링은 대부분 자신과 친구가 처음에는 잘하지 못하는 것을 개선하기 위해 수행됩니다.

이것이 도움이되기를 바랍니다.

기술적으로 말하면 오류가없는 사소한 프로그램을 작성할 수 있다고 생각하지만 Halting 문제로 인해 오류가 없음을 증명하는 것은 불가능합니다. 따라서 다른 프로그램을 증명할 수 없기 때문에 모든 프로그램에 버그가 있다는 가정하에 작업해야합니다.

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

업데이트 : 특정 알고리즘이 정답을 반환한다는 것을 증명할 수는 있지만 그것이 완전히 맞는다는 것은 아닙니다. http://en.wikipedia.org/wiki/Correctness_(computer_science )

그러나 내 요점은 인용은 프로그램에 항상 버그가 있다고 가정하고 그 이유를 설명하려고한다는 사실을 인용하고 있다는 것입니다. http://en.wikipedia.org/wiki/Software_bug#Bug_management

추가 통찰력으로 "두 가지 방법"은 Tony Hoare 의이 인용문에 대한 참조 일 수 있습니다 .

소프트웨어 설계를 구성하는 두 가지 방법이 있습니다. 한 가지 방법은 간단하게 결함이 없도록하고, 다른 방법은 너무 복잡하게하여 명백한 결함이없는 것입니다. 첫 번째 방법은 훨씬 더 어렵다. 그것은 복잡한 자연 현상의 기초가되는 간단한 물리 법칙의 발견과 같은 기술, 헌신, 통찰력 및 영감을 요구합니다.

조금만 묵상하면 그가 똑같은 말을하고 있음을 알 수 있습니다 : 소프트웨어가 사소한 것이 아니라면 버그가 있습니다 (그러나 복잡하고 명백한 버그 는 아닙니다 ).