인기 있다는 것

2001년 5월

(이 글은 새로운 언어를 위한 일종의 사업 계획으로 작성되었습니다. 따라서 좋은 프로그래밍 언어의 가장 중요한 특징인 매우 강력한 추상화가 (당연하게 여겨지기 때문에) 빠져 있습니다.)

제 친구 중 한 명이 저명한 운영체제 전문가에게 정말 좋은 프로그래밍 언어를 설계하고 싶다고 말한 적이 있습니다. 그 전문가는 프로그래밍 언어는 장점에 따라 인기가 있거나 없게 되는 것이 아니므로, 아무리 좋은 언어를 만들어도 아무도 사용하지 않을 것이라며 시간 낭비일 것이라고 말했습니다. 적어도, 그것은 그가 설계했던 언어에 일어났던 일이었습니다.

무엇이 언어를 인기 있게 만들까요? 인기 있는 언어는 그 인기를 누릴 자격이 있을까요? 좋은 프로그래밍 언어를 정의하려고 노력할 가치가 있을까요? 어떻게 해야 할까요?

저는 이 질문들에 대한 답이 해커들을 살펴보고 그들이 무엇을 원하는지 배우는 데서 찾을 수 있다고 생각합니다. 프로그래밍 언어는 해커들을 위한 것이며, 해커들이 좋아할 때에만 (예를 들어, 지시적 의미론이나 컴파일러 설계 연습이 아니라) 프로그래밍 언어로서 좋은 언어입니다.

1 인기 형성의 메커니즘

확실히, 대부분의 사람들은 단순히 장점만으로 프로그래밍 언어를 선택하지 않습니다. 대부분의 프로그래머는 다른 사람에 의해 어떤 언어를 사용할지 지시받습니다. 하지만 저는 프로그래밍 언어의 인기에 미치는 이러한 외부 요인의 영향이 때때로 생각되는 것만큼 크지 않다고 생각합니다. 더 큰 문제는 좋은 프로그래밍 언어에 대한 해커의 생각이 대부분의 언어 설계자의 생각과 다르다는 점이라고 생각합니다.

둘 중에서는 해커의 의견이 중요합니다. 프로그래밍 언어는 정리가 아닙니다. 그것은 사람을 위해 설계된 도구이며, 신발이 사람의 발에 맞게 설계되어야 하는 것처럼 인간의 강점과 약점에 맞게 설계되어야 합니다. 신발을 신었을 때 발을 조인다면, 아무리 우아한 조각품일지라도 그것은 나쁜 신발입니다.

대다수의 프로그래머가 좋은 언어와 나쁜 언어를 구별하지 못할 수도 있습니다. 하지만 다른 어떤 도구와도 다르지 않습니다. 그렇다고 해서 좋은 언어를 설계하려는 노력이 시간 낭비라는 의미는 아닙니다. 전문 해커들은 좋은 언어를 보면 알아보고 사용할 것입니다. 전문 해커들은 인정하건대 소수에 불과하지만, 그 소수가 모든 좋은 소프트웨어를 작성하며, 그들의 영향력은 나머지 프로그래머들이 그들이 사용하는 언어를 따르는 경향을 보이게 합니다. 실제로 종종 그것은 단순히 영향력이 아니라 명령이기도 합니다. 종종 전문 해커들은 상사나 교수 자문으로서 다른 프로그래머들에게 어떤 언어를 사용할지 지시하는 바로 그 사람들입니다.

전문 해커들의 의견이 프로그래밍 언어의 상대적 인기를 결정하는 유일한 힘은 아닙니다. 레거시 소프트웨어(Cobol)와 과대광고(Ada, Java)도 역할을 하지만, 장기적으로 볼 때 가장 강력한 힘이라고 생각합니다. 초기 임계 질량과 충분한 시간이 주어진다면, 프로그래밍 언어는 아마도 마땅히 받아야 할 만큼 인기를 얻게 될 것입니다. 그리고 인기는 좋은 언어와 나쁜 언어를 더욱 분리시키는데, 실제 사용자들의 피드백은 항상 개선으로 이어지기 때문입니다. 어떤 인기 있는 언어가 수명 동안 얼마나 많이 변했는지 보십시오. Perl과 Fortran은 극단적인 경우이지만, Lisp조차도 많이 변했습니다. 예를 들어 Lisp 1.5에는 매크로가 없었습니다. 이것들은 MIT의 해커들이 Lisp를 사용하여 실제 프로그램을 작성하는 데 몇 년을 보낸 후에 진화했습니다. [1]

따라서 언어가 인기 있기 위해 좋아야 하는지 여부와 관계없이, 저는 언어가 좋기 위해 인기 있어야 한다고 생각합니다. 그리고 좋게 유지되기 위해 인기 있는 상태를 유지해야 합니다. 프로그래밍 언어의 최신 기술은 가만히 있지 않습니다. 하지만 오늘날 우리가 가진 Lisp는 1980년대 중반 MIT에서 가졌던 것과 거의 같습니다. 왜냐하면 그때가 Lisp가 충분히 크고 요구사항이 많은 사용자 기반을 가졌던 마지막 시기였기 때문입니다.

물론 해커들은 언어를 사용하기 전에 그 언어에 대해 알아야 합니다. 어떻게 들을까요? 다른 해커들로부터요. 하지만 다른 사람들이 그 언어에 대해 듣기 위해서라도 언어를 사용하는 초기 해커 그룹이 있어야 합니다. 이 그룹이 얼마나 커야 할까요? 몇 명의 사용자가 임계 질량을 이룰까요? 즉석에서 말하자면, 스무 명이라고 생각합니다. 만약 어떤 언어가 스무 명의 독립적인 사용자, 즉 스스로 사용하기로 결정한 스무 명의 사용자를 가진다면, 저는 그것을 실제라고 간주할 것입니다.

거기에 도달하는 것은 쉽지 않을 것입니다. 스무 명에서 천 명으로 가는 것보다 0명에서 스무 명으로 가는 것이 더 어렵다고 해도 놀라지 않을 것입니다. 초기 스무 명의 사용자를 확보하는 가장 좋은 방법은 아마도 트로이 목마를 사용하는 것입니다. 사람들이 원하는 애플리케이션을 제공하고, 그 애플리케이션이 우연히 새로운 언어로 작성되도록 하는 것이죠.

2 외부 요인

프로그래밍 언어의 인기에 영향을 미치는 한 가지 외부 요인을 인정하는 것부터 시작합시다. 인기 있는 프로그래밍 언어가 되려면 인기 있는 시스템의 스크립팅 언어여야 합니다. Fortran과 Cobol은 초기 IBM 메인프레임의 스크립팅 언어였습니다. C는 Unix의 스크립팅 언어였고, 나중에 Perl도 마찬가지였습니다. Tcl은 Tk의 스크립팅 언어입니다. Java와 Javascript는 웹 브라우저의 스크립팅 언어가 되도록 의도되었습니다.

Lisp는 대중적인 시스템의 스크립팅 언어가 아니기 때문에 대중적으로 인기 있는 언어가 아닙니다. Lisp가 유지하는 인기는 1960년대와 1970년대, 즉 MIT의 스크립팅 언어였던 시절로 거슬러 올라갑니다. 당시 많은 위대한 프로그래머들이 한때 MIT와 관련이 있었습니다. 그리고 1970년대 초, C가 나오기 전에는 MacLisp라고 불리는 MIT의 Lisp 방언이 진지한 해커라면 사용하고 싶어 할 유일한 프로그래밍 언어 중 하나였습니다.

