最新 追記

Matzにっき


2003年08月01日 [長年日記]

_ [Ruby]1.8.0 preview7

なんとpreview7まで出てしまった。

  • IA64でちゃんと動くようになった気がする
  • いっぱいバグを直した
  • 1.8.0最終版のためのドキュメント書き
  • うちの会社の帯域を使い切らないためのミラーの準備

などなどが忙しく、日記を書いてる暇がありません。

オブジェクト指向の件の続きとか、VAIO U101の話とか、書きたい話はたくさんあるのですが。 一段落して、気持ちに余裕ができたら、ね。


2003年08月02日 [長年日記]

_ [Ruby]Ruby 1.8.0

月曜日リリースの約束を守ろうと思っているのだが、今になってもバグレポートが来る。

もちろんリリース前にバグが減るのはありがたいのだが、これがリリース後にもどんどん見つかる 予兆ではないかと思えてしかたがない。だいたいリリースにはイヤな思い出がたくさんあるし。

不安だ。

なんとなく北斗七星の隣に小さく輝く星を見たような気がする。

_ [生活]花火

今日は松江水郷蔡ということで、ベストポジションの社長の家にお邪魔して花火見物。 前田(修吾)くん家族も一緒。

リリース作業でたまったストレスを晴らす....ことができたのかな。

_ [OOP]オブジェクト指向が難しいのか(予告)

いや、それは違う、という話はまた今度。


2003年08月03日 [長年日記]

_ [教会]松江

3週続きで松江に出れるというのは珍しい。

幼児の命名の儀式があった。不安定な抱き方だったのか祝福の間中ずっと泣きどおしだった。 機嫌が悪かったのね。

_ [家族]米子

米子の実家で花火を見た。妹夫婦、弟夫婦も来ていたのだが、妹のダンナは具合が悪くなってしまったので (働き過ぎか)、途中で帰ることに。

子供たちはしっかり遊んですっかりくたびれて帰った。楽しんだようだ。

_ [名前]ひらがなのなまえ

えー、 オープンソース関係者はひらがなの名前が多いという指摘ですが、実際のところどうなんでしょう。Rubyコミュニティでは明らかに目立ちますが。 私とか「わたなべひろふみ」さんとか「やまだあきら」さんとか。

私の場合は単純な理由で、「松本」なんてありふれた名前を差別化したいというものです。 それとひらがな表記が気に入っているというのもあります。

最初のきっかけは小学生のときです。授業に使う算盤を注文することになって、 裏に名前を入れてもらうので注文書に名前を書くことになっていました。 当時から少々ひねくれていた私は、

  • フリガナの欄に漢字の名前を
  • 名前の欄にひらがなの名前を

書いたのです(バカ)。

数週間後、届けられた算盤にはひらがなの名前が刻まれていました。

たぶん、小学校3年か4年ころのことだと思うのですが、その時改めてひらがなの自分の名前を見た私は、 「この文字は丸みを帯びて美しい」と感じました。私の名前の漢字は直線ばかりですが、 ひらがなのほうはどれをとっても丸いものばかりです。

それ以降、私はひらがなの名前を多用するようになりました。

というわけで、 私がひらがなの名前を使うのは、冗談ではなく小学生のころからだというお話でした。


2003年08月04日 [長年日記]

_ 来訪者

首藤さんの日記にもあるように、 松江で開かれているSWoPPに参加中の「Ruby世代別GC」の木山くんと、首藤さんが訪問してくださる。

木山くんからは製本した博士論文をいただいた。 現時点では、彼はRubyをテーマにD論を書いた唯一の人物だろうなあ。 続く強者(つわもの)が出るか、否か。

ところで、昼食はご一緒しなかったんですが、やっぱりラーメンだったのね。

_ [Ruby]Ruby 1.8.0

やっと出ました

関係者の皆さんお疲れさまでした。直前のミスで古いChangeLogがパッケージに含まれていないのですが、 ここに置いておきます。

既に分かっている問題

  • 上記のChangeLog
  • doc/NEWSにいくつかのスペルミス(CVS→CSVとか)
  • OSF/1でmake testに失敗する。-lrubyで古いlibruby.soをリンクしてしまう。 とりあえず、2度インストールすることで解決。

しばらく休憩してから、ruby_1_8ブランチを作って、開発版1.9に集中しよう。 Riteはそれから。気の長い話だ。


2003年08月05日 [長年日記]

_ [車]見積もり

先日ぶつけた車の修理の見積もりを取る。

え、ろくまんごせんえんですか。そうですか。がっくし。

_ [Ruby]記者の眼

日経ITProの記者の眼でRubyが扱われていた

結構、好意的に扱ってあるではないか。これを書いた矢崎さんは今月の日経ソフトウェア9月号の特集で、PerlとRubyを扱ってくださった方だ。

最初は私に原稿の依頼があったのだが、ちょっと手に余ったのでお断りして、 代わりに、吉田さん(moriqさん)にお願いした。 『PerlユーザのためのRuby入門』の著者のmoriqさんなら適任だし、 任せても安心だと思ったからだ。 さいわい、快く引き受けてくださった。

矢崎記者がRubyに対して好意を持ってくださったのはmoriqさんのおかげが大きいと思う。

いや、Rubyが優れているのもあるんだけどね(不遜)。

_ [Ruby]1.8.0のバグ

満を持してリリースしたはずの1.8.0にすでにバグがいくつも見つかっている。 リリースエンジニアリングって難しい。

  • 空文字列のGCでSEGVすることあり
  • shell.rbのrmdirが動かない
  • Array#fillがブロックを取った時の挙動がおかしい

また、次の点も指摘されている(重要ではないが)。

  • Marsha.dumpがspecial constのインスタンス変数をダンプしない
  • Module#cloneがinitialize_copyを呼ばない

これをどうしたものか、1.8.1を出すのは早すぎると思うし、 1.8.0メンテナンスリリースとか用意しようかなあ。


2003年08月06日 [長年日記]

