定期的に話題になるが、さいきんまたPerlの是非論がネットを賑わしている。
自分がPerlが嫌いなら使わなければいいだけの話だと思うのだが、他の人が使うことも、Perlのコードが残っていることも我慢できないという趣旨らしいので、最近のネットやってる若い人は元気が良くて過激だなと思う。
ぼくは人がPerlを好きだろうと嫌いだろうとかまわないし、PerlのコードやPerl好きの人がこの世から根絶することはまずあるまいと思うので(なにしろ似たような議論ですぐに出てくるCOBOLとBASICが全然現役バリバリなので)正直どうでもいい。
議論で人々の考えが深まれば良いと思う。
ただ、この機会に、ぼくがPerlがなぜ好きかということをまとめておくのもいいだろうと思って書いてみる。
自分がPerlが嫌いなら使わなければいいだけの話だと思うのだが、他の人が使うことも、Perlのコードが残っていることも我慢できないという趣旨らしいので、最近のネットやってる若い人は元気が良くて過激だなと思う。
ぼくは人がPerlを好きだろうと嫌いだろうとかまわないし、PerlのコードやPerl好きの人がこの世から根絶することはまずあるまいと思うので(なにしろ似たような議論ですぐに出てくるCOBOLとBASICが全然現役バリバリなので)正直どうでもいい。
議論で人々の考えが深まれば良いと思う。
ただ、この機会に、ぼくがPerlがなぜ好きかということをまとめておくのもいいだろうと思って書いてみる。
ぼくがPerlと出会ったのは割に最近である。
15年前とかだ。
今の会社に転職して、UNIX中心の仕事になった。
それまでは大手の会社で汎用機の仕事をしていた。
まあ、COBOLを使っていたしJCLを書いていた。
あとは「仕様書」を書いていた。
UNIXの会社に来て、最初にやった仕事が「WordPerfect」の文書をFrameMakerに変換する仕事だった。
今で言うとFrameMakerの文書をInDesignに変換するような感じだろうか。
変換するシステムを作ったのは自分じゃなくて、会社の先輩だった。
みんな絵に描いたようなハッカーで、このときいろいろ教えてもらえばよかったのだがすごく忙しそうにしていたので、自分で内容を解読して覚えた。
Web前夜の話であり、自分で動物の本を読んで覚えたのだ。
時間のむだづかいだ。
システムは基本的にawkとsedで書かれたシステムをシェルスクリプトで剥ぎ合せていた。
これは伝統的な定法であって、いまでもこれが最高と思っている人は多いのではないか。
しかし、これがどうにも使いにくい。
以下のような引っかかりがあった。
・awk、sed、shのファイルをいちいち行き来するのが大変
・いちいち異なる文法で頭を切り替えるのが大変
・シェルスクリプトは遅い
・awkのスクリプトは基本的に文書処理に特化されているので制御構造が書けず、自由がきかない
非常に苦労した。
全部覚えている人ならカンタンかもしれないが、全部まったく知らないぼくには大変な苦労である。
そんな時、会社の社長がPerlに凝って勉強していた。
ぼくも会社にあった「はじめてのPerl」を読んで、たちまちその魅力に取りつかれた。
ていうか、本当にタイムリーだった。
「これだ」と思ったのである。
本書はPerlのハッカーでありエヴァンジェリストであるRandal L. Schwartz他が書いた本だ。
Perlの開発者であるLarry Wallが直接書いた本ではない。
しかし、Larry Wallは本書に序文を書いていて、これがまさにぼくの悩みにこたえるものだった。
Larryはこのように説く。
(要約はぼくによるもので、記憶に頼っている)
これまでのハッカーのやり方はawk、sed、Cというビーズを紐でつなげるようなやり方だ。
これは過度に還元主義的なアプローチである。
Perlは逆に、実際的であるために、多少がらくた的なピースを混ぜこぜにするのを恐れない。
その結果ビーズは熱で溶かされた美しい真珠(pearl)のようなものになったのだ。
ぼくは、東洋の端っこで会社を転職して使い慣れないUNIXのマシンの前で偉い先輩が書いたスクリプトの解読に悪戦苦闘している自分に、こんな立派な本の序文で、偉大な人が直接語りかけてくれているような感動を覚えた。
むろん偶然に過ぎない。
Larryが書いたときと、ぼくが読んだ時ではずいぶんタイムラグがある。
しかし、この偶然のアドバイスにどうしようもなく感動したのだ。
もしかするとこの悩みは、世界のコンピューター技術者に普遍的なものではあるまいか。
PerlはたいていのUNIXコンピューターに入っている。
Macにも入っているし、Linuxにも入っている。
上の件があってすぐに、ぼくは自分用のLinuxマシンを会社で持ちたくなったが、パッケージ管理がラクチンなDebianを会社の人に勧められた。
そのとき、Debianのインストーラーやパッケージ管理システムといったバックエンドシステムの多くの部分がPerlで実装されていると知った。
つまり、Perlが後からインストールされるのではなく、OS自体がPerlに依存しているのだ。
そしてPerlはWindowsにもやさしい。
システム依存のことさえしていなければ、同じスクリプトがUNIXとWindows両方で走る。
Strawberry Perlが出来たり、ActivePerlがMinGW対応になってVisual Cがいらなくなったりと、この方面は年々強化されている。
ネット界での評判とは別に、年々Perlを使い始める人はむしろ増えていると感じる。
もっともこれは、ぼくが技術翻訳の自動化という自然言語寄りの分野を生業にしているかもしれない。
世界中から「こういうツールを作ったんだけど、日本語で使ってくれないか」「こういうツールがあるらしいんだけど、使えるようにしてくれないか」という依頼が近年多く来るようになった。
Perlの用事だったらすぐに引き受ける。
自分でも何かと言うと使う。
使えば使うほど手に馴染む。
手放す気にならないし、手放せない。
ぼくは普通ならばバッチファイル(やWindows ShellScriptやWindows PowerShellや・・・)を使うようなレベルの自動化もPerlでやってしまう。
出来てしまうからだ。
いままでアホみたいに書き溜めた自作ツールの蓄積もある。
似たような処理を書くときはgrepすると昔作ったプログラムが出てくる。
ちょいちょいと書き足すと機能が増え、新しい仕事が出来る。
ツールのアーカイブが、自分の「味噌蔵」のようなものだ。
年を重ねるごとに味わいを増す。
(dankogaiさんぐらい頭がいいと、ワンライナー(1行プログラム)がシェルのヒストリーに残っていて、それをバックスクロールするだけで用事が済んでしまうらしい。すげー)
sedもawkもshも忘れてしまった。
sedとか難しすぎるよ!
Perlで出来ることはPerlでするし、Perlで出来ないことにはめったに出会わない。
もちろん、ただ「使えるから使っている」という消極的な理由だけではない。
ここで項を分ける。



