Rubyist Hotlinks 【第 6 回】 江渡浩一郎さん 前編

はじめに

著名な Rubyist にインタビューを行う企画「Rubyist Hotlinks」。前回の増井俊之 さんからのご紹介で、今回は、江渡浩一郎さんにインタビューさせていただきました。

今回のインタビュー、実に5時間弱と大変長時間なものになってしまったので、 前後編に分けることにしました。前編では、おもに江渡さんと Ruby の関係 についてお伺いしています。後編もお楽しみに。

なお、今回のインタビューには、田中哲さんに同席していただきました。

プロフィール　江渡浩一郎さん

1971年生まれで東京都出身。ネットワークを用いた活動歴は長く、 インターネットを利用した活動や作品制作をいちはやく手掛け、 数多くの作品を発表しているメディア・アーティスト。

最近では qwikWeb の開発者として有名。

座右の銘

「ここがロードス島だ、ここで跳べ」

尊敬する人

チャールズ・バベッジ、横井軍平

ご本人のサイト

http://eto.com

その他

eto.com/profile¹、江渡 浩一郎 プロフィール

インタビュー

聞き手

ささだ

語り手

江渡さん

野次馬

田中さん

日にち

2005 年 4 月 8 日

場　所

産業技術総合研究所 (文京グリーンコート)

人物像

好きな言葉

ささだ

好きな言葉、座右の銘などありましたら。

江渡

1 個これ、というのはないんですよ。たとえば一つ出てくるので言うと、「ここがロードス島だ、ここで跳べ」ってのがあって……知ってます？

ささだ

すみません。知りません。

江渡

意味はわりと簡単なことで、昔話なんですよ。古代ギリシャかなにかで、あるホラ吹きがいてですね、僕は凄く高くジャンプできるんだ、と。ここだと調子が悪くて 50cm しかジャンプできないないけど、ロードス島でなら 1m は跳べるとホラを吹いていたところ、他の人から「ここがロードス島だ、ここで跳べ」と言われる話なんですね。これが有名な台詞になるのはもう少し後の話で、色々な哲学者がそれを引用して。「今ここにある問題を解かなくちゃならない」という意味で引用されたのが、この言葉の使われ方なんです。なんか、問題を回避したがるじゃないですか、言い訳して。大体世の中の問題は難しいものであって (まあ誰も解いてないから問題なわけだけど)、それを解く時に逃げちゃうことがある。一番難しい問題から逃げちゃおうとする傾向があるんだけど、それは良くないよね、という言葉なんですよね。

ささだ

なるほど。

江渡

実を言うと、その先にあるのはですね、色々な人が色々な言葉を使っているわけだけど、「一番難しい問題は、実は一見簡単なところに隠れている」みたいな、そういう文脈で使われることもあるんです。最初にこの言葉を使ったのがヘーゲルなんです。ヘーゲル² という哲学者がいて、『法哲学』っていう分厚い本を書いてて、その本の序文に書いてるんです。序文の最後に「ここはロードス島だ、ここで跳べ」「ここに薔薇がある、ここで踊れ」³ って感じで。

ささだ

ふむ。

江渡

その次にマルクス⁴ っていう経済学者がそれを使っていて、『資本論』ていう凄くたくさん巻数のある本があるんですが、その最初の章がわりと有名で、価値形態論ていう「お金とはなんぞや」みたいなことをを論じている。で、2章3章4章……と続くんですけど、その4章に流通過程論てのがあって、そこでその言葉が使われているんですよ。資本論ていうのは経済学について批判的に検討した本なんだけど、一番最初にお金とは何ぞやということについて考えてみた、と。ところが、答えは出てこない。順々に先送りするんだけど、どこかに問題が隠れてるはずだ、と。で、4章に流通過程に着目して論が進めてあって、その中に「ここがロードス島だ、ここで跳べ」という言葉が出てくる。貨幣というのは非常に複雑なものだと、はじめに論を進めているけれど、ところがその答えというか、どうしたら貨幣に潜む問題を解決することができるかということが全然出てこない。それで細かいところをじっくり見ていくと、流通過程というのにメスを入れたときに書いてある言葉が、もうちょっと複雑な形で「ここに答えはあるが、答えは無い」みたいな感じで、逆説的な書き方をしているんだけれど。何が言いたいかというと、一見普通に見えるような、答えが無いようなところに答えが潜んでるっていうのが前提にあって、本当に複雑で隠されてよく見えないようなところに答えがあるから、じっくりそれと向き合わないと見えてきませんよ、という意味合いでその言葉を使っていたわけですね。

ささだ

なるほど。そういう言葉が好き、と。

江渡

パッと言われたら、そういうのが出てくるかなあと思うんだけど。いっぱいあるよね、……高林さん⁵ じゃないからスラスラ出てこないけど (笑)

ささだ

高林さんだったら、パッと出てくるんですか？

江渡

なんかそういうの好きだからね (笑)

尊敬する人

ささだ

尊敬する人は？

江渡

チャールズ・バベッジ⁶。僕もそんなに詳しくないんだけど、どこかこう、良くやったなーこの人っていう気がするんですよ。

田中

しますね。

江渡

なんていうんだろう、たとえばチューリング⁷ とかまでくると、今やってることとかなり地続きな感じがするじゃないですか。

ささだ

はい。

江渡

たかだか 55 年くらい前で、既に真空管とかできているから、そこで計算過程を抽象的に捉えて、しかもちゃんと計算機を作っちゃったっていうことで凄い人だと思うんだけど、さらに昔にバベッジは真空管も無くて、でもやるぞって言って歯車だけでかなり良いところまで行って、オーガスタ・エイダ・バイロン⁸ が「それって凄いわ」って言って、「計算を計算するってこともできるかもしれないわ」って文章を書いたりして、結局実現はしなかったんだけど、すげーなコイツ、と思いましたね。それが (チューリングの) 100 年くらい前。

ささだ

100 年くらい前の人なんですか。

江渡

そうなんですよ確か。だからチューリングとか今はかなり実績が高いんだけど、1900 年代中頃じゃないですか。バベッジは 1850 年くらいじゃなかったかな……かなり間があるんですよ、その間に。……なんか凄い人がいたんだなあと思いました。

ささだ

なるほど。

江渡

なんか色々いるじゃないですか、発明家って。でもコンピュータっていう文脈で考えると、大体 50 年位前から急激に発達してくる曲線を描いているんだけど、もっと先にちょこちょこっとあるんですよね。

江渡

一番最初まで行くとそろばんの発明とか、四則演算の発明とか色々あるかもしれないけど、計算そのものを抽象的に捉えて、しかもやるぞって言って歯車と蒸気機関で途中までやったっていうのが、凄い開きがあるなあと思ったわけです。初期のころの発達はこう直線になってて、バベッジとチューリングがいてその間が切れてるんですよ。で、その後コンピュータが広がっていくわけだけど、なんか凄いよねえ、と思ったことがある。

ささだ

計算機の歴史の原点の後ろみたいな。

江渡

これが原点だと思ったらまだ後ろにいた！みたいな。

ささだ

最近の人とか、日本人とかっていうのはいます？

江渡

なんだろうなあ……メディア・アーティスト的にいうと横井軍平さんなんだけど、知ってます？

ささだ

いや、すみません。

江渡

いや、知らなくていいんだけど、一番簡単な紹介の仕方が、ファミコンの十字キーを発明した人。

ささだ

はあ。

江渡

十字ボタンあるじゃないですか、十字の形をしたボタン。これを発明した人が横井軍平さん。

江渡

他にもゲームボーイっていうのは彼が作ったもので、それからゲームも作っていて、『メトロイド』とか『ドクターマリオ』とか『ファミコンウォーズ』とか、任天堂から発売されるマニアックなゲームというのは大体彼が作ってる。

ささだ

なんかゲームの名前に。

江渡

『グンペイ』っていうゲームがありましたよね。

ささだ

何か関係があるんですか？

江渡

まさしくその通りで、そのゲームはあの人の遺作なんです。横井氏は事故で亡くなったんですよ。途中で色々あって、バーチャルボーイ⁹ っていうゲームマシンが任天堂にあって、あれも横井さんが作ったんですね。それで色々経緯があって任天堂を辞めたと。大変可哀想な人なんだけど、全然挫けずに新しい会社を自分で作って、ワンダースワンていう、縦からも横からも遊べるようにボタンがついてるゲーム機を作って、そのゲーム機用のゲームを作って「まだまだやるぞー」っていう時に事故に遭っちゃったんです。

ささだ

なるほど。十字キーって凄く古くからってイメージがあったんですけど、そんなに古くなかったってことですか。

江渡

ファミコンに搭載されたのが最初ですね¹⁰。それまでは無かったんですよ。縦横にボタンがあるとか、レバーとかだけで。少なくとも国内の特許では彼らが初めてですね。それで、それ以降、たとえば PlayStation なんかで十字キーが微妙に真ん中がつながってなかったりするじゃないですか。

ささだ

ええ。

江渡

それから丸くなってて、上下左右に押すようにとか。わざと十字にならないようにしてるのがあるじゃないですか。あれは特許を避けるためなんです。

ささだ

そうなんですか。

江渡

なんか奥深くてさ、その世界が。

ささだ

ファミコンて結局 80 年代？　その頃から活躍されていたわけですか。

江渡

そうですね。その前から。ちょっと記憶が定かじゃないんだけど、ピッチングマシーンていう球を投げるのを作ったり、任天堂ラブテスターっていう細々とした装置が、僕も知らないくらい前なんだけど、そのくらい前から任天堂にいて、そういう電子装置を使ったおもちゃを作っていたんです。「枯れた技術の水平思考¹¹」っていう言葉があって、その人が繰り返し語っていたんですけど、おもちゃで儲けるにはどうしたらええんや、という話があって、先端技術とか使ってたらあきまへんで、と。枯れた技術を使いなさい、と。枯れた技術を思ってもみない使い方で使うことで、新しい遊びを生み出していくとか、面白いことをできるようにしよう、と。

江渡

そういう風に枯れた技術を水平思考で別の使い方で使いこなすことによって新しい遊びができるんやで、みたいなことを言っていて、わりとこの言葉に影響を受けた人は多いですね。

ささだ

影響を受けられた方の一人ということですか。

江渡

だいぶ影響を受けましたね。

ささだ

ウェブで調べさせていただいたんですが、任天堂のゲームを作っていらしたとか？

江渡

作ってましたねー。

ささだ

任天堂のゲームセミナーに参加されていたとか。

江渡

参加してました。

ささだ