_ [OOP]継承は悪か

Linuxビボ〜ろくより。

greenteaさんが 「GUIでは継承を使わない」って書いたことが発端です。

で、その中でgreenteaさんは

継承を多用することについての戒めとしては「オブジェクト指向スクリプト言 語 Ruby」でも「継承は最後の武器だ」と述べられています。

と述べておられます。

確かに私は『オブジェクト指向スクリプト言語Ruby』の中で、 「継承は最後の武器だ」と書きましたが(p.219, p.562)、別に継承を避けろというつもりはないのです。

例によって私の表現が安易だったのですが、この機会に補足説明させてください。

まず、元ネタから説明しましょう。この言葉の元となった「拳銃は最後の武器だ」というセリフは、 『忍者部隊月光』の劇中で多用されるのですが、 実際には拳銃はばんばん使われてます。 ですから、意図としては「使うな」ではなく、「使う前に考えろ」です。

さて、技術的な点から考えると、greenteaさんも引用しているように 「継承はカプセル化の概念を破壊する」 あるいは「クラス継承よりもオブジェクトコンポジションを多用すること」 とはよく言われます。

しかし、私は同意しません。

(ちゃんと考えた後でも)継承を使いたくなるケースでは、 オブジェクトコンポジションの方が継承よりも優れていることはまれだからです。 むしろ、明示的な委譲の定義が繁雑で、「こんなこと自分でしなくちゃいけないのは変だ」と感じます。 そんなことを言語に押しつけて自動で片付けるための仕組みが、 オブジェクト指向言語の継承機能であったはずです。

「継承はカプセル化の概念を破壊する」件については、また別にもう少し考えなければなりません。 なぜ継承がカプセル化の概念を破壊するかといえば、 サブクラスはインスタンスの構造に直接触ることができるからです。

インスタンス変数を直接参照すれば、スーパークラスの実装に強く依存してしまいますし、 インスタンス変数を直接更新すれば、インスタンスの不整合な状態を作り出すことができます。 確かにこれはカプセル化の原則に対立します。

しかし、スーパークラスで定義されたインスタンス変数に直接触ることができることは、 オブジェクト指向言語にとって必須ではありません。たとえばC++はprivateなメンバには サブクラスからもアクセスすることができません。そしてさいわいなことにprivateがデフォルトです。 これが私の考えるC++の唯一優れた点なのですが。

Rebecca Wirfs-Brock女史は1988年のOOPSLAの論文でResponsibility Driven Designについて述べています。

その論文の中で、クラスの利用者は

  • 外部利用者(第三者)
  • 内部利用者(つまり自分自身)
  • 継承利用者(サブクラス)

の三種類があり、それぞれに見せるべき視点が異なると述べています。C++のpublic, private, protectedは まさにこの三種類に対応しているのです。余談ですが、去年のOOPSLAで会った時にWirfs-Brock女史のサインをもらってきました。彼女のファンなんです(ミーハー)。

結局問題なのはRubyのような言語がスーパークラスのインスタンス変数に簡単に触れてしまうという 「言語上の欠陥」なのであって継承そのものの問題ではないのですよね。 Rubyの次の世代の言語はぜひ「インスタンス変数はクラスローカル」が常識になってもらいたいものです。 事実、Perl6ではそうなるってDamian Conwayが言ってました。

というわけで、私の言葉を引いて継承を使わないほうがよいというのは、 私の本意とは違うんだ、ということです。

最後にどんな継承がまずいのか、あるいは不要なのか、について述べておきます。

私個人が継承を用いるかどうかについての唯一絶対のルールは「is-aの関係にあるか」です。 この関係が成立しない時に継承を使うのは純粋に間違いです。

では、この話の出発点に戻って「GUIに継承を用いるべきか」ですが、 ケースバイケースとしか言いようがありません。 ただ、

  • 今作ろうとしているエンティティが既存のクラスのis-aである
  • 継承を使った方が楽ができる

場合には遠慮無く使った方が良いと思うのです。ちゃんと考えた後でね。


2003年08月07日 [長年日記]

_ [仕事]出張

茨城県ひたちなか市へ出張。あまり出番なし。やっぱりおまけだったか。

夕食をごちそうになる。タイ料理。おいしかった。からかった。おなかいっぱい。 しあわせだけど、ちょっとくるしい。

_ [OOP]オブジェクト指向の神髄

なんか以前にもどこかで書いたような気がするけど、私がなんの修飾もなく 「オブジェクト指向」と表現する時には、ほとんど「オブジェクト指向という考え方」を意味するつもりでいる。

そして、その最低限の条件は「アイデンティティがある」ことである。 アイデンティティとはある「オブジェクト」と別の「オブジェクト」が、 同じかそうでないか判定できる、という意味だ。

たったそれだけのことならば別にオブジェクト指向言語を使う必要はない。 Cのstdioだって、UNIXのシステムコールだってオブジェクト指向だ。 どんな言語、どんな環境でプログラムするかではなく、 プログラムする対象をどう捉えるかという考え方が重要なのだ。

でも、これだけではあんまり嬉しくない。

そこで、あえてもう一つの条件を付け加えるなら、 「あるアイデンティティがある存在(=オブジェクト)は自分に対して適応可能な処理を知っている」こと、 つまり「動的結合」とか「ポリモルフィズム」と呼ばれる概念を挙げたい。

この二つがあれば「オブジェクト指向(という考え方)」は十分である。

よく、オブジェクト指向の三要素として

  • 動的結合
  • 継承
  • カプセル化

のみっつが挙げられるが、「継承」と「カプセル化」はあくまでも「あると便利なもの」であって、 必須ではない。そのことは

  • オブジェクトによるカプセル化がないCLOS
  • クラスがなく継承もないSelf

が十分オブジェクト指向言語であること、 つまりオブジェクト指向という考え方に従ったプログラミングを十分支援していることからも分かる。

でもって、そういう「ファンダメンタルなオブジェクト指向」に付け加えて、

  • クラスベースのオブジェクト指向とか
  • カプセル化重視のオブジェクト指向とか

