내 가설은 간결함이 힘과 같거나, 문제 있는 특이한(pathological) 사례들을 제외한다면 동일하다고 취급해도 될 만큼 밀접하다는 것이다.

내게는 간결함이 프로그래밍 언어의 목표로 보인다. 컴퓨터라면 할 일을 기계어로 직접 지시받을 때 가장 행복할 것이다. 고급 언어를 개발하기 위해 애쓰는 주된 이유는, 지레를 쓰는 것처럼 기계어 천 줄이 필요한 것을 고급 언어 열 줄로 말할 수 (더 중요하게는 생각할 수) 있게 하기 위한 것이라고 생각한다. 다시 말하면, 고급 언어의 주된 목적은 소스 코드를 더 작게 만드는 것이다.

더 작은 소스 코드가 고급 언어의 목적이고, 어떤 것의 힘이 그 목적을 얼마나 잘 달성하는가에 있다면, 프로그래밍 언어의 힘은 그것으로 프로그램을 얼마나 작게 만들 수 있는가 하는 것으로 측정할 수 있다.

역으로, 프로그램을 작게 만들지 못하는 언어는 프로그래밍 언어가 당연히 할 일을 제대로 못하고 있는 것이다. 잘 안 드는 칼이나 읽기 힘든 인쇄물과 마찬가지인 것이다.

그럼 어떤 의미에서 작다는 말인가? 코드의 크기는 그 줄 수로 재는 것이 가장 일반적이다. 그런데 이 척도가 가장 일반적으로 쓰이는 것은 그렇게 재는 것이 가장 쉽기 때문일 것이다. 실제로 이렇게 해서 프로그램의 길이를 정확하게 검사할 수 있다고 믿는 사람은 아무도 없을 것 같다. 언어들마다 한 줄에 얼마나 많은 내용이 들어가는가에 대한 관습이 다르다. C에서는 한 줄에 구분자(delimiter) 한두 개만 달랑 있는 경우가 많다.

그 다음으로 쉬운 검사 방법은 프로그램에 들어 있는 문자의 개수를 세는 것이지만, 이것도 그렇게 좋은 방법은 아니다. 어떤 (예를 들어 펄과 같은) 언어는 다른 것들보다 식별자(identifier)들의 길이가 더 짧다.

프로그램의 크기를 재는 더 좋은 방법은, 요소(element)들의 개수를 세는 것이라고 생각한다. 여기에서 요소란 소스 코드를 나타내는 트리(tree)를 그릴 때 독립된 노드(node)가 될 수 있는 것을 말한다. 변수나 함수의 이름은 요소이다. 정수나 실수도 요소이다. 문장(literal text)의 각 부분도 요소이다. 형태(pattern)적 요소, 즉 형식 지시자(format directive)도 요소이다. 새로운 구역(block)도 요소이다. 경계에 있는 예도 있지만 (-5는 요소가 둘인가 하나인가?) 그런 것들 대부분은 모든 언어에서 공통되기 때문에 비교에 크게 영향을 끼치지 않을 것이라고 생각한다.

이 척도는 좀 더 구체화할 필요가 있으며 특정한 언어의 경우에는 해석이 필요할 수도 있지만, 이것은 프로그램을 이루는 모든 부분의 개수라는 올바른 것을 세려는 좋은 시도라고 생각한다. 이것을 실행하는 과정에서 그리게 되는 트리는, 프로그램을 이해하기 위해 머리 속에 그려 놓고 있어야 하는 것이다. 따라서 그 트리의 크기는 프로그램을 작성하거나 읽기 위해 해야 하는 일의 양과 비례를 이룬다고 생각한다.

이런 종류의 척도로 서로 다른 언어들을 비교할 수 있겠지만, 적어도 나에게는 이것이 그것의 주된 가치가 아니다. 간결성 검사의 주된 가치는 언어 설계의 지침이 된다는 데에 있다. 언어의 비교가 가장 유용한 때는, 같은 언어를 다양하게 변형(variant)해 본 것들을 서로 비교하는 것이다. "프로그램을 더 짧게 만들기 위해 나는 이 언어에 대해 무엇을 할 수 있는가?"

