通常通り。いや、第一だが断食ではないぶん通常ではないか。
帰省でしばらくぶりの人たちに会うことができた。 引っ越していった友達に会えた子供たちは喜んでいた。 本当は山口に行くはずだったのに、 病気で延期になってしまったのだが、良いこともあったね。
青少年クラスに授業参観。なかなか力が入っていた。 今後にも期待したい。
あとは休憩。一日休んで過ごす。 PCも動かないしな。
妻の実家の山口に出発。今回はPCは壊れてるし、 実家にネット環境もないのでしばらくはネットから隔絶される。 メールも読めそうにない。
OOPSLAなどの論文でも読んで暮らそうか。
まず山口への移動が大変なんだけどな。
予定より遅くなったが無事到着。
妻の実家にあるデジタル体重計のユーザインタフェースが秀逸だ。
従来のアナログ型体重計の操作ステップ(おおげさな)は以下のようになるだろう。
単純だ。しかし、たまに原点(負荷がかかっていない状態でのゼロ点)がずれていたりして不正確なことがあるので、 時々針の位置を調整する必要があるし、目盛りが動いたりして、 正確な数値を知ることが難しいときがあってストレスがたまる(ような気がする)。
一方、私の家にあるような通常のデジタル型体重計の操作は以下の通り。
まあ、普通だ。操作ステップがやや増えているので実際は面倒になっているのだが、 これが「より正確(そう)な数値」、「原点調整不要」というメリットとどう折り合うかの問題だろう。 本当にアナログ体重計より正確かどうかは実際よくわからないけどね。 あっちは針の位置で、なんとなくより細かい情報を示しているわけだし。
ユーザインタフェースの話に戻ろう。
これに対して妻の実家にある体重計の操作ステップはこうだ。
すばらしい。アナログ体重計に負けないくらい単純になっている。 「原点調整を後で行う」という発想はコロンブスの卵のようだ。
眼鏡利用者としては、降りてから顔を近づけて数値が読めるのも助かる。 体重計に乗る時は眼鏡を外していることも多いので。
不親切だった年末のエントリの続き。
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も実装も事前に十分に検討する必要があるだろう。
....、論文ネタになるかな。無理かな。
Smalltalk版はインタプリタそのものをいじって、メソッド呼び出しのコストが1.2倍程度らしい。 Java版はプリプロセッサを使っているのだが(だから仕様としては結局はC#のpartial classと同じ)、 ナイーブな実装のためかメソッド呼び出しが25倍遅いらしい。これは痛い。
Rubyの場合、インタプリタを直接いじれば、(今の実装ならば)グローバルメソッドキャッシュが効いて それほど遅くならずにすむのではないだろうか。ただ、クラスの参照がインダイレクトになるのが どの程度影響するのかはやってみないと事前に見積もるのは難しいだろうなあ。
山口は昨日に引き続き今日も雪。妻の実家の周辺もそれなりに積もっている。
山口から島根の県境の少し先くらいまでは結構な山道なので少々心配する。 雪でスリップ続出とか渋滞とかイヤだなあ、と思って。
しかし、実際にはそんなことは全然なくて、 道はちゃんと除雪されているし、 渋滞もないし、 快適だった。そんなに眠くもなかったし(運転手以外はみんな寝てたけど)。
途中で食事したり買い物したりしていたので、 予想以上に時間はかかったが無事帰宅。
ちょっと疲れたな。
で、帰省期間中、(故障している)Thinkpad X31を持って帰ってはいたものの 一度も電源を入れなかった。こんなにPCから離れていたのは久しぶりだ。
で、生活はどうだったかというと、 Webがチェックできないのはちょっと寂しかったけど、 思ったほどには不自由はなかった。
ヒトはインターネットやコンピュータがなくても生きていけるんだ。
大発見である。
しかし、自宅に戻ってインターネットアクセスが戻ると 溜まりに溜まったWebチェックにメールチェックに奔走することになる。 いつまでたっても終わらない。泣きそうである。
IBM スマートセンター(0120-20-5550)に電話して修理を手配する。 レノボになってもまだ「IBMスマートセンター」なのね。 クーリエサービスの引き取りは(月曜が休みなので)火曜日10日になるそうだ。 しかも、そこから10日から2週間、費用は6万弱かかりそうだ。痛い。
しかし、5550って日本IBMのふっるーいマシンの型番じゃなかったっけ。 IBM PCとか出てくるよりずっと前の。こんな形で歴史に跡を留めるとは。
山陰地方は大雪。少々高台にあるわが家は一面雪に被われた。
今日は、私の実家に行こうと思っていたのだが、 先方が風邪でダウンだそうで、中止。
子供たちと妻が玄関先を雪かきしている。 ガレージの辺り、かなり広くなっているのだが、 ここが低温で凍ると車の出し入れが面倒になるからだ。
次女は積み上げた雪で「かまくら」を作って楽しんでいた。 うーん、かまくらなんて子供の時に見て以来だなあ。
で、しょうがないんで、路地の入り口からガレージまで2,30メートルほど、 私が雪かきをした。息が切れた。あんまり電池の保ちが良くないんで。
ぐったり。
先週は第一日曜日だったが、 元旦だったので、今週が断食。
司会だった。
日曜学校は青少年クラスへ。 正規の教師からちゃんと課題が出ていたので、 私は監督するだけ。 みんな真面目にやっていた。
集会後、人を送っていったり、 用事をしたり。
米子へ行く。
実家の両親はまだ風邪が治り切っていないということで、 挨拶のみ。去年から滞っていた贈り物や荷物の交換。 こちらの風邪、向こうの用事などでクリスマス前からずっと会えてなかったから。
その後、弟のうちに行き、赤ん坊を見てくる。 まだ生後10日にもならないが、結構男の子らしい顔をしているような気がするのは 思いこみか。
その後、買い物などして帰る。
1930110979
ネタは「コードジェネレーション」。参考文献は 『1930110979』 by Jack Herrington。
しかし、コードジェネレーションっていうテクニックは 対象言語がRubyのような動的言語であればそれほど必要になることはない。 メタプログラミング機能を使った方が便利だし手軽だからだ。
Railsの用にコードジェネレーションとメタプログラミングの両方を活用するケースもあるけど。
で、今回はJavaのためのコードジェネレーションをRubyで行うという 話の流れにしようと思っているのだが、 いかんせん私のJavaの経験がほとんどないので 悩ましい。対象言語をCとかにしたいところではあるのだが、 Cにはマクロがあるのでけっこうカバーできちゃうしね。
苦手なテーマを選ぶと書くのに苦労する。 先週末は具合が悪かったから、なかなか進まなかったし。
ポータブルバックエンドのC--を対象にしたRubyコンパイラの研究。
博士論文(あるいは卒論?)のプロジェクトなので実用になるレベルまで発展するかどうかは 未知数だが、大変興味深い。
ん? また、スウェーデンか。以前.NETを対象にした研究をしてた人も確かスウェーデンだったよな。 大学は違ったように思うんだが(うろ覚え)。
あの国はこういうプロジェクトが好きなのかな。
RubyのOpenクラスの功罪について。
Openである(既存のクラスに動的に機能を追加できる)ことは、 結局はグローバルに変更を行うことだから、副作用があり、危険でもあるが、 同時に普通の手段ではできないことができる可能性もある。
特にオブジェクト指向プログラミングにおいて、システムが提供するものも含めて オブジェクトに挙動を追加できる(or 変更できる)のはすごいパワーを発揮できる。
だが、単なる追加ならともかく、「変更」は冒険だ。 jcode.rb(文字列をマルチバイト対応にする)やmathn.rb(除算などを有理数対応にする)などは、 グローバルな影響の範囲が見積もれないので気安く使えない。
そこで、Classboxという「その上」を考えている必要が出てくるのだ。
GoogleでのGuido van Rossumの生活の様子。
なかなか楽しそうだ。
いや、でも、フルタイムRubyのためにほぼ自由に使ってもかまわない私の方がもっと恵まれているわけだが。
4774122920
あいかわらず日経Linuxの記事が終わらず悩んでいる。〆切今日なんだけどなあ。
で、あまりに悩んだので、本屋でJavaの本を購入。 買ったのは『4774122920』。 内容よりは水玉蛍之丞のイラスト(とマンガ)が購入の決め手になったのは内緒だ。
言語仕様はともかく、EJBやJBossなどについては無知なので大変参考になった。 またXDocletというコードジェネレーションテクニックを使ったツールがあるということも 名前だけしか知らなかったので勉強になった。
しかし、こんな泥縄の知識に基づいた原稿で読者の皆さんにちょっと申し訳ない気もする。 来月はちゃんとよく知ってるRubyに関連するネタを選ぼう。
しかし、こうやってJavaのプログラムを見ると、 自分でこういうプログラムを開発することを想像するだけで憂鬱になる。 世に入るという「Java好き」の人はこんな冗長性とか気にしないのかな。
裏表紙には「Javaが好きなプログラマだけに本書を勧めます!」とあるので、 私ははなから対象外なのかもしれないけど。
宣教師のお手伝いに出かける。 今日教えた人は中国人で大学の研究生という人。 日本語はまだほとんど分からず、英語と中国語(北京語)が話せるということだった。
で、会話の内容は英語。本を読んでいただく時には中国語という状況で なかなか意思の疎通が大変だった。
というか、四人いて、開いている同じ本が、 英語(宣教師A)、ポルトガル語(宣教師B)、日本語(私)、中国語[繁体字](研究生)という 非常にインターナショナルな状況であった。
中国語には二種類の記法がある。
ひとつは本土で用いられる簡体字で、英語ではSimplified Chineseと呼ばれる。 もうひとつは主に台湾で用いられる繁体字で、英語ではTraditional Chineseと呼ぶ。
で、今回いろんな人と話してて、Simplified Chineseは言語そのものが簡単化されているのだと 思った人が複数いた。実際にはこれらは文字の画数が多いか少ないかしか違わないんだが。
もっともSimplified Chineseは北京語に、主にTraditional Chineseは広東語に使われるから
その辺の違いの方が大きいんじゃないかと思うんだが、
先の研究生はTraditional Chineseの本をなんの支障もなく読んでたなあ(Simplifiedの方が楽とは言ってたけど)。
追記:
繁体字は主に台湾で用いられるが、台湾の公用語は標準中国語(ほぼ北京語)だそうです。彼がすらすら読めたのはそういうことだったのね。
<URL:http://ja.wikipedia.org/wiki/%E5%8F%B0%E6%B9%BE#.E8.A8.80.E8.AA.9E>
娘が教会の活動でボーリングに参加する、とのこと。 ボーリング場まで連れていく。
で、ゲームコーナーで妻とエアホッケーを楽しむ。 で、辛勝したのだが、気合いが入りすぎて終わった後ぐったりしてしまう。
なんか毎週一度は体力が落ちていることを実感するな。 先週の雪かきといい。
聖餐会の話者で来れない人がひとりいて、時間が足りないかもしれないということで、 足りなかったらお話しして、と依頼される。というわけで、 どんな話をしたもんだか、と、人の話を聞きながら聖書を開けたりしてみる。
が、結局残りの話者で時間は十分だったので、私は話することなく終わった。
おかげで妻の話が集中して聞けなかったなあ。 なかなか面白い話だったのに。
また、日曜学校の教師も間に合わないかもしれないということで、 代理教師を依頼される。が、ふたを開けてみるとちゃんと間に合ったので、 代理の出番はなかった。
ま、こんなもんか。
時間数が足りなかったということで、補習。
とはいうものの、一通り教えてあるので復習ということで。 主に(パウロの)手紙を中心に。福音書は読んだり勉強したりする機会が多いけど、 手紙はあまり触れないものねえ。
日経Linuxの編集から「原稿が届いていません」との泣きのメールが。
こちらとしては土曜日に確かに出したつもりなのに届いていないらしい。 あんなに苦労して書いたのに。
最近、
などいろいろと変動が相次いでいるので、それのどれかが悪かったのだろう。
どうもGmail経由だと届いて、会社経由だと届かないようだ。 それってnetlab.jpがどこかのブラックリストにでも乗ったということなんだろうか。
えーと、なんというか...。
しかし、外見がアレな部分を取り除いて本質を見るとなかなか興味深いものがある。 まったくメジャーになりそうな方向性ではないが、そういうことを目指すものではないだろう。
「萌香」はRubyで実装されている。
Smalltalk(Squeak)用のClassbox、Java用のClassbox/Jを参考にしつつ、 Classbox/Rをデザインしてみる。
しかし、Rubyでは
などの理由で、そのままは適用できそうにない。Classboxに似た概念は必要そうだが、 ちょっと違うものになりそう。
あれ、待てよ。
Classboxから派生する二つのマイナーなアイディアを組み合わせると、 かねてからの懸案であった
相当(追記: これらの機能が解決しようとしていた問題の解決)を一度に実現できるような気がしてきたぞ。
詳細を書くにはこの余白は(ry (またか)。
冗談はともかく、なかなか良さそうなアイディアのような気がしてきた。 しかし、良さそうと思っても実際にやってみるとそうでもない場合はたびたびなので、 もうちょっと考えてみよう。確実に言語(クラスまわり)が複雑になるので、 仕様の複雑さや性能とのトレードオフになるな。
まあ、この辺は(多重代入とかと違って)元があんまり複雑じゃないから、 仕様の複雑さの方はあんまり問題にならないかなあ。
Classbox/Rの参考になるかもと思い、 CommonLispのパッケージについて学ぶ。
が、こちらは結局はシンボルの名前空間に過ぎない(こういう時は総称関数がうらやましい)ので、 あまり参考にはならなかった。が、名前空間というのはいろいろ難しい問題をはらんでいる ということは分かった。
Put in seven extremely random user interface commands
だっけか(CLtL「パッケージ」の章参照)。 結論としては、「CommonLispのパッケージ管理の仕様は複雑過ぎて使いにくい」。
Javaのパッケージ名にドメイン名を含めるというのは秀逸なアイディアだと思う。 ユニーク性が保証されたパッケージ名を簡単に用意できるから。 逆順だし見栄えはあんまり良くないけど。
Pythonのファイルごと別々の名前空間という仕様も優れた点が多いと思う。 Rubyでは、どういう風にファイル分割するのかは、名前空間とは独立に 自分で決めたいという理由で今のようになっているのだが、 ある意味制約されたPythonの方が一般的なケースでは使いやすいかも。
「はてなおや」さんのはてなでの質問。
Emacs暦は16年にもなるのに、意外と知らないものだ。
とかは使ってみようかなあ。
私が普段使ってて、人があんまり知らないのは(...elispディレクトリを調べている...)
くらいかなあ。
これはyaccルールを編集するモード。昔ネットで拾ったけど、 誰が作ったのか、どこで拾ったのかまったく覚えていないという。 それなりに便利だけど、 でも、今ならmmm-modeとか使ってもっといいのがあるかもしれないなあ。
あとは、anthy-kyuri.elってのを作ったけど、本家に取り込まれたみたいだし。 それに「きゅうり改」のキーバインドなんて、私以外の誰が使うんだ。
「オブジェクト指向神話」という言葉があるらしい。 こことか、 こことかで見受けられる。
要するに「オブジェクト指向は万能ではない」 または「適材適所」という話なので、一般論としては異論はない。 私がいくらオブジェクト指向プログラミングの長年のファンだからといって、 「万能」だとか「魔法の薬」、「銀の弾丸」のようになんでも解決すると主張するつもりはない。
だが、実際にこれらのブログエントリにおいて 「オブジェクト指向に向いていない」とされているのはなんなのだろうか。
読み進めているとこういう記述にぶち当たる
ふむ、「モデリング」ね。いつから「オブジェクト指向=モデリング」になったのだろうか。 この辺が「神話」なのかな。 この日記に引用されているように、ナップザック問題を解くのに、ナップザックやら缶詰やらのクラスを作るだけでは、問題は解決しないだろう。 しかし、逆にプログラム中でナップザックやら缶詰やらを表現する「なにか」を用意しなければ、 問題を解決することはできないだろう。オブジェクト指向はその部分を支援するものであり、 それ以上ではない。
よって、これは「オブジェクト指向の問題」ではない。
では、これが「神話」と呼ばれるということは、 「オブジェクト指向で問題解決」というイメージがいまだに存在しているということなんだろう、たぶん。
実際には、オブジェクト指向プログラミングは、構造化プログラミングの「次」と 認識されるべきものだと思う(OOAやOODのことは知らんけど)。
プログラムの開発に構造化プログラミング(乱暴な言い方をするなら、gotoを使わない、データ構造を意識する、など)を導入することと、問題の解決を混同する人はいないだろう。構造化しようとしまいとプログラムが必要なことには変わりないのだ。
オブジェクト指向プログラミングもそれと同じレベルである。 (インテリジェントな)データを用意し、それを中心にプログラムを構成する。 あくまでもプログラムの構成方法だということを認識すれば、 どんな構成をするかでわかりやすさや保守しやすさ、あるいは開発効率に影響が出るにしても、 できないことができるようになるわけではないということを認識するのはそんなに苦ではないのではないか。
正直なところ、20世紀によく見かけた「オブジェクト指向幻想」はもうそろそろ収まっているのではないかと 認識していたのだが、まだ「オブジェクト指向神話」なんて表現を目にする現状では あらためて強調しておいた方が良いのかもしれない。
そして、21世紀の今、わざわざ構造化プログラミング重要と叫ぶ必要がないのと同じように 近い将来、わざわざオブジェクト指向プログラミングがどうこうと言わなくても 当たり前になるのだと思う。一部の特殊な状況を除いて。
もうとっくになっててほしかったんだけど。
言語デザイナーはもうそのことに気づいている。 だいぶ前から新しく登場する言語は(一部の例外を除いて)みんなオブジェクト指向言語だ。 この「常識」がすみずみにまで到達するのに何年掛かるだろうか。
妻が思い立ったので、今日は「片付けの日」ということに。
二階にあった子供用の小タンスを一階に移動することに。 まず、妻が子供たちと一階を片付けたり掃除をしたりしている間、 私は赤ん坊のお守り。いまやちょろちょろ走り回るので、 これがなかなか一苦労。
その後、タンスを移動。恐れていたほどには重くなかった。 腰壊したらイヤだなあと思ってたんだ。
すこしきれいになった。
で、さらに妻が「焼肉を食べるのはどうだろうか」との発言。
普段あまり肉食を好まない草食動物的な(でも魚は食べるな_)ヒトの発言にしては珍しい。
子供たちの希望もあり、焼肉バイキングの店へ。 うちの子ったら、すし屋も焼肉屋もあまり高い店には恐くて行けない小心者なのだ。 親の財布なのに。
で、食べるわ、食べるわ。 お腹いっぱいになった。 みんなも満足げ。...というか、ちょっと苦しそう。明らかに食べ過ぎ。
後で吐いたやつもいるし。もうバイキングには連れて行けないか。
なんかもう訪問もしないのに毎週毎週「松江」って書く意味ないよな。
ま、それはともかく、ごく普通の日曜日、だったような気がする。 日曜学校は旧約聖書。
集会終了後、予算執行でどたばたした。
夕食に宣教師たちが遊びに来た。メニューは中華料理。 アメリカ人とブラジル人の口に合うか。
たいへん楽しい時間を過ごしたが、 食事をしちゃうとほとんどが食べることで終わってしまうのはちょっと残念。 会話を楽しみたいときにはむしろ食事なしで、 お菓子とかとともに時間を過ごしたほうがよいのかもしれない。
お客さんが多い人には当たり前のことなのかもしれないけど、 うちを訪れてくれる人はあんまりいないので。
4844317210 『4844317210』14章「コンテキスト」によると、Rubyには実行時スタックが「なんと七本もある」のだそうだ。
そんなにあったっけ。
ふむ、確かに七つリストされてるな。実際にはprot_tagもあるので8つだ。
この辺がRubyの実行系が複雑だと揶揄されている根源でもあるのだが、 ふと思い立って、ruby_blockをなくしてみようとやってみた。
ブロックとは本質的には引数の一部なので、引数が格納されるframeに置いてやるのがよいだろう。 ruby_frameに「struct BLOCK *block;」というメンバを追加する。
また、引数の一部であることからrb_call()やrb_call0()にblockを示す引数を追加する。 ブロックが与えられているときにはblock構造体を、ないときには0を渡すことにする。
イテレータを実現するNODE_ITERやNODE_FORを修正して、 rb_callを呼び出すときにblock構造体を渡すようにする。
ruby_blockがなくなったので、ruby_blockが現時点で有効かどうかを示すフラグである ruby_iterは不要になる。同様の理由でruby_frameのiterメンバも不要になる。
あとはそれらに付随していろいろごちゃごちゃと修正を加えると、 あら不思議ruby_blockは無くなってしまいました。 ついでにruby_iterもなくなってスタックは6本に。
スタックが少なくなって、 なんだかちょっとインタプリタがすっきりした(でもコード重複は増えちゃったけど)。
今までが100とすれば、今は99くらいかな。
パフォーマンスについても期待したんだけど、全然変わらないみたい。 まだ、make test-allが通らないんでcheck inはもう少し待ってね。
次はruby_classとruby_cbaseの統合かな。
しかし、『4844317210』って 絶版になってるの? Amazonでユーズド商品の価格が25,975円になってるんだけど。 こんなプレミア価格ってアリなの?
4840230242を購入したついでに買ってしまう。
いや、精神集中に素数計算を遅延実行すると書いてあったのに惹かれた というのが本音かもしれない。
sieve(n:ns) = n:sieve[m<-ns, m`rem`n/=0]
ってコードはHaskellだよね。前にakrさんがこの本のことに触れていたような気がするな。
でも、プログラムが出てくるのはそこだけで、 後はまあコンピュータは単なる小道具くらいかな。 登場人物の一人(女子高生)が「CとPerlならわかるけど」と発言するくらいかな、 業界人として面白かったのは。
しかし、
という設定はなかなかよろしかった。のに、ちょっと消化不良な感が。
いや、業界人が喜ぶ話は、きっと一般人には面白くもなんともないんだろうから、 ラノベとしては成功しなさそう。
ところで、二巻『4086301849』も 眺めてみたのだが、レベルは同じ程度。素材はいいと思うんだけどなあ。
この巻のタイトルであるGCには思い入れがあるぶん、辛くなってしまう。 なんだよ、「マーカー」と「リファレンサー」が 「ガーベージコレクター」が回収しないように保護するってのは。 そこは「マーカー」が「スイーパー」から保護するって言わなくちゃ。 「マーク&スイープ」を採用してるんなら。
いや、人間の記憶のGCってどうなってんのかな、正直な話。 なんか参照されてても平気で回収されてるような気がするな。
ところで、現在Enumerable#selectなど一連のメソッドは Arrayを返しているわけだが、 これをEnumeratorを返すようにすると、一種の遅延実行が実現できるのではないだろうか。
イテレーションの中でしか実行できないので、 関数型言語における遅延実行のようなわけにはいかないけれども。
要素数が非常に多くなると効率に違いが出てくるかもしれない。 無限な要素([1..]とか)も扱えるようになる。
とりあえず、将来への布石として 1.upto(3)などをブロックなしで呼んだときにはEnumeratorを返すようにする。
うーん、あんまり布石になってないかな。
会社に顔を出すとペリカン便の箱が。
やっと帰ってきたよ、私のThinkpad。
ブートしてみる。いい感じで立ち上がる。 完全復帰。
しかし、この2週間の間のデータやら、 作業やらを移したり復旧させたりするのがそれなりに面倒だ。
一番面倒なのはmorq、もっと具体的にはRastのデータだなあ。 データベース壊しちゃったしなあ。
というわけで、Rast担当者と話をしてみる。
「ちょっと遅いんじゃない?」とか「ちょっとスケーラビリティに欠けるんじゃない?」とか。 身内なのに容赦ないな。いや、「ちょっと」が付いてるぶんだけ優しいのか。
が、彼自身は本業が忙しくて手が出せないらしい。 うーむ。会社としてはお金になる仕事が当然優先だしな。 しかたない。私が手を出すか。 あんまり得意じゃないんだけどな、スピードが要求されるプログラミングは。
しかし、いい話も聞いた。 http://www.j96.org/w3ml/rast-ja/msg/52に投稿されたパッチを使うと(機能制限は出るが)、ずいぶん高速化されるらしい。
今度試してみよう。しかし、自前でRastコンパイルできる環境があったかな。 まず環境整備から始めないと。
今度、情報処理学会の全国大会でこういう発表をします、という話。
5つの主要なオープンソース全文検索エンジン(Namazu, Lucene, Senna, Estraier, Hyper Estraier)について、登録文書数1万件−500万件の範囲での、インデクシング速度および検索速度を測定した結果と、そこから得られた知見を報告します。
だそうです。Rastは仲間に入れてもらえませんよ、ぐすん。
これもスケールしないからだろうか。今後に期待。
Goslingへのインタビュー。彼までRubyに言及してくれるとは。 これもRailsのおかげだろう。ありがたや。シカゴのほうに足を向けて寝られない。 だんだん足を向けられない方向が増えてくな。
しかし、RailをJRubyとつなげて答えるなどとんちんかんな印象を与える答えも多い。 また、ちょっとスクリプト言語を見下していたり、 「言語のパワー」を低く見ているような印象も受ける。
ところで、彼の
ただ1つ、スクリプト言語の作成者には、もっと変わったものを作ってほしいという願いを抱いています。
というメッセージを自分のものとして聞ける立場の人間はさほど多くないと思うのだが、 さいわいにも私はその一人だ。
正直、「あまり変わったものを作らない(少しだけ変わったものを作る)」ことこそが 言語の成功の秘訣だと考えているので、 「もっと変わったもの」についてはあまり積極的ではないのだが、 少し考えてみよう。
「変わったもの」...うーん、APLのリストとか。 RubyのArrayにアレを実現できる機能を用意すれば...。
うむ、一次元のものについては今でもinjectとか使えばでできちゃうのかな。
20日分のエントリは結構話題になったようで ありがたいことである。小飼さんのところでも 「オブジェクト指向は構造化の「次」か?」というテーマで反応していただいている。
彼は構造化とOOPは「直交する」と認識していらっしゃるようだ。
ま、理屈ではOOPだが構造化されてないプログラムは存在しえるので、 直交していると言えないことはないと思う。 が、それを言い出すと構造化プログラミングを構成する各要素も直交してるし。
要するに同じカテゴリに属する同じ性質のもので、 オブジェクト指向(プログラミング)の方が後から出てきた、程度の意味なんだけど。
まあ、それはある意味どうでも良いことなんだが、 小飼さんの文章を読んでいて、少し気がついたことがある。
実際smalltalkやhypertalk、そしてsqueakといったプログラミング環境では、オブジェクトはフィールドとかボタンとかといった、「もろに目に見える」「実存」であり、それ故まだものごとを抽象化して捉えることの出来ない子供でも始められるようになっている。
Smalltalk環境やHypercardにおいて、「オブジェクトを操作できる感」が提供されていることは 事実だが、それは「オブジェクト指向プログラミング」とは直接関係ない。 それはある意味「アプリケーションの機能」であって、 オブジェクト指向プログラミングによらないアプリケーションでも ユーザに「オブジェクト感」を提供できるだろう。
オブジェクト指向プログラミングを使った方が そのようなアプリケーションを作りやすいだろうけど、逆に言えばそれ以上ではない。
で、私よりも数学的思考法に強そうな小飼さんまで、 そのような「混同」をしてしまうというのは、 単にマーケティング用語として「オブジェクト指向」が使われた不幸だけでなく、 「オブジェクト」という単語が持つ「魔力」というのものは 私の想像以上に強いということなのかもしれない。
オブジェクト指向プログラミングにおけるオブジェクトという抽象化された存在と 目に見える(あるいは触れる)モノとの連結性を強く連想してしまうのが (普通の)人間というものか。
私にとってのオブジェクトは、現実に対応するものがあるにしても 抽象化された存在であるから、現実とどこまで対応しているかなんて 気にしたこともないのだけれども。 そんなの「三匹の猫」と「数字の3」が同じ性質を共有してないと 文句を言うのと同じくらい不毛な気がする。
あるいは、私がそう感じるのは、私が日常的に扱う「オブジェクト」は、 「文字列」とか「配列」とか「コンティニュエーション」とか 現実世界に対応するものが存在しないものばかりだからかもしれない。
遅延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とかを導入してみればよいのか。
ユーザインタフェースについては気に入らない点が二つ。
前者はコスト的に記憶系を一切持っていないだろうから、しかたないとしても、 後者は手抜き過ぎかな。
司会とお話の両方が当たる。
司会はもうだいぶ慣れた。問題はお話だ。テーマは「慈愛」、 つまり、神の愛あるいはアガペについてだな。
しかし、愛について語るのは私よりも結城浩さんの方が似合っていると思うのだが (私はどうしてもテレてしまう)、まあ、そういうわけにもいくまい。
で、子供っぽい「条件つきの愛」や「男女の愛」と対比して、 慈愛について考えてみた。うーん、言いたいことが伝わったかどうか。
うむ、できてない。 自分で実践しきれていないことについて語るは、なかなか難しいものだ。
聖書に「心をいれかえて幼な子のようにならなければ、天国にはいることはできない」、 とある(マタイ 18:3)。
ちょうど、身近に幼な子(1才3ヶ月)がいるので、イメージしてみた。
たくさんの、まん丸い頭をしたかわいい子が「にぱっ」と口を開けながら大笑いしている イメージが脳裏にひらめいた。そんな天国に行きたいものだ。
単なる親馬鹿である。
小飼さんも「オブジェクト指向プログラミングは構造がプログラミングの次」という点に 納得して下さったようだ。伝わってよかった。
「サブジェクト指向」なるどこかで聞いたタームが登場するのはまあご愛敬として。
しばしば耳にする「サブジェクト指向」は(「自己中すぎる」という小飼さんの指摘以外にも)、 メッセージセンドのフォーマットにこだわりすぎているような気がする。
たとえば、CLOSのマルチメソッドだったら「サブジェクト」は存在しないわけだが、 これが「オブジェクト指向ではない」というのはちょっと極端すぎるだろう。 あるいは、通常のメッセージセンド(or メソッド呼び出し)についても、 たしかにレシーバは特別な位置にあるが、それ以外の引数もやはりオブジェクトである点は 見逃してはいけないと思う。