笹田氏によるVM実装YARVがRiteでに採用されることは以前報じましたが、
現在はmatz氏がRiteの実装、YARVの改良に着手されている模様。
RailsWEBスタックの生産性が現在、ruby界隈で前面に押し出されている格好ですが、
Railsの生産性は言語により支えられているということを忘れては本末転倒。
現在、JavaがRubyに対して優位にたてているのはパフォーマンスくらいのもの。それも
Riteの登場により揺らぐことがほぼ確定...。
Rubyを含むLLの持つ生産性の高さは90%LLの言語仕様によるもの。言語で生産性がほぼ
決定されるのに、LL以外の言語においてFWスタックで生産性を多少向上させたからといって
LLのFWスタックの生産性と比較して何になるのか疑問。
言語特性の異なるモノ同士を比較して云々するのは意味がないんですが...。
RubyはRailsの登場により一躍、LL言語レースにおいて勢力を拡大しましたが、PHP・Perlに
較べてまだまだ少数派なのが現状。OO言語をインタプリタで実装しているので、Perl・PHPと
較べてパフォーマンスが出にくいことが陰を落としているのだと思います...。
Perl・PythonサイドもRailsに手を拱いているわけではありません。PerlはCatalyst、Pythonは
TurboGearsを擁し、Railsを迎撃(追撃?)しています。
Riteの登場によるパフォーマンスの向上とRailsWEBスタック等による高い生産性の相乗効果
が実現した時、RubyはLL言語レースにおいてトップを走っているかもしれません。
#ここでの生産性は実装工程での生産性です。適用領域のほとんど異なる言語に対してシステム
#(設計〜実装)としての生産性を云々することに意味を見出せません。
最近、JavaとLLの違いで生産性ばかりが取りざたされていますが、生産性が嫌われる
理由の最たるものだとは思えません。
強いて言えば、Javaから漂う企業臭が嫌われる最大の原因ではないかと思います。
多少の生産性の改善を過剰宣伝するJavaスキーが多いのも原因の１つかもしれません。
言語仕様でほぼ決定されている生産性をFWスタックで多少向上させたからといって
大騒ぎするJavaスキーはLLスキーから白い目で見られていることを自覚すべきでしょう。
Rubyの設計者Matz氏が自身のブログで「Javaスキー(この場合、the Seasar Foundation)
による自分たちの作ったフレームワークの過剰宣伝に対してそれが何？」的な文章を
書かれていたのが思い出されます。
JavaスキーとLLスキーのシステム実装に対するスタンスの違いも忘れてはいけません。
Javaの嫌がられる理由でかなり上位にランクするモノを書き忘れてました。
それはJavaでWEBアプリを構築する場合のインフラの問題です。
インフラの問題の一例としてサーバの運用に掛かるコストを挙げておきます。
JavaでWEBアプリを構築する場合、何某かのAPサーバ(WEBコンテナを含む)が必要なため、
LLをサポートするレンタルサーバは数あれど、Javaをサポートするレンタルサーバはほぼ
皆無です。このため、必然的に"JavaでWEBアプリ"は専用サーバ必須です。
このインフラの問題がソフトウェア的には被る部分の多いWEB系でのJavaとLLの適用領域を
実際には殆ど被らないモノにしています。
現状のAPサーバではレンタルサーバでの運用が全く考慮されていません。この点が
改善されれば状況は変わるかも...。
つづく...。
#ここでの生産性は実装工程での生産性です。適用領域のほとんど異なる言語に対してシステム
#(設計〜実装)としての生産性を云々することに意味を見出せません。
->(on off)