Rubyist Hotlinks 【第 8 回】田中哲さんその2

初稿：2005-07-19

インタビュー(2/3)

[ 1

3 ]

インタビュー(2/3)

生い立ち

笹田　じゃぁ、生い立ちから。

田中　fj で育ったんですよ。

笹田　(笑) その前。その前。

田中　その前ですか。東京で生まれて、あるとき北陸に行こうと思い立って北陸に行きました。で、北陸に6年ほど籠って、次はつくばですね。

笹田　(笑) もうちょっと細かく。小学校とか中学校とか。何をどうしたらこうなっちゃったのかな、と。

田中　こうなっちゃた。

笹田　スポーツとかは？

田中　スポーツは今も昔もしません。

笹田　本とか読んでる少年？

田中　読みますね。コンピュータに最初に触れたのはたしか小学校4年生くらいで、VIC-1001 っていう8ビットの Commodore のマシンだったかな。でも、よくわかんなくて結局たいしたことやってない。別にプログラムもしなかったし。

笹田　ゲームとかはなかった？

田中　カセットテープで売ってるのがあって、いくつか買ってやったような気がしますが、まぁたいしてやらなかったですね。ただ、CG に凄く興味を持ったように思いますね。とはいえ自分でやるわけではなく、ああなんかやりたいなぁ、と思って。

で、もうちょっと後になると、FM77¹。しばらく BASIC を触って。グラフィックスに興味を持っていたのでレイトレーシングを書こうと決心して。書いた覚えがあります。

笹田　え、それは何時ごろ？

田中　中学校か高校のころだと思いますが。

笹田　BASIC で？

田中　BASIC で。

ただ、レイトレーシングでは反射と屈折を再帰的にたどらないといけないんですが、BASIC は再帰が困難という問題がありました。まぁ GOSUB はあるんで再帰自体は出来るんですが。でも、ふつうの BASIC はローカル変数がないのでそれをどうしたらいいかというのが問題でした。どうしたかっていうと、すべての変数を配列にして、再帰のレベルでアクセスするわけです。

笹田　自分でスタックを作る。

田中　そう。今風に言えば、っていうほど今風ではない気がしますが、変数毎にスタックがあるような感じで shallow binding² っていうところですかね。いや違うかな？まあともかく、そういうのを書いた。

で、苦労したのは、for 文が書けないってところですね。インデックスに配列の変数が使えないんですね。使えてもいいと思うんだけど。だから、while 文で全部書き直しました。そのときは while って素晴らしいと思いました。

BASIC で他にまともなプログラムを書いたのかどうかはちょっと覚えてません。

その後、何かの拍子に OS-9³ がやってきて。6809 用に書かれた OS です。マイクロウェア⁴ の。それが 8 bit で動くくせにマルチタスクでさ、UNIX っぽい。その上に Basic09 というのがあって。これは Basic という名前なんだけどずっとまともな言語で。その上でもレイトレーシングとか書いた気がします。ローカル変数とか procedure に感動したような覚えがありますね。

で、このころにはアセンブラでソートプログラムを書いた気がしますね。

笹田　高校時代？

田中　多分そのころ。そのときにアセンブラ覚えて、俺が覚えた唯一のアセンブラが 6809。他のアセンブラは真面目に勉強したことがない。いまひとつ x86、Pentium のレジスタ構成は、とかきかれてもぴんとこない。

で、そのときにソートコマンド相当のものを書いて、ダブルリンクトリストを使って結構でかいプログラムになった。

笹田　なんでそんなの作ったんですか。

田中　ソートコマンドが無かったから。

笹田　そのころ何してたんですか。

田中　レイトレーシング書いてたのはたしかそれで。他にはレポートの計算をしてましたね。

高校は工業高校で、実験の結果とかいろいろと計算しないといけない。そのための計算をしていました。電子科だったんですが、複素数が必要なんですね。で、複素数を計算するのが凄く面倒だったんですね。なんでかというと、Basic09 にはオペレータオーバーローディング⁵がないから。全部関数で書かないといけない。これは非常に痛い。この憤りは、随分と後になるまで解決されないんですけど。

そうこうしているうちに、次は Sony の NEWS⁶ を使うようになった。

で、ここで UNIX になって、Perl を覚えたんですね。

最初は結構長い間 sh と awk で生活してました。そのころはネットワークコネクションがなくて Perl を取ってくるのが困難だったから。

何をやってたかな。何のためだったか覚えてないんだけど、shell スクリプトを生成する awk スクリプトを生成する awk スクリプトを使う shell スクリプトを書いた覚えがあります。

笹田　(笑)

田中　なんでかというと、NEWS に載っている awk は old awk というやつで、正規表現がパターンのところにしか書けないんです。で、要求としては configuration file に正規表現を書きたかった。でも、configuration file に書いてある正規表現を動かすには awk に変換しないといけない。だから configuration file から awk スクリプトを生成するわけです。そして、そのスクリプトは、目的がファイルを弄ることだったんだけど、old awk はファイルを弄れないんですね。awk はフィルタだから。そうすると shell スクリプトを生成して sh -s につなぐ、という話になる。というわけで、awk スクリプトで configuration file から awk スクリプトを生成して、その awk スクリプトが生成するのは shell スクリプト、その shell スクリプトはパイプでシェルに渡されて実作業をする。今から考えると非常に信じがたい苦労をしたわけですね。

笹田　そんな高校時代だったんですか。

田中　それは大学だったかな。

笹田　小学校から、どんな興味の変遷があったんですかね。

田中　基本的にグラフィックに興味を持ってました。

笹田　子供のころだとゲームを作りたい、とかが多いような気がするんですが。

田中　もっとプリミティブに 3D グラフィックですかね。ワイヤーフレーム出したいとか。Pixel という雑誌があって、買っていたりしました。Oh! FM とかにレイトレーシングの記事があって、大事に何度も読んでた。

笹田　中学校のころとかも？

田中　コンピュータに関して、自分はかなり贅沢というか。リソースが十分にないと作業をしない、というのがあって。その結果、速いマシンが使えるまではたいしたことはやってなかった気がします。最初のマシンでは何もやんなかったし、77でもたいしたことはやらなかった気がする。77で覚えてるのは OS-9 上の C コンパイラがあって、すっげぇコンパイル時間がかかって即座に捨ててしまった。

笹田　中学校の部活とかは？

田中　よく覚えてません。ライトノベルを読むようになったのはそのころだった気がしますが。

笹田　本は好きだった？

田中　ライトノベルを読むようになって、いまだに読み続けてるわけですが、あんまり広い範囲は読んでません。まぁ、漫画も読みますが。

笹田　工業高校に行ったのはその分野が好きだった？

田中　あんまり気にしたことがなかった。親の影響だったかな。そのおかげで色々と知ってるわけですが。

笹田　北陸に行ったのは？

