UNIX系のシステムを使っている限りは，スクリプト言語なんてPerlがあれば十分だと思っていた。念のために解説しておくと，Perlというのは本来，他のコマンドの出力結果やログファイルなどを集計するスクリプトを記述する目的で開発された言語であった。その後，オブジェクト指向プログラミングの要素を取り入れたり，スレッド機能を備えたり，Unicodeに対応したりして時代の要請に応えてきた。

　ちょっとしたツールがほしいと思うとき，簡単なものであれば，bashやsed，awk，makeなどを駆使すれば事足りる。しかし，少し凝ったことをする場合にはPerlが欠かせない。いまや一般的なLinuxディストリビューションにはPerlが必ずインストールされているし，他のUNIX系のシステムだったとしても，たいした手間をかけずにPerlが利用できる。そういうわけで私はかれこれ20年近くにわたってPerlと付き合ってきた。

　しかしながら，Perlを自由自在に扱える技術者はそれほど多くないようだ。少なくとも私が出会ってきた範囲では，Perlのモジュールやクラスをコーディングする「正当な」手法をマスターしている者は数えるほどしかいなかった。その理由は，どうやらPerl特有の難解さにあるのではないかと思われる。Perlの構文にはちょっとしたクセがあり，基本的な機能の実装にも若干トリッキーな部分がある。そのため，初心者にとって理解しづらいコードになりがちなのだ。

　もちろんコーディングの定石はある。ただし，定石を教えるよい解説書はほとんどない。解説文を書くとしたら，おそらくかなりの分量になってしまうからだ。したがって，定石を覚えるには他人のコードをたくさん読んで勉強しなくてはならない。

仕事でPerlを使う人ならば，仕事と全く関係のないコードを山ほど読む必要があるというのは抵抗があるに違いない。要するに，プログラミングが好きで，言語の仕様と簡単なサンプル・コードがあれば，後は他人のプログラムをばりばり読んでマスターしてしまうぐらいのスキルがなければPerlを使いこなすのは難しいのである。これがPerlが一般受けしづらい理由ではないかと思う。

　にもかかわらず，ある程度知名度のあるスクリプト言語，例えばPHPやPython，Lua，Rubyなどは少なからずPerlの影響を受けている。だから，Perlをマスターしているという自負がある私にとって，他のスクリプト言語はそれほど魅力的に感じられなかったし，積極的にマスターする必要もなかった。

　ただ一つの例外はPHPで，これはWebシステムを開発する際に，発注元がPHPでの開発を希望するケースが多かったから，仕方なく使うようになったのである。長期にわたって安定した仕様を提供し続けているPerlに比べて，頻繁に仕様が変わるばかりかセキュリティ上の問題が次々と出てくるPHPにはかなり苦労させられた半面，Apache HTTP Serverのプロセス空間内で軽々と動くという点が魅力であった。使い始めて約5年，いまやPHPはPerlと並んで得意な言語の一つになってしまった。そして，もうこれ以上別のスクリプト言語をマスターする必要なんてないし，あったとしてもたいした時間はかからないだろうと思って，ずっとそのままにしていた。

　ところが，である。