어떤 프로그램의 개념적 부하(conceptual load)가 그 복잡도와 비례를 이루고, 지금의 프로그래머는 정해진 개념적 부하만 견딜 수 있다면, 이것은 이렇게 묻는 것과 같다. "프로그래머들이 최대의 효과를 얻게 하기 위해 나는 무엇을 할 수 있는가?" 그리고 이것은 이렇게 묻는 것과 동일하게 보인다. "나는 좋은 언어를 어떻게 설계할 수 있는가?"

(덧붙이자면, 언어를 설계할 때만큼 "모든 언어는 동등하다"는 케케묵은 이야기가 거짓이라는 것이 더욱 분명하고 확실해지는 때는 없다. 새로운 언어를 설계할 때는 어느 것이 더 좋은지 판단하기 위해 두 언어, 즉 x라는 것을 구현했을 때의 언어와 그렇지 않을 때의 언어를 끊임없이 비교한다. 이것이 실제로 무의미한 질문이라면, 동전 던지기로 결정해도 될 것이다.)

간결함을 목표로 삼는 것은 새로운 착상을 얻는 좋은 방법인 것 같다. 어떤 일을 했을 때 서로 다른 여러 프로그램들의 길이가 짧아질 수 있다면, 그것은 우연의 일치가 아닐 것이다. 아마도 유용한 새로운 추상화 방법(abstraction)을 발견한 것일 수 있다. 소스 코드에서 반복되는 형태(pattern)들을 찾아냄으로써 도움을 주는 프로그램을 만들 수도 있을 것이다. 여러 언어들 가운데 간결함으로 명성이 있는 것들은 새로운 착상을 얻기 위해 봐 두는 것이 좋을 것이다. 포스(Forth), 조이(Joy), 아이콘(Icon) 등이 그것이다.

내가 알기로 이 문제에 대해 처음으로 글을 쓴 사람은 "맨먼스의 신화(the Mythical Man Month)"의 프레드 브룩스(Fred Brooks)이다. 그는 프로그래머들이 하루에 생성하는 코드의 양은 언어에 상관없이 거의 똑같은 것으로 보인다고 썼다. 내가 이 글을 20대 초반에 처음 읽었을 때 그것은 너무나 놀라웠고 엄청난 내용을 함축하고 있다고 느꼈다. 이 글은 (a) 소프트웨어를 더 빨리 만들기 위한 단 하나의 방법은 더욱 간결한 언어를 사용하는 것이며, (b) 애써서 이렇게 한 사람은 그렇게 하지 않은 경쟁자들을 압도할 수 있을 것이라는 뜻이 된다.

브룩스의 가설은, 그것이 진실이라면, 바로 해킹의 핵심으로 보인다. 그 이후로 나는 형식을 갖춘 연구에서 개인 프로젝트의 일화들까지 그 질문과 관련하여 얻을 수 있는 모든 증거들에 세심하게 주의를 기울여 왔다. 그리고 그의 말과 모순되는 증거는 전혀 찾을 수 없었다.

물론 결론을 내릴 만큼 확실한 증거는 아직 찾지 못했지만, 그런 것을 기대하지도 않는다. 루츠 프렉헬트(Lutz Prechelt)의 프로그래밍 언어 비교와 같은 연구들은, 내가 기대한 종류의 결과가 나오기는 했지만, 의미 있는 검사라고 하기에는 너무 짧은 문제들을 사용하는 경향이 있다. 더 좋은 방법은, 만드는 데 한 달은 걸리는 프로그램들에서 그 언어가 어떠한가를 검사하는 것이다. 그리고 나처럼 언어의 주된 목적이 (무엇을 다 생각한 뒤에 컴퓨터에게 그것을 지시하는 것보다) 아예 그것을 통해 생각하기에 좋아야 하는 것이라고 믿는다면, 유일한 진짜 검사는 그 언어로 새로운 어떤 것들을 만들 수 있는가를 보는 것이다.