田中　その前の大学時代の思い出は、私は江渡さんと違って普通の学生でした。真面目に授業に出ていた学生を普通の学生というかは微妙ですが。コンピュータ関係で感動したことで覚えているのは、コンピュータの授業じゃなくて、電磁気の授業で、マックスウェルの方程式があって、これを差分的に変えると、どれかの式が、たとえばある点の電位が4近傍の平均になる、という式になるんですよ。そうしちゃうと誤差が入っちゃうじゃないか、とか疑わしく思いながら授業を聞いてたわけですけど。それからいきなり表計算ソフトが出てきて、すべてのセルに4近傍の平均である、という式を放り込むんです。それで再計算を繰り返していくと、出るわけです、電位分布が。おー、と思って。これは感動した覚えがあります。

笹田　大学は情報系？

田中　電子工学科。弱電。電気の話とか、フーリエ変換とか、回路とか。情報に行ったのは大学院で。結局その大学院に行ったのが情報系に行くんだという決心ですかね。なんとなくそういうふうにしようと、大学3年生のときに思い立ってJAISTに飛び級で行きました。

笹田　決心ってのは？

田中　ただ単にソフトウェアをやりたいってことですかね。それ以上の理由はなかったと思います。それは今のところあってる。

笹田　電子系の卒論とか書いた？

田中　それは書かなかった。一応3年の終わりに研究室を選ばないといけなくて、その研究室が4年になる前に軽いゼミをやって、日本語の本を一冊二冊読んだ覚えがあります。そこは信号処理やってました。

大学時代だと、他には計算機センターの補助員のバイトをしていて、計算機のお守りをしていました。その時代から、fj に参加した。それからは fj に少し記事を書いていたりしました。

笹田　で、fj で育っていったと。

田中　そうね。そのころの思い出は何かな。授業で UNIX を使うというのがあって、はじめての授業でみんなでサーバにログインする、と。そのときにある人数以上ログインできない、というトラブルがあって、そのときに居合わせて問題を同定したという思い出があります。ありがちな話なんだけど、pty が足りなかった。クラス全員分の pty はなかったわけです。それを作るには MAKEDEV という shell スクリプトを実行しなければいけなくて、それをどうやって呼び出すかというのが問題になった。MAKEDEV の中は非常に難しいコードが書いてあるんですね。16進の計算を shell スクリプトで無理やりやってるので、tr とかを使った非常に難解なコードになっていて、そこに苦労して読んだ覚えがありますね。まぁそれは解決して。思い出はそれくらいかなぁ。

JAIST 時代

田中　で、JAIST に行って、まあ JAIST っていう大学院は教育に力を入れているということになっています。つまり、遊んでると卒業できないわけです。ドクター (博士後期課程) だとまあともかく、マスター (修士課程) はようするに、学部とおんなじ様なスケジュールで、毎日毎日授業があると。だから、やっぱり真面目に授業を受けて、それなりに単位を取って、で研究室に行って、まあ研究をして、fj に関わりつつ、マスターを出たと。

笹田　修論とかっていうのは。

田中　拡張可能ななんとかってやつ⁷ですね。

笹田　渡部先生⁸のところに、すぐ行ったんですか、配属。

田中　俺の頃は一年生の終わりくらいに配属でした。たしかもうちょっと早めようかという話がありましたが、今は早まったのかどうかは知りません。まあでもその頃に行って。

笹田　聞いてる感じだと fj とかってなんかシステムよりのことに興味があるのかなあと思ってたら、理論的な話ですよね。

田中　なんで？

笹田　え、渡部先生そうじゃないの？

田中　あのひとは両方やるんですけど。

笹田　そうなんですか。

田中　理論のこともやるし実装もやるし。両方やる人ですけど。

笹田　そこを選んだ理由は何なんですかね。

田中　選択肢として何がよかったか、何があったかですかね。ああそうか、そもそも、グラフィックスに興味を持っていたのに、なぜいつの間にか言語になったのかっていう話をしませんでしたね。

それはですね、グラフィックスの記述言語に興味を持った。3D のモデルを書かないといけないじゃないですか。まあ書こうと思ったわけです。でも 3D ってよくわかんないし、だから二次元のやつを探したんですね。でそのときにめぐり合ったのが何だったかっていうと、PostScript だったんです。PostScript はまあ二次元の絵を書く言語で、でまあ要するに Forth なんだけど、スタック型言語で、でそれあたりからですかね。言語のほうにずれていったのは。

笹田　それはいつごろですか。

田中　これはいつだろう。多分高校だと思いますが。

笹田　高校で PostScript ですか。

田中　うん。べつに PostScript 書ける人そんなに珍しくなかったですけど。少なくとも JAIST の研究室では何人もいたし ⁹

笹田　まあ高校生ではあまりいなかったんじゃないですか。いました？周りに。

田中　わかんない。

だからそのころに、Ghostscript のかなり低い version のやつを持ってきて試したりとかやってましたね。

笹田　高校時代。

田中　これは高校だったと思います。あるいはもしかしたら大学に入ってからかもしれない。

笹田　だからあとで日本語化の話を。

田中　いや日本語化は、もちろん GS に興味を持っていたっていうのは事実なんですが、私自身は開発はしてなくて、っていうか GS の日本語化もしくはその類の話は何人かがやっていて、GS version 2 の頃に NACSIS の片山さん¹⁰っていう方がけっこうやっていた。で、ところが maintenance が途切れてしまって、それをもうちょっと新しい version に適用できるようにしたっていうのが私ですね。あとは、なんかあのへんは錯綜してて、VFlib を使うための patch がなんか別にあったりして、そういうのをまとめたっていうか取捨選択して、自分が欲しいところだけを取り出して patch をまとめたっていうのをしばらくやっていた。逆に言えば GS のバージョンが上がらない限りは何もしなくて、まあちょっとはコード書いたんですけど、まあたいしたことはやらなかったですね。

まあそのときの苦労もあってですね、日本語化はいろいろ虚しいことが多くて。虚しいというか苦労が多くて、あまりやりたくないなあと思ってます。あとは本家に feedback することが重要だってことですか。local でやってると手間ばっかかかってしょうがない。本家に放り込んでしまうのが最終的には一番幸せ。

笹田　えと、言語の話から飛んだんですけど、じゃあ大学はいる頃からもう言語とかじゅうぶん興味があった、と。

田中　あった

笹田　でまあ JAIST のほうに。言語がやりたくて行った？

田中　そのころはそこまで明確ではなかったと思いますね。ソフトウェアの講座で、JAIST も別にソフトウェアばっかじゃなくて、理論とかアルゴリズムとかもありますし、音声認識とかそっちのほうもありますし、まあもちろんソフトウェアもあります。でそういう中ではソフトウェアがが前提なのは確かでしたけど。その中でどれをっていうのは、いろんな可能性はあったと思います。たとえば渡部先生のほかの可能性としては二木先生¹¹とかあるいは中島先生¹²であったり篠田先生¹³であったり、いろいろいましたけど。

笹田　わからないですすいません。

田中　えっと、二木先生って分かります？

笹田　すみません、わかりません。

田中　‘オブジェクト指向入門’って本知ってますか。Meyer の。あれの監訳なんですけど。さらにいえば電総研の OB で。あと二木渡部研の大講座制だったんでゼミとかやりましたけど。

他には中島先生は今早稲田ですけど。あと篠田先生って有名じゃありません？

笹田　へー。

