パスワードを忘れた? アカウント作成
95169 journal

taro-nishinoの日記: 何故、私はPerlを続けるのか 2

日記 by taro-nishino

Jonathan Rockway氏は、いわゆるモダンPerlの旗手の一人です。Catalystの本も書いています。彼は昨年8月に、Why I stick with Perlというエッセイを書いていました。
今何故、それを思い出しているのか言いますと、言語論争があちこちにあり、宗教論争と同じく永遠に終わらないのは誰の目にも明らかなのに、特に日本において(私が日本人だから余計に思うだけかも知れませんが)後発の言語信者が蒸し返すことが多いので、彼のエッセイを思い出した次第です。
今読み返しても、私の言いたいことと全く同じです。以下、私訳を載せて置きます。

何故、私はPerlを続けるのか
2008年8月4日 Jonathan Rockway

私は今朝、discussion about Perl on Hacker Newsに気づいた。その記事は、著者がPerlを好きな理由についてのものである。この種の記事すべてと同様に、いつもの「Rubyの方がよい!」のコメントが付いた。Hacker Newsの議論はちょっとばかり知性があって、Perlが汚いこと、その記事の著者の「すぐにRubyに見切りをつけた」こと、正規表現が遅い(あたかも、それがPerlを扱う大層なものかのように)ことを主張している。ともかくも、私はこれらのポイントは解決するであろうと思ったので、Perlを使うべきと私が考える理由を示す。

Perlを含めてプログラミング言語について考える場合に先ず認識すべきことは、それが馬鹿げているということである。作りたくないけれども、とにかく押し付けられるエンジニアリング上の多くのトレードオフを持っているのである。例えば、perlコアは正しく動かない遺産のがらくたに満ちていて、互換性の理由のために、決してフィックスされないだろう。それは互換性のために、正しさをトレードしているのである。私はそんなことを決してしないが、Perlは私のプロジェクトではないので、その決定には関しない。Perlについて嫌いなものでも、引き続き使うであろう。信じて欲しいが、私が絶対的に嫌うものは何百とあり、それは私を泣かす。しかし、それはこの記事のポイントではない。

私が使ったことのある他の言語すべてが、Perlと同様に馬鹿げているのである。私は本当にLispが好きで、プログラミング言語はそのように動くべきであると考えている。最小のもので、残りを組み立てる。その方法に、私はずっと幸福に思うだろう。だが、何故Common Lispは、キーを値にマップするのに、少なくとも3つの方法を組み立てる必要があったのだろうか(getf、assoc、及びhash tables)? その答えは、言語設計者が3つ全部を欲したからである。再度言うが、私のプロジェクトではない・・・・そう、その決定には関していない。私が出来るのは、その妥協と同居するか、本当は好きでない妥協の組合せを他の言語に求めるか、私自身の言語を作るか(それはまた別の妥協である)しかない。理想的なものはないのである。完璧な言語はないのである。完璧でない言語が既に持っているライブラリをすべて書くための無限の時間を持てなければ、自分で作ろうとする言語は完璧ではないだろう。トレードオフ、トレードオフ、トレードオフ。それがエンジニアリングなのである。

ここまでで、貴方は自分が選んだ言語が嫌いな理由を考えているだろうと思う。そうではないのなら、貴方は十分に使って来ていないわけで、プログラミング言語を推奨したり批判したりする立場にはない。Perlが完璧でないことを実感するのに私は長い時間がかかった。それ以前は、素晴らしいとすべての人に話したが、その人達は私のことをサクラ的オタクをやっていると笑っただろう。今や私は少しは成長しているので、プログラミング言語を的確に考えられる。貴方もそうあってほしい。

とにかく、貴方が選んだ言語の嫌いな特徴について考えなさい。それは本当に貴方に、「どうして、この方法でそれをするために、人はそんな馬鹿になり得るのだろうか」と考えさせる。他言語からの好きな(貴方が選んだ言語にはない)特徴について考えなさい。本当にそれをしなさい。Common Lispに継続があればなと思わない? Pythonの実行スピードが速ければなと思わない?

