Matzにっき

_ [OOP]Mix-in

えー、Mix-in評論家のまつもとです。今日はshudoさんからコメントをいただきました。

mix-inの由来はともかく、次の2点がひっかかりました:

1. C++にmix-inクラスがある。
2. そういったmix-inクラスは、C#のinterfaceと同様の役割を果たす。

1.については、ここでは、多重継承を使って実装を差し込むことをmix-inと呼んでいるのかな？と想像してます。そういう流儀があるんでしょうか。 2.が言わんとすることは、なかなかわかりませんでした。ようやく気づいたことは「ここでは、実装(メソッド)の付加ではなくて、役割(interfaceも可)の付加をmix-inと呼んでいる」ということです。これをmix-inと呼ぶのは、どうなんでしょう？

まず、(1)ですが、元々Mix-inという用語が生まれたのはLispのオブジェクトシステムである Flavorsで、そのココロは「アイスクリーム(のフレーバー)にキャンディやチョコを混ぜ込む(Mix-in)」から なのだそうです。ちなみにそのアイス屋はSteve'sだそうです。だからFlavorsなんですね。

で、そのFlavorsシステムには多重継承はあってもMix-inという機能はありませんでした。 つまり、当時Mix-inとは多重継承の使い方だったわけです。ですから、そこから考えると(1)は必然です。 そういう流儀がある、というよりは、歴史的に見ると「Mix-inだけを目的としたエンティティ(moduleやtrait)」という考え方そのものが亜流なんでしょうね。 私はこの「Mix-inだけを目的としたエンティティ」をRuby以前に見たことはないので、 「実はオリジナルかも」とひとり悦に入っているのですが、実際に調べてみると先行者はいそうですね。

次に(2)についてですが、先程も述べた通り、元々Mix-inは単なる多重継承の使い方に過ぎず、 仕様の継承や実装の継承に限定されていませんでした。というか、Flavorsにはそんな区別はありませんでしたし。 ですから、仕様の継承を行うinterfaceのことをMix-inと呼ぶのは決して間違っていないわけです。 ただし、

These mix-in or capability classes serve much the same role as interfaces do in C#.

とまで断言すると、「実装の継承はどうした」と突っ込みたくなりますが。

_ [教会]ホームティーチング

ひさしぶり。灌油をしようと思ったら油が切れていた。10人の乙女のうち、駄目な方の5人のようだ。 結局、油を借りてしのいだのだが、「備えよ常に」という言葉を思い出してしまった。

_ [OOP]Mix-in(コメントあれこれ)

Mix-inについてコメントをいただきました。まず、shudoさんから。

「"Mix-in"は、当初は多重継承の使い方を指す言葉だった」

僕はRubyでMix-inを知ったもので、大変ためになりました。

正確には「当初は」ではなく、現在でも、です。 多分、海外ではほとんどの人はMix-inを多重継承の使い方として理解していると思います。 私はMix-inの啓蒙の意図を込めてRubyのmoduleを設計したのですが、 首藤さんのような人までが「Mix-inといえばアレ」と認識するようになるとは、クスリが効き過ぎたかな。

次にtmaedaさんから。

Metrowerks の CodeWarrior に PowerPlant という C++ のフレームワークが ついていて、PowerPlant では Mix-in が非常に効果的に使われています。

Ruby と比べてどっちが先か、というのはちょっとわかりませんけれども、 PowerPlant も結構昔から存在していたので、もしかしたら PowerPlant の方 が先かもしれません。

Googleで調べると、PowerPlantは1994年からだそうですから、Ruby(1993年)の方が若干古いですね。 いや、1994年は発売された年だから、開発開始はもっと古いのかな。 いずれにせよ、PowerPlantのMix-inは(C++ですから当然)多重継承の使い方としてのMix-inでしょう。 このようなMix-inの起源は上にも書いたようにMITのFlavorsで1979年のことだそうです。 「Rubyがオリジナルかも」と思っているのは「Mix-inだけを目的としたエンティティ」ですから、 直接は関係ないですね。

それから、suminさんから。

エンティティとしての Mix-in に関しては、Strongtalk ('93) の Mix-in ('94-)は Ruby と同じくエンティティみたいです。もっとも Java がらみで Strongtalk の公開は 2002 年までずれ込みましたから、Matz さんの自負を何ら揺るがすものではないでしょう。Strongtalk は Self の人たちとの共同研究成果なので、Ruby と Mix-in 発想の経緯は似たものだったように推察しますが、(Ruby の Mix-in に関しては Self ゆずりということで)当たっていますか？

StrongTalkは2001年にOOPSLAで発表していたのを聞きました。 その時は型についての話ばかりでしたので、Mix-inがあるとは気付きませんでした。 93年ということはこれもRubyとほぼ同時期ですね。

