« 小説木幡記:2008/06/17(火)今朝の感動・森KY話 | トップページ | 小説木幡記:2008/06/20(金)近況と反省の日々 »

2008年6月18日 (水)

小説木幡記: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。ロールプルレイングゲームのはしりだな。これが大局観。

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

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

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

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

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

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

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

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

|

« 小説木幡記:2008/06/17(火)今朝の感動・森KY話 | トップページ | 小説木幡記:2008/06/20(金)近況と反省の日々 »

小説木幡記」カテゴリの記事

Luna企画」カテゴリの記事

コメント

青年晩期への挽歌、ですか

 プログラミングにおける(設計図)とは?
なんて質問をして、遠い目にさせたり、胸つまらせたり、してしまいました。

 しかしなんですなあ。
やはりプログラミングができる人は楽器が弾ける人と同じように羨ましいです。
楽器を弾いて一曲聴かせてウットリさせる。
プログラミングしてロール・プレーイング・ゲームを作り人に遊ばせる。

 記事を拝見して分かったことがあります。
プログラミング言語と申しますがMu大兄にとってはやはり一つの言語なのですね。
だから小説を書くようにプログラムを書く。
思うように書く。
設計図?そんな七面倒くさいことは、余は知らぬ、と。

 純粋ロジックの世界はパスカルやモジュラー2で遊び、糊口をしのぐにはBASICやスッピンのCを使うにやぶさかではない。
そういえば関東の某S社のBASICのグラフィックスがよく出来ていると感心しておられましたねえ。

 青年期への挽歌、青春の残照となりましょうか。

投稿: ふうてん | 2008年6月19日 (木) 00時14分

ふうてんさん
 親父が土建業だった影響は強いです。たとえば、中学ころに親兄弟で自宅を造ったわけですが、そのころ、廊下やトイレや和室や洋室の型紙があり、それを親父がこねながら、やがて設計図が出来ていました。

 私も、その型紙で家を夢想するのが好きで、毎日「自分流の家」を考えていました。大抵は幅広の一間(1.8m)廊下が広い座敷を取り回すタイプでしたね。畳と木製の廊下を組み合わせるのが好きだったです。

 日曜作家や日曜プログラマーも、その程度の設計はしておりますよ。

 精密機器類や模型や、その他。設計図がないと作れませんね。
 ところが日曜作家&プログラマーの世界は、ソフトウェアだから、可塑性があって、その分、設計意図を離れたものに出くわし、想定外のおもしろみ、楽しみがわきあがるようです。

 そうだ。ふうてんさんは、マンドリンでしたか、ウクレレでしたか、百万遍工学部では、そんな特技を周りに披瀝していたという噂話が甦りました。

「青年期への挽歌、青春の残照となりましょうか。」

↑思念の奔流、制御の難しさでは、青年期と今も、大きな変化はないです。
 二十代頃にも、未来の自分が「挽歌、残照」とつぶやくのを想像していました。まさに、三つ子の魂百まで世界ですね。

「大仏」造営。いまだに興味が失せません。

投稿: Mu→ふうてん | 2008年6月19日 (木) 03時34分

この記事へのコメントは終了しました。

トラックバック


この記事へのトラックバック一覧です: 小説木幡記:2008/06/18(水)プログラミング考:

« 小説木幡記:2008/06/17(火)今朝の感動・森KY話 | トップページ | 小説木幡記:2008/06/20(金)近況と反省の日々 »