いろいろなレベルがあって、人によってどのレベルで「オブジェクト指向」 という単語を使っているかが異なっているので、 過去長らく発生した不毛な論争の原因になっていたのだと思う。

それよりなにより、誰もが自分の使っているオブジェクト指向言語から学んだ「オブジェクト指向」に こだわりすぎていて、一般化・抽象化が行われなかったことが不幸だと思う。

いや、私もけっして人のことは言えないのだが、私自身は

  • 最初Smalltalkをかじり、
  • Eiffelで静的型と多重継承に目覚め、
  • CLOSをかじってオブジェクト単位のカプセル化のない世界を知り、
  • Selfをかじって継承のない世界を知り、
  • ふたたび動的型と単純継承(+Mix-in)のRubyの世界を構築した

という経緯があるので、比較的オブジェクト指向という考え方を一般化しやすい立場にあるのではないかと思う。


2003年08月08日 [長年日記]

_ [Ruby]まつもとゆきひろを囲む会

渋谷のアジアンキッチンで夜8時から開催されました。 約30人のRubyユーザに取り囲まれてぼこぼこにされました。えーん(嘘)。

いや、それはそれとして、 昨日の夕食はタイ料理、今日の昼食はカレー(ナン付き)、 夕食はアジアンキッチンとアジアンな食事になったものです。 「アジア人だからいいのだ」といったのは、なかださんだったっけ。

_ [OOP]アイデンティティ

手元の広辞苑によれば

アイデンティティ

人格における同一性。ある人の一貫性が成り立ち、 それが時間的・空間的に他者や共同体にも認められていること。 自己同一性。同一性。主体性。

なのだそうだ。たとえば、私の同姓同名の「まつもとゆきひろ」という人がいるとしても (本当にいる)、その人と私は違う人間であり、区別もできる。 これは人間にはアイデンティティがあるからだ。

では、アイデンティティがないとはどういうことか。 ある二つの「値」があって、それがまったく同一のものか、 それともたまたま値が共通なのか知る方法がない時、アイデンティティが存在しない。

たとえば、PerlやBASICの文字列にはアイデンティティがない。 文字列を変数に代入する時、内部的にコピーが起きるかもしれないし、 そうでないかもしれない。あるいは代入が発生した時点では(内部的には)同一でも、 後で知らないうちにコピーに変わってしまうかもしれない。

アイデンティティがないということは、 「値」つまり「状態」にしか興味がないということだ。状態は(通常は)オブジェクトではない。 オブジェクトに関心がないということは、それはすなわちオブジェクト指向ではない。 よって、オブジェクト指向の本質としてアイデンティティが必要である、ということになる。

上記の理屈はとりあえず置いておくとして、アイデンティティは本当に必要かという点について、考えてみよう。実は以前のPHPの話のとき、 harukiさんの「リファレンスが無くてもオブジェクト指向できるのでは?」というツッコミに対して書こうと思ってた内容だ。

私の理解が正しければ、harukiさんの論理は「PHP4では代入によってコピーが発生する」が、 PHPにはオブジェクト指向機能がある、よってアイデンティティがなくてもオブジェクト指向ができる、 というものだったと思う。

しかし、PHPのオブジェクト指向機能はリファレンスというアイデンティティを利用しているので、 この論理は成立しないと思う。もしPHPにリファレンスがなければ オブジェクト指向プログラミングは不可能だろう。

私のもっともよく知っているアイデンティティのない言語はPerl4である。 バージョン4より前のPerlの「値」にはアイデンティティがない。 スカラー(数と文字列)も配列もハッシュもその内容でしか判定することはできない。 この言語でオブジェクト指向を行うことはほぼ不可能だ。 唯一アイデンティティを要求しそうなファイルハンドルは「グロブ」という シンボルテーブルのエントリをアイデンティティとして導入しなければ実現できなかった。

もうひとつのアイデンティティのない言語の例としてはTclがある。Tclには文字列というデータ型しかなく、 この文字列にはアイデンティティはない。 しかし、「オブジェクトパス」(.frame.buttonのようなの)や、番号のようなID(まさにアイデンティティの略だ)を 導入してオブジェクトを表現している

やはり、オブジェクト指向プログラミングにはアイデンティティが必要であると考えられるのではないだろうか。

とはいえ、つらつらと考えるに、 リファレンスのまったくない言語でオブジェクト指向プログラミングができる可能性はゼロではないかもしれない。

というのは、オブジェクトを更新するような副作用がまったくなければ、 アイデンティティはさほど重要にならないからだ。 Rubyの実装においてFixnumは厳密にはオブジェクトではなく単なる「値」なのに、 オブジェクトとして振る舞うことができるのもその例だ。

しかし、副作用の全くないオブジェクト指向プログラミングというのは、 なかなか考えにくい。はたして実用的に可能なのだろうか。 もし可能なら関数型言語に完全に整合したオブジェクト指向機能が実現できそうだが。 O'Camlには副作用があるしなあ。

_ 番号

昨日泊まったホテルの部屋番号が256、今晩が320。

なんとなくキリがいい、と思うのは、やっぱり壊れてるかも。


2003年08月09日 [長年日記]

_ [Ruby]Lightweight Language Saturday

台風で天気が悪いが、150人以上の人が集まった。

プレゼンもなんとか完了。しかし、うちのマシン、最近プロジェクタに出力できなくなってるんですけど、 壊れつつあるんでしょうか。

私にとってはあんまり新しいネタはなかったんだけど(当たり前?)、 聴衆の皆さんにとってはどうだったんでしょう

_ また欠航

ということで、LL Saturdayが終了したらとるものもとりあえず、 空港に向かったのだが、飛行機の到着が遅れているとさんざん待たされる。 しかし、さんざん待たされた後に天候不良のため欠航だと。しょっく。

最終便なので、他に変える手段はなく、明日の飛行機はことごとく満席だし、 どうしたもんだが。