プロトタイプベースのSelfにはクラスがありませんから、Mix-inもないんじゃないかと思います(StrongTalkにはクラスがあります)。ですから、RubyのMix-inがSelfゆずりということもありえません。

私のMix-inについての知識は以下から来ています。

• 『CommonLispオブジェクトシステム - CLOSとその周辺 -』, Bit1989年1月号別冊、共立出版

  5章「共通例題による他の言語との比較」p.84にExplorerのFlavorsの紹介があり、 その中でMix-inについて説明しています。 ほんのわずかの記述ですが、私のSteve'sについてなどの知識はここからです。 書いたのは日本ユニシスの川辺さん。

• SuperASCII 1992年6月号

  Browsing OOPLという連載の2回目。 「OOPLの最新モデルとしてのLisp」というタイトルでCLOSを紹介していますが、 この中でMix-inの紹介をしています(p.121)。これを読んで初めてMix-inについて理解できました。 書いたのは日本電気の佐治さん。

で、これらの知識をベースにMix-inを啓蒙(強制)するために考えた仕組みが、 「Mix-inだけを目的としたエンティティ」であるRubyのmoduleです。 ですから、発想としては独自ですね。1993年のことです。

_ [Net]Orkut.com

先日なにげなく登録したOrkut.comだが、Cnetの記事によると「Orkutは会員を限定しており、招待された人しか入会できない」ので、「先週、同ネットワークへの招待状がeBayのオークションサイトで11ドルで落札されたというできごとがあった」のだそうだ。

今はトラフィックの問題で休止中だが、実は貴重な機会だった？

_ [家族]三ヶ月目

末の子が生まれて今日でちょうど三ヶ月だ。 猫のようだとも思ったが、 もうずいぶん人間らしくなった。

って、1ヶ月のときにも同じことを書いてるぞ。

_ [Ruby]Ten Things Every Java Programmer Should Know About Ruby

Jim Weirichからの

We will be introducing Ruby to our XP Users group in Cincinnati next week. I thought it would be fun to create a list of "Ten Things Every Java Programmer Should Know About Ruby" to help the transition. I've got a number of things in my head, but would love to hear ideas from the mailing list.

来週コネチカットシンシナティのXPユーザーグループでRubyについて紹介するんだけど、 「Javaプログラマが知っていたほうがいい１０の事実」なんてリストを作るといいんじゃないかと 思うんだ。リストからの提案歓迎(超訳)

というポスト。

これから一大スレッドが発生する。とりあえずリストメンバからの提案は、 Jimのta-da listにまとめられている。 っていうか、１０どころじゃないんだけど。

そこから派生して

• Javaにはリファクタリングブラウザがあるが、Rubyにはない(RBBを紹介すべきか)。
• Static TypeとDynamic Type

などの話題が爆発する。

Francis Hwangの「Coming to Ruby from Java」も参考になる(かも)。

_ [OOP]OOP Is Much Better in Theory Than in Practice

「オブジェクト指向は一見すばらしいアイディアのように見えるけど実用上はそうでもない」という主張。

ま、オブジェクト指向ファンを自認する私でも万能だと思っているわけではないから、 彼の主張は理解できないでもないのだが、それは「向いていない局面もある」という意味だと理解していて、 今さら利点について議論の余地はないと感じていた。

そういうところに、この主張はかえってものめずらしい。 でも、どっちかっていうと２０年前なら珍しくなかった議論がなんかの偶然で「生き残って」しまった、 という印象かなあ。

「OOP Criticism」というページまで作って、 一生懸命オブジェクト指向プログラミングを否定する熱意はとても理解できない。 かつてオブジェクト指向に過大な期待をして、「万能でない」ということを発見した落胆が動機になっているのかなあ。

「OOPは実用的なケースでだめ」と主張する割に、彼の「Challenge」ではオブジェクト指向ソリューションの方が見栄えが良く、それに対して「不完全な解に過ぎない」などといちゃもんつけているのが美しくない。それって結局大差ないってことじゃん。 さらに、彼が「より良い手法」と提案する「Table Oriented Programming」が全然魅力的に見えないし、オブジェクト指向よりも汎用性が低そう。

そう感じるのは、私がオブジェクト指向プログラミングに「毒され」すぎているからだろうか。

_ [家族]ふたば祭

子供たちの小学校の文化会(のようなもの)。演劇や発表などなど。 それぞれの発表を見たが、がんばっていた。

高学年になった娘たちの同級生にはもはや大人サイズの子もいる。 妻より身長高いんじゃないか。幼稚園のころから知っているだけにびっくりする。 ヒトの子の成長は早いわ。

_ [言語] LINQ