오늘날 Lisp는 Emacs와 Autocad라는 두 가지 중간 정도의 인기 시스템의 스크립팅 언어이며, 그런 이유로 오늘날 이루어지는 대부분의 Lisp 프로그래밍은 Emacs Lisp 또는 AutoLisp로 이루어질 것이라고 생각합니다.

프로그래밍 언어는 고립되어 존재하지 않습니다. 해킹하다는 타동사입니다. 해커들은 보통 무언가를 해킹하고 있으며, 실제로는 언어가 해킹하는 데 사용되는 대상에 따라 평가됩니다. 따라서 인기 있는 언어를 설계하고 싶다면, 언어 이상의 것을 제공하거나, 기존 시스템의 스크립팅 언어를 대체하도록 언어를 설계해야 합니다.

Common Lisp가 인기가 없는 부분적인 이유는 고아와 같기 때문입니다. 원래는 해킹할 시스템, 즉 Lisp Machine과 함께 나왔습니다. 하지만 Lisp Machine은 (병렬 컴퓨터와 함께) 1980년대 범용 프로세서의 증가하는 성능에 의해 압도당했습니다. Common Lisp는 Unix의 좋은 스크립팅 언어였다면 인기를 유지했을 수도 있습니다. 안타깝게도, 그것은 끔찍하게 나쁜 언어입니다.

이 상황을 설명하는 한 가지 방법은 언어가 자체적인 장점으로만 평가되지 않는다고 말하는 것입니다. 다른 관점은 프로그래밍 언어가 어떤 것의 스크립팅 언어가 아니라면 진정한 프로그래밍 언어가 아니라는 것입니다. 이것은 놀라움으로 다가올 때만 불공평하게 느껴집니다. 저는 이것이 프로그래밍 언어가 예를 들어 구현을 가져야 한다고 기대하는 것보다 더 불공평하지 않다고 생각합니다. 그것은 단지 프로그래밍 언어의 일부일 뿐입니다.

프로그래밍 언어는 물론 좋은 구현이 필요하며, 이것은 무료여야 합니다. 기업은 소프트웨어에 돈을 지불하겠지만, 개별 해커는 그렇지 않을 것이며, 당신이 끌어들여야 할 대상은 바로 해커들입니다.

언어는 또한 그에 대한 책이 있어야 합니다. 책은 얇고, 잘 쓰여져야 하며, 좋은 예시로 가득해야 합니다. K&R이 여기서 이상적입니다. 현재로서는 언어가 O'Reilly에서 출판한 책을 가지고 있어야 한다고 거의 말할 수 있습니다. 그것이 해커들에게 중요한지 여부를 판단하는 기준이 되고 있습니다.

온라인 문서도 있어야 합니다. 사실, 책은 온라인 문서로 시작할 수도 있습니다. 하지만 저는 아직 물리적인 책이 구식이라고 생각하지 않습니다. 그 형식은 편리하고, 출판사가 부과하는 사실상의 검열은 불완전하더라도 유용한 필터입니다. 서점은 새로운 언어에 대해 배우는 가장 중요한 장소 중 하나입니다.

3 간결함

어떤 언어든 필요한 세 가지, 즉 무료 구현, 책, 그리고 해킹할 대상을 제공할 수 있다면, 해커들이 좋아할 만한 언어를 어떻게 만들 수 있을까요?

해커들이 좋아하는 한 가지는 간결함입니다. 해커들은 수학자나 모더니스트 건축가들이 게으른 것과 같은 방식으로 게으릅니다. 그들은 불필요한 것을 싫어합니다. 프로그램을 작성하려는 해커가 적어도 무의식적으로는 자신이 입력해야 할 총 문자 수를 기준으로 어떤 언어를 사용할지 결정한다고 말해도 과언이 아닐 것입니다. 이것이 해커들이 정확히 생각하는 방식이 아니라면, 언어 설계자는 마치 그렇다고 가정하고 행동하는 것이 좋을 것입니다.

영어를 닮도록 의도된 장황한 표현으로 사용자를 응석받이처럼 대하는 것은 실수입니다. Cobol은 이러한 결함으로 악명이 높습니다. 해커는 다음과 같이 작성하라는 요청을 받는 것을

add x to y giving z

대신

z = x+y

자신의 지능에 대한 모욕과 신에 대한 죄악 사이의 어떤 것으로 간주할 것입니다.

Lisp는 car와 cdr 대신 first와 rest를 사용해야 프로그램이 더 읽기 쉬워질 것이라고 가끔 말해졌습니다. 아마 처음 몇 시간 동안은 그럴 수도 있습니다. 하지만 해커는 car가 리스트의 첫 번째 요소를 의미하고 cdr이 나머지를 의미한다는 것을 충분히 빨리 배울 수 있습니다. first와 rest를 사용하면 타이핑이 50% 더 많아집니다. 그리고 길이도 달라서, car와 cdr이 종종 연속된 줄에서 호출되는 것처럼, 인자들이 정렬되지 않을 것입니다. 저는 코드가 페이지에 어떻게 정렬되는지가 매우 중요하다는 것을 발견했습니다. 가변 폭 글꼴로 설정된 Lisp 코드는 거의 읽을 수 없으며, 친구들도 다른 언어에서도 마찬가지라고 말합니다.

간결함은 강타입 언어가 불리한 지점 중 하나입니다. 다른 모든 조건이 동일하다면, 아무도 수많은 선언으로 프로그램을 시작하고 싶어 하지 않습니다. 암시될 수 있는 모든 것은 암시되어야 합니다.

개별 토큰도 짧아야 합니다. Perl과 Common Lisp는 이 문제에 대해 정반대의 입장을 취합니다. Perl 프로그램은 거의 암호처럼 밀집될 수 있는 반면, Common Lisp 내장 연산자의 이름은 우스꽝스러울 정도로 깁니다. Common Lisp 설계자들은 아마 사용자들이 이러한 긴 이름을 대신 입력해 줄 텍스트 편집기를 가지고 있을 것이라고 예상했을 것입니다. 하지만 긴 이름의 비용은 단순히 입력하는 비용만이 아닙니다. 읽는 비용과 화면에서 차지하는 공간의 비용도 있습니다.

4 해킹 가능성

해커에게 간결함보다 더 중요한 한 가지는 원하는 것을 할 수 있다는 것입니다. 프로그래밍 언어의 역사에서 프로그래머들이 부적절하다고 여겨지는 일을 하지 못하게 막는 데 놀라울 정도로 많은 노력이 들어갔습니다. 이것은 위험할 정도로 주제넘은 계획입니다. 언어 설계자가 프로그래머가 무엇을 해야 할지 어떻게 알 수 있을까요? 저는 언어 설계자들이 스스로를 보호해야 할 어설픈 사람보다는, 그들이 전혀 예상하지 못한 일을 해야 할 천재라고 목표 사용자를 생각하는 것이 더 나을 것이라고 생각합니다. 어설픈 사람은 어차피 스스로 발등을 찍을 것입니다. 다른 패키지의 변수를 참조하는 것으로부터는 그를 구할 수 있을지 모르지만, 잘못된 문제를 해결하기 위해 형편없이 설계된 프로그램을 작성하고 그것을 영원히 붙잡고 있는 것으로부터는 그를 구할 수 없습니다.

좋은 프로그래머들은 종종 위험하고 불쾌한 일을 하고 싶어 합니다. 불쾌하다는 것은 언어가 제시하려는 어떤 의미론적 외관 뒤로 넘어가는 것, 예를 들어 어떤 고수준 추상화의 내부 표현을 손에 넣는 것을 의미합니다. 해커들은 해킹하는 것을 좋아하며, 해킹은 사물 내부로 들어가 원래 설계자의 의도를 재해석하는 것을 의미합니다.