じゃあ、その話はまた追々、楽しみに。尊敬する人の話はこれくらいで。

主なソフトウェア作品、著作

ささだ

さて、代表作、っていうと何になるんですかね、たくさん作品がありますよね。

江渡

うーん、そうですね。厳しいんですよね、グループで作った作品が多いんですよ。たとえば『WebHopper』¹² という作品を作ったり、そのあとは時代が後になるんだけど『インターネット物理モデル』¹³ っていうのを作ったり。その後は仕事中に『SoundCreatures』¹⁴ ってのを作って、それは僕が筆頭の名前になっていて、キヤノンの ARTLAB で一緒に作ってて、他には個人で『LivingWebBrowser』とか作ってるんですけど、やっぱりグループで作ってるほうが出来が良いんですよね。だから、代表作というとインターネット物理モデルとか、皆今でも見に行けるし¹⁵、触って遊べるし、良い出来の作品なんだけど、「僕の」代表作とは言い難いじゃないですか。5人くらいで作っていて、しかも私はコンセプトとソフト制作をやっていて、具体的に物を作る部分は他の人がやっているから。

田中

微妙だよね。

江渡

でも、たとえば SoundCreatures とかだと、もう現物がないから今見られないし、ネット上でも体験できないし……なんて言えばいいんだろう。

ささだ

じゃあ qwikWeb¹⁶ で(笑)

江渡

qwikWeb にしましょう(笑)

ささだ

わかりやすいものでいうとそうなりますね。我々としては。著作みたいなものだと何でしょう。エッセイとか Web に色々書かれていて、雑誌にも書かれてますよね。

江渡

それはありますけど、本とかはないですね。

ささだ

じゃあ、それは今後楽しみにさせていただくということで。

江渡

はい。

Ruby について

好きなメソッド、嫌いなメソッド

ささだ

Ruby で好きなメソッドなどありましたら。

江渡

質問リストに入るのかなーと思って、マジ難しいんですけどって思ったんだけど、何か 1 個挙げるとしたら、好きなメソッドは method_missing ですね。

ささだ

なるほど。

江渡

これは好きですね。でも、これを書いた時はちゃんと respond_to? も書かなくちゃいけないというのが見落としがちですね。嫌いなメソッドは特にないかな。他に好きなのは Enumerable ですか、メソッドじゃないですけど。

ささだ

はい。

江渡

で、ハッシュがあるけれど、ハッシュに対する Enumerable みたいなのがないじゃないですか。こう、key と value のペアに対して map するみたいな。ハッシュを map してハッシュとして返すメソッドがなんで無いんだろうって憤ったことがありますけど。

ささだ

(田中さんに) なんで無いんですか？

田中

なんでかなあ。面倒くさいからね。

江渡

あってもよさそうなのに、何で無いんだろうと思ったことはあるなあ。

田中

誰も作ろうと思ったことがないからじゃないかな。

江渡

誰も指摘しない、と。

田中

結局ハッシュを配列にして、その後すぐにハッシュにできればいいんだけど、それが無いんだよね。

江渡

無かったっけ？

江渡

長さが 2 の配列の配列をハッシュにするような。

ささだ

たしか無かったっけ？

田中

これは結構話題になる話で、key と value が交互に並んでる Array からハッシュを作る奴はある¹⁷、でも key と value のペアが並んでる Array からハッシュを作るのが無い。

江渡

本当だ、そうだ。

田中

じゃあ、一段だけ展開すればいいじゃん、というと flatten はリカーシブに展開するから使えない。これが結構憤りに。ちょっとだけ話題になったんですかね。

ささだ

なるほど、じゃあその辺が嫌いというか、不思議、と。

江渡

不思議ですね。

田中

そういう時はですね、「これはわがままじゃないんだ！」という決意の元に、「これは嫌い」とか「だから Ruby は嫌い」とか言ってみるとか (笑)　だから直せ、と。

江渡

ああ、なるほど。まあもうちょっと良いのが欲しい、ということで。

Rubyist になったきっかけ

ささだ

それでは Rubyist になったきっかけは。

江渡

きっかけ。

ささだ

いつ頃から Ruby を使われてるんですか？

江渡

実は結構古いような気がするんですけど。90 年代かなあ。

ささだ

作品を作る中で必要になって？

江渡

そうですね。この話があって自分の半生を振り返ってみたんですけど、順番から言うとね、Python を使ってたんですね。

ささだ

ほう

江渡

それで Python が嫌になって、というか、これじゃあかん！と思って、それで Ruby になったんだけど。

田中

それ不思議だなあ (笑)

ささだ

これじゃあかん！となったきっかけですが。

江渡

多分なんでって思うかもしれないけど、すごいわかりやすい理由があって、その時は Python ていっても JPython 使ってたんです。今でいう Jython、Java VM 上で動く Python。あまりに遅くて使えないと思ったのが最初の理由。CPythonを使うという話もあったんだけど、Lightflow¹⁸ っていうレンダラーがあって、フリーじゃないんだけど凄い綺麗なレンダリングしてくれるソフトで。

田中

レイトレーシングみたいな。

江渡

レイトレーシングよりも高度な。レイトレーシングは結構遅いじゃないですか。そうじゃなくて、それと同じくらい綺麗で。

田中

ともかく、3D のレンダラーね。

江渡

そうそう。で、それが DLL としてしか配布されていなくて、拡張子が .so の Python のライブラリとしてリソースされていた、ってのがあって。

ささだ

なるほど。

江渡

で、使ってみようと思って Python を使い始めたんだけど……

ささだ

では、それが最初ですか。

江渡

いや、Python そのものはもっと前から触ってたんだけど、CPython には全然触れてなくて。で、その時は Java VM 上で動くっていう前提で、何かスクリプト言語を使ってみようと思ってたんですよ。で、JPython を使ったんだけど、死ぬほど遅くて諦めて。その当時は、サーバは Perl で書いて、クライアントは JavaApplet で書いてっていう組み合わせが多かったんですよ。だから Java 上でもう少し楽に書けるものとしてスクリプト言語をということで、JPython とかを考えてたんだけど、遅くて。なので、やっぱり Java を捨ててネイティヴな言語で、しかもオープンソースで、とか考えて、CPython を使ってみたんだけど。なんでそこで Ruby に流れたのかな？

ささだ

Python の文法は知ってたんですよね。

江渡

うーん、なんか慣れなかったんだよね。お尻が座りが悪いっていうか、上る階段はあるけど下りる階段は無くて。

田中

インデントのこと？

江渡

階段を上っていくとスポッと抜けちゃうような。

田中

いいじゃないですか。

江渡

僕は慣れなかったんだよね。

ささだ

あー、なるほど。

江渡

その頃は、オブジェクト指向そのものを良くわかってなかったんだよね。

田中

Python をやっていたのはいつ頃？　多分 1.4 とかかな。2.0 は使ってないよね。

江渡

うん。

田中

そうすると、長らく 1.4 だったから、1.4 かなあ。¹⁹

江渡

(メモを見て) 1999 年の 4 月に JPython を使ってますね。無謀なことに物理シミュレーションとかやろうとしてたんですね。1999 年 11 月に Lightflow を使ってますね。1999 年 12 月に「JRuby なんてあったら良いんだけどなあ」って書いてますね (笑)

ささだ

なるほど。

ささだ

Ruby が良いよ、っていう人は周りにいたんですか？

江渡

うん、いないよ。

ささだ

じゃあ、雑誌か何かを見て。

江渡

雑誌とか Web 上を調べて……そんな感じでしょうね。実は JRuby、Ruby on Java っていうのは早稲田大学の五十嵐さん²⁰ が作っていた……というのが書いてあるなあ。で、何か Ruby 本を買ってるなあ。なんだか知らないけど Pike²¹ とかと比較してるなあ (笑)

ささだ

Pike ってなんでしたっけ？

田中

最近あまり聞かないなあ。

ささだ

言語？

田中

ええ、言語です。

江渡

Roxen²² ていうサーバがあってですね…… Pike は更にマニアックだなあ。Pike は元々 MUD²³ を作ってる人が、その中に埋め込むために作った言語で、それが Pike っていう言語として設計されて、それから Roxen ていう Web サーバに埋め込みの形で実装されて、当時その Roxen ていうのがヨーロッパで流行っていて、Roxen が良いよってオーストリアに行ったときに言われて。

ささだ

オーストリアですか。じゃあ、そのまま Pike でいった可能性もあったと？

江渡

というと？

ささだ

江渡さんが、そのまま Pike を使う可能性もあった、と。

江渡

なかったね (笑)　ただ、なんとかっていう MUD で使われていた言語がこんな形で復活するなんて、とびっくりしたね。そういうのって世の中ありますよね。

ささだ

ゲーム記述言語ってことですよね。

江渡

そうです²⁴。そういうわけで、実をいうとかなり色々天秤にかけてるんですよね。それでも、2000 年にはかなり Ruby を使い始めてるなあ。

ささだ

その頃には天秤は Ruby に傾いた、と。

江渡

多分、5 月には傾いてますね。

ささだ

なるほど。

江渡

で、LightFlow の時に、Python からしか呼べないライブラリ (DLL) をどうするんだってことで、Ruby/Python²⁵ を使って、Ruby から Python のライブラリを呼び出す、みたいなことをやってますね。

江渡

そしたら Ruby/Python に一箇所バグがあって動かなかったから、ML で教えてもらうってことをしてますね。

ささだ

Ruby/Python てなんですか？

江渡

Ruby から Python を呼び出すんです。結構良くできてますよ。普通の Python のオブジェクトを Ruby のオブジェクトとして使える。

ささだ

そんなのあるんですか、知らなかった。

江渡

そうだよね、最近見ないね。RubyPerl とかもありますよね。

ささだ

すみません。それも全然知らなくて。

江渡

それもありますよ。そっちは出来が悪いというか、オブジェクトとして扱えなくて、Perl 側に存在するものは全部文字列としてしか見えないという。

ささだ

じゃあ Ruby/Python は Python のオブジェクトのメソッドを呼び出すと Python の処理が実行されるという。

江渡

ええ。

ささだ

へー。なんで廃れてるんですかね？

江渡

廃れてますよね、確かに。なんででしょうね？

ささだ

(田中さんに) 知ってました？

田中

名前は知ってますよ。使ってはいないけど。逆に、というか Perl には Inline::○○ というのが結構沢山あって、たとえば Inline::C っていうのは C のコードが書ける。で、確か Inline::Ruby っていうのもあったと思うんだけど。

ささだ

ありましたっけ？

田中

名前だけは聞いたことがある。

ささだ