15年前とかだ。
今の会社に転職して、UNIX中心の仕事になった。
それまでは大手の会社で汎用機の仕事をしていた。
まあ、COBOLを使っていたしJCLを書いていた。
あとは「仕様書」を書いていた。
UNIXの会社に来て、最初にやった仕事が「WordPerfect」の文書をFrameMakerに変換する仕事だった。
今で言うとFrameMakerの文書をInDesignに変換するような感じだろうか。
変換するシステムを作ったのは自分じゃなくて、会社の先輩だった。
みんな絵に描いたようなハッカーで、このときいろいろ教えてもらえばよかったのだがすごく忙しそうにしていたので、自分で内容を解読して覚えた。
Web前夜の話であり、自分で動物の本を読んで覚えたのだ。
時間のむだづかいだ。
システムは基本的にawkとsedで書かれたシステムをシェルスクリプトで剥ぎ合せていた。
これは伝統的な定法であって、いまでもこれが最高と思っている人は多いのではないか。
しかし、これがどうにも使いにくい。
以下のような引っかかりがあった。
・awk、sed、shのファイルをいちいち行き来するのが大変
・いちいち異なる文法で頭を切り替えるのが大変
・シェルスクリプトは遅い
・awkのスクリプトは基本的に文書処理に特化されているので制御構造が書けず、自由がきかない
非常に苦労した。
全部覚えている人ならカンタンかもしれないが、全部まったく知らないぼくには大変な苦労である。
そんな時、会社の社長がPerlに凝って勉強していた。
ぼくも会社にあった「はじめてのPerl」を読んで、たちまちその魅力に取りつかれた。
ていうか、本当にタイムリーだった。
「これだ」と思ったのである。
本書はPerlのハッカーでありエヴァンジェリストであるRandal L. Schwartz他が書いた本だ。
Perlの開発者であるLarry Wallが直接書いた本ではない。
しかし、Larry Wallは本書に序文を書いていて、これがまさにぼくの悩みにこたえるものだった。
Larryはこのように説く。
(要約はぼくによるもので、記憶に頼っている)
これまでのハッカーのやり方はawk、sed、Cというビーズを紐でつなげるようなやり方だ。
これは過度に還元主義的なアプローチである。
Perlは逆に、実際的であるために、多少がらくた的なピースを混ぜこぜにするのを恐れない。
その結果ビーズは熱で溶かされた美しい真珠(pearl)のようなものになったのだ。
ぼくは、東洋の端っこで会社を転職して使い慣れないUNIXのマシンの前で偉い先輩が書いたスクリプトの解読に悪戦苦闘している自分に、こんな立派な本の序文で、偉大な人が直接語りかけてくれているような感動を覚えた。
むろん偶然に過ぎない。
Larryが書いたときと、ぼくが読んだ時ではずいぶんタイムラグがある。
しかし、この偶然のアドバイスにどうしようもなく感動したのだ。
もしかするとこの悩みは、世界のコンピューター技術者に普遍的なものではあるまいか。
PerlはたいていのUNIXコンピューターに入っている。
Macにも入っているし、Linuxにも入っている。
上の件があってすぐに、ぼくは自分用のLinuxマシンを会社で持ちたくなったが、パッケージ管理がラクチンなDebianを会社の人に勧められた。
そのとき、Debianのインストーラーやパッケージ管理システムといったバックエンドシステムの多くの部分がPerlで実装されていると知った。
つまり、Perlが後からインストールされるのではなく、OS自体がPerlに依存しているのだ。
そしてPerlはWindowsにもやさしい。
システム依存のことさえしていなければ、同じスクリプトがUNIXとWindows両方で走る。
Strawberry Perlが出来たり、ActivePerlがMinGW対応になってVisual Cがいらなくなったりと、この方面は年々強化されている。
ネット界での評判とは別に、年々Perlを使い始める人はむしろ増えていると感じる。
もっともこれは、ぼくが技術翻訳の自動化という自然言語寄りの分野を生業にしているかもしれない。
世界中から「こういうツールを作ったんだけど、日本語で使ってくれないか」「こういうツールがあるらしいんだけど、使えるようにしてくれないか」という依頼が近年多く来るようになった。
Perlの用事だったらすぐに引き受ける。
自分でも何かと言うと使う。
使えば使うほど手に馴染む。
手放す気にならないし、手放せない。
ぼくは普通ならばバッチファイル(やWindows ShellScriptやWindows PowerShellや・・・)を使うようなレベルの自動化もPerlでやってしまう。
出来てしまうからだ。
いままでアホみたいに書き溜めた自作ツールの蓄積もある。
似たような処理を書くときはgrepすると昔作ったプログラムが出てくる。
ちょいちょいと書き足すと機能が増え、新しい仕事が出来る。
ツールのアーカイブが、自分の「味噌蔵」のようなものだ。
年を重ねるごとに味わいを増す。
(dankogaiさんぐらい頭がいいと、ワンライナー(1行プログラム)がシェルのヒストリーに残っていて、それをバックスクロールするだけで用事が済んでしまうらしい。すげー)
sedもawkもshも忘れてしまった。
sedとか難しすぎるよ!
Perlで出来ることはPerlでするし、Perlで出来ないことにはめったに出会わない。
もちろん、ただ「使えるから使っている」という消極的な理由だけではない。
ここで項を分ける。



