[DLR] VM魂でお見せしたDLR電卓について
前回、VM魂にパネラーと参加させていただいたことを記載しました。その時にお見せしたDLR電卓がアットマーク・アイティさんで記事になっています。本音を言うと、DLRに感動してもらってホッとしています。記事では、コードが読みにくいのですが、実際にお見せしたのは以下のようなコードです。
py> import calc as x # Pythonでモジュールの読み込み
js> c = new x.Calc(canvas) //JScriptでインスタンスの作成
js> x.enliven(c) //イベントハンドラ登録
これでPythonで書かれたモジュール(calc.py)を読み込んで、定義されているCalcクラスのインスタンスをJScriptで作成して、イベントハンドラの登録も行いました。後は、普通の電卓ですから、電卓として使うことができます。
記事には「でも、オブジェクトのマッピングは自明じゃないから、そうそううまく何でも共有できると思えませんね」という説明があるのですが、それはその通りだと私も思います。色々な言語は、その使われ方を想定したチューニングを施しています。このチューニングは、専門化されればされるほど効果を発揮します。でも異なる使い方をすると、思いのほか効果が見えないからです。
色々な言語が世の中に存在することを思い出してください。何故、色々な言語があるのでしょうか？やはり用途に合わないからだと私は思います。自分が達成したいことに適した言語を使えるのに越したことはありません。でも...全てのケースでうまくいくのでしょうか？中々うまくいかないジレンマに陥ることは、ないのでしょうか。そう言った場合に、別の言語にするとうまく行くケースもあります。別の言語を使うことを許して貰えないので、ライブラリを自作したという話もあります。こうした場合に、既に存在するライブラリなどの資産を共有化できそうなDLRという技術に私は、魅力を感じます。つまりトレードオフの関係があって、自分の問題解決の手段を選択するときに何を優先するのかということです。このような事を書いている私でさえ、ケースに拠ればコンパイラ言語でカリカリにチューニングしたりもします。目的としていることを達成するためです。
もっとも可能な限り楽をしたいという考えを私は持っていますから、DLRで目的を達成できるのなら迷わずDLRの上で動く既存のライブラリを使うでしょう。目的に合わないケースは、あっさりと使わないという選択もしますけど... 目標は目的を達成することなので、手段を問わないのが私の考えです。無節操すぎるでしょうか?
PS.実はこのDLR電卓は、TechEd Yokohama向けに作成したものです。なのでTechEdに参加される方がLL魂にいらっしゃったとしたら、少し早めに見たと思ってくださいませ。
