第60回 その時、家政婦さんは見た！！（ＶＣ++6.0のエラーメッセージ） 99/7/11
このエラーを見て、何のことかわかった人は、相当のプログラマだろう。
d:\myproject\projectt\prog\tedit\gamemap.cpp(14)
: error C2248: 'Add' : public ﾒﾝﾊﾞ (ｸﾗｽ 'CLayer'
で宣言されている）にｱｸｾｽできません。
d:\myproject\projectt\prog\yanesdk\yanelayer.h(20)
: 'Add' の宣言を確認してください。
privateメンバにアクセスできませんならわかるが、publicメンバにアクセスできません、とはこれいかに？いかに？いかに？と１時間ほど悩んで、頭が痛くなってきたから、これでは、いかん！と思い、いかを買いに行った。個人的には、よっちゃんイカが食べたかったのだが、ローソンにはよっちゃんイカは売られていなかったので、イカのだるま焼きを買うことにした。このだるま焼きがまた、一つ一つ大きさが違うんでやんの。じっと見比べていたら、大きいのと小さいのとで２倍ぐらい大きさが違う。ひょっとすると隣町ローソンなら３倍ぐらい大きいやつがあるかも知れないと思い、隣町まで走って行くことにした。深夜の３時。どうせモニターを眺めながら考えていても、埒があかないのであるから、適度の運動をしたほうが良いのだ。隣町まで、全速力で走る。走る。走る。
そういや、テンプレートも使うと、とんでもないエラーメッセージ出すよなぁ。なんちゅーか、頭悪すぎなんだよなー。マクロの延長として定義するから正当性のチェックがしにくくなるんだよなー。もうちっと考えろよなー。だいたい、プログラミングのエラーは大別すると２種類しかないんや。実行時と、コンパイル時。まー、設計段階でコケてるときもあるけど、それはそれとしよう。んで、実行時のんは、ブレークポイントしかけて、ウオッチしたら何とかなるやろし、暴走してそうに見えたら、ブレークかけてコールスタック表示させたら、どこでつっかえてんのか一発でわかる。フルスクリーンでやってたら、リモートデバッグか、２画面表示を使うんや。簡単なこっちゃ。あとは、コンパイル時のんや。これがあるおかげで実行時にエラーを出さんで済むんや。ありがたいこっちゃ。しかしやなー、そのエラーとしてこんなわけわからんの出てきたら、どないしたらええんや？そうや。いらん部分をとってくんや。プロジェクト丸ごとバックアップしといて、どんどんいらん部分とって行くんや。そしたら、いつか動きよる。そこがバグやったわけや。などとぶつぶつ言いながら、走ること２０分。ついに隣町のローソンに到着。もうヘトヘトだよ。これの、どこが適度な運動なのか。
深夜３時、ローソンに押し入る不審な汗だくの男、懸命に何かを探す。防犯カメラにもばっちり写っていることだろうし、テレビカメラの向こうで目を凝らしてこちらの様子をうかがっているはずである。「深夜３時に、汗だく」、もうそのへんからして、これはコンビニ強盗か、連続強盗殺人鬼の類しか想像できない。探しているのは、ナイフか出刃包丁だろうか？少なくとも僕の貧困な想像力ならば、そうだ。
まさか、だるま焼き目当てで隣町から猛ダッシュで駆けつけた納期に追われ土日を潰してゲームプログラミング中の非職業的プログラマの苦悩の姿だとは思いもよらねぇんだろうな。（あたり前） そして、お目当てのイカのだるま焼きが．．．無い！姿焼き？こんなサクサクしたのはいかん。だるま焼きだ。だるま焼きをよこせ！
一気にチカラが抜けた。そのとき、あのクラス宣言に、
class CTMap : CLayer {
と、publicが抜けている映像が浮かびあがってきた！それだ！！ＶＣの奴め、また俺を騙しやがった。何が
d:\myproject\projectt\prog\yanesdk\yanelayer.h(20) : 'Add' の宣言を確認してください。
だ。そんなとこ、関係ねーじゃねーか。ざけるんじゃねぇ！！コンビニの奥のほうで思わず叫んでしまったではないか。それを聞いて、何やら、店員が店の奥に走って行ってしまった。やばい。ひょっとするとパトカー来るんか？もしかして、俺は指名手配されてしまったか？もう後戻りは出来ない。もし捕まってしまって、刑務所にでも入れられた日にゃ、恐怖の大王が来て助けてくれることをただ祈らんばかりである。
第61回 ようやくマップエディタが完成（ＶＣ++6.0のエラーメッセージ２） 99/7/13
またもや謎のエラーメッセージが．．．
D:\myproject\projectT\PROG\YaneSDK\yaneFileDialog.cpp(32) : error C2600: 'CFileDialog::CFileDialog' : ﾛｰｶﾙ ｸﾗｽのﾒﾝﾊﾞ 'operator`__restrict signed __segment'' には非集合型 '<Unknown>' はありません。
やねうらおには、まったくもって意味不明。これは日本語なのか？それとも、俺を陥れるための陰謀か？CFileDialogのclass宣言内でコンストラクタのCFileDialog(void)を間違えてCFilaDialog(void)と書いていたら、こんなエラーが出た。馬鹿にしくさって！！
そして、このスペルミスを修正したところ、どうも、このコンストラクタが呼び出されていないような気がする。ブレークポイントしかけてみたけど、やっぱ呼び出されていない！うお！！ＶＣのバグ発見か？と正直思ったよ。しばらくソースを眺めていると、~CFileDialog(void)と、デストラクタの宣言に引数をつけていることに気付く。うお！バグの原因は、これか！！なんで、これエラーメッセージ出てけーへんねん？しかも、コンストラクタ呼び出されてへんねん。どういうこっちゃー！！
そういや、返し値持つ関数書いてて、複雑なフローで関数抜ける部分にreturnするの忘れてたら、そこに来たらローカルラベルにジャンプしてやんの。ＶＣで最適化をほどこさないときは、ローカルラベルが出現すると関数の後ろにジャンプ命令を生成して、２段ジャンプでgotoを実現するようだ。関数から抜けるときreturnが無いので、そのジャンプ台から、ローカルラベルに飛んでいたのである。このバグを発見するのに、以前、３時間ぐらいかかったことがあるし、こーゆーの、なんでコンパイル段階でエラー（警告でも可よ）出てけーへんのかなぁ。もう、あんたとはやっとられんわ！今日限り、コンビ解消じゃ。（お前、漫才師か！＞俺）
第62回 デストラクタに気をつけろ！（ＶＣ++6.0のエラーメッセージ３） 99/7/16
毎日、謎のエラーメッセージを出し続けてやまないＶＣ＋＋である。ついでに言えば、最近、熱いのか寒いのかよくわからん。いまは、昼なのか、夜なのか？昨日、ごきぶりの大軍を街で見掛けた。これは、地球の終末へ向けて日夜邁進せしめている我々、愚民どもに対する警鐘ならんや？（なんのこっちゃ．．．）
d:\myproject\projectt\prog\yanesdk\yanemouselayer.cpp(18)
: error C2084: 関数 '__thiscall
CMouseLayer::~CMouseLayer(void)' はすでに実体を持っています。
実体を持ってますー言われて、しかしてその実態は！！などと阿呆なことを言いながらソース見たら、
CMouseLayer::~CMouseLayer(){
Del();
}
これでんがな。テキスト検索で、同名のデストラクタを探す．．．あらへんがな！！どこが実体持ってんねん！自分、あたまおかしいんちゃうん！んなアホな！と会社でタダでもらった２１インチモニタに４連続突っ込みを入れながら、classの宣言を見ると．．．デストラクタの記述を忘れとる．．．。
うーん。つまり、クラスの定義が終わった時点で、コンストラクタとかデストラクタが見つかれへんかったら、ディフォルトのコンストラクタやらデストラクタを登録して、んで、実体定義も入れ込んでまうっちゅーことか？ご苦労なこった。原理はわからんでもないけどやねぇ、もうちっと親切なエラーメッセージは出されへんかなー。ＶＣ君よー。いま、おばあちゃんが信号渡ろうと思っていつまでたっても渡られへんねん。なんでかゆうたら、信号、押しボタン式やってんよ。そういうとき、どうするー？おばあちゃん、この信号は押しボタン式ですよーって教えてやりなさいよ！間違っても、ここは信号ではありませんとか、この信号を渡るのにはお金がいるんですとか、そんな大人に．．．いや、押しボタン式の話はどうでもいいんだよ。
第60回でも話したが、デバッグ作業ってのは、コンパイル段階のと実行段階のとがある。いくら実行段階で便利なトレーサやらリモートデバッキングできようが、コンパイルエラーのメッセージがこんだけ不親切だったら、外装だけが綺麗やったけど食うてる最中にずっと横でダスキンつこて掃除してたポテトチップ一皿２０００円の神戸ぼったくり料理店と同じやないかい！（どういう例えやねん！）
第63回 ＮＴにおけるDirectInput（どうなってんのやー！？） 99/7/19
Windowsでプログラミングしていると、毎度、まいど、頭の痛くなるような怪現象に悩まされる。システム自体が複雑化してきているからだとか、やねうらおのプログラミング技術が高校生並みだからだとか、そういうのもちっとはあるだろーが、どうも、それとはまったく別の問題のような気がしてならない。
たとえば、COMオブジェクトをLoadLibraryするのは御法度であることは第５５回で触れたが、WinNT4.0でCOM的な呼出しではDirectInputを利用しようとすると、DirectInputのインターフェースが得られない。（そもそも、キーボードのためだけにDirectInputを使用する価値があるのか？というツッコミは、この際、勘弁して欲ちい）
CoInitialize(NULL);
CoCreateInstance(CLSID_DirectInput,NULL,CLSCTX_INPROC_SERVER,
IID_IDirectInput, (VOID**)&m_lpDirectInput);
とする。ヘッダーを読むときは、もち、
#define DIRECTINPUT_VERSION 0x0300
#include <dinput.h>
それなのにNTだとCoCreateInstanceで失敗する。(Win98では動く）
もちろん、NTでもDirectInputCreateなら動く。
返ってくるエラーの値を見る限り、GUIDがレジストリに登録されていないようだったので、regedit.exeでDInputを検索する。
HKEY_CLASSES_ROOT\CLSID\{25E609E0-B259-11CF-BFC7-444535540000}
で、dinput.dllが登録されている。では、dinput.hを見てみると．．．
DEFINE_GUID(CLSID_DirectInput,
0x25E609E0,0xB259,0x11CF,0xBF,0xC7,0x44,0x45,0x53,0x54,0x00,0x00
良く似ているが、驚くべきことに最後から４番目の数字が違う！！のである。
おいおい、これは入力ミスかい？GUIDの入力ミスってーのは、ちょっとシャレならんのちゃう？いまだどこにもこの現象について書かれていない。誰も騒がないのが不思議で仕方がない。誰もＮＴでDirectInputなんかつこてへんのか、それとも、ＮＴでDirectXなんてやろうとしとらんのか、わざわざCOM呼出しにしとらんのか、そりゃなんか知らんけどやなー、そりゃないんちゃうかー。たとえて言うなれば、深夜２時半にゲーセンで知り合ったばかりの女に携帯で呼び出されて、一晩中、一緒に猫を探しまわって、朝の６時まで探したけど、結局猫は見つからんかって、あたしあなたとはいいお友達でいたいのとか何とか言いながら帰って行くもんだから、噴水前で呆然と立ち尽くしていたら、「ミーコ イエニ モドッテタ(^^;」とかゆーメッセージが送られてきて、一体おれは何やってんだかと日の出を眺めながら人生の意義について考えた忘れもしない１９９７年の３月２４日じゃないんだから！（なんじゃそりゃーー！！）
第64回 MFCとやねうらおの相関危険指数について（MFC HowTo講座） 99/7/21
MFCをベタ誉めの人がいる。やねうらおのまわりにも、結構いる。WindowsでプログラミングするならMFCだよ、みたいな寝ぼけた連中。（まあ、彼らも、それなりの技術者ではあるんだけど）
自慢ではないが、やねうらおは、Windowsプログラミングを初めて間もないころ、OpenGLのプログラムをMFCフレームワークを利用して実行しよう、などとわけのわからんまま触って、てんで理解できなかった覚えがある。プログラミングとはかくも難しきものなのかと正直感じた。しかし、それは大きな間違いだった。MFCは、Win32APIを隠匿なんてしていなかったのである。単に、C++的呼び出し手段を提供していたに過ぎない。（よちよちさんのやねうらおには、そのことにさえ、気づかなかった） つまりは、Ｗｉｎ３２ＡＰＩ自体を理解していない者が触るべきものではなかったのである。（よって、MFCの本なんて、買うだけ無駄！そんな金あんならWindowsのAPIバイブル買いなよー。WindowsAPIを理解すれば、自ずとMFCは理解できるだろうし。オンラインヘルプが完全に日本語化されたら、WindowsAPIの本も買わずに済むんだろうになぁ...）
逆に、Win32APIをある程度理解した今となっては、MFCなんぞ屁でもないし、こんなマイルーラのごとき薄いラッパーなんて使いものにならないとも思っている。（そもそも、すべてのＡＰＩがきちんとラップされとらん！）
おまけに、配列や実行時型判定だってSTLの仕様が固まる前だったから独自の実装を行なっているし、テンプレート使えばすっきり書けるところもたくさんあるし、一部の機能を利用したいだけなのに不要なやつが大所帯でついてくるし（”不要”家族かいな？）、ウィンドゥのサブクラス化はめちゃんこやりにくいし、ゲームプログラミングをやるんなら、こんなくだらないクラスライブラリ、わざわざ覚えて使うだけの価値があるとは思えないのだが、使いこなせばちょっとしたプロトタイプを作るのが速くなるっちゅーのは否定しないが。
第65回 新・プログラミングスピリッツ（現代プログラミングの基礎体力） 99/7/24
誰でもそうだと思うのだが、やねうらおのまわりにも、オブジェクト指向信奉者がたくさんいる。ＳＴＬの有用性やらなんやらを説いて全国津々浦々を放浪している連中である。
そういう連中のなかには人のソースを読むとき、インデントがきちっとしていない、あるいは自分風のスタイルでなければ読めないという輩が結構いる。熟練したプログラマほど、意外とこの傾向が強いのではないかと思う。変数が厳密にハンガリー記法に基づいていないとダメだとか、機能単位でクラス化されてないと駄目だとか．．．。目が慣れてしまっているのかも知れない。
確かに違ったスタイルを目の当たりにするとき、違和を感じるのは普通だろう。しかし、「だから読めない」と言うのならば、それは、明らかに”退化”の証明ではないのか？熟練者でさえ、ときおり「こんな汚いソースは読めない」と他人のソースを弾き飛ばしたりするが、僕に言わせれば、それは自分の無能さを露呈しているに過ぎない。
結局のところ、文字がどれだけ詰まっていようとプログラムは読めるし、どれだけスパゲッティであろうと頭のなかでクロスリファレンスしながら読めなくてはならない。それは、実際に可能だし、僕の周りにもそういうことが出来る人は、少なからず存在する。
近年、プログラミング環境が便利になりすぎたせいか、そういう基礎体力が欠けているような気がしてならない。インデント位置などに頼っているから、高速スクロール画面を見ながらリアルタイムに頭のなかでフローを解析する程度の力すら養われないのである。検索機能に頼ってばかりいるから、画面上にびっしり文字が詰まっていると、特定の語句を瞬時に見つけることが出来ないのである。文字は自分がカーソルキーを押すまで表示されているという甘えがあるから、いつまでたっても人並みの速度でしか文字が読めないのである。「そんなこと出来なくったって」なんて思わずに、それはそれとして謙虚に受け止めたほうが良いのではなかろうか。大規模のソースを処理したり、多数の文献のなかから必要なものをピックアップしたりするためには、そうした能力が必要不可欠だし、簡単な計算さえ電卓を使うクセがつくと、足し算さえ間違うようになるのが人間なのだから。
かと言って、自分のスタイルを捨てろと言っているわけではない。確固たる自分のスタイルはあって良いと思うし、あるべきである。しかし、それを他人に強要しようとしたり、他人が自分のスタイルに合わせてくれないからと言って、他人のプログラムを（あるいは、他人そのものを）拒否しようとするのならば、それは間違っていると言いたいだけである。
第66回 地球滅亡へのカウントダウン（yaneGameSDK::CPlaneについて） 99/7/27
そろそろ７月も終わろうとしているけれど、地球は、本当に滅亡するのか？ちょっとは、滅亡することを想定して人生設計を練っている者の身にもなってみて欲しい。（んな奴、いないって．．．）
ちなみに、やねうらおは、フランス語がめっちゃ好きだったので、ノストラダムスの予言を原書で読んだことがある。予言ちゅーか、あれは単なる詩だと思う。詩だからして、音韻を踏まなければならないだとか、いろんな制約があって作るのは大変そうだ。内容はたとえば、当時の時事ネタを、皮肉って抽象的に書いているだけのような気がする。それを馬鹿な翻訳者が日本語にするときにわけわからん翻訳をしただけのことなのだが、やっぱし世論のチカラとかなんかで、地球さんも滅亡しないのかな〜なんて思わないでもない。
さて。今回から、数回にわけて、yaneGameSDKの解説をしていかねばならない。解説と言っても、使用説明ではなく、内部の実装についてなのだが．．．。えっ？早くサンプルプログラムを提示しろだって？それは、ちょっと待って！サンプルプログラムを提示しちゃうと、プログラムが組めちゃうでしょ。（当たり前） そうすると、今度バージョンがあがったとき、SDKの仕様が変更になって前に作ってたプログラムが動かなくなったりすると、「やねうらおめ！インターフェイスを変更しやがったな！！」なんて、やねうらおの方に、足を向けて寝るようになるでしょ。それが不愉快なもんで（うそ） そんなわけで、もうちっと仕様が固まるまで待ってちょ．．．。
☆ class CPlaneについて
バックサーフェイスは、画面切り替え、主にｂｐｐ（bit per pixel＝色数）の変更の際にLostする。
よって、WM_ACTIVATEAPPに応じて、バックサーフェイスをRestoreする必要がある。しかし、Restoreしただけでは、まだ使えない。持っていたBMP画像も消失しているからである。
そこで、あらかじめ持っていたBMP画像名もどこかに保存しておく必要がある。おまけに、透過キー転送を設定している場合、そいつもｂｐｐの変更に伴い新しいものに変更する必要がある。
よって、ユーザーから設定された透過キーを保存しておく必要がある。透過キーの設定にはCOLORREFを使って設定するのが一般的でそのマッチングルーチンは、DirectX SDKのmiscフォルダに入っているddutil.cppを見れば良い。
あるいは、左上の点という風に、ビットマップ上の座標で透過キーを設定したいときもある。この二つの透過キー指定方式を提供する場合、どちらの方式をユーザー選択したのかも保存しておかなければならない。これだけ言えば、バックサーフェイスバッファクラスを作れば良いのではないか？という気になるだろう。
ビットマップのロード、（消失時の）リロード、透過キーの設定、あとバックサーフェイスなのだからBlt,Bltfast、保持しているビットマップ画像のサイズを取得する関数．．．などなどを詰めようとする。yaneGameSDKにあるCPlaneがまさにそれである。
yaneuraoGameSDK1.00α３では、さらに、こいつを可変長配列テンプレートCArrayを経て、CDirectDrawのメンバにして、これを描画クラスであるというような設計をしたのだが、よく考えたら、このような設計は、よろしくない。可変長配列にしているところらへんは、まだ誠意が感じられるが（自分で言うか？）、これが固定配列だった日にゃ、プログラミングセンスを疑われるというものだろう。
この可変長配列を使っても、ユーザー側で、あらたにCPlaneを単独で使用できない。なぜかというと、WM_ACTIVATEAPPに応じて、CPlaneのリストアを呼び出す方法を提供できないから、バッファをロストしたときに、復元できないからである。これは、DirectSoundのセカンダリバッファの設計にも同様のことが言える。
単独で使用できないということは、背景は０番、この絵は１番．．って感じで常に連番で管理しないといけないということである。非常にダサイ。使いたいときに、使いたいだけCPlaneを使いた〜いのである。
よって、CPlaneのコンストラクタでthisポインタをWM_ACTIVATEAPPで呼び出すべきコールバックリストに登録しておくという手段が考えられる。コールバックリストは、タイプセーフとなるように、当然CPlane*の可変長配列を、例によってCArrayテンプレートを利用して作る。yaneuraoGameSDK1.00α４では、そういう感じの実装に変更した。
細かいことだが、WM_ACTIVATEAPPが、自分のクラスにあるのが気持ち悪いから、先日紹介したCWinHookというメッセージをフックするためのクラスをCDirectDrawの基底クラスに置いて、ウィンドゥメッセージをフックし、（CWindow側で処理せず）CDirectDraw内部でDirectDrawの処理を完結させてしまったほうが良いかも知れない。まあ、少なくともこれくらいせねば、DirectDrawをクラス化したとは言えないだろう。
しかし、本当にちたまさんは滅亡するのか？滅亡したら、いま作ってるこのライブラリはどうなってしまうんだ！？（んなこと知らんがな） ８月某日にゲーム出すってーから、毎日毎日、徹夜してんのに、ちっとは滅亡しないことを想定して人生設計を練っている者の身にもなって欲しい。（あんた、最初と言うてること違うがな！！）
第67回 Ｃコンパイラを実装したぜよ（yaneGameSDK::CScriptCompilerについて） 99/8/1
ゲームの納期も着々と迫っている。メールでやりとりするには、あまりに複雑なゲーム仕様なもんで、必要な部分はカスタマイズできるようにしとくから、何とでもやってくれとスクリプトを作った。スクリプトというと、フツー、簡単な言語セットを想像するらしく、クライアントもアリスソフトのsystem35とか、その程度のものだと思われていたようだが、あんな一文字や二文字命令なんて気持ち悪いものをやねうらおの身体がアクセプトするはずもなく、１日でＣ言語のサブセットのような言語を実装した。時間がなかったので、型や構造体はサポートしていないが、紛れもないＣ言語である。
ついでに言えば、Ｃ言語の醜いfor文は排除して、永久ループを作るloop文と、loopから抜けるbreak文を用意した。こっちのほーがよっぽどすっきりする。また、breakのあと数値を指定すれば複数のloopから一気に抜けることも可能である。本来、制御構造とは、こうあるべきなのだ。whileやrepeatなんてうざったいだけである。
そのあと、
alt {
case x==1 : y=10;
case x==2 : y=20;
case x>=3 : {
y = 30;
x = x +1;
}
}
のように、条件選択文を用意した。Ｃ言語では、if 〜 { } else if 〜 { } else if 〜{ }となって、まったくもって汚い。非常に見通しも悪い。まあ、きちんとstatement_sequenceを実装してるから、そのように書くことも出来るが、自分ではそんな風に書く気にはとてもなれない。
あと、switch〜caseも没である。caseラベルをすべて洗い出さないとジャンプテーブルを利用した最適化が出来ないし、caseのあとのbreak忘れてバグるようなことがあってはいけないんだってば！
さらに、これをインタプリタ方式で実行するだなんて、やねうらおのベルリンの壁ほどの高さを持つプライドが許すはずもなく（ベルリンの壁はとっくの昔に崩壊しとるっちゅーに．．．）、これ用の仮想言語を作り、それを実行するCVirtualCPUという仮想ＣＰＵのエミュレーティングクラスを実装した。おかげで、阿呆な型チェックをして馬鹿遅いVisualBasic5.0と同等かそれ以上のものが出来上がってしまった。本当は、こんなことまでクライアントは要求していなかった。正直言って、やりすぎである。（余談ではあるが、yaneGameSDK1.00α4の段階ではまだコード生成にバグがいろいろあって、そのあとバグを一掃したんで、このあたりの機能を使うのは次期バージョンからにしてください:p）
ただでさえ睡眠時間が限りなく０に近い状態が続いているというのに、わざわざ自分から苦労する道を選ぶとは、やねうらおは死に向かって邁進しているレミングスであると言われても仕方がない。
なんか、言語関係のことになるとついムキになってしまう。それと言うのも、やねうらおは、「はじめに言葉ありき」だと信じている言語至上主義者であって、実は、その昔、京都大学にてんぷらし（＝授業料を払わずに勉学に勤しむこと。もちろん入学試験なんてものは受ける必要がない。卒業するためだけに通いたくもない学校に通っているという学歴社会の落し子に対するアンチテーゼである）、チョムスキーから、ソシュールに始まり、ラカン、デリタを学び、哲学・心理学・認知科学・人工知能の専門書と論文をひやかし半分に毎日眺めていたからである。
夏の暑い日に、ゴンタ亭のから揚げ弁当（誰も知らんて）を食べながら、「ほえほえー。そうなってくると思考作用とは一体なんなんやね？思考とは、言語的媒介によって行なわれるんではないのかえ」と思った。
最後のから揚げの一個を食べるころには、「言語的媒介によって行なわれるかどうかは別としても、思考作用とはつまり、ヒューリスティックなプロダクションルールによってルールないしメタルールをimplicitないしexplicitに生成していく過程なのではないかえ」と思うようになった。最後のから揚げは、ちょっとこげていたことが、やねうらおを不幸な気持ちにさせた。（そんなん、知らんがな）
「だけど、その元となるプロダクションルールとは、誰がいつインプリメントするんや？人間は、どの段階でそれを獲得するんや？それは遺伝子レベルで本能として組み込まれているのかえ？」
最後に食べた小さな半球状に盛られたサラダは、なぜか苦かった。そのことが、ますますやねうらおの気持ちを不幸にさせた。「人間が、そのような知性を獲得するのが、ア・プリオリであるかア・ポステリオリであるかという議論にはそもそも意味があるのか？あるとして、それは、このサラダが苦いことより重要なことなのか？概念の自動獲得機構をコンピューティングする為には、初期状態で概念を敷延させるだけの、ミニマルセットが必要だとしても、人間の場合、それが結局は神経細胞ネットワーキングの挙動としてインプリメントされているのであって、それは複雑系なのだから、もとより単純なニューロン細胞の挙動に還元できるわけでもなく、そんなことより重要なことは、そもそも、このサラダは、腐っているのではないのかということであって．．．」 しばらく考えていると急に腹部が猛烈に痛くなってきた。オーモウレツ〜とか、なんか場違いのギャグを言いながら救急車で病院に運ばれた。
次の週、ゴンタ亭は潰れていた。聞いた話では、なんでもゴキブリのから揚げを出して、営業停止処分になったそうだ。本当か嘘かは知らないが、多分嘘だろう。ゴンタというと、ＮＨＫの「できるかな」しか思い付かないやねうらおにとって、ゴンタ君が「うほほ・うほほ・うほほ〜！」とか言いながら、から揚げを揚げていたのではないかと思う。ノッポさんがあっちを向いている間に、自分はから揚げをつまみ食いし、数が合わなくなったから、ゴキブリをスリッパでたたいて中に入れたのではないかと思った。（やはり、そのときは、手を口に当てて、しめしめのポーズをしたのではないか） あるいは、ノッポさんのことだから、紙とハサミとセロテープでから揚げを作っていたのではないか。あのから揚げは、紙とセロテープを揚げたものだったのではないか。いや、そうだったに違いない。そういや、あの店は、ノッポさんが店長だったような気がしてきた。そうだ。いつもゴンタ君が調理していたような覚えもあるぞ。まったくもって、嘘のような嘘の話である。（それやったら、まるっきりウソの話やないかい！）
第68回 スーパープログラマの給与ベースについて（給料少ない．．．？） 99/8/5
やねうらおは、いま、会社では専任職（？）である。誰とも組んでいない。一人で、のほほんと研究・開発をしている。会社での給料は、正直言ってあまり良くない。これで仕事がきつかったら２秒で退職しているが、まあ、それなりに楽チンぽんなので、のほほーんとやらせてもらっている。しかし、いまは、めちゃんこ忙しいのである。家が本業、会社はクラブ活動！と思っているやねうらおにとって、クラブ活動ばかりが忙しくって学業に専念できないのでは、タマランチ会長なのだ。（なんのこっちゃ）
今日も、隣の席で作業している同僚が、電話で営業相手に喧嘩していた。うちの会社の営業マンは、どうも質が低いのか無茶ばかり言ってくる。彼は、いま、チャゲアスのコンサートの為の舞台装置を設計しているのだが、納期がもう間近に迫っているというのに、担当営業マンに、いまから変更をするように頼まれているようだ。お客さんの無理な要望をなんとか取りまとめ、うちの会社の都合も考えうまく折衝するのが営業マンの役割であって、単なる御用聞きしか出来ないような営業マンなら、いらないのである。うちの営業マンと来たら、そりゃもう、お客様の立場に立ってハイハイ聞いて、設計に無理ばっかり言ってくる。お客さんにしてみたら、いい会社なのかも知れないけれど、設計に余裕がなく、土日も出勤、お盆休みも返上せねばと言っているときに、まだいまから仕様変更！とか言われると、もう死ぬしかないのである。暑さのせいもあってか、あまりの無茶な営業マンの要望に、突然彼がプッツンしてしまった。「もー！チャゲンなよ！こっちは短納期で難しい仕事、アスかっとんねや！！」まったくもって意味不明な日本語だが、なんとなく気持ちはわからんでもない。やねうらおの日本語が最近、ブロークンしてきたのも、このような粗悪な周辺環境が影響しているのではないかと思わんでもない。（日本語がブロークンなんは、もとからや＞俺）
まあ、来年には、いまの会社をやめて、東京にある某ゲーム会社のチーフプログラマーに就任する予定である。そちらのほうも、給料は、正直言って、あまりよろしくない。東京でワンルームを借りて生活したりすると、いまよりも遥かに生活水準が低くなってしまうこと必至である。決して、お金が欲しくて働いているわけではないので、少ないからどうとか言う気はさらさらないのだが、これは、果たして相場なのかということは大いに興味がある。エンジニアにとって、給与は、技術力を評価するひとつのバロメータであるからだ。
技術情報系の就職誌を見ると、ＪａｖａとＨＴＭＬがちょっと出来るだけで給料三十数万保証なんてざらにある。また、お叱りを受けるかも知れないが、Ｊａｖａなんて阿呆みたいな言語だ。暴れハッチャクなら逆立ちしながらでも覚えられるだろう。（いまどきの子供は知らんて＞暴れハッチャク） ＪａｖａとＨＴＭＬが出来るだけで、給料三十数万保証だなんて、どこか間違っているような気がしないでもない。そりゃ、世のなかにはニーズってもんがあって、それとのバランスで給料が決まるんだろうけれど．．．。
さらに悪いことに、僕の知人のハナクソプログラマのＮ君は、派遣社員であり、月に４０数万もらっているそうである。はっきり言って、彼の技術力たるや、見るに無残なものがある。「そもそも、君は、２０行以上のまともなプログラムを組めんのか？」とよく彼に冗談で言っているのだが、まー、そのへんからして怪しげな人間である。こいつでさえ月に４０数万。うーん。そんなん聞くと、俺の人生って、一体なんなんやーとか思ってしまう。俺がいままでしてきたことって、間違ってたんかー？とか。
結局やねー、ゲームプログラマなんて、やっぱあかんなー世間でなめられとんなー、とか思うんよ。大手のゲーム会社とかでは、ある意味、単純労働やと思われてんやろなー。確かに、そーゆー面も多々あるし、プログラムがある意味＜作業化＞されているからこそ、ロジックのロの字も知らんような連中でも、ある程度の生産性を叩き出せるのだろう。
企画とかクリエイティブな部分は、プランナーやらゲームデザイナーが行なって、音楽は、音楽、ＣＧはＣＧ、プログラムはプログラムと分業化がなされると、プログラマというのは、定められたことを定められたように行なうプログラムを書くことが仕事であって、そこに独自の仕様を盛り込むことは許されない。そういった場合、優秀なプログラマと無能なプログラマとの差は、バグの少なさや、完成までのスピードなどだけしか残らない。（まあ、それ以下の無能プログラマでは一生かかっても完成にすらこぎつけられないのだが、そういうのは論外である）
もちろん、バグの少ないプログラムを書くのには、かなりの技術とノウハウが必要だし、まして、それを早く仕上げようと思えば、なおさらである。しかしやねー、そういうのは、クリエイティブな仕事とは言えない。プログラミングが単なる技能であり、お稽古事の延長でしかないのならば、それほどつまらないことはないだろう。これを読んでいるプロクラマ諸氏よ。もっとアグレッシブであれ！