The Story of Mel - For longer date than mine.

（以下の記事は2006年3月5日に書いたものです）

ハッカー界に伝わる英雄叙事詩「The Story of Mel」の翻訳です。有名な割に Web 上で読める日本語訳がなかったので訳してみました。誤訳や間違いはコメント欄で指摘してくれれば幸いです。

プログラミングの硬派な面について捧げられた最近の投稿で、
次のような率直で大胆な宣言がされた：

本物のプログラマは FORTRAN で書く。

恐らくいまならそうだろう
ライトビールと電卓と”ユーザフレンドリ”なソフトウェアが支配する
この堕落した時代では
しかし古き良き時代、
”ソフトウェア”という言葉が滑稽に聞こえ
本物のコンピュータがドラムと真空管でできていた時代、
本物のプログラマはマシン語で書いた。
FORTRAN でない、RATFOR でもない、
アセンブリ言語ですらない
マシン語で。
生の、何の飾りもない、
謎めいた16進数で
直接。

すべての新しい世代のプログラマが
この栄光ある過去を知らずに育たぬよう
私には世代を乗り越え、最善を尽くして
本物のプログラマがどのようにしてコードを書いたかを
語るべき義務がある。
彼をメルと呼ぼう、
それが彼の名だったからだ。

メルと初めてあったとき、私はロイヤルマクビーコンピュータという
今はもうなき、あるタイプライタ会社の子会社に就職したときだった。
当時 LGP-30 という
小さくて安い（当時の基準で）、
ドラムメモリのコンピュータを作っていて、
大幅に改良されたRPC-4000 という、
新たな機種の製造を開始したばかりだった
大きくてより優れた、速いドラムメモリのコンピュータだ。
コアメモリは高すぎて、
いずれにせよここでは使われなかった。
（君たちがこの会社やコンピュータを知らないのはこのためだろう）

私はこの新しくてすばらしいコンピュータのための
FORTAN コンパイラを書くために雇われていて
この驚異の世界へのガイド役がメルだった。
メルはコンパイラを是認しようとしなかった。

「プログラムが自分自身を書き換えられないのならば」*1
彼は尋ねた、「そんなもののいったい何がいいんだ？」

メルは社内でもっとも有名なプログラムを16進数で書いた。
それは LGP-30 上で動き、コンピュータショーで
将来の顧客を相手にブラックジャックをやるプログラムだった。
その効果はいつも劇的だった。
どのショーでも LGP-30 のブースはいっぱいで、
IBM のセールスマンはそこら辺でおしゃべりをしながら立っていた。
このプログラムが本当のところコンピュータの売り上げに貢献したかどうかは
問題にはならなかった。

メルの仕事はこのプログラムを RPC-4000 向けに書き直すことだった。
（移植？なんて意味だい？）
この新しいコンピュータは 1+1 アドレッシング方式を採用していた、
マシン命令ごとに、オペコードと必要なオペランドのアドレスに加えて
回転するドラム上で次の命令がどこに位置しているかを示す
2番目のアドレスが含まれていた。

現代的な言葉で言えば
すべての命令の後ろに GO TO がくっついているといえよう。
これを Pascal のパイプに入れて燻らせればよい。

メルは RPC-4000 を愛していた
自分のコードを最適化できたからだ。
ドラム上にうまく命令を配置して
ひとつのジョブが終わったと同時に、
次の命令がちょうど読み取りヘッドの真下に来ているという具合だ。
このような仕事を行う”最適化アセンブラ”というものがあったが
メルはこれを使うのを拒否した。

「君は最適化アセンブラがどこに何を配置するかわからないだろ」
彼は説明した、「そんなものを使うと別々の定数を使うことになる」

私は彼の言わんとすることを理解するまで長い時間がかかった。
メルはすべてのオペコードの数値を知っており、
自分自身でメモリ番地を割り当てていた
彼が書いた命令はすべて数値定数として扱うことができた。
彼は前に加算命令として使用した命令をもってきて、
それが正しい数値をもっていれば
それを使って乗算したりした。
彼のコードを他人が修正するのは困難だった。

