[NOTE]
This article is written ONLY in Japanese.
I hope you can read the contents through one of the surprisingly advanced latest machine translators,
such as Google and DeepL.

Fliege über die Rekursiven!

ここに記載した内容は Viivi に関する 非公式で個人的な考えを雑然と思いつくまま書いたものです．
Viivi 開発の背景にある経緯や考えかたを知っていただくために設置しています．

(1) 開発の動機と経緯

• 動機
  最初から言語処理系を自力で作ってみたいという欲求がありました． 他のアプリケーションでなく「言語処理系」なのは， この種のものがプログラムの中でもいちばんおもしろいと思うからです． 人が書いたプログラムを読み込んで処理するプログラムというのは，漠然としていますが， 人工知能っぽくてかっこいいと思っていました．
  
  最初から「自力で」作ることも重要な要素でした． どこか知らないところにいるすごい人たちが書いているのであろう言語処理系という種類のプログラムを 果たして僕のような素人が0から書けるのか 試してみたかったのです． 正直いちばん初め(1980年代中盤)の段階では人のコードを参考にすることも少し考えていました． でもその方法は僕には全く合いませんでした． 世の中には柔軟に他人の考えかたに自分の思考を合わせられる方もいらっしゃるようですが， 僕にとっては，自分のコードを書くことほど楽しいことはなく，他人のコードを読まされることほど苦痛なことはありません． そういうわけで，一貫して独自設計，独自実装に徹底的にこだわっています．


• 日本語LOGO
  PC98が日本で覇権を握る直前のころ，両親にIBM-PC互換機を買ってもらいました (その後も親のスネをかじり続けることになってしまいました)． 最初にプログラミングがほんとうにおもしろいと思ったのは1980年代なかばに日本語LOGO(固有名詞ではありません)で遊んだときでした． 日本語がそのまま使えるのが非常に楽しかったからです． 当時まだ70年代の人工知能ブームの名残りで簡単な擬似人格お話しプログラム的なものがあり， LOGO だとそういうのが比較的簡単に書けるので興味を持って遊んでいました． ところがいざやりたいことを書こうとするとたいていの場合何らかの問題が起きて行き詰まってしまい， 残念ながら言語にも処理系にも何か足りない感じを拭いきれませんでした． (などと書いてしまうとこの LOGO のシステムにケチをつけているように取られかねませんが，むしろ逆です． 当時全メモリ 256KB という限られたリソースの上で驚くほどの高機能を備えたソフトウェアでした． プログラミングにただならぬ魅力を感じさせてくれた大好きなソフトウェアのひとつです．) ここから，いつか自分の言語処理系を作りたいという願望がわいてきました．
  
  一方，当時 PDS (Public Domain Software) という形式で Lisp のソースコードも配布されていました． 「LOGO の元になったハッカー御用達言語」と聞いていくつか試してみましたが，あまりピンときませんでした． 興味がいまひとつ湧かなかったのはやはり日本語が使えなかったためだと思います． お話プログラムで「こんにちは！」じゃなくて「Kon-nichiwa!」とか「Hello!」じゃ， やっぱりちょっと興ざめですよね． Lisp は LOGO とくらべて文法が一様で単純そうだなーという印象は持っていました．


• C/C++
  日本語LOGOと同時にC言語の勉強も始めていましたのでこれで自分の言語処理系を作ることを考えました． 最初から日本語が使えることが重要な要素のひとつでした． ところが当時まだコンピュータ上での日本語の扱いが統一されておらず， 当然C/C++による日本語処理ライブラリも統一されたものがなく，自分で書くしかありませんでした． 言語のフレームワークよりも前にまず日本語処理ライブラリを書くことにしましたが， いきなり行き詰まりました． C/C++のスキルもオブジェクト指向プログラミング(OOP: Object-Oriented Programming)的な考えかたも充分ではなく， コンパクトで矛盾のない日本語処理ライブラリを設計・実装することができなかったのだと思います．


• IEEE Scheme
  1990年代初めに2つの出版物に出会いました(当時まだインターネットが充分に使えなかった)． ひとつは IEEEのScheme規格書である IEEE Standard 1178-1990, "IEEE Standard for the Scheme Programming Language" です． これを手に入れるためだけにIEEEの会員になりました． 当時 8000円 くらいかかった記憶がありますが，届いた印刷物はペラペラな印象で， 逆にこれなら実装できるかも，という期待をもたせてくれるものでした． Lisp 言語へのあこがれは既に大きくなっていて， 雑誌などで Scheme 言語の簡潔さと強力さについての記事を見るにつけ Scheme 言語へ傾倒していきました (実際にSchemeで何か書くようになったという意味ではなく，実装したいという気持ちが強くなったという意味です)． 残念ながらこの規格書は引越しを繰り返すうちに捨ててしまいました． 手に入れるにはまたIEEEから買うしかないらしく， 資料として取っておくべきだったなぁと後悔しています．


