Perl은 왜 태어났는가 — 1987년 12월 18일, awk와 C 사이

Larry Wall이 Perl 1.0을 공개했을 때, 그는 언어 설계자로 알려져 있지 않았다. 알려져 있던 것은 rn과 patch라는 두 개의 도구였다. awk로는 부족하고 C로는 과한 틈에, 언어학자가 언어를 만들면 어떻게 되는가. 그리고 Perl 4 시점에 이미, 훗날 Perl 6을 필요하게 만들 두 개의 제약이 보이고 있었다.

September 18, 2026

perlhistorylanguage-designlarry-wallprogramming-languages

1987년 12월 18일

Larry Wall이 Perl 1.0을 Usenet의 comp.sources.unix에 투고했다. 이것이 공식 생일이다.

Perl 커뮤니티는 지금도 이 날을 생일로 취급한다. 2007년의 Perl 5.10은 20주년에 맞춰 12월 18일에 릴리스되었다. 우연이 아니라, 의도해서 그 날에 냈다.

이 날짜에서 시작하는 것은, Perl이 「언제 태어났는가」가 분명한 드문 언어이기 때문이다. 많은 언어는 사내 프로젝트의 시작이나 논문이나 최초의 커밋 등, 기점을 골라야 한다. Perl에는 투고된 날이 있다.

Larry Wall은 무엇의 사람이었나

Perl 1.0을 낸 시점에, Larry Wall은 언어 설계자로 알려져 있지 않았다. 알려져 있던 것은 그가 만든 두 개의 도구였다.

rn(1984) — Usenet 뉴스리더
patch(1985) — diff를 적용하는 프로그램

두 번째가 중요하다. patch는 지금도 그대로의 이름으로 우리 손에 있다. git apply 아래에도, 배포판의 빌드 스크립트 안에도 있다. 40년 전의 도구가 이름도 역할도 바꾸지 않고 살아남아 있다.

그리고 patch가 푼 문제는 「남의 코드에 내 변경을 전달한다」는 것이었다.

이 발상은 Perl의 후년의 문화와 일직선으로 이어진다. CPAN, 모듈, 남이 쓴 것을 조합해 일을 끝내는 문화. Larry Wall은 언어를 만들기 전부터, 「남의 코드와 어떻게 지낼 것인가」의 도구를 만들고 있었다.

메운 틈

Perl이 태어난 자리는 기존 도구의 틈이었다. 구체적으로는, awk와 sed와 셸로는 부족하고, C로는 과한 영역이다.

도구	할 수 있는 것	부족했던 것
셸	프로세스의 접착	복잡한 데이터 구조, 제대로 된 계산
sed	행 단위 치환	분기, 서브루틴
awk	필드 처리, 연상 배열	파일 조작, 프로세스 제어, 정규표현식의 표현력
C	무엇이든	쓰는 양이 많다, 컴파일이 필요하다

Larry Wall은 보고서를 생성하는 일에서 이 틈에 반복해서 빠지고 있었다. awk로 쓰기 시작해 도중에 부족해져 C로 다시 쓴다. 혹은 awk와 셸과 sed를 파이프로 이은 괴물을 만든다.

Perl의 정식 명칭 Practical Extraction and Report Language(실용적 추출 리포트 언어)는, 이 유래를 그대로 나타내고 있다.

다만 Perl 문화답게, 공인된 역두문자어도 있다.

Pathologically Eclectic Rubbish Lister (병적으로 절충적인 잡동사니 출력기)

이 둘이 모두 공식이라는 시점에서, 이 언어의 성격은 대체로 알 수 있다.

언어학자가 언어를 만들면

Larry Wall은 대학원에서 언어학을 전공했다. 이것은 Perl의 설계에 구체적인 형태로 남았다.

문맥(context)

같은 식이, 놓인 자리에 따라 다른 의미가 된다.

my @array = (1, 2, 3);
my $count = @array;      # 3  — 스칼라 문맥에서는 요소 수
my ($first) = @array;    # 1  — 리스트 문맥에서는 첫 번째

이것은 자연 언어의 발상이다. 같은 말이, 문장 속의 위치에 따라 의미를 바꾼다. 프로그래밍 언어의 설계로서는 이단이며, 「같은 것이 다른 의미가 된다면 그건 다른 것이겠지」가 다수파의 입장이다.

시길(sigil)

$ @ %는 품사 표지처럼 작동한다. 단수 · 복수 · 대응표. 변수 이름을 보는 것만으로, 그것이 무엇인지 알 수 있다.

어순의 자유도

print "done" if $ok;

후치 if, unless, until은 영어 종속절의 어순을 그대로 들여왔다. 「done을 출력한다, 만약 ok라면」. 쓰는 순서를 생각하는 순서에 맞출 수 있다.

이 설계를 어떻게 평가할 것인가

Perl의 최대의 개성이자, 최대의 비판 대상이기도 했다.

옹호하는 쪽의 논리는 이렇다. 프로그램은 사람이 읽고 쓰는 것이고, 사람의 언어가 그렇게 되어 있다면 그쪽으로 붙이는 편이 자연스럽게 쓸 수 있다.

