Haskellでイベントモデルとスレッドモデルを融合した 新しい並列実行モデルを実装したという話。 Linux上のI/OベンチマークでNTPLよりも高速だったそうだ。 ふむ。
まだ論文は読んでない。
「Rubyな生き方について」。 4/16から公開されていたが紹介するのを忘れていた。
改めて読み返してみると、私は変なキャリアを生きてるよなあ。 ただ、「自分の環境をデザインする」という考え方は 誰にも応用できる発想だと思う。
Erlangの紹介。
＠ITみたいなメジャーなサイトでErlangが紹介される日が来るとは。 しかも、私のエントリもリンクされてるし。
Erlangのやり方に時代がやっと追いついてきた、ということだと思う。 もっとも純粋に言語としてみた時のErlangは少々とっつきにくい。 記法にPrologの影響が強すぎるのかもしれない。 あと、エラーメッセージがぜんぜん直感的でない。
もっとも、最大のとっつきにくさは私の関数型言語への苦手意識という 非常に個人的なものなのかもしれない。
達人プログラマーDave Thomasによる最初のErlangプログラム。 これくらいなら別に難しくもなんともないんだけどねえ。
４月のブログコンテストのエントリを勝手に批評するシリーズ(その6)。 最後はJRubyのCharles Nutterのもの。
実際にRuby処理系を実装しているだけあって具体的。
Threading
Thread#kill, Thread#raise, Thread#criticalをなくしたい。
Thread#criticalをなくすのは規定路線。前二者はJavaのスレッドでは 提供されていない機能だからCharlesがなくしたいというのはもっともである。 これらはいずれもより抽象度が高い機能(timeoutとか)を実装するための道具 なので、それらが別の形で提供されるなら(段階的に)取り除いてもかまわない
ObjectSpace
なくしたい(特にeach_objectとか_id2refとかだと思う)。
_id2refについてはThread同様、上位機能(weakrefとか)が実装できれば 問題なし。そのために「_」で始まる名前にしてるんだし。
残りはメソッドのうち、garbage_collectはGCをスタートするだけだから問題ないはず。 each_objectは悩ましいところだが、デバッグ用のオプションを必要として普段は動かないとかは 許容されるかもしれない。こういうのが必要なのはどうせハックだし。 後はfinalizer関係だが、これらはなくすわけにはいかないと思う。
$SAFE and tainting
Charlesの意見は「これらはいらない」というもののようだ。 それなりに便利なのに。
が、$SAFE=4のSandboxは_whyのSandboxのようなもので 実現すべきであるという意見はもっともだと思う。 $SAFE=1だけ残すというのが良いのかもしれない(2.0以降)。
「Javaのsecurity modelにマップすべきだ」という主張は 私自身の知識が足りなくてイメージできなかった。 個人的にはJavaのsecurity modelには「繁雑」という印象しかないんだけど。
Direction
非技術的なのであえて具体的にはコメントしない。 もっともなことだとは思う。