ソースコードの重要性

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

連中が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２連覇

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

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

性善説に基づいて設計されていたこと。埋め込まれたデータに

虚偽の情報が含まれていれば破綻する、学者の考えそうな設計

だった。その破綻を回避する仕様があれば、失敗はしなかった

かも？

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)エンジニアを

雇えていたとは思えない。

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とよく似ている。

推敲中...