私はメルが手で最適化したコードと
最適化アセンブラにマッサージさせた同じコードを比較してみたが、
いつもメルのコードの方が速かった。
”トップダウン”法と呼ばれるプログラム開発手法が
発明される以前のことだったし、
たとえそれが発明されていたとしてもメルは使わなかっただろう。
彼はプログラムの一番内側のループを最初に書いて
それを最適なメモリアドレスに配置した。
最適化アセンブラはそんなふうにやるほど賢くなかった。

メルは決して遅延ループを書かなかった
強情なフレキソライタが、
正しく文字を出力するためにそれを要求していてもだ。
彼は遅延ループが必要とされるとき
読み取りヘッドのすぐ後ろに次の命令を配置した。
ドラムが次の命令を見つけるために
もう一回転しなければならないようにしたわけだ。
彼はこの一連の処理について忘れがたい用語を作り出した。
”最適”という言葉は
”一意的”という言葉と同様に絶対的な意味を持つにもかかわらず
相対的な意味を持つ動詞として使われるのが一般化してしまった。
”まったく最適ではない”、”より最適ではない”、
”あまり最適ではない”というように。
メルはもっとも遅延する配置を
”もっとも最悪”と呼んだ。

彼がブラックジャックプログラムを完成させて
走らせた後に
（「初期化部分も最適化したよ」と彼は誇らしげに言った）
営業部から仕様変更を受け取った。
そのプログラムは
”カード”をまぜて”親”から配るために
エレガントな（最適化された）
乱数ジェネレータを使っていたが、
それを公平すぎると思ったセールスマンがいた
なんせ顧客でさえときどき負けたのだから。
彼らはコンソールのスイッチをオンにすると
オッズを変化させて顧客が勝つように、
プログラムを修正するようメルに求めた。

メルは渋った。
彼はこれを明らかな不正と思ったし、
実際そうだった、
加えてこのことが彼自身のプログラマとしての誠実さを侵害するとして
プログラムの修正を拒んだ。
営業主任がメルと話し、
上司が彼と話し、
上司にせかされた同僚が彼を説得しようとした。
ついにメルは降参し、
コードを書いた
しかし彼は条件を逆にして、
スイッチをオンにすると、
プログラムはいかさまをして、いつも勝つようにした。
メルはこのことに喜び、
自分の潜在意識はコントロールできないほど倫理的であると主張し、
断固として修正を拒否した。

メルがもっと $青い牧草$ を求めて会社を去った後、
上司は私に例のコードを調査して
条件の部分を見つけたらそれを修正するように頼んだ。
メルのコードを追いかけるのは本当に冒険だった。

私はプログラミングが芸術のひとつの形態だと感じることがよくある、
それは同様の神秘的な芸術に熟練した人たちでなければ
その本当の価値を理解できない芸術だ。
このような性質をもつ芸術であるがために
美しい宝石や輝かしい大成功が
時として永遠に、
人々の視界や賞賛から隠されたままなのだ。
しかし君たちはコードを読むことによって
それを書いた人間について多くのことを知ることができる。
たとえそれが16進数で書かれたものであっても。
メルは世に知られていない天才だと私は思う。

私が最も衝撃を受けたのは
条件判定を持たないたわいないループを見つけたときだった。
条件判定なし、一切なしだ！
常識的に考えてそれは閉じていなければならず、
そうでなければプログラムは果てしなく永遠に回り続けることになる。
ところがプログラムは正しくそのループを通って、
安全に外に出てしまう。
私はこれを理解するのに2週間を要した。

RPC-4000 は真に現代的な
インデックスレジスタ *2と呼ばれる仕組みを備えていた。
それを使うとプログラマは
インデックス付き命令を内部に含むループを書くことができた。
ループを回るたびに、
インデックスレジスタ内の数値が
命令中のアドレスに加算されるので、
連続した次のデータを参照できるのだ
ループを回るたびにインデックスレジスタの数値を
増やすだけでいい。
しかしメルは決してインデックスレジスタを使わなかった

