2009年7月25日土曜日

「SIerの解体と再生」を読んで

>この不景気をきっかけに、発注側のユーザ企業に
>変わってもらいたい。
他力本願。根本的に間違ってる。

ユーザ企業の前にSIerが変わるべきだろ...。
とにかく数で押す人月商売からの転換が先。

人月商売の中では数が正義だから、真のプロ意識のない
「なんちゃってエンジニア」が生息できる。

少数の精鋭が頑張って多数のなんちゃってエンジニアを
支えるスタイルから少数精鋭スタイルへの転換。

数だけは揃えて後は現場にお任せがまかり通っていて、
現場に少数でも精鋭がいなければすぐに破綻する。

だいたい、精鋭だけを揃えれば10人もいれば納期内に
完成できるシステムを玉石混交(ほとんどはなんちゃって
エンジニア)で数倍の人数がいても納期内に完成できない
ケースがざらにある現状が異常。

これから数年のSI業界不況でなんちゃってエンジニアは
黙っていても淘汰されるだろうが...。

次に実装屋よりも設計屋が偉いという間違った思考回路
の是正。

実装屋と設計屋はベクトルが違うだけで本来その間に
優劣の違いはないにも関わらず、SIerの中ではクライアント
と会話して外部設計を行う設計屋が重視され実際の実装面を
担当する実装屋は軽視されてきた。

本来は車の両輪である筈の設計屋と実装屋、SIerの中では
設計屋のみが即席培養され実装屋は育成されてこなかった。
その結果、SIerの中には実装のプロがほとんど、いない。

外部仕様はそれなりに立派でも実装がヘタレで使い勝手の
悪いシステムが多数量産されてきたし、きているのが
現実。

実装屋と設計屋を対等に位置づけ、それぞれの社内での
職位を設計しなおすくらいの大変革が必要。

SIerの中で実装屋と設計屋を兼務するオールラウンダー
の育成はまず無理。

オールラウンダーの育成を目指しても、中途半端な
似非オールラウンダーができあがるだけ。

設計にも実装にも特化しない中途半端な似非
オールラウンダーが跋扈するから実装がヘタレで
使い勝手の悪いシステムが多数量産される結果
になる。

それなら、SIerの中で実装技術には疎いが顧客との
対話が得意で顧客の代わりに要求仕様・外部仕様を
纏める設計屋部門と実装技術に特化し内部仕様以降を
担当する実装屋部門を明確に分離するか別会社化した
ほうがよい。

そして、社内では設計屋部門と実装屋部門を独立採算
制にし、顧客に対しては設計屋部門と実装屋部門で
別契約にする。

SIerの中では設計工程と実装工程の責任を明確に分離
し、責任の所在を不明瞭にしたまま設計工程の失敗を
実装工程で補填する悪しき慣習をなくすことに繋がる。

独立採算制にすれば、設計工程で失敗があった場合、
設計屋部門から実装屋部門に金銭の移動が発生する
ことになるので、責任の所在を不明瞭にしたままとは
ならない。

設計屋部門と実装屋部門に分割すれば、設計屋部門は
外部設計のプロとして外部設計に特化し、実装屋部門は
実装のプロとして内部設計・実装に特化すればよくなり、
それぞれの部門でその部門に適した人材を育成すれば
よくなる。

現状、SIerでは実装のプロではない設計屋か似非オール
ラウンダーが実装の指導を行うので、実装のプロが育つ
はずがない。

ここでの外部設計は実装を意識しない表層の設計、
内部設計は実装を意識した深層の設計を指します。

更に無意味な中間管理職への過度のインセンティブ
の撤廃。

実務にほとんど従事せず管理だけを行う人員が
SIerには多すぎる。

PMにしてもPLにしてもマネージメントが上手いか
どうかの指標が一人歩きして、過度に評価されすぎ
ている。

PMにしてもPLにしてもその管理手腕が卓越していて
全体が上手く回っているのは稀、ほとんどの場合、
PMやPLが実務を割り当てる際にできる人間に本来
こなすべき量より多くの作業を割当、その人間を酷使
して、全体が上手く回っているかのように帳尻あわせ
しているケースが多い。

つまり、PMやPLの管理手腕が優れていてプロジェクトが
回るのではなく、できる人間(数人)がいてそこに作業負荷
を集中させることができるからプロジェクトが何とか
回っているケースが多い。

