March 24, 1983

本物のプログラマはPASCALを使わない
- Real Programmers Don't Use PASCAL -

Ed Post
Tektronix, Inc.
P.O. Box 1000 m/s 63-205
Wilsonville, OR 97070
Copyright (c) 1982

(decvax | ucbvax | cbosg | pur-ee | lbl-unix)!teklabs!iddic!evp

　古き良き時代にたちかえってみよう–男たちと少年たちを簡単に見分けられた、コンピュータの「黄金時代」に (文学的には “本物の男たち'' と “Quiche Eaters [訳注 1]'' とよばれることもあった)。この時代、本物の男たちはコンピュータプログラミングを理解していたし、Quiche Eaters はそうじゃなかった。本物のコンピュータプログラマは “DO 10 I=1,10'' とか “ABEND'' といった具合に物事を話し(かれらはふつう、大文字、大声で話していたんだ、わかるね)、それ以外の連中は“コンピュータは難しすぎるよ'' とか、“コンピュータには馴染めないね、非人間的すぎるんだ'' なんて話していた (過去の研究 [1]では、本物の男たちは何ものにも馴染むことはしなかったし、非人間的であることを恐れなかったと指摘されている)。

　しかし、何ごともそうであるように、時代は変わった。私たちが今日直面しているのは、ちっちゃなおばあちゃんがコンピュータ内蔵式の電子レンジを買い、12歳の坊主どもがアステロイドやパックマンで遊ぶために本物の男たちをはじき飛ばす、そして誰もが自分用のパーソナルコンピュータを買って使いこなすことさえできる、そんな世界なのだ。本物のプログラマは絶滅の危機に瀕しており、TRASH-80 [訳注 2] を使う高校生にとって替わられようとしている。

　パックマンで遊ぶ典型的な高校2年生と、本物のプログラマの違いを指摘しておく必要があるだろう。この違いを明らかにすることで、こうしたゲーム少年たちに大いなる希望となるような役割モデル、つまりは理想の父親像を与えることができるだろう。また、本物のプログラマの雇用者にとっては、(人件費を大幅に抑えられるからといって) 本物のプログラマ要員を12歳のパックマンプレイヤーに置き換えるのがなぜ誤りであるのかを説明することにもなるだろう。

[訳注 1] Quiche（キッシュ）とは甘くないタルトのような菓子で、軟弱な女子供の典型的な食べ物。Quiche Eater とは、女々しい軟弱者の意味。
[訳注 2] TRASH-80 は Tandy Radio Shack 社のパソコン TRS-80 のこと。1980年頃には日本でも人気があった。

言語 (LANGUAGES)

　大衆の中から本物のプログラマを選り分けるには、彼(彼女)の使う言語をきいてみたらよい。本物のプログラマは FORTRAN を使う。Quiche Eater たちは PASCAL を使う。PASCAL を設計した Nicklaus Wirth は、かつて“あなたのお名前はどう発音したら良いのでしょう？''ときかれて、こう答えた。“名前そのまま `Veert' と読んでもらってもいいし、その返り値のとおり `Worth' と読んでもらってもいい。'' このコメントから、Nicklaus Wirth は Quiche Eater だということがわかるだろう。本物のプログラマが支持するパラメータ受渡しのメカニズムは、IBM/370 FORTRAN G and H コンパイラに実装されているように call-by-value-return だけなのだ。本物のプログラマは、ジョブをこなすのに、そんな抽象概念をまったく必要としない — 彼らはキーパンチャーとFORTRAN IV コンパイラ、そしてビールがあれば完璧に幸福になれるのだ。

• 本物のプログラマは FORTRAN でリスト処理を'する(do)'。
• 本物のプログラマは FORTRAN で文字列操作を'やる(do)'。
• 本物のプログラマは FORTRAN で経理処理を(必要ならば)'する(do)'。
• 本物のプログラマは人工知能プログラムを FORTRAN で'する(do)'。

もし FORTRAN で出来なければ、アセンブリ言語でやる。アセンブリ言語で出来なきゃ、それはやる価値がないのだ。

