Perl はなぜ生まれたか — 1987 年 12 月 18 日、awk と C のあいだ

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 は言語設計者として知られていたわけではない。 知られていたのは、彼が作った 2 つのツールだった。

• rn（1984）— Usenet のニュースリーダ
• patch（1985）— diff を当てるプログラム

2 つ目が重要だ。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 （病的に折衷的なガラクタ出力器）

この 2 つが両方とも公式であるという時点で、この言語の性格はだいたい分かる。

言語学者が言語を作ると

Larry Wall は大学院で言語学を専攻している。 これは Perl の設計に、具体的な形で残った。

文脈（context）

同じ式が、置かれた場所によって違う意味になる。

my @array = (1, 2, 3);
my $count = @array;      # 3  — スカラ文脈では要素数
my ($first) = @array;    # 1  — リスト文脈では先頭

これは自然言語の発想だ。同じ語が、文の中の位置によって意味を変える。 プログラミング言語の設計としては異端で、 「同じものが違う意味になるなら、それは違うものだろう」というのが多数派の立場である。

シジル

$ @ % は品詞標識のように働く。単数・複数・対応表。 変数名を見ただけで、それが何であるかが分かる。

語順の自由度

print "done" if $ok;

後置の if、unless、until は、英語の従属節の語順をそのまま持ち込んでいる。 「done と出力する、もし ok なら」。書く順番が、考える順番に合わせられる。

この設計をどう評価するか

Perl の最大の個性であり、最大の批判対象でもあった。

擁護する側の言い分はこうだ。プログラムは人が読み書きするものであり、 人の言語がそうなっているなら、そちらに寄せた方が自然に書ける。

批判する側の言い分もはっきりしている。文脈依存は予測を難しくする。 コードを読んで「ここは何文脈だ」を追わなければならないのは、認知的な負荷である。

そしてこの連載の観点からは、もう 1 つ重要なことがある。 この設計判断の一部が、後に Perl 6 が変えようとしたものになる。 シジルが文脈で変わる規則は、Raku では逆になった。それは第 4 話で扱う。

3 つの原則

Perl の設計哲学として最初期から言語化されていたものが 3 つある。 この 3 つは、そっくりそのまま Raku に受け継がれる。

TMTOWTDI

There’s More Than One Way To Do It — やり方は 1 つではない。

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 のシンボルになった。

ここに 1 つ、後で効いてくる事実がある。 ラクダは O’Reilly の書籍表紙の動物であり、商標も O’Reilly が持つ。 Perl の公式ロゴとして自由に使えるものではない。

だから Perl 6 は、最初から別のマスコットを持っていた。 蝶の Camelia である。camel から一文字ずらした名前で、 連続性を示しつつ、商標の問題を回避している。 改名してもこのマスコットは変わらなかった。 第 10 話で戻ってくる。

Perl 4 が抱えていた 2 つの制約

ここが、この回でいちばん書きたかったところだ。

Perl 4 の時点で、後に Perl 6 を必要とさせるものと同じ種類の問題が、 既に 1 つ小さいスケールで起きていた。制約は 2 つあった。

1. データ構造がネストできない

リファレンスが無いため、配列の配列やハッシュのハッシュが直接書けなかった。 多次元を模す仕組み（$a{$x,$y} のようにキーを連結する）はあったが、本物ではない。

つまり Perl 4 で表現できるデータの形に、天井があった。

2. 名前空間がグローバルしかない

package が無く、モジュールという単位が無い。 大きなプログラムを分割し、他人と共有する手段が弱かった。

この 2 つがどう解かれたか

答えは「Perl 4 を改良する」ではなかった。 1994 年、インタプリタが一から書き直された。それが Perl 5 である。

ここに型がある。

言語の根本的な制約は、機能を足しても解けない。実装を作り直すことになる。

Perl 5 はそれをやって成功した。互換性もおおむね保たれた。

そして 2000 年、同じ判断がもう一度なされる。 今度は Perl 5 の根本的な制約 — シジルの規則、bless ベースの OO、@_ による引数渡し — を解くために、また一から作り直そうとした。

違ったのは、今度は互換性が保てなかったことだ。 そして 15 年かかり、最後には名前が変わった。

その話を、この連載でこれから書いていく。

---

次回（第 2 話）: Perl 5 と CPAN が作ったもの。 1994 年の全面書き直しで何が入ったのか。そして 1995 年、 当時どの言語にも存在しなかったものが作られる。