WHY PROGRAMMING IS A GOOD MEDIUM FOR EXPRESSING POORLY UNDERSTOOD AND SLOPPILY FORMULATED IDEAS, Marvin Minsky
Intro
뭔가 만들고 코드를 작성하는 중에는 그러니까 몰입하고 있는 중에는 그 어떤 순간보다 재미있게 푹 빠져서 코딩을 하는 것 같습니다. 그런데 뭐랄까 요새 좀 개발, 프로그래밍에 대한 사랑..ㅋㅋ이 좀 식었는데 의욕도 좀 줄어들고, 다 비슷한 것 같고 나에게 새롭게 다가오는 자극이 없는 느낌을 받습니다. 그런 의미에서 예전부터 좋아하던 글을 번역하는 포스트를 하나 작성해보기로 했습니다. 《SECRET TEXTS》에서도 이 글을 활용했었는데, 오랜만에 다시 또 꺼내보며 마음을 다잡아보기로. [1] (의역주의)
프로그래밍이 제대로 이해되지 않거나 부정확하게 구성된 아이디어를 표현하기에 좋은 매체인 이유
컴퓨터는 프로그램된 대로만 할 수 있다는 일반적인 믿음이 널리 퍼져 있습니다. 이 잘못된 믿음은 형식과 내용 사이의 혼동에서 비롯된 것입니다. 엄격한 문법이 과정들을 정확하게 설명해 준다는 의미는 아닙니다. 프로그래머는 컴퓨터 문법을 따를 때 매우 정확해야 하지만, 그가 표현하려는 내용은 자유롭게 남아 있습니다. 문법이 엄격한 이유는 컴퓨터 때문이 아니라 프로그래머가 그것을 사용하기 때문입니다. 프로그래머는 자신의 아이디어에 대해 정확할 필요가 없으며, 일정 범위 내에서 허용 가능한 컴퓨터의 답변을 마음속에 두고 그 범위에서 벗어나지 않으면 만족할 수도 있습니다. 프로그래머는 특정 과정을 컴퓨터에 고정시킬 필요가 없습니다. 불확실성의 범위 내에서 프로그래머는 컴퓨터에 새로운 절차를 생성하도록 요구하거나, 선택 규칙을 권장하고 컴퓨터가 어떤 선택을 할지에 대해 조언할 수 있습니다. 따라서 컴퓨터는 실행할 내용이나 방법에 대한 매우 명확하고 정확한 공식화가 없어도 프로그램될 수 있습니다.
여기서 제시된 주장은 "디자인"에 관한 것이 아니라, 우리가 컴퓨터를 통해 어떤 일을 도울 수 있는지에 대한 일반적인 질문에 대한 것입니다. 여러 가지 이유로 인해 이러한 가능성을 과소평가하는 경향이 있습니다. 시작하기 전에, 나는 상황을 이해한다고 믿는 많은 사람들이 취하는 "중도적" 입장을 수용하는 함정에 빠지지 않도록 경고하고 싶습니다. 공상과학 작가들, 각종 과학자들, 경제 예측가들, 심리학자들, 심지어 논리학자들까지 종종 우리에게 컴퓨터는 절대 진정으로 생각할 수 없다고 말합니다. "우리는 기계에 대해 의인화된 사고방식을 갖지 말아야 합니다. 기계는 프로그램이 말하는 대로만 수행하며, 독창적이거나 창의적일 수 없습니다." 우리는 모두 이러한 견해를 들어왔고, 대부분 그것을 받아들입니다.
사고 과정의 모호성에 대해 인문학자가 열변을 토하는 이유는 쉽게 이해할 수 있습니다. 왜냐하면 그 모호성과 의도된 의인화된 독창성 사이에는 쉬운 잘못된 추론이 있기 때문입니다. 그러나 여기서 중요한 것은 이 잘못된 추론이 아닙니다. 여기서 논의되는 오류는 매우 명확하고 정밀한 공식이 없이는 컴퓨터 프로그램을 작성할 수 없다는 널리 퍼진 미신입니다. 이 미신은 인문학자들뿐만 아니라 과학자들, 심지어 "컴퓨터 과학자들"에 의해 적어도 동일한 정도로 퍼지고 있습니다.
우리가 컴퓨터의 한계에 대해 들을 때, 보통 이런 일반적인 형태를 띱니다: "컴퓨터는 창의적일 수 없다. 시키는 대로만 정확히 수행할 수 있다. 과정이 완벽하게 정밀하게 공식화되지 않으면, 컴퓨터로 그것을 수행할 수 없다." 이제, 이 말은 한 가지 의미에서는 완전히 사실이지만, 다른 의미에서는 절대적으로 거짓입니다. 왜 그런지 설명하기 전에, 컴퓨터가 등장하기 훨씬 전에 악마에 대해서도 같은 이야기가 있었다는 점이 흥미롭습니다. 즉, 그는 창의적인 것처럼 보일 수만 있다는 것이었습니다.
1966년 9월호 Scientific American 에서 저는 세 가지 프로그램을 논의했습니다. 첫 번째는 Samuel의 체커 프로그램으로, 마스터 수준에서 플레이합니다. 또 하나는 Evans의 ANALOGY 프로그램으로, 기하학적 도형들 사이의 유사 관계를 인식하는 특정 지능 테스트 문제에서 꽤 잘 작동합니다. 세 번째는 Bobrow의 "STUDENT"라는 프로그램으로, 영어로 주어진 고등학교 대수학 "이야기" 문제를 풉니다:
메리는 앤이 지금 나이였을 때 메리의 나이의 두 배였다. 메리가 24세라면, 앤은 몇 살인가?
이 프로그램은 일부 문제를 해결하지만, 모든 문제를 해결하지는 못합니다. 그 글에서 저는 이러한 연구를 보다 다재다능한 일반 지능의 방향으로 확장하는 문제에 관심을 가졌습니다. 그러나 여기서 제 목적을 위해서는, 이러한 프로그램들이 현재 상태에서도 충분히 적절한 예가 될 수 있습니다. 이 프로그램들은 처리할 수 있는 것에 한계가 있지만, 이미 오래된 편견들을 충분히 혼란스럽게 만들고 있습니다.
전통적인 관점은 프로그램이 각 상황에서 정확히 무엇을 해야 할지를 정해놓은 고정된 규칙들의 집합에 불과하다는 것입니다. 이는 프로그래밍을 처음 배우는 사람들을 안심시키거나 초보자가 작성한 프로그램을 분석하는 데 유용한 관점입니다. 그러나 더 발전된 프로세스에 대해서는, 이 말이 한 가지 의미에서는 완전히 사실일 수 있지만, "집이 건축 자재의 배치에 불과하다"거나 "책이 단지 긴 단어들의 문자열에 불과하다"고 말하는 것만큼이나 맞는 말일 것입니다. 실제로, 제 Scientific American 기사에 대한 리뷰가 1967년 1월 Computer Reviews 8권 1호에 실렸는데, 이 리뷰에서는 이러한 프로그램들이 "사전 검색 루틴, 검색 및 비교 함수의 연속, 그리고 정렬-병합 유형의 작업"으로 구성되어 있다고 주장하고 있습니다.
논리와 일관성
좋은 논리학자와 나쁜 철학자의 몇 가지 주장에서 파생된 회의적인 태도 중 하나에 대해 논의하면서 시작하겠습니다. 우리는 다음과 같은 이야기를 듣습니다: "논리 시스템의 자기 일관성을 증명하는 것에 관한 특정 정리들은 '발견의 과정을 완전히 기계화하는 것은 불가능하며, 따라서 인간은 항상 기계보다 우위를 가질 것이다'라는 결과를 낳는다." 아마도 거의 모든 독자가 괴델의 정리에 대해 들어봤을 것이고, 대부분은 이 주장된 결과에 대해 들어봤을 것입니다. 그러나 이것은 논리적 결과가 아닙니다. 왜냐하면 이 주장은 부주의한 기술적 실수에 기초하고 있기 때문입니다. 문제 해결 질문에 적용할 수 있다면, 괴델의 정리는 엄격하게 말해 완벽하게 자기 일관적인 논리 시스템에만 적용됩니다. 사람들은 이처럼 일관되지 않으며, 우리는 반드시 그러한 방식으로 기계를 구축해야만 하는 이유가 전혀 없습니다. 대신에, 우리는 이미 모순된 사실적 주장을 용인할 수 있는 기계를 구축할 수 있고, 이미 그렇게 하고 있습니다. 이를 위해서는 모순을 해결하기 위한 선택 규칙, 상충하는 진술 사이에서 선택하기 위한 우선순위 계층 등을 추가해야 합니다. 이러한 체계의 간단한 예는 Bertram Raphael의 1964년 MIT 박사 논문에 설명되어 있습니다. 이 프로그램과의 대화 예시는 다음과 같습니다:
모든 소년은 사람이다.
(이해했습니다)
손가락은 손의 일부이다.
(이해했습니다)
각 사람은 두 손을 가지고 있다.
(위 문장은 애매합니다. 다시 표현해 주세요.)
각 사람에게는 두 손이 있다.
(이해했습니다)
존은 몇 개의 손가락을 가지고 있습니까?
(손가락이 존의 일부인지 모릅니다.)
존은 소년입니다.
(이해했습니다)
존은 몇 개의 손가락을 가지고 있습니까?
(손마다 몇 개의 손가락이 있습니까?)
각 손에는 5개의 손가락이 있습니다.
(이해했습니다)
존은 몇 개의 손가락을 가지고 있습니까?
(답변: 10개)
존은 몇 대의 자동차를 가지고 있습니까?
(위 문장은 애매합니다. 다시 표현해 주세요.)
미국 대통령은 누구입니까?
(진술 형식을 인식하지 못했습니다.)
소년은 테이블의 왼쪽에 있습니다.
(G02840은 테이블입니다)
(이해했습니다)
램프는 테이블의 왼쪽에 있습니다.
(G02841은 램프입니다)
(위 진술은 불가능합니다.)
테이블은 의자의 오른쪽에 있습니다.
(G02842는 의자입니다)
(이해했습니다)
사람의 상대적인 위치는 무엇입니까?
(왼쪽에서 오른쪽 순서는 다음과 같습니다)
(의자 소년 테이블)
Raphael의 지식 수집, 질문-응답 시스템은 일반 원칙과 충돌할 때 특정 사실에 더 높은 우선순위를 부여하는 방법을 보여줍니다. 이 "예외 원칙"은 물론 모순을 해결하는 다소 단순한 방법이며, 진술들 사이에 명확한 일반성의 차이가 있을 때만 사용할 수 있습니다. 진술들이 같은 수준에 있을 때, 프로그램은 단순히 나중에 나온 진술을 거부합니다. 다음은 그 예시입니다:
모든 손에는 5개의 손가락이 있습니다.
(이해했습니다)
사람에게는 두 손이 있습니다.
(이해했습니다)
소년은 사람입니다.
(이해했습니다)
톰은 소년입니다.
(이해했습니다)
딕은 소년입니다.
(이해했습니다)
해리는 소년입니다.
(이해했습니다)
톰은 9개의 손가락을 가지고 있습니다.
(위 문장은 애매합니다. 그러나 (가지고 있다)는 (부분으로 가지고 있다)을 의미한다고 가정합니다.)
(이해했습니다)
딕은 한 손을 가지고 있습니다.
(위 문장은 애매합니다. 그러나 (가지고 있다)는 (부분으로 가지고 있다)을 의미한다고 가정합니다.)
(이해했습니다)
톰은 몇 개의 손가락을 가지고 있습니까?
(답변: 9개)
딕은 몇 개의 손가락을 가지고 있습니까?
(답변: 5개)
해리는 몇 개의 손가락을 가지고 있습니까?
(답변: 10개)
조는 몇 개의 손가락을 가지고 있습니까?
(손가락이 조의 일부인지 모릅니다.)
물론, Raphael은 다른 우선순위 규칙을 작성할 수도 있었습니다. 그런데, 프로그램의 "위 문장은 애매합니다..."라는 진술은 "has"라는 단어가 "부분으로서 가지고 있다" 또는 "소유하다" 중 어느 의미로 사용되었는지를 고려하고 있습니다. Raphael의 프로그램은 보통 그 단어가 논의 중인 개체들이 이미 무언가를 소유하고 있는지, 또는 무언가의 일부인지 등을 연구하여 올바르게 추측합니다. 이에 대해서는 나중에 더 자세히 설명할 것입니다. 이러한 "문맥적" 결정을 프로그래밍할 수 있다는 Raphael의 시연은 더 일반적인 점을 보여주거나, 혹은 프로그램에 대한 "단지 ~일 뿐이다"라는 접근 방식보다 다른, 더 건전한 태도를 보여줍니다. 따라서 우리는 프로그램에 대해 생각하는 이러한 더 나은 방법들 중 일부를 설명하려고 합니다.
(1) 명령어의 연속으로서의 프로그램
가장 흔하고 단순한 관점은 컴퓨터 프로그램이 어떤 데이터에 대해 수행해야 할 명확한 작업들의 연속이라는 것입니다. 간단한 프로그램의 예를 들어보겠습니다. X가 입력으로 주어진 숫자라고 가정합시다.
START: SET R = 1
LOOP: SET S = X/R
SET T = R + S
SET R = T/2
SET U = R x R
SET V = X - U
IF |V| > .001, GO TO LOOP
ELSE PRINT V
이 프로그램(아이작 뉴턴에 의해 고안된 것으로 알려짐)은 X의 제곱근에 대한 근사값을 계산합니다. 프로그램의 각 줄에서 현재 상황이 무엇인지, 그리고 다음에 무엇을 해야 하는지 명확하게 알 수 있습니다. 물론, 이 과정이 올바른 R 값을 도출하고 계산을 종료하도록 개발된 상황의 연속성이 결국 받아들일 수 있는 값으로 이어질 것임을 수학적으로 분석해야 합니다. 따라서 이러한 명령어들을 일련의 단계로 생각하는 데 큰 문제는 없습니다. "GO TO" 명령어는 메인 루프의 여러 사본을 위한 초약어로 생각될 수 있습니다. 물론, 분석이 이루어지기 전까지는 이 프로그램을 유용하지만 명확히 이해되지 않은 아이디어의 표현으로 생각하는 것이 좋습니다.
(2) 법정으로서의 프로그램
Raphael의 프로그램에서는 "x has y" 형태의 문장이 등장할 때, "has"가 "소유하다(owns)" 또는 "일부로서 가지고 있다(has as parts)"를 의미하는지 결정해야 합니다.
존은 사람입니다.
(이해했습니다.)
딕은 사람입니다.
(이해했습니다.)
체인은 자전거의 일부입니다.
(이해했습니다.)
전기톱에는 체인이 있습니다.
(위 문장은 모호합니다. 하지만 저는 "has"가 "일부로 가지고 있다"를 의미한다고 가정합니다.)
(이해했습니다.)
존은 체인을 소유하고 있습니다.
(이해했습니다.)
딕은 의자를 가지고 있습니다.
(위 문장은 모호합니다. 하지만 저는 "has"가 "일부로 가지고 있다"를 의미한다고 가정합니다.)
뻐꾸기 시계에는 체인이 있습니다.
(위 문장은 모호합니다. 다시 표현해 주십시오.)
문제가 인식되면, 프로그램의 다른 부분으로 전달되어 이전에 일어난 모든 일을 검토할 수 있게 됩니다. 이 서브 프로그램은 다음과 같은 기준에 따라 결정을 내립니다.
- y가 이미 다른 것의 일부로 알려져 있거나, 일부로 알려진 집합의 구성원인가?
- y가 이미 소유된 것으로 알려져 있거나, 소유된 것으로 알려진 집합의 구성원인가?
- (1) 또는 (2) 중 하나만 참이라면 해당 방향으로 선택합니다. 둘 다 해당하지 않으면 추가 정보를 요청합니다. 둘 다 참이라면 아래 (4)번을 고려합니다. (즉, 프로그램은 이전에 획득한 정보가 그 세계의 "모델"에 어떻게 통합되었는지에 대한 증거를 사용합니다.)
- 이 지점에 도달했다면, y는 이미 무언가의 일부로서 또는 소유된 것으로 알려져 있으며, 더 정교한 검사를 필요로 합니다. U1과 U2는 각각 질문 (1)과 (2)에 대한 답변에 따라 존재하는 것으로 알려진 "무언가" 또는 "어떤 집합"을 나타냅니다. 이는 y에 따라 달라집니다. 이제 우리는 x가 U1 또는 U2의 구성원인지 또는 주제인지 묻습니다. 둘 다 아니라면 포기합니다. 둘 중 하나가 해당된다면, 해당 결과(일부로서 또는 소유)를 선택합니다. 둘 다 해당된다면 다시 포기하고 추가 정보를 요청합니다.
Raphael이 말하듯이:
"이러한 기준은 단순하지만, 이 프로그램이 애매한 단어 'has'가 포함된 다양한 문장에서 의도된 목적에 대해 꽤 합리적인 결정을 내리게 하는 데 충분합니다. 물론, 프로그램은 위 대화에서 'John owns a chain' 문장보다 먼저 'Dick has a chain' 문장이 제시된 경우와 같은 실수를 저지를 수 있습니다. 하지만 유사한 상황에서 새로운 단어를 접한 인간도 비슷한 실수를 할 것입니다. 여기서 중요한 점은, 애매한 문장의 의미를 자동으로 해결하는 것이, 애매하지 않은 문장에 적절히 노출되어 단어의 설명을 참조함으로써 가능하다는 것입니다."
따라서, 프로그램은 이전 지식의 수집을 통해 x와 y가 서로 어느 방향으로 더 밀접하게 관련이 있는지를 찾기 위해 시도하라고 지시받습니다. 이 "부분" 프로그램은 작은 재판소, 또는 증거 수집 및 증거 평가 절차로 생각하는 것이 가장 좋습니다. 이를 문제 해결의 사전에 정해진 순서에 직접 속하는 절차로 생각하기보다는, 프로그램이 일관성이나 모호함에 직면했을 때 상담할 수 있는 항소 법원으로 생각하는 것이 좋습니다. 이제, 우리가 많은 이러한 법정을 가진 대형 프로그램을 작성할 때, 각 법정이 필요할 때 다른 법정을 호출할 수 있다고 가정하면, 프로그램을 "순서"로 생각하는 것은 무의미해집니다. 비록 프로그래머 자신이 이러한 "법적" 원칙들을 제시했더라도, 프로그램이 실행되는 동안 이 절차들이 언제, 어디서 서로를 호출할지에 대해 매우 불완전한 이해만 가지고 있을 뿐입니다. 그리고 특정 "법정"에 대해서는, 그것이 호출될 몇 가지 상황에 대해서만 대략적인 이해를 가지고 있을 뿐입니다. 간단히 말해, 초보 단계를 지나면, 프로그래머들은 단순히 '명령어의 연속'을 작성하는 것이 아니라, 작은 사회 또는 과정의 개체들을 위해 작성하게 됩니다. 아무리 노력해도, 그 상호작용의 모든 세부 사항을 미리 완전히 예상할 수는 없기 때문입니다. 결국, 그것이 우리가 컴퓨터가 필요한 이유입니다.
(3) 프로그램을 조언의 모음으로 보는 관점
프로그래밍이 본질적으로 정확하고 엄격한 표현 매체라는 착각은 단지 공포에 질린 인문주의자들뿐만 아니라 대부분의 컴퓨터 "전문가들"도 공유하는 큰 착각입니다. 이 착각은 형식과 내용 사이의 기본적인 혼동에서 비롯됩니다. 만약 시인들이 14줄로 이루어진 시를 써야 한다면, 그들이 더 정확해지지는 않을 것입니다. 만약 작곡가들이 12음계를 모두 사용해야 한다면, 그것이 전체 형식을 제한하지는 않을 것입니다. 만약 디자이너들이 4차 곡면만 사용해야 한다면, 그것을 눈치챌 사람은 거의 없을 것입니다! 따라서 (구형의) 프로그래밍 언어의 다소 엄격한 문법이 과정을 설명하는 데 있어서 정확성을 만든다는 의견에 대해 일치된 견해를 발견하는 것은 유머러스합니다. 컴퓨터 문법(구문)에 있어 매우 정확해야 프로그램이 실행될 수 있다는 것은 사실입니다. 철자나 구두점 오류가 허용되지 않습니다! 하지만 이것이 여러분이 프로그램이 실제로 어떤 일을 할 것인지에 대해 정확한 아이디어를 가지게 만든다는 것은 완전히 거짓입니다. 예를 들어, FORTRAN에서는 미리 작성된 프로시저를 호출하려면 "GO TO"와 같은 고정된 형식을 사용해야 합니다. "USE"나 "PROCEED ON TO" 등의 표현을 사용할 수 없습니다. 따라서 구문은 엄격하지만, "GO TO"로는 거의 무엇이든 할 수 있으므로 내용은 자유롭습니다.
더 나쁜 오류는 이러한 엄격함이 컴퓨터 때문이라고 가정하는 것입니다! 이는 프로그래밍 언어를 정의한 프로그래머들 때문입니다! Bobrow의 STUDENT 프로그램에서는 원한다면 "USE ALWAYS MEANS GO TO"라고 한 번만 입력하면 이후 간단한 상황에서는 "GO TO" 대신 "USE"를 사용할 수 있도록 해줍니다. 물론, 이는 유연성의 사소한 예에 불과하지만, 대부분의 사람들이 잘 이해하지 못하는 점입니다: FORTRAN의 엄격함은 엄격함의 미신에서 비롯된 것이지, 어떤 엄격한 사실의 사례가 아닙니다!
더 유연한 현대 시스템의 예로, Warren Teitelman이 개발한 프로그래밍 언어인 PILOT(1966년 MIT 박사 학위 논문)이 있습니다. 이 언어는 프로그래머가 외부 언어로 자신의 프로그램과 언어 자체를 수정할 수 있게 해줍니다. 우리는 종종 이러한 것을 "프로그램"이라기보다는 "조언"으로 생각할 수 있습니다. 왜냐하면 이들은 예상치 못한 시점에 작성되며, 보통 기본 상황에서 조건부로 적용되거나 이전 조언의 결과로 적용되기 때문입니다. 예를 들어, 유명한 "선교사와 식인종" 딜레마(보트에 두 명만 탈 수 있는 문제)를 해결하는 프로그램을 개발하는 동안 작성된 다음과 같은 예가 있습니다:
Tell progress, if m is a member of side-1 and m is a member of side-2 and (countq side-1 m) is not equal to (countq side-1 c), then quit.
(이전의 입력 시스템에 대한 조언 모음을 사용하여 합리적인 인간적 입력 구문을 생성했습니다.) 프로그램은 사람들을 강 건너로 옮기는 "진전"을 만드는 것을 선호하며, 다양한 배열과 움직임을 시도하는 휴리스틱 검색입니다. Teitelman은 기본 프로그램을 먼저 작성합니다. 그러나 선교사들이 잡아먹히게 되고, 위의 "조언"은 프로그램이 강의 양쪽에서 선교사와 식인종의 수가 동일하지 않은 움직임을 거부하도록 "진전 측정 부분을 수정"하라고 지시합니다. Teitelman은 이렇게 말합니다:
이것은 식인 조건을 PROGRESS에 부여합니다. 단순히 숫자를 세고 비교하는 것으로는 충분하지 않습니다. 왜냐하면 모든 식인종이 한쪽에 있고 선교사가 없을 때, 그들은 3대 0으로 선교사보다 많아지기 때문입니다. 그러나 아무도 잡아먹히지 않습니다.
그러나 중요한 점은 구문 제한의 완화가 아니라 방금 프로그램에 수정된 조언의 성격입니다. "tell progress" 문장은 "progress"가 이미 어떻게 작동하는지, 또는 그것이 "프로그램"의 어디에 위치하는지 잘 알지 못한 상태에서도 작성될 수 있습니다. 그것은 이미 다른 조언에 의해 영향을 받고 있을 수도 있으며, 새로운 조언이 언제 사용되고 언제 무시될 것인지 명확히 알지 못할 수도 있습니다. 다른 기능이 수정되어 특정 상황에서는 "progress"가 상황을 평가하지 못할 수도 있으며, 그러면 누군가는 잡아먹히게 될 것입니다. 만약 그런 일이 발생하면, 외부인은 그 이유를 추측하려고 할 것입니다.
그는 다음과 같은 선택 사항을 가질 수 있습니다: (1) 기존 프로그램을 철저히 이해하고 문제를 "정말로 고치는" 것이나 (2) 결함이 있다고 상상하는 상황을 설명하고 프로그램이 선교사를 잡아먹히는 위치로 이동하지 않도록 지시하는 새로운 조언 문장을 입력하는 것입니다. 프로그램이 부분적으로 이해된 패치와 수정의 진화를 통해 강력해질 때, 프로그래머는 내부 세부 사항을 놓치기 시작하고 더 이상 무슨 일이 일어날지 예측할 수 없게 됩니다. 그리고 알기보다는 희망하게 되어, 프로그램을 마치 예측할 수 없는 행동을 하는 개체로 지켜보게 됩니다.
이것은 이미 일부 대규모 프로그램에서 사실이며, 우리가 다중 콘솔 컴퓨터의 시대에 접어들면서 곧 더욱 심각해질 것입니다. 타임셰어링이 가능해지면 여러 프로그래머가 각각 다른 콘솔에서 다른 예제를 테스트하고 독립적으로 조언을 삽입하여 대규모 휴리스틱 프로그램을 개발하고 수정할 것입니다. 프로그램은 효율성이 향상될 것이지만, 프로그래머 중 누구도 이를 완전히 이해하지 못할 것입니다. (물론, 이것이 항상 성공적이지는 않을 것입니다. 상호 작용으로 인해 프로그램이 더 악화될 수 있으며, 아무도 그것을 다시 고칠 수 없을지도 모릅니다!) 이제 "프로그램은 단지 프로그래머가 지시한 대로만 작동한다"는 주장에 문제가 있다는 것을 알 수 있습니다. 한 명의 프로그래머만 존재하지 않기 때문입니다.
표현의 자유와 아이디어의 구체성
마지막으로, 프로그램을 작성하고자 할 때 무엇을 해야 하는지, 또는 어떻게 해야 하는지에 대한 아이디어가 불완전하게 정의된 경우 어떻게 해야 하는지에 대해 논의하겠습니다. 이 문제에 대해 모든 사람을 혼란스럽게 한 논리적 오류는 매우 간단합니다:
대전제: 내가 프로그램을 작성하면 프로그램은 특정한 일을 할 것이다. 모든 프로그램은 명확한 일을 한다.
소전제: 내 아이디어는 모호하다. 나는 특정한 결과를 염두에 두고 있지 않다.
결론: 따라서, 프로그램은 내가 원하는 것을 하지 않을 것이다.
그래서 모든 사람들이 생각하기를, 프로그램은 모호한 아이디어를 표현하지 못한다고 생각합니다.
사실 두 가지 오류가 있습니다. 첫 번째로, 특정 결과물을 염두에 두고 있지 않다고 말하는 것은 충분하지 않습니다. 대신, 누군가 (불명확한) 충분한 성능의 스펙트럼을 가지고 있고, 컴퓨터의 퍼포먼스가 그 범위 안에 든다면 좋은 것입니다. 스펙트럼이 넓을수록 프로그램을 구체화할 때 자유가 넓어집니다. 이는 특정 단어 또는 지시어를 작성하더라도 무효화되지 않습니다. 왜냐하면 그 프로그램을 여전히 하나의 인스턴스처럼 간주할 수 있기 때문입니다. 이 의미에서, 이렇게 '쓰인 이야기'를 여전히 작성자의 마음속에 남아있는 모호한 개념중 하나의 사례로 간주할 수 있습니다.
이것은 회피로 들릴 수 있으며, 어느 정도는 사실입니다. 두 번째 오류는 내가 특정한 프로세스를 작성해야 한다는 주장에 달려 있습니다. 불확실성의 각 영역에서 나는 특정 절차 대신 절차 생성기, 선택 규칙, 선택에 관한 조언 법정 등을 지정할 자유가 있습니다. 따라서 행동은 광범위할 수 있으며, 두 번 다시 동일한 경로를 따르지 않아도 되며, 그것은 작성자의 마음속에 있는 관용 범위를 대략적으로 포함할 수 있습니다.
이 시점에서 이런 마지막 반대가 있을 수 있습니다: 프로그램이 정확히 이 범위에 놓여있을까요? 저는 프로그래밍이 명확하지 않은 아이디어를 표현하는 쉬운 방법이라고 말하는 것이 아닙니다! 이 매체의 뛰어난 유연성을 최대한 활용하려면 기술적, 지적, 그리고 미적 능력이 필요합니다. 프로그램의 동작을 정확히 특정 범위에 맞추는 것은 매우 어려울 수 있으며, 이는 작성자가 특정한 정도의 모호성을 표현하기 위해 일정한 기술이 필요한 것과 마찬가지입니다. 컴퓨터는 바이올린과 같습니다. 초보자가 처음에 축음기를 사용해보고 다음에 바이올린을 시도하는 모습을 상상해 보세요. 그는 후자에 대해 이렇게 말할 것입니다, "소리가 형편없다." 이것이 인문학자들과 대부분의 컴퓨터 과학자들로부터 들었던 주장입니다. 그들은 컴퓨터 프로그램이 특정 목적에는 적합하지만, 유연하지 않다고 말합니다. 바이올린이나 타자기도 마찬가지입니다. 사용법을 배우기 전까지는 유연하지 않습니다.