会社としてはプロジェクトの実態はどうでもよくて
プロジェクトが表面上、上手く回っていれば問題なく、
実際の管理手腕は問われない。特定の個人(数人)に
作業を集中させてその犠牲?でプロジェクトを回して
いるPMやPLであっても、高く評価されるし、されてきた。


推敲中...。

2009年7月9日木曜日

「PHPを叩く人にガツンと申し上げたい」を読んでふと...

ttp://d.hatena.ne.jp/higayasuo/20090707/1246940526

>すべての国民は何か一つ言語をマスターしなければ
>いけない。
>※ただしモテ言語に限る

日本国民の99%(?)はある特定のモテ言語をマスター
している。その言語の名は日本語、日本で一番の
モテ言語。

日本で2番めモテ言語は英語。

他国もまた、母国語と呼ばれるその国一番のモテ言語を
ほぼ全ての国民がマスターしている。

プログラミング言語は言語としてはどマイナー、
プログラミング言語にモテ言語と呼べるモノは
存在しない。

2009年6月18日木曜日

「梅田望夫にオープンソースを語るなとガツンと申し上げたい」について思う事

ttp://d.hatena.ne.jp/higayasuo/20090618/1245292543

梅田望夫は日本のオープンソースの現状を見抜いている
と感じる。

海外はよく知らないが、日本国内では、一部の熱狂的?な
OSS信奉者が作成物をOSSとしてリリースし、大半の
エンジニアはそのユーザとしてフリーライド(ただ乗り)
しているだけで、何ら還元を行おうとすることはなく、
OSSはフリーライド(ただ乗り)する(できる)ものだと
思っている。

>何か知的資産が生まれそうな萌芽がネット上に公開される
>と、そうしたことに強い情熱を持った「志向性の共同体」
>が自然発生して、そこに「集合知(ウィズダム・オブ・
>クラウズ)」が働き、有志がオープンに協力してある
>素晴らしい達成をなし遂げるといった公的な貢献──を育む
>土壌がありません。

これも本質をついている。

「志向性の共同体」という観点から見ると日本国内にも
発生し、数十人程度の規模にはなるもののそれ以上の
大きな規模になることはほとんどない。その程度の集合
から得られる集合知はたかが知れているので、現状を
変革していくような素晴らしいアイデア(orイノベーション
(変革))が生まれてこない。「志向性の共同体」が素晴らしい
アイデアを生み出す集合知の母体になる規模まで育っていく
ための土壌が日本にはないといっても過言ではないと思う。

集合知を生み出す母体となる集合に属さず、生み出された
集合知の恩恵に預かっているだけの存在が梅田氏のいう
ところの「志向性の共同体」に含まれることはない。

日本のオープンソースは日本の土壌に立脚したものではなく
日本の土壌には本来根付かない徒花のような存在、海外から
飛んできた種子が芽をふいて必死になって根を下ろそうと
している状態に永らくあり、オープンソースへの日本国内
での貢献者は徐々に増えてきているものの、それらの貢献者
はOSS信奉者かつエンジニアであり非信奉者あるいは
非エンジニアではない、日本にオープンソースの精神が
根付いているかというと、そうはいえないと思う。

OSS開発団体(者?)は志向性の共同体に含まれるが、
OSSを使っているだけでOSS開発団体(者?)と何の
接点(接触)も持たないor持っていてもバグ報告程度
でOSSに何の変化ももたらさないユーザは「志向性
の共同体」には含まれない。

「梅田望夫にオープンソースを語るなとガツンと申し上げ
たい」の著者は日本国内のエンジニア周辺という狭い範囲
内で考えていて、梅田望夫氏は一般人をも含む広い範囲
での日本国内を俯瞰しているので、そもそも批判にさえ
なっていないように感じる。

「梅田望夫に〜」の著者、イノベーション(革新)という
単語の誤用が多く、イノベーションとは何かを理解して
いないように見受けられる。イノベーション(革新)には
当たらないモノをイノベーション(革新)だと喧伝するから
外国人からは胡散臭さがられ相手にされない。

推敲中...。

2009年5月14日木曜日

狛犬もどきのスリム3について思うこと

今更ながら書いておく。

「軒先を借りて母屋を乗っ取る戦略」にでたのか...今更。

狛犬もどきのスリム3って要するに
Struts+狛犬もどきSpringアドオン(+α)、
新規性や革新性は感じられない。

