2000년, Perl 6이 시작되었다 — 언어 설계를 공모했더니 361건이 모였다

지난번의 결론은 이랬다.

근본적으로 바꾸고 싶다. 그러나 Perl 5는 바꿀 수 없다. 그렇다면, 다른 언어를 만들 수밖에 없다.

이번에는, 그 「다른 언어를 만든다」는 판단이 실제로 내려진 날의 이야기다.

깨진 머그컵

2000년 7월, Perl 5 Porters(개발자 메일링 리스트)의 모임에서의 일이다.

Jon Orwant — 당시 The Perl Journal의 편집자이자 O’Reilly 쪽 인물 — 이, 논의의 정체에 견디다 못해 커피 머그를 벽에 던졌다고 전해진다.

「이대로는 Perl은 죽는다. 무언가 극적인 일을 해야 한다」

이 자리에서 Perl 6을 시작한다는 방향이 정해졌다, 는 것이 전해 내려오는 이야기다.

여기는 「전해진다」라고 쓴다. 이 일화는 널리 이야기되지만, 머그의 개수도, 정확한 발언도, 자료에 따라 다르다. 일차 정보에 가까운 것은 당사자의 후년의 인터뷰나 강연이며, 그 자리의 회의록이 있는 것은 아니다.

다만, 이 이야기가 반복해서 이야기되는 이유는 알 수 있다. 기술적인 논의가 막혔을 때, 그것을 움직인 것이 기술적인 논의가 아니었다는 구도가 선명하기 때문이다.

2000년 7월 19일 — 발표

Larry Wall이 The Perl Conference 4.0(TPC4, O’Reilly 주최)의 연례 강연 「State of the Onion」에서 Perl 6을 발표했다.

발표의 골자는 기술적인 내용이 아니었다. 이랬다.

Perl 6은, 커뮤니티가 설계한다.

2000년으로서는 상당히 급진적인 선언이다.

당시의 주요 언어는 어느 것이나 설계자나, 소수의 위원회나, 기업이 정하고 있었다. 「언어의 설계를 공개 프로세스에 개방한다」는 시도에는 전례가 거의 없었다.

그리고 Perl에는 그것을 할 이유가 있었다. Perl 5의 문제점은, Larry Wall보다 쓰고 있는 사람 쪽이 더 잘 알고 있을 터이기 때문이다. 매일 그것에 걸려 넘어지는 사람이, 전 세계에 있다.

RFC — 361건

발표와 동시에 **RFC(Request For Comments)**의 모집이 시작되었다. 누구나 「Perl 6은 이래야 한다」는 제안을 써서 투고할 수 있다.

• 기간: 2000년 8월~9월경
• 제출 수: 361건
• 내용: 문법의 세부부터, 타입 시스템, OO의 쇄신, 연산자의 추가까지

361이라는 수는, 이 시도가 동원으로서는 성공했다는 것을 보여준다. 사람은 모였다. 썼다.

공모가 돌려준 것

그리고 361건을 늘어놓았을 때, 알게 된 것이 있다.

커뮤니티는 「무엇이 싫은가」는 정확히 말할 수 있다. 그러나 「전체로서 어때야 하는가」는 말할 수 없다.

구체적으로는, 세 가지 형태로 나타났다.

1. 제안끼리 모순된다

어떤 RFC가 「이 구문을 이렇게 바꿔야 한다」고 말하고, 다른 RFC가 같은 구문에 대해 반대의 변경을 요구한다. 어느 쪽이나, 쓴 사람의 문맥에서는 옳다.

2. 국소 최적의 집합일 뿐, 일관된 언어가 되지는 않는다

361건은 각각, 하나의 아픔에 대한 하나의 처방이었다. 전부 더해도 언어가 되지는 않는다. 언어는 기능의 집합이 아니라, 기능끼리의 관계가 일관되어 있는 것이기 때문이다.

3. 「더하고 싶다」는 많고, 「덜고 싶다」는 적다

이것은 공모라는 형식 자체가 가진 편향이라고 생각한다.

