백년 언어

원본 The Hundred-Year Language 폴 그래햄

2003년 4월

(이 에세이는 PyCon 2003에서 행한 키노트 연설에서 유래되었다.)

백년 후에 생활이 어떨지는 예측하기 힘들다. 확신을 갖고 이야기할 수 있는 것은 몇개 안된다. 모두가 날으는 자동차를 몰 것이고, 수백층의 건물이 가능하게끔 고도제한 규정이 풀릴 것이며, 하루의 대부분이 컴컴할 것이며, 여자들은 모두 무술 훈련을 받을 것이다. 여기서 이 상상의 한 부분을 확대해 보자. 날라다니는 자동차를 조종하는 소프트웨어를 짜기 위해선 무슨 프로그래밍 언어를 쓸까?

우리가 결국은 이런 언어들을 사용하게 될 거라는 이유보다는, 우리에게 운이 있다면, 지금으로부터 그때에 이르는 도중에 언어들을 사용할 것이기 때문에 이 문제는 생각해 볼 가치가 있다.

생물 종들처럼, 언어들은 사방에서 막다른 가지가 뻗어져 나오는 진화 계통수(樹)를 형성할 거라고 생각한다. 벌써 이런 일들은 일어나고 있다. 코볼은 한 때 인기 있었음에도 불구하고 어떤 정신적 후계자도 없어 보인다. 진화적으로 막다른 가지— 네안데르탈 언어이다.

자바도 비슷한 운명을 겪으리락고 예측한다. 사람들은 가끔 나에게 편지를 보내 “자바가 성공적인 언어가 되지 못할 거라고 어떻게 이야기할 수 있나? 이미 성공적인 언어인데”라고 이야기한다. 언어에 대한 책(특히 개별적인 책)들이 책장에서 차지하고 있는 공간의 크기로 성공을 잰다면 그렇다고 인정한다. 혹은 직업을 얻기 위해선 그 언어를 배워야 한다고 믿는 학부생의 숫자로 재던가. 자바가 성공적인 언어가 되지 못할거라고 말하는 것은 좀 더 구체적인 의미로, 자바가 코볼처럼 진화적으로 막다른 언어가 될 거라는 것이다.

이건 단지 추측이다. 내가 틀릴 수도 있다. 요점은 자바를 깍아내리는 것이 아니라 진화수 문제를 제기해서 사람들이 어떤 언어 X는 진화수에서 어느 위치에 있는가를 질문하게 하는 것이다. 이런 질문을 하는 이유는 백년 후에 우리 유령들이 거봐 내가 맞았지라고 하려는 것이 아니라, 큰 줄기에 가까이 머무르는 것이 현재 프로그램하기 좋은 언어를 찾는데 유용한 지침이 되기 때문이다.

어떤 시점에서라도 진화수의 큰 줄기에 있는 것이 가장 행복할 것이다. 수적으로야 아직 네안데르탈인이 많이 있겠지만 그들은 괴로울게 틀림없다. 크로마뇽인들이 계속 찾아와서 때리고 음식을 훔쳐갈테니까.

내가 백년 후의 언어가 어떨지 궁금해 하는 이유는 그래야 지금 어떤 가지에 운을 걸어야하는지 알 수 있기 때문이다.

언어의 진화에서는 줄기들이 합쳐질 수 있다는 것이 생물학적 진화와는 다르다. 예를 들어 포트란 줄기는 알골의 후손들과 합쳐지고 있는 것으로 보인다. 이론적으로 줄기의 병합은 생물학적으로도 가능하다. 하지만 세포보다 큰 단위에서 일어난 적은 없어 보인다.

언어들이 더 잘 합쳐지는 이유의 일부는 가능한 가짓수가 적기 때문이고, 일부는 돌연변이가 랜덤하지 않기 때문이다. 언어를 설계하는 사람들은 다른 언어로부터 아이디어를 열심히 가져온다.

프로그래밍 언어의 진화가 어느 방향으로 일어날지에 대해서 언어 설계자들이 생각해 보는 것은 매우 유용하다. 그에 따라 방향을 잡을 수 있기 때문이다. 이런 경우 “본 줄기에 머무르기”는 좋은 언어를 선택하는 것을 넘어서서, 언어 설계에 있어서 바른 결정을 내리는 지침이 된다.