GAE対応は現在をみているだけで(数年先の)
未来をみているモノではない。
GAE対応に関しては他のフレームワークも
対応に乗り出している(あるいは既に対応を
完了している)ので、直に陳腐化する。
数年先の未来でも色あせないモノを先取りして
はじめて革新的であるといえる。

DIコンテナがHOTなトピックだった(騒がれた)時代は
既に(とうの昔に)終わっている気がするのは自分
だけだろうか?

数年前(スリム3の影も形もない頃)に「プロダクトを
Springに対応させてSpringのユーザを地道に切り崩し
たら...」な文章を別の場所に書いたような気がする...。

そのとき、狛犬もどきのチーフデベロッパは
「著名人一本釣り大作戦」を展開していた記憶が...。
(本人たちにはそんなつもりはなかったのかもしれない
が、傍からみるとそのようにみえた。)

著名人を一本釣りすると、もれなくその著名人を
支持(崇拝?)するエンジニアが付いてくると...
そんな都合のいい(美味しい)話はない。

JavaにおけるDIコンテナの世界的デファクト
スタンダードはSpring、2番手はGuice?、
3番手はEJB3コンテナ?。
日本国内だけがDIコンテナについてもガラパゴス状態
で、狛犬もどきがSpringといい勝負をしているらしい。

海外では狛犬もどきの知名度がないに等しいのは
言わずもがな。

海外で狛犬もどきの知名度がない理由は
簡単で英語のドキュメントを整備しなかったから。
その結果、欧米のエンジニアには見向きも
されなかった。

英語のドキュメントを整備していないのは、
「英語圏の人間に日本語のドキュメントを読め」
と言っているようなもの。律儀に読む人間が
数人はいるかもしれないが、ほとんどの欧米人
には相手にもされない。

スリム3を引っさげて海外に挑んだとしても
英語のドキュメントが整備されていなければ
勝負にならない。

英語のドキュメントを整備しておけば
少しは欧米のエンジニアの気を引ける
かもしれない...。
英語のサポートMLも必須...。

狛犬もどきの開発者はSpringとの差異を強調して
おきながら、「海外のSpringユーザはドキュメントが
なくても狛犬もどきに移行できる」と思っている
感じがある。

ちなみに...狛犬もどきの英文ドキュメントの不足に
関しても数年前に書いた気がする...数年たっても
状況はほとんど改善されていない...。

狛犬もどきのプロダクトはドキュメント
なしで直感的に扱えるようにはなっていない
(直感的に扱える(サンプルを見ただけで使い方
がわかる)程、単純ではない)。

ソフトウェアの作者はえてして自分(たち)から
みて直感的だから(作者の欲目で)他人からみても
直感的であると思いがち。

狛犬もどき開発団体自体がアカデミックな組織
ではないので、英文ドキュメントの整備という
効果が目に見えない一見無駄にみえる
作業はしない方針なのかもしれない。

#スリム3よりスライム3か、DQ的には。

2009年5月10日日曜日

JCPを主導する企業(Sun)は慈善団体でも慈善事業をしているのでもない

TCKがタダでないこと を理由にJCPを非難するOSS信奉者は
Sunが営利事業をしていることを失念しているとしか 思えな
い。

OSS開発団体がJAVAのTCKを引き取って(無償で)
エンタープライズで要求されるレベルの品質を 保ちながら
メンテナンスできる状態にありJAVAのTCKのメンテナンス
を引き受けようとしているのなら、JAVAのTCKをOSS開発
団体に委ねないJCPを非難する理由になる。

しかし、現状ではエンジニアを雇ってJAVAの TCKの品質を
維持するのはSunの責任であり、 自分たちはその責任を
肩代わりはしたくない、責任は肩代わりしたくないがTCKは
無償(タダ)で使わせてくれて 当たり前だとJCPを非難する
OSS信奉者が主張しているようにしかみえない。

SunはJAVAのTCKや純正VMの品質を維持するために必要な
コスト(の一部)をTCKのライセンス料でまかなっている。
JAVAのTCKを無償にした場合、Sunは無償にすることで
発生する損失をどのようにして補填すればいいのだろうか?

Sunは純正VMの開発やTCKのメンテナンスにおいて泥臭い
部分のほぼ全てを一手に引き受けている。

泥臭い部分というのはバグ取り等の心の中で誰もやりたく
ないと思っている作業を主に指します。

