Perl 5와 CPAN이 만든 것 — 너무 성공한 언어는 바꿀 수 없게 된다

지난번에는 Perl 4가 두 개의 제약을 안고 있던 데까지 썼다. 데이터 구조가 중첩되지 않는 것과, 네임스페이스가 전역밖에 없는 것. 그리고 그 푸는 방식이 「개량」이 아니라 「처음부터 다시 쓰기」였다는 것도.

이번에는 그 재작성과, 그 이듬해에 일어난 일의 이야기다.

1994년 10월 17일 — Perl 5.000

인터프리터가 전면적으로 다시 쓰였다. 문법의 추가가 아니라 구현의 재구축이며, 여기서 Perl은 다른 언어가 되었다고 해도 좋다.

들어온 것은 크게 넷이다.

레퍼런스

\로 스칼라 · 배열 · 해시 · 서브루틴에 대한 참조를 얻을 수 있게 되었다.

my $data = {
    users => [
        { name => 'alice', tags => ['admin'] },
        { name => 'bob',   tags => [] },
    ],
};

Perl 4에서는 쓸 수 없던 것이다. 표현할 수 있는 데이터의 형태에서 천장이 사라졌다.

패키지와 모듈

package에 의한 네임스페이스와, use / require에 의한 로드.

이것이 의미하는 것은, 파일 단위로 남의 코드를 가져올 수 있게 되었다는 것이다. 그리고 이것은 이 회의 후반에서 다루는 CPAN이 성립하기 위한 전제 조건 그 자체다.

객체 지향 — bless

Perl 5의 OO는 이미 있는 구조의 조합으로 실현되었다.

• 객체 = 레퍼런스(대개는 해시 레퍼런스)에 bless로 클래스 이름을 붙인 것
• 클래스 = 패키지
• 메서드 = 그 패키지의 서브루틴
• 상속 = @ISA 배열

