日々の破片

_ 鳥頭

どういうものだか、よくわかってなかったのだが、もしかしてヒヨコの時のすりこみで親だと思って付いていく行動のことを指すのかな？ 途中で変えるってことができないのかも。

と、mixiのCのコミュニティを眺めていて思った。

#たぶん、モズのはやにえみたいな、やった先から忘れてく状態を指すことだと思うが、上のようなことを思ったということ。

_ お、新しい感覚を発見

じじいの繰言のたぐいで、「……ってなんだそれ？ それ10年前にやったよ」ってのがあるけど、ついに、おれもそれを感じたぜ。

RubyとJavaScriptとVBというか実装系でruby-mswin32、JScript、VBScriptの相互呼び出しだったら、8年前にASRで既にやっているが何か？ ……そうか、C#とPythonが無いか（HaskelScrptのCOM呼び出しがいまいちわからなくて放置したが、あの時、ちゃんとやってたら、「でもHaskelも呼んでるぜ」と言えたのだが）。

#そうか、これは技術的な差異とかが見えてないから言うんじゃなくて、ユースケース抜きじゃ意味無いだろ、というあり様についての苦言（じゃないな。なんだろう？ 多分、半分はおもしろそうだけど（おー、やってるやってるという感じ半分、くそーおもしろそうなおもちゃだなぁという感じ半分）、それだけじゃつまらんよ、もっと上（ユースケース）からの別の切り口が欲しいね、という感じみたいだ）なんだろうな。

_ SilverlightのイベントモデルとRuby

def initialize
    button.click do |s, e|
        output.Text = 'Hello World !'
    end
end

clickイベントで実行するコードの登録にクロージャを利用する。（さて、ここで気になるのは、変数のスコープルールなわけだけど、sやeは（ここでは利用してないけど）どうなるのか。と気になったけどここでは外に影響しないから良いのか。

というか、eはEventArgsっぽいけど、sってなんだろう（sourceか）。

_ reqruire

requilre 'Sliverlight.Samples.Controls.Version=0.0.0.0'

ネームスペースのサポートに'.'を導入したのか。というか、アセンブリを指定するように拡張している。

というか、rqeuireはロードしたオブジェクト(暗黙のModuleのインスタンスということか、それともネームスペースのエイリアス)を返す拡張をしている。

JS = require '3DText.js'

今は、trueとかfalseが返るわけだし。

というよりも、requireがネイティブな関数になっているらしい。

VB = require 'technorati.vbx'

（VBのスクリプトをロードして、そこに定義された関数をVB.foo()で呼べるようになる）

_ Caveat

Rubyはケースセンシティブな言語で、JavaScriptも同じだ。でもVBは異なる。

コード片を見ている限り、たとえば

Document = System.Windows.Browser.HtmlPage.Document

のように（CLRのサブセットなんだから当然だろうけど）、ケースセンシティブなネームスペース付きの名前が使われまくる。

現実問題として、このてのクラス名をすべて覚えることは不可能だ。

したがって、コード補完機能をもつエディターの利用が必須になるんじゃないかな（あまり嬉しいことではない）。

_ Silverlight

結局は、このプラットフォーム（でいいのかなぁ？ Flashはプラットフォームとして利用できるんだから良いのかも）自体にどれだけ魅力があるか、がキモなわけだろう。

ActionScriptを覚える（どってこたないことだが、「業務」となると「では無理です」となるところはありそうだ）必要があるFlashと違って、VBでできるならOK（これはASPが使われた理由）という点だ。

でも、VBでできるよ、じゃ全然おもしろくないので（というか、「業務」でSilverlightをどうしたという話の人はDEVセッションには関係ない）こういうプレゼンになったんだろうな。

#で、rubyが使われるんだろうか？ というのは興味深いわけだが。

_ それkmem

ダイナミックランゲージの良い点は、という話だと思うんだが、スクリプトをちょっといじってそれが反映するとこデモしてたが、それメモリーいじれば機械語でもできるよね（と、何が良いのかアスペクトを変えるとわからなくなる例）。

というか、Silverlight DLR Console（Safariがホストしてる）が良い感じだ。FireBugが画面を縦分割でやれれば（デュアルモニタの人、多そうだから悪い選択ではないはずだ）、こんな感じかな）

_ ちょっと考えてみた

MSプラットフォームかどうかはともかく、勤勉な世界と軽量な世界の2つを共にターゲットにしていると想定してみる（というか、当然、そうだろう）。

軽量な世界についてはまったく問題ない（Freeな世界はまた別として）。ある意味、当然のことばかりで、おお、新しいいかしたおもちゃですな、という感じだ。

もちろん、問題は繊細な世界でSilverlightはどう受け入れられるか、だろう。

たとえば、逆説的にCurlは繊細な世界で生きてる（ようだ）。同じように、繊細な世界に需要があるのはわかっている。

繊細な世界を4象限で考える。

金使える｜使えない

技術指向｜人力指向

Curlを採用しているところは、金使える（Curl自体に金を使うという意味ではない。クライアントマシン環境構築、開発者の教育、その他、もろもろが必要だ）かつ技術指向（Curlという技術を採用して問題領域を解決しようとしていることで、かつCurlそのものの普及度を考えれば、これが技術指向の解決方法だということは明らか）だ。

Silverlightはどこへ位置するか？

もちろん、金使える（デモで利用しているOS Xはともかくとして、現実問題としてVista以降のOSとそれを動かすPCの全社あるいは関連部門導入が前提となるだろう）は間違いない。かつ人力指向という方向じゃなかろうか。

というのは、金使える＋技術指向であれば、すでにFlash、Curl、JWS、.NET SmartClientという有力な選択肢があるからだ。これから、な選択としてはわかるが、今更な気もする（UIの概念をひっくり返すようなすごいものがアーキテクチャになっていればもちろん別）。

ということは、人力指向な場所で、ruby、python、JavaScriptが出てくることは現状では考えにくい。するとVBということになる。VBはケースセンシティブでは無いという長所もある。

この場合、.NET SmartClientとは競合しないと考えられる（上ではああ書いたけど、.NET Fxのインストールは勘弁なXPマシンはターゲットとなり得るわけだし）。

と、2001年には、.NETならC#一押し、であったが、「業務」切り口だと、VB安泰というか、VBの継続、が良い選択ということが現時点での結論。

#レガシーは消えぬ。なんどでもよみがえるさまんさふぉっくす。でもDBからFoxは消えたみたいだけど。

#おれは、↑みたいなのは「地口」と呼ぶわけだが、そういう概念を知らない／そもそも言葉を知らない無知な人には（昨日のスラドの「無償」釣堀を想起しているわけだが）、別のものに見えるんだろうな。でも、江戸時代から東京に住んでいる人間（とその子孫）には、地口は普通の文化なわけだからしょうがない。