2013年09月16日

Programming with Punched Cards(パンチカード時代のプログラミング)を読む

こんな文章を読んだ。

Programming with Punched Cards
http://www.columbia.edu/cu/computinghistory/fisk.pdf

まだプログラムがパンチカードによって行われていた1973年。急遽、プログラミングをやるよう上司から命令された男性のお話。ライトな文体で書かれていて面白かった。

せっかくなので、あらすじがわかる程度に適当に訳してみる。

何をとち狂ったのか、うちのボスが急に「プログラム書いてくんない?」と言ってきた。私がプログラミングに対する知識がまったくないと知ってるにも関わらずだ。

命令されたからには仕方ない。私はプログラミングに挑戦することにした。

まず最初に「プログラマってどんなふうにプログラムを作ってるんだ」ってことを調べることにした。IBM 360が置いてあるでっかい部屋があることは知ってた。あと、彼らがパンチカードの入った、高さ8cm、幅20cm、奥行40cmくらいの箱(というかトレイ)をそこに運び込んでることも。

プログラマのオフィスに行ってみたら、パンチカードの箱がうずたかく詰まれてた。ピンクやブルー、クリーム色など、いろんな色のカードがあった。どれもフェルトペンで名前が書いてある。プログラマたちはパンチカードの束をパラパラとめくっていた。

パンチカードは1枚ごとに1つの命令が記述されていて、あの箱には2000枚のカードを入れることができるらしい。1箱以上のプログラムを書くのは避けたいところだ。重そうだし、箱ごとの順番間違えたりもしそうだ。幸い、私が作るプログラムはそんなに大きい物じゃないので大丈夫だろう。

プログラムを書くには、まずコーディングシート(訳注:プログラムを書くための専用紙。方眼紙に似ている)に手書きで書く。コーディングシートには1ページで50行が記述できて、1行がパンチカード1枚に対応している。

なんとなくわかったので、実際にやってみることにした。プログラマのボブのところへ行ってコーディングシートをもらい、デスクに向かう。本を片手にコードを書いたり消したりを繰り返す。なんとか1つ、プログラムを書き上げることができた。

この後、どうすればいいかはわかってる。ラボに行って、顔見知りのキーパンチャーのマリアに挨拶する。マリアはコーディングシートが入れられた「in」のかごを指して、「そこにシートを入れて、明日取りに来て」と言った。翌日、マリアのところへ行ってみると、「out」のかごにゴムバンドでまとめられた私のコーディングシートと厚さ1cmくらいのパンチカードが置いてあった。

デスクに戻ってパンチカードの束を見る。これをどうすればいいのだろう。とりあえずカードの内容がコーディングシートと合ってるかどうか確認してみることにした。

パンチカードには小さな穴がいくつも空けられている。それがコードを変換したものだというのはわかるのだけど、手作業でそれをデコードしようとしたら尋常じゃない時間がかかるだろう。どうやってパンチカードの内容を確認すればいい?

カードを持ってマリアのところへ聞きに行ってみる。マリアは1台のマシンを紹介してくれた。「このパンチカードインタプリタを使えば、パンチカードの内容を印字してくれるよ」

使ってみると、パンチカードの上部に内容が印字された。これでパンチカードの内容もわかった。タイプされた内容に間違いがないことも確認できた。

さて、次はどうすればいいのだろう。これをIBM360に読み込ませればいいのはわかるのだけど。ボブに聞いてみよう。

「まず初めに」と言ってボブはパンチカードを指した。「そのカードはまだプログラムじゃない。俺達の間でソースデッキって読んでるものだ。それをコンピュータに読み込ませて、コンパイラを実行する。そうするとコンパイラは別のパンチカードを生成してくれる。そうしてできるのが、プログラムだ」

なるほど。プログラムを書くには2つのステップが必要なのか。誰かの手によって書かれたコンパイラというプログラムが、私が書いた「ソースデッキ」を読み込む。そうすると別のカードが出力される。それが完成した私のプログラム、というわけだ。