というわけで、また東京泊になってしまったのだった。 明日早朝から新幹線で松江に向かいます。疲れるんだよなあ。


2003年08月10日 [長年日記]

_ 帰宅

というわけで、ゆうべ泊まったホテルを5時半に出発して、新幹線と特急で松江に帰る。 ようやっと松江についたのは昼の1時であった。払い戻しがあったので(割引無しの時期だし)、 金銭的な損はないのだが、それにしても半日つぶれたのと、この疲れはどうしてくれる。 今日は岡山に行くはずだったのに。

ひどい目にあった。

夜、他の人の日記を呼んでいたら、mputさんが飛行機で帰ったとのこと。ううっ、飛行機で帰れたらもうちょっと楽だったのに。

結局、電車で寝て、うちに帰っても寝て、一日中寝てた。

で、夜になるとごそごそと活動を開始したりして、また昼夜逆転生活。


2003年08月11日 [長年日記]

_ [Ruby]バグ

結構バグが見つかっている。やっぱり1.8.1だろうか。まだ決めかねている。

  • bigdecimalがなんか手が入っているぞ
  • opensslも直している
  • IA64 thread対応(こんどはシグナルがおかしいらしい)
  • 8/3のrb_call_super()の修正は良くなかったらしい。気がつかなかった
  • marshal_dumpではインスタンス変数をダンプしない

_ [Ruby]LL Saturday感想

リンク集ができていた。 なかなかいろいろな感想があって楽しい。

やはり自分がどう見られているかには関心があるのだが、

うーん、やっぱ子供っぽいか。娘にも「大人げない」とか言われるものなあ。

私自身のLLの感想はと言うと、

  • P2は(予想通り)発散してしまった。もっとも発散しないパネルに参加したことないんだけど。
  • P3は

    • 画面のコードが見えない
    • プリントのコードと実際のコードが違う
    • しかも、バグってるし

    とちょっと辛かった。コードのプリントが全員の手元にあったら、すごい役に立った思うんだが。 まあ、そのうち資料公開されるだろう。

  • O'Reilly Author capをもらえたのが嬉しかった。やっぱ子供っぽいか。

2003年08月12日 [長年日記]

_ [家族]帰省

今日から休みをとって(というか、会社に行かない宣言をして)、 妻の実家である山口に移動。

私の実家も、今住んでるアパートも、妻の実家もみんな国道9号線から少し入ったところにある。 もっともそれぞれの距離は相当離れているのだが。

というわけで、傷がついたままの車に家族を詰め込んで山口まで移動。 はしゃぐ子供たちがうるさい。

寄り道をしたので実に7時間近くかかって山口につく。3分の1は妻が運転したのだが、 私の方がすっかり疲れてしまって、ついたそうそう居眠りをしてしまう。 いや、ゆうべ3時までIA64でのデバッグをしていたのがいけないんだけど。

_ [芸術]トリック×トリック

で、途中での寄り道と言うのが、 「浜田市世界こども美術館」で 開催中の「トリック×トリック」展である。 これは江戸の遊び絵とM.C.エッシャーの作品展示である(8月31日まで)。

私は元々エッシャーの絵が好きなので(「上昇と下降」とか)、これが目当てだったのだが、 江戸の遊び絵もそれなりに面白かった。

印象深かったのは、この解説。

このようなエピソードを聞くと、エッシャーが大の数学好きだったのだろうと想像してしまいますが、 実はその反対で、まるっきりの素人でした。その証拠に、ある学者がエッシャーの版画に使われている 法則について話をしても、エッシャーには全く理解できなったといいます。

信じられないことに、エッシャーのほとんどすべての作品に見られる数学の法則は、 エッシャーが制作をしながら自然と身につけたものだったのです

「トリック×トリック」ガイドブックより

数学苦手の私としては、大変に勇気づけられる言葉である。

妻: 自分をエッシャーと同一視してる?
私: いや、そこまでは...でも、ちょっとね。

2003年08月13日 [長年日記]

_ [休暇]秋芳洞

1.8.0のバグも気になるし、原稿の〆切も近づいているのだが、昼間はやっぱり遊ぶのだ。

というわけで、秋芳洞を訪問する。 ここのことは「あきよしどう」と発音する人と「しゅうほうどう」と発音する人の 両方がいるのだが、どうも「しゅうほうどう」の方が正統らしい。

完成するのに何万年もかかったという解説を聞きながら、 ばかでっかい洞窟を見てると、時間の観念がおかしくなる。 たかだか何十年という人生のタイムスケールを越えると適切に把握するのが難しい。

むしろ、観光のためにこんな洞窟をこっそり作ったんじゃないかとか、 今我々人類が見て楽しむ目的で自然の摂理が用意してくれていたんじゃないかとかの どちらかといえば馬鹿馬鹿しい考えの方に説得力を感じてしまう私の頭はきっとどうかしてるかも。

どうしても自分の生きている時代を特別と考える「現代セントリック」な考えと、 人類を特別扱いしてしまう「人類セントリック」な考えを持ってしまう。

いや、本当に特別なのかもしれないんで、むげに否定するのも変なのだが。

考えてみれば「人類セントリック」と「現代セントリック」は自分たちの信仰の一部でもあるんだし。

_ [Ruby]今日のバグ

今日のバグは再現条件が厳しい。

  • メソッドgでreturnを含むブロックとともにメソッドfを呼び、
  • そのブロックをメソッドfはブロック引数で受け、
  • f内部でそのブロックをcallすると、
  • returnが終了させるメソッドはどれか
  • 正解はg(returnを直接含むメソッド)

returnの飛び先がおかしかった。具体的なコードとしては

def f(&b)
  b.call
end
def g
  f{return 42}+1
end
p g

のような感じ。

とりあえず対処したが、ブロック中のreturnの場合はbreakとは別に対処しなければならないような気がしてきた。


2003年08月14日 [長年日記]

_ 買い物

昨日まで遊び過ぎたので、今日はおとなしく。

