2009年3月24日火曜日

日本、WBC2連覇

神様、仏様、イチロー様。イチロー、すげぇ、凄すぎる。

2009年3月22日日曜日

W3CのセマンティックWEBの失敗の原因の一つ?

性善説に基づいて設計されていたこと。埋め込まれたデータに
虚偽の情報が含まれていれば破綻する、学者の考えそうな設計
だった。その破綻を回避する仕様があれば、失敗はしなかった
かも?

2009年3月14日土曜日

PHPからRoRへの移行!?

Ruby/Pythonは構文の違いを除けば大した違いはなく、Perl5.xはOOでない
ことと構文の違いを除けばRuby/Pythonと大した違いはない。
PHPはRuby/Perlと類似の構文を採用しているものの、OOやスレッド等に
関して(言語仕様上の)扱いが大きく異なる、似て非なる言語。

海外でPHPからRoRへの移行プロジェクトが上手くいかない事例があった
のも頷ける。"Ruby/Python/Perl"と"PHP"の構文の類似性から軽く考えて
移行しようとすれば必ずといっていいほど失敗する。

設計・構築フェイズでPHPと"Ruby/Python/Perl"の言語仕様における違い
をきちんと把握し、ボトムアップ指向で移行していけば失敗には
繋がらなかったはず。

自分たちの"見識のなさ、見積もりの甘さ”による移行の失敗をRoRのせい
にし、「PHPのほうがRoRより優れている」と主張するようなエンジニア
は論外。

Ruby on Railsは万能ではない を読んで思った事を遅ればせながら
書いてみた。
上記記事の元ネタの著者が真に優秀なRails(Ruby)エンジニアを
雇えていたとは思えない。

2009年3月6日金曜日

PHPについてふと思った事

PHPはASPの模倣品として始まった(?)。
ASPがIISのモジュールとして実装されたのと同様に、Apacheの
モジュールとして登場。

PHPはリクエストに対して(X)HTMLやXMLを描画して返す事に特化した、
つまりMVCのうちV(ビュー)に特化した言語でありながら、現状は
その延命措置としてMVCのしくみを無理矢理PHPの世界に持ち込み、
大型システムに適用しているようにみえる。

PHPはその言語の特性上、スレッドという概念がない(スレッドが
実行環境によって隠蔽されている、リクエスト・レスポンスの一連
の流れが一つのスレッド上で実行されているものの、スレッドを
ユーザーが認識することはない)ため、スレッドを跨がって存在する
オブジェクトを言語構文上、定義することはできない、そのため、
外部モジュールと組み合わせるor実行環境を拡張することにより
オブジェクトのキャッシュ等をすることになる、自ずとPHP単体で
できることの自由度に限度がでてくる。

並列処理に関してもそう、curl_multi関数群を導入して、並列処理を
PHPの言語仕様の外側にある実行環境で対応しようとしている。

スレッドを跨がったオブジェクトのキャッシュや並列処理等をPHPは
全て実行環境に依存しているため、ユーザサイドが実行環境をいじらずに
自由に拡張・改良することはできない。

PHPユーザの多くに共通するのは、「PHPではこのようにしたら楽に
できる」ということは簡単に言えるけれど、PHPの実行環境が内部で
行っている処理については全くと言っていい程知らないため、「PHP
ではこうしている処理を他の言語でもこのようにすればできるよ」
ということができない点。
PHPユーザの大半は、PHPの実行環境の挙動を全く理解していないので、
PHPという閉じた環境の中では生息できるが、他の環境で生息できる
だけの適応力を養ってはいない。

有り体に言えば、PHPユーザの大半は「結果があっていればそれでOK、
結果に至る過程は我関せず」なタイプ。

PHPはプログラミング言語でありながら、実行環境により隠蔽された
部分が非常に多く、その点でVB6以前のVBとよく似ている。

推敲中...

2009年3月5日木曜日

LLの立ち位置をOSに例えるなら...

Ruby・Python・JavaScriptはLinux、様々なアイデアの実験場となり、
ユーザ数増加中。

PerlはFreeBSD、枯れていてコアなユーザもいるが、ユーザの更なる
増加は望めない。安定を優先するため、実験場にはなりえない。

PHPはWindows、その簡便性でユーザを一気に延ばしたけれど、言語と
しての進化は手詰まり、お手軽言語であることを売りにしたため、(先進的
で)マニアックな言語仕様を導入しにくいorできない。

Perlの場合、互換性を維持するための言語仕様上の負の遺産の継承がその
進化を阻害している(枯れて安定していることを優先して今まで大規模な
言語仕様の改訂を行ってこなかったことが言語としての進化を停めて
しまった)、今や大規模な改訂は大きすぎるイタミに直結する、そのため、
言語仕様上の負の遺産を滅するような改訂をもはや行えない、その時期
を逸してしまった。

現にPerl5.8とPerl6の関係はCとC++の関係よりもVB6とVB.netの関係
に良く似ている、Perl6のOOはPerl5.8の仕様のオブジェクト指向的
側面を見直し、多少、体裁を整えたようにしか見えない。
それでもVB6からVB6.netへの移行時にそのユーザが経験したイタミと
同種のイタミをPerlユーザは経験することになるだろう...。

Rubyのように言語仕様を段階的に改訂する場合、ユーザに多少の混乱は
与えるものの、大きすぎるイタミを伴う大規模な言語仕様の改訂をユーザ
は経験しなくて済む、それを最善とはいえないが...。

PHPの場合、言語仕様が成熟する前に、ユーザ数が急激に増加したことが
不運、お手軽言語として確立した地位を維持していく以外に道はない。
(先進的で)マニアックな仕様のメリットをPHPユーザに納得させるのは
難しい。そのような仕様を導入しても利用されずに終わる可能性大。