모든 프로그래밍 언어는 두 부분으로 나누어질 수 있다. 공리 역할을 하는 기본적인 오퍼레이터의 집합과 그것들로 씌여질 수 있는 나머지 부분이다.

이 기본적인 오퍼레이터들이 어떤 언어가 장기적으로 살아 남는데 가장 중요한 요소라고 생각한다. 나머지 부분은 바꿀 수 있다. 마치 집을 살 때 무엇보다도 먼저 위치를 고려해야된다는 법칙과 같다. 다른 모든 것은 나중에 고칠 수 있지만 위치를 고칠 수는 없다.

공리를 잘 선택하는 것만이 중요한게 아니라 그 개수가 적어야 한다. 수학자들은 공리에 대해서 늘 이런식으로 느껴왔다 — 적을 수록 좋다 — 그리고 거기에는 그럴만한 이유가 있다고 생각한다.

적어도 어떤 언어의 핵심을 자세히 살펴서 제거할 수 있는 공리가 있는지 보는 것은 유용한 훈련이 될 것이다. 게으른 생활을 오래해봐서 경험상 더러움이 더러움을 낳는 것을 안다. 침대 밑이나 방구석에서 뿐만이 아니라 소프트웨어에서도 이런 일이 일어나는 것을 봤다.

진화 계통수의 본 줄기들이 가장 작고, 가장 깨끗한 핵심을 가진 언어들을 관통해서 지나간다라는 감이 온다. 그 언어 자체로 그 언어의 더 많은 부분을 작성할수록 좋다.

물론 나는 백년 후에 프로그래밍 언어가 어떨 것인지에 대해 물으면서 큰 가정을 하고 있다. 백년 후에도 우리는 프로그램을 짜고 있을 것인가? 그냥 컴퓨터에게 우리가 시키고 싶은게 뭔지 이야기하면 안될까?

지금까지 그 분야에선 큰 진전이 없었다. 나의 추측은 백년 후에도 사람들은 아직 프로그램을 이용해서 컴퓨터에게 하고 싶은 일을 시킬 것이다. 프로그램은 그런 것이라고 인지할 것이고. 현재는 프로그램을 짜서 해결하는 많은 작업들이 백년 후에는 그렇지 않을 수 있다. 하지만 오늘날 하고 있는 많은 형태의 프로그래밍이 그때에도 계속 있을거라 생각한다.

백년 후에 어떤 기술이 어떻게 보일지 예상하는 것은 주제넘어 보일 수 있다. 하지만 우리가 이미 거의 오십년의 역사를 지나왔다는 것을 기억하라. 지난 오십년간 언어가 얼마나 느리게 발전되어 왔는지 생각해 볼 때 백년을 앞서 보는 것은 이해가능한 아이디어이다.

언어는 실제로는 기술이 아니기 때문에 천천히 발전한다. 언어는 표기법이다. 프로그램이란 컴퓨턱가 당신을 위해 풀어주길 원하는 문제를 수학적으로 정형화해 설명한 것이다. 따라서 프로그래밍 언어의 발전 속도는 교통이나 통신같은 기술의 발전 속도보다는 수학적 표기방법의 발전 속도에 가깝다. 수학적 표기방법도 발전하지만 기술 분야에서 보듯이 엄청난 단계를 뛰어넘는 식은 아니다.

백년 후에 컴퓨터가 무엇으로 만들어지던지 간에 현재보다는 무척 빠를 것이라고 가정하는 것은 안전해 보인다. 만약 무어의 법칙이 계속된다면, 컴퓨터는 74퀸틸련 (73,786,976,294,838,206,464) 배 빠르게 된다. 상상하기 힘든 형태이다. 사실은 속도 분야에서 가장 그럴듯한 예상은 무어의 법칙이 멈출 것이라는 것이다. 그 어떤 것도 18개월마다 두배가 되어야 한다면 언젠가는 어떤 종류의 기본적인 제한에 부닥치게 될 것같다. 하지만 컴퓨터가 무척 빨라질 것이라고 믿는데는 아무 문제도 없다. 심지어 보잘것없이 백만배 빨라지는데 그친다 해도 프로그래밍 언어에 대한 기본 규칙을 엄청나게 바꿀 것이다. 다른 무엇보다도 우리가 느리다고 생각하는 언어(아주 효과적인 코드를 생산해 내지 못하는 언어를 뜻함)들에게 많은 기회가 있을 것이다.

