題名:Java Diary-106章

五 郎の 入り口に戻る
日付:2012/12/16
目次に戻る


Gozen - Part1

年があけるとすぐに「プログラミングシンポジウム」というものに参加する。別名プロシン。前から存在は知っていたのだが、参加するのは 今回が初めて。なんというか実に独特の雰囲気を持った集まりでございました。貴族の清談というかね。

参加の動機は「初めてだから」というのが一番大きかったのだが、未踏ソフトの時にPMをしてもらった原田さんに今年の構想についてコメントをもらう、という目的もあった。

というわけで初日の宴会でさっそく原田さんを見つける。あれこれ説明するが、「やってみたければ、やればいいんじゃない」的なコメントをもらう。そんなもの見た事あるよ、というのが一番恐れていた反応なので、これで十分である。プロシンから帰ってくるとさっそく構想を練る。

何をやりたいかのアウトラインは決まっている。昨今プレゼンテーション用ソフトが広く使われるようになった。それとともに既存のソフトに悪口を言う人も増えたが、では

「どうすればいいのか」

についての提案は驚くほど少ない。調べてみれば

・プレゼンというよりは、学校の講義に使う事を想定したもの

・とにかくブラウザで実行できる事に注力したもの

は多い。しかし私の関心はそこにはなかった。仔細は省く(というか後述する)がプレゼン用のソフトというのは、「スライド」なる大時代的なものの上に文字やらを配置するのが主眼ではない。スライドなどはもう消え去るべき。プレゼン用ソフトは、プログラミング言語であるべきだ、というのが主張である。それゆえプロシンに参加することにしたわけである。

とはいっても、具体的にどう進めばいいのかさっぱりわからない状態だ。それはいつものことであるといわれればその通り。しかし今回はちょっと次元が違う。今まで自分で言語を作る等考えたこともなかったのだ。おまけにそもそもどういう構成のプログラムにすればいいのだ。インタープリターって画面ないよな。となるとコンソールアプリか。でも画面上であれこれ操作したい気もするし。どうしよう、と本を買い込んでみる。なるほど。名前だけ聞いて一度も使った事がなかったyacc/lexなるものを別プロセスで動かし、その出力を受け取ると。しかしこれをやろうとするとCを直接触らなくてはならない。そりゃ大学の研究室で最初に学んだ言語はCだったけど、今やそこから遠ざかって久しい。となれば、なんとかObjective-Cの世界で事がすまないだろうか。

というわけであれこれGoogle先生にお伺いを立てる。するとParseKitなる言語定義&処理用のフレームワークが公開されていることを知る。これですよこれ。というわけでさっそく使ってみようとする。デモプログラムがついているからそれを参考にすればよかろう、とあれこれやりだす。多分こういう風に切り出すのが正しいのだろう、という方法を見つける。となると次は「言語定義」という壁が迫ってくる。

このParseKitはなんとかいう有名なプログラミング言語に関する本の内容をそのままインプリメントしたものとのこと。というわけで本来であればその本を買うのが正しいのだが、私は怠け者である。この場合「急がば回れ」が正しいのだと思うが、そうした正道をとらずに、見よう見まねで言語の定義を始める。フレームワークにはいくつかの言語の定義らしきファイルがついており、これを使えば簡単ではないか、と思ったのだがもちろん世の中それほどすんなり話は進まない。どうもそれらの「定義」は不完全なものであり、一部を除いてそのままでは動かない。こういう時は本を買わないまでも、Tutorialをやってみるべきだろう。観念すると一歩一歩ParseKitのサイトにのっているTutorialをやってみる。例題は「cold cold beer」とかいう文を解析する物だ。思えばこの時期まだ世間が寒かったのは幸いだった。夏の盛りにこんな例文をいていては、気がちってしょうがなかったと思う。一歩一歩進んで行くと、なんとかcold cold beerがうまく解析できるようになる。さて、これで準備ができたことにする。実際にプレゼン用の言語を定義して行きましょう、とはもちろんならない。

そもそもどんな言語を作ればいいのだ。原田さんからは「Javascriptでいいじゃん」とコメントをもらったような記憶があるが、そりゃ確かにJavascript使えば何でもできるけど今回の目的にはOver killだ。というかちゃんとJavaScript勉強するの面倒だし。しかしあれだよね。考えてみれば、

・画面上に複数の要素を一度にだす

ことと

・画面上に複数の要素を順番に出す

ことやんなくちゃならないよね。こういう制御を綺麗に書ける方法ってきっとプログラミングの世界でやられていないかしら。これはきっと並列処理言語とかそういう事に違いない、と勝手に思い込む。そういえばOccamってあったなあと調べてみる。20年くらい前にはいろいろな言語が覇を競っており

「この言語はいいんだ」

とかそういう議論がずいぶんあったように思える。勿論最近でもPythonがどうとかHaskshellがどうとかの話はあるのだが、昔にあった議論に比べると実用的だと感じる。つまりおとなしいのだ。Occamがどうのとか言っているころはもっと荒っぽく、そして興味深かった。そもそも単純継承と多重継承とどちらがいいんだろうね。そりゃ多重継承に決まっているさ、というわけでFlavorsとか。何事も広がる時にはカンブリア紀のような様相を呈するものだが、それを懐かしがっていてもしょうがない。

というわけでOccamに興味は持ったがこのままで良い気もしない。そもそもどうするのだ。そのうち構想はあらぬところに飛んで行く。やりたいことは、自分のしゃべりにうまくタイミングを合わせ、どんどん要素を表示することだ。これはトムとジェリーにおける動画とオーケストラ音楽のシンクロにも相通じるものがあるのではなかろうか。そうだ。人類には「楽譜」というタイミングと負荷情報(この場合は音の高さ)を記述するための方法があるじゃないか。よし楽譜で記述しよう。ああ、おれは天才かもしれない。

とひとしきり自己満足に浸った後、ふと気がつく。古くはMacromedia,今はAdobeが作っているFlash(というかDirector)は今から何十年も前から「スコア」なる楽譜を模したような記述形式を持っているじゃないか。There is nothing new under the sunとはよくいったもの、というより私が考えつくようなことはほとんどの場合誰かが先に気がついているのだ。しかしあのインタフェース私も使った事あるけど表示要素が多くなると使いづらくなるんだよね。

というわけで、構想は元に戻る。もうあれこれ考えていてもしょうがない。ここは一発

「僕が考える便利なプレゼン記述用プログラミング言語」

を書いてみようではないか。というわけでしょこしょこ書き出す。まあ要するに画面に出す、消すの制御だけできればいいんだよね、ということで書きだすとなんとなく成立しそうである。これはいけるかもしれない、と思うのは簡単だが、その言語を自作インタープリタが理解してくれるまでにはまだまだ長い道のりがあるのであった。

前の章 | 次の章


注釈