July 24, 2005

25時間TVをみながら久々に２ちゃんねるのWebプログラム板見てたら、PHP vs JSPという話があった。

さらに、そこからRubyの方のblogへのリンクがあって、PHPが流行った理由に対する疑問を呈する話が書いてあって面白く読んだ。２ちゃんのスレは最初の方は随分レベルの低い話で、２ちゃんもレベル下がったなぁとか思ってたが、最後の方から読んだら結構楽しかった。

■Javaの人達は考えすぎ。フレームワーク主義は、諸刃の剣。

昔、Javaの本見てたら、NECの人のインタビューがあって、「EJBぐらい使えないと採用できない。多くの人はEJBは知ってる程度。ほとんどServletまでしかわからないから困る」的な話が載ってて、そりゃそうだろうなぁ、あれ、その仕事にどっぷり浸からない限り、身につけるの無理だろと思ってたんだが、そんな感じ（意味不明）、つまり未経験者は永遠に未経験になりかねないジレンマ

つまるところオブジェクト指向だからって、約束事を増やさないとか、半端にブラックボックスにしないとか、深い階層にするなってことにつきるのかな。

ちなみに最近、Struts使ってますが、ページごとに思考を独立して考えられる感覚が気にいったかも。まだそういう段階なんで、DICONは次のステップで。

そんな奴が偉そうなことを言うなという話があるが、フレームワークってのは、要は先人の知恵ですがドキュメントを読む努力をしないと、全然ダメってのも結構辛いところもある。

特にフレームワークがよくできていればできているほどドキュメント量が増えて、それ自体が、ついていけない罠。最終的に生き残るのは一番努力せずとも、わかりやすい奴かと。

開き直ると、決して人はドキュメントでコミュニケーションするものじゃないんで。

人間ってエレガントさと、ベタな努力のどっちを取るか？って、人まちまちなんですよね。エレガントにしすぎると理解に知識や経験が必要、敷居が高い、ベタなものを作ると、量は増えるは、統制取れないわ、ワケわからんわ、でも理解するために必要な知識は低く済む。

どっちが悪いかというとわからないな。現実のプロジェクトを前に理想論では語れない。

少なくともプロジェクトで、新しいフレームワークを広めようとするなら、どんなに優れている技術でも、アーキテクト的役割の人が頑張って啓蒙していく努力はしないとだめ。決してドキュメントがコミュニケーションしてくれるわけじゃないですから、一般論はさておき現実には仕様書読め、以上、はマズイ。そういう役割の人がいると、必ず周りはその人に期待します。もし、そういう立場になったら、必ず意識していますが、そうやってコミュニケーションして広めていきましょう。（なんのこっちゃ）

■PHPの良さって。
Web＋DBに特化した言語と言うか標準ライブラリがあるからだと思うけどなぁ。VBっぽいとこ。もちろん、性能が高いというのも採用する決め手だと思うが、誤解を恐れずに言えば、ベタなプログラムを書くための参入障壁が低い。

とはいえ最近はsmartyやらライブラリを学ばなくてはいけない壁が増えてきて、最初の頃の魅力とズレが出てきたという話は納得かも。

まぁPerlもCPANが使えるのは当たり前的な感じみたいだし、そんな時代と言えばそれまでなんですけど。コンポーネント志向の理想と現実って奴なのかな。

プログラマーとしてやっていくために、言語に捕らわれない技術を持っていなくてはいけないという話があるんだけど、でも現実にどんな言語でも使えるのか？っていうと、先のコンポーネント志向やフレームワークなどの言語の上位に来る概念知識、経験がなくてはダメという時点で、実は簡単には使えなくて、いかにその言語や技術にコミットしてきたか？こそが重要になるという意味では、簡単に人材の確保ができないことに繋がるわけでして。

人材採用などで人材に求められる基準が、PHP + PEARは当たり前とか、Perl + CPANは当たり前とか、Java + J2EE + Struts + Hibernate当たり前とかってなると、なんか本末転倒かもしれないなぁと。

明日のプロジェクトから必要な人材だったら、そのままリスクにもなりかねないので、結局、メジャーな組み合わせにしとけってことなんだと思いますが。

タイトルに vs Rubyと書いておきながら知らないので触れられませんが、これまでの話に含まれてるかな。何にプライオリティを置けるかという組織の問題だったりもしますね。こういうのは。