それらの理由を留意すれば、特徴が問題解決を妨げていないことが分かるだろうと思う。問題が深刻に貴方を非生産的にしているとすれば、問題を再考する以前にとくに他の言語に切替えていたであろう。貴方が有害と思う特徴は、簡単には使えない。存在しない特徴は真似ることは多分出来る。(PythonはPerlのようなレキシカルクロージャを持っていないが、クラスを使えば真似ることは出来る。問題は解かれた。)結論は、貴方の言語の文法と実装は実際はそんなに問題ではないということである。いくつかの関数を呼出し、クラスを作り、少量のビルトインに投げ入れ、そして問題は解かれる。そうなのだ、文法は汚い。しかし、今や貴方はリッチで有名で、問題の数nプラス1に進むことが出来るのだ!

ご存知の通り、実際のプログラムは滅多に文法に関係しない。HTTPをする必要があるなら、素晴らしい言語の特徴がそれをするのではない。たとえ貴方の言語が完璧なる特徴を備えているとしても、HTTPヘッダーパーサを書くことは貴方の時間の無駄である。ライブラリが生産性の鍵なのだ。貴方の嫌いな文法を無視することは、HTTP仕様書を読み、それを実装し、テストすることより早いはずである。

ライブラリが重要である理由は、車輪の再発明の代わりに、解かれていない問題に時間を費やせるからである。良いライブラリが無ければ良いソフトウェアを書くことは出来ない。

例として、このブログ(Angerwhale)を走らせているソフトウェアは212の異なるPerlモジュールを使用している。私がそのコードすべて自分で書かなければならないとすれば、機能はもっと貧弱であるだろう。「たかがブログのために」それらのライブラリを必要とする私を嗤うまえに、貴方の知らない複雑性すべてを考えてほしい。中身は、任意の文字エンコーディングにエンコードされた投稿について働き、異なるリッチテキストフォーマットをサポートし、HTTP ETagヘッダーのために投稿のMD5の総計を計算し、ファイルシステムのパスをクロスプラットフォームに処理し、PGP署名を読む事などを含む。それは簡単に言っているのである。ライブラリが無ければ、もっと貧弱であるか、または、もしかして動かないかも知れないという類のガラクタになっているだろう。(ついでながら、PHPは大量のライブラリを持っていない・・・・)

私は、Perlコミュニティは誰よりもライブラリをよく考えていると確信している。何万もののディストリビューションが既にある、CPANを持っている。1万のディストリビューションは分かり辛いが、search.cpanで貴方の好都合なプログラミングのトピックを探すことを努めよう。問題が容易でこなれ易い形のライブラリに解かれていることが分かるだろう。少しのリンクをクリックすることがコーディングの連続から貴方を救うかも知れない。

Perlについて重要なことは、良いライブラリを書く文化があることである。少しのコードを書いて、それをブログに投稿し、それを「ライブラリ」と呼ぶのは、Perlプログラマではない。誰もが、ドキュメンテーション(時には極端に少ない場合があるが、誰もがライターではない)、テストスイーツ、Makefile等が付いているCPANディストリビューションを作ることに義務感を持っている。私は理由が分からないが、これが常に生じている。強い習慣があり、その習慣に従っているツールがあるからだと思う。

ライブラリの存在は更に容易にライブラリを書かせる。サイクルがそれ自身に餌を与える。すなわち、我々は多くのライブラリを持っている、それが別のライブラリを簡単に書かせ、更に多くなって、別のライブラリを書くことが更に簡単になる・・・・そして、貴方がそれを知る以前に、想像出来るよりも大量のライブラリを持っているのである。