당신의 의도가 재해석되도록 하세요. 어떤 도구를 만들든 사람들은 당신이 의도하지 않은 방식으로 그것을 사용하며, 프로그래밍 언어와 같이 고도로 정교한 도구에서는 특히 그렇습니다. 많은 해커들이 당신이 상상하지 못한 방식으로 당신의 의미론적 모델을 조정하고 싶어 할 것입니다. 저는 그렇게 하도록 두라고 말합니다. 가비지 컬렉터와 같은 런타임 시스템을 위험에 빠뜨리지 않는 한, 프로그래머에게 가능한 한 많은 내부 요소에 대한 접근 권한을 부여하십시오.

Common Lisp에서 저는 종종 구조체의 필드를 반복하고 싶었습니다. 예를 들어, 삭제된 객체에 대한 참조를 제거하거나 초기화되지 않은 필드를 찾는 것입니다. 저는 구조체가 내부적으로는 벡터라는 것을 알고 있습니다. 하지만 어떤 구조체에도 호출할 수 있는 범용 함수를 작성할 수 없습니다. 필드에 이름으로만 접근할 수 있는데, 그것이 구조체가 의미하는 바이기 때문입니다.

해커는 큰 프로그램에서 의도된 모델을 한두 번만 전복시키고 싶을 수도 있습니다. 하지만 그렇게 할 수 있다는 것이 얼마나 큰 차이를 만드는지 모릅니다. 그리고 그것은 단순히 문제를 해결하는 것 이상의 문제일 수도 있습니다. 여기에는 일종의 즐거움도 있습니다. 해커들은 외과 의사가 끔찍한 내장을 뒤적거리는 은밀한 즐거움, 십대들이 여드름을 짜는 은밀한 즐거움을 공유합니다. [2] 적어도 소년들에게는 특정 종류의 공포가 매력적입니다. Maxim 잡지는 핀업 사진과 끔찍한 사고 사진이 혼합된 연간 사진집을 발행합니다. 그들은 독자를 압니다.

역사적으로 Lisp는 해커들이 원하는 대로 할 수 있도록 하는 데 능숙했습니다. Common Lisp의 정치적 올바름은 일탈입니다. 초기 Lisp는 모든 것을 손에 넣을 수 있게 해주었습니다. 다행히도 그 정신의 상당 부분은 매크로에 보존되어 있습니다. 소스 코드에 임의의 변환을 가할 수 있다는 것은 얼마나 멋진 일입니까.

고전적인 매크로는 진정한 해커의 도구입니다. 간단하고, 강력하며, 위험합니다. 그것들이 무엇을 하는지 이해하기는 매우 쉽습니다. 매크로의 인수에 함수를 호출하고, 그 함수가 반환하는 모든 것이 매크로 호출 자리에 삽입됩니다. 위생적인 매크로는 정반대의 원칙을 구현합니다. 그것들은 당신이 그들이 무엇을 하는지 이해하지 못하도록 보호하려고 합니다. 저는 위생적인 매크로가 한 문장으로 설명되는 것을 들어본 적이 없습니다. 그리고 그것들은 프로그래머가 무엇을 원하도록 허용할지 결정하는 것의 위험성을 보여주는 고전적인 예시입니다. 위생적인 매크로는 다른 것들 중에서도 변수 캡처로부터 저를 보호하기 위한 것이지만, 변수 캡처는 제가 일부 매크로에서 정확히 원하는 것입니다.

정말 좋은 언어는 깔끔하면서도 더러워야 합니다. 잘 이해되고 고도로 직교적인 연산자로 이루어진 작은 핵심을 가지고 깔끔하게 설계되어야 하지만, 해커들이 원하는 대로 다룰 수 있다는 의미에서 더러워야 합니다. C가 그렇습니다. 초기 Lisp도 그랬습니다. 진정한 해커의 언어는 항상 약간 불량스러운 특성을 가질 것입니다.

좋은 프로그래밍 언어는 "소프트웨어 공학"이라는 문구를 사용하는 사람들이 고개를 저으며 못마땅해할 만한 기능을 가지고 있어야 합니다. 연속체의 다른 끝에는 Ada와 Pascal과 같은 언어가 있는데, 이는 교육에는 좋지만 그 외에는 별다른 쓸모가 없는 적절성의 모델입니다.

5 일회성 프로그램

해커들에게 매력적이려면, 언어는 그들이 작성하고 싶어 하는 종류의 프로그램을 작성하는 데 좋아야 합니다. 그리고 그것은 아마도 놀랍게도, 일회성 프로그램을 작성하는 데 좋아야 한다는 것을 의미합니다.

일회성 프로그램은 어떤 제한된 작업을 위해 빠르게 작성하는 프로그램입니다. 예를 들어 시스템 관리 작업을 자동화하거나, 시뮬레이션을 위한 테스트 데이터를 생성하거나, 데이터를 한 형식에서 다른 형식으로 변환하는 프로그램입니다. 일회성 프로그램의 놀라운 점은 제2차 세계대전 중 많은 미국 대학에 지어진 "임시" 건물처럼, 종종 버려지지 않는다는 것입니다. 많은 프로그램이 실제 기능과 실제 사용자를 가진 실제 프로그램으로 진화합니다.

저는 최고의 대규모 프로그램들이 Hoover Dam처럼 처음부터 크게 설계되기보다는 이런 식으로 시작된다는 직감이 있습니다. 아무것도 없는 상태에서 큰 것을 만드는 것은 두려운 일입니다. 사람들이 너무 큰 프로젝트를 맡으면 압도당합니다. 프로젝트는 지연되거나, 결과물이 무미건조하고 딱딱해집니다. 실제 도심 대신 쇼핑몰, Rome 대신 Brasilia, C 대신 Ada처럼 말입니다.

큰 프로그램을 얻는 또 다른 방법은 일회성 프로그램으로 시작하여 계속 개선하는 것입니다. 이 접근 방식은 덜 부담스럽고, 프로그램의 설계는 진화의 혜택을 받습니다. 저는 살펴보면 대부분의 큰 프로그램이 이런 식으로 개발되었다는 것을 알게 될 것이라고 생각합니다. 그리고 이런 식으로 진화한 프로그램들은 아마도 처음 작성된 언어로 여전히 작성되어 있을 것입니다. 왜냐하면 정치적인 이유를 제외하고는 프로그램을 포팅하는 경우가 드물기 때문입니다. 따라서 역설적으로, 대규모 시스템에 사용되는 언어를 만들고 싶다면, 일회성 프로그램을 작성하는 데 좋은 언어를 만들어야 합니다. 왜냐하면 대규모 시스템은 거기서 나오기 때문입니다.

Perl은 이 아이디어의 두드러진 예시입니다. Perl은 일회성 프로그램을 작성하기 위해 설계되었을 뿐만 아니라, 그 자체로도 거의 일회성 프로그램이었습니다. Perl은 보고서 생성을 위한 유틸리티 모음으로 시작했으며, 사람들이 Perl로 작성한 일회성 프로그램이 커지면서 프로그래밍 언어로 진화했습니다. Perl 5가 되어서야 (그때라도) 진지한 프로그램을 작성하는 데 적합한 언어가 되었지만, 이미 엄청난 인기를 누리고 있었습니다.