비판하는 쪽의 논리도 분명하다. 문맥 의존은 예측을 어렵게 한다. 코드를 읽으며 「여기는 무슨 문맥인가」를 따라가야 하는 것은 인지적 부하다.

그리고 이 연재의 관점에서는 하나 더 중요한 것이 있다. 이 설계 판단의 일부가, 훗날 Perl 6이 바꾸려 한 것이 된다. 시길이 문맥에 따라 바뀌는 규칙은 Raku에서 반대가 되었다. 그것은 4화에서 다룬다.

세 가지 원칙

Perl의 설계 철학으로 초기부터 언어화되어 있던 것이 셋 있다. 이 셋은 그대로 Raku에 계승된다.

TMTOWTDI

There’s More Than One Way To Do It — 방법은 하나가 아니다.

Python의 “There should be one obvious way to do it”과 정면으로 대립하는 입장이며, 두 언어의 문화적 분기점이 되었다.

Raku는 이것을 더 밀고 나간다. 같은 조작에 여러 철자를 마련하고, for와 map이 둘 다 있고, if는 전치로도 후치로도 쓸 수 있다.

쉬운 것은 쉽게, 어려운 것은 가능하게

Easy things should be easy, and hard things should be possible.

언어의 복잡함을, 쓰는 쪽이 필요해졌을 때만 지불한다는 사고방식이다.

Raku의 「타입 표기는 생략할 수 있지만, 쓰면 작동한다」는 점진적 타이핑은 이 원칙의 직계에 해당한다. 쓰지 않아도 돌아간다. 쓰면 엄격해진다.

언어는 자연 언어처럼

위에 쓴 대로.

Perl 2에서 Perl 4로

판	시기	내용
Perl 1.0	1987-12-18	최초 공개
Perl 2	1988	정규표현식 엔진의 강화
Perl 3	1989	바이너리 데이터의 취급. 라이선스를 GPL로
Perl 4	1991	실질적으로는 「낙타 책에 맞춘 판」

Perl 4의 위치는 조금 특이하다. 언어의 큰 변경이라기보다, 서적을 위한 구획이었다.

1991년, O’Reilly에서 Larry Wall과 Randal L. Schwartz에 의한 Programming Perl이 출판되었다. 표지에 낙타가 그려져 있어 「낙타 책」이라 불린다. 그 내용에 대응하는 판으로 Perl 4가 놓였고, 4.036(1993)에서 갱신이 멈췄다.

그리고 낙타는 이후 Perl의 상징이 되었다.

여기에 하나, 나중에 작용하는 사실이 있다. 낙타는 O’Reilly 서적 표지의 동물이며, 상표도 O’Reilly가 가지고 있다. Perl의 공식 로고로 자유롭게 쓸 수 있는 것이 아니다.

그래서 Perl 6은 처음부터 다른 마스코트를 가지고 있었다. 나비인 Camelia다. camel에서 한 글자 옮긴 이름으로, 연속성을 보이면서 상표 문제를 피하고 있다. 개명해도 이 마스코트는 바뀌지 않았다. 10화에서 돌아온다.

Perl 4가 안고 있던 두 개의 제약

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

Perl 4 시점에 훗날 Perl 6을 필요하게 만드는 것과 같은 종류의 문제가, 이미 한 단계 작은 규모로 일어나고 있었다. 제약은 둘이었다.

1. 데이터 구조가 중첩되지 않는다

레퍼런스가 없기 때문에, 배열의 배열이나 해시의 해시를 직접 쓸 수 없었다. 다차원을 흉내 내는 방법(키를 이어 붙이는 $a{$x,$y})은 있었지만, 진짜가 아니다.

즉 Perl 4로 표현할 수 있는 데이터의 형태에 천장이 있었다.

2. 네임스페이스가 전역밖에 없다

package가 없고, 모듈이라는 단위가 없다. 큰 프로그램을 분할해 남과 공유하는 수단이 약했다.

이 둘이 어떻게 풀렸는가

답은 「Perl 4를 개량한다」가 아니었다. 1994년, 인터프리터가 처음부터 다시 쓰였다. 그것이 Perl 5다.

여기에 형(型)이 있다.

언어의 근본적인 제약은, 기능을 더해도 풀리지 않는다. 구현을 다시 만들게 된다.

Perl 5는 그것을 해서 성공했다. 호환성도 대체로 유지되었다.

그리고 2000년, 같은 판단이 한 번 더 내려진다. 이번에는 Perl 5의 근본적인 제약 — 시길의 규칙, bless 기반의 OO, @_에 의한 인자 전달 — 을 풀기 위해, 또 처음부터 다시 만들려고 했다.

달랐던 것은, 이번에는 호환성을 유지할 수 없었다는 점이다. 그리고 15년이 걸렸고, 마지막에는 이름이 바뀌었다.

그 이야기를, 이 연재에서 앞으로 써 나간다.

다음 회(2화): Perl 5와 CPAN이 만든 것. 1994년의 전면 재작성으로 무엇이 들어왔는가. 그리고 1995년, 당시 어느 언어에도 존재하지 않았던 것이 만들어진다.

← Back to Perl과 Raku의 계보