그래도 어떤 응용프로그램들은 계속 속도를 요구할 것이다. 우리가 컴퓨터를 이용해서 풀고자하는 문제들 중 일부는 컴퓨터에 의해 만들어진 것이다; 예를 들면, 동영상을 처리해야 하는 속도는 그 동영상을 만들어내는 다른 컴퓨터의 속도에 맞추어야한다. 그리고 근본적으로 무제한 용량의 사이클을 먹는 부류의 문제들도 있다: 이미지 렌더링, 암호화, 시뮬레이션.

만약 어떤 응용프로그램들은 더욱더 비효과적이 될 수도 있는 동안 어떤 것들은 하드웨어가 제공할 수 있는 최고의 속도를 요구한다면, 빠른 컴퓨터에선 언어가 폭넓은 범위의 효율성을 담보해야 한다는 것을 의미한다. 이것은 이미 일어나고 있는 현상이다. 새롭게 인기얻은 언어들 중 일부의 현재 구현은 지난 수십년의 기준으로 보면 깜짝 놀랄 정도로 낭비가 심하다.

이런 현상은 프로그래밍 언어에만 일어나는 것은 아니다. 이것은 일반적인 역사적 경향이다. 기술이 발전하면서 그전 세대가 낭비라고 생각했던 것들을 그 세대는 할 수 있게 된다. 30년 전에 사람들은 우리가 얼마나 가볍게 장거리 전화를 하는지 보면 놀랄 것이다. 백년 전의 사람들은 우리가 하루만에 보스턴에서 멤피스를 거쳐 뉴욕에 갈 수 있다는 것에 더욱 놀랄 것이다.

다음 백년 동안 더 빨라진 하드웨어가 우리에게 제공할 그 모든 사이클이 무엇에 쓰일지 난 이야기할 수 있다. 거의 대부분이 낭비될 것이다.

나는 컴퓨터 용량이 귀할 때 프로그램을 배웠다. 4K TRS-80 메모리에 맞도록 베이직 프로그램의 모든 공백을 지웠던 기억이 있다. 이 엄청나게 비효율적인 소프트웨어가 같은 일을 거듭하면서 사이클을 잡아먹고 있다는 생각이 나한테는 무척 혐오스럽다. 하지만 이부분에서 나의 직감이 잘못되었다고 생각한다. 가난하게 자라서 예를 들면 의사를 찾아가는 것처럼 중요한 일에도 돈 쓰는 것을 못 견디는 사람처럼.

어떤 종류의 낭비는 진짜 혐오스럽다. 예를 들면 SUV는 오염을 발생시키지 않고 고갈되지도 않는 연료로 간다고 하더라도 추잡스럽다고 할 수 있다. SUV가 추잡스러운 이유는 추잡스러운 문제에 대한 해결책이기 때문이다. (미니밴을 어떻게 하면 근육질로 보이게 할 수 있는가.) 하지만 모든 낭비가 나쁜 것은 아니다. 기반 시설이 이미 충분한데 장거리 전화 통화 시간을 재는 것은 옹졸해 보인다. 자원이 있다면 상대편이 어디에 있건 상관 없이 모든 전화 통화가 한 종류라고 생각하는 것이 더 고상해 보인다.

좋은 낭비도 있고 나쁜 낭비도 있다. 나는 좋은 낭비 쪽에 관심이 있다 — 더 많이 소비해서 우리가 더 단순한 설계를 할 수 있는 종류의. 새로 나올 더 빠른 하드웨어에서 우리가 얻을 사이클들을 낭비할 기회를 어떻게 활용할 것인가?

속도에 대한 갈망은 보잘것없는 컴퓨터를 쓰고 있는 우리 내부에 너무나 깊게 새겨져 있어서, 그것을 극복하는데는 의식적 노력이 필요하다. 언어 설계에 있어서, 편의성을 아주 조금이라도 증진시키는 대가로 효율성을 포기할 수있는 상황이 있는지 의식적으로 찾아봐야 한다.