• James O. Coplien
  もうひとつは James O. Coplien の「Advanced C++ Programming Styles and Idioms」という本です(まだ買えます！)． 今となっては時代遅れの内容かもしれませんが (いや，やはりそんなことはないですね．時代を越えた価値をもつ内容だと思います． 20年以上経ってもまだ販売されているわけですから)， 現在までにたくさんの賞を受賞しているらしい名著です． 僕が読んだ初版にも既に JOLT Cola の賞を受けたということが書いてあったように記憶しています． とにかくこの本にめぐり逢えたのはラッキーでした． 内容を簡単に言うなら 「構造化プログラミングの域を出ない似非オブジェクト指向プログラミングから 真のオブジェクト指向プログラミングへのパラダイムシフトの提示」です． 今でいうところのデザイン・パターンに至るまでの過程における考えかたについて述べたものと書けば良いのかもしれません． 豊富な例を挙げてあり記述のスタイルは非常に具体的なのですが， プログラミングの本というよりはむしろ哲学書的なテイストがあってとても気に入ったので バイブルとしていつも持ち歩いて何度も読み返しました． ちなみに，浅学を露呈しますが，オブジェクト指向モデリングについて 一冊の本を最初から最後までちゃんと読んだのはこの本だけです． これ，「C++をどう使えば正しいオブジェクト指向プログラミングができるか」について解説した本であると書いてありますが， 僕には「C++ではどうやっても正しいオブジェクト指向プログラミングはできない」ことを切々と語っている本であるように読めました． C++はOOP言語としては不完全なものであり， C++で「ほんとうに」OOPするには 設計者やプログラマが意識してほとんどすべて面倒をみてやらないと正しいプログラムを組むことができません． C++は 高級アセンブラであるC言語の直接の継承者であり， 制限なしに何でもできるというその特長が OOP にとっては強力すぎて危険だったということだと思います． 日本語処理ライブラリの作成に失敗したのも個人的なスキル不足だけが原因ではなかったのかも， と正当化して自分を納得させるようになりました． でも，じゃあいったいどうすれば良いのでしょうか？


• Java
  そんなとき(1990年代なかば)，Java プログラミング言語が Sun Microsystems 社から発表されました． 最初はブラウザの HotJava との区別もつかないくらいわけのわからないものでしたが， 1年後には既に当時の「次世代」プログラミング言語の最有力候補として様々な雑誌で取り上げられるようになっていました． C++での実装に行き詰まっていた僕はこれに飛びつきました． ちょっとやってみたところ C++ にそっくりです． Java で小さなプログラム(Unix のフィルタで今も現役で使っています)を書いてみたところ，C++より簡単に書けます． 何よりも Java API と称する莫大なライブラリ群が最初から用意されていて， ずっと悩んでいた文字列処理のツール(日本語に対応したのは少し後だったかもしれない)も既にあるじゃないですか！ 当時の僕の感覚では Java は， C++ の OOP 言語として不完全だった欠点をつぶして 全体的にもっと便利にした言語というものでした． C++のように比較的自由で何でも許されるというわけではなく， 心地よい(うーん…これはウソだな．正直なところかなりキツい)制限があってそれに従えば正しいOOPスタイルが保たれるという感じです． 大枚はたいて毎月取り寄せていた Dr. Dobb's Journal (US版) に Java の HashTable (HashMap に代わってからか？) を使った変数管理の記事が載っているのを見たとき，実装言語は Java で行けると確信しました．


• Viivi のデータ構造
  Coplien の本の OOP 哲学は Java のものと見事に一致していました． Java 言語の文法・規則に沿ってコーディングしていけば，特に意識することなく自然に Coplien の言っていたように書けました． そこで (まだ Scheme とは言えない) いわゆる「俺Lisp」を書き始めました． インタプリタ本体ではなく，Lisp のデータ構造から書き始めました． ペア，文字列，数値データなどを実装し，それらのための基本的な処理コードを書いていきました． これからするとViiviはほぼ bottom-up で作ったことになります． OOP 的な考えかたの軸さえあれば，あとはこどものときにブロックでロボットや飛行機を組んでいたのと同じです． 具体的なイメージをもって部品を組み合わせていけば良いだけです．


• Viivi 本体
  ずっと夜の空いた時間に少しずつ Java の勉強をしていましたが， 1990年代末に仕事の環境が変わってしまい， 以前のようには自分のプログラミングに時間を割けなくなってしまいました． それでも週末はViivi本体の完成を目指してほんとうに少しずつですが実装を続けました． まず二進木評価装置を作り，それからR5RSを実装目標に据え， パーサを実装してS式を読み込めるようにしました． 実際にはこの期間が開発に関していちばん本質的なのですが，いろいろあって現在に至ります．


• Java と Scheme
  たまたま Viivi がなんとなく形になってバグ探しのために公開するところまでこぎつけたのはありがたいのですが， Viivi は Java の勉強には良い教材だったように思います． ずっと AWK 言語を愛用していて今でもスクリプトのほとんどを AWK で書いていますが， 数年前に AWK で書くのが難しい処理を JavaCC+Java で書いたらわりとすんなり書けました．
  
  こんなところまで読んでいただいているということは，多分生粋の Scheme ハッカーの方だと思いますが， ごらんのように残念ながら僕がなんとか使える言語は Java くらいです． 一方，Scheme のほうは「美しい理想的な言語」として崇め奉る対象ではありますが， とても使いこなすレベルにまでは行きません． 自分は「モデラー」だと思っています． Java 言語を使ってモデル化するのが仕事で，Scheme はそのモデル化の対象， そして Viivi はモデル化された実体，という位置づけです．
  
  Scheme を使う側として全くの初心者なのですが， つたない自分の処理系を試していただく立場になってしまいましたので， これを機会にこれからはもっと Scheme 言語でのプログラミングを勉強させていただきたいと思っています． Scheme 言語を自由に使いこなすことがいかにすごいことかについては充分理解しているつもりですので Schemer のみなさまには近寄りがたいオーラを感じてしまうのですが， なるべく優しくご指導いただけますようお願い申し上げます．
  

2010/10/24 開設
Copyright(C) 2003-2022 ilma <ilma@viivi.io> All rights reserved.