でも、あれは単に system 関数で呼び出してるだけかと思ってたんだけど。

田中

どうだろう、そうかもしれない。

江渡

そうかもしれないけど、所謂ちゃんとした埋め込み型の Ruby があるじゃないですか。

ささだ

ええ。

江渡

あれで呼び出してるんじゃないですかね？

江渡

それで、かなり面白いのが、ある人が冗談だか知らないけど Inline::Perl というのを作っていて (笑)　Perlからインラインで Perl を呼び出すという。確か早川さん²⁶ も同じネタでやってたんじゃなかったかなあ。

江渡

最近、Ruby で使える inline C っていうのが公開されてましたよね。

田中

最近？

ささだ

最近ですね。Ruby to C を書いてる人たちがやってますね。

田中

ああ、あれか。思い出しました。

ささだ

江渡さんはいきなり濃いところをやってるんですね。

田中

大体、新しいものに手を出す時って、何か扱いたい時だから、そこに繋がるところにトラブルがあると手を出さざるを得なくなりますよ。で、皆が使ってないものはささださんは濃いと表現されましたけど、こなれてないってことですね (笑)　だから、未知数なものに手を出さざるを得ないわけですよ。

ささだ

Ruby はその頃から使われてるわけですね。Python は？

江渡

Python はフェイドアウトしてます。

ささだ

なるほど。

Ruby との付き合い

ささだ

では、現在はどんな風に Ruby を使われてますかね。qwikWeb 等有名ですが。

江渡

教育に使っている、という感じですかね。

ささだ

教育？

江渡

ええ。そこを強調しておかないと (笑)

ささだ

誰を教育しているのでしょうか？

江渡

Ruby で、昔多摩美²⁷ で教えてたんです。多摩美術学校っていう学校がありまして。

ささだ

何の先生を？

江渡

プログラミングの先生みたいなことをやってたんです。1 年間しかやってないけど。春と秋と 1 年生と 2 年生それぞれに教えました。最初は DBN²⁸ ってシステムがあって。これは MIT の前田ジョンさん²⁹ が作ったシステムで、Web ブラウザ上で JavaApplet として動く開発環境みたいなもので、非常に単純なコマンドしかないけれど、それを使って計算で形を表す、みたいなことを学習できる開発環境で、それを使って春学期は教えていたんです。で、後期は自分なりにやってみようということを考えて、その間に準備をして、Ruby で SDL³⁰ を使って OpenGL を使えるようにして、それにラッパーを書いて、非常に簡単に Line 文とかで線が引けるとか、バックグランドカラーが指定できるような簡単な学習環境を作って、それを使って教えていました。

ささだ

前回の増井さんのインタビューの時に、その話があって。なんというシステムでしたっけ。

江渡

それ以外に、Processing³¹ ってのが最近普及していて。メディアラボで前田ジョンが DBN を使って教えていたんだけど、そこから派生して普及して。DBN は完全に学習用と割り切っていて言語仕様を 0 から作り上げて、拡張性とか全然ない、というものだったんだけど、そのコンセプト的なものを残しながら、もっと発展させようと思って Processing っていう環境ができて、それがケーシー・リースとベン・フライが一緒に作ったもの。で、僕が sgl を作った頃は、Processing はコンセプトだけで配布を開始してなかったから、しょうがない、作るかってことで、その時はもう Java はやる気なかったから Ruby で。そういうわけで、Processing とは割とコンセプト的には近いです。DBN が元になっていて、簡単に使えて、という。

ささだ

学生さんたちとしてはどんな感じでした？　DBN を使った場合と、Ruby を使った場合で。

江渡

学生たちには前半 DBN という非常に限られた言語を使って教えて、後半は sgl を使って教えたんだけど……教え方のセオリーって色々あると思うんだけど、美術学校だから所謂大学ではないんですよ。そういう意味で結構気を使う点があって、単純に技術教育に特化した教え方をするんです。なので、そもそも Ruby という言葉を使っていないんですよ。言語を教えている最中に。

ささだ

なるほど。

江渡

だから、コマンドラインに入力する時に r-u-b-y って入れるんですよとは言うんだけど、これが Ruby という言語だということは一切、一言も言ってなくて、「ここでこう入れてください。そうすると起動して、ウインドウが出てきます」ってことしか教えない。アルゴリズムとかも殆ど教えない。ひたすらに自分の書きたい形があるとして、それをどうしたら書けるかということを繰り返しやらせる、というような教え方をしていました。結構、成果は良かったですね。

ささだ

ほう。

江渡

一番苦労したのは……配列を教えるのが苦労したなあ。

ささだ

配列は教えるんですか？

江渡

配列までは教えます。

ささだ

配列と繰り返しくらいですか。

江渡

配列と繰り返しと、メソッドの定義。その時はコマンドの定義みたいにして教えたけど、コマンドの定義をすると嬉しいよというところまで発展させた人は僅かしかいなかったかな。結構、数人は良くできて、凄い面白いのを作ってきましたね。

江渡

大体の人も配列と繰り返しまではマスターして、残像のようなものがじわーっと残るようなものを作ってました。

ささだ

なるほど。

ささだ

DBN というシステムには不足があったということですか。

江渡

DBN にはあった。というか、DBN は不足だらけで、ブラウザ上に画面が出るのだけれど、100×100 しか使えなくて、しかも白黒しか使えない。意図的に環境を制限しているものだったんです。

(DBN 実演中)

江渡

たとえば cos 100 とかやって Run とかすると……あ、間違えてる(笑)　お、来た来た。これで、たとえばバックグラウンドカラーを Paper=50 とかすると、背景が灰色になります、と。で、Pen を 0 にすると白になります。こんな感じで、非常に限られたシステムなんです。

ささだ

タートルグラフィックスのような。

江渡

そんな感じ。で、これを使って、限られた機能で一応コマンドの定義とか配列とか繰り返しができて、それで絵を描くという授業をやっていて……割と言語じゃなくて教え方が重要であるっていうコンセプトが裏側にあって、わざと要素を絞って理解しやすくして、実際に形を書きたいという要求を満たせるように作りましょう、というメソッドを DBN が用意していて、それに刺激を受けて自分でも sgl を作ったというわけなんです。

ささだ

今はまだ、開発を続けている、というわけではないんですか。

江渡

sgl をですか？

ささだ

はい。

江渡

今は、そのときに作ったコードを捨てて、ゼロから書き直していて、今日とか明日とかのレベルで公開³² しようと思っている、と。

ささだ

おお！　たまたまそんなリリースの時期だったんですか。

江渡

ちょうど来学期というか。今、芸大で教えているんですよ。そこでも同じようなものを使ってやってみようと。今これが sgl を使って学生さんが作ったもので。(編集部注：学生さんの作品のため、スクリーンショットなどお見せできません。ごめん)

ささだ

おお！　これを学生さんが。

江渡

ええ。これだけの人数がいて、一人 5 作品ずつ作る、と。半年間やって、今この 5 作品だから、これを順番に見せて、こんな感じの物が作れるようになりました、と。

ささだ

うわー、カッコいい。これは一般公開はされていないんですか？

江渡

これはしてないですね。

田中

入力はあるんですか？

江渡

マウスがある。

田中

マウスだけ？

江渡

マウスの動きでこんな風になる。

ささだ

うわあ、凄い綺麗だ。

江渡

やっぱり、学生さんは皆ビジュアルなものを作ろうと思って学校に入ってきた人たちだから、凄い真剣に作ってありますね。

ささだ

良くわかってないんですけど、芸大って絵の描き方とかの勉強の一環としてそういった sgl を使うような授業があるわけですか？

江渡

芸大って、そもそも多摩美だったから。多摩美では情報デザイン学科。

(ここでメロディが炸裂)

ささだ

音も使えるんだ。

江渡

音も使えるようにしたんですけど、音のほうは教える時間が少なくて、悲惨な出来のものしかないんですけど。

田中

この人の作品では音を使ってる、ってことね。

江渡

そう。いくつかテーマを設定していて、たとえばこの人は水だと思うんだけど。

ささだ

この学科はそういうこと、計算機を使うものをメインにしているわけですか。

江渡

そうですね。

(作品閲覧中)

田中

物理シミュレーションぽいなあ。

江渡

で、これは音が鳴るわけよ。壁の高さで音が異なる。

田中

昔 Squeak³³ で、こういうのが簡単に作れるのがあったなあ。物理シミュレーションエンジンみたいなのが。

江渡

(作品を見せながら)　水滴が、冬の窓ガラスに……水が落ちていくような。で、文字を書いてみる。実際こういう使い方が考えられますね。

江渡

こんな感じで、1 個の視覚的テーマを 5 種類に発展させるということで、結構みんなついて来ていたので、成果としてはなかなか良かったんじゃないかなあと。

ささだ

これはどのくらいのスパンで？

江渡

半年ですね。週一です。午後丸々これでしたね。

ささだ

なるほど。どう見せればいいか分かってるから、後はどう作ればいいか、なんですね。

江渡

うん。

ささだ

こういうので勉強した学生さんは、何をツールとして使うようになるんでしょうね。

江渡

実際の話、おそらくここから先何かをやるとすると、sgl を継続して使うことは考えてなくて、多分 Flash に流れるとか Director を使うようになるとか……スタジオによって分かれるんですね。多摩美の場合だと、スタジオが 6 種類あるんです。電子工作のようなものに特化しているところとか、情報デザインに特化しているところとか、色々種類があって、こういうインタラクティヴアート的なものに特化しているのは……なかったんじゃないかなあ。

ささだ

スタジオというのは研究室のようなイメージですか？

江渡

研究室のちょっと発展版みたいなものだと思ったほうがよくて。1 〜 6 のそれぞれのスタジオによって担当の先生が分かれていて、その 1 個のスタジオに複数の担当の先生がいる。先生は 10 人くらいでスタジオは 6 個。

田中

先生が二人ってことは大講座制ってやつかな？

江渡

そんな感じに近いと思いますね。更に、アートコースとデザインコースに分かれていて、アート的な方向とデザイン的な方向と大きく真っ二つに分かれていた、と。

田中

アートとデザインてどう違うの？　って聞いていいですか(笑)

江渡

いいですよ。答えるのは結構難しいんだけど、たとえば研究と開発ってどう違うんですかっていう。

田中

ああ、目的があるかどうか、というか役に立つかどうか。

江渡

研究は役に立たない、と (笑)

田中

あるいは、それ (目的・役に立つ) には遠いってことですね。

ささだ

開発っていうと、作るものが決まっているという感じがありますね。

江渡