대부분의 자료 구조는 속도 때문에 존재한다. 예를 들면 많은 오늘날의 언어들이 문자열과 리스트를 둘 다 갖고 있다. 의미적으로는 문자열은 구성 원소가 문자인 리스트의 하위 집합이라고 볼 수 있다. 그렇다면 왜 다른 데이터 타입이 필요한가? 실제로는 필요하지 않다. 문자열은 단지 효율성을 위해 존재한다. 프로그램이 더 빠르게 동작하기 위해서 언어의 의미를 흐트려뜨려야 하는 것은 불완전하다. 언어에 문자열이 있는 것은 성급한 최적화의 경우로 보인다.

만약 언어의 핵심을 공리의 집합이라고 생각한다면, 표현 능력을 늘리지 못하는데 단지 효율을 위해서 공리들을 추가하는 것은 좋지 않아 보인다. 효율은 중요하지만 이런 방식으로 효율성을 얻는 것은 옳은 방법이 아니라고 생각한다.

내가 생각하는 이 문제를 푸는 바른 방법은 구체적 구현 방법과 프로그램의 의미를 구분하는 것이다. 리스트와 문자열 둘 다 있기 보다는 리스트만 있으면서 필요하다면 컴파일러가 문자열을 연속적으로 배치된 바이트로 최적화할 수 있도록 충고할 수 있으면 된다.

프로그램의 대부분에서 속도는 문제가 되지 않기 때문에 보통은 이런 세밀한 조작에 신경쓰지 않을 것이다. 컴퓨터가 빨라질수록 더욱 그럴 것이다.

구현 방법에 대해 적게 말할수록 프로그램이 더 유용해진다. 프로그램이 씌여지는 동안 스펙이 변하는 것은 피할 수 없을 뿐만 아니라 바람직하다.

“essay”란 단어는 프랑스어 동사인 “essayer”에서 왔는데 “시도하다”라는 뜻이다. 그런 의미에서 에세이란 뭔가를 알아내기 위해서 당신이 쓰는 뭔가이다. 이것은 소프트웨어도 마찬가지이다. 시작할 때 작가가 무엇을 쓰려고 시도하는지 모르고 있었다는 의미에서 나는 최고의 프로그램들 중 일부는 에세이라고 생각한다.

리스프 해커들은 자료 구조의 유연성이 갖는 가치를 이미 안다. 우리는 첫 버젼을 작성할 때 모든 것을 리스트로 해결하는 경향이 있다. 이 초기 버젼들은 놀랄만큼 비효율적이어서 그것이 무엇을 하는지에 대해 생각하지 않는 의식적 노력이 필요하다. 마치 내가 스테이크를 먹으면서 그것이 어디서부터 왔는지 생각하지 않는 의식적 노력이 필요한 것처럼.

백년 후의 프로그래머들은 대부분 가능한 가장 적은 노력으로 믿을 수 없을 만큼 비효율적인 버전 1을 짜맞추는 언어를 찾을 것이다. 적어도 오늘날의 용어로 설명하자면 그렇다. 그들 입장에선 프로그램하기 쉬운 언어를 원한다이겠지만.

비효율적인 소프트웨어가 역겹지 않다. 역겨운 것은 프로그래머들이 쓸데 없는 일을 하게끔 만드는 언어이다. 기계의 시간이 아니라 프로그래머의 시간을 낭비하는 것이 진짜 비효율이다. 컴퓨터가 빨라질수록 이것은 더욱 명백해질 것이다.

문자열을 없앤다는 생각은 우리가 받아드릴 수 있다고 생각한다. Arc에서 그랬는데 성공적인 것 같다. 정규식(regular expression)으로 설명하기 어려웠던 어떤 조작들은 재귀 함수(recursive function)로 쉽게 설명된다.

자료 구조를 단순하게 하는 것의 한계는 어디일까? 충분히 열린 마음을 가진 나 스스로도 놀랄만한 가능성을 생각할 수 있다. 예를 들면 우리는 배열(array)를 없애게 될까? 배열은 단순히 정수의 벡터가 키인 해쉬 테이블의 하위 집합일 뿐이다. 우리는 해쉬 테이블 자체도 리스트로 바꿔치게 될까?

그보다 더 충격적인 가능성도 있다. 1960녀에 맥카씨(McCarthy)가 기술한 리스프에는 숫자가 없었다. 논리적으로는 숫자를 표현하는데 별도의 방법이 있을 필요는 없다. 왜냐하면 리스트로 숫자를 표현할 수 있기 때문이다. 정수 n은 n개의 원소를 갖고 있는 리스트로 표현할 수 있다. 수학을 이런 식으로 할 수 있다. 단지 못 견딜만큼 비효율적이다.

