Perlの自滅 — 過剰な自由がもたらした言語の終焉

われわれは技術の墓場において、特定の死体に対してのみ異常な関心を抱く。それは単に死んだからではなく、その死に方が — あまりにも — 示唆的だからである。Perlという言語の衰退は、まさにそうした死に方をした。九〇年代、ウェブという新大陸の開拓において圧倒的な支配力を誇ったこの言語は、二十一世紀の最初の十年間で静かに、しかし確実に、その地位を失っていった。問題は、なぜそれが起こったかではない。むしろ、それが — 必然的に — 起こらざるを得なかったという事実そのものにある。

Larry Wallが掲げた「There's more than one way to do it」という標語は、一見すると自由の讃歌であり、プログラマーという職人たちに対する信頼の表明のように思われる。だが、ニーチェが貴族的道徳の堕落について語ったとき、彼が見ていたのはまさにこの種の「過剰な寛容」ではなかったか。デカダンスとは、選択肢が多すぎることによって選択そのものが無意味化する状態を指す。Perlは、あらゆる問題に対して無数の解決策を提供することで、逆説的に、どの解決策も正当化されないという事態を招いた。正規表現の魔術的な簡潔さと、シジル記号によって修飾された変数の暗号めいた羅列。それらは確かに「できる」ことを証明したが、「すべき」かどうかについては何も語らなかった。

この言語の設計思想には、ある種の楽観主義 — いや、むしろ無邪気さ — が含まれていた。プログラマーは皆、適切な判断力を持っているという前提。だが現実は、自由が与えられた瞬間、人間は最も安易な道を選ぶということを証明し続けてきた。ワンライナーの快楽。暗黙的変数の濫用。文脈によって振る舞いを変える演算子の乱立。これらは確かに「書く」という行為を加速させたが、「読む」という行為を — 根本的に — 破壊した。そして、ソフトウェア開発において、コードが書かれる時間よりも読まれる時間のほうが圧倒的に長いという事実を、Perlのコミュニティは軽視し続けた。いや、軽視したというよりも、その事実に気づいたときには、すでに手遅れだったのだ。

Perl 6という救世主の到来は、十年以上にわたって約束され続けた。だが、その約束が実現したとき — 正確には、Rakuという別の名前で生まれ変わったとき — すでに誰もそれを待っていなかった。この遅延は単なる技術的な問題ではない。それは、ある種の — 形而上学的な — 躊躇を示している。言語を根本から再設計するという試みは、既存のコードベースという巨大な遺産を放棄することを意味する。そして、プログラミング言語の価値は、その言語で書かれたコードの総量によって — 残酷なまでに — 決定される。Perl 6の開発者たちは、完璧な言語を作ろうとして、その過程で現実の世界から乖離していった。彼らが理想的な構文と型システムについて議論している間に、PythonとRubyは、それほど完璧ではないが実用的な解決策を提供し続けた。

しかし、この物語を単なる技術選択の失敗として片付けることはできない。Perlの衰退は、より大きな — そして普遍的な — 法則を示している。それは、適応の速度についての法則である。技術的環境は加速度的に変化する。新しいパラダイム、新しいフレームワーク、新しいベストプラクティスが、数年ごとに出現する。この環境において生き残るのは、最も優れた設計を持つものではなく、最も速く適応できるものである。Perlは、その柔軟性が — 皮肉なことに — 足枷となった。何でもできるということは、何に最適化すべきかが不明確だということを意味する。CGI時代の遺産であるcgi.pm、オブジェクト指向への中途半端な対応、モダンな非同期処理への抵抗。これらすべてが、言語の進化を遅らせた。

われわれは、ここで一つの逆説に直面する。自由を最大化することが、必ずしも進化を促進するわけではない。むしろ、適切な制約こそが、特定の方向への最適化を可能にする。Pythonの「一つの明白な方法があるべきだ」という哲学は、Perlの対極にある。だが、まさにその単純さゆえに、Pythonは科学計算、機械学習、ウェブ開発という明確な領域で支配的な地位を確立した。制約は、選択肢を減らすことで、コミュニティの力を集中させる。Perlには、そうした集中力が欠けていた。CPAN（Comprehensive Perl Archive Network）という膨大なモジュール群は、確かに印象的だったが、それはまた、標準的な解決策が存在しないことの証左でもあった。

言語の死は、通常、静かに訪れる。コボルやフォートランのように、レガシーシステムの中で生き続けることもあるし、アカデミックな領域で化石として保存されることもある。だが、Perlの場合、その死は — ある意味で — より屈辱的だった。なぜなら、それは忘却によってではなく、積極的な拒絶によって訪れたからである。新しい世代のプログラマーたちは、Perlを学ぶことを拒否した。彼らにとって、その構文は理解不可能であり、そのコミュニティは時代遅れであり、その価値観は — 根本的に — 受け入れがたいものだった。「読めないコードを書くことが美徳である」という暗黙の文化。それは、ソフトウェア工学が協調作業であるという現代的理解と、真っ向から対立していた。

ここで、われわれは技術的選択が決して中立的ではないという事実に気づかされる。プログラミング言語は、単なるツールではない。それは、思考の様式であり、コミュニケーションの形式であり、最終的には — ある種の — 世界観である。Perlが体現していたのは、ハッカー文化の黄金時代における個人主義的な職人気質だった。一人の天才的プログラマーが、深夜に一人で作業し、誰も理解できないが確実に動作するコードを書く。そうした美学は、確かに魅力的だったが、それは同時に、スケールしない美学でもあった。現代のソフトウェア開発は、チームで行われ、レビューされ、保守される。個人の才能よりも、集団的な理解可能性が重視される。Perlは、この変化に適応できなかった。

そして今、われわれが目にするのは、廃墟である。かつて繁栄したコミュニティは縮小し、新しいプロジェクトでPerlが選ばれることは稀になり、既存のPerlコードベースは — 徐々に — 他の言語に書き換えられている。だが、この廃墟から学ぶべきことは多い。それは、技術的優位性が永続しないこと。コミュニティの合意が、個人の自由よりも重要であること。そして、最も重要なこととして、進化とは単なる機能追加ではなく、時には — 残酷なまでの — 選択と集中を要求するということである。Perlの自滅は、過度な柔軟性という毒によってもたらされた。それは、自由の名のもとに、自らを食い尽くした言語の物語である。そして、その物語は — 決して — Perlだけのものではない。