2004-12-27 [長年日記]
_ 変わりチーズ2種
変わったチーズを見つけた。
唐辛子好きにして醤油星人の私が食べないわけにはいかない。
同じ日に食べたわけではないけど、軍配はわさび醤油に上がった。さけるチーズの方はピリっと辛い感じがする以外はただのさけるチーズで、全体になじんでないのが敗因。（分かりきった話ですが、こりゃ個人的な好みの話でずぜ。）
ま、どちらも無理に食べるものではないと思うけど。
_ 違いは作業環境的な面だと思うんだな
企業システムにおけるPHP5の可能性 （Matzにっき）
思いつきだけだらだらっとメモ。
- まつもとさんがまた危険な橋を渡ろうとしているように見える(w
- きっと ishinao さんは大きな声で言わないだけでとてもよい回答を手に入れているはずだ。
なんか知らないリファラが増えててビビったのでお断り。自分の経験値は Perl : PHP : Ruby = 5 : 3 : 1 くらいでしかも利用局面が同じとは限らないので、それを加味して読むように。mixi ではどんな文脈で参照されているんだろう、どきどき。
- PHP はオブジェクト指向を知らなくてもまともに使えることが前提で、Ruby の場合はオブジェクト指向を知らなくても使えなくはないが、リファレンスマニュアルとか読もうとしたときにオブジェクト指向が分かっているか、他の言語に汚染されていないまっさらな状態かのどちらかでないとつらい。*1
- PHP は Unicode、半角カナを含め文字コードの扱いに悩む必要がなく、透過的に内部エンコーディングに変換してくれてとても便利。しかもこれは php.ini などに設定してあれば、コーディングする人はその機能の詳細を知る必要すらない。
- PHP はブラウザを裏切らない。CGI の場合、CGI としての最低限の機能を満たさないスクリプトのエラーは Apache のログを調べる必要がある。あるいはコマンドラインでごにょごにょ。しかし PHP はエラーがブラウザに出る。Unix 的な文化に親しみがない人間でも PHP はブラウザとエディタがあれば開発できる。これはレベルはともかく、PHP で Web アプリを開発する人の絶対数を相当に押し上げる効果があると思う。
- PHP は permission に厳密になる必要がない。CGI ベースの場合は x が落ちると最悪。でも PHP の場合は気にする必要がない。*2これは多人数で共同作業するときにかなり助かる。アプリケーションとして主張しない、「ちょっと高級な SSI」程度の頻繁に HTML ベースで更新する原始的なサイトにはとてもよくマッチする。
- phpdoc が javadoc みたいで、同じノウハウが通用するのがよい。phpdoc を生成するツールの完成度も高い。（ただし動作はトロい。）
- RDoc が標準添付されたとき、「おい、RD はどうした」と本気でめまいがした。
- でも使ってみてとても便利だったので今はどうでもよくなっている。
- PHP はマイナーバージョンアップに伴う挙動の変化が怖い。とても怖い。Ruby はその点結構安心。
- だから PHP ではやたらと wrapper を書くのが普通とされている。（ほんとか？とも思うけど。）
- PHP のコーディングはたるい。特に正規表現のからんだ文字列処理は Perl の流儀に慣れ親しんだものからすると気が遠くなるくらいにたるい。
- てゆーか正面切って書かれてるのを見たことがないが、PHP では標準の ereg と mb_ereg と preg で細かく挙動が違うんだぞ。*3面倒くさいじゃないか。しかも正規表現クラスとかないから普通の文字列扱いになってすごく面倒なんだよ！
- PHP のハッシュはなぜか入れた順番通りに取り出せる。なんか気持ち悪い。
- PHP はハナから HTML と混在するのが前提なのでテンプレートの意義とか考えずにとりあえずゴリゴリ書いてしまいがち。流行った頃の Perl 4 ベタ書き CGI スクリプトみたいなのが氾濫している気がする。チョー思い込み。
- てゆーか PHP だけ書いてるのにいちいち <?php ?> を書かなきゃならなくてウザイ。
- PHP は立ち上がりが速いので負荷の低いものを細かく繋いでいったときにかなり嬉しい。
- Ruby は mod_ruby にすると速いんだけど、mod_ruby は require したスクリプト掴んじゃうので開発中の場合面倒くさくね？*4 でも CGI だとなんかかったるいし、しかも CGI でも mod_ruby でも動くように〜とか考えるの面倒なんで、フレームワーク使いなさい。
- たぶん PHP と Ruby の関係は Pythonのパラドックス における Java と Python の関係に似ている。だから PHP の案件を見た人が「なんでそれ Ruby にしないの？」と言うのが普通な時代は（少なくともしばらくは）こない。
- PHP の良さはある一人のプログラマにとっての良さではなく、兵隊の集めやすさ、兵隊の仕立てやすさだと思う。
- でもそれは PHP の戦略だったわけじゃなくて結果的にそうなっただけだと思う。（PHP っていうか Zend 以前、Zend 以後とか分けて考えないとダメなんじゃないかな。）
言い訳。TrackBack を送らないのはこのサーバではプラグインが動かないからです。TrackBack を受け付けていないのは、自分が送れなくて受け付ける一方になっちゃうのがいやだからデス。
*1 こういう切り口はすでにオブジェクト指向どっぷり、Ruby どっぷりな人には反論できないのでフェアじゃないかもしれない。ただ自分はそうだったんだもん。でも反対に Ruby や Perl を経なければ自分はオブジェクト指向はよく分からなかったと思う。
*2 セキュリティ周りのことはとりあえず今は置いておく。
*3 もっと言うと PHP3 との互換性のためにある mbereg とも違ったりする。本当は mbereg は mb_ereg への alias として機能するはずなのに、途中でおかしなことが起きたりするんだから困りもの。こういうネタはマニュアルひっくり返しても分からない。PHP3 の頃から動いているシステムはバージョン上げるのほんと大変ですよ。
*4 これは mod_perl でも同じなんだけど、PHP の場合は掴むのは accelerator の仕事なので、mod_xxx で動かしながらの開発しやすさは実はちょっと違う。
mod_rubyでも、httpd.confで RubyRequire auto-reload と記述すると、更新されたものが自動的に読み込まれたと思います。mod_ruby付属のサンプルhttpd.confに書いてありました。
はい、その通りです。ただ、今はどうか分かりませんが私が試した当時は確実にリロードされるとは限らなかったように思いますし、auto-reload がデフォルト動作じゃないって辺りも加味して開発しやすさに差がある、と判断しています。
ポイントは「知っていれば解決できる」ではなく、「知らなくても期待通りに動いてくれる」というツクリになっているかどうかだと思うんです。