어떤 점이 언어를 일회성 프로그램에 좋게 만들까요? 우선, 쉽게 사용할 수 있어야 합니다. 일회성 프로그램은 한 시간 안에 작성할 것으로 예상하는 것입니다. 따라서 사용하려는 컴퓨터에 이미 언어가 설치되어 있어야 할 것입니다. 사용하기 전에 설치해야 하는 것이어서는 안 됩니다. 그곳에 있어야 합니다. C는 운영체제와 함께 제공되었기 때문에 그곳에 있었습니다. Perl은 원래 시스템 관리자를 위한 도구였고, 당신의 시스템 관리자가 이미 설치했기 때문에 그곳에 있었습니다.

하지만 사용 가능하다는 것은 설치되어 있다는 것 이상을 의미합니다. 명령줄 인터페이스를 가진 대화형 언어는 별도로 컴파일하고 실행해야 하는 언어보다 더 사용 가능합니다. 인기 있는 프로그래밍 언어는 대화형이어야 하고, 빠르게 시작되어야 합니다.

일회성 프로그램에서 원하는 또 다른 것은 간결함입니다. 간결함은 항상 해커들에게 매력적이며, 한 시간 안에 완성할 것으로 예상하는 프로그램에서는 더욱 그렇습니다.

6 라이브러리

물론 간결함의 궁극은 프로그램이 이미 작성되어 있어서 단순히 호출하기만 하면 되는 것입니다. 그리고 이것은 제가 프로그래밍 언어의 점점 더 중요해질 기능이라고 생각하는 것, 즉 라이브러리 함수로 이어집니다. Perl은 문자열 조작을 위한 대규모 라이브러리를 가지고 있기 때문에 승리합니다. 이러한 종류의 라이브러리 함수는 데이터를 변환하거나 추출하기 위해 원래 작성되는 경우가 많은 일회성 프로그램에 특히 중요합니다. 많은 Perl 프로그램은 아마도 몇 개의 라이브러리 호출을 함께 붙여서 시작될 것입니다.

저는 향후 50년 동안 프로그래밍 언어에서 일어날 많은 발전이 라이브러리 함수와 관련될 것이라고 생각합니다. 미래의 프로그래밍 언어는 핵심 언어만큼 신중하게 설계된 라이브러리를 가질 것이라고 생각합니다. 프로그래밍 언어 설계는 언어를 강타입으로 만들지 약타입으로 만들지, 객체 지향으로 만들지 함수형으로 만들지 등이 아니라, 훌륭한 라이브러리를 설계하는 방법에 관한 것이 될 것입니다. 타입 시스템을 설계하는 방법에 대해 생각하기를 좋아하는 언어 설계자들은 이것에 몸서리칠 수도 있습니다. 거의 애플리케이션을 작성하는 것과 같으니까요! 안타깝지만 어쩔 수 없습니다. 언어는 프로그래머를 위한 것이고, 라이브러리는 프로그래머가 필요로 하는 것입니다.

좋은 라이브러리를 설계하는 것은 어렵습니다. 단순히 많은 코드를 작성하는 문제가 아닙니다. 라이브러리가 너무 커지면, 필요한 함수를 찾는 데 직접 코드를 작성하는 것보다 더 많은 시간이 걸릴 수도 있습니다. 라이브러리는 핵심 언어처럼 소수의 직교 연산자 집합을 사용하여 설계되어야 합니다. 프로그래머가 어떤 라이브러리 호출이 자신이 필요한 것을 할지 추측할 수 있어야 합니다.

라이브러리는 Common Lisp가 부족한 부분 중 하나입니다. 문자열 조작을 위한 기본적인 라이브러리만 있을 뿐, 운영체제와 통신하기 위한 라이브러리는 거의 없습니다. 역사적인 이유로 Common Lisp는 OS가 존재하지 않는 척합니다. 그리고 OS와 통신할 수 없기 때문에, Common Lisp의 내장 연산자만으로는 진지한 프로그램을 작성하기 어려울 것입니다. 구현별 해킹도 사용해야 하며, 실제로는 이러한 해킹이 원하는 모든 것을 제공하지 않는 경향이 있습니다. Common Lisp에 강력한 문자열 라이브러리와 좋은 OS 지원이 있었다면 해커들은 Lisp를 훨씬 더 높이 평가했을 것입니다.

7 문법

Lisp의 문법, 더 정확히는 문법의 부재를 가진 언어가 과연 인기를 얻을 수 있을까요? 이 질문에 대한 답은 모릅니다. 저는 문법이 Lisp가 현재 인기 없는 주된 이유가 아니라고 생각합니다. Common Lisp는 익숙하지 않은 문법보다 더 심각한 문제를 가지고 있습니다. 저는 접두사 문법에 익숙하지만, 강력한 문자열 라이브러리를 가지고 있고 OS와 통신할 수 있기 때문에 기본적으로 Perl을 사용하는 프로그래머들을 여러 명 알고 있습니다.

접두사 표기법에는 두 가지 가능한 문제가 있습니다. 프로그래머에게 익숙하지 않다는 것과 충분히 밀집되어 있지 않다는 것입니다. Lisp 세계의 통념은 첫 번째 문제가 진짜 문제라는 것입니다. 저는 그렇게 확신하지 않습니다. 네, 접두사 표기법은 일반 프로그래머들을 당황하게 만듭니다. 하지만 저는 일반 프로그래머들의 의견이 중요하다고 생각하지 않습니다. 언어는 전문 해커들이 어떻게 생각하는지에 따라 인기가 있거나 없게 되며, 저는 전문 해커들이 접두사 표기법을 다룰 수 있을 것이라고 생각합니다. Perl 문법은 상당히 이해하기 어려울 수 있지만, 그것이 Perl의 인기를 방해하지는 않았습니다. 오히려 Perl 컬트를 형성하는 데 도움이 되었을 수도 있습니다.

더 심각한 문제는 접두사 표기법의 확산성입니다. 전문 해커들에게는 그것이 정말 문제입니다. a[x,y]라고 쓸 수 있는데 (aref a x y)라고 쓰고 싶어 하는 사람은 아무도 없습니다.

이 특정 경우에 문제를 우회하는 방법이 있습니다. 데이터 구조를 인덱스에 대한 함수처럼 취급한다면, (a x y)라고 쓸 수 있으며, 이는 Perl 형식보다도 더 짧습니다. 유사한 트릭으로 다른 유형의 표현식도 단축할 수 있습니다.

들여쓰기를 중요하게 만듦으로써 많은 괄호를 없애거나 (선택 사항으로 만들 수 있습니다). 어차피 프로그래머들은 그렇게 코드를 읽습니다. 들여쓰기가 한 가지를 말하고 구분자가 다른 것을 말할 때, 우리는 들여쓰기를 따릅니다. 들여쓰기를 중요하게 취급하면 이러한 일반적인 버그의 원인을 제거하고 프로그램을 더 짧게 만들 수 있습니다.

때로는 중위 문법이 읽기 더 쉽습니다. 특히 수학 표현식에서 그렇습니다. 저는 프로그래밍 인생 내내 Lisp를 사용했지만 여전히 접두사 수학 표현식이 자연스럽다고 생각하지 않습니다. 하지만 특히 코드를 생성할 때, 임의의 수의 인수를 취하는 연산자를 가지는 것은 편리합니다. 따라서 중위 문법을 사용한다면, 아마도 어떤 종류의 읽기 매크로로 구현되어야 할 것입니다.

저는 Lisp에 문법을 도입하는 것에 대해 종교적으로 반대해서는 안 된다고 생각합니다. 잘 이해되는 방식으로 기본 s-표현식으로 변환되는 한 말입니다. Lisp에는 이미 상당한 문법이 있습니다. 아무도 강제로 사용하지 않는 한 더 많은 것을 도입하는 것이 반드시 나쁜 것은 아닙니다. Common Lisp에서는 일부 구분자가 언어에 예약되어 있는데, 이는 적어도 일부 설계자들이 미래에 더 많은 문법을 가질 의도가 있었음을 시사합니다.

