«前の日(11-21) 最新 次の日(11-23)» 追記

Matzにっき


2003年11月22日

_ [家族]校内音楽会

急に寒くなる。と思ったらどうやら具合が悪くなってるらしく、 悪寒がしているらしい。

午後からは娘たちの校内音楽会。前述の通り、具合が悪いので私は前半はパス。 娘の登場する後半だけ聞きに行く。まあ、けっこう頑張っているのではないだろうか。 私は子供時代、音楽(特に楽器演奏)が得意ではなかったので、よけい評価が甘くなりがちだ。

_ [家族]ペット

なかなか引っ越しについて話も進まないし、 これではいつになったら犬が飼えるかわからないぞ、 ということで、 当面引っ越しせずにハムスターを飼おう、と決める。

子供たちが気に入ったのはロボロフスキーという種類のハムスターなのだが、 あまりに素早いので気軽にかわいがれないだろう、ということで、 パールホワイト種のものを購入。

名前はパールホワイトだから「パール」だそうだ。Rubyじゃないのね。

_ [Ruby]インスタンス変数

昨日のローカル変数に続いてインスタンス変数について。

Rebecca Wirfs-Brook女史*1によると、 クラスのユーザには三種類あるそうだ。

  • 自分自身
  • サブクラス
  • 他人

これはC++のprivate/protected/publicに相当する。私がC++のデザインでもっとも優れていると思う点だ。

ところがRubyのインスタンス変数は、

  • どのクラスのメソッドからも同じスコープで見える
  • 外からは参照できない

ため、 アクセスに「自分自身かサブクラス」と「他人」の二種類のレベルしかない。 当初目指していた「単純さ」という点からはこの素直なデザインは良い面も多いが、 問題もある。

サブクラスからすべてのインスタンス変数が見えるということは、 継承関係があるものからは実装を隠蔽することができないということだ。

このことはまだいい。サブクラスから状態を操作するためのprivateメソッドを用意することで対応できるから。 しかし、インスタンス変数名がうっかり衝突した場合は対応不能だ。悲劇としかいいようがない。 特にモジュールはどのようなクラスにMix-inされるかわからないので、 うかつな名前のインスタンス変数は使えない。

それもこれもインスタンス変数にprotected相当しかないことが問題だ。 privateなインスタンス変数があれば問題は解決するのだ。

ということで、Ruby2ではprivateなインスタンス変数を導入しようと思う。 これから考えなければならないのは、文法をどうするか。

現在との互換性を重視するならば、

  • @fooで普通の(protectedな)インスタンス変数
  • @_fooでprivateなインスタンス変数

というのが考えられるだろう。しかし、インスタンス変数は原則privateであった方が問題が少ない、 という観点からは、その逆、つまり

  • @_fooで従来の(protectedな)インスタンス変数
  • @fooでprivateなインスタンス変数

の方が良いのかもしれない。もうちょっと考える余地がある。

*1  私、個人的にWirfs-Brook女史のファンで、昨年のOOPSLAで出会った時にはサインもらっちゃいました


2004年11月22日

_ [家族]休日

子供たちが土曜日の代休で休みなので、 私も休みを取る。Linux Magazineの初校を取りにオフィスに寄ると、 同様に休みのはずのかずひこくんがいる。「私、休んでますよ」だそうだ。

そのまま高速を使い米子へ。「社会実験」とやらで普段の70%オフ。 普段の普通車650円だと利用する気にならないが、200円なら活用する気になる。

昼食後、何件か買い物に。

_ 削らないで虫歯を治療

うむ、近所でやってくれる歯科医院はないものか。3Mix-MP法のホームページを見ても、医院のリストはないようだ。差別化になると思うんだけどなあ。

_ 査読

ACM SIGPLAN TOPLASから査読を依頼された。 名誉なことだと感じたので引き受けることにしたが、 英語の論文を一生懸命読まなくてはいなんなあ。

_ ASS KICKIN' HONEY ROASTED PEANUTS

米子のスーパー(PLANT-5)で買ったピーナッツ。 よくあるハニーローストのピーナッツなのだが、 なぜかハバネロ入り。からい。とてもからい。

からいおやつがなにがいいかというと、子供に横取りされないことだな。

しかし、この商品名は何とかならないものか。


2005年11月22日

_ 取材

いつも通り、午前中ふにふにとしていると会社から電話。

珍しいなと思ったら、そういえば今日は取材を受けるって約束してたんだった。 うっかりしてた。子供の笑顔見てなごんでる場合じゃない。慌ててオフィスまで移動。

「日経バイト」の取材。 最終号に過去記事の検証としてさまざまな分野の人に話を聞くという特集なのだそうだ。 で、「プログラミング言語」の担当が私。わざわざ松江まで来るという時点でかなり豪気な企画だ。

そもそも「プログラミング言語」の一人者が私で良いのかって疑問があるのだが、 その辺を聞いたところ、実装技術の偉い人はたくさんいるけど、 言語そのものについて扱っていて、日経バイトの読者に名前がピンと来る人ってのが なかなかいないそうだ。まあ、確かにこのネタだと中田先生とかに話を聞くわけにもいかないか。 苦肉の策といったところか。

まあ、いろいろしゃべったが、役に立てたんだろうか。

