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

今更ながら書いておく。

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

狛犬もどきのスリム３って要するに

Struts＋狛犬もどきSpringアドオン(＋α)、

新規性や革新性は感じられない。

GAE対応は現在をみているだけで(数年先の)

未来をみているモノではない。

GAE対応に関しては他のフレームワークも

対応に乗り出している(あるいは既に対応を

完了している)ので、直に陳腐化する。

数年先の未来でも色あせないモノを先取りして

はじめて革新的であるといえる。

DIコンテナがHOTなトピックだった(騒がれた)時代は

既に(とうの昔に)終わっている気がするのは自分

だけだろうか？

数年前(スリム３の影も形もない頃)に「プロダクトを

Springに対応させてSpringのユーザを地道に切り崩し

たら...」な文章を別の場所に書いたような気がする...。

そのとき、狛犬もどきのチーフデベロッパは

「著名人一本釣り大作戦」を展開していた記憶が...。

(本人たちにはそんなつもりはなかったのかもしれない

が、傍からみるとそのようにみえた。)

著名人を一本釣りすると、もれなくその著名人を

支持(崇拝？)するエンジニアが付いてくると...

そんな都合のいい(美味しい)話はない。

JavaにおけるDIコンテナの世界的デファクト

スタンダードはSpring、2番手はGuice?、

3番手はEJB3コンテナ？。

日本国内だけがDIコンテナについてもガラパゴス状態

で、狛犬もどきがSpringといい勝負をしているらしい。

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

言わずもがな。

海外で狛犬もどきの知名度がない理由は

簡単で英語のドキュメントを整備しなかったから。

その結果、欧米のエンジニアには見向きも

されなかった。

英語のドキュメントを整備していないのは、

「英語圏の人間に日本語のドキュメントを読め」

と言っているようなもの。律儀に読む人間が

数人はいるかもしれないが、ほとんどの欧米人

には相手にもされない。

スリム３を引っさげて海外に挑んだとしても

英語のドキュメントが整備されていなければ

勝負にならない。

英語のドキュメントを整備しておけば

少しは欧米のエンジニアの気を引ける

かもしれない...。

英語のサポートMLも必須...。

狛犬もどきの開発者はSpringとの差異を強調して

おきながら、「海外のSpringユーザはドキュメントが

なくても狛犬もどきに移行できる」と思っている

感じがある。

ちなみに...狛犬もどきの英文ドキュメントの不足に

関しても数年前に書いた気がする...数年たっても

状況はほとんど改善されていない...。

狛犬もどきのプロダクトはドキュメント

なしで直感的に扱えるようにはなっていない

(直感的に扱える(サンプルを見ただけで使い方

がわかる)程、単純ではない)。

ソフトウェアの作者はえてして自分(たち)から

みて直感的だから(作者の欲目で)他人からみても

直感的であると思いがち。

狛犬もどき開発団体自体がアカデミックな組織

ではないので、英文ドキュメントの整備という

効果が目に見えない一見無駄にみえる

作業はしない方針なのかもしれない。

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

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内外でコミュニティが議論していくべき課題だと

思います。

推敲中？

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

#また書いている。

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

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は期待していると思われる。

推敲中。

ソースコードの重要性

処理速度等の差別化要素をないがしろにし気にもとめない

連中がSI屋を中心に多いから、仕様書さえあれば誰でも

全く同じシステムをくみ上げることができる という間違った

認識が日本国内に蔓延る。

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

プログラマーの技量によって全く同じ仕様書から別物といっても

過言のないくらい、性能等の異なるシステムが組み上がってくる

ことにいい加減、 気づいてもいいんではないかと思う。

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

同じものを いくらでも複製できる。

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

ソースコードを渡した場合にそのコードが民間に流出しない

保証は何処にもない。

中国政府を信頼すること自体馬鹿げている、保険となる機密保持契約

の締結を、最低限、中国政府に求めるべき。

中国は偽造複製品王国、中国政府に何の保険もなしにソースコードを

渡せば山程偽造複製品が作られる結果しか後には残らない。

機密保持契約を結んでおけば、例えその相手が政府であっても

契約を守っていなければ訴訟を起こし勝訴することができるので

もしものときの保険にできる。

中国政府が開示を求めているのは基幹ソフトウェア、つまり

ドル箱、機密保持契約を結ばずに開示に応じる企業がある

はずがない。

中国は世界の中心ではない。中国の要人や官僚に未だに

中華思想が蔓延っているから、馬鹿げた発想が出てくるのだろう。

中国政府が機密保持契約を結ばずにソースコードの開示を求めようと

すれば、中国自体が大打撃を受ける結果になるだろう。

ソースコードの開示を強要すれば、世界中の企業が中国に最先端より

数世代前の製品しか輸出しないようになるのが誰の目にも明らか、

数世代前の製品ならソースコードを開示してもダメージにはならない

のがその理由。

中国によるソースコード強制開示報道に踊らされるのはまだ早い

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

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

但し、1.0は中間コードコンパイラ作成者に

向けたベータ版的なリリースで安定板は

2010年７月リリース予定の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利用型の動的言語実行環境の実現に道筋が出来上がる

だろう。

つづく...推敲中

OO言語における処理速度向上

　ASIPのRubyistなるままに

日本、WBC２連覇

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