Common Lisp에서 가장 심하게 Lisp답지 않은 문법 조각 중 하나는 형식 문자열에 나타납니다. format은 그 자체로 언어이며, 그 언어는 Lisp가 아닙니다. 만약 Lisp에 더 많은 문법을 도입할 계획이 있다면, 형식 지정자를 포함할 수 있을 것입니다. 매크로가 다른 종류의 코드를 생성하는 방식과 동일하게 형식 지정자를 생성할 수 있다면 좋은 일일 것입니다.

저명한 Lisp 해커가 CLTL 사본을 펼치면 format 섹션이 나온다고 말했습니다. 저도 그렇습니다. 이것은 아마도 개선의 여지가 있음을 나타낼 것입니다. 또한 프로그램이 많은 I/O를 수행한다는 의미일 수도 있습니다.

8 효율성

모두가 알다시피 좋은 언어는 빠른 코드를 생성해야 합니다. 하지만 실제로는 빠른 코드가 주로 언어 설계에서 하는 일에서 비롯된다고 생각하지 않습니다. Knuth가 오래전에 지적했듯이, 속도는 특정 중요한 병목 현상에서만 중요합니다. 그리고 많은 프로그래머들이 그 이후로 관찰했듯이, 이러한 병목 현상이 어디에 있는지 매우 자주 착각합니다.

따라서 실제로는 빠른 코드를 얻는 방법은 언어를 강타입으로 만드는 것보다 매우 좋은 프로파일러를 갖는 것입니다. 프로그램의 모든 호출에서 모든 인수의 타입을 알 필요는 없습니다. 병목 현상에서 인수의 타입을 선언할 수 있어야 합니다. 그리고 더 나아가, 병목 현상이 어디에 있는지 알아낼 수 있어야 합니다.

사람들이 Lisp에 대해 불평하는 한 가지는 무엇이 비용이 많이 드는지 알기 어렵다는 것입니다. 이것은 사실일 수 있습니다. 또한 매우 추상적인 언어를 원한다면 불가피할 수도 있습니다. 그리고 어떤 경우든 좋은 프로파일링이 문제를 해결하는 데 큰 도움이 될 것이라고 생각합니다. 무엇이 비용이 많이 드는지 곧 알게 될 것입니다.

여기서 문제의 일부는 사회적입니다. 언어 설계자들은 빠른 컴파일러를 작성하는 것을 좋아합니다. 그것이 그들이 자신의 기술을 측정하는 방식입니다. 그들은 프로파일러를 기껏해야 추가 기능으로 생각합니다. 하지만 실제로는 좋은 프로파일러가 빠른 코드를 생성하는 컴파일러보다 언어로 작성된 실제 프로그램의 속도를 향상시키는 데 더 많은 일을 할 수 있습니다. 여기서도 언어 설계자들은 사용자들과 다소 동떨어져 있습니다. 그들은 약간 잘못된 문제를 정말 잘 해결합니다.

능동적인 프로파일러를 갖는 것이 좋은 생각일 수 있습니다. 프로그래머가 요청하기를 기다리는 대신 성능 데이터를 프로그래머에게 푸시하는 것입니다. 예를 들어, 편집기는 프로그래머가 소스 코드를 편집할 때 병목 현상을 빨간색으로 표시할 수 있습니다. 또 다른 접근 방식은 실행 중인 프로그램에서 무슨 일이 일어나고 있는지 어떤 식으로든 표현하는 것입니다. 이는 서버 기반 애플리케이션에서 특히 큰 이점이 될 것입니다. 서버 기반 애플리케이션에서는 살펴볼 실행 중인 프로그램이 많기 때문입니다. 능동적인 프로파일러는 프로그램이 실행될 때 메모리에서 무슨 일이 일어나는지 그래픽으로 보여주거나, 심지어 무슨 일이 일어나는지 알려주는 소리를 낼 수도 있습니다.

소리는 문제에 대한 좋은 단서입니다. 제가 일했던 한 곳에서는 웹 서버에 무슨 일이 일어나고 있는지 보여주는 큰 다이얼 보드가 있었습니다. 바늘은 작은 서보모터에 의해 움직였고, 서보모터는 회전할 때 약간의 소리를 냈습니다. 저는 제 책상에서 보드를 볼 수 없었지만, 소리만으로 서버에 문제가 생겼을 때 즉시 알 수 있다는 것을 발견했습니다.

비효율적인 알고리즘을 자동으로 감지하는 프로파일러를 작성하는 것도 가능할 수 있습니다. 특정 메모리 접근 패턴이 나쁜 알고리즘의 확실한 징후로 밝혀져도 놀라지 않을 것입니다. 만약 우리 프로그램을 실행하는 작은 사람이 컴퓨터 안을 돌아다닌다면, 그는 아마도 연방 정부 직원만큼이나 길고 애절한 직업 이야기를 들려줄 것입니다. 저는 종종 프로세서를 많은 헛된 일에 보내고 있다는 느낌을 받지만, 프로세서가 무엇을 하고 있는지 제대로 볼 방법이 없었습니다.

현재 많은 Lisp는 바이트 코드로 컴파일되며, 이는 인터프리터에 의해 실행됩니다. 이는 보통 구현을 더 쉽게 포팅하기 위해 수행되지만, 유용한 언어 기능이 될 수도 있습니다. 바이트 코드를 언어의 공식적인 부분으로 만들고, 프로그래머가 병목 현상에서 인라인 바이트 코드를 사용할 수 있도록 허용하는 것이 좋은 생각일 수 있습니다. 그러면 그러한 최적화도 이식성이 있을 것입니다.

최종 사용자가 인식하는 속도의 본질이 변하고 있을 수 있습니다. 서버 기반 애플리케이션의 등장으로 점점 더 많은 프로그램이 I/O 바운드(I/O에 의해 제한됨)로 판명될 수 있습니다. I/O를 빠르게 만드는 것은 가치 있는 일입니다. 언어는 간단하고 빠른 형식화된 출력 함수와 같은 직접적인 조치뿐만 아니라 캐싱 및 영구 객체와 같은 깊은 구조적 변화를 통해서도 도움을 줄 수 있습니다.

사용자들은 응답 시간에 관심이 있습니다. 하지만 또 다른 종류의 효율성이 점점 더 중요해질 것입니다. 프로세서당 지원할 수 있는 동시 사용자 수입니다. 가까운 미래에 작성될 흥미로운 애플리케이션 중 다수는 서버 기반이 될 것이며, 서버당 사용자 수는 그러한 애플리케이션을 호스팅하는 모든 사람에게 중요한 질문입니다. 서버 기반 애플리케이션을 제공하는 사업의 자본 비용에서 이것은 제수(나누는 수)입니다.

수년 동안 대부분의 최종 사용자 애플리케이션에서는 효율성이 크게 중요하지 않았습니다. 개발자들은 각 사용자가 점점 더 강력한 프로세서를 책상에 두고 있을 것이라고 가정할 수 있었습니다. 그리고 Parkinson의 법칙에 따라 소프트웨어는 사용 가능한 자원을 사용하도록 확장되었습니다. 이는 서버 기반 애플리케이션에서 바뀔 것입니다. 그 세계에서는 하드웨어와 소프트웨어가 함께 제공될 것입니다. 서버 기반 애플리케이션을 제공하는 회사에게는 서버당 지원할 수 있는 사용자 수가 최종 수익에 매우 큰 차이를 만들 것입니다.