JCPを非難するOSS信奉者はSunにオンブにダッコして
もらっている状態で自分たちに都合の良い状態にしてくれ
と主張しているようにしかみえません。

Apache HarmonyがSunの純正VMと同じレベルの品質を達成
してその品質を維持し続けることができる(Sunの純正VMが
なくなってもApache Harmonyで代替できるので問題ない)
とOSS信奉者は言い切れるのだろうか?

Sunの純正VMはSunという企業が検証や品質のチェックを
行ってから公開しています。特定の企業による品質補償?
があることでユーザは独自の検証や品質のチェックを簡略化
して行い利用することができています。また、特定の企業に
よる品質補償?があることがJAVAを採用する上での安心感
になっているというのもあると思います。

ちなみにOpenJDKの大部分はSunのエンジニアによって
開発・メンテナンスされている状態です、OSSコミュニティ
がOpenJDKの開発を主導しているわけではありません。

Apache HarmonyはApache Foundationが公開します、
Apache FoundationはOSS開発に特化した非営利団体です。
検証や品質のチェックは公開前にApache Foundation内で
行われますが、品質の補償はありません。
Apache Harmonyの場合、安心感を欲するなら、有償で
品質補償を提供する企業から、品質補償という安心を買う
事になります。

特定のOSS開発団体を特別扱いしてTCKを無償でライセンス
することもできません。

特定のOSS開発団体を特別扱いしてTCKを無償でライセンス
すれば、TCKを有償でライセンスしている企業が独自のVM
開発を破棄し特定のOSS開発団体の開発するプロダクトに
合流しようとするのが目に見えているからです。

特定のOSS開発団体を特別扱いしてTCKを無償でライセンス
することは営利企業がそのOSS開発団体を介してTCKを無償
利用することに直結します。

そうなれば、TCKのライセンス事業は破綻し、SunはJAVA
に費やしているコスト(の一部)を補填する事ができなく
なります。

SunがOracleに買収されたからといって、OracleがJAVAの
TCKの品質を維持しながらメンテナンスすることになるの
なら、JAVAのTCKが無償でライセンスされることはまず
ありえません。

OracleもSunと同じく慈善事業をしているわけではない
のがその理由です。

TCKを今後どのような体制で開発・メンテナンスしていく
のか、OpenJDKを 含めJavaVMのリファレンス実装を
今後どのような体制で開発・メンテナンス していくのかは、
JCP内外でコミュニティが議論していくべき課題だと
思います。

推敲中?

#以前、同じような内容の文章を別の場所に書いたことがあるが
#また書いている。

2009年5月2日土曜日

既存システムのクラウド化はほとんどの場合、必要ない

GAEマンセー、既存システムはクラウド化すべき、RDBMSを捨て
全てをMapReduce・BigTable(あるいはHadoop等の代替品)で行う
べきと主張しているように読める文章を読んだ、電波以外の
何物でもない。

既存システムの担う処理のうち元来RDBMSで扱うには無理のあった、
大量のデータを並列で分析する処理にクラウドの要素技術を適用する
というのはありだと思うが、RDBMSに向いている処理はは今まで
どおりRDBMSを利用すべき。
クラウドの要素技術であるMapReduce・BigTableは大量のデータを
複数のマシンを用いて並列で分析する処理に特化して設計されている
ので、RDBMSが得意とする処理の多くには向いていない。

MapReduce・BigTableの有効性を世界に発信したGoogleがこれらの
技術とRDBMSを併用していることを鑑みても明かなように、
MapReduce・BigTableの特性を無視してこれらの組み合わせが
RDBMSよりも優れていると考えるのは馬鹿げている。

GAEでRDBMSが提供されていないのは、RDBMSがユーザの手許に
既にあるから、RDBMSが必要であればユーザは自前で準備することが
できる。Googleはユーザの手許にないクラウドの要素技術のみ提供する
ことでGoogle社内のハードのリソースを節約していると考えるのが
妥当ではないかと思う。
MapReduce・BigTableが優れているからRDBMSは必要ないと
Googleのエンジニアが判断してRDBMSを提供していないのではない。

Googleのエンジニアが思いもつかない用途でMapReduce・BigTable
等クラウドの要素技術を活用するアプリがGAE上に構築されるのを、
Googleは期待していると思われる。

推敲中。

2009年4月26日日曜日

ソースコードの重要性