실무에서 숫자를 리스트로 구현하자고 제안한 사람은 없었다. 사실 맥카씨의 1960년 논문은 그 당시에는 구현할 의도가 전혀 없었다. 그것은 이론적 과제였고 튜링 머신보다 좀 더 우아한 대안을 만들려는 시도였다. 누군가가 예기치 않게 이 논문을 가져다 작동하는 리스프 해석기로 만들었을 때 숫자가 리스트로 표현되지는 않았다. 다른 언어에서처럼 이진수로 표현되었다.

프로그래밍 언어가 숫자처럼 기초적인 데이타 타입을 없앨만큼 나갈 수 있을까? 미래와 담력을 겨룰만큼 진지하게 묻는 것은 아니다. 움직일 수 없는 물체를 미는 저항할 수 없는 힘의 경우와 같은 가정이다. 말하자면 상상을 초월하는 비효율적인 구현과 상상을 초월하는 엄청난 자원이 만난 것이다. 그렇지 못할 이유도 없다. 미래는 아직 멀다. 언어 핵심에서 공리의 개수를 줄일 수 있는 어떤 것이 있다면 t가 무한대에 접근하는 동안 거기에 걸어야 할 것 같다. 만약 백년 후에 그 아이디어가 아직 받아들일 만한 것이 안된다면 천년이 지나도 그럴 것이다.

이 문제에 대해서 명확히 하자면, 모든 숫자 계산은 리스트를 이용해서 수행되어야 한다고 제안하는 것은 아니다. 나는 언어 핵심은 구현에 관한 어떤 표기 방법이 추가되기전에 이런 식으로 정의되어야 한다고 제안하는 것이다. 실제에서는 수학을 조금이라도 할려는 프로그램은 숫자를 이진수로 표현할 것이지만 이것은 최적화이지 언어 핵심의 의미를 이루진 않는다.

사이클을 소모하는 다른 방법은 하드웨어와 응용프로그램 간에 많은 계층을 두는 것이다. 이것 또한 이미 일어나고 있는 경향이다. 근래의 많은 언어들이 바이트 코드로 컴파일된다. 계층을 하나 추가할 때마다 어림잡아 속도는 10배 느려진다고 빌 우즈(Bill Woods)가 말한 적있다. 이 추가 비용 덕분에 유연성이 생긴다.

Arc의 최초 버전은 이런 종류의 다 계층 때문에 생긴 느림과 거기에 상응하는 이점의 극단적 경우였다. 그것은 Common Lisp 위에 쓰여진 전통적인 “metacircular” 해석기였는데 맥카씨의 원래 Lisp 논문에 정의된 eval 함수에 무척 가까웠다. 전체 코드는 수백줄이어서 이해하고 바꾸기 쉬웠다. 우리가 사용한 Common Lisp인 CLisp 자신도 바이트 코드 해석기 위에서 실해되었다. 그래서 두 단계의 해석이 있었던 것이고 그 중 하나는(위에 것) 매우 비효율적이었지만 언어는 사용가능했다. 인정하건대 간신히 사용가능했지만 사용가능했다.

응용프로그램안에서도 여러단계의 계층으로 소프트웨어를 작성하는 것은 강력한 기술이다. 아래서부터 위로 프로그래밍이란 프로그램을 각 단계가 그 위의 단계에 대해서 언어로써 작동하는 단계들의 나열로 프로그램을 작성하는 것이다. 이런 접근 방식으로 더 작고, 더 유연한 프로그램을 만들어지게 된다. 이는 또한 재사용성이라는 성스러운 목표로 가는 최선의 길이다. 언어란 그 정의 자체로 재사용가능하다. 당신의 응용프로그램을 그런 형식의 응용프로그램을 작성하는데 적합한 언어로 밀어 내릴 수록 당신의 소프트웨어는 더 많이 재사용가능해질 것이다.

어찌된건지 1980년대에 재사용가능성이라는 아이디어는 객체 지향 프로그래밍과 연관되어 아무리 많은 반대되는 증거도 그것을 떼어낼 수 없어 보인다. 비록 일부의 객체 지향 소프트웨어가 재사용가능한 것은, 그것이 아래에서부터 위로 형식으로 쓰여졌기 때문이지 객체 지향적이기 때문이 아니다. 라이브러리를 생각해 보자: 그것이 객체지향적으로 쓰여졌는지 아닌지는 상관없이 그것이 언어이기 때문에 재사용가능한것이다.