일부 애플리케이션에서는 프로세서가 제한 요소가 될 것이며, 실행 속도가 최적화해야 할 가장 중요한 것이 될 것입니다. 하지만 종종 메모리가 한계가 될 것입니다. 동시 사용자 수는 각 사용자의 데이터에 필요한 메모리 양에 따라 결정될 것입니다. 언어는 여기서도 도움을 줄 수 있습니다. 스레드에 대한 좋은 지원은 모든 사용자가 단일 힙을 공유할 수 있도록 할 것입니다. 또한 영구 객체 및/또는 지연 로딩을 위한 언어 수준 지원을 갖는 것도 도움이 될 수 있습니다.

9 시간

인기 있는 언어가 필요로 하는 마지막 요소는 시간입니다. 너무나 많은 프로그래밍 언어가 사라지는 것처럼, 사라질 수도 있는 언어로 프로그램을 작성하고 싶어 하는 사람은 아무도 없습니다. 그래서 대부분의 해커들은 언어가 몇 년 동안 존재한 후에야 비로소 사용을 고려하는 경향이 있습니다.

멋진 새로운 것을 발명하는 사람들은 종종 이 사실을 발견하고 놀라지만, 어떤 메시지든 사람들에게 전달하려면 시간이 필요합니다. 제 친구 중 한 명은 누군가 처음 부탁할 때 거의 아무것도 하지 않습니다. 그는 사람들이 때때로 원하지 않는 것을 요청한다는 것을 알고 있습니다. 시간을 낭비하지 않기 위해, 그는 세 번째나 네 번째 요청을 받을 때까지 기다립니다. 그때쯤이면 요청하는 사람은 상당히 짜증이 날 수도 있지만, 적어도 그들은 아마도 정말로 요청하는 것을 원할 것입니다.

대부분의 사람들은 새로운 소식에 대해 비슷한 종류의 필터링을 하는 법을 배웠습니다. 그들은 어떤 것에 대해 열 번 들을 때까지는 주의를 기울이지도 않습니다. 그들은 완벽하게 정당합니다. 대부분의 뜨거운 신기술들은 결국 시간 낭비로 판명되고, 결국 사라집니다. VRML 학습을 미룸으로써, 저는 그것을 전혀 배울 필요가 없었습니다.

따라서 새로운 것을 발명하는 사람은 사람들이 그것을 이해하기 시작하기까지 수년 동안 메시지를 계속 반복해야 할 것으로 예상해야 합니다. 제가 아는 한, 우리는 최초의 웹 서버 기반 애플리케이션을 작성했으며, 사람들이 그것을 다운로드할 필요가 없다는 것을 이해시키는 데 수년이 걸렸습니다. 그들이 어리석어서가 아니었습니다. 그들은 단지 우리에게 귀를 기울이지 않았을 뿐입니다.

좋은 소식은, 단순한 반복이 문제를 해결한다는 것입니다. 당신이 해야 할 일은 당신의 이야기를 계속하는 것이고, 결국 사람들은 듣기 시작할 것입니다. 사람들이 당신이 있다는 것을 알아차릴 때 주의를 기울이는 것이 아니라, 당신이 여전히 그곳에 있다는 것을 알아차릴 때 주의를 기울입니다.

추진력을 얻는 데 시간이 좀 걸리는 것은 당연합니다. 대부분의 기술은 처음 출시된 후에도 상당히 진화합니다. 특히 프로그래밍 언어는 더욱 그렇습니다. 새로운 기술에게는 소수의 얼리 어답터들만이 몇 년 동안 사용하는 것보다 더 좋은 것은 없습니다. 얼리 어답터들은 정교하고 요구사항이 많으며, 당신의 기술에 남아있는 모든 결함을 빠르게 찾아냅니다. 사용자가 몇 명밖에 없을 때는 그들 모두와 긴밀하게 연락할 수 있습니다. 그리고 얼리 어답터들은 당신이 시스템을 개선할 때, 비록 약간의 문제가 발생하더라도 관대합니다.

새로운 기술이 도입되는 두 가지 방법이 있습니다. 유기적 성장 방식과 빅뱅 방식입니다. 유기적 성장 방식은 고전적인, 자금 부족한 차고 스타트업으로 대표됩니다. 몇몇 사람들이 알려지지 않은 곳에서 새로운 기술을 개발합니다. 그들은 마케팅 없이 출시하고 처음에는 소수의 (열광적인) 사용자만을 가집니다. 그들은 기술을 계속 개선하고, 그동안 사용자 기반은 입소문을 통해 성장합니다. 그들이 알아차리기도 전에, 그들은 커집니다.

다른 접근 방식인 빅뱅 방식은 VC의 지원을 받고 대대적으로 마케팅되는 스타트업으로 대표됩니다. 그들은 제품 개발을 서두르고, 대대적인 홍보와 함께 출시하며, 즉시 (그들이 바라건대) 대규모 사용자 기반을 확보합니다.

일반적으로 차고에서 일하는 사람들은 빅뱅 방식의 사람들을 부러워합니다. 빅뱅 방식의 사람들은 매끄럽고 자신감 있으며 VC들에게 존경받습니다. 그들은 모든 최고의 것을 감당할 수 있으며, 출시를 둘러싼 홍보 캠페인은 그들을 유명인으로 만드는 부수적인 효과를 가집니다. 차고에 앉아 있는 유기적 성장 방식의 사람들은 가난하고 사랑받지 못한다고 느낍니다. 하지만 저는 그들이 자신을 불쌍히 여기는 것이 종종 착각이라고 생각합니다. 유기적 성장은 빅뱅 방식보다 더 나은 기술과 더 부유한 창업자를 낳는 것 같습니다. 오늘날 지배적인 기술들을 살펴보면, 대부분이 유기적으로 성장했다는 것을 알 수 있을 것입니다.

이 패턴은 회사에만 적용되는 것이 아닙니다. 후원 연구에서도 볼 수 있습니다. Multics와 Common Lisp는 빅뱅 프로젝트였고, Unix와 MacLisp는 유기적 성장 프로젝트였습니다.

10 재설계

"최고의 글쓰기는 다시 쓰는 것이다"라고 E. B. White는 썼습니다. 모든 좋은 작가는 이것을 알고 있으며, 소프트웨어에도 마찬가지입니다. 디자인에서 가장 중요한 부분은 재설계입니다. 특히 프로그래밍 언어는 충분히 재설계되지 않습니다.

좋은 소프트웨어를 작성하려면 동시에 두 가지 상반되는 아이디어를 머릿속에 담고 있어야 합니다. 젊은 해커의 능력에 대한 순진한 믿음과 동시에 베테랑의 회의론이 필요합니다. 뇌의 한쪽으로는 얼마나 어렵겠어?라고 생각하면서 다른 쪽으로는 절대 안 될 거야라고 생각할 수 있어야 합니다.

요령은 여기에 실제 모순이 없다는 것을 깨닫는 것입니다. 당신은 두 가지 다른 것에 대해 낙관적이고 회의적이어야 합니다. 문제를 해결할 가능성에 대해서는 낙관적이어야 하지만, 지금까지 얻은 어떤 해결책의 가치에 대해서는 회의적이어야 합니다.

좋은 일을 하는 사람들은 종종 자신이 작업하는 것이 좋지 않다고 생각합니다. 다른 사람들은 그들이 한 일을 보고 경이로워하지만, 창작자는 걱정으로 가득합니다. 이 패턴은 우연이 아닙니다. 그 걱정이 그 작업을 좋게 만든 것입니다.