언어에 대한 진짜 검사는 새로운 문제를 얼마나 잘 발견하고 해결할 수 있는가를 보는 것이지, 다른 사람이 이미 공식을 만들어 놓은 문제를 해결하기 위해 그 언어를 얼마나 잘 사용할 수 있는가를 보는 것이 아니다. 이 둘은 기준이 매우 다르다. 미술에서 자수(embroidery)나 모자이크와 같은 매체는 무엇을 만들고 싶은지 사전에 알고 있다면 매우 효과적이지만, 그렇지 않다면 정말 지저분해질 뿐이다. 어떤 모습(image)을 그려 가면서 그 모습을 찾아내고 싶을 때는 (예를 들어, 사람의 모습처럼 복잡한 작업을 할 때) 연필이나 잉크 워시(ink wash)나 유화처럼 좀 더 유동적인 매체를 사용할 필요가 있다. 게다가 태피스트리(tapestry)나 모자이크가 실제로 만들어지는 방식에서도 먼저 그림을 그리고 다음에 그것을 복사한다. ("카툰(cartoon)"이라는 단어는 원래 이런 목적으로 그린 그림을 가리키기 위해 사용되었다.)

이것은 프로그래밍 언어들의 상대적인 힘을 정확하게 비교할 수 없을 것 같다는 말이다. 정밀하게(precise)는 비교하겠지만, 정확하게(accurate)는 아니다. 특히 언어의 비교가 목적이라고 명백히 밝힌 연구에서는 아마도 규모가 작은 문제들을 사용할 것이고 필연적으로 미리 정의된 문제들을 사용할 것이므로, 더욱 강력한 언어의 힘을 과소평가하기 쉬울 것이다.

해당 분야에서 나온 보고서들이, 비록 "과학적인" 연구들보다 덜 정밀할 수밖에 없겠지만, 의미는 더 클 것 같다. 예를 들어, 에릭슨(Ericsson)의 울프 비거(Ulf Wiger)는 한 연구에서 다음과 같이 얼랑(Erlang)이 C++보다 4~10배 간결하며, 그에 따라 소프트웨어 개발이 더 빠르다고 결론을 내렸다. 역자 주: 얼랑(Erlang)은 에릭슨(Ericsson)에서 개발한 함수형 언어(functional language)로서 분산 통신 시스템에 적합하다. 이 이름은 덴마크의 수학자 A. K. 얼랑(Erlang)에서 왔으며, 전화 통화량의 단위로 쓰이기도 한다.

에릭슨 내부의 개발 프로젝트들을 비교한 결과, 소프트웨어 개발의 모든 단계에서 어떤 언어(얼랑, 플렉스(PLEX), C, C++, 자바(Java) 등)를 사용했는가와 무관하게 시간당 줄 수의 생산성이 서로 비슷한 것으로 보인다. 서로 다른 언어를 구별 짓는 것은 결국 소소 코드의 분량이라는 말이 된다. 역자 주: 플렉스(Programming Language for EXchange)는 에릭슨에서 개발한 실시간 내장 시스템(realtime embedded system) 언어이다.

또한 이 연구는 브룩스의 책에서 은연중에 언급된 논점을 명백하게 다루고 있다. (브룩스는 디버그된 코드의 줄 수를 셌다.) 즉, 강력한 언어로 만든 프로그램들은 버그도 적다. 버그가 적다는 것은 네트워크 스위치(network switch) 같은 응용 분야에서는 그 자체가 목적이며, 프로그래머의 생산성보다 더 중요할 수도 있다.

궁극적으로는 자기 본능대로 행동해야 한다고 생각한다. 어떤 언어로 프로그래밍 한다는 것은 무슨 느낌인가? 최선의 언어를 찾는 (또는 설계하는) 방법은, 그 언어를 통해 내가 얼마나 잘 생각할 수 있는가에 대해 초고감도의(hypersensitive) 감각을 동원하여 그 중 최고의 것을 선택(설계)하는 것이다. 어떤 언어의 특징이 불편하거나 제한적인 것인지 아닌지는 걱정하지 않아도 바로 알 수 있을 것이다.