しゃべった内容は(記事の邪魔になるといけないので)ここでは書かないことにする。

_ [言語] Secrets of Successful Programming Language Business

注目の編集者、森田さんがFranz Inc.のCEO、Fritz Kunzeに「言語ビジネスで成功する秘訣」を尋ねた答え。さすがに成功した人は違うな。おっしゃる通り。

詳細はリンク先を自分で読んでほしい(なぜか英文)。

ただねえ、成功するにはそれでいいだろうけど、 そういう言語って技術者とか言語設計者にとっては面白くないんだよねえ。

で、面白い言語でビジネスしようとすると...やっぱり死屍累累になるんだな。 面白くないとモチベーションが維持できないし。

難しいものだ。

_ [Ruby] Ruby the Rival

Bruce Tate, James Duncan Davidson, Robert Cooper, Bill Vennersの各人に対する 「JavaのライバルとしてのRubyについてどう思うか」という感じのテーマでのインタビュー集。

さすがに彼らは冷静でRubyを一方的に褒めたりしないわけだが、 それにしたってこれらの面子がRubyに対してポジティブな感想を述べてくれるというだけで それはそれですごいことではないかと思う。


2006年11月22日

_ [OSS] GPLv3カンファレンス

妻に送ってもらって出雲空港へ。

移動中に、先日のクラスローカルインスタンス変数に手を入れる。 前の実装ではシンボル名とクラスアドレスをpackしたシンボルを 作るという無理矢理な方法であったが、 シンボルテーブルを増やすことで対応した。

ついでにSymbolをもう一度immediateに戻す。 YARV方面で遅くなったという話を聞いたから。 これでもうちょっとマシになるといいんだけど。

GPLv3カンファレンス・パネル。

自作ライセンスを作ったのは出来心だった。 むしゃくしゃしてやった。フリーソフトであれば何でもよかった。 今は後悔している。

GPLv3についてはあまり語ることはなし。 ドラフト1はあまりに冒険的で不安になったけど、 現在のドラフト2は(ひと目で見るかぎりは)もっとずっとおとなしいし、 しかも、表現が難しくて正確なところは素人にはよくわからないし。

もうすぐドラフト3が出るということだし、 もうちょっと様子を見るしかないと思っている。

_ 書類不備

明日は妻と待ち合わせていたのだが、 夕食時に電話で連絡したら明日必要な大事な書類が期限切れだった、とのこと。

正直、内心「これは絶対ムリだな。予定変更か」と思ったのだが、 彼女の努力と、まわりの人の協力があって、驚くべきペースで、 手続きが進み、なんと書類更新が完了してしまった。

熱意か、信仰か。

感心した。感動したといってもいい。


2007年11月22日

_ [Think IT] 第3回:オブジェクト指向と関数型を兼ね備えた「Scala」 (1/3)

最近Think ITがプログラミング言語の特集をやっている。 すばらしいことだと思う。

実は最初私に話が来たのだけど、 とても書けそうになかったので、ご遠慮したのだが、 ちゃんとライターを見つけてくるところがますますすばらしい。

で、今回はScalaなのだが、最後のここがちょっと不満。 いや、解説ではなくて言語に。

これらを踏まえてScalaが依然として静的型付け言語であるということを思い出してほしい。「動的言語の特徴のように見える物」が、実はそうでもないことがみえてくるのではないだろうか。実際Scalaを学んでいくと「型安全性と実行効率を引き換えに記述性と柔軟性を手に入れる」という「動的言語の常識」が覆されていくような感覚すら覚えるほどだ。

ここではDuckTyping(もどき)がScaleのstructural conformanceで 実現されているところをもって、上のように説明しているのだが、 実際にはRubyのプログラムとScalaのプログラムはこのようになっている。

Ruby版

def safe_close(x) x.close unless x.closed? end

Scala版

def safeClose(x)[T] (x: T {def isClosed: boolean; def close}) = 
  if (!x.isClosed) x.close;

うむ、確かにScala版でも、ある特定の型(IOとか)を指定しておらず、 isClosedとcloseがある任意のオブジェクトに対して呼び出せるので これはDuckTypingの「匂い」がする。

しかし、考えてみてほしい。この二つのプログラムには重大な違いがある。 それはScala版が簡潔ではないことだ。特にxの型指定の部分が。 safeCloseの例は簡単だが、 もっと複雑な関数なら引数それぞれがネストして structural conformanceな型を持つ可能性だってあるわけだし。 明示的な指定では、複雑になれば発狂しそうになるだろう。

この明示性はDuckTypingの思想とは対立する。

せっかく型推論があるのだから、指定などさせず、 「xに対してisClosedとcloseが呼ばれているから、xの型は〜」と きちんと推論してほしいものだ。実際にOCamlなどでは可能なのだから。

どこまで複雑なものまで可能かは知らないけど。

_ NHK取材

1.9のリリースに関連して、もう一度松江局でとりあげたいとのお話。

だが、それでなくてもこれから年内は予定がびっしり 詰まっているので、「年明けてからにしてください」とお願いした。

リリース前に取材したかったみたいで、 少々不満そうな気配も感じられたが、 勘弁してもらった。そろそろ限界が近い。


«前の日(11-21) 最新 次の日(11-23)» 追記