私は他の言語を見て、そのコミュニティは全くPerlとは似ていない。彼等はシェアリングライブラリのためのサイトを立てたが、誰も寄贈しなかった。確かにRubyForgeはいくつかのライブラリを持っている。PEARは少ない。Pythonは多い。しかし、ライブラリを書いて、使用する文化がなく、ほとんどの人は1つのライブラリか、または、ある車輪の再発明の2番煎じとカット・ペーストのコードに終わっている。("rails"を検索してみなさい。これらのプログラマの殆どが1つのライブラリ、Railsに頼っているだろうが、彼等の残りのコードはブログからのカット・ペーストである。)これらの人は本当にライブラリを分かっていないし、自力で書くことも嫌がっていない。人がライブラリを書かないことを続けていると、そこに何のライブラリもないことになる。Perlの膨大なライブラリは、更に書くことを容易にする。他の言語のライブラリの不足は益々書くことを困難にする。そういうことで、Rubyが数年で不思議に何万もののライブラリを持つだろうとは、私は思わない。彼等は今していることを維持するだろう。(ブログからのカット・ペーストよりも、パッケージングシステムと中心となるライブラリレポジトリがいい戦略である理由を説明する必要がないことを祈る。)

Cコミュニティもライブラリを理解していない。GTK+のように、少しあるが、殆どのCプログラマはプログラミング時、ライブラリのことを考えていない。彼等を批判しているのではない。つまり、コードに依存関係を宣言する方法が無い、名前空間が無い、エラー伝播が無いのでは、ライブラリを使用すること、書くことはぞっとする悪夢である。相応に多くのライブラリがあることに、私は驚く。

だが、ウェブアプリケーションからGPGを得る必要がある時、苛立たせる。全く"libgpg"は使えないのである。gpgプロセスをforkし、ファイルディスクリプタを正しく立て、パイプの入力を書き、別のパイプの入力を待ち、そして結果をパースしなければならない。すなわち、すべて、少しのXORオペレーションとビットシフトの塊である。どうして、誰がこれをいいアイデアと考えるだろうか? (libgpgmeがあるが、これは単にライブラリ内にforkを隠しているだけである。全体的に不必要な作業がまだ沢山ある。)

Gitも同様に悪い。ライブラリを使い、書く文化のプログラマがGitを書くとすれば、Gitの殆どが、コマンドラインの引数により初期化、変更されるコマンドラインスクリプトを薄くするクラスからなっているであろう。スクリプトの中に重要なコードは無くなり、容易に再利用可能なクラス内のみに存在するであろう。これは他のプログラムからのgit使用を当り前のことにする。つまり、クラスのインスタンスを作り、メソッドを呼び、それでお終い。代わりに、Cプログラマは誰かがライブラリを必要とするだろうとは決して考えないであろうから、forkし、カスタム化されたデータを返すバイナリをexecしなければならない。それから、カスタム化されたデータのパーサーを書かなければならない。素晴らしいアイデアだ。(ライブラリの中に簡単にものを作るための、git-fast-importですら巨大なバイナリである。貴方は、Gitと対話するために「簡単な」新しい言語を学ばなければならない。誰がそれを素晴らしいアイデアだと思うだろうか!?)

そうして終に結論である。貴方が私と同様なら、貴方のする殆どのプログラミングは、ライブラリを使って、糊付けである。Perlは綺麗な言語でないかも知れないが、汚さを見る時間も無いほどに、沢山のライブラリがある。他の言語が綺麗な文法を持っていても、人がPerlを続けている理由はこれである。道具を使い、そして貴方の道具をコミュニティに寄贈するのはとても簡単だ。私達は汚い文法を気にもかけない。只我が道を行くのみ。私達が考えている事はすべて、問題を解くことなのである。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2009年05月17日 1時41分 (#1566843)
    Common Lisp had continuations? の continuations はプログラミング用語でいう「継続」に当てはまるものでしょう。 具体的な説明はここでは書きませんが、Scheme 継続 あたりで検索すれば概要がわかると思います。
    • Common Lisp had continuations? の continuations はプログラミング用語でいう「継続」に当てはまるものでしょう。
      具体的な説明はここでは書きませんが、Scheme 継続 あたりで検索すれば概要がわかると思います。

      御指摘、有難うございます。
      そうでした、そうでした。全然、頭が回っていませんでした。変だなとは思ってはいたのですが。
      継続に訂正しました。

      親コメント
typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...