그런 초고감도의 감각을 얻기 위해서는 노력이 필요하다. 결국에는 서투른 언어로 프로그래밍 하는 것을 견딜 수 없을 것이다. 나는 매크로가 없는 언어로 프로그래밍 할 때 참을 수 없이 제한받는 것을 느낀다. 이것은 동적인 자료형 설정(dynamic typing)에 익숙해진 사람들이 어쩔 수 없이 변수들의 자료형을 일일이 선언해야 하는 언어로 프로그래밍 해야 할 때 제한받는 것을 느끼는 것과 마찬가지이다. 서로 다른 자료형의 객체들을 하나의 리스트로 만들 수 없을 때도 그런 느낌을 받는다.

나만 그런 것이 아니다. 나는 이런 경험을 한 리스프 해커들을 많이 알고 있다. 사실 프로그래밍 언어들의 상대적인 힘을 재는 가장 정확한 척도는, 그 언어를 사용한다면 응용 분야에 상관없이 어떤 일이라도 해 낼 수 있는 사람들의 비율일 것이다.

대부분의 해커들은 언어에서 제한받는 느낌이 든다는 것이 무슨 뜻이 알 것이다. 그런 느낌이 들면 어떻게 되는가? 이것은 가려고 한 길이 폐쇄되어서 가고 싶은 곳으로 가기 위해 멀리 우회해야 할 때 받는 느낌과 같을 것이라고 생각한다. 무엇인가를 말하고 싶은데 언어가 그것을 허락하지 않는 것이다.

내 생각에 여기에서 핵심은, 제한적인 언어는 충분히 간결하지 않은 것이라는 사실이다. 단순히 하고자 하는 것을 말할 수 없다는 것이 문제가 아니다. 그 언어 때문에 우회해야 하는 길이 길다는 것이 문제이다. 실험삼아 이렇게 생각해 보자. 만들고 싶은 어떤 프로그램이 있는데, 그 언어로는 내가 하고자 하는 방식으로 표현하지 못하고, 그 대신 더 짧은 어떤 다른 방식으로 그 프로그램을 만들 수밖에 없다고 가정하자. 최소한 나라면, 그것을 그렇게 제한받는다고 느끼지는 않을 것이다. 이것은 가려고 하는 길이 폐쇄되었지만, 경찰관이 교차로에서 우회로 대신 지름길을 알려 주는 것과 같다. 훌륭하다!

나는 제한성의 느낌 대부분이 (90퍼센트쯤?) 그 언어로 프로그램을 만들 때 머리 속에 있는 것보다 더 길어질 수밖에 없다는 사실에서 온다고 생각한다. 제한성은 대부분 간결함이 결여된 것이다. 어떤 언어가 제한적으로 느껴진다면 그것은 (대부분) 그 언어가 충분히 간결하지 않다는 의미이며, 언어가 간결하지 않을 때 그것이 제한적으로 느껴질 것이다.

처음에 인용한 글은 두 가지 다른 성질, 규칙성(regularity)과 가독성(readability)에 대해 언급하고 있다. 나는 규칙성이 무엇인지, 혹은 규칙성과 가독성 있는 코드가 가독성만 있는 코드보다 무슨 장점이 있는 것인지 잘 모르겠다. 하지만 가독성이 무엇을 뜻하는지는 알고 있으며, 이것 또한 간결함과 관련되어 있다고 생각한다.

이 때 코드의 개별 줄들의 가독성과 프로그램 전체의 가독성은 주의해서 구분해야 한다. 여기서 중요한 것은 두 번째 것이다. 베이직(Basic)의 한 줄은 리스프의 한 줄보다 더 읽기 쉽다는 데에는 동의한다. 하지만 베이직으로 만든 프로그램은 (특히 일단 그린스펀 세계(Greenspunland)로 넘어 들어갔다면) 리스프로 만든 같은 프로그램보다 줄 수가 더 많을 것이다. 그리고 베이직 프로그램을 읽을 때 드는 총 노력은 분명히 더 클 것이다. 역자 주: C나 포트란(Fortran)으로 만든 복잡한 프로그램에서 지저분한 절반 부분은 커먼 리스프(Common Lisp)로 구현되었다는 '그린스펀(Greenspun)의 프로그래밍의 열 번째 법칙'이 있다. 그린스펀 세계의 베이직 프로그램도 절반은 리스프로 구현되었을 테니 리스프로 만든 프로그램보다 당연히 더 길 것이다.