買い物で立ち寄ったリサイクルショップでVisor Deluxが4000円。 ちょっと心引かれた。今のVisor Edgeがだめになったときのバックアップ用に欲しいかも。

でも、決心できずに買えなかったと言う。決断力がない。

_ [原稿]Linux Magazine

休暇中とはいえ、バグレポートも〆切も遠慮なくやってくる。

家族の不評を買いながらも、深夜原稿を書いてたりするわけだ。

10月号の原稿のテーマは「オブジェクト指向」。この日記で書いたり、 ツッコミを受けたことを参考に初心者にもわかりやすいように書くように心がけたのだが、 ....読み返すとあんまり初心者にはわかりやすくはないかも。

だいたい用語が多すぎるんだよね。オブジェクト、メソッド、クラスなどなどなど。 しかし、オブジェクト指向という概念そのものがこれらの用語に依存しているので 説明しないわけにもいかないし。ぶつぶつ。

せめて実際に経験してもらおうとirbについても少々紹介してみた。 が、まだ規定のページ数には足りないみたい。もうちょっと。


2003年08月15日 終戦記念日 [長年日記]

_ でえと

子供を妻の実家に預けて、ふたりだけで出かける。なんだか久しぶり。

とはいうものの、連日の遊び過ぎでふたりとも少々疲れ気味。 けっきょくちょっとショッピングして、昼食を食べただけであった。

_ 温泉

その後、実家の近くの奥湯田温泉に入る。ひとり100円は安すぎ。

効能書きによると単純アルカリ泉らしいのだが、湯につかるとすべすべした感触があり、 いかにも温泉らしい気分が味わえる。玉造温泉は歴史はあるものの、お湯は普通だものなあ。

_ 原稿

なんて、ゆっくりした気分を味わってはみたものの〆切が延びるわけではない。

_ [Ruby]irb

で、原稿を書くためにirbを使っているのだが、補完機能が思いのほか便利で、 いまさらながら感動する。

ホームディレクトリの.irbrcに

require 'irb/completion'

という記述を追加すると、あら不思議、TABキーで識別子を補完してくれるじゃありませんか。

しかも、

foo.

の後ろでTABを押せば、変数fooの指すオブジェクトに応じてメソッド名を補完してくれます。 これ、最強。

これがあれば、他の対話環境はめじゃないなと。


2003年08月16日 [長年日記]

_ 帰宅

山口から帰る。田舎の国道でも珍しく一部渋滞していたりしたので、思ったより時間がかかった。

途中、妻に運転を変わってもらったのだが、数分後、寝ぼけて交代したことをすっかり忘れていて、

なぜ私は運転中に寝ているのだっ

とパニックになってしまった。一瞬、居眠り運転で死ぬかと思った。びっくりして大声を出した。 家族もみんなびっくりした。

恥ずかしい。


2003年08月17日 [長年日記]

_ [教会]出雲訪問

今日は出雲支部の訪問の割り当て。

聖餐会の話は、経済的な話。わりと現実的なネタだが、できるだけ借金を避けようとか、 計画的に収入の範囲内で生活しようとか、感謝の気持ちを忘れないようにしようとか。

集会終了後、出雲支部の会計監査。無事終了。


2003年08月18日 [長年日記]

_ [原稿]技術の真髄

Linux Magazineの原稿はようやっと片付けたのだが、 今月は実はもう一本引き受けていたのだ。 これは日経バイトの「技術の真髄」という記事で、 名前が知られている技術者に技術の動向等について 書いてもらうという企画なのだそうだ。

で、私には言語おたくとしてプログラミング言語の歴史と現状と未来についての依頼があった。まあ、好きなネタではあるので、 初心者に分かってもらえるだろうかなどの葛藤がないぶん、楽かも。しかし、これもお盆開けに原稿出すと約束しているので、すでに〆切が過ぎているのだった。メールで交渉し、数日期限を伸ばしてもらう。


2003年08月19日 [長年日記]

_ [会社]送別会

同僚である西田(圭介)くんが退社するということで、 送別会。中華料理。

で、退社後、彼がどうするかというと、SOHOとして うちの会社から開発を個別受注するのだそうだ。 だから、彼の席もそのまま。

OpenCOBOLの開発については ご心配なく。


2003年08月20日 [長年日記]

_ [原稿]「技術の真髄」完了

先日来、書いてきた「技術の真髄」だが、 ようやっと今月分(前半)が完成した。

前半の内容は

  • なぜ世の中にこれほどプログラミング言語が存在するか
  • なぜプログラマ(の一部)はプログラミング言語に魅せられるか
  • プログラミング言語の歴史
  • プログラミング言語の分類

などについて。 目新しい内容としては世界最初のプログラミング言語Plankalkulについてくらいかな。

後半も書かなきゃ。


2003年08月21日 [長年日記]

_ [大学]Linux体験講座

島根大学で開催される「Linux体験講座」に参加する。

いや、私が体験するんじゃなくて、TAとしての参加。 講師の縄手先生には普段からお世話になっているので、 井上社長とともにお手伝いということで。

でもなんとなくスタッフのために用意されたお弁当が目当てだったような気がする。(苦笑)

ええ、皆さんがLinux(GNOME)を体験するのをお手伝いしましたとも。いやあ、実は私がGNOME初体験だったりするのですが。しかも、講座中に日記更新してたりするし。

_ [家族]対話

夕食時の対話

A: きょう学校はどうだった?
B: まあまあかな、先生の手伝いをしたけどあまり忙しくはなかったよ

A = 息子(6歳)

B = 父


2003年08月22日 [長年日記]

_ 訪問者

松江に帰省中のmputさんが会社に遊びに来てくださる。

timitidytimidityのプロジェクト管理の話など、興味深い話をたくさん聞く。 やはり、どこのプロジェクトでも同じような経験をするのね、とか思ったり。

でも、私が中心になっているRubyと集団管理体制のプロジェクトでは、また違った側面もあるようだ。 それとsourceforge遅いとか。やはり自前で用意する方が良いのか。compile farmだけはうらやましいと思う。