田中　あるいは片山先生¹⁴、落水先生¹⁵、たとえば落水先生は ‘UNIX C SHELLフィールドガイド’ って本知ってます？あの本の訳者だったかなんだったか。なんとかの本といえば篠田先生が、Stevens の本がありますよね、ネットワーク系のやつが何冊か。‘UNIX Network Programming vol. 1’, ‘2’ とか。あれの訳者だったり。

笹田　ネットワーク技術やってる田中さんって想像できませんね。

田中　そう？ネットワークはそこそこやっている気がしますが。今でもたとえば UDP が云々とかやってますよね。

笹田　まあたしかに。なるほどね。

田中　ネットワークプログラミングは、今でもします。あるいは、五月雨だってネットワークプログラムですよね。べつにそんなにやらないっていう話じゃないですね。kernel 内を弄ったりはしませんが。

笹田　そんなんで、再構成可能な何とか。

田中　拡張可能な何とかっていうのをいろいろ、拡張可能な言語であったりシステムであったり。まあアーキテクチャを。そういうお題目で研究してました。

笹田　修論でそれやって、ドクターでも。

田中　笹田さんのようなものとは違って¹⁶、何も外に出てなくて何の役にも立ってないんで。

笹田　PRO¹⁷ かなんかに出てませんでした？どっかで論文見ましたよ。

田中　出したけど落ちたんじゃなかったかな。

笹田　研究会報告、ああないのか PRO は。

田中　うむ。PRO は確か一回出したけど落ちた。

笹田　PDF でどっかでみたのかな。

田中　まあ多分どっかに落ちてた気はします。あとなんかの研究会には出した覚えがあります。でも結局、世の中へのインパクトはないんで。

笹田　パッチとかバグレポートとかやってた時期はドクターの頃？

田中　ドクターですね。ドクターも確かかなり後のほうな気がしますが (笑)

笹田　研究もやらずにそんなことばかりやってたというふうに、口悪くいうと。

田中　そうです。よく言えば就職活動してたというか。その頃はそんな可能性があるとは夢にも思いませんでしたが。

笹田　まあ好きにソフトウェア書いてたってことですかね。

田中　ですかね。といってもソフトウェアねえ。

笹田　マスターの頃とかってずっと勉強ばっかりで書いてなかったんですか。

田中　いやそんなことはないと思いますよ、プログラミングをやめるほどの根性はないから。でも、外に出てきてるものってない気がしますね。

笹田　たとえばマスターの頃って何やってたんですか。

田中　ちょっと覚えがないなあ。記憶が。まあでもいろんなものをインストールして試すとか、そういう普通の、普通かどうか知りませんが。

笹田　なるほど。

田中　まあ周りの人に影響されるたちもあるので、守岡さんや小林君に影響されてメール関係を考えてみたり。そんでもって RFC を読んでみたり。

笹田　そのころにどんどん知識を付けていったと。

田中　ですかねえ。まあ RFC を読むっていうのはいろいろ、fj で議論するためにも重要なんですけど。

笹田　なるほど。

実は RFC1468 にはバグがある

田中　RFC1468 は、ああ結局、改定されなかったなぁ。

笹田　1468 って何？

田中　ISO-2022-JP。あれにはバグがあってですね、空行が書けないんですけど、それを見つけて。正確にはエスケープシーケンスがない行を書けないんだったかな。

fj で、end 行の問題があったときに、って言ってもわかんないか。end っていうだけの行があると、たしか Outlook Express でその記事が読めないという問題があったんです。でこれはなんでかっていうと、end っていうのは uuencode の終わりで、それを detect してなんか変に動くが故にですね、記事が読めないという。でまあその頃に、それは Outlook Express が悪いのか、あるいはそれを書く人が悪いのかという議論が盛り上がってですね。その議論自体には関わってなかったんだけど、それと同時期に、end 行っていうのは RFC1468 を字面通りに解釈すると invalid なんですよ。正しくない。だから書いてる人が悪い。Outlook Express は悪くない。という、論陣を張るというほどではなかったんだけど、その可能性を指摘して、RFC1468 について、BNF とは何かというところから議論した覚えがありますね。

他には MIME がどうこうとか。encoded word の話はずいぶんやりましたね。encoded word はすごく難しいので。まあでもそういう難しいことはあんまり意味がないんで、机上の空論に非常に近く……ああそうだ。だから encoded word については、それの正しい decoder を作りましたね。規格的に正しいところに出てきた encoded word だけを decode するという。この結果が何かっていうと、普通の人が encoded word だと思うところがかなり decode されないんだけど、そういう不幸な、でも正しい decoder っていうものを作ってみました。

笹田　なるほど。あれはバグだよと指摘。

田中　バグ。何のバグなんですかね。

笹田　仕様。っていう話じゃないの？

田中　いやこれがまあ、いろいろ選択可能にしたんで。なんでもかんでも decode すればいいので、まあそんなに難しくはないっていうか、それで誰かを非難するっていうことはなかったかな。

笹田　まあなんか、そんな大学院生活だったと。

田中　うむ。

使いやすさについて (2)

笹田　言語処理系の興味としては、言語処理系じゃないですね、言語としての興味としてはどんな感じだったんですか。

田中　PostScript をはじめとして、いろんな言語を調べたりして、で、渡部先生の、っていうか研究室も言語設計学講座ってやつで、まあ言語の講座で。でそこでしばらく Scheme を使って、拡張可能ななんとか。拡張可能な言語とかをやってました。

笹田　なるほど。

田中　まあでも、自作の言語を作るまでには至らず今に至ってますが。

笹田　つくろうとはしてた？

田中　いやあんまり。拡張可能っていうほうに行ってしまったから。なんかベースがあって、何か追加すれば何でもできますというアーキテクチャなわけです、拡張可能システムっていうのは。でもまあ、これはちょっと反省点でもあるんですけど、実際使えるところまではだいたいたどり着かないんですね。それに、簡単なものを作るだけで済ましてしまうし。なので使えるところまで行かなかったんで、言語設計っていえるようなものを結局は経験しませんでした。

笹田　反省点っていうのはやっぱり使えるものを作ってなんぼだよなっていう話？

田中　いやまあ、んー、これは Ruby に関わって考えたことなんですけど、「拡張すればできます」ではまだダメで。原理的にはできるはずだではダメで、ちゃんと使えて、使いやすくなければならないという。で、そのためにはちゃんとやんなきゃね、っていう。まあそれだけの話なんですが。

さらには、もうちょっと強い考えとしては、拡張可能システムっていうのはもしかしたら、よいものを作るためには邪魔かもしれないという疑問もあります。これはなぜかっていうとフィードバックが得られにくいという可能性があるためです。つまり拡張可能だと、いろんな人が個人でどうにかしちゃって作者のところに要求が来ないので「みんなで共通して使うためには、どういうものがよいものか」っていうのを作者が知る機会が減ってしまう。

笹田　え、じゃあ Scheme はダメなの？

田中　そういう意味ではそうかもしれない。つまり低レベルな、特に SRFI とかが出る前の Scheme は非常に primitive で。

笹田　みんながみんな自分のものを作っていた、と。