遅延Enumerableに関連して コメントで教えていただいた LINQ(Language Integrated Query)だが、 C#だとこんな感じらしい。

var 学籍番号前半名 =
  from p in 学生名簿
  where p.学生番号 <= 15
  orderby p.学生番号
  select p.名;

ふむ、だけどこれならRubyで

学籍番号前半名 =
  学生名簿.
  select{|p| p.学生番号 <= 15}.
  sort_by{|p| p.学生番号}.
  collect{|p| p.名}

で実現できるよね、

各節に当たるものが独立なので、同じパラメータを何度も指定する必要があることと、 効率良く実装するのがちょっと大変ということは除くとして。

ブロック万歳。

だが、「|p|」が何度も登場するのは確かにちょっとうっとうしいかも。 ruby-talkで話題になっていた「implicit block parameter」(具体的にはGroovyの「it」)が欲しくなるかも。

そうすると、こうなる

学籍番号前半名 =
  学生名簿.
  select{it.学生番号 <= 15}.
  sort_by{it.学生番号}.
  collect{it.名}

あるいは、一連のブロックで共通に使うパラメータを用意すると言う手もあるかも。 今は文法、思いつかないけど。

いずれにしても、LINQいらないじゃん。

後はLINQっぽいものを効率良く実装する仕組みだな。

あ、でも、上記のページで紹介されている「C# 3.0の新機能」はどれも面白い。 「面白いけど、ほんとに(言語レベルで)必要？」というものが多いけど。

もうちょっと考えてみよう。

_ シガーソングライター(もどき)

ディスカウントストアで「シガーソングライター」のようなものが、 安売りしていたので思わず購入。4980円。

外見も含めてほぼ同じ(OEM?)のようだが、再生順序が謎(シガーソングライターはファイル名順らしい)。 ドキュメントには登録順と書いてあるのだが、どうもそうでもないようだ。 FATファイルシステムのファイル取得順ってなにかあったっけ？

fatsortとかを導入してみればよいのか。

ユーザインタフェースについては気に入らない点が二つ。

• 電源が落ちるとリセットされる
• 「戻る」ボタンを押すと、前の曲の先頭に戻る。

前者はコスト的に記憶系を一切持っていないだろうから、しかたないとしても、 後者は手抜き過ぎかな。

_ [教会] リアホナ2007年２月号

先日インタビューされた記事が 教会の月刊誌リアホナ２月号ローカルニュースに掲載された[PDF]。 なんだか照れ臭いぞ。

教会でも読んだ人から「読みましたよ」と言われて、恐縮する。 恥ずかしい。まあ、覚悟の上で引き受けたんだけど。

集会では、先週のバプテスマに引き続いて、按手と確認。

集会後、セミナリーの補習。教材ビデオを見たのだが、 (すでに見たことあるプログラムだったのに)感動してうるうるしてしまった。 年取って涙腺がゆるんだか。

_ 散髪

息子の学校で学級閉鎖があったので、 息子共々散髪に。さっぱりした。

が、すこし伸びてた髭がまた剃られてしまった。

そんなもんだ。

_ asahi.com：副検事、特急列車「止めて」　松本駅乗り過ごし停車 - 社会

ラジオのニュースで聞いた。 検事さん、乗り過ごしてしまったのは失敗だったけど、 次の駅で列車を止めてもらえてどんなに助かったことだろう。

いい話や。

と、思ってたんだけど、なんかアナウンサーのコメントとか聞いてると なんか不祥事っぽい対応してるように見えるんだけど。

世の中、それだけ不寛容になってるということか。

_ [Ruby] コミッタになった - まめめも

「やりたい放題です」w

どうぞ、よろしく。

_ [OSS] NokiaがノルウェイTrolltechを買収へ、ソフトウェアを強化 | 経営 | マイコミジャーナル

MySQL ABに続いてTrolltechまでが買収とは。 これをどう読み取るべきか。

1. オープンソース企業がビジネスになることが明らかになったので買っておこう
2. オープンソース企業間でも寡占化が進みつつある
3. とりあえずある程度規模の大きなIT企業には金が余っている。バブルっぽい？

うーん、(3)かな。

_ [Ruby] ruby, java Job Trends | Indeed.com

RubyとJavaの求人数の伸びをグラフ化するとこうなる、という話。

ほぼ横這いのJavaに対して、 Rubyがめちゃめちゃ伸びていて、このグラフだけ見るとRubyの圧勝、という印象がある。

実際には母集団の数が全然違うわけで、ここで「伸びてる、伸びてる」と 安易に喜ぶのもどうかとは思うけど。一種の統計のマジック。

とはいえ、一部で言われているような「Ruby(とRails)のピークは2006年。現在は下降気味」という 説に対する反証にはなっているような。