희망과 걱정의 균형을 유지할 수 있다면, 그것들은 두 다리가 자전거를 앞으로 나아가게 하는 것과 같은 방식으로 프로젝트를 추진할 것입니다. 두 주기 혁신 엔진의 첫 번째 단계에서는 문제를 해결할 수 있다는 자신감에 영감을 받아 어떤 문제에 대해 맹렬히 작업합니다. 두 번째 단계에서는 아침의 차가운 빛 속에서 자신이 한 일을 보고 모든 결함을 매우 명확하게 봅니다. 하지만 비판적인 정신이 희망을 압도하지 않는 한, 당신은 인정하건대 불완전한 시스템을 보고 '나머지 길을 가는 것이 얼마나 어렵겠어?'라고 생각하며 주기를 계속할 수 있을 것입니다.

두 힘의 균형을 유지하는 것은 까다롭습니다. 젊은 해커들에게는 낙관주의가 지배적입니다. 그들은 무언가를 만들어내고, 그것이 훌륭하다고 확신하며, 결코 개선하지 않습니다. 나이 든 해커들에게는 회의주의가 지배적이며, 야심 찬 프로젝트를 감히 맡으려 하지도 않습니다.

재설계 주기를 계속 유지하기 위해 할 수 있는 모든 것은 좋습니다. 산문은 만족할 때까지 계속해서 다시 쓸 수 있습니다. 하지만 소프트웨어는 일반적으로 충분히 재설계되지 않습니다. 산문에는 독자가 있지만, 소프트웨어에는 _사용자_가 있습니다. 작가가 에세이를 다시 쓴다고 해서 이전 버전을 읽었던 사람들이 새로 도입된 비호환성으로 인해 생각이 깨졌다고 불평할 가능성은 낮습니다.

사용자는 양날의 검입니다. 그들은 당신의 언어를 개선하는 데 도움을 줄 수 있지만, 개선을 방해할 수도 있습니다. 따라서 사용자를 신중하게 선택하고, 그 수를 천천히 늘리십시오. 사용자를 갖는 것은 최적화와 같습니다. 현명한 길은 그것을 지연시키는 것입니다. 또한, 일반적으로 당신은 언제든지 생각하는 것보다 더 많은 것을 변경할 수 있습니다. 변화를 도입하는 것은 반창고를 떼어내는 것과 같습니다. 고통은 느끼는 즉시 거의 기억이 됩니다.

모두가 위원회에 의해 설계된 언어를 갖는 것이 좋지 않다는 것을 알고 있습니다. 위원회는 나쁜 설계를 낳습니다. 하지만 저는 위원회의 가장 큰 위험은 재설계를 방해한다는 점이라고 생각합니다. 변경 사항을 도입하는 것이 너무 많은 작업이라 아무도 귀찮아하지 않습니다. 위원회가 결정한 것은 대부분의 구성원이 좋아하지 않더라도 그대로 유지되는 경향이 있습니다.

두 명으로 구성된 위원회조차도 재설계를 방해합니다. 이는 특히 두 명의 다른 사람이 작성한 소프트웨어 조각 간의 인터페이스에서 발생합니다. 인터페이스를 변경하려면 둘 다 동시에 변경하는 데 동의해야 합니다. 따라서 인터페이스는 전혀 변경되지 않는 경향이 있는데, 이는 어떤 시스템에서든 가장 임시적인 부분 중 하나인 경향이 있기 때문에 문제입니다.

여기서 한 가지 해결책은 인터페이스가 수직이 아닌 수평이 되도록 시스템을 설계하는 것입니다. 즉, 모듈이 항상 수직으로 쌓인 추상화 계층이 되도록 하는 것입니다. 그러면 인터페이스는 그들 중 하나에 의해 소유되는 경향이 있을 것입니다. 두 레벨 중 낮은 레벨은 상위 레벨이 작성된 언어가 될 것이고, 이 경우 낮은 레벨이 인터페이스를 소유할 것입니다. 또는 하위 레벨이 종속될 것이고, 이 경우 인터페이스는 상위 레벨에 의해 지시될 수 있습니다.

11 Lisp

이 모든 것이 의미하는 바는 새로운 Lisp에 대한 희망이 있다는 것입니다. Lisp를 포함하여 해커들이 원하는 것을 제공하는 어떤 언어에도 희망이 있습니다. 저는 우리가 Lisp의 낯섦 때문에 해커들이 등을 돌린다고 생각하는 실수를 저질렀을지도 모른다고 생각합니다. 이 위안이 되는 환상은 우리가 Lisp, 또는 적어도 Common Lisp의 진짜 문제, 즉 해커들이 하고 싶어 하는 일을 하는 데 형편없다는 것을 보지 못하게 막았을 수도 있습니다. 해커의 언어는 강력한 라이브러리와 해킹할 대상을 필요로 합니다. Common Lisp는 둘 다 가지고 있지 않습니다. 해커의 언어는 간결하고 해킹 가능해야 합니다. Common Lisp는 그렇지 않습니다.

좋은 소식은, 형편없는 것은 Lisp 자체가 아니라 Common Lisp라는 것입니다. 만약 우리가 진정한 해커의 언어인 새로운 Lisp를 개발할 수 있다면, 해커들은 그것을 사용할 것이라고 생각합니다. 그들은 일을 해내는 어떤 언어든 사용할 것입니다. 우리가 해야 할 일은 이 새로운 Lisp가 다른 언어보다 어떤 중요한 작업을 더 잘 수행하도록 하는 것입니다.

역사는 약간의 격려를 제공합니다. 시간이 지남에 따라, 연속적인 새로운 프로그래밍 언어들은 Lisp로부터 점점 더 많은 기능을 가져왔습니다. 당신이 만든 언어가 Lisp가 되기 전에 복사할 것이 더 이상 많이 남아 있지 않습니다. 최신 인기 언어인 Python은 중위 문법과 매크로가 없는 희석된 Lisp입니다. 새로운 Lisp는 이러한 진행 과정에서 자연스러운 단계가 될 것입니다.

저는 때때로 그것을 Python의 개선된 버전이라고 부르는 것이 좋은 마케팅 전략이 될 것이라고 생각합니다. 그것이 Lisp보다 더 멋지게 들립니다. 많은 사람들에게 Lisp는 괄호가 많은 느린 AI 언어입니다. Fritz Kunze의 공식 전기는 L-단어를 언급하는 것을 신중하게 피합니다. 하지만 제 생각에는 새로운 Lisp를 Lisp라고 부르는 것을 두려워해서는 안 됩니다. Lisp는 여전히 최고의 해커들, 예를 들어 6.001을 수강하고 이해했던 사람들 사이에서 많은 잠재적 존경을 받고 있습니다. 그리고 그들이 바로 당신이 사로잡아야 할 사용자들입니다.

"해커가 되는 법"에서 Eric Raymond는 Lisp를 라틴어나 그리스어와 같은 것으로 묘사합니다. 즉, 실제로 사용하지 않더라도 지적 훈련으로 배워야 할 언어라고 말합니다.

Lisp는 마침내 그것을 이해했을 때 얻게 될 심오한 깨달음의 경험 때문에 배울 가치가 있습니다. 그 경험은 Lisp 자체를 많이 사용하지 않더라도 남은 평생 동안 당신을 더 나은 프로그래머로 만들어 줄 것입니다.

만약 제가 Lisp를 몰랐다면, 이 글을 읽고 질문을 던졌을 것입니다. 저를 더 나은 프로그래머로 만들어 줄 언어라는 것이 어떤 의미라도 있다면, 그것은 프로그래밍에 더 좋은 언어라는 의미입니다. 그리고 그것이 Eric이 말하는 바의 실제 함의입니다.