_ 記憶のふしぎ

仕事柄、年に2,3度海外に行って、Rubyについて話したり、議論したりする。 また、毎日のように英語のメールを書いているわけだ。

にもかかわらず、私の脳にはすべて日本語で記憶される。

日本に帰ってから「こんな話をしたよ」と説明していると、 「で、それ英語でどう表現するの」と聞かれると答えられなかったりする。 どうも短期記憶から長期記憶に移行する時に自動的に翻訳されるらしい。

だから英語が上手にならないんだ。

記憶と言えば、私は歌の歌詞を覚えることができない。 メロディーはすぐに覚えるんだけどなあ。


2003年08月23日 [長年日記]

_ 休日

木曜の夜から次女が妹夫婦のところに泊まりに行っている。 5人家族のうち、ひとりがいないだけでずいぶん寂しいものだ。

出かけている方は新しい経験の真っ最中なのでそれほどでもないようで、 わりとそっけない。電話でも「ちょっと寂しいよ」くらいか。

残された方は普段と同じ生活なのにいるべき人がいないので喪失感がある。 なんか足りないなあ、とか。 思えば一人暮らしを始めた時には親や家族に同じような思いをさせたのかなあ。


2003年08月24日 [長年日記]

_ [教会]松江

ひさびさの松江出席だが、聖餐会でお話してくれと依頼される。 うう、自分のワードに来た時くらい人の話を聞いていたいんだけど。

テーマは聖典。今は簡単に聖書が手に入るが、昔は写経するしかなかったし、 そもそも中世の教会は一般信徒の入手を禁止していた。 書いた預言者たちも、書き写してきた人たちも大変な苦労をして、 今の聖典が存在する。それくらい大切なものなのに、自分を含めてあんまり大切にしてないよなあ。 あらためて感謝しよう、とかいうような話。

息子はお気に入りの先生がお休みだということでクラスに出たくないとごねる。 誰に似たのか人見知りが激しい。感受性が豊かということだと思うことにする。


2003年08月25日 [長年日記]

_ [OOP]Mix-inと多重継承

matjuことMathieu Bouchardが、「Rubyに本物の多重継承を」と提案している([ruby-core:1378])。

基本的な主張は

  • RubyのMix-inは実質的には多重継承である
  • だからclassとmoduleの差を無くしてしまえば制約が減る
  • より理解しやすいし、説明も簡単になる

というようなことなのだが、私の答えは「気持ちは分かるが賛成できない」である。

というのも、Rubyのmoduleのような制約によってMix-inを強制した方が、 クラスの階層構造のデザインがきれいになることを支援できると考えているからだ。

しかし、改めて考えると、「なぜその方がきれいになるか」とうことを上手に説明できない。

継承のラインとMix-inのラインを区別することで、単純(単一)継承のシンプルさと、 多重継承の機能の両方を実現できる、というのが一応の答えだが、本当にそうか、証拠があるか、 と問われると答えに窮したりして。

結局matjuはあまり賛成が得られなかったということで、この提案を引っ込めてしまうのだが、 将来の考察の材料にはなったと思う。

Mix-inは本当に多重継承より優れているのか

今後も考察を続けたい。

_ [OOP]アイデンティティ再び

最上さんの日記で、 私が書いていることについての疑問点をリストしていらっしゃる。 分からないのは、私が書きなぐった日記を時間をかけて考察しているからではないかと(苦笑)。

これらの記事を読むと「アイデンティティがあること」と「リファレンスあるいはポインタ値があること」と「代入によってコピーが発生しないこと」がほぼ同じ事とされているように思う。しかし本当にこれらは同じことなのだろうか。これが第一の疑問点。しかもこれらがオブジェクト指向の必要条件とされている。

同じじゃないかも。私が同じでない例を思いつかなかっただけで。

これらが必要条件かというとそれは微妙で、 RubyにおけるFixnumの実装などを考えると、アイデンティティがないオブジェクト指向は不可能ではないと思います。 しかし、それはあくまでもtrivialなケースだけで、アイデンティティがない(よって副作用もない)状況で、 実用的なオブジェクト指向プログラミングは不可能ではないかというのが私の意図です。

その辺が、以前「アイデンティティ」で「副作用の全くないオブジェクト指向プログラミングというのは、なかなか考えにくい」と書いた真意なのです。

第二の疑問はこの条件を満たさなくてもオブジェクト指向と呼べる場合があるのではないかということ。例えばC++ではクラスメソッドの内部以外では一切ポインタを使わないことにしてobject.method(arguments); と言う形の呼び出しを使って全てを済ませることが出来る。可変長のものを扱わなくて良いのならクラスメソッドの内部でもポインタを一切使わなくて良い。この場合はアイデンティティはない。ポインタ値もない。代入によってコピーが発生する。でもこれでも充分オブジェクト指向ではないのか。それともなにか見落としているだろうか。

「object.method(argument);という形」がどういう形なのかいまいちよくわからないのですが、 objectというのはスタック上のオブジェクトであるということなのかな。 仮にそうだとしてもC++だとメンバ関数にはthisというリファレンスが暗黙に導入されちゃっているんで、 「ポインタ値もない」とはいえないんじゃないかと。

仮に「メンバも一切使わない」のだとすると、 それだけで実用的なオブジェクト指向プログラミングができるとは私には思えません。 つまり、「不可能」ではなく「実用的ではない」ですね。 動的結合も副作用さえも使えないわけですよね。

追記

あれ、もしかして「アイデンティティがない」って表現を、 「アイデンティティがないものがある」という意味で使ってます?

私は「アイデンティティがないものしかない」という意味で使ってます。 アイデンティティがあるものとないものが混ざっている場合には、 オブジェクト指向するのになんの問題もないので。


2003年08月26日 [長年日記]

_ [Ruby]多重代入

scanfの辺りで悩んだことからきているのだが、また多重代入の挙動で悩んでいる。

