Matzにっき

_ [教会]断食安息日

今年最初の日曜日。新年の挨拶。

甥っ子が退院したので、姪を返す。

_ [生活]小豆雑煮

昨日、米子で食べ損ねた小豆雑煮を食べる。

ご存じない方のために:

小豆雑煮とは、潰した小豆を砂糖とともに煮たものに餅を入れたものである。 全国的には「ぜんざい」と呼ばれるものに似ているが、違いは

• 正月に食べる
• 餅は焼かない
• 名前が違う

鳥取県東部地方(鳥取市とか)では、さらに地位が上がるほど砂糖をてんこ盛りにするのだそうだ。 昔、砂糖が貴重だった頃の名残であろう。

_ [言語]Adding Optional Static Typing to Python

Python作者、Guido van Rossum自らPythonにオプショナルな静的型を導入することについて語る。 パート1。 パート2。

さすがはGuido、Python Type SIGでのさまざまな議論を反映しているとみえて、素晴らしいまとめである。 CLOS(とその派生系であるDylan)を別にするとまだ誰も成功していない 「動的言語における静的型」に必要な機能を不足なくカバーしているように見える。

• DuckTyping。提案ではデフォルトではsignature conformanceしか要求しないDuckTypingである。ただし明示的にクラス適合も指定できる。
• Generic Type。オブジェクト指向言語に静的型を導入するならば、かならず必要になる。型変数に型指定ができる(この型はある型のサブタイプである、とか)のが現代風。
• Overloading。型を指定するならば型の違う複数のメソッドを定義したい。
• Interface。「型」をまとめる単位としてのインタフェース。メソッドボディは提供できないが、アサーションは定義できるというのがちょっと珍しい。
• 型のUnion, Intersectionが指定できる

これだけあれば、静的型言語として足りないものはなさそうだ。 Generic Typeなどは多くの静的型言語(例: C++, Java)の設計者も当初は見落としていた(しかし後にその重要性に気付いた)ものなので、きちんと押さえていることはポイントが高い。

私が一昨年のRuby Conferenceのスライドで「Optional Static Typing」とさらっと書いたものに対して、 より深く、より完全な考察を行ったものだと考えてよいだろう。さすがだ。

しかし、このようにGuidoがまとめてくれたものを眺めて、改めて考えると、 やっぱ将来Rubyに静的型は導入するのやめようと思った。 たとえオプショナルでも。

理由は以下の通り。

• これだけ完備した型システムを用意しても、オプショナルでは効果は半減以下である。 しかし、RubyがRubyであり続けるためには必須にすることはできない。 完全な型指定を要求するのでは動的言語とは呼べないような気がする。 たとえ、ここで述べられている型システムが DuckTypingを採用した、いわば「動的言語フレンドリー」なものであるにもかかわらず。
• 「効果が半減」することが予想されるのにもかかわらず、 型の導入は言語を複雑化される。その複雑さは割りに合わないように思える。
• 効率の良い実装が思いつかない。私の知識や能力の限界かもしれない。

Guidoは

this is something that many people, especially folks writing frameworks or large applications, need

と書いているが、LispあるいはSmalltalkの実績は、必ずしも静的な型がなくても 大規模アプリケーションやフレームワークが構築できることを証明しているようにも思える。

というわけで、オプショナルな型システムは将来にわたってRubyに実装されることはないだろう。 もうちょっと簡易な(かつDuckTypingを意識した)型チェック機能の導入はありえるかもしれないが。

_ [OOP] Classbox

不親切だった年末のエントリの続き。

OOPSLAの論文(Java版)と2003年の論文(Smalltalk版)を読む。

Classboxは一種のパッケージ(ネームスペース)で、 importで取り込んだクラスに対して自分のパッケージ内だけで有効な修正(refine)を行うことを許す、 というものだ。一種のpartial class(複数のファイルに分散してクラスを定義する)とか open class(あるクラスに対して追加で定義を変更できる)に似ているが、 重要な違いはrefineによって加えた修正の有効範囲はそのClassboxにレキシカルに限定されるということ。

Rubyに関連して具体的な例を出すと、 たとえばjcode.rbのようStringクラスのメソッドを置き換えちゃうようなClassboxを作ったとすると、 そのメソッド置き換えはjcode.rbが提供するClassbox(と、それをimportしたClassbox)でだけ有効で その外には影響を与えないってこと。同じことはmathn.rbにも言える。

これらのライブラリは、グローバルにクラスの振る舞いを変えちゃうので嫌われているんだけど、 Classboxに限定した範囲内でだけ有効だったら、そんなに気にしないで既存のクラスをがんがん変更しても 悪影響は与えないってこと。

Rubyのopen classは非常に便利なんだけど、 グローバルな影響が大きいというデメリットもあった。

