小説木幡記：2008/06/18（水）プログラミング考

　畏友のふうてんさんが「2008・6・15　梅雨の晴れ間に篇」を書いたので余もコメントをいれた。

　するとほどなくしてMuBlogの記事には、余のプログラミング考をあまり見かけないが、余は以前どのようなプログラミング設計手法を用いていたのかという、ご下問がござった。
　というのも、30年も昔になろうか、余は某社新鋭の、FM-TOWNS開発課長「ふうてん」さんの指導のもと、一介のLuna企画開発部長として、なにやかやとゲームやらデータベースシステムを、名機FM-TOWNSのCPU上で作っておった。そんな縁がある。

　しかしこの件は、たしかFM-Gearsとかいう、いまでいう、強力なプログラミング機能を備えたプレゼンテーション・アプリケーションに入れ込んでしまって、いっかなふうてんさんの所望の作品ができなかったという、苦い記憶がある。ここで伏線を明かすなら、余がやれ恭仁宮の、紫香楽宮の、そして近いうちに「大仏の」「平城京の」とMuBlogに記すのは、ひとえにこの苦い記憶、負い目を解き放ちたいという、一種の、青年晩期への挽歌じゃなぁ。と言っても、その内実は誰にも分からぬ。うはは。

　さて。
　たびたびこれはしるしたが、Pascal系のTrubo-PASCALが余の最強の得物だったが、皮肉にも、いわゆる糊口をしのいだのは、BASICであり、スッピンのCであった。いや、記憶が蘇った。他の研究会で最強・主力兵器にしたのはModula-2じゃった。この言語による作品は学術的なものだったので、一般の目には触れていない。

　それで、プログラミング設計手法。
　昔の事例で申すなら、手続き型言語では、関数(function)と手続き(procedure)という二種類の部品化手法でモジュール（ひとまとまりの仕事）を作って、それを組み合わせることで、一式意味のある作用をするプログラムができた。現代は大規模工場生産が主流だから、そのあたりの筋目が見えず、複層する絡みの沼に足を突っ込んでしまう。ことの起こりはオブジェクトオリエンテッドという考えがあったようだが、今のことはもう分からぬ。ただしかし、Modula-2というのは、その原型だったのは間違いない。ヴィルト先生が開発した言語でした。

　……（遠い目になるな）
　それで、現代のことは放念して、そのころの設計手法じゃが。
　……（胸がつまるな）

　これがおどろくなかれ、まるっきり日曜作家と同じで、設計図らしきものがなきに等しい。
　ただ、今にしておもえば、高校の数学を思い出して作っておった。ものごとが複雑になってくると、それをひとまとめにして、ラージXというか、別名で置換して使う手法だな。

　Pascal系は、すべての手続きや関数を最初の　main　部分で披瀝する手法だ。だから、置換しつくすと、最後の主プログラムは、以下のように単純極まるものになってしまう。

主プログラム
　　begin
　　　あれせい;
　　　これせい;
　　　ついでにこれもやれ;
　　　もういいか？;
　　end.

　注意したのは、極細部と大局とのバランスじゃった。これも日曜作家と変わらぬ。ともかく、なにがしたいかは大体イメージにあった。たとえば、ゲームなら、地図上をあっちらこっちら歩き回って、事件に出くわして、情報をえて、ゲームしている人は自分がなにをすべきなのかが、だんだん分かってくる。そう、RPG。ロールプルレイングゲームのはしりだな。これが大局観。

　そして、地図上の人間もどきが事件に遭遇したのをどうやって判定するのか、などなど細部を事細かに考えること。これがプログラミング技術とか、当時なら開発マシン毎にだいぶ異なってくる。
　大局を考えながら、細部を造り込む。技術的にデッドロックにぶちあたると開発が停まる、幾何学や代数学の問題を解くように、時間がかかる。ひらめく。まったく別の手法が。熱中し、完成する。
　すると。
　大局を忘れてしまって、大局がその細部によって変成してくる。……。

　余の日曜作家はまさにこうであった。
　ということは、プログラミング手法も、おなじく行き当たりばったり。どんなものが出来るかは、まるっきり分からないことも多い。現代の大勢が関わる工場開発手法では許されないことやね。

　ただし、プログラミングにおいては最低のルール、つまり後日の他人である自分自身が数ヶ月後、数年後にも自分で分かるような「流れ」アルゴリズムを使わないと駄目だ、ということは２０代末に分かっておった。それは、やはり苦い経験の上でのことじゃろう（昔のことを類推）。

　基本は、repeatという命令に代表される、一連の作業全体の繰り返し（ループ）。
　その中でさまざまなスイッチング（切り替え、具体的には処理系による）で分岐させる。
　それに尽きた。
　さらに、クセとしては、「再帰」リカーシブというのかな？　それを多用した。
　それは効率が悪くて、スピードも落ちるが、清明さでは優れていた。
　ともかくそこら中、再帰手法だから、あとで余には、よく分かる！

過去のプログラミング手法のまとめ
　　なにが出来るかはわからない。だから、担当さんが「ふうてん」さんみたいな人でないと、潰れる。
　　しかし、イメージはしっかりある。雰囲気だな。
　　「こうなる」と、余の脳には明瞭にあった。ただし、それが毎日変化するということ。

　　行き当たりばったりだが、最低限のルールを持っていた。
　　ああして、こうして、こうなって。
　　これは逆転できない。こうなって、こうして、ああして、とはならない。地道な積み上げ。
　　そして、次々と置換して、名を与えメモリの海にモジュールを浮かしていき、
　　さらにモジュール間で連絡船を造ったり、橋を渡したり、トンネルを造ったりして、
　　各モジュールを繋いでいった。
　　つまり、基本的なアルゴリズムは、多重ループ内でのスイッチング手法。
　　さらに再帰手法。

　　というわけで、細部にとらわれながらも大局を思い出し、
　　一度動いたアルゴリズムも大抵は再帰手法にかえることで、構造を分明たらしめた。
　　つまり、変換することで、善し悪し、無駄がよくわかってくる脳。

　そんな方法で、昔男ありき、なにやらシステム開発のはしりに、身を寄せておりましたなぁ。