ボブの説明に従って私はラボに行き、入り口にあるカウンターを確認した。カウンターは「in」と「out」のセクションに分けられていた。ラボの中には許可された人間しか入れない。私は「in」セクションにソースデッキを置いた。「in」セクションには例の箱に入ったパンチカードがいくつか置いてあった。また待たなければいけないようだ。どれくらい待てばいいのだろう? わからない。

この後、何が起こるのかは分かっている。オペレーターが私のカードを回収して、コンピュータのリーダーに読ませる。ラボの窓からコンピュータが動いているのは見える。オレンジや緑のライトが明滅している。コンピュータと直結したタイプライターがあって、オペレーターはそれを使ってプログラムを操作している。

私はしばらく「in」のカウンターの前で待ってみた。オペレータは大きな箱を1つ回収した後、姿が見えなくなった。30分くらいしてからもう1度見に行ってみたけど、私のソースは「in」セクションに置かれたままだった。仕方ない。今日は帰るか。

翌朝、ラボに行ってみると「in」セクションは空になっていた。「out」セクションにはたくさんの結果が置かれていた。私の名前が書かれたソースデッキとプリントアウトされた紙(3mmくらいの厚さしかなかった)がそこにはあった。

デスクに持って帰って出力された紙を確認してみる。最初の数枚は、コンパイラが動作した詳細が印字されている。紙しか出力されておらず、プログラムのパンチカードは出力されてないようだ。なぜないのだろう?

さらにページをめくると、プログラムがソースを読み込み始めた記述が見つかったのだが、すぐにエラーになってしまている。コンピュータめ。何かしくじったか?

ラボに行ってオペレーターに「なんか結果おかしいから。もう1回やってくれよ」と言いに行く。オペレーターは「本当に? もうすぐ今動いてるプログラムが終わるから、少し待ってて」と言って、私のパンチカードを優先的に処理してくれた。(後で考えると、悪いことをしたと思う)

しばらく待つと、コンピュータの出力が終わった。中身を確認する。まただ。プログラムのパンチカードは出力されてない。同じ厚さのプリントアウトされた紙が出てきただけだ。

何がいけないのだろう? 参考にした本を取り出して、ソースと比べてみる。しばらくして、必要なカンマが1つ抜けていることを発見した。コンピュータめ。カンマがないことに気づいたんなら、なんで直してくれないんだ? 使えないヤツだ。

私は抜けていたコンマを加えて、マリアのところに持っていった。マリアは仕事の手を止めてすぐに新しいカードを作ってくれた。出来上がったカードを間違っていたカードと入れ替えて、再度、ラボの「in」カウンターに置く。しばらく待ってから「out」のカウンターに行くと、またエラーメッセージが出力された結果が待っていた。さっきとは違うエラーだった。

間違っていた箇所を探して、マリアのところへまた持っていく。マリアは「こっちのスペアのキーパンチ使ってもいいよ。1枚のカードを直すだけの時は、自分でやっちゃった方が速くできると思うから」こうして私はプログラムだけじゃなく、キーパンチを使うことも覚えた。

最初と比べると、だいぶ手順が効率的になってきた。マリアの手が空くのを待つことなくソースの修正ができる。それまでは1日に2回〜3回の修正しかできなかったけど、今は4〜5回コンパイラにかけることができる。数日後、いつものようにラボの「out」カウンターに結果を取りに行くと、1cm強の厚さの出力がされていた。プリントアウトされた紙と、2つのパンチカードの束! ソースデッキと、新しく作られた私のプログラムデッキ!

ようやくプログラムを動かすことができるようになった。プログラムのパンチカードはソースより小さな穴が空けられていた。文字がタイプされておらず穴の数も多い。レースのように見えた。さて、出来上がったこのプログラムはどうやって解読すれば良いのだろう。

ボブに聞いてみると「これはバイナリコードだ。コンピュータにしか理解できない。頑張れば理解出来なくもないけど、その必要はない」と言われた。