処理速度等の差別化要素をないがしろにし気にもとめない
連中がSI屋を中心に多いから、仕様書さえあれば誰でも
全く同じシステムをくみ上げることができる という間違った
認識が日本国内に蔓延る。

今やその認識は世間にまで広がっている?

プログラマーの技量によって全く同じ仕様書から別物といっても
過言のないくらい、性能等の異なるシステムが組み上がってくる
ことにいい加減、 気づいてもいいんではないかと思う。

仕様書を渡しても全く同じものはできない、ソースコードを渡せば
同じものを いくらでも複製できる。

ソースコードと新幹線の部品を同じ尺度で考えるのは全くの間違い。

ソースコードを渡した場合にそのコードが民間に流出しない
保証は何処にもない。

中国政府を信頼すること自体馬鹿げている、保険となる機密保持契約
の締結を、最低限、中国政府に求めるべき。

中国は偽造複製品王国、中国政府に何の保険もなしにソースコードを
渡せば山程偽造複製品が作られる結果しか後には残らない。

機密保持契約を結んでおけば、例えその相手が政府であっても
契約を守っていなければ訴訟を起こし勝訴することができるので
もしものときの保険にできる。

中国政府が開示を求めているのは基幹ソフトウェア、つまり
ドル箱、機密保持契約を結ばずに開示に応じる企業がある
はずがない。

中国は世界の中心ではない。中国の要人や官僚に未だに
中華思想が蔓延っているから、馬鹿げた発想が出てくるのだろう。

中国政府が機密保持契約を結ばずにソースコードの開示を求めようと
すれば、中国自体が大打撃を受ける結果になるだろう。

ソースコードの開示を強要すれば、世界中の企業が中国に最先端より
数世代前の製品しか輸出しないようになるのが誰の目にも明らか、
数世代前の製品ならソースコードを開示してもダメージにはならない
のがその理由。

2009年4月6日月曜日

続・Perl6は何処にいった その2

3月中旬にParrot1.0がリリースされた。

但し、1.0は中間コードコンパイラ作成者に
向けたベータ版的なリリースで安定板は
2010年7月リリース予定の2.0までお預け。

LLVMとParrotは似て非なるもの、Parrotが
動的言語をターゲットにバイトコードを設計
しているのに対し、LLVMはC・C++等の
静的言語を主なターゲットにしておりLLVM
用の中間コードはParrotのものよりもずっと
機械語(アセンブリ)に近く、静的言語を様々な
タイミングにて最適化できるように作られている。

Parrotをバイトコードインタープリタとして捉えた
場合、最適化の方向性に疑問が残る。

OO言語と手続き型言語を同じバイトコード
インタープリタで扱うのは効率が良いとは
思えない。

CLR、RubyVM、Java、JavaScript用VMの何れに
ついてもOO言語に最適化する方向でバイトコードを
設計している。

OO言語と手続き型言語を同じバイトコードで
扱おうとした場合、手続き型言語かOO言語の
どちらかにあわせてバイトコードを設計する
ことになる。
手続き型言語に合わせた場合、OO言語を内部的
に手続き型言語に変換してからバイトコードに
落とし込む事になる、一旦バイトコードに変換
してからは高速に動作するもののバイト
コードに落とし込む際のオーバーヘッドが
馬鹿にならない。
OO言語に合わせた場合は手続き型言語を内部的に
OO言語のように扱いバイトコードに落とし込む
ことになる、OO言語は手続き型言語の特徴を内包
するのでバイトコードへの変換時のオーバーヘッド
はそれほどないものの、手続き型言語に合わせて
バイトコードを設計した場合に比べると実行時の
オーバーヘッドがそれなりにある。

OO言語と手続き型言語を両方とも上手く
扱うためにはバイトコードの設計が重要であり、
どちらかに特化した場合よりも複雑になると
思われる。

OO言語と手続き型言語の両方に上手く最適化された
動的言語用VMは今のところ、存在しない。Parrotが
初のそんなVMになるとは考えにくい。

RubyVM、Java、JavaScript用VMの何れにしても
特定の言語に特化させる形でバイトコードを設計
し、処理速度面で成果を上げている。

CLRは汎用性を追求する形でバイトコードを設計
しているため、それぞれの言語についてはその
言語へ特化した場合よりも処理速度面で劣ると
思われる。