그렇다고 객체지향 프로그래밍이 없어질 것이라고 예상하는 것은 아니다. 어떤 특별한 분야를 제외하곤 좋은 프로그래머에게 별로 소용이 없겠지만, 큰 조직에선 안 쓸 수 없다. 객체지향 프로그래밍은 스파게티 코드를 작성하는 것을 지속가능하게 해준다. 그것은 짜집기의 연속으로 프로그램을 만들게 한다. 큰 조직은 늘 이런 방식으로 소프트웨어를 개발하는 경향이 있고, 오늘날 그런 것처럼 백년 후에도 그럴 것이라 예상한다.

미래에 대해 말하자면, 병렬 계산에 대해 말하는게 좋을 것이다. 왜냐하면 병렬 계산이란 아이디어가 살아 숨쉬는 곳이 미래이기 때문이다. 즉, 언제 말하는지 상관 없이 미래에는 병렬 계산이 일어날 것으로 보인다.

미래에는 그것을 따라잡을까? 적어도 20년간 병렬 계산이 곧 닥쳐올 것이라고 이야기해 왔지만, 프로그래밍 습관에 큰 영향을 미치진 않았다. 아니면 영향을 미쳤을까? 칩 설계자들은 그것에 대해 이미 생각해야만 했고, 다중 cpu 컴퓨터에서 작동하는 시스템 소프트웨어를 작성하려는 사람들도 그렇다.

진정한 질문은 병렬성을 어느 정도나 추상화할 것인가이다. 백년 후에는 응용프로그램 프로그래머에게도 영향을 미칠까? 아니면 컴파일러 작성자가 생각해야할 문제로 응용프로그램의 소스코드에선 보이지 않을까?

병렬성의 기회가 대부분 낭비될 것 같아 보인다. 우리에게 주어진 여분의 컴퓨터 능력이 대부분 낭비될 것이라는 나의 일반적인 예측의 특수한 경우이다. 거대한 속도의 하드웨어가 받쳐주는 한 병렬성은 명시적으로 요구하면 사용가능하지만 보통의 경우에는 사용되지 않을 것으로 예상한다. 이것은 특별한 응용프로그램을 제외하곤 백년 후에 우리가 가질 병렬성의 종류는 대규모 병렬성이 아닐 것을 의미한다. 나는 평범한 프로그래머들에게 있어서는 같은 프로세스를 여러개 실행시키는 쪽이 될 것이라고 예상한다.

그리고 이것은 최적화를 하려고 노력할 때 자료구조의 구체적 구현을 요구하는 것과 같이 프로그램 작성 단계에서 상당히 늦은 시점에 할 것이다. 버젼 1은 자료의 특정한 표현에서 얻는 장점을 무시하듯이 병렬 계산에서 얻는 장점들을 무시할 것이다.

특별한 종류의 응용프로그램들을 제외하고, 병렬성은 백년 후에 작성될 프로그램들에서 널리 퍼지지는 않을 것이다. 만약 그렇다면 성급한 최적화가 될 것이다.

백년 후에는 프로그래밍 언어가 몇개나 있을까? 근래에 엄청나게 많은 수의 새 프로그래밍 언어가 생긴 것 같다. 이유중의 일부는 더 빠른 하드웨어가 응용프로그램에 따라서 프로그래머들에게 속도와 편의성 중에서 다른 선택을 할 수 있게 해준 것이다. 이런 경향이 맞다면, 백년 후에 하드웨어는 이런 경향을 더욱 증가시킬 것이다.

그래도 백년 후에 폭 넓게 사용될 언어는 몇개에 지나지 않을것이다. 이런 말을 하는 이유 중의 일부는 낙관주의이다: 만약 정말 잘 만든다면 느린 버전 1을 작성하는데 이상적이면서도 필요하다면 컴파일러에게 최적화 충고를 해줘서 매우 빠른 코드를 생산해 낼 수 있는 언어를 만들 수 있어 보인다. 나는 낙관적이어서 받아들일 만한 효율성과 최고 효율성 사이의 거대한 차이가 있음에도 불구하고 백년 후의 프로그래머들이 그것의 대부분을 포용할 언어를 가질 것이라고 예측하려 한다.