私は今までのとは別のリクエストフォームに必要項目を埋めて、新しく出来たプログラムデッキを「in」のカウンターに置いた。翌日、これまでとは違ったプリントアウトされた紙が返ってきた。最初の数ページを見てみる。私のプログラムが開始されて、コンピュータを操作していることがわかる。私はコンピュータに一覧を出力するように命令していた。ちゃんと出力されている。どうやら成功したようだ。私が書いたプログラムが、動いた!

でも、ちょっと待て。このプログラムは正しく動いているのだろうか。おそらく、違うだろう。今の私にはわかっている。多くのプログラマはデバッグに大半の時間を使っている。おそらくたくさんのエラーやバグがこのプログラムには潜んでいるはずだ。それを直していく必要がある。

プログラムのもっと詳細な情報がプリントアウトされる方法を学び、バグとその原因を探していく。原因を見つけたらコーディングシートを書き直す。パンチカードを作り直して、新しいカードをと入れ替える。プログラムが大きくなると、ソースの修正は難しいものになっていった。間違ったカードを入れ替えてしまったり、新しいバグを埋め込んでしまったり。私は慎重に慎重にソースを更新するよう努めるようになった。

更新したソースを「in」のカウンターに置いて、しばらく待ってから「out」のカウンターに行く。新しいプログラムのパンチカードが出力されたら、それを実行してもらう為のリクエストフォームを書く。その繰り返し。

ある日、ボブが「もうデバッグに入ってるなら、コンパイルと実行は一緒にリクエストできるぜ?」と教えてくれた。この方法を使うと、1日に今までの2倍の回数プログラムを実行することができた。

徐々に私はデバッグ以上にプログラムとはどうあるべきかを意識するようになっていった。プログラムは複雑になり、コードの量は増大し、私のソースは数センチの厚さにまでなっていた。私はソースをゴムバンドでまとめるようにした。

数週間が経った。ある日、コンピュータオペレータが言った。「これはもうカードリーダーに読ませられないな。新しいパンチカードで持ってきてくれないかな」

えっ、読めない? 1セットしかソースデッキは持ってないんだけど。バックアップでもしておかないといけなかった? そんなことをしてる人はいないだろ。

マリアを訪ねてみると「カードリーダーは繊細だから、コンディションが悪いカードは読ませられないの。そんな時の為にパンチカード複製機があるから。あなたのソースカードを貸してみて?」

たった数分で、彼女は新しくなったカードを作成してくれた。彼女はカードの端をきっちり合わせると、フェルトペンでカードの縁に左下から右上に向けて斜めの線を入れた。この線は以前見たことがある。カードの並び順がわからなくなったりしないように入れている線だ。

マリアはカードを箱に入れて渡してくれた。あのプログラマたちが使っていた箱だ! もうゴムバンドを使う必要はない。

私はプログラムのより詳細な動きを確認し、変更や追加を重ねていった。自分でカードをパンチすることもあったし、大幅な追加があった時はマリアにお願いすることもあった。

私のプログラムは徐々に信頼性を高めていった。ある日、ラボのマネージャーと話をしている時に、うちのコンピュータでプログラムを動かす時に適切なメモリ上限がどのくらいか聞いてみた。彼は話の後に「キミはラボの鍵を持っておいた方がいいね。これでいつでも入れるから」と言ってラボの鍵を渡してくれた。

私は初めてラボの中に入った。デスクサイズのディスクドライバやプリンタ、カードリーダー、冷蔵庫サイズのテープドライブが並んでいる。壁側にはマリアが使っているのと同じようなキーパンチマシンもあった。その前に座って作業していたプログラマは私を見ると、軽く手を降って挨拶し、すぐまた仕事に戻った。この場所に受け入れられているように感じた。