ですね。こういうのを作ってくれっていうオーダーがあって作るのが開発、っていうイメージがありますよね。それに近いです、デザインは。それと違ってアートというのは、何を作るかは決まっていない、というか自分で決める、と。そういう違いがあるわけです。

田中

はあ。

江渡

それで、もう少し本質的にみるとアートの場合はその人にしかできないものは何かっていう問題設定があって、それに従って作るものっていうことになってます。

ささだ

それじゃあ、この作品 (学生さんの sgl による作品) はアートになるんですか。

江渡

微妙な質問ですね。それは研究と開発の違いと同じように外形的に定義できるものじゃないですね。アートっていうのは人生みたいなものなんですよ。だから、これが面白いか、アート的かってことは別として、継続的に続けていくということがもしあれば、それはアートになる。

ささだ

なるほど。ちなみに、当時 Processing があったら、そちらを使ってました？

江渡

可能性はあります。ただ、今の Processing でも、まだ Java の枠内でしかドローしてないんです。僕は SDL と OpenGL の組み合わせを使っているから、結構大きい画面でフルスクリーンで大きいものがぐるぐる回っているような、こういうことが簡単にできるんだけど、Processing は元々の発祥自体が JavaApplet の枠内で何とかってところから始まっているから、AWT で全部レンダリングしている、と。AWT でゴリゴリやって 3D とかを描画している。

ささだ

Java3D とかまでは含んでいない？

江渡

ええ、今でも含んでいない。最新版が今開発中で、そのバージョン 80 からは OpenGL とかにも対応して、結構大きい画面でも高速に動作するようになった、と。³⁴

ささだ

なるほど。

江渡

だけど、やっぱり教育目的っていうのを引きずっているので、実践に投入するのは難しいということがあって、僕は実践でも使ってみたかったので、OpenGL で言語は Ruby という方向に振ってみた、と。

ささだ

なるほど。

江渡

それが、私的には良かったなあ、と。

ささだ

sgl は何年も先を行っていた、と。

江渡

そういうことにしておきましょう (笑)　実際には sgl は配布もしてないし、ようやく書き直して配布できるようになったんだけど。

ささだ

楽しみにしてます。というか、そういう言語がもっとあっていいと思うので。

江渡

そうですよね。

ささだ

だからきっと、出せば流行ると思います。

江渡

今は OpenGL とか SDL が裏に控えているわけだけど、そんなのは知らなくても使えるわけで。たとえば学生たちがどんなソースコードを書いているかというと、こんな感じのソースを書いているわけですよ。

(編集部注：学生さんのソースなので非公開。ゴメンナサイ)

江渡

この程度しか書いていないけど、さっき見せたようなことができる。さっきのを凄いと思ったかもしれないけれど、大体このくらいでできるわけです。最初がここで最後がここで、setup して display で表示する。

ささだ

10 行くらいですね。

江渡

変数名に $ をつけて「変数には$を付けるんだよ」って教えて (笑)　ちょっと凝った人でもこのくらいで、色々バリエーションがあったように見えたかもしれないけれど、こんなものなんです。

ささだ

なるほど。

江渡

教える時にはそれ以外のものが重要になる感じですね。

ささだ

では、是非 sgl の配布を始めたときにはるびまに記事を (笑)

江渡

それいいですね (笑)

ささだ

まあ、あれは、あまり初心者が読まないので (笑)　どうかとは思いますが、暇があったら書いてください。

江渡

はい。

Ruby の好きなところ、嫌いなところ

ささだ

では、Ruby の好きなところ嫌いなところ……さっき Hash の話がありましたが、他に気に入っているところ、嫌いなところがあれば……

江渡

遅い (笑)

ささだ

遅いというと。

江渡

一杯あるけど、「ネイティブスレッドを使うようにさせてくれ」って感じですかね。

ささだ

ほお。

江渡

ネイティブスレッド対応があれば、少なくとも 2 倍になるじゃないですか。CPU を 2 個積んでれば。原理的には。

田中

(ささださんに) 並行処理の専門家として一言。

ささだ

なったらいいですね (笑)

田中

何にネイティブスレッド使いたいんですか？

江渡

いや、遅いから速くしたい。

田中

仕事は自分で分ける？

江渡

具体的には qwikWeb。

ささだ

アートとかではなくて？

江渡

それもあるんだけど、qwikWeb の性能チューンとか言い出して。それよりも前に、常に遅さはつきまとうんだけど、sgl を作ったのは、Processing の話でも出たけれど、自分でも使うということを想定していて、だから自分でも使って、教育用にも使えるというのを目指して、かなりうまく行ったんだけれど、自分の作品ではかなりがんがん計算していて、長いソースになっていて。そのソースを見せましょうか。

ささだ

でも、時間がかかるのって描画処理だけのような気がしますけど。

江渡

それもありますけど、そうじゃないのも色々あってですね。

ささだ

物理シミュレーションとかすると？

江渡

そうですね、物理シミュレーションとかもしようと思ったし。

ささだ

これも公開されるんですか？

江渡

これは作品として公開したものなので。

ささだ

じゃあ写真は。

江渡

写真は大丈夫ですよ。むしろ撮って下さい。

（江渡さんの作品実行中）

江渡

これはある種の楽器的にも機能する作品で、形と音が繋がるんです。この時は線だけでいかに豊かな表現ができるかということを考えていて。これを使ってライブのようなこともやって、駒場で目の前でライブのようなことをやったんです。スピーカーを良くするだけで結構いい感じに。

ささだ

ライブというのはこれが後ろにいるんではなくて、これがメインで。

江渡

そう。

（作品演奏中）

ささだ

ライブをやるときは後ろでマウスを動かすわけですか。

江渡

そう。でっかいスクリーンがあって、その横に机が用意されていて。

ささだ

これは sgl で？

江渡

そう。で、これはセルがオートマトンになってるから実は遅さが目立ったりして。要はこの数だけ演算してるわけで。こういうものは結構スムーズに動くんだけど、これなんかは配置問題みたいな感じで、空いてる場所を勝手に探して自分で自分を配置するという。これなんかはシミュレーションぽい奴。

田中

重ならないようにしてる。

江渡

そう、重なるとそれがエネルギーになってっていう計算なんだけど、結構最初は遅かった。

ささだ

よくこれだけのものが動いているという感じですね。なんだかこれは C で書いても遅いんじゃないかという気も。

江渡

そんな感じするけど、どうなんでしょうね。計算を工夫しているからこんなものなのかなあ。結構、「全然速度が出ないよー」って苦労しながら。

ささだ

浮動小数点使ってます？

江渡

使わないようにしたんだっけなあ、確か。距離も自乗のまま比較したり。重なってるかどうか近傍処理を整数でしたりとか。

ささだ

Ruby は浮動小数点は遅いんですよ。

田中

オブジェクトですから。アロケーションするんですよ。

江渡

ああ、そうだったんだ！　String とかもそうですよね？

ささだ

はい。

田中

そういう意味では、速いのは小さい整数と、あとシンボル。

江渡

そう、シンボルは速いんだよね。だからシンボルにすればいいんだなあと思いながら、色々なものをシンボルにしまくってましたね。

田中

いや、でもシンボルは使いすぎるとちょっと……。

江渡

ダメなの？

田中

あれ、GC されないんですよ。いつ使われるかわからないから。

江渡

グローバルに作られちゃうんだ。

田中

そう。

江渡

とまあ、こういうものを作ってきたわけです。で、何となくこう計算の負荷が高くなっていくんだろうなあというのが想像してもらえるかなあと思うんですけど。

田中

まあ大体、複雑なコードを書くと遅くなるんだよね、Rubyって。

江渡

うん。

田中

原理的には作業量が減っているはずだから速いと思って複雑なコードを書くと大体遅い。

江渡

うんうん。ここには出してないけど、もうちょっとちゃんと物理シミュレーションしているのがあって、所謂スプリングモデル、分子がぶつかって、こうひゅーんとかびゅーんとか飛んでる、そういうのを書いているときにはあかんと思って (笑)、「これは拡張ライブラリだ！」と拡張ライブラリの書き方を勉強したりしましたね。それはそれであるんだけど、それはスレッドで速くするのは難しくて。それで時代がぴょんと飛んで qwikWeb で 1 個 1 個の Request の処理は分かれているから、それさえ分離して処理できれば原理的には良いわけですよね。だからネイティブスレッドに対応すれば 2 倍速くなるんじゃないかと思うんだけど、ボトルネックが DB にあったりして(笑)

ささだ

よくある話だ (笑)　今の Ruby だと dRuby で分散しましょうみたいな話が。

江渡

ああ、その手があったか。その手はまだ試してないなあ。結局どうすれば速くなるか考えないといけないから、どうしてもお手軽な方向に行ってしまって。難しいですね。

田中

お手軽な方向…… YARV (笑)　ささださんに頑張ってもらう。シーケンシャルのままで 50 倍でしたっけ？

江渡

それだ！

ささだ

いや、50 倍は、かずひこさんが 50 倍にしたら (ささだを) NaCl に入れてくれるという話で (笑)

江渡

テストコードをちゃんと書くようにしてるんですよ。で、テストをする手法が、Request をして Response があるという処理が沢山並んでいて、それをテストするという簡単な手法なんですけど、Response の中から XPath でタイトルを抜き出すとか、class が day の div の中の A タグの中を XPath で取り出してきたものを assert するという処理が並んでいるんだけど、それが一番最初は色々遍歴があって、はじめは全部を REXML³⁵ で書いていたんです。ページの生成も REXML でいってて、REXML で作ったものを REXML で解釈して、そのまま XPath で抜き出して処理していたんだけど、凄く遅くてビビりましたよ(笑)　バグじゃなかろうかと思うくらい遅かったんだけど、原因がわかったと。

ささだ

ふむふむ。

江渡

element.parent = って書いてあるところが、単なるアクセサじゃなくて、@parent というところに代入してから、元の parent から自分自身を探して削除するという処理を含めていたんです。なので、50 個くらいの TextFormat というちょっとした長さのページから、一部分を変更して作りかえるという処理を実装したら 5 秒くらいかかって、調べてみたら一つの処理に 0.5 秒くらいかかってる。で、parent = となっているただの代入だと思っていたところでそんなにかかっていて、ありえないだろと思ったら、元の親から自分自身を探して削除するソースが入っていて、でも、オブジェクト自体は再作成されているわけだから、自分自身が見つかるはずがないんです。ということは、あるはずのないものを毎回全部探してなめているわけで、だからそんなに遅いわけで、それを外したコードを作ったら割と素直になったんだけど、やってられねえと思って全部書き直して、だいぶ幸せになれました。