사람은, 자신이 곤란했던 것에 대해서는 쓴다. 자신이 쓰지 않는 기능이 존재한다는 것에 대해서는, 굳이 쓰지 않는다.

결과적으로, 제안의 총합은 반드시 언어를 크게 만드는 방향으로 작용한다. Perl 5의 문제의 일부는 「너무 크다」는 것이었는데도 말이다.

Larry Wall이 무엇을 했는가

여기가 이 회에서 가장 중요한 부분이다.

Larry Wall은, 361건을 그대로 채용하는 길을 택하지 않았다. 그렇다고 무시한 것도 아니다. 전부를 읽고 소화해, 자신의 책임으로 다시 설계했다.

그 출력이 Apocalypse(묵시록)라 불리는 일련의 설계 문서다. 번호는 『Programming Perl』(낙타 책)의 장에 대응하고 있어, 「낙타 책의 제N장에 해당하는 부분을, Perl 6에서는 어떻게 할 것인가」라는 구성으로 되어 있다. 그 체계에 대해서는 7화에서 다룬다.

중요한 것은, RFC의 역할이 사후적으로 바뀌었다는 점이다.

당초의 위치	실제로 한 역할
Perl 6의 설계안	Perl 5의 아픔의 목록
커뮤니티가 정한다	커뮤니티가 문제를 제출하고, 설계자가 푼다

그리고 이것은 실패가 아니다. 361건의 RFC는, 문제의 목록으로서는 지극히 유용했다. Larry Wall 혼자서는, 전 세계 사람이 Perl 5의 어디에서 걸려 넘어지는지를 망라할 수 없다.

즉, 이렇게 말할 수 있다.

공모가 돌려주는 것은, 해답이 아니라 문제다. 그리고 그것은, 공모로밖에 모을 수 없는 것이다.

현대의 Rust RFC나 Python PEP와 비교하면, 차이가 분명해진다. 그것들은 기존 언어에 대한 개별적인 변경을 다루고, 결정권자가 있는 프로세스다. Perl 6의 RFC 모집은, 백지의 언어에 대해, 결정권의 소재도 모호한 채로 이루어졌다. 모이는 것의 성질이 다른 것은, 당연하다면 당연했다.

2000년의 예상과, 실제

발표 시점에 Perl 6이 어떻게 예상되고 있었는지를 적어 둔다.

2000년의 예상	실제
몇 년 안에 나온다	최초의 안정판까지 15년(2015-12-25)
Perl 5의 후계	호환되지 않는 별개의 언어로
Perl 5는 6으로 대체된다	Perl 5는 독자적으로 진화를 계속해, 2026년에도 현역
이름은 Perl 6	2019년에 Raku로 개명

이 네 줄이, 이 연재의 전부라고 해도 좋다. 남은 9화는, 이 네 줄 각각이 「왜 그렇게 되었는가」를 다룬다.

왜 15년이 걸렸는가 (예고)

「15년」이라는 숫자는, 태만이나 혼란의 증거로 인용되는 일이 많다. 이 연재에서는 그 독법을 취하지 않는다. 스코프의 문제로 다룬다.

이유는 적어도 넷이 있고, 각각 다른 회가 된다.

1. 설계가 너무 웅대했다(4화) — grammar, MOP, 병행 모델, 점진적 타이핑을 전부 넣었다
2. 구현 기반의 내기를 빗맞혔다(6화) — Parrot에 오래 투자했고, 최종적으로 쓰이지 않았다
3. 사양이 계속 움직였다(5·7화) — 구현이 사양을 따라잡으면 사양이 움직이는 왕복이 길었다
4. 전임 담당자가 얇았다 — 주요 인물의 이탈이 곧바로 속도에 영향했다

다음 회는 우선 첫 번째를 본다. Perl 6이 바꾸려 한 것을 늘어놓으면, 어느 것이나 언어 하나 분량의 일이었다는 이야기다.

---

다음 회(4화): 무엇을 바꾸려 했는가. 시길 불변성, grammar, 다중 디스패치, 메타 연산자, Junction, 그리고 유리수. 0.1 + 0.2 == 0.3이 True가 되는 언어의 이야기를 한다.