package Point;
sub new {
    my ($class, %args) = @_;
    my $self = { x => $args{x} // 0, y => $args{y} // 0 };
    return bless $self, $class;
}
sub to_string { my $self = shift; "($self->{x}, $self->{y})" }

새로운 기구를 거의 더하지 않았다. 「기존 부품으로 OO를 만들 수 있다」는 증명이며, Perl 5의 설계의 훌륭함이기도 하다.

그리고 동시에, 「OO가 언어에 내장되어 있지 않다」는 후년의 비판의 근거도 되었다. new는 관습이지 언어의 기능이 아니다. 속성의 선언 방법도 정해져 있지 않다. 그래서 유파가 난립했다.

Perl 6이 class / has / method를 언어에 내장한 것은, 여기에 대한 응답이다.

렉시컬 스코프 — my

my에 의한 어휘적 변수. 그때까지의 local(동적 스코프)과 달리, 블록으로 닫히는 변수를 쓸 수 있게 되었다.

use strict와 조합됨으로써, Perl은 「큰 프로그램을 쓸 수 있는 언어」가 되었다.

1995년 10월 26일 — CPAN

Comprehensive Perl Archive Network. Perl의 모듈을 집적 · 배포하는 아카이브망이다.

Perl의 역사에서, 아마 이것이 가장 영향이 큰 발명이다. 그리고 말해 두고 싶은 것은, 당시 이에 상당하는 것이 어느 언어에도 없었다는 점이다.

구조	시작
CPAN	1995
PyPI	2003
RubyGems	2004
npm	2010
Cargo(crates.io)	2014

CPAN은 8년간, 달리 비교 대상이 존재하지 않는 상태였다.

CPAN이 발명한 것

「모듈을 두는 곳」만이라면 당시에도 FTP 사이트는 있었다. CPAN이 달랐던 것은, 주변의 구조를 처음부터 가지고 있었다는 점이다.

1. PAUSE — 저자 등록과 네임스페이스 관리

누가 어떤 이름의 모듈을 낼 수 있는가를 관리한다. 이름의 충돌을, 기술이 아니라 운영으로 풀었다.

2. 메타데이터의 표준화

의존 관계, 라이선스, 전제가 되는 Perl의 버전. 이것들을 기계 가독 형태로 가짐으로써, 인스톨러가 자동으로 의존을 해결할 수 있다.

3. 미러망

전 세계의 미러에 의한 분산 배포. 1995년의 회선 사정에서는 절실한 기능이었다.

4. CPAN Testers

이것이 가장 특이하다. 다수의 플랫폼 · 다수의 Perl 버전에서 자동으로 테스트를 돌리고, 그 결과를 공개하는 구조다.

모듈의 저자는, 자신이 가지고 있지 않은 OS · 가지고 있지 않은 버전에서의 결과를 볼 수 있다. 「내 환경에서는 돌아간다」를, 제도로서 넘어서는 구조를 1990년대에 만들고 있었다.

현대의 CI에 상당하는 것이, 패키지 저장소의 기능으로 존재하고 있었다. 그리고 흥미롭게도, 후발 패키지 매니저는 이것을 계승하지 않았다. npm에도 RubyGems에도, 이에 상당하는 공식 구조는 없다.

CPAN에 대해 쓸 때, 모듈 수로 이야기되는 경우가 많다. 그러나 발명으로서 중요한 것은 수가 아니라, 이 네 가지 구조를 처음부터 갖추고 있었다는 것이라고 생각한다.

인터넷의 덕테이프

1990년대 후반, Perl은 웹의 주요 언어가 되었다. 이유는 셋이다.

1. CGI와의 궁합. 표준 입출력과 환경 변수로 완결되는 사양은, 텍스트 처리 언어에게 이상적이었다.

2. 문자열 처리. HTTP도 HTML도 텍스트다. Perl의 정규표현식이 그대로 무기가 되었다.

3. mod_perl(1996, Doug MacEachern). Apache에 Perl 인터프리터를 심어, 프로세스 기동의 비용을 없앴다. 실질적으로 최초기의 애플리케이션 서버다.

이 시기의 Perl은 「인터넷의 덕테이프(duct tape of the Internet)」라고 불렸다. Amazon도, 초기의 Slashdot도, 셀 수 없는 사이트가 Perl로 쓰였다.

Perl 5.6(2000년 3월)

버전 번호의 표기가 5.005 형식에서 5.6.0 형식으로 바뀌었다. 내용 면에서는:

• Unicode의 초기 지원
• **our**에 의한 패키지 변수의 선언
• 64bit 대응, 큰 파일의 취급

그리고 이 4개월 후에, Perl 6이 발표된다.

여기는 오해되기 쉬우므로 강조해 두고 싶다. Perl 6은, Perl이 쇠퇴했기 때문에 시작된 것이 아니다. Perl이 웹을 지배하고, CPAN이 유일무이한 자산이며, 절정에 있던 시기에 구상되었다.

너무 성공한 언어

여기가 이 회에서 가장 쓰고 싶었던 부분이다.

Perl 5의 설계 판단 중, 훗날 「바꾸고 싶지만 바꿀 수 없는」 것이 된 것이 있다.

판단	무엇이 문제가 되었는가
시길이 문맥에 따라 바뀐다(@a의 요소가 $a[0])	초학자가 가장 걸려 넘어지는 점
OO가 bless 기반	표준적인 쓰는 법이 정해지지 않아 유파가 난립
함수의 인자가 @_	시그니처를 쓸 수 없다
문맥(스칼라/리스트)이 암묵적	동작의 예측이 어렵다

이것들은 Perl 5에서는 바꿀 수 없었다. 하위 호환성 때문이다.

그리고 하위 호환성이 무거웠던 것은, 바로 CPAN이 있었기 때문이다.

• 수만 개의 모듈이 돌아가고 있다
• 전 세계의 프로덕션 환경이 돌아가고 있다
• 30년 분량의 자산이 있다

Perl 5의 최대의 자산이, Perl 5를 바꿀 수 없게 만들고 있었다.

여기에, 이 연재를 통해 몇 번이고 나오는 형(型)이 있다.

성공한 언어는, 그 성공의 형태에 고정된다. 자산이 클수록, 근본적인 변경의 비용은 올라간다.

Perl 4 때는, 자산이 아직 작았으므로 다시 쓸 수 있었다. 호환성도 대체로 유지할 수 있었다. Perl 5 때는, 그것이 불가능했다.

그래서 2000년의 판단은 이렇게 된다.

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

이것이 Perl 6의 출발점이다. 그리고 「다른 언어인데 Perl 6이라는 이름을 붙였다」는 것이, 19년 후에 이름을 바꾸는 이유가 된다.

그 19년의 입구를, 다음 회부터 본다.

---

다음 회(3화): 2000년, Perl 6이 시작되었다. Perl 5 Porters의 모임에서 깨진 머그컵, State of the Onion에서의 발표, 그리고 언어 설계를 공모했더니 무슨 일이 일어났는가 — 361건의 RFC 이야기.