構造化プログラミング (STRUCTURED PROGRAMMING)

　コンピュータサイエンスの学者連中は、過去何年にもわたってさかりがついたように“構造化プログラミング''にのぼせ上がっている。連中は、プログラマが特製の言語構成と技法を使えば、プログラムはもっと解りやすくなるのだ、と主張している。連中は、どういう構成が一番良いのかはいうまでもなく、特定条件下での知見をわかりづらい学術誌の1ページにぴったり収めて出してくる場合でさえ、意見がわかれている — 誰もが納得するには、明らかに証拠不足なのだ。学校を卒業したとき、著者は自分が世界一のプログラマだと考えていた。必勝の tic-tac-toe プログラムを書けたし、5種類のプログラミング言語をこなし、1000行のプログラム、それもちゃんと動くやつも書けたからだ (本当だ!)。そこで著者は本物の世界に飛び込んだ。本物の世界で最初の任務は、200,000 行の FORTRAN プログラムを読んで理解し、そしてそれを2倍にまで高速化することだった。本物のプログラマは誰だって、世界中にある構造化コーディングが、こんな場合には何の手助けにもならないってことを教えてくれるだろう — 本物の、実力が、必要なのだ。本物のプログラマと構造化プログラミングに関する観察から、以下のことがわかる：

• 本物のプログラマは、GOTO を恐れずに使う。
• 本物のプログラマは、5ページにわたる長い DO ループを混乱せずに書ける。
• 本物のプログラマは 算術 IF ステートメントを好む — こうするとコードがもっと面白くなる。
• 本物のプログラマは自己拡張コードを書く。とりわけ、タイトなループの途中で 20 ナノセカンドを節約できる場合には。
• 本物のプログラマにコメントは不要である — コードは一目瞭然なのだ。
• FORTRAN では IF 文や REPEAT…UNTIL、や CASE 文が構造化されていないので、本物のプログラマはこれらを使わないことを気に病む必要はない。そのうえ、これらの文は GOTO 指定で必要に応じて代替可能である。

　最近はデータ構造にもいろいろな型がある。抽象データ型や構造体、ポインタ、リスト、文字列などは、一部のグループでは普及しつつある。Wirth (前述の Quiche Eater) は、プログラムをデータ構造に基づいて書くことが出来ると主張して、実際に本まで出している。だが、本物のプログラマなら誰でも知っているとおり、有用なデータ構造は配列しかないのだ。文字列も、リストも、構造体も、セットも — これらはすべて、配列の特殊な場合であり、プログラミング言語をやたらと複雑化したりしなくても、そのとおり扱うことが出来るのだ。こうした突飛なデータ型の最悪な点は、使うたびにいちいち宣言してやらなければならないというところだ。本物のプログラミング言語は、ご存知のとおり、変数名 (6文字) の最初の1文字に基づいた明示的な型設定を備えているものだ。

オペレーティングシステム (OPERATING SYSTEMS)
　本物のプログラマは、どんなオペレーティングシステムを使うのだろうか? CP/M? 禁断の－CP/M は、なんといっても基本的に玩具OSである。CP/M など、ちっちゃなおばあちゃんや小学生でも理解して使うことが出来る。

　もちろん、Unix はもう少し複雑だ — 典型的な Unix ハッカーは、今週の PRINT コマンドがなんて名前になってるか憶えていられない — しかしはっきり言って、Unix はテレビゲームの豪華版だ。Unix システムで本気で仕事をする奴はいない：UUCPネットでジョークを世界中に飛ばし、冒険ゲームとリサーチペーパーを書くだけの話だ。

　いいや、本物のプログラマはOS/370を使うのだ。良きプログラマなら、IJK305I というエラー出力の意味するところを JCL マニュアルから導き出すことが出来るだろう。優れたプログラマなら、JCL をマニュアルをまったく見ずに書くことが出来よう。真に傑出した能力を持つプログラマなら、6メガバイトのコアダンプに埋もれたバグを、16進計算機を使わずに見つけ出すことも出来よう。(著者は実際にその現場を目撃したことがある)