しかし2つの問題がすぐに気になった。1つは、寒い! コンピュータは熱を嫌う為、エアコンが可能な限り低温に設定されている。後で聞いたところでは、部屋の温度が26度を超えるとコンピュータはシャットダウンしてしまうそうだ。1度でも落ちたら大変だ。コンピュータを再起動するには数時間かかるのだから。次からはセーターを持っていくことを忘れないようにしよう。

もう1つの問題は、音。窓の外から覗いていた時は静かな空間に見えたけど、いざ中に入っていみると空調のファンの轟音が常に鳴り響いている。プリンタが整列した紙を吐き出す。急にパンチカードリーダーのホイールが回りだし、積まれたパンチカードを飲み込んでいく。磁気テープリーダーが穏やかな音で回り、ディスクドライブが不規則な音を立てている。コンピュータ自体は無音で、ただオレンジと黄色のライトを明滅させている。

オペレータが「in」カウンターに置かれた次のリクエストを運び込み、パンチカードの束をリーダーにセットする。カードリーダーは置かれた束を読み込み、結果が出力される。オペレーターは次のリクエストをセットし、出力結果を「out」のセクションに置いていく。その繰り返しが何度も行われる。

翌日、デスクでソースの修正をしている時に、何枚かのカードをフロアに落としてしまった。落としたのはほんの数枚だったので、すぐに正しい順序で戻すことができた。でも、これはインシデントだ。マリアはソースに線を引いて並び順をわかるようにしてくれた。でもその後、何度も修正をするうちにマークが入っていないカードが増えてきている。もし、全部のカードを床に落としてバラバラになってしまったら、どうなる?

さっそくボブに聞いてみることにした。ボブは「1枚のパンチカードに何文字が書けるか知ってるか?」と言った。もちろん知っている。80文字だ。「じゃ、プログラムで使う文字数は?」72文字だ。コンパイラは最初の72文字しか見ない。「じゃ、残りの8文字は何に使う?」何も。何にも使われない。「その8文字は別のことに使えると思わないか?」

なるほど、シーケンスナンバーを振るのか。

パンチカードソートマシンというものがあった。これは残り8文字に書かれたシーケンスナンバーを元に、ほんの数分で正しい並び順でパンチカードを並べ替えてくれる。修正や追加が起きた後もシーケンスナンバーを正しく保つのは一苦労ではあるけど。

私のプログラムは増え続け、カードを入れる箱は満タンになりそうなところまできた。だんだん周囲のプログラマから質問をされることが増えてきた。ボブに質問に行くことは減り、もっとプログラムの哲学的を話す機会が増えた。

ある土曜日。私はプログラムを書きにラボに向かった。スケジュールが若干遅れていたので、コンピュータを占有して使いたかったからだ。ラボに着くと、何人かのプログラマがコンピュータの回りに集まっている姿が見えた。何かまずいことが起こったのだろうか。コンピュータが壊れたのだろうか。

ラボに入ると「やったぞ」という声が聞こえた。何があったか訪ねてみると、「新しいMFTオペレーティングシステムを入れたんだ。これで一度にもっとたくさんのプログラムをコンピュータで動かせるようになるぞ!」

どうやら彼らは新しいOSを入れていたらしい。コンピュータが壊れたわけではないようで安心した。けど、どうやら今日は私が作業をする隙はないようだ。がっかりして家に帰った。

コンピュータに同時に複数のプログラムを実行させて、それでどうなるのだろう。1つのプログラムが動く速度は半分になるだけじゃないだろうか。

この時、私はわかっていなかった。この新しいOSが、パンチカードで行なってきたプログラミングにどれだけ多くの変化をもたらすかということを。



かなりかい摘んで訳したのだけど、だいぶ長くなってしまった。

この後、MFTなOSを入れたことによって大きな変化が起こり、ノスタルジックな気持ちになるお話が展開されるのだけど、その辺まで訳すと情緒が失われそうなので、気になる人は本文でどうぞ。

個人的には、これからプログラマになる人に「ちょっと(?)内容は古いけど、プログラミングってこんな感じだよ」と言って見せても問題なさそうな文章な気がした。