いろいろな条件が重なっているので、全体として見るととても複雑で、 自分でも「なんでこうなっているんだろう」と悩むような部分があり、 何ヶ月かおきに「挙動を変えよう」と思ったりする。

しかも、こんなすみっこの挙動に関心を持つ人がいないので、誰にも相談するわけにもいかず (akrさんなら気が向けば考えてくれるかも)、結局自分一人で考えるしかない。

今回問題にしているのは

"a".scan(/(.)/){|*a| p a}

の出力が[["a"]]なのに、

"ab".scan(/(.)(.)/){|*a| p a}

の出力が["a", "b"]である点だ。

いっそ多値でも導入しようかという気にもなるのをぐっと押さえて、いろいろ考える。 結論としては

  • 1要素以下の配列を特別扱いしているのが違和感のもと
  • いっそ配列は全部同じ扱いにしては

というもの、これで後者の出力は[["a", "b"]]になる。 多重代入では

a,b = 1,2
a,b = [1,2]

は同じように動作するので、この変更による影響はあまり大きくないと思う。 いや、本当に大きくないかはやってみないと分からないな。 実際に修正して、試してみよう。「ぎゃっ」と言う人が多ければ考え直すことにして。


2003年08月27日 [長年日記]

_ [OOP]続々アイデンティティ

いくつかツッコミをもらいました、どうも。

まず、ゆあいさんのツッコミから。

アイデンティティが重要なのは、アイデンティティがあるオブジェクトと無いオブジェクトでは、 コピー時の動作が大きく異なるからではないでしょうか?

まあ、そういうこともあるでしょうが、 私が重視している理由は「アイデンティティがないものはオブジェクトではないだろう」ということです。

「オブジェクト指向」というからには「オブジェクト」を意識しないといけないわけで、 そのために最低限必要なものはなにかと考えた時に行き着いた概念が「アイデンティティ」です。

アイデンティティという観点からプログラミング言語(というか計算モデル)を分類すると

  1. すべてのデータにアイデンティティがある
  2. あるデータにはアイデンティティがあり、あるものにはない
  3. すべてのデータにアイデンティティがない

と分類できますが、オブジェクト指向するにあたって、(1)は問題なし、(2)はアイデンティティがないものも「その値がアイデンティティである」と考えて(1)に準じる、とすることができて、(3)ではちょっと無理だろう、というのが私の仮説です。

最上さんのツッコミでは、

  • 暗黙のポインタ:あり
  • 明示的なポインタ:なし
  • アイデンティティ:なし
  • 代入によるコピー:発生
  • 副作用:あり

というC++のサブセットを考えておられるとのことです。 私はこの言語におけるプログラムがどのようなものになるのか想像できないのですが、 実際のところどうなんでしょうね。この言語には本当にアイデンティティがないのでしょうか。

実際には、暗黙のポインタによってアイデンティティが導入されてそうな気がします。

さて、最後にともさんのツッコミです。

アイデンティティが無くて、メンバーはあるけど単一代入で、メッセージ送信はマルチキャストがデフォルトな言語ってどうでしょうか?割と実用的に書けるんじゃないかという気がするんですが。アイデンティティが必要ならそのためのメンバーを書けば利用者がアイデンティティのようなものを使うことはできるし (現実世界ではアイデンティティはそんなに自明じゃなくて、代用品でまにあわせている気がするし)。

これは難しい。

なにが難しいって、おそらく非常に高度な概念を短い言葉で記述してあるので、全体像が想像しにくいことです。

  • アイデンティティがない

    参照がないという意味なのでしょうか。 そもそもアイデンティティがない言語というのが(古い)FORTRANのような 低レベルのものか、純粋な関数型言語くらいしか思いつかないのですが。

  • メンバーはあるけど単一代入

    「単一代入」は分かりますが、メンバーの単一代入というのはどういう意味でしょうか。 初期化時にメンバの値を指定してその後は変えることができないということかな。 Pythonのタプルとかのようなimmutableなオブジェクトを想像しちゃいます。

  • メッセージ送信はマルチキャスト

    これが一番分かりませんでした。複数のレシーバに同時にメッセージを送るという意味だと思うのですが、 「複数のレシーバ」という概念にすでにアイデンティティが含まれていると思うのですが。

ということで、もしよければこのアイディアについていろいろ聞かせてください。

ちなみにこういう場合、「アイデンティティがある」ことになるんでしょうか?個人的にはオブジェクト指向するのに必須かどうかで議論した方が良い気がするんですけど。

すでに述べたように「オブジェクト指向という考え方の最低限」がアイデンティティだと思っています。 アイデンティティのない言語でもオブジェクト指向はできると思っていますが、 そのためにはユーザレベルでなんらかのアイデンティティを導入する必要があると思います。

一つの例としてTclがあります。Tclにはデータ型として文字列しかありません。 数値やリストなどは文字列として表現します。少なくとも表面的には。

で、Tcl上のツールキット(Tk)には「ウィンドウ」とか「ボタン」とかいったような「オブジェクト」が 登場するのですが、どのオブジェクトが明示するために「パス」というものを使います。 たとえば「.frame.panel.button1」のような感じですね。これはTcl的には文字列に過ぎないのですが、 Tkにとってはあるオブジェクトを指し示す参照でありアイデンティティです。


2003年08月28日 [長年日記]

_ チケット

JAOO2003のチケットの手配終了。最終的には向こうが払ってくれるとはいえ、結構な額を立て替えることになる。

もっと重要人物になれば自分で苦労しなくても向こうでチケット手配してくれるようになるんだろうか。 あまり期待できそうにないな。

_ [OOP]アイデンティティFAQ

もうそろそろアイデンティティの話はもういいかなって気持ちになってるんだけど、 乗りかかった船なんで最後にまとめておこう。