(FIXME: 여기서도 역자주의 그린스펀 이야기가 조금 이상합니다. 베이직 언어로 복잡한 프로그램을 작성했다면, 거의 틀림없이 커먼리습의 절반을 엉터리로 구현했을 거라는 의미죠.)

총 노력 = 줄당 노력 x 줄 수

가독성도 힘처럼 간결함과 직접 비례를 이루는지는 분명하지 않지만, 간결함은 (위의 식에 보이는 수학적인 의미에서) 가독성의 한 요소이다. 그래서 언어의 목표가 간결함이 아니라 가독성이라고 하는 것은 별로 의미가 없는 말일 수 있다. 이 말은 그 목표가 가독성이 아니라 가독성이라고 (동어 반복) 하는 것과 같을 수 있다.

'한 줄의 가독성(readability-per-line)'이란, 그 언어를 처음 접한 사용자들에게 소스 코드가 두렵지 않게 보인다는 바로 그 뜻이다. 그래서 '한 줄의 가독성'은, 비록 설계 측면에서는 안 좋은 결정이라도, 마케팅 측면에서는 좋은 결정일 수 있다. 이것은 사람들이 할부로 비용을 지불하게 하는 매우 성공적인 수완과 형태가 똑같다. 즉, 높은 선불 가격으로 사람들을 놀라게 하는 대신, 낮은 월 할부금을 말해 주는 것이다. 하지만 할부 계획은 구매자 입장에서는 결국 손해이다. 단순한 '한 줄의 가독성'이 프로그래머에게 그러한 것과 마찬가지이다. 구매자는 그 낮고 낮은 비용을 여러 번 지불해야 할 것이고, 프로그래머는 개별적으로 읽기 쉬운 줄들을 여러 줄 읽어야 할 것이다.

이런 식으로 균형을 맞추는 것(tradeoff)은 프로그래밍 언어를 과거로 돌려놓는 것이다. 소설이나 신문 기사를 읽는 것에 익숙하다면, 수학 논문을 처음 읽어 보는 것은 당황스러울 수 있다. 한 페이지를 읽는 데 반 시간이 걸릴 수도 있다. 그 기호가 문제인 것처럼 느껴질 수 있지만, 사실은 그렇지 않은 것이 분명하다. 수학 논문이 읽기 어려운 것은 거기에 담긴 생각이 어렵기 때문이다. 그것과 같은 생각을 (수학자들이 간결한 기호를 발전시키기 전에 그래야 했듯이) 산문(prose)으로 표현한다고 해서 읽기가 더 쉬워지지는 않을 것이다. 그 논문은 책만큼 두꺼워질 것이기 때문이다.

많은 사람들이 '간결함 = 힘'이라는 생각을 무시해 왔다. 나는 단순히 이 둘이 같은지 아닌지 논쟁하는 것보다는, 어느 범위까지 '간결함 = 힘'인지 묻는 것이 더 유용할 것이라고 생각한다. 분명히 간결함은 고급 언어들이 지향하는 바의 많은 부분을 차지하기 때문이다. 간결함이 언어들이 지향하는 전부가 아니라면, 그 나머지는 무엇이며, 그런 다른 기능들은 상대적으로 얼마나 중요한가?

이것을 제안하는 것은 단지 논쟁을 더 교양 있게 하려는 것이 아니다. 나는 정말로 그 답을 알고 싶다. 어떤 언어가 그 자체에 득이 되는 것도 없이 지나치게 간결해 본 적이 정말 있었는가?