　OSは間違いなく素晴らしいオペレーティングシステムだ。スペースの位置をたった1箇所間違えるだけで、過去何日分もの仕事をすべて消滅させてしまうことも出来る。だからプログラミング要員への注意喚起もスムーズだ。このシステムを扱うには、キーパンチを使ってやるのが一番いい。OS/370で走る時分割システムがあるなどと主張する輩がいるが、著者は慎重に研究を重ねた結果、彼らが誤っていると結論づける。

プログラミングツール (PROGRAMMING TOOLS)

　本物のプログラマは、どんなプログラミングツールを使うのだろう? 理論的には、本物のプログラマはその手になるプログラムを、コンピュータの前面パネルから直接入力して動かすことができる。コンピュータが前面パネルを備えていた頃、これは時おり、一般的に行なわれていたのだ。典型的な本物のプログラマはブートストラップローダの16進コードを丸ごと憶えていて、プログラムエラーでシステムが破壊されるたびにトグルスイッチで入力したのだ。(その頃は、メモリはメモリだった — スイッチを切っても、どこかへいったりはしなかった。今日では、メモリは忘れてほしくないことを忘れてしまうか、あるいは忘れてほしいものまで長いあいだ抱え込んでしまうかのどちらかだ.) シーモア・クレイこそは伝説の人物だ。スーパーコンピュータ クレイ I と、コントロールデータ社のほとんどのコンピュータの発明者である彼は、実際に CDC7600 用の最初のオペレーティングシステムを、電源を入れたあと前面パネルのトグルスイッチからメモリへ直接入力したのだ。シーモア、言うまでもなく、彼こそ本物のプログラマだ。

　私の好きな本物のプログラマに、テキサスインスツルメンツのシステムプログラマがいる。ある日、重要な仕事を保存している最中にシステムがクラッシュしたというユーザから、長距離電話を受けた。ジムは電話で損傷を修復することができた。彼はまずユーザに指示して、ディスクI/Oのインストラクションコードをトグルスイッチから入力させて、システムテーブルを16進で修復し、レジスタの内容を電話での会話だけで読みとることができたのだ。教訓：本物のプログラマはふつうキーパンチャーとラインプリンタをツールとして使うが、緊急時には前面パネルと電話でこなしてしまう。

　ある会社では、テキスト処理はもはや1列に並んで 029 キーパンチャーを使う 10人のエンジニアによってのみ行なわれている。実際に、著者が働くビルにはキーパンチャーは1台もない。この場合、本物のプログラマは“テキストエディタ''プログラムで仕事をこなさねばならない。ほとんどのシステムでは数種類のテキストエディタが選べるようになっているが、本物のプログラマは選ぶときに注意する必要がある。なぜなら、エディタは個人のスタイルを反映するからだ。多くの人は、世界最高のテキストエディタはゼロックスのパロアルト研究所が Alto と Dorado コンピュータで使うよう書いたもの[3]だと考えている。残念ながら、本物のプログラマならば誰も SmallTalk などという名前のオペレーティングシステムはけっして使わないし、コンピュータとマウスで対話したりすることもけっしてないだろう。

　ゼロックスエディタのコンセプトは、もっとまっとうな名前のついたオペレーティングシステムで走るエディタに取り込まれている — EMACS と VI はその2つだ。こうしたエディタは困りものだ。本物のプログラマは“what you see is what you get''なんて、テキストエディタと女については邪悪なコンセプトとしか考えていないのだ。いや、本物のプログラマがほしいのは、“頼んだら、やってくれる (you asked for it, you got it)'' そんなテキストエディタだ — 複雑で、神秘的で、強力で、情け容赦なく、そして危険なエディタ。TECO は、そんな貴重なエディタだ。

