2010年9月24日・25日に開催された「PHPカンファレンス2010」にあわせて、PHP開発者のRasmus Lerdorf氏が来日されました。日本を訪れるのは2度目という氏に、PHPの現状とその根底にある思想についてお話を聞きました。
現在の仕事について
大垣：昨年 Yahoo! Inc.を退職されましたね。現在はどのような仕事をされているのでしょうか？
Rasmus：WePayという起業したばかり小さな会社にいます。WePayはカリフォルニアにある、グループで支払いを行う処理を行うベンチャー会社です。
大垣：グループで支払いを行う、というのは、どういうことですか？
Rasmus：グループで何かを買いたいときに、グループとしてお金を管理したいですよね。例えば、大学で学生が集まってプレゼントを買いたいという場合があります。どんなものでも構わないですが、10人が集まって共同でオンラインショッピングをするとしたら、どうしたらよいでしょう？ PayPalを使うこともできますが、使いやすいとは言えません。正しくお金を処理するには、個人のお金と一緒にならないように別の口座が必要です。WebPayはすべてのグループごとに口座を作ります。クリックするだけで口座が作れ、デビットカードや小切手、オンライン送金や引き出しができる仕組みを提供します。ソーシャルネットワークにも対応しており、Facebookと連携する機能をもっています。Facebookのイベントと連携してチケットを販売したりすることが簡単にできます。ホテルのイベントを企画するなどの、いくつかの会社はWePayの機能とのインテグレーションに非常に興味をもっています。例えば、ホテルでイベントに参加する場合、6人以上ならディスカウントを受けられるというサービスがあったりしますが、現在このようなケースに対応できる便利なオンラインサービスはありません。これを実現するのがWePayのサービスです。
大垣：便利そうなサービスですね。近い将来日本でもサービスが開始されることを楽しみしています。
Rasmus：リストに載せておきます。そうなればよいですね。
使用言語とその選択について
大垣：現在、どの言語を利用していますか？
Rasmus：当然、PHPとCです。
大垣：ほかのLL言語は使っていませんか？
Rasmus：あまり使っていません。でも少しはRubyを使ってますね。デプロイメントシステムに使っています。
大垣：長い経験の中でさまざまなLL言語を使ってきたと思いますが、どの言語が一番よいと思いましたか？
Rasmus：解決しようとする問題によりますよね。WePayではデプロイメントシステムにRubyを使っています。それはCapistranoというRubyで作られたよいツールがあったからです。別の言語で作り直す必要はありませんでした。もし、あなたがCMSを作らなければならないとして、ベースとするよいCMSがない言語を選びますか？ 選ばないですよね。DrupalやJoomlaなどのCMSは何年も利用され、利用者が利用したいと思った機能のほとんどが実装されています。言語は開発者が考えているほど重要ではありません。重要なのはどのような製品が必要とされているのか、ではないでしょうか。必要とされている製品をいかに速く作り、かつ簡単に維持するかが重要です。多くの場合、言語は重要ではありません。DrupalやWordPressのように広く利用されている製品のエンドユーザは、どの言語で書かれているか？なんて気にしていません。WordPressのエンドユーザはWordPressで何ができて、何がすばらしいかを調べて、自分が必要としている機能をもっていることを知っています。WordPressやDrupalはある意味フレームワークのようなものです。
大垣：確かにWordPressやDrupalはフレームワークのようなものとして利用されていますね。お客様やエンドユーザにとって重要なのは言語ではなく、どのような製品が使えるのか重要ですね。
Rasmus：はい。その通りです。
PHPを作った理由
大垣：1995年にPHPをリリースされましたよね。なぜPHPを作ったのでしょうか？
Rasmus：単純に必要だったからです（笑） PHPは存在してなかったし、PHPのようなツールが必要だったのです。1995年のWeb環境は今とはかなり違い、ほとんどのツールはありませんでした。
大垣：CGIだけでしたよね。
Rasmus：Perlで書かれたCGIがほとんどでしたね。負荷の高いサービスを提供しようとするとリクエストのたびにPerlプロセスをフォーク（起動）しなければならず、すぐにサーバが利用できなくなりました。この問題を解決するためにmod_perlが開発されましたが、何年も後のことでした。ですから開発者はC言語でCGIプログラムを書くようになりました。この方法でもプロセスをフォークしなければなりませんが、Perlのような大きなプロセスをロードすることなく、自分が必要とするコードだけを実行できました。この方法で少しは早く処理できるようになりました。その後、サーバーサイドインクルードが利用されるようになりました。Apache Webサーバで、特別なタグを使えば動的なWebサイトを構築できるようになりました。PHPも最初はCGIで作っていましたが、NCSAサーバをハックしたバージョンもありました。私のハックしたNCSAサーバをダウンロードすればPHPが組み込まれた形で利用できました。しかし、人々にWebサーバを替えてもらうのは難しいです。ApacheがモジュールAPIを提供してからは、そのモジュールAPIを利用してPHPを作りました。それからPHPの利用がどんどん拡大していきました。私は机に向かって「PHPという言語を作ろう」と考えて作ったのではありません。「問題を解決するためのツールを作ろう」と思って作っていました。
大垣：なるほど。ダイナミックなWebを作るために便利なツールを作りたかったのですね。
Rasmus：その通りです。そして、それは速くなければなりませんでした。
PHPの成功について
大垣：私がPHPを使い始めたのも、実用的で十分に速くて便利なツールが欲しかったからです。ラスマスさんはPHPの生みの親で、PHPが生まれて15年ほどになります。現在のPHPの状況に満足していますか？
Rasmus：満足していないとは言えないでしょう。ほぼ1/3のWebサイトがPHPで作られているのが現状です。もし私が満足していないなんて言えば本当におかしなことですよね（笑）
大垣：確かにその通りですね。現在のPHPの状況はすばらしい成功といえます。
Rasmus：はい。PHPの実装や仕様の汚い部分についていろいろな批判がありますが、PHPは動的な言語としてはかなり古いほうの言語で、話言葉のように進化してきた言語です。英語はとても汚い言語で、古い習慣や矛盾する文法があってとてもひどい言語です。もし言語学の教授が完璧な言語を作るとしたら英語のような言語にはならないでしょう。日本語のような言語ににもならないと思います。でも、言語学の教授が作ったおかしな言語は誰も使わないでしょう。
大垣：使わないですね。
Rasmus：学術的に純粋であることと実用的であることはあまり関係がありません。何がしたいのか？何ができるのか？どんな問題を解決できるのか？ こういった部分と常に向き合っているのがPHPの強みといえると思います。結果、問題を簡単に解決できるPHPが人々にとって魅力的に見えるのだと思います。私もPHPに対する多くの批判には同意できます。PHPには沢山の醜い部分がありますが、これらの醜い部分は「問題を解決」することを阻みません。関数のパラメータの順序が逆になっている場合がありますが、これらは致命的な障害ではありません。順序が同じでないことに腹が立つかも知れませんが、反対にすれば問題なく動作します。確かに美しくないですが、正しく動くことが重要なのです。それに、我々が解決しようとしている問題は美しい問題ではないですよね。美しくない問題を美しくないツールで解決することに何の問題もありません。美しいツールは美しい問題を解決するためには非常に効果的かも知れませんが、多くの場合は必要がありません。さまざまなルールを作り、フレームワークを使い、モデルやビューを使って解決できない問題があるのです。
大垣：私も同感です。私のPHPに対する考え方はRasmusさんとほとんど同じですね。ですから私はRasmusさんの答えに非常に満足しています（笑）
Rasmus：それは良かったです（笑）
PHP 6の頓挫と“スーパーヒーロー”
大垣：PHP 6についての質問です。多くの人たちが「どうしてPHP 6は頓挫したのか？」と思っています。最も致命的な設計上のミスとは何でしょうか？
Rasmus：もっとも重大な問題であったのは、PHP 5からPHP 6への大きな変更が多すぎたことだと思います。そして、大きすぎる変更が原因で多くの開発者はPHP 6に付いていけなくなっていました。PHP 6の変更のほとんどは2、3人の開発者によって実装され、とてもリリースできる状態ではありませんでした。完成させるには置き去りにされた多くの開発者の協力が必要でしたが、PHP 5と比べてあまりに違いすぎました。開発者はPHP 6について学ぶ動機がありませんでした。また、Unicodeの問題は難しいです。Unicodeは多くの人に必要とされていなかったと同時に多くの人に必要とされていました。現状でもmbstringやほかのトリック、Unicodeを使って完璧な日本向けの製品を作れますよね。日本語だけでなくほとんどの言語で完璧な製品を作ることができます。右から左に書くアラブ語やトルコ語のiには問題があるようですが、そのほかの言語では問題ありません。トルコ語のiの問題には本当に困りました（笑） とにかく、3、4年前からPHP 6の開発が始まりましよね？
大垣：そうですね。
Rasmus：最初の1年は開発は順調でした。2年目には勢いをなくし、3年、4年目は虫の息でした。どこかの時点で「プラグを抜く」ことが必要でした。これは前進ではなく、PHP 5では活発な開発が行われ、新しいアイデアが検討され実装されていました。開発者はPHP 5のコードベースをよく理解していました。そこで「PHP 6のことは忘れて、PHP 5のブランチで開発を進めよう」ということになりました。いつかはPHP 6がリリースされることになるでしょうが、コミュニティ全体がついてこれるように少しづつ前進することにしたのです。エンドユーザにとっても同じです。メモリ消費が4倍になって今までより2倍遅いです、でもアップグレードしてくださいね、は通用しません（笑） IBMが作ったICUライブラリは非常に大きく複雑で、処理速度も遅すぎでした。そんなことはないでしょうが、ネイティブな文字列と同じ速度で処理できるUnicodeライブラリを作って欲しいですね。誰かがネイティブ文字列に近いUnicodeライブラリを作ってほしいです。
大垣：Rusmusさんも小泉さんを知ってますよね？ 昨日の懇親会でとなりに座っていたのが彼です。小泉さんはmbstringのmbfilterを作り直したい！と言ってましたから、もし十分な時間がとれたら彼なら作ってくれますよ（笑） でもPHP開発者としてフルタイムで働ける仕事でないと無理でしょうね。
Rasmus：Unicode対応は小さな問題でなく大きな問題です。一人の開発者が沢山の貢献をできますが、すべての拡張モジュールやコードに変更が必要な場合はほかの開発者の協力が必要です。一人のスパーヒーローが問題を解決するわけにはいきません。これが4年前に起きたことです。ある一人の開発者が「PHP 6とはこうあるべきだ」と言って開発をはじめました。今でも技術的には正しいソリューションだったと思いますが、誰も付いてこなければ意味がありません。驚くような技術は沢山ありますが、誰も使わなければ意味がありません。世の中には沢山の言語がありますが、PHP、Perl、Python、Rubyのことばかり耳にします。何百というスクリプト言語が開発されており、新たに開発されたこれらの言語はPHPやPerlよりよほどよいものがほとんどでしょう（笑）
大垣：後発の言語ですから、よりよくなっていて当然ですね。
Rasmus：学術的にどんなにすばらしくても、ドキュメントがなかったり、使い方が非常に複雑だったり、使い方がまったく違ったりします。彼らにとって完璧な言語を作っているかも知れませんが、彼らは利口すぎて一般のプログラマは「こんな風には考えられないよ」と思える言語であることが多いのではないでしょうか。彼らはマーケットを見ていないのです。だからこそ一人の利口なスーパーヒーローが何かをする場合に気を付けなければならないのです。我々には人々を付いてこさせるスーパーヒーローが必要なのです。
大垣：そうですね。
Rasmus：すごく利口な人とその人を手助けをする人、利口でなくても沢山の作業ができる人が必要かな。
大垣：なるほど。世の中にはクールな言語が沢山あります。例えば、Lispなどの関数型言語を使えば「カッコいい」コードが書けますが、一般的なプログラマに同じように書いてね、とは言えないですね。
Rasmus：そう。自分が書けても他人が書けなければ全部自分で書かなければならなくなります。経験のあるLisp開発者を探すのは簡単ではないからね（笑） だからこそPHPが大きな会社採用されるているのだと思います。PHP開発者を探すのは簡単ですし、PHPでの開発経験が無くても、何らかの開発経験があれば、1週間ほどコードを読んでもらえば開発に加われます。
PHP言語開発のマネジメント
大垣：では次の質問です。PHPプロジェクトはマネジメントに問題があるように思えますがどう思いますか？
Rasmus：我々にはマネジメントが無いからね。無いことが問題かもしれない（笑）
大垣：マネジメントは無いですね（笑） 既に答えをもらいましたが、マネジメントがないことが問題だと思いませんか？
Rasmus：根本的な問題は、ボランティアをマネジメントできないことだと思います。ボランティアにタスクをアサインすることはできません。いや、できますが、ボランティアに「今週の金曜日までに終わらせなさい」とは言えません。単純にこんな感じではPHPプロジェクトは動きません。より小さなプロジェクトで会社がバックアップしているようなプロジェクト、例えばDrupalのようなプロジェクトで、Acquiaのような会社であれば「これを金曜日までに終わらせてね」とは言えるでしょうけど（笑）
大垣：確かにその通りです（笑）
Rasmus：いくつかの会社がPHPプロジェクトに関わっていますが、我々はそのような会社を持っていません。JavaにおけるSUN（Oracle）のような会社はPHPプロジェクトにはないです。オープンソースプロジェクトでタイムラインをWebに公開して、実装する機能を公開して7週間後にリリースします！と言っても何も実装されておらず、別の5つの機能を実装しました！なんて開発者が現れてしまうのです。実装する機能のリストには意味がなく、スケジュールが守れないです。このようなマネジメントをPHPプロジェクトではやろうとしてなかったし、ほかのオープンソースプロジェクトで期限を何年も守れなかったことは多くあります（笑）
大垣：実際にありますね（笑）
Rasmus：私にはこのような努力に意味があるのか分かりません。機能のリストを作ったり、スケジュールを作ったりすれば、ビジネスでPHPを利用している方たちを安心させるにはよいでしょうけれど、守れなかったら意味がないでしょう？（笑）
──機能リストとかは作らないのですか？
Rasmus：実際には沢山の機能リストを作ってますよ。
──Apache Foundationのようなものを作ろうとしたことはありますか？
Rasmus：確か2001年頃にPHP Foundationを作ったことがあります。ある弁護士がお金や必要な手続きをボランティアでやってくれました。でも、自分たちはボランティアのGEEKでコードを書く連中です。誰も使いませんでした（笑） こういうことをするには誰かフルタイムで働ける人を雇わないとならないです。どうやって私が雇えます？ もし私が雇わなかったら誰が雇ったでしょう？ とにかくPHPはほかのプロジェクトと違って、とても「利己的」なプロジェクトです。
大垣：（笑）
Rasmus：我々はツールを作るために集まっていて、誰かが必要なツールを作って持ち寄って作っています。私はOAuthのプロバイダーが必要だったのでコードを書きました。Yahooに居た時はバイトコードキャッシュが必要だったのでAPCのコードを沢山書きました。ほかの開発者も同様で、自分に必要な機能を実装しています。これらにスケジュールを設定して管理する？ ちょっと無理でしょう。
大垣：分かります。自分も同じですから（笑）
Rasmus：1つだけ心がけていることがあります。すべての作業がプロジェクトに還元されるようにしています。Oracleがモジュールを開発した時には、「なぜすべてのOracleの顧客にバグのないモジュールを提供しないのか？ 一部の顧客にバグがあるモジュールを利用させるのか？ 全部Oracleの顧客でしょう」と言いました。プロジェクトマネジメントは私の役割ではないし、PHPプロジェクトをマネジメントするのは不可能だと思っています。
PHPプロジェクトの将来
大垣：今回のPHP 6のリリースは失敗しましたが、将来PHP 6はリリースされるでしょう。その時に、実装して欲しい、実装しておくべき機能は思い浮かびますか？
Rasmus：未来を予想して欲しいとの質問ですね。PHP 6の前に、PHP 5.4がリリースされるでしょう。PHP 5.4について答えましょう。例えば、現在では多くの会社がOpenIDをサポートしています。OpenIDをサポートするためにOpenSSLサポートの拡充が必要でした。多くの機能追加は拡張モジュールの部分で行われています。例えば、OAuthは広く使われる技術となっています。将来、OAuthモジュールはサポートされることになるでしょう。いくつかのモジュールが追加され、利用されなくなったいくつかのモジュールはバンドルされなくなるでしょう。例えば、SOAPは数年前にはホットな技術でしたが、複雑で遅く、今ではRESTやJSONに取って替わられました。ソース配布版の機能セットはこのような感じで変わるでしょう。言語のコア部分はできるだけ変わらないようにすべきだと思います。PHPは既に成熟した言語だからです。整数型などの基本データ型に対して型を強制できる拡張がありますが、これはあまりよい変更だとは思っていません。15年間弱いデータ型をもっていたのに強いデータ型をもたせるのはPHPでなくなるように思っています。世の中には既に沢山の強いデータ型を持つ言語があります。オブジェクト指向プログラミングのサポートについては実装されるでしょう。traits（継承による垂直なコードの再利用でなく、水平な再利用を行うRubyのmixinのような機能）にはよい実装があるのでPHP 5.4に含まれることになるでしょう。finallyも、もしよい実装があれば追加されるかも知れません。
大垣：PHPプロジェクトは多くのオープンソースプロジェクトで採用されている「早くリリースして、多くリリースする」方針を採用することで合意がとれているように思いますが。
Rasmus：我々はもうそんなに沢山のリリースを出してないよね。
大垣：最近はそうですね。しかし、PHP 4のサポートは何年も前に終了したのに、まだ多くのユーザが利用し続けています。これが現状なのでリリースが多すぎだとは思いませんか？
Rasmus：我々はPHP 5を2002年にリリースしました。つまり、PHP 5は8年間も利用可能だったのです。8年とはほとんどWebの世界の時間の半分に相当する時間です。これでリリースが頻繁すぎるのか、といわれるとそうとも言えないと思います。ほかの問題もあります。古いコードのサポートはおもしろくありません。
大垣：ええ。特にGEEKにとってはつまらない作業ですね。
Rasmus：その通り。GEEKにとってつまらないし、会社のように誰かに命じて何年も昔のコードを修正しなさい、とは言えません。既にPHP 5に移行してしまっている開発者には古いコードへパッチをバックポートするようにと言っても、違いすぎるし、古すぎる、知ったことかということになります。
大垣：（笑）
Rasmus：前にも言ったように、PHPの開発者は「利己的」なのです。自分の問題を解決するために集まったプロジェクトであり、PHP 5を使っている開発者にPHP 4の開発を強制することは難しいです。何かのサービスを開始したい、と思っている会社にとってはPHP 4サポートはよい機会かも知れませんね。もし、需要が沢山あるならビジネスとして実施すればよいでしょう。しかし、PHP 4サポートのように古いバージョンのPHPサポートは私達からは期待できません。Microsoftのように大きな会社でもWindows 2000のサポートを終了しているのです。我々は新しいバージョンのPHP、よりよいPHPの開発に資源を集中すべきです。
大垣：確かに。考え方はよく分かります。PHPは「利己的」な開発者の集まりであるとの話はよく分かるのですが、少なくともどのような方向性で開発するのかロードマップはあったほうがよいのではないでしょうか？
Rasmus：でも、ロードマップは基本的には機能リストですよね？
大垣：そうとも言えますね。
Rasmus：そういう機能リストはロードマップのように作るものではないと思います。我々はもう開発用のWikiを持っていますね。
大垣：はい。
Rasmus：Wikiには機能の説明やパッチがあります。コメントも記載されています。Wikiには最近提案されたすべてのコア機能の追加・修正の提案が載っています。リリース前にはこれらの機能が検討されます。
大垣：これがPHP流のロードマップと言うことですね。
Rasmus：我々は潤沢なリソースを持っていないので、現在のリリースブランチ、つまりPHP 5.3の機能が中途半端な状態で放置されないよう注意しなければなりません。PHP 5.4ブランチを作る前にPHP 5.3を安定させなければなりません。PHP 5.4のブランチを作る際にはWikiの提案（RFC）が一つ一つ吟味され、どれがPHP 5.4に取り入れられるべきか検討されます。Wikiがロードマップのような役割を果たしていると思います。とは言っても、PHP 5.4用の提案について作業中の開発者もいます。長期間のロードマップとはいえませんが、WikiにはこれからのPHPがどうなるのか予想するための情報が記載されています。ロードマップというよりはコードですね。実際に新しいバージョンのPHPに組み込まれる機能のコードです。コードを組み込んでバグを潰してリリースする。また1年半ほど経ったら提案されているコードを集めて、どれを組み込むのか検討する。実装されていない夢の機能を作ろうとするのではなく、既に在るものをどうするのか、どれをPHP 5.4に組み込むのかという感じで作っています。実装が無いと判断できないですからね。これは、とても実践的なアプローチで、今のところは非常によい形で機能しています。
大垣：ですね。
Rasmus：WikiによるRFCの仕組みはまだ数年しか運用していません。
大垣：数年前はMLで「これ作ったよ」と議論していましたね。カオスのような感じで。
Rasmus：基本的なところはWikiでも同じですね。機能について議論して、MLでこの機能を取り入れるかどうか決定しています。Wikiがあるから前よりは少し上手く機能的に対応できるようになっています。新しい機能を知るために毎日MLを見るのではなく、Wikiを見ればよいようになっています。
PHPフレームワークの現状について
大垣：別の質問です。毎年毎年、何十という新しいPHP用のフレームワークが開発されています。この状況について何かコメントはありますか？
Rasmus：私はよいことだと思っています。コミュニティにとっても健康的なことだと思っています。我々はいろいろなレベルで利用されるフレームワークを必要としています。DrupalもWordPressも、ターゲットやアプリケーションに特化したフレームワークのようなものだと言えます。CMSを作る場合にはDrupalやJoomla、ほかのCMSシステムをベースに作るほうが速いです。WordPressについても同様で、フレームワークとは言えないかも知れませんが、特定アプリケーションのより高いレベルのフレームワークだと考えています。より下層のレベルのフレームワークでコンポーネントレベルで再利用できるものも沢山あります。そのまた下層にPHPがあります。異なるさまざまなレベルで沢山の実装があることはよいことです。学校などの授業を管理するためのCMSのようなものもありますよね？
大垣：Moodleのことでしょうか？
Rasmus：はい。Moodleのようなアプリケーションも、私にとってはフレームワークのようなものです。Moodleはカスタマイズが可能で、プラグインを使って独自の機能を追加することができます。PHPはフレームワークが多すぎてよくない、汎用的なフレームワークは集約されるべきだとの批判がありますが、アプリケーションは同じではないですよね？ 解決しようとしている問題は同じではないですよね？ いろいろな問題を解決しようとしているのに、1つのハンマーで解決することはできません。解決しようとする問題に対して適切な、違うツールが必要になります。1つのハンマーで自分の思うようなものすべてを作ることも可能です。低いレベルのPHPの機能だけで作ることも可能です。しかし、Moodleのような教育用CMSを作る場合、Moodleを使ってその上に必要な機能を実装すればあっという間に問題を解決できます。Railsのような汎用フレームワークでMoodleのような教育用のシステムを作ることもできますが、構築により長い時間を必要とします。
大垣：まったくその通りだと思います。
PHPへの自身のかかわりについて
大垣：次の質問です。PHPプロジェクトの中でどのような役割を果たしたいとお考えですか？ 具体的には、Perlのラリーウォールさんのようになりたいとお考えですか？
Rasmus：まったくそうは思いません。
大垣：まったくですか？
Rasmus：私は利己的かつ実践的な開発者で、物を作ることが好きなのです。ツールについて強いこだわりがあるわけではありません。もしPHPが現状の問題をうまく解決してくれているなら、私自身はPHPについてあまり関わっていません。もし、OAuthのように足りない機能があった場合、問題を吟味してPHPを直します。でも、PHPに問題がないならPHPのことについて考えていません。私はPHPのことを考えてるのではなく、自分が実際に作っている製品について考えています。ほかの人たちで、言語やコンパイラといった部分に対して学術的な興味をもっている人がいることは非常によいことです。私はこの分野について興味をもっているわけではないからです。言語やコンパイラといった部分が好きということではなく、物を作るのが好きなのです。
大垣：なるほどよく分かりました。
PHPの役割と未来
大垣：これが最後の質問です。8才の息子さんが居ますよね？ お子さんにPHPを教えますか？
Rasmus：息子がプログラミングをしたことがあると言えるのはLEGOのMindStormだけですね。とてもビジュアルな言語で「この小さい箱を動かす」「何かを見たらこうしろ」「10メータ先に何かがあったらこうしろ」「右にこれがあったらこうする」などができます。息子はこのビジュアルな言語を使ってとても面白いことをしています。MindStormが子どもでも分かる言語だとは言っても、ループやif文などの言語がもっているいるべき機能を一通りもっています。息子は自由にやっていて、あれをしたら？これをしたら？とプログラミングをさせるつもりはありません。水泳にいったり、自転車に乗ったり、子どもらしいことをするように言っています。それでも、息子はLEGOとMindStormに非常に大きな興味をもっているようです。
大垣：昨夜一緒に食事をしたジンガジャパンのジャスティンさんは15才からPHPでプログラミングを始めたと言ってましたね。息子さんも中学生くらいになったらPHPでプログラミングしているかも知れないですね。
Rasmus：私も13、14才の時からBASICとアセンブラでプログラミングをしてました。メモリが1KBしかなかったから、すぐにアセンブラでプログラムする必要がありました。
大垣：私も初めてプログラムを書いたのはBASICで16KBのメモリ持ったコンピュータでした。
Rasmus：雑誌を買ってきてBASICのプログラムを入力してましたね。でも保存することができなかったから電源を切ると消えてしまって（笑） またプログラムを動かしたかったらそのたびに入力し直しました。8回も入力し直した頃にはプログラムが何をしているのか理解できました。PHPは新しいBASICのようなものなのかも知れないですね。現在のPCは電気を入れてもBASICのプロンプトが点滅しているわけではないし、インストールされているアプリケーションは子どもが競争するのは無理なアプリケーションばかりで、簡単なゲームでもさえ週末の時間を使って作るれるようなものではないです。しかし、子どもでもWebサイトのソースは見れます。PHPはこのWebサイトに対して何でもできるツールを提供しています。YahooやFacebookのようなサイトがPHPだけで作られていると知ること、「無料のWebサーバと無料のスクリプティング言語で自分もFacebookと同じことができるんだ！」と知ることはクールなことだと思います。
大垣：私もそう思います。今日はインタビューを受けて頂きありがとうございました。
インタビューを終えて
今回のPHPカンファレンスまでRasmus氏とは直接話したことがなかったのですが、想像していたとおりのナイスガイでした。私もRasmusさんと同じで「利己的」な開発者なのかな？とインタビューを終えて感じました。言語に興味があるからプロジェクトに貢献しているのではなく、言語で実装できる成果物のために貢献している、という姿勢は、Rasmusさんと同じです。Rasmusさんや私だけでなく、PHPプロジェクトに関わっている開発者の多くが、今自分が直面している問題に対してのソリューションを作りたいと考えているのだと思います。PHPの言語のコア部分を修正している人はそう多くありませんが、PHP本体とモジュールについて貢献している人は沢山います。PHPの開発体制はPHP本体とモジュールの開発が一緒であるため、言語本体を開発していない人でもPHPの言語部分について意見が言える状況になっています。この現状は良い意味でも悪い意味でも機能しているのだな、と改めて思いました。