그 아이디어가 여전히 떠돌아다니는 한, 저는 해커들이 새로운 Lisp에 대해 충분히 수용적일 것이라고 생각합니다. 비록 그것이 Lisp라고 불리더라도 말입니다. 하지만 이 Lisp는 1970년대의 고전적인 Lisp처럼 해커의 언어여야 합니다. 그것은 간결하고, 단순하며, 해킹 가능해야 합니다. 그리고 해커들이 지금 하고 싶어 하는 일을 할 수 있는 강력한 라이브러리를 가지고 있어야 합니다.

라이브러리 문제에 있어서는 Perl과 Python 같은 언어를 그들 자신의 게임에서 이길 여지가 있다고 생각합니다. 앞으로 몇 년 안에 작성되어야 할 많은 새로운 애플리케이션은 서버 기반 애플리케이션이 될 것입니다. 새로운 Lisp가 Perl만큼 좋은 문자열 라이브러리를 가지지 못할 이유가 없으며, 이 새로운 Lisp가 서버 기반 애플리케이션을 위한 강력한 라이브러리도 가지고 있다면 매우 인기가 있을 수 있습니다. 진정한 해커들은 몇 번의 라이브러리 호출로 어려운 문제를 해결할 수 있게 해주는 새로운 도구를 외면하지 않을 것입니다. 기억하십시오, 해커들은 게으릅니다.

서버 기반 애플리케이션을 위한 핵심 언어 지원을 갖는 것은 훨씬 더 큰 승리가 될 수 있습니다. 예를 들어, 다중 사용자 프로그램에 대한 명시적 지원이나 타입 태그 수준에서의 데이터 소유권 같은 것입니다.

서버 기반 애플리케이션은 또한 이 새로운 Lisp가 무엇을 해킹하는 데 사용될 것인가에 대한 답을 제공합니다. Unix의 스크립팅 언어로서 Lisp를 더 좋게 만드는 것은 나쁘지 않을 것입니다. (더 나쁘게 만들기는 어려울 것입니다.) 하지만 저는 기존 언어를 이기기 더 쉬운 분야가 있다고 생각합니다. Tcl의 모델을 따르고, 서버 기반 애플리케이션을 지원하는 완전한 시스템과 함께 Lisp를 제공하는 것이 더 나을 수 있다고 생각합니다. Lisp는 서버 기반 애플리케이션에 자연스럽게 잘 맞습니다. UI가 단순히 일련의 웹 페이지일 때 어휘적 클로저는 서브루틴의 효과를 얻는 방법을 제공합니다. S-표현식은 HTML에 잘 매핑되며, 매크로는 HTML을 생성하는 데 좋습니다. 서버 기반 애플리케이션을 작성하기 위한 더 나은 도구가 필요하고, 새로운 Lisp가 필요하며, 이 둘은 매우 잘 어울릴 것입니다.

12 꿈의 언어

요약하자면, 해커의 꿈의 언어를 묘사해 봅시다. 꿈의 언어는 아름답고, 깔끔하며, 간결합니다. 빠르게 시작되는 대화형 최상위 레벨을 가지고 있습니다. 매우 적은 코드로 일반적인 문제를 해결하는 프로그램을 작성할 수 있습니다. 당신이 작성하는 어떤 프로그램의 거의 모든 코드는 당신의 애플리케이션에 특화된 코드입니다. 다른 모든 것은 당신을 위해 이미 처리되어 있습니다.

언어의 문법은 지나치게 간결합니다. 불필요한 문자를 입력할 필요가 없으며, 심지어 시프트 키를 많이 사용할 필요도 없습니다.

큰 추상화를 사용하여 프로그램의 첫 버전을 매우 빠르게 작성할 수 있습니다. 나중에 최적화하고 싶을 때, 어디에 집중해야 할지 알려주는 정말 좋은 프로파일러가 있습니다. 필요한 경우 인라인 바이트 코드를 작성하여 내부 루프를 눈부시게 빠르게 만들 수 있습니다.

배울 만한 좋은 예시가 많고, 언어는 직관적이어서 몇 분 만에 예시를 통해 사용법을 배울 수 있습니다. 설명서를 많이 찾아볼 필요가 없습니다. 설명서는 얇고, 경고나 단서가 거의 없습니다.

이 언어는 작은 핵심과 핵심 언어만큼 신중하게 설계된 강력하고 고도로 직교적인 라이브러리를 가지고 있습니다. 라이브러리들은 모두 잘 작동하며, 언어의 모든 것이 정교한 카메라의 부품처럼 잘 들어맞습니다. 아무것도 더 이상 사용되지 않거나 호환성을 위해 유지되지 않습니다. 모든 라이브러리의 소스 코드는 쉽게 구할 수 있습니다. 운영체제 및 다른 언어로 작성된 애플리케이션과 쉽게 통신할 수 있습니다.

이 언어는 계층적으로 구축됩니다. 고수준 추상화는 하위 수준 추상화로부터 매우 투명한 방식으로 구축되며, 원한다면 하위 수준 추상화를 다룰 수 있습니다.

절대적으로 숨겨져야 하는 것 외에는 아무것도 숨겨져 있지 않습니다. 이 언어는 당신에게 무엇을 해야 할지 지시하는 방식이 아니라, 당신의 작업을 절약해 주는 방식으로만 추상화를 제공합니다. 사실, 이 언어는 당신이 그 설계에 동등하게 참여하도록 장려합니다. 당신은 문법을 포함하여 모든 것을 변경할 수 있으며, 당신이 작성하는 모든 것은 가능한 한 미리 정의된 것과 동일한 지위를 가집니다.

주석

[1] 현대적 개념에 매우 가까운 매크로는 Lisp 1.5가 출시된 지 2년 후인 1964년에 Timothy Hart에 의해 제안되었습니다. 초기에 부족했던 것은 변수 캡처와 다중 평가를 피하는 방법이었으며, Hart의 예시는 둘 다에 해당합니다.

[2] 신경외과 의사 Frank Vertosick은 _When the Air Hits Your Brain_에서 수석 레지던트 Gary가 외과 의사와 내과 의사("벼룩")의 차이에 대해 이야기하는 대화를 회상합니다.

Gary와 저는 큰 피자를 시켜 열린 부스를 찾았습니다. 수석 레지던트가 담배에 불을 붙였습니다. "저 빌어먹을 벼룩들을 봐, 평생 한 번 볼까 말까 한 질병에 대해 떠들어대고 있잖아. 벼룩들의 문제점은 기이한 것만 좋아한다는 거야. 그들은 자신들의 주된 업무를 싫어해. 그게 우리와 빌어먹을 벼룩들의 차이야. 봐, 우리는 크고 즙이 많은 요추 디스크 탈출증을 좋아하지만, 그들은 고혈압을 싫어해...."

요추 디스크 탈출증을 즙이 많다고 생각하기는 어렵습니다(말 그대로가 아니라면). 하지만 저는 그들이 무엇을 의미하는지 아는 것 같습니다. 저는 종종 '즙이 많은' 버그를 추적해야 했습니다. 프로그래머가 아닌 사람은 버그에서 즐거움을 찾을 수 있다는 것을 상상하기 어려울 것입니다. 분명 모든 것이 잘 작동하는 것이 더 좋습니다. 어떤 면에서는 그렇습니다. 하지만 특정 종류의 버그를 찾아내는 데는 부인할 수 없는 냉혹한 만족감이 있습니다.