　TECO のコマンドシークエンスは、可読テキストと言うよりは、むしろ送電線の輻射雑音に近いと言う観察が報告されている[4]。TECO でとても楽しめるゲームのひとつに、コマンドラインに自分の名前を入力して、何が起こるか当てる、と言うものがある。TECO と対話している間は、ほんのわずかのタイプミスでもプログラムはたいてい破壊されるし、もっと深刻なことも起こりうる — 繊細かつ神秘的なバグが、それまで動いていたサブルーチンに混入するのだ。

　こうした理由から、本物のプログラマは一般にちゃんと動いているプログラムをいじるのを好まない。彼らは、SUPERZAP (か IBM 互換機ではその同等品) という素晴らしいプログラムを使って、バイナリー化されたオブジェクトコードを直接パッチとして当てる方が容易なことを知っているのだ。このプログラムはとてもうまく働くので、IBM上での多くの実行プログラムは、もとの FORTRAN コードとほとんど無縁なものとなっている。多くの場合、オリジナルのソースコードはもはや存在しない。このようにプログラムを fix するときが来たら、本物のプログラマをジョブに投入する以上のことを、マネージャーは考えもしないだろう — どこから手をつけたらいいかさえ、Quiche Eating な構造化プログラマには解らないだろう。これを “ジョブ・セキュリティ'' と呼ぶ。本物のプログラマが使わ`ない'ツールを以下に示す：

• FORTRAN プロセッサ。MORTRAN とか RATFOR といったもの。プログラミング作法 — Quiche を作るにはいいが。構造化プログラミングに関する上述コメントを参照。
• ソースコードデバッガ。本物のプログラマならコアダンプを読める。
• 配列のバインドをチェックできるコンパイラ。これらは創造性を失わせ、EQUIVALENCE の面白い用法のうちほとんどを駄目にし、そして negative subscript を使ってオペレーティングシステムのコードを改変することをできなくする。最悪なのは、バインドのチェックが不完全なことだ。
• ソースコードのメンテナンスシステム。本物のプログラマなら、自分のコードはカードファイルにきっちり打ち込んでおくものだ。なぜなら、こうすることでプログラムのオーナーは重要なプログラムを無防備な状態でおいておくことができなくなるからだ [5]。

本物のプログラマの仕事 (THE REAL PROGRAMMER AT WORK)

　典型的な本物のプログラマは、どこで働いているのだろうか? これほど有能な人物が努力してなすに値するプログラムとは、一体どんなものだろうか? 本物のプログラマの誰一人としてCOBOLで会計プログラム書きやピープル誌の発送先リストのソートに没頭したりしないということは、誰でも知っている。本物のプログラマは地球が震え上がるような任務(それも文字通りのやつ!)をほしがっているのだ。

• 本物のプログラマはロスアラモス国立研究所に勤めて、クレイ I で走らせる原爆のシミュレーションを書いている。
• 本物のプログラマは国家安全保障局に勤めて、ロシアの暗号を解読している。
• 我々の同胞が露助どもより先に月へ行って帰ってこられた、その大部分は、NASA にいる何千人もの本物のプログラマが努力したおかげだ。
• スペースシャトルのコンピュータは本物のプログラマがプログラムした。
• 本物のプログラマは、ボーイングで巡行ミサイルのオペレーティングシステムを設計している。

　本物のプログラマのうちで最も素晴らしい何人かが、カリフォルニアのジェット推進研究所で働いている。彼らの多くは、パイオニアやボイジャーのオペレーティングシステムを、すみからすみまで知りつくしている。地上の大規模 FORTRAN プログラムと、宇宙機に搭載されたアセンブリ言語のプログラムを一体化して、彼らは操縦と即興演奏の傑作を生み出すことができる — 打ち上げてから 6年も経過した後で宇宙船を土星の10キロ四方の範囲にヒットさせて、損傷したセンサープラットフォームや通信機やバッテリを修理・バイパスしたりするのだ。うわさによると、本物のプログラマのある1人はなんとかやりくりして、ボイジャー宇宙機に搭載された数百バイトの未使用メモリに、パターンマッチングプログラムを組み込んだという。そのときボイジャーは木星にいて、新しく発見された月を撮影していたのだ。

　現在のプランでは、ガリレオ宇宙機は火星を通過して木星にいたるまで、重力アシスト軌道を用いることになっている。この軌道は火星表面からわずか 80±3 キロを通過する。これほど厳しい条件では、誰も PASCAL プログラム(と PASCAL プログラマ)を信用して航法を任せようとはしないだろう。

　知ってのとおり、世界中にいる本物のプログラマの多くは合州国政府 — 主に国防総省 — のために働いている。いるべき場所にいる、というわけだ。しかしながら最近、本物のプログラマの地平に暗雲がたちこめはじめた。どうやら国防総省にいる高位の Quiche Eater たちが、国防プログラムはすべて “ADA''((r)国防総省) という大規模統合型言語で書くべきだと決定したようだ。しばらくのあいだ、ADA は本物のプログラミングから得られた教訓に真向から対決する言語 — 構造化言語、データ型を持つ言語、強力なタイピング、そしてセミコロン — となるよう運命づけられていると思われた。手短に言って、典型的な本物のプログラマの創造性をすり潰すために設計された言語だ。幸いにして、国防総省が採用した言語は挑むに足るよう改変できる程度には十分に面白い機能を持っている — それはおそろしく複雑で、オペレーティングシステムをぐちゃぐちゃにしたりメモリを再構成する手法を備えていて、それに Edsgar Dijkstra がこいつを気に入ってない [6]。(Dijkstra は知ってのとおり、“GoTos Considered Harmful'' — プログラミング技法の画期的作品で、PASCAL プログラマやQuiche Eaterたちに拍手喝采を浴びた本 — の著者だ。) その上、意志の堅い本物のプログラマなら、どんな言語の上でも FORTRAN を書ける。

　本物のプログラマがその信念に妥協して、私たちと同様に、生活破綻よりはましと、充分な金銭的見返りと引き替えに、少しばかりくだらないことがらに手を染めることはあるかもしれない。たとえば、アタリ社でテレビゲームを作っている本物のプログラマもいる。(だけど、テレビゲームでは遊ばない — 本物のプログラマはコンピュータをいつでも倒せるからね：チャレンジ精神は湧いてこないわけだ。)ルーカスフィルムで働く連中は、みんな本物のプログラマだ。(スタートレックファン 5000万人の金を拒絶するとはいい度胸だ。) コンピュータグラフィックスの世界では、本物のプログラマの割合はやや少ない。これはおそらく、コンピュータグラフィックスの用途がまだ限られているせいだろう。一方、コンピュータグラフィックスはすべて FORTRAN で行なわれているので、COBOL プログラムを書くはめになるのを避けてグラフィックをやっている人が存在する。

本物のプログラマの遊び (THE REAL PROGRAMMER AT PLAY)

　一般に、本物のプログラマは仕事するのと同じように遊ぶ — コンピュータで。彼は、仕事であれ遊びであれ、いずれにせよ楽しんでやっていることなのに雇用主が金を払ってくれることに、常に驚きを感じている (しかし、彼はこの意見を大声で表明しないよう注意を払っている)。本物のプログラマはたまにオフィスの外へ出て、新鮮な空気と1、2杯のビールを取り込む。コンピュータ ルームの外で本物のプログラマを識別するコツを以下に記す：

• パーティーでは、部屋の隅でオペレーティングシステムのセキュリティとその実現方法について話してるのが本物のプログラマだ。
• フットボールの試合観戦では、11×14 インチのファンフォールド紙に出力したシミュレーションと実際のプレイと比較してるのが本物のプログラマだ。
• ビーチでは、砂にフローチャートを描いてるのが本物のプログラマだ。
• 本物のプログラマがディスコへ行くのは点滅するライトを眺めるためだ。
• 葬儀では、“可哀想なジョージ。心臓病になるまではソートルーチンもちゃんと動いていたのに'' と言ってるのが本物のプログラマだ。
• 雑貨屋では、缶詰をレジのレーザー読みとり機に自分の手でかけると言い張ってるのが本物のプログラマだ。彼はキーパンチ係が一発で入力に成功するなんて絶対に信じていないからだ。

本物のプログラマの生息地 (THE REAL PROGRAMMER'S NATURAL HABITAT)

　本物のプログラマがその機能を最大限に発揮するのは、どんな環境だろうか? 本物のプログラマのマネージャーにとって、これは重要な問題だ。要員を 1人雇用するのにかかる費用を考えてみてほしい。彼(または彼女)を、仕事ができるような環境におくのが、一番良いのだ。

　典型的な本物のプログラマはコンピュータ端末の前に生息している。 端末の周りには、以下のようなものがある：

• 本物のプログラマがいままでこなしたプログラムのリスト。各部門ごとに、おおまかな時系列順に束ねられている。
• 冷めたコーヒーがカップに半分ほど入っている。たまに、コーヒーにタバコの吸殻が浮いていたりする。場合によってはオレンジスカッシュが入っていることもある。
• よほど優秀でない限り、OS JCL マニュアルとPrinciple of Operationが、とくに興味のあるページを開いて置いてある。
• 壁に止めてあるのは、ラインプリンターで出力した1969年用のスヌーピーのカレンダー。
• 床にばらまいてあるのはピーナツバター入りチーズバーの包装 — パン屋で腐る直前にしてあるタイプのやつで、自販機で並んでも、これ以上傷むことはないだろう。
• 机の左上の引出しに隠してあるのは、オレオの2枚重ねタイプ。何かあったときのために備えてある。
• オレオの下にあるのはフローチャート用定規で、この職場の前任者の忘れものだ。(本物のプログラマはプログラムを書くのであって、書類を書くわけではない。そんなのは維持管理屋にやらせろ。)

　本物のプログラマは30や40時間、50時間でも、連続して強い緊張のもとで働くだけの能力を持っている。実際、そうすることを望んでいる。本物のプログラマにとっては、トロい反応速度もたいした問題ではない — それは彼に仮眠をとるチャンスを与えてくれるのだ。スケジュールの密度が充分でない場合、本物のプログラマは細々としてはいるが面白いと思う部分を最初の 9週間をかけてやってしまい、それから最終週に50時間マラソンを 2、3発こなして残りの全部を仕上げる。こうしたやりかたは、プロジェクトを締切どおりに仕上げるのに汲々とするマネージャーから地獄のような言葉を浴びることになるが、文書化してないことの格好の言い訳となる。一般に以下のことがいえる：

• 本物のプログラマは9時から5時まで働いたりしない(夜の、なら働く)。
• 本物のプログラマはネクタイをしない。
• 本物のプログラマはハイヒールを履かない。
• 本物のプログラマは昼食時間に合わせて出勤する。
• 本物のプログラマは妻の名を知らないかもしれない。しかし、ASCIIコードテーブル(か EBCDIC)はしっかり憶えている。
• 本物のプログラマは料理の仕方を知らない。食料品店は午前3時に開いてはいないからだ。本物のプログラマは Twinkies [訳注 3] とコーヒーで生き延びる。

[訳注 3] Twinkies は、一口サイズのスポンジケーキにクリームをつめたようなお菓子。

未来 (THE FUTURE)

　未来だって? 何の? 本物のプログラマは、最近の若い世代のコンピュータプログラマが古い世代と必ずしも同じようには育ってきていないことに、少々危惧しているのだ。彼らの多くはフロントパネルのついたコンピュータを見たことがない。最近学校を卒業した連中には、計算機なしで16進の算術計算ができる奴はめったにいない。最近の大卒連中は作りがヤワだ — ソースレベルデバッガーや括弧をチェックしてくれるテキストエディタ、それに“ユーザーフレンドリー'' なオペレーティングシステムに守られて、本物のプログラミングを見てない。最悪なのは、FORTRAN をまったく習わずになんとかやりくりして学位まで取っている “コンピュータ科学者さま'' がいるってことだ! 我々は Unix ハッカーと Pascal プログラマになるよう運命づけられてるのか?

　私の経験からは、本物のプログラマの未来は明るい、とだけ報告できる。プログラマはどこにでもいる。OS/370 も FORTRAN も、Pascal プログラマがその世界に幕を引こうと努力しているにも関わらず、死に絶える気配は微塵もない。もっと陰湿な試み、たとえば FORTRAN の構造化なども失敗した。ああ、もちろんいくつかのベンダーが FORTRAN 77 コンパイラとともに現れたが、どれも FORTRAN 66 コンパイラへ変換するようにオプションカードを備えているのだ — DO ループを、神がお望みのとおりコンパイルするために。

　Unix だって、かつて本物のプログラマがそう感じたほどにはひどくないかもしれない。Unix の最新リリースは、本物のプログラマすべてにとっても価値あるオペレーティングシステムになる、そんな潜在能力を秘めている — 細かいところで互換性のない2つのユーザーインターフェース、難解で複雑なテレタイプドライバ、仮想記憶。“構造化されている'' という事実にさえ目をつぶれば、`C' プログラミングでさえ、その良さがわかるだろう：結局のところ変数型のチェックはないし、変数名は最長7文字だし(10文字か? 8文字か?)、それにボーナスとしてポインタデータ型が加わった — FORTRAN とアセンブリ言語のいちばんおいしい部分が一緒に入っているようだ。(#define のより創造的用法については何も言うまい.)

