ネタもと→「ローグで考えるソフトウェアの老後」(107stepsさん)（まっちゃ139・わんくま同盟合同勉強会）

「ROGUE」というゲームをご存じでしょうか？ご存じない方は、Wikipedia を読んでもらうとして、話を進めます。

この「ROGUE」というゲームは、1980年頃に、BSD UNIX で作成されたものです。1980年というと、昭和55年。私は小学5年生でした。28年も前の話ですね。

コンピュータがどうだったかというと、NEC の PC-8001 の発売が1979年。PC-8801 が、1981年。ちょうどそんな頃です。8ビット機が主流でした。

この時代に作られたゲームが、今でも動いています。恐るべし UNIX！！

で、そのゲームに、ちょっとした“バグ”があったということです。このゲーム、主人公キャラクターの移動は [h][j][k][l] で行います。これで一歩動きます。でも、「部屋の端まで移動したい」というときに、[h][h][h] と押すのは面倒なので、[Shift]+[H] で一気に移動できます。

この、「一気に移動できる」というところのコードを見てみると、キャラクターを書いて、消して、書いて、消して…という作業を丁寧にやっているということです。なので、ここに sleep をかませば、「勝手に移動」に変わる、と。

なぜこんな単純なことが、今まで放っておかれたのか？おそらく、1980年当時は、CPU が非力だったので、wait 処理を入れなくても「勝手に移動」だったのではないか？というのが、107stepsさんの考察でした。そして、1980年当時でも、CPU などの高速化は予見できたはず。もっとハードウェアの進化を見据えてソフトウェアのコードを書く必要があるのではないか？ということでした。

考察についてですが、おそらく、半分正解。

当時は、メイン コンピュータに対して、キーボードとディスプレイだけの端末からアクセスしていたと思います。そしてこの2つの間の通信速度が遅かったのではないかと思います。いや、実際に遅かったのだけど。キーを押しっぱなしにすると、キーバッファにたまって制御ができなかったのだと思う。そして、転送速度が遅いから、「勝手に移動」になっていたのだと思う。

私が遊んだのは1990年頃ですが、当時の SunView では tty の通信速度をエミュレートで変えることができました。で、遅くして遊ぶと、「勝手に移動」になっていたので。

CPU 速度によるウェイトのかけ方については、どんどん速いのが出てきた 386 や 486 の頃に、話題になりました。「＊＊、486DX4 だと速すぎてついてけねー」とか。この頃、「CPU スピードに依存しないウェイトのかけ方」として、単に sleep (NOP) して待つのではなく、単位時間あたりに何回割り込みを入れるとか、前回実行からどれだけ経過したからもう一度実行するとかの方法が説明されていました。

ってところは、今回のエントリのメインではなくて。

ソフトウェアというか、コードの寿命です。みなさん、今自分が書いているコードが、どれくらい後まで使われることを想定して書いているでしょう？

私が業務で関わったもので、最短のものは J-Phone の「ブリッジメール システム」というシステムです。昔、携帯電話のメールは、音声を聞いてからプッシュ音で送信していました。そのため、キャリアによってガイダンスが違い、キャリアを跨いでメールを送ることはできませんでした。それを J-Phone は他社との回線契約をし、音声認識装置を挟んで、自社ユーザーから他者ユーザーへメールを送信することができるようにしました。（自社ユーザー → 自社サーバー → 自社 NTT 契約端末 → 宛先）

このシステムがなぜ短命だったかというと、すでにインターネット化が始まっていたからです。そのため、3年ほどで役割を終えました。

その他、社会インフラを提供する会社のシステムで、いくつかのリプレース案件に関わりました。それらも、約10年で役割を終えています。1990年代の終わり頃、「2000年問題」という「問題」が取り上げられました。それまで西暦の下2桁だけで年を表していたのですが、西暦2000年、つまり「00年」になると、「2000年」なのか「1900年」なのかわからなくなる、という問題です。

似たような問題に「2038年問題」というのがあります。こちらは日付を表すのに通算秒を使っているのですが、オーバーフローしちゃうよー、という問題です。

さて、こういった問題を含んだシステムは、いったいどれくらいの期間使われることを意識して、組まれたのでしょうか。

1990年に働き始めた私の周りでは、2000年問題はあまり「問題」ではありませんでした。主に UNIX を使っていたので、すでに年は4桁で持っていたからです。それでも、2038年問題はあります。「30年も使わないだろう」と思っていたのですが、金融系では30年後40年後の日付を扱います。聞いた話では、「西暦だと桁が多いから、和暦で計算する」場合もあるようです。

CPU のアーキテクチャが変わることも予想されます。数年前まで Linux を含む UNIX 系の OS は、Intel CPU では動きませんでした。そのため、バイトの並びが違います。コンパイラが吸収する？いえいえ。通信していると、その違いが命取りになります。画像フォーマットである JPEG では、そのことも考えてか、ヘッダの中にどちらのバイト オーダーで記述されているかを指定します。

セッションでは、「未来を予測してコードを書く」といわれていました。いったい、いつまで使われることを想定し、その時のどんなことを予測してコードを書けばいいのでしょう？