田中　毎回みんな苦労する。でもそうじゃなくて、もっと使えるものを最初から付けとけという。まあだから Scheme の人に喧嘩売ってるような感じですが (笑) 拡張可能なだけではダメかなと。

笹田　ちなみに拡張可能なシステムっていうのは、その研究自体は、既存の言語に対して何かする、という話だったのか、それとも？

田中　私がやったのはもっと、こんなふうなアーキテクチャにしたらいいんじゃないですかっていう感じです。特に reflection と絡んでいたので、meta-level アーキテクチャとか、そういうのをもうちょっと具体的に、言語に適用してこういう風にしたらいいんじゃないでしょうか、まあそういう話だけどまあ、あんまり聞かないでください (笑)

笹田　黒歴史？

田中　まあ、それに近いかな。

笹田　ええとじゃあ大学はそんな感じで。修了されたという。

田中　そうね

Mule にバグ報告をしていた頃からすでに田中さんは報告するだけで fix しない今のパターンを築いていた

田中　まあなんとか出させていただいて、でまあ、その次が産総研ですね。ああだからそうか、なぜ産総研に来れたのかという問題はありますね。まあこの件に関してはインターネット上の活動が原因になってまして。

Mule というソフトウェアがあるんですが、どういう順番だったのかはちょっと覚えてないんですが、Emacs 関係の話をやっている守岡さん¹⁸と小林君¹⁹という人と、よくつるむようになった。でまあいろいろ議論したり、さっき話²⁰に出てきた CHISE の原型になる話を議論したり、まあ俺はあんまりたいしたことやってないんですけど。で Emacs 本体にも絡むことがありました。Emacs っていうか Mule 部分に、少し顔を出すようになってきた。

で、そのときに、たしか Emacs の、たしか 20.3 に対して、バグの鉱脈を見つけたんですね。鉱脈って言うかな、まあ Ruby にもあるんですけど様々なバグが発生するようなアーキテクチャといいますか、そういうものがある、っていうことを発見して、で大量にバグレポートを送ったんだよね。でこれは Mule のバグなんで、送り先は mule-ml ってやつで、これはどこでやってるかっていうとつまり戸村さん²¹、つまり、産総研でやってるわけですね。

笹田　もう産総研になってた？

田中　電総研だったかもしれない。ああ電総研だったと思います。で、電総研でやっていて、そこに大量にバグレポートを送ったと。で半田さん²²に fix してもらいつつ、半田さんが fix すると次のバグを送るということをしばらくやって、まあその頃からつまり、私自身は fix をしないという話だったのですが、大量のバグレポートを送っていたら向こうからお誘いが来て、でとりあえずは非常勤職員としてしばらくいました。でもうちょっと経って、機会があったときに滑り込んだと。

そのときのバグは byte combination ってやつで、これは Emacs が落ちる類のバグなんですけど、これの経緯に関して話すと、Emacs の 20.2 まではですね、buffer っていうのは byte の並びだったんですよ、だから、1byte 目、2byte 目、3byte 目……ってあったんですけど、あるとき Stallman がこれを一文字単位に変えたんですね。一文字っていうのは Mule には internal encoding っていう state-less な encoding があって、それでの一文字なんですが、にもかかわらず buffer は任意の文字列を保持できるというふうにしたんです。

つまり internal encoding としては invalid なものも buffer に放り込める。放り込める挙句にそれを無理やり文字っぽい単位で判断して動く、という非常に不明瞭な、つまり文字としてあんまり正しく解釈できないものを無理やりなんとなく文字っぽいものとして無理やり解釈した上でその操作を行うというアーキテクチャなんです。で、それを扱う側のコードはちゃんと文字になってる場合しか考えていないことがあって、そういうコードにちゃんとした文字じゃないものを扱わせようとすると非常にへんなことが起こる。でそこを突くと、まあ落ちるわけですね。たとえば文字数と byte 数の対応がなんかずれると、buffer の後ろのほうが壊れたり、まあ非常にひどいことが起きて。

これが、そういう性質をすべての primitive に対して全部完全にやらないと落ちないようにならないという不幸な、不幸なんだけど Stallman がやったからしょうがなくって。でこれが安定化するまでにどんぐらいかかったのかなぁ。半年だったか一年だったか。

笹田　でもそんなんで収束したんですね。

田中　いやまあ、あの連中は (笑) なんとかするんですよ。Emacs はすごいですよね。腕利きがそろっていて。

笹田　やっぱりそうなんですか。

田中　守岡さんに言わせるにと、Emacs は腕利きがたくさんいてやってる。XEmacs は凡人がまとまってやってる。って言ってました。俺が表現すれば Emacs は要するに奇跡が連続して起きているような、そういう開発体制みたいに感じます。

笹田　へー。

さっき ISO-2022-JP が云々って話をしておられましたが、それはそのまま Mule でバグレポートする話に繋がっていくんですか。

田中　前提知識としてはありますけど。

笹田　興味として？

田中　まあ文字コードの話とか知ってるとまあいろいろと、便利というんですかね、いろいろなところを突くのに必要だったりしますが。たとえば ISO-2022-JP の構造を知っているから見つけられたバグとかもあるにはありましたけど、そういうのは少なかったですね。

笹田　なるほど。興味としては別に多言語化がどうのという話では。

田中　それはないですね。ないっていうかまあ、あんまり気にしない。まあもちろんハートマークを使っていたあたりには、名残はあったわけですが。

笹田　なんですかハートマークって？

田中　あー。ハートマークって言うのは JIS X 0208、普通に使ってる日本語の漢字コードには入っていない文字なんです。でもまあ、使いたいわけですよ。で、その代わり何が使えるかって言うと、韓国の文字コードがあって、そこには入っている。

で、ISO-2022-JP-2 ってやつがあって、そこでは韓国のと日本語のとあとなんだっけ、中国のとギリシャ語と、まあそういうのを使えるやつがあって、まあだいたい ISO-2022-JP と同じなんで、JP-2 をちゃんとサポートしてなくても日本語の部分はだいたい読めることが多いので、ハートをちょっと埋め込んでおくには便利というか使えるんです。で fj とかでも、ハートが読めてるかどうかは知りませんが、JP-2 で書いても日本語の部分は伝わるので、ハートを書いてもそんなにトラブルにはなんないわけですね。少なくとも私が使っていることに関して文句をいう人はあまりいなかったので、ハートをそれで使ったり。

っていうか、signature は、あれは全部ハートが入ってるんですけど。

