Lisperでもハッカーでもない
実は私はLisperでもハッカーでもない。単なるLISP経験者。LISPにハッカー的なイメージももっていない。現在ソフトウェアエンジニアリングを仕事の糧としているということもあり、またLISP時代もNTTとかXEROXという環境で業務としてソフトウェア開発をやってきた訳でもある。人工知能(AI)がブームのときでもあり、バブルのときでもある。機械翻訳、金融系エキスパートシステム（ポートフォリオ、事業承継対策、相続税対策、生保の生活設計）、マニュアル診断、マルチメディア試作、高速PostScriptプリンタ試作を行った。
例えば、再帰をバンバン使っていたかというとそうではない。再帰をあえてPROG-LOOPで記述していた。XEROX時代は「1121」というハードウェアを売ることだけが最終目標だった。JSTARチーム、SMALLTALKチーム、LISPチームでそれぞれ目標台数が設定されていたくらいだ。1121はMem=16KB、HD=8MBくらいだったのではないか。再帰だとStackやHeapを消費してパフォーマンスが出なくなることがあったので、StackやHeapを消費しないPROG-LOOPを多用していた。ほとんど手続き型言語とかわりない使い方だ。
(※後日の調査にて1121は、Mem=1MB以上、HD=80MBと判明)
LISPのメリットと適性を思い出しながら考えてみた。結論は以下の３つだ。
数学的帰納法を適用できるドメイン
−σで試算し、＋σで試算する。さらに幅を徐々に狭めて試算を繰り返し、目指す最終形に収束させていく。ポートフォリオ、事業承継対策、相続税対策、生活設計（収支バランスと資産のシミュレーション）などはそうだ。パラメータ間の相関を厳密に定義せず、行き過ぎたら戻す、戻しすぎたらちょっと進めるという制御だけを与えて、ひたすらシミュレーションを繰り返し、リスクとのバランスで数年後に資産が最も増えるものという最終形を目指して最適なパラメータを導くのだ。
機械翻訳実験でも、形態素解析以降の係り受けから多義が爆発的に出てくる。多義が発生する条件をパラメータ化し、翻訳文をNativeに評価させた情報をもとに相関関係を見出しながら、徐々にパラメータの幅を狭めていく。
何が変動要因となるパラメータであるかを見きわめて揺さぶりの方向を決め、どのように目指す最終形に収束させるかということだけに注力すればいい。途中のロジックは要らない。後はLISPが延々と試行錯誤でシミュレーションを繰り返してくれる。せいぜい無限ループにならないようにするだけだ。
これらは数学的帰納法に基づく再帰処理で解が得られる。どういう状態になれば再帰を抜けるかの条件のみがうまく設定できればよいのだ。そういったドメインがあるのだ。LISPに適したドメインがあるのだ。無理してあらゆるドメインのシステムにLISPを用いるというのは考えたことがない。言語は手段であって、目的ではないはず。
