トップ «前の日記(2007-05-21) 最新 次の日記(2007-05-23)» 編集

2007-05-22 [長年日記]

_ よーしパパ釣られちゃうぞー < PHP

もう 21 日に長いの書いちゃったから久しぶりに未来日記書いちゃうぞメソッド発動。

404 Blog Not Found:そろそろPHPに関して一言いっとくか

細かく言ってみよう。つかまぁ、自分も PHP マスターではないのでそこら辺のツッコミも希望しつつ。

全部 cofigure でビルド?

No. phpize がある 4.3.0 以降は個別にインストールできる。

ただし、できるだけ。

PHP には pear, pecl という便利なリポジトリ&管理ツールがあるが、phpize はその範疇になく、どの拡張モジュールを入れたのかの管理はできない。はず。

Perl や Ruby では Pear と違って pure Perl, pure Ruby 以外のライブラリも多く、そこら辺で格安 or 無料レンサバ使いの人には不評だが、逆に言うと拡張モジュールもライブラリも一元的に管理できる便利さがある。PHP では Pear が pure PHP を守ってくれるというメリットはあるが、逆に拡張モジュールの管理はできない。(全部 pecl に入ってればいいのにね。)

php.ini で on/off できるのとはまた別な話ね。言うなれば Apache モジュールのようなものなんだよな、これ。ビルド済みのものでなければ .conf で on/off できない。結局全部まとめてビルドしてないと不便、ということになってしまう。このスクリプトのときだけこのモジュールが欲しい、てな要求にはもう対応不能。

最初に設定しちゃえば似たようなスクリプトを書く際にいちいち気を使わなくていいって意味では php.ini 方式は楽なんだけど、PHP のコードでそれを制御できないのはやっぱ面白くないと感じる場合もあるな。

<?php はウザイ ?

同感。

否定する気まったくなし。というか、いまどきはテンプレートを使って V とそれ以外を分離するので実は <?php なんて記法必要ないし。

すっげー簡単な確認用のスクリプト以外では最近では <?php は不要です。オプションかなんかで、書かなくていいようにできるとすごい嬉しい。

妙な約束事が多いのは Perl も一緒

prefix とか 1文字、2文字の特殊変数とか微妙な構文レベルの呪文になってしまってる分、見た目や理解しやすさは Perl の方がきつい。

ただし、細かい関数の違いという意味では PHP の方がきつい。似たような関数が大量にあり、バッドノウハウの塊と化しているのは間違いない*1。そして充実しているはずのマニュアルにそのノウハウは還元されていない。

例えば Perl や Ruby では obosolete なメソッドなどが必ず出てくるのだが、PHP はなぜか全部平等に扱われたままである。そんなわけないやろ、とツッコミたくなる。

余談だが、PHP はマニュアルが充実してしまっている分、動かして確認している人が少ない感じがする。動かして確認していればあり得ない嘘を再生産しているサイトが多いなぁという印象。

PHP 4 と 5 の違い < Perl 5 と 6 の違い

つかまぁ、Perl 6 は pugs であってもいじったことはないので知らないのが正直なところですが、ちらっと文法を眺めた限りでは Perl 6 を持ち出してまで叩くほどの違いはないと思う。

Perl 4 〜 5 の時代も経験しているのでそれと比較すれば、ドッコイドッコイか、少し PHP 4 から 5 の移行の方がヘビー。ってくらい。ただし Perl 4 から 5 への移行と同じく、メリットがかなり多い。

MVC の V しか書けない?

そんなわけないが、面倒くさい。バックエンドは Ruby で書きたくなる。

結局のところ、関数一発で書けない処理は書きにくいのだ、PHP は。Pear があるって言っても、あまり感嘆するようなライブラリはなかったりする。いやテメーで書けと言われたらシンドイからヤダって言うけど、なんつーかこう、他の言語では「なんて超絶すげーライブラリなんだ!」と思うようなものがあるのに、PHP ではそういう感動を覚えることがほとんどないのね。

自分でライブラリを書き始めると、Perl って自由だなぁ、とうらやまくしくなることもあります。マジな話。

まとめというか

フレームワーク全盛の今、PHP のメリットはけっこう薄れてきていると言える。以前 違いは作業環境的な面だと思うんだな で書いたときに比べると

  • フロントコントローラ方式なら実行ビットの必要なファイルは 1つだけなので、そこら辺がルーズでもよいと言う PHP のメリットはなくなる
  • ブラウザ上で back trace できるのは素の PHP の何倍も便利

てな感じ。

ただ。

フレームワークを日曜大工スクリプトに応用しちゃうと基本的に重たくなる一方だし、アクセラレータがない環境ではそんなに嬉しくないだろうことを思うと、手軽に使ってサクサクと動的なページを高級 SSI 程度の感覚で作って行く分にはやはり PHP 最強だなと思う*2

プロが仕事の道具として使うには微妙なところがいくつもあるんだろうけど、そこら辺も Debian のようにバージョンを fix したうえでパッチを提供してくれるディストリビューションを使う、あるいはそういうサービスを使うという選択肢も当然あるわけで、プラスして IDE でコード品質の統一をはかりやすいという部分もやはり大きいかなと。Zend もeclipse も頑張っているわけだから、その成果を使えばよいのではないかと。

ただそういうプロダクト頼みっていうところがなんとなくオープンソース万歳、フリーソフト万歳な他の LL と違うっていう感じはする。なんというか言語そのものというよりは文化の違いと言うか。例えば PHP が好きになれない人はたぶん VB も好きになれない人だと思う(自分はそう)んだけど、それって結局「お仕着せのツールを使ってる分には楽」っていう、制限された堕落さにあるんじゃないかという気がしている。工夫の余地がないというか、ハッカー的においしくないというか。

Perl で Perl を、Ruby で Ruby を、JavaScript で JavaScript を拡張できる、書きやすくできるってのはやはりものすごく「オレってばスゲー感」が前面に出てるわけ。その快感をあまり PHP から得ることはできない、という感じはする。

ただ。

同じ「使わなきゃいけない状況」になるのであれば、絶対に Perl より PHP の方がいいな。自分が書き手の場合は。力量を図るためにあえて求人のメインストリームから外れた言語を使わせる場合は「Perl + CPAN モジュール + コーディングスタイル」よりは Ruby か Python にすると思う。コーディングスタイルまで含めるなら Python がいいのかねぇ。書いたことないけど。

しかし元記事のコメント欄、釣れてるなぁ。

Tags: PHP

*1 よく似た機能が違う名前で提供されている、名前も機能もよく似ているのに引数の順番が違う、など。ここら辺はデザインセンスのなさというか当初からの言語デザインの中心を担う人やチームがいないんだなーという印象が強い。

*2 別に悪い意味で言ってるわけではなくて、例えば PHP と MySQL あるいは SQLite が動きますっていう環境は mod_perl が使える環境より圧倒的に普及しているわけで、どちらがより多くの Web サイトを豊かにできるかというとそら間違いなく PHP だと思う。言い換えるとビジネスチャンスも多い。