ささだ

じゃあ、そちらは速いんですか。

江渡

いや、速いとは言い切れないけれど遅くはなくて、自分で全部制御してるから。

ささだ

XML を、配列とシンボルの組にしていると。

江渡

そうです。

田中

それは、親を持ってるのがいけないんですかね。

江渡

そう。デザインとして、親から子へのマッピングを 1 個にしようとしていたのが間違いだと思うんです。たとえば、1 個の XML の Tree と XML の Tree があって、片方を移植するってことができていいんだけど、そうすると Tree の繋がる先が 2 個になってしまう。それは嫌だから、REXML の作者は元のマッピングを削除することを考えたわけだけど、それは余計だった、と私は考えているんですけど。

田中

親って普通一個なんですよ。これは関数型言語ではとても問題で。

江渡

そうなんだ。

田中

だって、親から子にいけて、子から親にいけたらサイクルになるじゃないですか。サイクルがあると、関数型言語でボトムアップに作れないじゃないですか。後から書き換えるとなると、これは破壊的代入が大体において必要になるんですけど……何故親があるかという話は、DOM とか XMLInfoSet とかに起因するんですが、W3C の規格において、XML の情報セットというのは親があるんだ、となってるんですね。だから、その通りに作ると親ができて、だからサブツリーというのは、同時に二つのところには入れない、だから他のところに入れようとすれば元のところから消さないといけないし、ということだと思いますね。

江渡

逆に言えば DOM のバグということだよね。

田中

そう。

江渡

DOM の設計がまずかったということだね。

田中

親が何故必要か、というのは調べたことがあるんですよ。getParentNode というメソッドを Google で検索して、DOM のマニュアルが一杯ひっかかるんですが、それ以外にどういう用途で使われているか調べたんですが、そのサブツリー自身を消す時に使われてますね。それを消す時に、親へのリンクがないと消せない。

江渡

そりゃそうだ。

田中

他には、他のノードと入れ替える、そのノードの直前に追加、とか。

ささだ

sibling とか。

田中

sibling 系は上に行って下に行かないとダメだから。兄弟に追加とか、兄弟の末尾に追加とか、兄弟を調べるとか、あるいはそのノードの場所を示す XPath を作る。root ノードを得る、JavaScript で、Script を書いた要素からいくつか上の要素を得る、TR が TABLE の何番目かを調べる、Draft 要素の中かどうかで処理を変える、DFS的に直前直後のノードを得る、とか、いくつかあるんだけど、後は子ノードに自分を追加しないように確認する。子供は一杯あるから探すのが大変なんだけど、親は一直線だから簡単に調べられる。というわけで親が必要な理由が無いわけじゃない。まあ、破壊的にやらなければいいじゃん、というのはあって、まあ良し悪しなんですけど。まあ、俺は無くしちゃったけど。

ささだ

HTree³⁶ から？

田中

HTree は親をもってない。

江渡

ロケーションオブジェクトとして処理しているわけですね。

田中

そう。あのデザインはちょっと煩雑なので、あれはあれであまり良くないかなと思うけど、一つの挑戦ではあります。親の話は難しいですね。

ささだ

REXML は、遅いという話はありますね。ちょっと使おうとすると大変、という。

江渡

まあ、ありがたいんですけどね。XPath も使えますし。

ささだ

遅いというのが不満ということで、では良い点は……。

江渡

色々あるというか、遅いという点以外では全部いいですね。だって、不満といわれて遅いのしか思い浮かばないわけだから、他は全部良いということになるじゃないですか。

田中

さっき Hash の話してたけど (笑)

ささだ

ところどころ疑問はある、と。

江渡

ところどころはありますね。

ささだ

おおむね良い、と。

江渡

そうですね。(取り立てて良い所を挙げるのは) うーん、難しいなあ。

田中

まあ、気に入らないところは使わないしね (笑)

ささだ

(笑)

江渡

言えてる。やっぱ Python でちょっとこれは、と思って来た経緯があるわけだから、何かしらこっちが良いっていうのがあるんだろうね。

ささだ

やっぱり階段 (笑)

江渡

階段、てのもあるんだけど、@ かなあ。Python の self. ってのが慣れなかったなあ。

ささだ

Python って self. を強要するんですか？　これからは Ruby でも self.XXX と書かなければいけなくなるかもしれませんが。

江渡

なんで？

ささだ

まつもとさんがそういう風にしようとしているので。いや、インスタンス変数が、ではないんですけど、オーバーライドされるかもしれないメソッドは self.XXX で書かないといけないかも、という議論がありまして。

江渡

なるほど。

ささだ

まあ、それはちょっと横道に逸れすぎるというか、次の田中さんの時にでも聞こうかなと (笑)

江渡

多分細かい話なんだけど、よく悩むというか、なぜこうなるんだと思うことは一杯あるんですけど、attr_accessor :XXX とやると、アクセサが定義されますよね。

ささだ

ええ。

江渡

それに public とかつけたいじゃないですか。多分 Java から移ってきたりすると「なんでこれに public とか private とかつけられないんだろう」と思うと思うんですよ。……今だと「ああ、これは多分わざと使い難くしてるんだ」と考えられるようになったけど、最初の頃は全部 attr_accessor とか attr_reader とかやって「なんでこれ簡単に (アクセス制御を) 書けないんだろう」って思うことが多いし、実際僕は思ってましたね。最近、少し達観してきた。

ささだ

これがですね、私みたいな言語処理系に興味のある人間からすると、メソッドと変数は全然別のレイヤーなので、こうなるのが普通かなあ、と。

江渡

そうだよね。

田中

そういうことなら、いちいちメソッドを定義するんじゃないの？　@XXX とか使わずに。

ささだ

だから、メソッドを定義する attr_XXX って楽じゃん、という。要するに、(attr_XXX で定義するのは) 変数にアクセスする何かじゃなくてメソッドですよね。だから、その時点で public で当たり前。

田中

まあ Python の流儀だとメソッドもインスタンス変数もどっちも同じですけど。

ささだ

ああ、そうか、インスタンス変数は特殊だってことだ。

江渡

Java とかで、public をつけると外から変数が操作できるっていうのがおかしいってことですよね？　そんなことはない？

田中

まあ、Java でそれ (public なインスタンス変数) は良くない、ということにはなってますよね。

江渡

アクセサを、Java だと get_XXX、set_XXX とかするじゃないですか。アレは馬鹿ですよね (笑)

田中

うん。それは、なんでそうするかというと、中身の実装を変えるためなんだけど。

江渡

意味ないよ。

田中

うん。たとえば Ruby だったら、これは ‘Eiffel’ も同じなんだけど、変数の参照の形式と、メソッドの形式が同じなんですよね。だから Eiffel で主張されてるんだけど、変数だったものがメソッドになったり、メソッドだったものが変数になっても、クライアント側は変えなくていい。だから余り気にしないんだけど、Java だとそれができないから、get_XXX を作れ、ということに。

江渡

だから、Java が嫌いになっちゃったんですよ。かなり前の話に戻るけど (笑)　それで、もうだめだと思って次の言語を色々漁っていって、Ruby に辿り着いたわけです。

江渡

Ruby は当たり前のことが当たり前なんです。1 とか 2 とかがオブジェクトだ、とか。まあ 3.times っていうのはちょっとどうかと思うけれど (笑)　あとは演算子オーバーローディング。Java だと演算子オーバーローディングが使えないから、複素数でさえ + 演算子が使えないじゃないですか。というわけであらゆることが「こんなもの捨ててやる」ということで Java を捨ててここに来た、と。

田中

成熟してくると、プログラマをちょっとは邪魔したくなるものなんですよ、言語屋は。C++ で演算子オーバーローディングで乱用が問題になって、じゃあ (Java では) 無しにしよう、と。Ruby でもたまに、さっきの self. をつけるほうがいいじゃん、と。メソッド呼び出しについて。

江渡

前、できなかったよね。

田中

できたんだけど……

江渡

private だと付けられないよね。

田中

それ 1.6 の話。

江渡

1.8 だとできるの？　知らなかった！

田中

できます。中田さん³⁷ が直した気がする。

江渡

あれ、バグだったの？

田中

いや、仕様だったんだけど、キーワードなメソッドについてはそれはできないじゃないですか。class って書くとキーワードになっちゃうから。

江渡

本当だ。

田中

その時のために、self. を付けて呼び出せるようにしましょうっていう話が出て、直ったんです。

江渡

そうだったんだ。

田中

それはともかくとして、ローカル変数と自分自身のメソッドは区別つかないじゃないですか。だから、やっぱり区別を付けた方がいいよねっていうのは、一つの合理的な案ではあるわけです。そっちのほうが良いかなあというほうに傾くと、プログラマを邪魔することはたまにあるんじゃないですかね。まあ、邪魔をすると恨みを買う場合があるので (笑)　だから、恨みを買わずに最終的に良いバランスにするためには、最初に簡単にしすぎないことが重要ですね (笑)

ささだ

でも、最初に簡単にしなかったら誰も寄り付かないじゃない。

江渡

そうそう。

田中

だから、迷う時にはやりすぎないこと。特に Ruby でいえば、オペレータのメソッド仕様については気をつけるべきですね。つまり、オペレータって、限られてるので、「これでいいじゃん」と思って割り当てると、後で思い直したときに変えるのが非常に痛い。たとえば、CGI のアレとか (笑)　CGI がオペレータをとる時に配列を返すんだけど、昔はね。でも、最初の一個がいいなあと皆思ってたんだけど、結局今移行にトラぶってるわけですが。

江渡

必ず後ろに [0] ってつけなきゃいけない奴でしょ？

田中

昔はそうしていたんだけど、嫌だよねってことで最終的には最初の一個、もしくは nil を返して欲しいっていう仕様になって。これどうやって移行したらいいの？　という話になっていて。まあ、これの問題はメンテナが消えてしまったということもあるんだけど(笑)

江渡

誰？

田中

青山さん³⁸。まあ、その辺はレイヤーが違うんだけど。もっと早く移行すれば、たとえば開発版の 1.9 ではそうすればいいじゃんと思うんだけど、Go という人がいないから、中途半端なままになってるんだけど。

ささだ

言語仕様というよりは、本当にプログラミング一般の話だよね。

田中