이 간극이 넓어질 수록, 프로파일러가 점점더 중요해질 것이다. 현재에는 프로파일링에 별 주의를 기울이지 않고 있다. 많은 사람들이 아직도 빠른 응용프로그램을 얻는 방법은 빠른 코드를 생산하는 컴파일러를 작성하는 것이라도 믿는 것 같다. 받아들일 만한 성능과 최고의 성능간의 간격이 넓어질 수록 빠른 응용프로그램을 얻는 방법은 전자에서 후자로 가는 좋은 가이드를 갖는 것이라는 것이 점점 더 명백해 질것이다.

내가 몇개의 언어만이 있을 것이라고 말할 때에는, 어떤 분야에 특정한 “작은 언어”들까지 포함하는 것은 아니다. 나는 그런 내장된 언어들이 매우 좋은 생각이라고 생각하며 급격히 증가할 것이라고 예상한다. 하지만 나는 그것들이 충분히 얇은 껍질로 작성되어 사용자들이 그 밑에 있는 범용 언어를 볼 수 있을 것이라고 기대한다.

누가 미래의 언어를 설계하게 될까? 지난 십년간 가장 흥분된 경향중의 하나는 Perl, Python, Ruby 같은 오픈 소스 언어의 출현이었다. 해커들이 언어 설계를 넘겨받고 있다. 지금까지의 결과는 엉망이지만, 의욕적이다. 예를 들면 Perl에는 멋지게 기발한 아이디어들이 몇몇 있다. 많은 수가 놀랍도록 나쁘지만 야심적인 노력이란 늘 그런법이다. 현재의 변형 속도라면 백년 후에 Perl이 어떻게 발전할지는 신만이 알 것이다.

뭔가를 직접 할 수 없는 사람이 가르치는 일을 한다라는 것은 사실이 아니지만 (내가 아는 최고의 해커들 중 몇명은 교수이다), 가르치는 일을 하는 사람들이 할 수 없는 일이 많다는 것은 사실이다. 연구활동은 억압하는 계급 제도적 제한을 강요한다. 어느 학문 분야라도 연구를 해도 괜찮은 주제와 그렇지 않은 주제가 있다. 불행하게도 받아들여지는 주제와 금지되는 주제의 구분은 흔히, 그 일이 좋은 결과를 얻는데 얼마나 중요한지 보다는 연구 논문으로 썼을 때 얼마나 지적으로 보이는지에 근거한다. 아마도 극단적인 경우는 문학일 것이다; 문학을 연구하는 사람들은 그것을 생산하는 사람들에게 조금이라도 도움이 되는 것을 이야기하는 것이 드물다.

과학의 경우에는 상황이 낫지만, 허용되는 일들과 좋은 언어를 만들어내는 일들 사이의 겹침은 애처롭게도 작다. (Olin Shivers가 이것에 대해 감명적으로 불평했다.) 예를 들면, 정적 타입이 진정한 매크로 — 그것이 없으면, 내 의견으로는, 어떤 언어도 사용할 가치가 없다 — 를 배제한다는 사실에도 불구하고 타입은 수많은 연구 논문의 마르지 않는 원천으로 보인다.

경향은 단지 언어들이 “연구”보다는 오픈 소스 과제로 개발되는 것뿐만 아니라 컴파일러 작성자에 의해 작성되기 보다는 그것을 사용할 필요가 있는 응용프로그램 프로그래머들에 의해서 설계되는 쪽으로 나가고 있다. 이것은 좋은 경향으로 보이고 나는 이것이 계속되리라 예상한다.

예측하기가 거의 부득이하게 불가능한 백년 후의 물리학과는 다르게, 나는 백년 후의 사용자들에게 끌릴 수 있는 언어를 지금 설계하는 것이 원칙적으로 가능하다고 생각한다.

언어를 설계하는 방법 중의 하나는 그것을 번역할 컴파일러나 그것을 실행할 하드웨어의 유무의 상관없이 당신이 작성하고 싶어하는 프로그램을 적어내려 가는 것이다. 이렇게 할 때 무한정의 자원을 가정하고 할 수 있다. 백년 후처럼 오늘날에도 무한정의 자원을 상상할 수 있을 것 같아보인다.

어떤 프로그램을 작성하고 싶을까? 어떤 것이던지 가장 노력이 작게 드는 것이다.