처음에 세운 가설에서 나는 특이한(pathological) 사례들을 제외한다면 간결함이 힘과 동일한 것으로 간주해도 될 것이라고 생각했다. 이 말은, 어느 누가 설계할 어떠한 언어에서도 이 둘은 동일할 것이지만, 누군가가 이 가설을 명백히 반증하기 위해 어떤 언어를 설계하고 싶다면 아마 그렇게 할 수도 있을 것이라는 뜻이었다. 하지만 그럴 수 있다고는 사실 믿지 않는다.

우리는 개별 프로그램이 아니라 언어의 간결함에 대해 이야기하고 있다는 것을 분명히 할 필요가 있다. 개별 프로그램들을 단단히 압축해서 만드는 것은 틀림없이 가능하다.

나는 이 점에 대해 "On Lisp"에 쓴 바 있다. 복잡한 매크로(macro)는 그 자체의 길이도 줄의 폭에 맞춰 여러 번 줄여 줘야 할 것이다. 지금 만든 어떤 텁수룩한 매크로를 사용할 때마다 코드 열 줄을 줄일 수 있는데, 그 매크로 자체가 코드 열 줄을 차지한다면, 그 매크로를 두 번 이상 사용해야 총합적으로 줄 수를 아끼는 것이 될 것이다. 하지만 비록 그렇다 해도 이것은 좋은 수가 아니다. 매크로 정의는 일반 코드보다 더 읽기 어렵기 때문이다. 가독성에서 총합의 향상을 얻기 전에 이미 그 매크로를 열 번에서 스무 번은 써야 할 것이다.

모든 언어들에는 이런 식으로 균형을 맞추는 방법이 있을 것이라고 확신한다. (언어가 강력할수록 따낼 수 있는 것도 더 많아지지 않겠는가 하는 의심이 들기도 한다.) 프로그래머라면 어떤 똑똑한 사람이 수상쩍은 프로그래밍 기법을 써서 극도로 짧게 만들어 놓은 코드를 본 적이 있을 것이다.

이제 이 점에 대해서는 더 이상 논쟁이 없을 것이다. 최소한 내가 더 할 말은 없다. 개별 프로그램들은 그 자체에 득이 되는 것도 없이 지나치게 간결해질 수도 있다. 여기서 질문은, 언어도 그럴 수 있는가이다. 언어가 프로그래머들을 강제하여, 전체적인 가독성을 희생하면서까지 (요소(element)들이) 짧은 코드를 만들게 할 수 있는가?

어떤 언어가 지나치게 간결해지는 것을 상상하기 어려운 한 가지 이유는, 어떤 것을 표현하는 과도하게 축약된 방식이 있다면, 더 길게 표현하는 방식도 있을 것이기 때문이다. 예를 들어, 리스프 프로그램이 매크로나 고차 함수(higher-order function)를 많이 사용하여 너무 압축된 것처럼 보인다면, 원하는 바에 따라 파스칼과 형태가 똑같게 코드를 작성할 수도 있을 것이다. 아크(Arc)에서 팩토리얼(factorial)을 다음과 같은 고차 함수 호출로 표현하고 싶지 않다면,

(rec zero 1 * 1-)

다음과 같이 재귀적인 정의로 작성할 수도 있다.

(rfn fact (x) (if (zero x) 1 (* x (fact (1- x)))))

역자 주: 고차 함수(higher-order function)는 함수를 인자로 받거나 결과로 반환하는 함수이다. 아크(Arc)는 폴 그레이엄이 리스프를 기초로 새롭게 설계해 가고 있는 프로그래밍 언어이다.

지금은 아무 예도 머리에 떠오르지 않지만, 어떤 언어가 지나치게 간결해질 수 있는가의 문제는 항상 관심이 있다. 난해하고 불가해한 방식으로 코드를 작성하도록 강요하는 언어가 있는가? 그런 예가 있다면, 정말 간절히 그것을 보고 싶다.

(참고: 내가 찾고 있는 것은 앞에서 묘사한 "요소"들이라는 척도에 따라 매우 압축된 프로그램이지, 단순히 구분자를 생략할 수 있거나 모든 이름이 한 글자로 되어 있어서 짧은 프로그램이 아니다.)