でも、言語仕様というかどういうスタイルをお勧めするかっていうのは非常に重要な話で、たとえば、気になるのは class を何回も宣言するとして、スーパークラスを指定するのは最初の 1 回だけでいいじゃん。これって非常に微妙で、毎回同じものを書くという仕様もあるわけです。このどちらがいいかは微妙で、たとえば違うファイルに書いてあって、require で読み込む順番が違うと、最初のクラス宣言が読み込まれていないとこれは継承してないオブジェクトだ、ってことになってしまって、他のを継承しているとエラーが出たりしてしまう。そうなると、全部書いていたほうがいいじゃん、と。

江渡

継承しなけりゃいいじゃん (笑)

ささだ

継承はしないんですか？

江渡

継承はしなくなりましたね。include するようになりました。

ささだ

へえ。

田中

なんか痛い目にあった？

江渡

痛い目にはあってないけど、なんとなくコードをスッキリさせようと思ったら include を使うようになりましたね。

田中

まあ、どこまでやるかということだけど。そうすると、module に穴が開いて他のメソッドなりインスタンス変数なりの存在を仮定してしまっている場合とかに、共通部分だけでは動かないじゃないですか。たとえば、Enumerable みたいに、each が抜けてるとか。

江渡

もうちょっとね、プリミティブなのが多いな。qwikWebの構造で言うと、ページジェネレータってのがあって、EditPage ジェネレータ、ViewPage ジェネレータとかあるわけです。でも、読み込むスタイルシートとか JavaScript は大体どれも一緒。そういう時に、JavaScript についてのメソッドを加える module を作って、それを include する。そういう感じの使い方ですね。

ささだ

それはまあ、普通の module の使い方ですね。

江渡

最初はベースのジェネレータを作って、皆それを継承していたんだけど、何となく直していくと、InitPage と MessagePage だけはこのメソッドを使うけど、他は使わない、みたいなのが出てきて、段々混乱しちゃったんです。それで、全部モジュールにしてバラバラに分割していくと、スッキリ書けてよかったね、と。なんだか当たり前のことを言ってるね(笑)

ささだ

いやいや、ちゃんと自分で作らないと分からないですよ。

江渡

なんだか楽しいですよね、Ruby。割と初期の段階で「ああ、オブジェクト指向わかってなかったんだ、俺」って、オブジェクト指向がわかるようになって。

田中

手軽に楽しめるっていうのが。

江渡

最近、クロージャがなんだかわかってきた。クロージャとブロックの違いがよくわかってなくて、変数のスコープを引き継げるのが良い所じゃないですか。それがよくわかってなかったんですよ。

江渡

JavaScript で同じことをやろうとして、無名関数を書いて処理として渡して実行すると、当然ローカル変数は使えないんですよ。

ささだ

使えないんですか？

江渡

使う方法もあるんですけど、一番簡単なのがグローバル変数を使って処理させる方法で、poor な書き方だとそうなるんです。そうじゃない書き方もあるんだけど、ああだから Ruby が良かったんだ、っていうのがようやくわかってきて。

田中

そういう風に面白いのに、何故 Ruby は色々とスコープが切れることがあるのか、という(笑)　class でも切れるし def でも切れるし、そうすると見えない (笑)

ささだ

それは……なんだかんだいって Ruby は複雑なんですよ。だから「言語の設計者さえ仕様を把握していない言語はダメだ」とか言われちゃったり。

江渡

なるほどね。

ささだ

JavaScript はすっきりしているし、あれはあれで良い言語だと思いますけど。

便利な Ruby ライブラリ

ささだ

話がずれてしまったので戻して、Ruby のアプリケーションやライブラリで、自分で使っていて便利だなあというものはありました？

江渡

WEBrick³⁹。WEBrick は良いですね、あれは楽です。僕はあれを使っていて、ソースも結構参考にしました。フレームワークとか Web アプリの書き方とか結構良い感じで。

ささだ

じゃあ、Ruby をはじめる人はまず WEBrick を見ろ、と (笑)

江渡

割りと近い (笑)　大きなものを書くときには分け方とかあんな感じになっていると良いと思う。

Ruby の習得

ささだ

Ruby の習得は簡単でしたか？　何か引っかかったところでもあれば。それともすんなりできたとか。

江渡

うーん。

ささだ

Ruby の前に Python をやっていれば簡単でしたかね。概念を置き換える感じで。

江渡

その頃は Python もわからないまま使っていたから。Java は何となくわかっていて、でもさっき話したようにオブジェクト指向とはなんぞやとかはわかってなかった。あとは Perl を使って、Perl は Perl らしい使い方をしていて (笑)

江渡

最初に気になるのは「なんで end で終わるんだろう？」とかそういう細かいところなんですよ (笑)　なんで大括弧じゃないんだろう、って。

ささだ

なるほど。

江渡

別に、Python を理解していたわけじゃないんですよ。

ささだ

じゃあクラスとかも後から。

江渡

何をクラスにするかとかは、Ruby を習得する過程でわかってきたことです。逆の言い方をすると、最初にもう少しわかっていたほうがよかったのかなあ、と。その頃テストっていう考え方を理解していなかったから、最初からテストがわかっていれば、もう少し幸せな人生が送れた気がする (笑)

田中

その頃は、簡単に使えるテストユニットのライブラリはなかったんじゃないかなあ。流行ったのはもっと後だから。

インターネット物理モデルと Ruby

:

江渡

なかったね。でもまあ、あったかもしれないけど、全然知る余地はなかった。2001 年にインターネット物理モデルとか作ったんだけど、そのときに Ruby を使ったんです。Ruby でガリガリ書いていたんだけど、所謂「プログラム」だったんです。書いて、Run して、「ああ動いた」っていうのを繰り返してたんだけど。インターネット物理モデルは大変だったんですよ。1m くらいのタワーが沢山並んでて。タワーの裏側に PIC を積んだ基盤が見えない形で付いてて。

ささだ

PIC って FPGA の弱い奴？

江渡

そう。それで書かれていて、それぞれが I2C っていう仕様のバスで繋がっていて、電源とグランドと信号の 3 本しか (配線が) 無いんですね。3 本だけで通信ができる、と。それが I2CtoUSB というちっちゃい基盤に繋がっていて、USB か USB ハブに対応して、一つのマシンに繋がっている……そういうモデルだったんです。

ささだ

いや、観に行ったんですよ、あれ。凄い面白いですよね。

田中

僕も行きましたよ。残念ながら壊れててさ、あれ。ルーター間の通信ができなかった。1 台だけだったら動きましたけど (笑)

ささだ

行って帰って？

田中

いや、localhost に Ping してた (笑)

ささだ

来館してたお子さんたちが喜んでましたよ。

田中

ちょっと説明員の人がナニなところがあった。「これ、ASCII 規格なんですよ」っていうから行ってみたらハートマークがあってさ (笑)

ささだ

ASCII で何？

田中

いや、あれさ文字選べるじゃない、それで「ASCII の規格だ」っていうから見てみたらハートマークで、それは違うんじゃないか、と (笑)　まあ本質じゃないからいいんだけど。

ささだ

私は結構説明員の方はきちんとしてると思いましたけどね。「ちゃんとルーティングしてますか？」って聞いたら「ルーティングしてます」って言われて、ああ、ルーティングって言葉が通じるんだ、と (笑)　ところで、もっと複雑なもので制御しているんだと思ってたら、全部色で制御していると聞いて感動しました。

江渡

あれは玉を途中でパッと止めて色を入れ替えたりすると、違う方向に行く。更に、これは裏技なんだけど、タワーにルーティングテーブルみたいに色で表示する仕掛けがあるじゃないですか。こういう風に白と黒のボタンがついていて、この色のパターンはこっち、この色のパターンはこっち、みたいに表示させているんです。

江渡

たとえば白黒白みたいになっているとこっちというのを、ひょっと引き抜いて白と入れ替えると、その時点でルーティングテーブルが書き換わる。

ささだ

あのセンサー自体は、専用の？

江渡

あのインジケーターの裏側で色をセンスしていて、インジケーターであると同時に入力デバイスになっている。

ささだ

ああ、なるほど！

江渡

あれは飾りじゃないんです。だからあの上にインジケーターとして付いている白と黒の色と、下を通る色を見て、一致していれば通す、という形でルーティングしている。

ささだ

通すかどうかの情報が、メインのマシンに入ってる。で、8 つのアドレスを見て、こっちかあっちかをマシンが返して、開くか開かないかを決めている、と。

江渡

そうです。ちなみにネットワークルータとローカルルータと呼んでいるんだけど、ネットワークルータは先頭 4 ビットしか見ない。

ささだ

ああ、そうでしたね。

江渡

だから IP アドレスが 8 ビットだとすると、先頭 4 ビットがネットワークアドレスで、後半 4 ビットがローカルアドレス。

ささだ

見ました見ました。なんでセンサーが 4 つしかないんだろうと思ったら、（説明が）上のほうに書いてあったような気がします。

田中

聞き逃したかもしれませんが、あれに Ruby をどう使ったんですか？

ささだ

あ、そうだ。

江渡

話すと長いんだけど、半年くらい制作期間があったんですね。2000 年の 9 月になんとなく話があって、12 月に「じゃあやるべか」ってことで、「何やろうか」って話になって、「じゃあ物理モデルやろうよ」ってことになって、地獄の行進が始まったわけですよ (笑)　それで翌年の 7 月になって、当然まだ動いてなくて (笑)、動いてないならまだしもセンサーが動いてるかどうかの確認もできていなくて。ソフトウエアはできていることになってるんだけど、ソフトウエアも実をいうと PIC で書いていたんですよ、動作制御の。で、書いて取り付けて、動くはずのプログラムなんだけど動かないねえ (笑)　ってのが続いて 1ヶ月たって、じゃぁ同時並行でこっちでも実験してみるからってことにして、テストプログラムから順番に書いていった。何となく白と黒とがまずはとれるようになって、とりあえず 1 台動かすっていうことでプログラムを書いてみるねってことで書き始めめて、段々動かしていって、全部動かした、と。

ささだ

そのプログラムが Ruby だったんですか？

江渡

そうです。

ささだ

今も Ruby なんですか？

江渡

そうですよ。

ささだ

へえ……

田中

良くわからないんですけど、動くはずのプログラムが動かなかったから、代わりのものを書いた、と。それってどこに載ってるの？

江渡

地下にケーブルがあって、横のところに小屋があって、そこに PC があるんです。

ささだ

そこに普通の PC/AT 互換機が入ってる？

江渡

ノート PC ね (笑)　しかも Windows 98 なんですよ (笑)

ささだ

Windows 98 なんですか。98 の上に Ruby が。

田中

疑問に思ってたけど、PC があるなら Ruby が動いてもおかしくないな。

ささだ

PIC の上で動いているんだと。

田中

