Matzにっき

_ LL Ring

朝から新木場へ移動。

ちょっと迷ったが、新木場1st Ringへ。 それらしい場所で、「日本Rubyの会会長」が矢印を持って立っていた。

他数名と「1.8.5リリースお疲れさま」とかいうような話をしてから、 控え室へ。

会場を覗いてみると、すげえ、ほんとうにリングだよ。

Language Updateは会場に陣取って、 いろいろ聞いていた。 言語ごとにいろいろ「熱さ」が違っているのが面白い。 毎年参加してる言語とか、あんまり「Update」ないんだよね。

印象に残ったのは

• 「馬」。いや、ホントはラクダなんだって。OCamlだから。 でも、O'ReillyのOCaml本の表紙は馬だったような...。
• 「ハワイから生中継」。かっこいい。 私もこれやろうかな。そしたら、大変な思いをして海外へ移動しなくてすむかも。 だんだん括弧が薄くなるウィットは尊敬しちゃう
• 「パイプ椅子」。乱入かと思った。しかし、あいかわらずSqueakはデモが素晴らしい。 Rubyも爪の垢を煎じないとな。
• 「Matz引退？(1.8系から)」。昨日の今日だからな。 スライドを書いてた時点では90%以上本気。 今でも割とその気だったりする。

一方、会場でボーッと聞いてたら呼び出しをくらってしまったので、 私の発表の直前のPythonなどは聞けなかった。残念。 Pythonってのは毎年初心に返って「言語紹介」をしてる気がする。 真面目というか、継続こそ力なりというか。

ちゅーか、そろそろLanguage Updateは止めたほうがよいのではないか。 あるいは1年交代とか。

発表が終わって昼食食べて。関数型言語のパネルを聞こうと思ってたのだが、 うちに電話したら家人が具合が悪いのがいるということで、早めに帰ることにした。

その後のプログラム、あれやこれや見たかったんだけどな。 まあ、ホントに知らないこと、調べられないことは少ないんだけど、 face to faceで生まれることってのあるしな。

_ [Ruby] Are Ruby's Open Classes a Poor Fit for Large Projects?

「Rubyのオープンクラスってば大規模ソフトウェアに不向きじゃない？」という話。

誰も協調しない環境ではその通り。

でも、誰も協調しないで大規模ソフトウェアってのは難しいんじゃないかなあ。

で、おそらくプロジェクトメンバが問題を引き起こすことは(協調が起きるから)滅多になくて、 になるのは独立して開発されているライブラリ同士が それぞれ独立に既存のクラスにメソッドを追加して、 それらの名前が重なってしまったとかじゃないかなあ。

で、そういうこと(ライブラリ矛盾)が起きてしまうと、 可能な対策はかなり限られていて、現状では

• どちらかのライブラリ(または両方)をあきらめる
• どちらかのライブラリ(または両方)に手を入れる

くらいしかない。ほとんどのライブラリは自分の管理下にはないから、 手を入れる(結果的にフォークする)のは面倒だし、 ライブラリを使うことで達成できたはずの生産性をあきらめるのも悔しい。

当面は

• 一般に公開するライブラリはあまりオープンクラスを活用しない
• 活用する時には名前をできるだけ明確にし重複を避ける

ことを徹底するくらいしか対策がない。 とはいえ、全面禁止にしちゃうと 中にはActiveSupportのようにオープンクラスを活用して 違う言語みたいにしちゃう可能性を否定しちゃうことになるし。

将来的にはクラスボックス(のような機能)で、この辺を住み分けできる 名前空間管理を導入したい。けど、きっと導入されるのは(1.9ではなく)2.0になることだろう。