SIGGRAPH

研究

SIGGRAPHのねただが、読み方の話ではない。

http://www.cs.utah.edu/~michael/leaving.htmlへの言及を五十嵐さんその他のところで見たため。著者の彼は、SIGGRAPHのtechnical paperのreviewの仕方に矛盾を感じて悔しい思いもしたので、Computer Graphicsのエリアを離れることにした、という話。

"hot"であるねたが過剰にもてはやされることがある、というのはプログラミング言語の分野でも同じかもしれん。余り新しいねたを言挙げするのは問題もあるので古い話を持ち出すが、OOPSLAでも「Javaにmulti-methodを導入してみた」とかいう話があったりして、「Javaという言葉がタイトルについていれば中身がどんなに意味がなくても許されるのか」、という疑問を持ったりしたこともあるし。

Science Envyという、「分野の名前に"Science"と名乗っているものはchemistryとかphysicsみたいな本物の科学へのジェラシーがある」という意味の言葉があるが、computer scienceはまあ確かに真の科学ではない。科学とは、どの理論が良さそうかどうかの最終判断は「宇宙・自然そのものが下す」というものであるのだが、「プログラミング言語の使いやすさ」なんかはある程度のevidenceをもって「科学的」に主張はできるものの、人間の審美眼に頼るところも多いし、情報というものの定義にほとんど「人間」というものが入っているようなものなわけなので、「使えるかどうか」という判断も人間の役に立つかどうか、というものなわけだし。

京都賞には「思想・芸術部門」、「基礎科学部門」、「先端技術部門」の3つがあるのだが、某受賞者は、これらは「究極的に人間のみが審判を下すもの」か「究極的に自然と宇宙が審判を下すもの」か、あるいは「自然がもたらす制約の中で、人間の審美眼による審判も仰ぐもの」か、という違いがあると言っていた。コンピューティングは最後のものに入る。

型理論なんかは「数学」として、「外世界による審判は必要なく、その体系内で矛盾がなく美しければよい」という理論としてはよいものなわけだが、プログラミングとはUIでありコミュニケーションツールであると思った場合、例えば「"int x, y; x = 0; y = 0"と書いたほうが、"int x, y; y = 0; x = 0"と書くよりも良い」、というような「practice」に関わるところまではカバーできないものではある(そんなことはやっている人にとっては当たり前だが)。要は、静的型言語と動的型言語のどちらがよいか、という議論は「科学」にはなりえず、人間のジャッジメントは入るものだ、ということである。彼が書いているように"at the end the success or failure of any specific technique is, quite literally, in the eye of beholder."ということだ。プログラミング言語では、CGほど「見た感じ結果が良さそうに見える」という開き直りをしない話も多いのでたちが悪いかもしれん。

それはともかく、「SIGGRAPHに投稿して落とされたから、改訂して1年後のSIGGRAPHに出す」という行動を取る研究者が出てしまうのが確かにシステム上の弊害だな。彼の書くようにひとつの"superconference"がある、というのは、分野の発展そのものを考える場合にはあまりよろしくないのだろう。

ふつうのHaskell

その他

昨日のことだったが、書類仕事の合間に中谷君が持っていたふつうのHaskellプログラミング ふつうのプログラマのための関数型言語入門をパラパラと。モナドの章の前までは読んだが、時間切れ。後のほうが面白そうではあったのだが。

将来的には、Ianのシステム上にHaskellを実装する、という時も来ることであろう。AlexはJavaにLazy Evaluationを入れたりしていたので、まあ案外近いうちに起こるかもね。

会食

その他

豊田、東、あきらと晩御飯。豊田はなんとトランプ手品を練習しているそうでいろいろ披露してくれたのだが、目の前でやっているのに種がわからないのだよなあ。トンデモねたが嫌いな理由のひとつに、俺自身が本質的にはだまされやすい、ということがあるかもしれん。
豊田が悪魔に魂を売ったという仮説もだいぶ唱えてみたけど、きっとこれは違うな。

書類仕事

仕事

なにやらいろいろ印刷しては切り取って「様式6」みたいな紙にのりで張る、という作業を半日。latexで表の各行の高さをきっちりそろえるときにどうしたらよいのか分からなかったのだが、なりゆきでごまかす。

少なくとも、「マスに合ってない」とかいったbullshitはなかったのでまあ提出できたのだが、半日かけて誰も見ないような紙をたくさん図画工作するというのはふもーな気はするなあ。

というわけで

仕事

まだ論文の修正は必要なのだが、少し心の曇りが晴れたような気はする。となるとなにやらコーディングをする機運が高まるわけだが、さて何をしようか。

ひとつは、某所との共同研究でやると言ってしまった「大きいやつと小さいやつを滑らかにつなぐインターフェイス」。これはいずれやらなくてはならない。

が、研究っぽいことはつらいこともあるので、役立ち系として、mpeg4ipのライブラリを使ったSqueakでメインの部分が書かれたビデオデコーダー・エンコーダ。できあがりがどのくらいの品質になるかがちょっと予測できないわりに手間がかかりそうなのがいやらしいし、idstとの絡み方も考えないといけないわけではある。

あとは、SketchPadの論文を再び読み直して思ったが、制約解消系。レイアウトやテキストレンダリングやConnectorsをまとめて書きなおせる基盤になりうるし、下まで開けられる20,000行のシステムを目指す場合に役立ちそうなので欲しいところではあるが、本当に必要なものはなんなのかお勉強をしなくてはいけない。

Tin LizzieのeToysを見捨てずに使えるようにしたい、という気持ちもあるのだよな。ただし、タイルの表現法を変えたりコードの中間表現を作るところから、デバッガを誰かに直してもらうよう頼んだりすることまで含まれるので時間のかかる話ではある。

毛玉のパッチ変数の型を変えられるようにしたり、フィールドを導入したり、GPUを使った最適化をしたりということもすることにはなるな。

Scratchも含めて、多言語化処理のフォントレンダリング周りを拡張する必要もある。もう外部ライブラリに頼ります。これはちゃんとglyph shapingできるようにする、ということを含んでいるので$100 Laptopにつながるわけではある。

どれか一つでもできればよいのだが。