アイデンティティってなんですか?
あるものと別のものを区別するなにかです。アドレスだったり、ユニークな番号だったり、 一意に決まる名前だったりします。アイデンティティがあるものが「もの」であり、 存在であり、オブジェクトになります。 まつもとは、アイデンティティがオブジェクト指向に最低限必要なものだと考えています。
アイデンティティがあるとオブジェクトなんですか?
私の主張は「アイデンティティがある存在はオブジェクトとして認識できる」です。 アイデンティティがないものはオブジェクトではありませんが、 アイデンティティがあるものがオブジェクトになるとは限りません。
アイデンティティがないとはどういうことですか?

わたしが「アイデンティティがない」という時には以下のことを意味しています。

  • すべてのデータを一意に区別する手段がない
  • すべてのデータとそのコピーを区別する手段がない

たとえばTclのような言語は、言語機能としてアイデンティティがありません。

アイデンティティがない言語ではオブジェクト指向できないと言う意味ですか?
いいえ、上記のTclでもオブジェクト指向できることが実証されています。 その場合にはユーザが自前でアイデンティティを用意することになります。 オブジェクト指向には何らかのアイデンティティが必要ですが、それを 言語が提供するか、自分で用意するか、は重要ではありません。 ただし、言語が提供した方が楽でしょう。
アイデンティティ以外にもオブジェクト指向に必要なものはあるんじゃないですか? 動的結合とか継承とか情報隠蔽とか。
Selfには継承がありません。CLOSには情報隠蔽がオブジェクトレベルでは存在しません。 動的結合が必要ないケースもたくさんあります。考え方としてオブジェクト指向を考える時、 これらは必須ではないのです。 本当に本質的な最低限はなにかと考える時に登場するのがアイデンティティだと考えます。
アイデンティティがないとは代入でコピーが発生するということですか?
たしかに、すべての代入でコピーが発生するような言語にはアイデンティティは存在しないでしょう。 しかし、実装と概念は切り離して考える必要があります。 今は考え方としてのオブジェクト指向とアイデンティティにについて考察しています。

2003年08月29日 [長年日記]

_ [Ruby]local jumpの改善

ふと思い立ってeval.cの大改造。変更した点は以下のとおり

  • ブロック付きメソッド呼び出しのたびにBLOCKTAGオブジェクトを生成していたのを止めた
  • ブロック内からのreturnやbreakは妙なことをして伝達していたが、単純化
  • POP_TAGはreturn値をコピーしていたが、止めた。returnやbreakが直接設定する
  • ブロックのorphan判定を単純化。scopeがNOSTACKかどうかだけで判断する

試行錯誤でコーディングしているので、ここを直すとあちらが動かずなどということを繰り返しているうちに、 次第に全体像が頭に入ってきて、あるべき姿を理解できるようになった。こういうコーディングしているから、 いつまでたってもバグがなくならないんだろうなあ。

で、改造結果だが、構造はやや単純になったが、別に速くなったわけではないと思う。 しかし、なんだか達成感がある。

私がRubyをハックしているかたわらで、妻は手芸にいそしんでいた。夜中の3時まで。 お互いに夜更かしが過ぎます。


2003年08月30日 [長年日記]

_ [家族]流しそうめん

知人の家で流しそうめんをやるということで、お誘いを受ける。 本当は8月9日の予定で、LL Saturdayと重なるので無理だと思っていたのだが、 例の台風のおかげで今日に延期になっていたのだ。 あの台風にはひどい目にあわされたが、いいこともあるのだな。

あいにく天気はあまり良くなく、小雨混じりの天気であったが、決行。

竹を割って樋のようなものをつくり、器を作り、箸を作り、水とそうめんを流す。 途中から水遊びを始める子供たちもいたし、庭の家庭菜園を探検するものもいた。

後には、泥だらけの靴、びしょぬれの服、虫さされの痕。

大人も子供も楽しんだ。


2003年08月31日 [長年日記]

_ [教会]松江

松江に出席。今日はお話もない。

しかし、妻がお話の割り当てが当たっていた。彼女なりに緊張していたらしい。 ゆうべも遅くまで準備していたし。結果はいい話であった。

_ [OOP]箱モデル

ruby-listで「変数=箱モデル」の優劣についての議論がある。 まあ、あくまでもたとえなんだから、完全なたとえはありえないわけだが。

箱モデルについて考察すると、まず前提としては

  • 「箱モデル」は、変数は値を入れる箱という実行モデルを説明するためのもの。
  • そのような実行モデルを持つ言語はいくつかある(Cとか)

ということがある。これは別に問題ない。 私がCの解説書を書けと言われたら、変数の解説には箱モデルを使うだろう。

問題はそれをRubyの解説書に適用するのが適切かどうかだ。 これはもちろん読者のバックグラウンドによって違うだろう。

すでに箱モデルになじんだ人にとっては箱モデルの解説に意味があるのは確かだが、 問題は

  • 箱モデルを自覚的に理解している人は実はあまりいないかも。
  • 十分に箱モデル言語を理解していれば「ポインタと同じ」で通用するので、たとえ話は不要。
  • 箱モデル言語に対する知識がない人には、Rubyの解説としては役に立たない
  • ここで箱モデルを説明したとして、Rubyの次に習う言語で役に立つとは限らない。必要なら、その時改めて箱モデルを学んだ方が良さそう。

ということだ。やっぱり、Rubyを題材にした解説本に箱モデルは有効ではないんじゃないかなあ。

ただし、反論の中にはいくつか興味深いものがあるので、引き続き考察してみる。

オブジェクトIDを入れた箱という解説は有効
オブジェクトIDと言うのは「数値で表現したアイデンティティ」に過ぎないので、 このたとえ話で一度に説明する必要があるものではない。
配列を箱が並んだものと説明するために箱モデルが有効

配列は普通箱の並びとして図示するので、気持ちは分かる気がするけど、 「名札が並んだもの」でも別に困らないと思う。

一番心配するのは、箱モデルでは変数に箱という実体を与えてしまうため、 変数がオブジェクトであると認識させてしまうのではないかということ。 変数が実際にオブジェクトであるCのような言語でない限り、じゃまにしかならないような。


最新 追記