Classboxのようなやり方であれば、影響範囲を制御できる。 できることならば、このような機能を将来のRubyに取り込みたい。 何回考えても挙動が理解できなかったselector namespaceと違って、 Classboxは即座にピンと来た。これこそが進む道だと思う。

ただ、Classbox(Smalltalk版)やClassbox/J(Java版)の仕様をそのまま Rubyに持ってこれるかっていうとなかなか難しい。 Javaと違ってRubyのクラスはオブジェクトだし、 インナークラスも外からまる見えだし。

APIも実装も事前に十分に検討する必要があるだろう。

....、論文ネタになるかな。無理かな。

_ [OOP] Classboxの実装

Smalltalk版はインタプリタそのものをいじって、メソッド呼び出しのコストが1.2倍程度らしい。 Java版はプリプロセッサを使っているのだが(だから仕様としては結局はC#のpartial classと同じ)、 ナイーブな実装のためかメソッド呼び出しが25倍遅いらしい。これは痛い。

Rubyの場合、インタプリタを直接いじれば、(今の実装ならば)グローバルメソッドキャッシュが効いて それほど遅くならずにすむのではないだろうか。ただ、クラスの参照がインダイレクトになるのが どの程度影響するのかはやってみないと事前に見積もるのは難しいだろうなあ。

_ [Ruby] Headius: New JRuby Compiler: Progress Updates

ホリデーシーズンにJRubyはちゃくちゃくと進化中、という話。

実際にServer VMを使った場合には、 場合によってはC Rubyに比肩しうる性能が出る(こともある)ということだ。

今までは「Bignum計算なら速い」とか、JRuby自身の性能によるものではない 点でしか性能勝負はできてなかったんだけど、 今回はわりとアグレッシブな最適化(再定義されてない整数メソッドの直接呼び出しとか)を 行ったようだ。

JRubyってのは非常に面白いポジションにいると思うんで、 かれらの頑張りには今後も期待したい。

_ [Ruby] ユメのチカラ: マルチプロセッサ向けソフトウェアパラダイムとは？

この間のメニーコアのエントリを連想させる内容。さらに吉岡さんのはてな日記の方では

Rubyあたりでマルチコアに対応した実装をハックしちゃうというのも面白いかなあなどと妄想しているがあくまで妄想である。そこの人、本気にしないように。

とある。いやあ、私もそういうの欲しいなあ。 私自身は並列は得意じゃないので、できそうにないけど。

そういえばささだくんの専門はそっちだったっけか。

_ [Ruby] Class Variables

「落とし穴」のエントリ以来、 ずっと考えていたのだが、ようやっと結論が出たような気がする。

今までクラス変数は、登場した場所を囲むもっとも内側のクラス(ただし、特異クラス定義は除く)に所属する、というのがルールであった。 変数がどのクラスに所属するかは静的に決定した方が分かりやすいだろう という判断からである。

しかし、「落とし穴」と呼ばれるからには、この判断は間違っていて ユーザの暗黙の期待を裏切っている(悪い驚き)である可能性は否定できない。

新しいルールはこういう風にしようと思う。

1. メソッド内部のクラス変数はそのメソッドを定義するクラスに所属する。 特異メソッドの場合には特異クラスに(1.8とは非互換)。
2. クラス定義内部のクラス変数は定義中のクラスに所属する
3. クラス変数の参照(とdefined?チェック)において、 そのクラスに当該の名前のクラス変数が定義されていなければ、 a) そのクラスがクラスの特異クラス(メタクラス)ならば、 そのクラスとさらにそのスーパークラスを検索する。 b) そうでなければ最初のクラスのスーパークラスを検索する(現状の1.9ではエラー)。
4. 代入では、スーパークラスにさかのぼらない。 スーパークラスで同名のクラス変数が定義されていても自クラスに代入する。 サブクラスからはクラス変数は更新されない

こうやって文章にすると結構複雑なのだが、どうやらこれが多くの人が暗黙に期待するルールに一番近いようだ。

_ The Mythical 5%

以前、RubyをDISってくれた*1、 Bruce Eckelのエントリ。

IT技術者ではトップ5%は残りの人たちの20倍の生産性を持つという。 これが本当のことであるとしたら、その科学的な根拠はなにか、という話。

80%の技術者は、本を読まない、イベントに参加しない、勉強しない。 それでどうして、それらを継続的に行う開発者と同等の生産性をあげることができるのか。 それらを行う20%のうち、さらに80%は、(まだ)うまく成果をあげられていない。 すると、それらを継続的に行い、さらにうまくいっている人はおおよそ5%になる。

「トップ5%」というと、なにか持って生まれた才能の違い、というようなものを 感じさせるが、実際には「(効果的なことを)やっているかどうか」、 「それを成功するまで継続しているか」という実にシンプルなことによって 実現されている。

この講演はその他にも面白い内容を含んでいるので、 英語が苦手でない方はいちど読んでみるとよい。