#acl SomeUser:read,write All:　 read
= Lightweight Language Lovers =
== PythonとRubyを比較してみる(JRubyの可能性) ==

メインフレーム上のCOBOL というと、LLをお使いの方の眼には、まったく融通のきかない対極の存在のように映るかも知れません。
実際、ちょっとした抽出条件の変更でもコンパイル&リンクが必須ですし、変数がまたすべてグローバル変数なので何かと気を使い、全くと言っていいほど「軽さ」はありません。

しかし、私の触っていたIBMのCOBOL環境では、実行時に、内部ソートで呼び出されるDFSORTというソート専門プログラムに以下のようなパラメータを追加で指定することができました。
{{{
INCLUDE (1,2,CH,EQ,'A1',OR,1,2,CH,EQ,'B1')
OMIT (10,1,CH,EQ,'1')
}}}
これは、「1～2桁目の文字項目が'A1'または'B1'のレコードのみ含み、10桁目が'1'のレコードは除外する。」と読みます。この条件は','で区切って自由に続けることが出来ます。この機能のおかげで、例えば「部署コードの○桁目が○のみのリストを大至急」みたいな突然の要求にも対応ができたのです。このことから、
 ''実行時にミニ言語で指示を与えることができると極めて柔軟性が高くなる''
ことが分かります。アプリケーションプログラムは通常、必要と思われる条件を想定してパラメータ化しておく訳ですが、こうしておくと想定外の条件に遭遇した場合、コンパイラ型の言語でもプログラムの変更とコンパイル無しに対応できるわけです。

JRuby なら新たに専用の言語を設計することなく、この「ミニ言語」になることができます。現在の「COBOL」は Javaです。一方、Ruby は DSL としての側面が非常に注目されていますので、この組合せは非常に可能性があるといえるでしょう。この例として、
[http://www.ibm.com/developerworks/jp/java/library/j-javascripting2/index.html: 動的言語を動的に呼び出す、第 2 回: 実行時にスクリプトを発見し、実行し、そして変更する] はとても参考になります。

また、一般に、コンパイラ型の言語はインタプリタ型言語に比べて実行性能の面では有利ですが、柔軟性は低くなります。[[BR]]
一方、インタプリタ型言語はその逆です。なので、
 ''コンパイラ型の言語で書かれたプログラムに対し、柔軟性が必要な部分だけインタプリタ言語が使えれば両方の長所を組合せられるのでは?''
とも考えられます。

ここでは、Java の GUI(Swing) からスクリプトを呼びだすことを行います。[[BR]]
「それだけ?」と思わないでください。仕事でLLを活用し始めると、最初の内は良いのですが、すぐにスクリプトファイルが一杯になって、どれを選んでよいか分からなくなりがちです。これを GUI でまとめておくと、
 1. 手順書を書く代わりに GUI のパネルに説明を書くようにすれば、DRY が実現でき、プログラムとドキュメントがずれる恐れも無くなる。
 1. 急ぎの時など、うっかり古いバージョンのスクリプトを実行してしまうミスを防止できる。
といったメリットが期待できます。

なぜわざわざ Java を使うのかですが、一言で言えば、Netbeans の GUIエディタが非常に使い易いためです。LLにも様々な GUIツールキットがあるのですが、どうしても馴染めませんでした。

----
CategoryPython CategoryRuby