笹田　「ふえろ! わかめちゃん作戦です$(C⊇」とか？

田中　そう。あの引用の$(C⊇は全部ハートが入っていて。

笹田　へー。

田中　だからそういうものを選んであるわけですけど。まあそれも、いつしかやめてしまいましたが。

笹田　ハートっていうと Macintosh の Shift-JIS 体系にはハートがあったとか。

田中　まああってもおかしくはないけど。

笹田　私はその話しか知らなくて。

田中　今 0213 にはハートは入ってますね。

笹田　0213?

田中　新しい漢字コード²³。日本のやつ。あでも、0213 使えるのかな。

笹田　これから使えるようになっていくんですか。

田中　さぁ？それはどうなんでしょう。よくわかりません。

笹田　なんか私の家族がね、なんで音符は使えるのにハートは使えないんだ、って。

田中　うーん。どうなんでしょう。いや Unicode に入ってるから、まあべつに。

笹田　普通 Windows では出せないから。ハートって。変換して。

産総研

CVS ネタの未踏でやったこと

笹田　で、産総研にめでたく。あっと、電総研でしたね。

田中　うむ。まあ。

笹田　で、非常勤で入られて。未踏で CVS やったのは。

田中　それはもうちょっと後、ああ、すぐかな。まあ一年目か二年目のときですね。今の cvs.m17n.org っていうのは、もともと JAIST 時代に守岡さんが始めた chamonix.jaist.ac.jp ってやつで、これはようするに守岡さんが使うため、もしくは他の人と共同して開発されるために運用していたものです。で、守岡さんはその後、これまた戸村さんに誘われてしばらく電総研にいたわけです。その後京大に行ったんですけど。で電総研時代に、cvs.m17n.org っていうのを電総研ではじめて、それを引き継いでメンテナンスしているのが私。という状況です。引き継いでっていっても中身はほとんど完全に作り直したんだけど、そのときの経験がすごい大変だったので、もうちょっと普通の人にもできるようにしようよ、っていう題目で、未踏をちょっとやってみた。

笹田　なるほど。

田中　まあお題目はいいんですが、まああんまりうまくまとまらなくて、唯一うまくできたと思ってるのは commit のたびにメール送るシステムですかね。個人的にはあれはうまくできたと思ってます。

笹田　あれってそんなに難しいことですか。

田中　それは条件によるわけですけど。chroot(2) して、内部に Ruby とかのインタプリタがなくて、という状況だと難しい。

笹田　chroot?

田中　あーだから、CVS って信用できないわけですよ。信用できないことがはじめっから分かってるから、なんか他の変なプログラムを実行されては困る。だから、変なプログラムは、とくに Ruby みたいな何でもできるプログラムは置きたくない。だから Ruby スクリプトでやるのはちょっとまずいわけです。かといって C で書くのはきつい。じゃあ何で書くかというところで迷うわけですが。つまり、native code が生成可能な言語処理系で、かつまあ比較的まともな、まともなっていうか、たとえば buffer overflow とかが起こらない、という条件が必要で、結局 ocaml を選んでそれで書いた。

笹田　へー。

田中　まあ、これはいまだに動いているし、個人的にはうまく書けたと思ってるんですが、まあでもあんまり万人向けというところまではいかなくて。

笹田　ようするに CVS で開発したい人のためのっていう、ノウハウ集、っていうお題目だったんですよね。

田中　もうちょっと広くて、たとえばそれを make install でできればいいなあと思ったんですが、まあそこまで行かなかった。

笹田　CVS に限った話ではない？　そうでもない？

田中　いやこの件は結構 CVS に依存した話で。たとえばそういう CVS から呼び出す chroot の中で動けるプログラムとか、あるいは CVS にちょっと patch を当てて、変更して何かやるとか。そういうやつですね。だからまあ、これは CVS そのものの話でした。ただあんまりうまくはいかなくて、そのメールを送るところ以外はほっぽってあります。すいません。

笹田　未踏のはそんな感じ、と。

プログラミング言語 MixJuice

笹田　であわせて MixJuice。

田中　しばらく MixJuice の周辺作業をやってましたね。あれでいちばんでかかったのは、MixJuice 版デザインパターンっていうやつです。MixJuice の処理系には手を出さないで、ユーザーとしての話ですが。まあデザインパターンっていうのは、要するに書くのが面倒な、あるいは思いつき難い書き方なわけで、それを MixJuice でやるともっと簡単に、あんな難しいことをせずに同等な効果が得られるっていう話を GoF²⁴ の 23 種類についてやってみたというものです。あれはどうなのかなあ、特に反響は聞いたことがありませんが。

笹田　その研究自体はどうだったんですか。どうだったというか、田中さん的な評価は

田中　あれは自分としては結構うまくいったとおもってますよ。予想されていたけれども、実際にどういう風に MixJuice みたいな機構を、まあ今流に言えば AOP 機構をどうやって利用するかっていう形を示せたと思っています。

笹田　研究の主題は、実装をどのようにするか？　言語デザインの研究？

田中　あの話では、既存の MixJuice っていうのを前提にしたから、「こういう機構があればもっと簡単に書けるのに」っていう話はないですね。「MixJuice みたいなのがあればこのぐらい簡単にかけます」っていう話をしました。

笹田　田中さんの仕事はそうなんだけど、その MixJuice というもの自体。

田中　MixJuice というもの自体？　それはどうなんでしょうね。それはなんか先行きはあんまりなさそうですけど。数多くの様々な言語と同様。

笹田　田中さんみたいなそういう人から見てどうだったのかっていうのが気になるんですが。

田中　なにが。

笹田　なんだろうな、田中さんの興味というか。

田中　MixJuice そのものはいいと思いますよ。いいっていうか、言語処理系というよりは、メソッドのスコープの話は非常に興味深い。だからまつもとさんが selector namespace がわかんないとか言ってるけども、MixJuice 流の考え方でよければ実現例があるんだからいいじゃんとか思っています。

笹田　Ruby で実装できるもの？

田中　もし selector namespace をああいう機構だとすれば理解するのはそんなに難しくないと思ってますが。単に、class とは直交して namespace があって、メソッドは namespace に属して定義されて、定義の属する namespace を参照している namespace の中でだけ呼べるというだけの話ですが。で、同名のメソッドがあっても定義している namespace のひとつだけを参照している限りは問題なく (参照しているほうを) 呼べる。複数参照している場合はあいまいなので、呼ぶにはどれかを指定しないといけない。

笹田　そんな話なんですか。

田中　まあ基本的にはそうですね。

笹田　いや selector namespace ってやりたいことっていうのは

田中　ああ、たとえば jcode.rb は嫌だよねっていう話があります。これは、jcode を使いたくないのに、誰かが require したとたんに、問答無用で jcode のメソッドが使われてしまうことですよね。でも、selector namespace があれば、jcode を使ってるところでは jcode のメソッドを使って、使ってないところでは元のが呼び出せるからとくに問題ない。

笹田　それをどう切り分けるかっていう言語デザインとそれをどう実装すればいいかっていう話か。

田中　そうですね。まあ仕様のほうはそれに関して言えば MixJuice ではできていたので、別に仕様の定義はいいんじゃないのと個人的には思うわけですが。でも selector namespace に関してまつもとさんが毎回毎回わかんないわかんないって言うので、まあいつまでたってもわかんないんじゃないでしょうか。

笹田　いってあげればいいじゃないですか MixJuice 読めって。

田中　それは向こうも知っているのです。

笹田　知ってる上でわかんない。

田中　知ってるっていうか、「MixJuice を調べればいいんだけど」とか言ってるの。

笹田　調べてないんですか。

田中　さあ知りませんが。想定されているのは MixJuice みたいなものではないのかもしれない。まつもとさんが考えてるものが。それは俺にはわかんないんだけど。

笹田　なるほど

使いやすさについて (3)

笹田　田中さんがよくおっしゃってるのは、さっきの話にもありましたけど、ライブラリに関するインターフェースっていう話はよく言いますよね。

田中　言いますね。

笹田　いやまあ (笑) それは自分の興味というかそういう話を聞きたいな、と。

田中　自分の興味というか。

笹田　田中さんの研究のテーマはそういうことなのかなぁ、と。

田中　まあ少なくとも論文にまとめているかといわれればまとめていない。興味を持っているのはそうなので、いつか書ければとは思うけれども、今のところは遠い話かな。それにそもそもどうやったら論文にまとまる話なのか良く分からない。

笹田　そういうのに興味を持った発端とか。Ruby を見て？

田中　うん。だから Ruby に非常に大きな影響を受けてますね。その件に関しては。

笹田　Ruby のライブラリかいてみようとしたらとか？

田中　なんでしょうね。以前はできるかできないかしか意味がないと思っていんです。ちょっとオーバーないいかたですが、可能だったら後はどうでもいいという感じで。アカデミックにはできるかできないかのみが重要な事も多いので、そっちに偏っていたわけですね。でも、そうじゃなくて、できるという中にも簡単にできるとの大変なのとすごい苦労するのとあって、そこを気にしないといけない、ということを明確に気にするようになったんです。これは Ruby の影響ですね。

で、自分が影響されたんだけど、まああんまり影響されてないような人も見受けられるというのも事実で、繰り返し言いたくなる原因なわけですけど。

笹田　じゃあ研究自体はそういう話じゃないのか。

いや、産総研でどういう立ち位置なのかな、とか。

田中　産総研における立ち位置ってなんか、まあ、なんとなく立ってる

笹田　(笑)

江渡　採用の時にはなんていって採用されたんですか。

田中　非常勤としての採用の時にはないんですよ、何にも。予算さえあれば採れたんです。今年からはちょっと何か公募を通さないと取れないんですが。

で採用、常勤になるときには、拡張可能システム云々ってやりましたよ。

笹田　D 論の？

田中　まあ D 論と、二年間一杉さんと一緒にいたから、まあそのときのことも含めて一杉さんにいろいろと指導してもらってですね。

言語の進化はいかにして加速されるべきか

田中　ようするに、言語の進化って凄い遅いと。現在主流な言語を Java とすると、その前は C で、さらにその前は Fortran とかなわけです。それぞれ 10 年あるいは 20 年の時間ですよね、一世代。それは新しい機能をいれるには遅すぎるというわけです。GC とか、研究やマイナーな言語にはもうずーっと前からあるのに、やっと Java で入ったって感じ。ちょっと遅すぎるので、もっとスピードを上げましょうと。上げるにはどうしたらいいかっていうと、もっとお気楽に変えられなくちゃいけない。なので拡張可能言語が重要だね、っていうストーリーをプレゼンしました。

笹田　おー。なるほどぉ。

田中　でもね (笑) まあなかなか難しいところで。

笹田　それを Ruby でやってるの？

田中　どうなんでしょうね。言語の進化って意味では、少なくとも Ruby に関して言えば拡張可能にすることによって進化を加速させているのではないですね。たとえば、まつもとさんは % 記法を拡張可能にすることを必ず拒否するとか。ならどうやって進化させているかと言うと、いろんな人が議論しながらひとつのものを進化させてるわけですね。だからそういう意味ではプレゼンしたようなモデルで言語の進化に関わっているわけではない。ただ、私が Ruby というひとつの言語の進化に関わっているのは確かなんじゃないかなあ。まあ少なくとも変化には関わってます。stdio を捨てるとか。あるいは open-uri は喜ぶ人が多いので、アレを進化と呼ぶのであれば進化かもしれない。

笹田　バグフィックスは進化とは違う?

田中　バグフィックスは進化か。普通は進化とは言わないんじゃないですかね。まあただ、バグの鉱脈がある時には、たまに全部潰すときに必要上進化することがあります。

笹田　callcc とか？

田中　callcc はどうかなあ。例としては 1.6 の頃に Marshal が原因となって core を吐くのを大量に報告した覚えがありますね。で、その結果何が起きたかって言うと、Allocation Framework が入ったのがあるんですけど、これは比較的明確な進化ですね。

最近の話で finalizer のタイミングがずれたっていうのが。あれは進化かって言われるとちょっと微妙ですが (笑) まあ shiro さん²⁵に言わせれば Boehm の論文がある²⁶って話だから、論文と同じくらいの新規性があるのかもしれませんが。

笹田　何の話でしたっけ。

田中　えーとだから finalizer を GC の時点で動かすのは凄い危険だっていう²⁷。

笹田　あー、はいはい。え、ずれたの最近でしたっけ。

田中　最近ですよ。私が提案したので覚えてますが。(ruby-dev:24354)

言語の進化ねえ。だからそういう風によってたかってやるのと、拡張を可能にしてみんなが個々にやるのとどっちがいいのかねえ。というのは微妙なところではあります。

笹田　拡張可能なのをみんながよってたかってやるのは……なんか発散しそう。

田中　うんそう、よってたかってやる必要があるのかっていう問題がありますよね。だって別にある人が拡張したからって、それが気にくわなければ使わなければいい。でも Ruby に俺が変更を加えると、それを使わなくていいわけにはいかないよね (笑) いかないので、議論を巻き起こすもしくは議論に巻き込む効果はあります。だからちゃんと興味がちょっとでもあるやつをかき集めて議論する意味はある。拡張可能だと、気に入らない人は発言しないかもしれない。

笹田　拡張可能なことと Lisp のマクロが云々って言う話とは関係ない？

田中　もちろん関係あります。Lisp の macro も含めて、作れば何でもできますっていうのはそのとおりなわけです。でも、みんな自分で作って自分だけで使うというのは不幸なわけです。でも、とくに簡単に作れるものに関してはそうなってもおかしくない。まあ作るのは大変なやつは共通化していくでしょうけど。でも、簡単に作れるものだって、やっぱり共通化は重要で、そういう方向性を推奨もしくは強制するようなフォースが重要かも知れない、という話なんです。まあ強制しすぎると耐えられない人もいるんでなんですが。

笹田　じゃあその辺のバランスを何とかしたいっていう感じなんですかね、目標は。

田中　バランスっていうのはどういう風にとったらいいんでしょうね。まあでも、別に完成したものを一個作るというのではなく、成長しながらバランスをとっていくというのが現実的ですかね。つまりソフトウェアは成長していくんだと思えば、ある時点で完璧なのを作らなくてもいいかな。不満があるんであれば、あるいは迷いがあるんであれば、そこは実装しない、機能不足にしておくとか。できなくてもいいと。あとで誰かが要求してから作ればいいとか、あるいは要求されてから議論すればいいかと。やや乱暴な話かもしれませんが。

いやまあ実際、仕様を早く決めすぎるっていうのは非常に怖くて、微妙なところの仕様って決められないんですよ。用例が見つからなくて。たとえば Ruby でいえば IO#read の引数に 0 を与えたときに、これは nil が返るべきか空文字列が返るべきか。っていうのは、実例がなかなかなくてなかなか判断できませんでしたね。まあ ML を探しまわって結局二つ例を見つけたんですが。だいたい read(0) って、0byte 読むってことだけど、そんなことやんないじゃん。少なくともリテラルで 0 ってそこに書く人はまずいないわけ。そんなことをしても何も情報は得られないから。でも 0 を渡せるのが有用であることは実はあって、たとえば CGI で Content-Length の数値をそこに渡すとか。ここで Content-Length: 0 っていうことがあるわけで、このときにはどっちがいいかっていうと、これは空文字列のほうがいい。つまり 1 以上だったら文字列返ってくるから、0 のときだけ nil が返ってくるというのは普通気がつかなくて間違いの元なわけです。だからこの例では read(0) は文字列のほうが良い。

これとおんなじ様な話が Marshal の内部でも実はあって、やっぱり「長さ指定 + 文字列」っていうときに、長さが 0 のときに、文字列が返ってきたほうが便利。で今のところ nil が帰ってきたほうが便利っていう例は見つかってない。

でもこれ、メーリングリストとか探し回ってさ、ウン年分あってもさ、たった 2つよ。こんなの最初に設計したときに判断できるわけなくて、そういうことを思うと、まあ変わっていくしかないかなーと。あるいはエラーにしておくとか。迷ったら、まあこの場合はちょっと、機能つけないってことはできないから、とりあえずエラーにしておくとか。たぶん最初にエラーにしておけば、あとから変えてもあんまり文句でないと思うから。使いにくすぎてはダメですが、迷うところについては使いにくくしておいてもいいかなぁと。後から使いにくく変えると恨まれるから、最初は使いにくくしておくのがまあ、恨みを買わずに進化させていくことに必要かなと思ってますが。

笹田　そういうことを普段なんか研究としてやってるっていう。

田中　いやこれは実践ですね。

笹田　なんか論文にならなそうな話だなあ。

田中　論文ねえ。どうしたらいいんでしょうね、これ。もうちょっと普及して欲しい概念なんですけど。

江渡　Java でいっぱい例外とか出るじゃないですか。でだいたい try{} って書いて catch{} で何も書かずに終えるっていう風にすることが多いんですよ。

田中　うむ。checked exception の弊害ってやつですね。

江渡　うん。その話を思い出したなあ。ちょっと厳しいようにするのはいいけども、だいたいそういう風に逃げて、何の意味もなくて。

田中　だから、よけ方も考えないといけない。たとえば今 WebApp っていうライブラリを作っていて、form のっていうかパラメータへのアクセスに非常に迷ってるんですよ。CGI 流だとまあなんか Hash みたいな物が入ってやるんだけど、あそこは危ないから、なるべくなら validation 付きでアクセスさせたい。だから validation 付きのアクセスと validation なしのアクセスがあって、validation 付きの方が簡単に呼び出せるようにしたい。

でも validation のほうはまだどういう風に validation していいかっていうのよくわからないから今すぐには実装はできないって言うか、ちょっとやったんだけどまああんまり完璧なものではなくて。でそうすると validation なしのほうを難しくしておきたい。その結果として何をしたかっていうと、すっげー長いメソッド名にしたんですよ。別に意味なく長くしたわけではなくて、application_www_x_… って MIME type が全部書いてあるわけです。すごい長いわけ。get_<MIME type>とか、MIME type すごい長いからでまあこれでいっかと。こうしておけばこれはあんまり使わないでいてくれるに違いないと思っていたらですね、最近 RedHanded で _why が「こうやって alias すれば短くなりますよ」って書いて。

笹田　(笑)

田中　うーむとか思って。いやあなかなかままならないものだなと、思いましたが。

メソッド名長くするっていうのは、あんまりへんな、checked exception みたいに有害な害にはならないぶんまだマシかな。

笹田　へんな alias を作らせるっていうのは有害になる気がしますけどね。

田中　まあでも、それは悪い書き方なのね。そのうち validation 付きのよい書き方を設計したいという希望だと思ってください。それに、短くてもいいやと思い直したら、ライブラリが alias を提供してもいいわけですし。そうしても互換性は壊れませんしね。

普段の仕事

笹田　普段の仕事ってそういうことやってるんですか?

田中　普段の仕事ですか。

笹田　うん。仕事仕事。

田中　こういうことを考えてることもありますしまあ Ruby のことを考えてることもありますし、あるいは職務として委員会とかの作業をやっていることもありますし。まあいまはプログラム委員のことをいろいろやってます。LC2005 の。

笹田　え、業務ってそういうことなの？

田中　業務。うむまあ、ひとつは外に発表することですかねえ。

笹田　あーなるほど、研究会とかで発表する。

田中　まあそれもそうかな。まあなかなかあんまり output をうまく出せなくて心苦しいんですが、

笹田　でもあれですよね、この間高林さんに言われましたけど、私みたいにへんな論文²⁸よりも、ちゃんと Ruby の VM 書いたほうが世の中に役に立つよねっていう話をされたけど、田中さんはまさにそれを地で行ってるわけですよね。へんな論文なんか書かないで役に立つものをアウトプット、コードとして出してるっていうのは。

田中　まどうなんでしょうね。

笹田　でもそれは業務としての実績にはならないとか、そういうことですよねきっと。

田中　まあそこは難しいですね。

そういえば実績って言う程のものではありませんが、産総研では常勤になると、年度末に自分がどんなことをやりました、こんなにちゃんとやりましたっていうことを書かされるのですが、バグレポートの件は書いたなぁ。

笹田　一日一件。

田中　一日一件じゃないけど、たくさん書いてたくさん送ってこのくらい当たってこのくらい fix されました。確かそのときは 8 割から 9 割くらい当たったのかな。当たったっていうのはそのつまり、それはバグであったってことです。バグレポートが間違っていたっていうことはあるので。まあそういうことをこんぐらいやりましたと。いうようなことは書きましたね。

笹田　それ評価されるの？

田中　グループの方針次第ですが。うちはされる。てか戸村さんのグループは、フリーソフトウェアもやるというグループなので、それは評価できるわけですけど

笹田　じゃあ田中さんのお仕事はフリーソフトウェアを云々って話なんですか。上のほうでは。上の方っていうかグループとしては。

田中　それは一部で。去年の初めまでは一杉さんと一緒にやってたんでまあいろいろと拡張可能云々っていうのをやってましたね。で去年の途中からちょっとこっちに来て、しばらくは、BTS の類を作ってまして。これはどうにかしてそろそろ公開したいと。

BTS について

田中　ちょっと日記に書いたんですけども、まあようするに、プログラムってのは開発しているとたまに壊れたり直ったりするわけですよ。

笹田　うん。

田中　あるとき壊れたことを発見したらいつ壊れたのかを知りたいじゃないですか。昔は動いたんだから。

もちろん、ソースを見て調べるのは一つの手だけれども、毎日コンパイルしてあれば全部テストすればわかるわけじゃないですか。あるいは二分探索でもいいけど。これは、みんなちょっと考えれば思いつくんだけど、実際にやるのこれすごい面倒臭いんです。で、まずコンパイルしなきゃいけないわけでしょ。対象にもよりますがそれなりの時間がかかるわけですよ。で、真ん中毎に試すとかいうと、残しとくにはディスクが必要だし、消しちゃうとそこで問題が再現したかどうかおぼえてられないしさ、で二分探索すると、二分探索って、人間にあわないんですよね。まあ、指が 16 本あって 16 進数で世界が動いていたらよかったと思うんですけど、えと、10 を 5 にわけて、5 の次をどうわけるかとか。

笹田　うん。

田中　なんかうまく分かれないし、それから、二分探索してるとどっちに失敗があったのか、どっちに切れ目があったのか、忘れちゃうことがあったり。可能なことは知ってるんだけど、現実的には面倒臭くてやらないことが多い、というテクニックなんですけども。

でもそんなのは機械的にやればいいわけで、機械的に毎日コンパイルしておいて、で、全部がーっとテストさえ試せば切れ目が一目瞭然、という。で、ここで導入されたんだというと、そこの変化を diff でとれば、これでもうこの中にバグが入ってると。

笹田　なるほど。今やってる ruby の autobuild っていうのはそれの話？

田中　autobuild 自身はもっと簡単な話ですね。まあ似てなくもないけど。

笹田　じゃあもっとそれをそれももっと難しく、難しいというか密にしようと。

田中　そうですね。cron で実行してログを取って。

笹田　あれがもっと便利になるという感じ？

田中　ちょっと質が違うものになるはずです。

笹田　なるほど。

田中　autobuild は最新のいくつかしかコンパイルしたのを保存してないけれど、こっちはもっとディスクを使って、たくさん保存してあります。で、Web から (認証付で) テストを登録することができる予定。で、登録したテストは過去にコンパイルされたのに対して実行される。予定ですが。いやまあ、なかなかすすまなくて、しょぼいものしかできてないのが問題なんだけども。

笹田　DamageControl とかともまた違うんですね? あれは commit されたら make だから。

田中　あれはそうですね。autobuild に似てますね。あれは画面がかっこいいですね。autobuild と比べるとあっちの方がきれいな気がします。

autobuild は何がいいんですかね。シンプルなところですかね。autobuild の問題は、autobuild は何で始めたんだっけな。

笹田　自分がバグを見つけたいからじゃないですかね。

江渡　まつもとさんが毎日はテストしないからとかそういう話から……

田中　そうかもしれないね。あるいは自分が気付いてても他の人がなんで気付かないんだっていう憤りかな。じゃあメールかけばいいじゃんっていうのはそうなんだけど、メールかくの面倒だし。

笹田　(笑)

田中　でも問題はさあ、autobuild になってもやっぱり、メールかかないわけですよね。誰がかいてるかというと西山さんがかいてるんだけど (笑)

笹田　(笑)

田中　いや非常にありがたい話ですが。なかなか難しいところですね。結局ああここで問題が入ったかってわかったらそれで満足してしまう。

笹田　やっぱメールだす機能も必要って。

田中　うん、そうですね。

笹田　いま作ってるやつではそういう機能が入るんですか？

田中　あいや、それは違います。入んないと思いますよ。

笹田　ま、バグをみつけるってことですか

田中　うん。そういやメールを送るのは gcc でやってるって聞いたことがありますね。新部さん²⁹に聞いたんですけども、gcc ではテストを定期的にして、で、それでバグが、というかまあテストが失敗すると、前回から今回のところまでの ChangeLog に入ってるメールアドレスにがーんとメールを送る、というのがあるんだと、言ってました。

笹田　へぇ。

田中　それはそれでちょっとなにかという気もしますが。

笹田　今度はユニットテストでメールアドレスかなにかを書く欄をおいといて、テストが失敗したらがーっとメールを出す。

田中　どうなんでしょうね。Ruby ぐらいだと要らないと思うんだけど。ああつまり Ruby ぐらいだとみんな見渡して理解できる。

OS とかだと、OS 全体とかいわれると、全部を一人で把握するのは無理なので。適切なところに送らないといけないと思いますが。Ruby だと規模の問題として別にそこまでの機構はいらないんじゃない、と思います。

笹田　なるほどね。

田中　そうそう、autobuild は最近は警告の数を数えているんです。正確には「warn」という 4 文字の文字列を数えていて、たまに増えたり減ったりするんですよ。でまあ増えたときはちょっと diff をとって何が原因で増えたのか調べてます。何かの拍子に増えたときに、警告が増えるときにはこれはなんかバグが入ったということを意味しているのではないかということでね。

まあただ、そもそもなんで警告があんなに多いのかという問題はありますけど。

笹田　うん。

田中　まあ autobuild 自身は -Wall でやってるから警告ですぎなんですけど。それでも例えば unused variable が残ってるんですよね。たくさん。誰も消さないんだけど

笹田　うん。

田中　消しても文句を言われることは絶対ないと思うんですが。

笹田　誰も -Wall やってないからじゃない？

田中　-Wall じゃなくても普通にやれば出ます ³⁰。

笹田　なるほど。

田中　-Wall で出てまあ消さなくていいかなと思うのは && と

を括弧でくくれってやつとかは、まあ問題ないかなと思うんだけど。unused variable は削除するだけだから、消していけない理由はどこにもない、と思うんですが、誰もやらないなあと。まあ、俺もたまにやろうかなと思ったりもするんですが、結局やらないままなんだけど。

笹田　ふむ。

田中　他にもインストールが失敗するってことがたまにありますね。make install って時間がかかるんで、やらないで commit する人はそれなりにいるんですよ。

あるいはクリーンインストールしないと再現しない問題とか (笑) あるんですよ。まあ checkout してインストール先が空っていうのは私も滅多にやんないんで開発者はみんなそうだと思うんですが。これでトラブるのは、例えばつまりライブラリを減らしたんだけど、なんか require するところが残っていて、でも以前インストールしたものが残ってるから動いちゃうとかいうケースですね。こういうのはクリーンインストールしないとわかんなくて、これは、素早く発見できるようになった気がする。

バックナンバー

Rubyist Hotlinks 【第 8 回】田中哲さんその2

インタビュー(2/3)

生い立ち

JAIST 時代

実は RFC1468 にはバグがある

使いやすさについて (2)

Mule にバグ報告をしていた頃からすでに田中さんは報告するだけで fix しない今のパターンを築いていた

産総研

CVS ネタの未踏でやったこと

プログラミング言語 MixJuice

使いやすさについて (3)

言語の進化はいかにして加速されるべきか

普段の仕事

BTS について

おすすめのライブラリ

ドキュメントのあるべき姿とは

バックナンバー

Rubyist Hotlinks 【第 8 回】 田中哲さん その2

インタビュー(2/3)

生い立ち

JAIST 時代

実は RFC1468 にはバグがある

使いやすさについて (2)

Mule にバグ報告をしていた頃からすでに田中さんは報告するだけで fix しない今のパターンを築いていた

産総研

CVS ネタの未踏でやったこと

プログラミング言語 MixJuice

使いやすさについて (3)

言語の進化はいかにして加速されるべきか

普段の仕事

BTS について

おすすめのライブラリ

ドキュメントのあるべき姿とは

Rubyist Hotlinks 【第 8 回】田中哲さんその2