そうそう (笑)　それはありえないので。

江渡

そこまで移植してたら神です (笑)　それはないよ。

ささだ

今でも同じプログラムが動いている、と。

江渡

そうですね。そういうわけで、ボトムアップで開発したからぐちゃぐちゃで。本当はロジックがあるじゃないですか。玉が来て、入って、何秒後にきて、これとこれが一致してたら通してっていうのがあって、センサーとロジックで分ければロジックだけ動作テストっていうのができるじゃないですか。

ささだ

はい。

江渡

そういう概念がなかったから、一々動かして。

ささだ

プログラムを動かすたびに動かして (笑)

江渡

そう。おまけにちょっと動かす場所が遠くて (笑)

田中

つまり、今風に言えばセンサーの MockObject があればよかった。

江渡

そう。それを作って単体テストができればよかったんだけど、人間がやってるから (笑)。「ちょっと、次白白黒ちょうだい」とか (笑)　それで並べてゴロゴロって……。

田中

データベースのテストが大変だってどころの話じゃないですね (笑)

ささだ

本当に走らなきゃ (Run) いけないという (笑)

江渡

あの現場では怪我人続出で。こういう風な柱とかがあって、あれをくぐったりして中まで入ってテストして、くぐる時ににガンて背中を打って、ほぼ全員が怪我をしたんだけど、僕だけ大怪我はしなかったなあ。

ささだ

外でテストしたってわけじゃなくて、その場で作ったという。

江渡

勉強になりました。

テストとアート

ささだ

テストって、先ほど見せていただいたようなアートのようなものでテストというのはあり得る話なんでしょうか？

江渡

考えましたね、昔。当然見た目も含めてテストというのはあり得ないわけで。こういう風にしたら絵が出る、と。その絵が綺麗か綺麗じゃないかで判断する、っていうレベルではテストはあり得ないんだけど、変更するとどうも動かなくなってしまうという可能性はあり得ますよね。それに関してはテスト可能じゃないかと思ったことがあって、たとえばマウスを動かすと何かが出るってことだったら、マウスの動きを記録しておいて、それを再現するようにすれば、少なくともプログラムが途中で止まっちゃうかどうかはテストできますよね。でも、いわゆる単体テストのレベルでは難しいというか意味がないですよね。

ささだ

では、芸大ではテストは教えない、と。

江渡

今のところ無理ですね。でも、プログラマを養成する学校だったら、テストは教えるべきだと思いましたね。

ささだ

でも、人にテストをやれやれと言っても、テストをしないんですよ、奴らは。

江渡

かもしれない。重要性がわからないからね。彼らは。

ささだ

「あんなの面倒くさいだけじゃないですか」とか言って。

江渡

ささださんも教えてるわけだ。

ささだ

ええ、まぁたまに。

美しいソースコード

ささだ

では、Ruby の習得はそんな感じで、では、美しいソースコードって何か記憶にありますか？　さっき WEBrick の話が出ましたが。

江渡

Ruby に限って？

ささだ

いえ、何でも構いません。

江渡

全然違う文脈だけど、Befunge⁴⁰ って知ってます？

ささだ

いえ。

江渡

Befunge ていうプログラミング言語なんだけど、冗談プログラムの一種で、2次元プログラム言語なんです。2次元ていうのは Python みたいなのじゃなくて、プログラムソースが回路図みたいになっているというと、わかりやすいかな。

ささだ

こっちいったり、こっちいったり。

江渡

そうそう。で、v っていう記号とか < > で下行ったり右行ったりするっていう、とかいうのがあって、そういうプログラミング言語があって、そういうのが好きで調べた時期があって、そういうソースコードって良いですよね (笑)　で、そういう話をしていたら、これはまだ言ってなかったんだけど、僕は 2002 年に産総研に移ってきたんだけど、それまでは国際メディア研究財団⁴¹ というところにいたんです。そこはメディアの研究をやる専門の研究所で、きわめて珍しいところなんだけど、メディアの研究といいつつ、作品をガンガン作っていた、ということなんだけど。そこで一緒にやっていた杉原君⁴² という人がいるんだけれど、ColorFL⁴³ というプログラミング言語を作ったんですね。それがドット絵みたいな感じで色が並んでいて、色が何色かっていうのがプログラムの 1　コードに対応する、というようなもので。上のほうに変な色が並んでいるだけで、なんだろうと思ったらカーソルがスーッと動いて、(ドット絵が) 解釈されて形が書かれる、という。『チューリップを書くコード』、なんて書いてありましたね (笑)

田中

ライフゲームの拡張っていう感じかな？　違うか。

江渡

パッと見、近いけど、ニュアンスとしてはメモリダンプ、16進メモリダンプってあるじゃないですか、アレに近い。

田中

コアウォーズ？

江渡

そう、コアウォーズに近い。

(コアウォーズ実演中)

ささだ

これ (コアウォーズ) はプログラミング言語なんですか？

田中

言語というか、メモリ空間なんです。MOVE とか、スレッドじゃないんだけど FORK とかあって、そういうプログラムがいくつかあって、ポジションインディペンデント型の言語なんです。だから 2 つ以上作って同時に動かすわけ。メモリに書き込んむんですが、ハーバードアーキテクチャじゃないので、プログラムにも書き込めるわけです。で、上書きして相手を殺すゲーム。

ささだ

へー。殺すプログラムを書くのが。

田中

うまく殺すプログラムを書くのがゲーム。ポジションインディペンデントだからどんどん逃げていくわけだけど、これも結局プレーヤ毎に色が違っていて、どっちかの色一色になれば勝ちという。

ささだ

自分の色は決まってるんだ。

田中

そうですね。

ささだ

塗りつぶして喰っていく戦略なんですね。

田中

それが基本なんだけど、他にも色々あって、複数に分けたりとかいろいろ。

ささだ

ソースコードでアートってイうのはそんなには多くないですか。

江渡

そんなにはないんだけど。

(ColorFL の画面)

江渡

こんな感じの画面になっていて、これがコマンドのヘルプで、これがプログラムなんですね。で、順に解釈していって、ペンを上に上げるとか、右に一個進めるとか、前の動作を繰り返すとかペンの色を選ぶとか、そういうのが書かれていて、上にいってある動作を繰り返して、下に行って、ということが書かれている。で、Run を選んで実行するとこれがこうして、こういう絵が書かれる。

ささだ

なるほど。

江渡

これが書かれた結果のイメージで、この絵はもともとなかったわけ。それが実行されると、この絵が描かれる。メモリ空間がキャンバスにもなっていて、一回実行されると二度と実行できない。もう一回実行するとバグるわけ。

田中

ライフゲームの美しさはないなあ。

江渡

そうなんだけど、スタックがここにあって、そこに自分自身を積んだりとか色々な処理ができる。

ささだ

なるほど。

江渡

このアートビットコレクションていう展覧会⁴⁴ は、僕がキュレーションした展覧会なんです。色々なこういうちょっとプログラム的にも面白くて、アート的にも面白いものを集めて展覧会を開いたら面白いんじゃないかという話があって、そういうことを 2002 年にですね、やってました。

Art と Programming

ささだ

ところで、プログラミングとアートにつながりはありますか？　という質問が来ていたんですが。

江渡

誰の質問なんですか？

ささだ

わかりません。編集 Wiki に書いてあって。

江渡

プログラミングとアートって、言葉のレイヤーとしては違いまくるよね。なんだろうな。ささださんが質問者じゃないから想像して答えるしかないんだけど、「めちゃくちゃ関係あるんじゃないんですか」。そうなんだよね。考えてたんですよ実を言うと。一個、大変適切な例を発見したんだけど、リチャード・ストールマン⁴⁵ が「ハックとは何か」という文章で、「ハックとは何か」を説明するときに一番最初に出している例がジョン・ケージ⁴⁶ の「4分33秒」っていう曲なんですよ。それってご存知ですか。

ささだ

はい。

江渡

まったく音を出さないで 4 分 33 秒続くだけなんだけど。ある意味ハックとは何かというのを説明するのにその比喩を真っ先に持ってきたというのは、ハックとアートの関わりを如実に表しているのではないかと。

ささだ

へぇ。

江渡

でもねぇ、凄くむずかしいのは、その話をしようかなと思った後に考えたのは、「でもそれってハックじゃないよ」と思って。それはジョン・ケージがハックをしたとストールマンは言うんだけど、それはハックじゃなくて作曲なんですよ。あくまでも。それは芸術作品である曲っていうものを作曲するっていうことであって芸術の創造行為なんですよ。それはハックじゃない。で、それはストールマンがハックという側面でそれを見たいと言っているわけで、本来違うもの。ジョン・ケージがしたのは作曲なんですよ。

ささだ

ふむ。

江渡

じゃあ本質的にハックとはなんだろうか、ということなんだけれど、もう一個質問とつなげると「プログラミングとハックって関係があるんだろうか」ということになる。これも難しい話なんだけど、プログラミングそのものは結構ジェネラルな言葉で、企業がつまんねープログラミングをするのもプログラミングだし、なんかものすごいことを書いちゃって世界を変えるようなことをするのもプログラミングだし。ある程度ジェネラル。それと、アートの関係は結構難しいと思う。でも、ハックとはつながりが深いと思いますよ。ただ、同一のものではない。

田中

つまり、アートとハックは似ている、と？

江渡

そう。似てると言わざるを得ない。逆の言い方をすると、ハックを説明するときにまず最初にアートの例が出てきたっていうのはハックの説明のしづらさっていうものだけではない何かつながりを感じる。でも、プログラミング一般まで話を広げると難しいよね。プログラミングとしての一場面として、アートとしてのプログラミングがあり得るか、というと、そりゃあるでしょう。というか、僕はあると思いたい。Befunge とか僕大好きだとさっき話しましたけど、そんな感じで一個のプログラミング言語そのものが表現としかいいようがない特殊性を備えているというのがたまにあり得て、そういう現象は凄く大好きですね。同じように、言語としては C とか Ruby なんだけど、アートなのかもしれない。たとえば IOCCC⁴⁷ とか、Ruby でも最近あった⁴⁸ けど、そういうものとかはかなりアートですよね。でも、現実問題としてのアート、たとえばマーケットからみるようなアートは当然ながら、取引され得るような絵画としてのものだったり、映像というメディアだったり、徐々に幅が広がってインタラクティブアートとかも含まれるようになってきたけど、まだまだ少ない。ということで、いわゆるアートといわれるものとは距離があるけれど、でもアートとしか言いようがないものってのがプログラミングの場面にはあると思う。それは間違いないと思う。

田中