汎用性を持たせてバイトコードを設計するよりも
個々の言語に合わせてバイトコードを設計する方
が動的言語では性能的に有利ではないかと思う。

現にParrot上に実装されたメジャーな言語の実行
環境はどれも現状では各々の言語に特化して実装
された実行環境と同等の性能を達成していない。

PythonのParrot正式採用の可能性が報じられていた
時期もあったが、今やその可能性は著しく低いという
か、ないに等しい。 unladen-swallow というPython
実装の高速化プロジェクトでは既にCPythonをベース
にLLVM利用型VMの開発を開始している。

Ruby界隈ではAppleによるRuby1.9互換(?)実装MacRuby
の開発チームが次期リリース(0.5)に向けてCRubyを
ベースにLLVM利用型VMの開発を開始している。
日本国内では有志によりYARV中間コードをLLVM中間コード
に変換するJIT(?)コンパイラyarv2llvmの開発も行われている。

LLVMは静的言語をターゲットにしてきているが、
動的言語をどのようにサポートするかもプロジェクト内で
議論されている模様。

Parrotは開発に時間が掛かりすぎている感がある。

Parrot開発開始当初には影も形もないに等しかった
LLVMに先を越された感がいなめない。

Parrotがその安定版の開発に1年以上の時間を掛ける間に
LLVM利用型の動的言語実行環境の実現に道筋が出来上がる
だろう。

つづく...推敲中

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ユーザに納得させるのは
難しい。そのような仕様を導入しても利用されずに終わる可能性大。


2009年2月15日日曜日

続・Perl6は何処にいった

昨年末のアルファ版リリースはならなかったようだ。

Perl6用でも使用されるParrot VMは先月23日に0.9がリリースされ
現在は3月の1.0リリースに向け、開発中。(こちら)。

少なくともPerl6はPerl6自体の中間コードコンパイラとPerl5互換の中間
コードコンパイラの両方が実用レベルで動作する必要があるため、この
2つが実用レベルで実装されるまでリリースされない。いつリリース
されるかは已然不明。

中間コードコンパイラは任意の言語をParrotバイトコードに変換する
コンパイラをここでは指します。

Perl6は複数の言語を利用できる夢の言語のようにPerl6使いの間では
思われていた節もあるようだが、この夢物語を現実にするには、それ
ぞれの言語に対して中間コードコンパイラが必要であり、実用レベル
の中間コードコンパイラのある言語は何処にも存在しない現状では
当分の間は夢物語になりそうである。最低限必要なPerl用のコンパイラ
でさえ実用にほど遠い現状では。

Parrotは実装が開始されてから、かなりの年数がたっており、先進的な
VMとはよべなくなっている。

Parrotは今や数あるVMの一つにすぎず、他のVMを圧倒する性能と
いうわけでもない、Parrotに格別の思い入れのあるエンジニアでも
なければ、Parrot用コンパイラを書く事はないと思われる。

それを証明するかのようにPerl以外のParrot用コンパイラの実装は
遅々として進んでいない(実験的なモノを除く)。

Parrot.orgのlanguagesのリストに記載されている中間コードコンパイラ
のほとんどは実装途中で開発が停滞・停止あるいは放棄されている。

Parrot用にPerl以外の言語の言語仕様を満たすコンパイラを書く
ことに意義を見いだすエンジニアがこのさき、多数出てくるか
甚だ疑問。

以前、Perl6はParrotVMへの移行よりも現行VMベースでの実装を
先行したほうがいいのでは、と書いたが、現行のPerl5系をParrotVM
上に実装、Perl5.12(?)として公開してからPerl6を進めるのが現実解で
あると今は思う。

Perl5系のParrotVM実装(5.12)、PerlのOO言語化(6.0)、現行のPerl6
仕様のOO言語化以外の機能の実装(7.0?)くらいが妥当ではないだろう
か?

Rubyの場合、アグレッシブな変更を伴う予定で仕様の確定しない
Ruby2.0を先送りし、代わりに1.8仕様の改良版をYARV上に実装する
現実解を開発陣が選択した。それが功を奏し、安定板である1.9.1が
既にリリースされている、1年以内に実運用に耐える段階に達する
だろう。Ruby2.0で予定されていた機能が1.9系に取り込まれながら、
段階的に2.0(理想形?)に近づいていくと思われる。

Perl開発陣もPerl6のリリース時期が確定できないのなら、現実的な
ロードマップを模索してはどうだろうか?