　いいや、未来はけっして暗いわけじゃない。過去数年間にわたって、名のある雑誌までがコンピュータおたくやハッカーの明るい未来について M.I.T. やスタンフォードをまるで僻地扱いしてまで報道した([7], [8])。一体なぜだ? その理由はつまり、本物のプログラミングの精神はこうした若い“男たち女たち''に受け継がれてるからなんだ。この世に悪夢のような仕様要求や、奇怪なバグや、非現実的なスケジュールがある限り、本物のプログラマが存在して、問題を解決し、後世のために文書を救おうと飛び込むんだ。FORTRAN 万歳!

謝辞 (ACKNOWLEGEMENT)

　本物のプログラマの性格描写は Jan E., Dave S., Rich G., Rich E. に、実例は Heather B. に、その練り上げは Kathy E. にご助力いただきました。また、atd!avsdS:mark には、最初の着想でご助力いただきました。記して感謝します。

参考文献 (REFERENCES)

1. Feirstein, B., Real Men Don't Eat Quiche, New York, Pocket Books, 1982.
2. Wirth, N., Algorithms + Datastructures = Programs, Prentice Hall, 1976.
3. Xerox PARC editors . . .
4. Finseth, C., Theory and Practice of Text Editors – or – a Cookbook for an EMACS, B.S. Thesis, MIT/LCS/TM-165,
5. Massachusetts Institute of Technology, May 1980.
6. Weinberg, G., The Psychology of Computer Programming, New York, Van Nostrabd Reinhold, 1971, page 110.
7. Dijkstra, E., On the GREEN Language Submitted to the DoD, Sigplan notices, Volume 3, Number 10, October 1978.
8. Rose, Frank, Joy of Hacking, Science 82, Volume 3, Number 9, November 1982, pages 58 – 66.
9. The Hacker Papers, Psychology Today, August 1980.

(「本物のプログラマ～」の派生については割愛しました)

　
初出公開：　2000年01月05日、　最終更新日： 2000年02月25日
Copyright Ed Post 1982.
この文書は、かつてUSENETを通じて世界中に無償配信されたものの翻訳である。訳者の意向としては内容を不当に改竄しない限り自由に複写、再配布、再利用を認めるものだが (つまり翻訳の改良ならＯＫってことだ)、原著者の意向については不明である。この点を知った上で、読者の責任において利用してほしい。もし原著作権者から何らかのクレームがついた場合は、ただちに削除する予定であることを、あらかじめおことわりしておく。
日本語訳： おおくぼ (E-mail: okubo@mbox.kyoto-inet.or.jp)

See Also:
[どこかには行く（オアシスへの道のり）]
http://www.geocities.co.jp/Milkyway-Orion/3324/prog/realprog.html