代わりに彼は命令をマシンレジスタに入れ、
そのアドレスに1を加えて
またレジスタに戻した。
こうして彼は変更された命令を
レジスタから正しく実行できた。
ループはこの演算の実行時間を
考慮して書かれていた
この命令が終わると同時に、
次の命令が読み取りヘッドの下に来るように
それ行け。
しかしループには条件判定がないのだ。

私が重要な手がかりをつかんだのは
命令語の中のオペコードとアドレスとの間にある
インデックスレジスタのビットが
オンになっているのに気づいたときだった
メルはインデックスレジスタを決して使わなかったので、
そのビットは常に0であるはずなのに。
光明が差し込んできたとき私はほとんど目がくらみそうになった。

彼はメモリの先頭近くに
使用しているデータを配置していた
それは命令によって番地付けできる最大の場所なので
最後のデータが処理された後、
命令アドレスのインクリメントによって
桁あふれした。
そのキャリーによってオペコードに1が加えられて
オペコードは命令セットの中で次の命令を表すものに変身した。
ジャンプ命令だ。
次のプログラム命令はアドレス位置0にあるので、
プログラムは楽しそうに動き続ける。

あれ以来私はメルと連絡を取っていないので、
過ぎ去りし日々のプログラミング技術を流し去った
変化の洪水の中で
彼が屈してしまったかどうか知らない。
私は彼がそうしていないと思いたい
とにかく、
私はあまりにも大きな感銘を受けたので
例の条件の部分を探すのをあきらめ、
上司に見つけることができなかったと報告した。
上司は驚いた様子もなかった。

私が会社を去るとき
ブラックジャックのプログラムはいまだに
スイッチを入れるといかさまをやっていて、
私はそうあるべきだったのだと思った。
本物のプログラマのコードをハックする気には
到底なれなかったのだ。

これは自由詩であろうがなかろうが、ハッカー界における偉大な英雄叙事詩である。ハッキングの美意識と心理について捉えた描写は、このテーマについて論じられたすべての学術書よりも優れている。（これと正反対の見方については「本物のプログラマ」参照）

［1992 追伸 - （この詩の）作者が言うには「ネットへ投稿したオリジナルは自由詩ではなく、また似ても似つかないものだった。直接的な散文形式で、行の長さがそろっていない段落からなっていた。ネット上をバウンドするにつれて、今のよく知られている自由詩の形式に修正されていったんだろう。違う言葉で言えば、ネット上でハックされたといえよう。それはある意味妥当なことだと思う」。作者はオリジナルより今の自由詩の方が好きだと付け加えた…］

［1999 更新: メルのラストネームは今では判明している。LGP-30 のマニュアルに「ロイヤルマクビーのメル・ケイが ACT 1 システムの大部分のプログラミングを行った」と言及されている。］

［2001: ロイヤルマクビーの LGP-30 にまつわるもう一つの有名な話が明らかになった。気象学者のエドワード・ローレンツが「バタフライ効果」と計算機カオスを発見した1961年に LGP-30 を用いて気象シミュレーションを行っていたことが判明。どういうわけか、これは私用に供していたようだ。］

［2002: LGP-30 のプログラミングマニュアルのコピーが http://ed-thelen.org/comp-hist/lgp-30-man.html にある。］

*1:主記憶上の命令をデータと見なして書き換える（あるいはデータを命令と見なして実行する）ことができるのがノイマン型コンピュータの大きな特徴だが、様々な理由（デバッグが難しくなる、メモリ管理が大変等々）から今日ではそのようなプログラミングは滅多に行われない。自己書き換えをサポートしている高級言語は少なく、LISP がその代表格。自己言及は計算機科学や数学基礎論において本質的な概念である。

*2:アドレス修飾のために使うレジスタ。メインメモリのアドレスのオフセット（C 言語で言うところの配列の添字（a[i] の i）にあたる）を格納する。インデックスレジスタが発明されてから（発明当初は B レジスタと呼ばれた）自己書き換えプログラミングは廃れていった。