そういうものを求めて、この前和田先生の聞きにいったの？

江渡

ちょっと求めていった。そしたら全然違ってさぁ。

ささだ

思い出話が多かったですね。

江渡

しかも全然つまんなくてさぁ。

田中

append には美しさは感じない？

江渡

そういう話あったっけ。

田中

Scheme の append は完璧なプログラムだって言ってましたが。

江渡

あれは難しいよねえ。ただほんとに微妙な差異なんで。実際、アーティスト側と制作活動をどうするのか、そこに関わる問題はなんぞや、という問題があって難しいんだけど。結局泥臭い、こまごまとしたことをしなくちゃいけないわけですよ。それこそ OpenGL でウィンドウ出すには、とかそのときにスピード出すには、とかいろいろあるわけですよ。そこで尊敬する人もう一人の話になって、枯れた技術をうまく使うのがいいんだ、という話になるんだけど、そうすると先端技術ですらなくなって、じゃぁどこにアート的なものが出てくるんですかって聞きたくなるんだけど、そういう話をすると、和田先生の話って単なる知恵みたいなものに思えるんだよね。

田中

知恵。

江渡

なんかこう、美とは何か、美しいとはなにかっていうことと、アートとは何かっていうことと、実をいうと全然関係ないことであって、根本的に切り離されるべき問題なんですね。でも、とはいえ実をいうと、美というものから芸術がスタートしていることは間違いないわけで、重要な一部分ではある。てことなんだけど、美学というものと芸術というものをごっちゃにして語っているものが結構あって、すっきりしていて美しいからこれは芸術だ、みたいなことを言ったりすると、バカヤローとか言って殴りたくなるんだけど、じゃぁ何が芸術かってのはほんと曖昧模糊としてわからない。で、一個の言い方は、人生とは芸術であるって言い方で、一個単体を取り出してきてこれは芸術である、と判断する外形的な手法はないんだけど、それに対してその人がどう向き合ってきたか、どう向き合い続けていて、その人の一生を通してみて、それがそのときにどんな存在であったかを通してみると、ああそれは芸術なのかと言うしかないというのがある。もう一個は、芸術とは何かということを再定義することを芸術であるというメタな議論があって。

田中

(笑)

江渡

それはそれで面白いんだけど。いささか技巧的に過ぎる。ゴードン・マッタ＝クラーク⁴⁹ という作家がいて、建築家だったんですね。でも凄いアーティストで。で、いろんな方法論があるんだけど、かなり消滅の美学なんですね。だからまったく作品が残らないんですね。彼が作った作品で凄く面白いものの一つは、家があるんだけど、真中で真っ二つで切れてる。だから家の中に入ってみると、床がピーっと切れていて、外が見える。そんな作品を作ってる。で、それはなんの変哲もないように見えるけど、それを作るには物凄い腕が必要。

田中

わかります。

江渡

倒れないようにしつつ全部切れている。

江渡

壊す予定だったからそういう作品を作ったわけだけど。なんかあの、なんとなくそれってハック的だよね。でも、それはやっぱりアートなんですよ。ハックじゃなくて。それがなぜかわかるのは、彼の人生を通してみて、建築というものを彼が非常によく知っていつつも、しかしある建築を作るということに力を向けただけじゃなくて、破壊という形で表現を成立させた。建築って建物ではなくて、そこに暮らす人との関係性で成り立つってことから、彼はそれを作ったわけですね。真っ二つに切れた家というもので、そこに暮していた家族が、同じ家に住んでいたけれども認識は二つに切れていたということを表現しているわけですね。

田中

それがハックではない、というのは？

江渡

それがハックではないというのが、彼の人生を通してみたとき初めてわかる、と。

田中

たとえば、唐突に思いついて作ってみた、ちょっと苦労した、というのはもしかしたらハックかもしれない。

江渡

ハックとはいうことはできるけど、アートということはできないねえ。アート的といってもいいかもしれないけど。

田中

ハックというイメージはなんか思いついて、いじくりまわしてみる、みたいな。

江渡

たまたま結果が同じだったと。でも、たまたまジョン・ケージよりも前に「4分32秒」とかいう作品を作ったとするよねえ。

一同

(笑)

江渡

それはなんか思いつきで作っちゃってたとするよね。それはでも作曲でもないし、芸術でもない。それは違うものだっていうことは強調したいですけど、関係がある。

田中

真剣に向き合ってるかっていうことかなぁ。

江渡

すごく平たくいうとそうなるんだけど。でもそうすると「真剣に向き合えばアートができるんだ」と思っちゃうと、そうではないのでまた話がややこしくなっちゃう。

田中

(笑)

ささだ

まぁ、Rubyist Magazine なんで。たとえば Ruby を作ってるまつもとさんの活動はアートですか？

江渡

すっごい微妙な質問だけど、僕はアート的なものを感じてるけどね。

ささだ

あ、あれはアート、という基準になる？

江渡

いや、断言しようとも思わないし、それがとくに影響与えるとも思わないから言うけど、アート的だなぁ、と思いながら見てますけどね。何が重要な点かというと、まつもとさんは形式的に判断したりしないじゃないですか。たとえばあるプログラミング言語で、BNF で記述すると非常にに短く書けるので、このプログラミング言語は理解しやすい、という主張を目にしたことがあるんですけど、「馬鹿かお前は」と言いたくなるんだけど。関係ないって思いっきり言いたい。あの、えてしてそういうふうに形式的に割り切りたくなるんだけど、まつもとさんは絶対そうしないじゃないですか。それが偉いなぁと思っていて、すごくアート的な感じを受けますけどね。

田中

BNF なりなんなりで書けないと、理解しきった気になれないじゃん。アカデミック的な都合でいうなら。

江渡

人はたいていのものを理解してないんですよ。

田中

理解しきったものだけを扱う世界もあるんで。アカデミックな、下から積んでいくような。

江渡

そうですねえ。そうしないと壊れちゃったりするからねえ。

田中

(笑)

江渡

さっきの家の話でもそうだけど、家とか下から積み上げていくから土台が壊れたら壊れちゃうじゃない。そういう世界でアートをやるのって超困難なんですよ。だからアート的な建築っていっても建築基準法は必ず満たしているわけですよ。

ささだ

(笑)

江渡

そういうこと考えると、技術とアートの関係って曖昧なもんだなぁと思いますね。

ささだ

なるほど。なんとなく『‘The Art of Computer Programming’』みたいなものもあるし、あれはアートなのかな、と思ってたんですが。

江渡

そうそう。それもついでに言うと、関係ない、ってことで強調させてください。

ささだ

あれは名前がよろしくない。

江渡

もう一つ言うと、英語と日本語の art という言葉は全然意味が違って。技芸とか技巧と本当は訳すべきで。芸術として訳される art も結構ある。

ささだ

はい。

江渡

artist という言葉もわりとそうで、うちのお母さん artist なんだ、と子供が言うときに、お母さんがやってるのは毛糸で編物してることも結構ある。ということで、職業としての artist も結構ある。art という言葉を受け取ったときに、芸術としてのプログラミングと受け取っちゃうというのもあるし、もし万が一 Knuth⁵⁰ が芸術という意味を意図しているのなら、それは違う。読んでないからわかんないけども。

ささだ

なるほど。

江渡

まあ芸術としての、とは意図してないんじゃないかと推測してるけど。

（後編へ続く）

途中で

これだけでも十分長いんですが、後編はもっと長いです。後半では江渡さんご自身についてのお話をお届けする予定です。お楽しみに。

(インタビュー: ささだ、編集:伏原、卜部、西山、早川)

Rubyist Hotlinks 連載一覧

• Rubyist Hotlinks 【第 39 回】古橋貞之 さん

• Rubyist Hotlinks 【第 38 回】国分崇志 さん

• Rubyist Hotlinks 【第 37 回】村田賢太 さん

• Rubyist Hotlinks 【第 36 回】 須藤功平さん

• Rubyist Hotlinks 【第 35 回】 島田浩二さん

• Rubyist Hotlinks 【第 34 回】 大場さん夫妻 後編

• Rubyist Hotlinks 【第 33 回】 大場さん夫妻 前編

• Rubyist Hotlinks 【第 32 回】 卜部昌平さん

• Rubyist Hotlinks 【第 31 回】 樽家昌也さん

• Rubyist Hotlinks 【第 30 回】 遠藤侑介さん

• Rubyist Hotlinks 【第 29 回】 松田明さん

• Rubyist Hotlinks 【第 28 回】 Yugui さん

• Rubyist Hotlinks 【第 27 回】 小波秀雄 さん

• Rubyist Hotlinks 【第 26 回】 cuzic さん

• Rubyist Hotlinks 【第 25 回】 加藤勇也さん

• Rubyist Hotlinks 【第 24 回】 okkez さん

• Rubyist Hotlinks 【第 23 回】 yhara さん

• Rubyist Hotlinks 【第 22 回】 nari さん

• Rubyist Hotlinks 【第 21 回】 原信一郎さん

• Rubyist Hotlinks 【第 20 回】 石塚圭樹さん

• Rubyist Hotlinks 【第 19 回】 伊尾木将之さん

• Rubyist Hotlinks 【第 18 回】 立石孝彰さん

• Rubyist Hotlinks 【第 17 回】 青木峰郎さん

• Rubyist Hotlinks 【第 17 回】 青木峰郎さん　インタビューイントロ

• Rubyist Hotlinks 【第 16 回】 essa さん

• Rubyist Hotlinks 【第 15 回】 arton さん

• Rubyist Hotlinks 【第 14 回】 角谷信太郎さん

• Rubyist Hotlinks 【第 13 回】 関将俊さん

• Rubyist Hotlinks 【第 12 回】 後藤兄弟 後編

• Rubyist Hotlinks 【第 11 回】 後藤兄弟 前編

• Rubyist Hotlinks 【第 10 回】 わたなべひろふみさん

• Rubyist Hotlinks 【第 9 回】 中田伸悦さん

• Rubyist Hotlinks 【第 8 回】 田中哲さん

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

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

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

• Rubyist Hotlinks 【第 7 回】 江渡浩一郎さん 後編

• Rubyist Hotlinks 【第 6 回】 江渡浩一郎さん 前編

• Rubyist Hotlinks 【第 5 回】 増井俊之さん

• Rubyist Hotlinks 【第 4 回】 ただただしさん

• Rubyist Hotlinks 【第 3 回】 かずひこさん

• Rubyist Hotlinks 【第 2 回】 前田修吾さん

• Rubyist Hotlinks 【第 1 回】 まつもとゆきひろさん

---