つい3年ほど前まで、ネット上で伝説の投稿「本物のプログラマはPascalを使わない」を読むことが出来たのだが、今はマニアックに日本語訳を探さないと読めなくなってしまった（原文は今でもネット上で参照可能）。
私の記憶が確かならば、日本語訳が月刊『bit』というコンピュータ雑誌に85年頃？に発表されたと思う。当時の私はまだ少年で、プログラミングの師匠（ソフトハウスの正社員）から「読んでみろ」と読ませてもらった記憶があるが、当然半分も理解出来なかった。
そんな私もSEとしては老人と言われるような中年になり、昔を知らない若いエンジニアや若いエンジニア志望の人が非常に多くなった。温故知新と言うが、当時を知る人や、若い人にも読んでもらえれば幸いだ。
- 1. はじめに
- 2. 言語（LANGUAGES）
- 3. 構造化プログラミング（STRUCTURED PROGRAMMING）
- 4. オペレーティングシステム（OPERATING SYSTEMS）
- 5. プログラミングツール（PROGRAMMING TOOLS）
- 6. 本物のプログラマの仕事（THE REAL PROGRAMMER AT WORK）
- 7. 本物のプログラマの遊び（THE REAL PROGRAMMER AT PLAY）
- 8. 本物のプログラマの生息地（THE REAL PROGRAMMER’S NATURAL HABITAT）
- 9. 未来（THE FUTURE）
- 10. 謝辞（ACKNOWLEGEMENT）
- 11. 参考文献（REFERENCES）
- 12. 筆者注
- 13. おわりに
- 14. 関連記事
はじめに
March 24, 1983
Real Programmers Don’t Use PASCAL
本物のプログラマは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」といった具合に物事を話し（彼らは普通、大文字、大声で話していたんだ、わかるね）、それ以外の連中は「コンピュータは難しすぎるよ」とか、「コンピュータには馴染めないね、非人間的すぎるんだ」なんて話していた（過去の研究では、本物の男たちは何ものにも馴染むことはしなかったし、非人間的であることを恐れなかったと指摘されている）。
しかし、何ごともそうであるように、時代は変わった。私たちが今日直面しているのは、ちっちゃなおばあちゃんがコンピュータ内蔵式の電子レンジを買い、12歳の坊主どもがアステロイドやパックマンで遊ぶために本物の男たちをはじき飛ばす、そして誰もが自分用のパーソナルコンピュータを買って使いこなすことさえできる、そんな世界なのだ。本物のプログラマは絶滅の危機に瀕しており、TRASH-80（※2）を使う高校生にとって替わられようとしている。
パックマンで遊ぶ典型的な高校2年生と、本物のプログラマの違いを指摘しておく必要があるだろう。この違いを明らかにすることで、こうしたゲーム少年たちに大いなる希望となるような役割モデル、つまりは理想の父親像を与えることができるだろう。また、本物のプログラマの雇用者にとっては、（人件費を大幅に抑えられるからといって）本物のプログラマ要員を12歳のパックマンプレイヤーに置き換えるのがなぜ誤りであるのかを説明することにもなるだろう。
言語（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コンピュータで使うよう書いたものだと考えている。残念ながら、本物のプログラマならば誰もSmallTalkなどという名前のオペレーティングシステムは決して使わないし、コンピュータとマウスで対話したりすることも決してないだろう。
ゼロックスエディタのコンセプトは、もっとまっとうな名前のついたオペレーティングシステムで走るエディタに取り込まれている－－EMACSとVIはその2つだ。こうしたエディタは困りものだ。本物のプログラマは「what you see is what you get」なんて、テキストエディタと女については邪悪なコンセプトとしか考えていないのだ。いや、本物のプログラマが欲しいのは、「頼んだら、やってくれる（you asked for it, you got it）」そんなテキストエディタだ－－複雑で、神秘的で、強力で、情け容赦なく、そして危険なエディタ。TECOは、そんな貴重なエディタだ。
TECOのコマンドシークエンスは、可読テキストと言うよりは、むしろ送電線の輻射雑音に近いと言う観察が報告されている。TECOでとても楽しめるゲームのひとつに、コマンドラインに自分の名前を入力して、何が起こるか当てる、と言うものがある。TECOと対話している間は、ほんのわずかのタイプミスでもプログラムはたいてい破壊されるし、もっと深刻なことも起こりうる－－繊細かつ神秘的なバグが、それまで動いていたサブルーチンに混入するのだ。
こうした理由から、本物のプログラマは一般にちゃんと動いているプログラムをいじるのを好まない。彼らは、SUPERZAP（かIBM互換機ではその同等品）という素晴らしいプログラムを使って、バイナリー化されたオブジェクトコードを直接パッチとして当てる方が容易なことを知っているのだ。このプログラムはとてもうまく働くので、IBM上での多くの実行プログラムは、元のFORTRANコードとほとんど無縁なものとなっている。多くの場合、オリジナルのソースコードはもはや存在しない。このようにプログラムをfixするときが来たら、本物のプログラマをジョブに投入する以上のことを、マネージャーは考えもしないだろう－－どこから手をつけたらいいかさえ、Quiche Eatingな構造化プログラマには解らないだろう。これを「ジョブ・セキュリティ」と呼ぶ。
本物のプログラマが使わ「ない」ツールを以下に示す：
FORTRANプロセッサ。MORTRANとかRATFORといったもの。プログラミング作法－－Quicheを作るにはいいが。構造化プログラミングに関する上述コメントを参照。
ソースコードデバッガ。本物のプログラマならコアダンプを読める。
配列のバインドをチェックできるコンパイラ。これらは創造性を失わせ、EQUIVALENCEの面白い用法のうちほとんどを駄目にし、そしてnegative subscriptを使ってオペレーティングシステムのコードを改変することをできなくする。最悪なのは、バインドのチェックが不完全なことだ。
ソースコードのメンテナンスシステム。本物のプログラマなら、自分のコードはカードファイルにきっちり打ち込んでおくものだ。なぜなら、こうすることでプログラムのオーナーは重要なプログラムを無防備な状態でおいておくことができなくなるからだ 。
本物のプログラマの仕事（THE REAL PROGRAMMER AT WORK）
典型的な本物のプログラマは、どこで働いているのだろうか？これほど有能な人物が努力してなすに値するプログラムとは、一体どんなものだろうか？本物のプログラマの誰一人としてCOBOLで会計プログラム書きやピープル誌の発送先リストのソートに没頭したりしないということは、誰でも知っている。本物のプログラマは地球が震え上がるような任務（それも文字通りのやつ！）を欲しがっているのだ。
- 本物のプログラマはロスアラモス国立研究所に勤めて、クレイIで走らせる原爆のシミュレーションを書いている
- 本物のプログラマは国家安全保障局に勤めて、ロシアの暗号を解読している
- 我々の同胞が露助どもより先に月へ行って帰ってこられた、その大部分は、NASAにいる何千人もの本物のプログラマが努力したおかげだ
- スペースシャトルのコンピュータは本物のプログラマがプログラムした
- 本物のプログラマは、ボーイングで巡行ミサイルのオペレーティングシステムを設計している
本物のプログラマの内で最も素晴らしい何人かが、カリフォルニアのジェット推進研究所で働いている。彼らの多くは、パイオニアやボイジャーのオペレーティングシステムを、隅から隅まで知り尽くしている。地上の大規模FORTRANプログラムと、宇宙機に搭載されたアセンブリ言語のプログラムを一体化して、彼らは操縦と即興演奏の傑作を生み出すことができる－－打ち上げてから 6年も経過した後で宇宙船を土星の10キロ四方の範囲にヒットさせて、損傷したセンサープラットフォームや通信機やバッテリを修理・バイパスしたりするのだ。噂によると、本物のプログラマのある1人はなんとかやりくりして、ボイジャー宇宙機に搭載された数百バイトの未使用メモリに、パターンマッチングプログラムを組み込んだという。そのときボイジャーは木星にいて、新しく発見された月を撮影していたのだ。
現在のプランでは、ガリレオ宇宙機は火星を通過して木星に至るまで、重力アシスト軌道を用いることになっている。この軌道は火星表面からわずか 80±3 キロを通過する。これほど厳しい条件では、誰もPASCALプログラム（とPASCALプログラマ)を信用して航法を任せようとはしないだろう。
知ってのとおり、世界中にいる本物のプログラマの多くは合州国政府－－主に国防総省－－のために働いている。いるべき場所にいる、というわけだ。しかしながら最近、本物のプログラマの地平に暗雲がたちこめはじめた。どうやら国防総省にいる高位のQuiche Eaterたちが、国防プログラムはすべて「ADA」（(R)国防総省）という大規模統合型言語で書くべきだと決定したようだ。しばらくの間、ADAは本物のプログラミングから得られた教訓に真向から対決する言語－－構造化言語、データ型を持つ言語、強力なタイピング、そしてセミコロン－－となるよう運命づけられていると思われた。手短に言って、典型的な本物のプログラマの創造性をすり潰すために設計された言語だ。幸いにして、国防総省が採用した言語は挑むに足るよう改変できる程度には十分に面白い機能を持っている－－それは恐ろしく複雑で、オペレーティングシステムをグチャグチャにしたりメモリを再構成する手法を備えていて、それにEdsgar Dijkstraがこいつを気に入ってない。（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）とコーヒーで生き延びる
未来（THE FUTURE）
未来だって？何の？本物のプログラマは、最近の若い世代のコンピュータプログラマが古い世代と必ずしも同じようには育ってきていないことに、少々危惧しているのだ。彼らの多くはフロントパネルのついたコンピュータを見たことがない。最近学校を卒業した連中には、計算機なしで16進の算術計算ができる奴はめったにいない。最近の大卒連中は作りがヤワだ－－ソースレベルデバッガーや括弧をチェックしてくれるテキストエディタ、それに「ユーザーフレンドリー」なオペレーティングシステムに守られて、本物のプログラミングを見てない。最悪なのは、FORTRANをまったく習わずになんとかやりくりして学位まで取っている「コンピュータ科学者さま」がいるってことだ！我々はUnixハッカーとPASCALプログラマになるよう運命づけられてるのか？
私の経験からは、本物のプログラマの未来は明るい、とだけ報告できる。プログラマはどこにでもいる。OS/370もFORTRANも、PASCALプログラマがその世界に幕を引こうと努力しているにも関わらず、死に絶える気配は微塵もない。もっと陰湿な試み、たとえばFORTRANの構造化なども失敗した。ああ、もちろんいくつかのベンダーがFORTRAN77コンパイラとともに現れたが、どれもFORTRAN66コンパイラへ変換するようにオプションカードを備えているのだ－－DOループを、神がお望みのとおりコンパイルするために。
Unixだって、かつて本物のプログラマがそう感じたほどにはひどくないかもしれない。Unixの最新リリースは、本物のプログラマすべてにとっても価値あるオペレーティングシステムになる、そんな潜在能力を秘めている－－細かいところで互換性のない2つのユーザーインターフェース、難解で複雑なテレタイプドライバ、仮想記憶。「構造化されている」という事実にさえ目をつぶれば、「C」プログラミングでさえ、その良さがわかるだろう：結局のところ変数型のチェックはないし、変数名は最長7文字だし（10文字か？8文字か？）、それにボーナスとしてポインタデータ型が加わった－－FORTRANとアセンブリ言語のいちばんおいしい部分が一緒に入っているようだ（#defineのより創造的用法については何も言うまい）。
いいや、未来は決して暗いわけじゃない。過去数年間にわたって、名のある雑誌までがコンピュータおたくやハッカーの明るい未来についてM.I.T.やスタンフォードをまるで僻地扱いしてまで報道した。一体なぜだ？その理由はつまり、本物のプログラミングの精神はこうした若い「男たち女たち」に受け継がれてるからなんだ。この世に悪夢のような仕様要求や、奇怪なバグや、非現実的なスケジュールがある限り、本物のプログラマが存在して、問題を解決し、後世のために文書を救おうと飛び込むんだ。FORTRAN万歳！
謝辞（ACKNOWLEGEMENT）
本物のプログラマの性格描写は Jan E., Dave S., Rich G., Rich E. に、実例は Heather B. に、その練り上げは Kathy E. にご助力いただきました。また、atd!avsdS:mark には、最初の着想でご助力いただきました。記して感謝します。
参考文献（REFERENCES）
- Feirstein, B., Real Men Don’t Eat Quiche, New York, Pocket Books, 1982.
- Wirth, N., Algorithms + Datastructures = Programs, Prentice Hall, 1976.
- Finseth, C., Theory and Practice of Text Editors – or – a Cookbook for an EMACS, B.S. Thesis, MIT/LCS/TM-165, Massachusetts Institute of Technology, May 1980.
- Weinberg, G., The Psychology of Computer Programming, New York, Van Nostrabd Reinhold, 1971, page 110.
- Dijkstra, E., On the GREEN Language Submitted to the DoD, Sigplan notices, Volume 3, Number 10, October 1978.
- Rose, Frank, Joy of Hacking, Science 82, Volume 3, Number 9, November 1982, pages 58 – 66.
- The Hacker Papers, Psychology Today, August 1980.
筆者注
- Quiche（キッシュ）とは甘くないタルトのようなフランスの食べ物で、当時東海岸でおしゃれな食事として人気があった。そこから転じて軟弱な女子供の典型的な食べ物としている。Quiche Eater（キッシュイーター）とは、女々しい軟弱者の意味
- TRASH-80はTandy Radio Shack社のパソコンTRS-80のことで、1980年頃には日本でも人気があった
- Twinkiesは、一口サイズのスポンジケーキにクリームをつめたようなお菓子
おわりに
私は大型汎用機での開発やFORTRANでのコーディング経験はない（運用管理とSO経験ならある）。なので、1945～1980年代初頭までの大型汎用機全盛時代は、本で読んだ知識しかない。しかし、1980年代初頭の日本でのパソコン黎明期にパソコン少年だったので、当時のコンピュータ事情は今でも良く覚えている。
固有名詞等に関しては、理解しやすいように外部リンクを埋め込んだが、たまたま月刊『bit』誌の当該記事が載っているブログを発見し、非常に懐かしい思いをした。それはともかく、本稿と当時の解説は別の記事で改めて書くことにしよう。
もう30数年前の文章なので、いくら現役のSEやプログラマでも、平成以降に生まれた人には「なんじゃこりゃ？」な世界観だと思う。が、いつの時代も「本物」になるには、このぐらいの気概と誇りとユーモアが必要なのは言うまでもない。それに、当時と現在で違うのはコンピュータのアーキテクチャと開発環境ぐらいだ。私はエンジニアとしては老人だが、今の若いエンジニアもいずれ歳を取り「昔は･･･」と言い出して若い人から嫌われるようになる（笑）。
最後に付け加えると、新しいチップを開発した場合、またスーパーコンピュータを開発した場合、その性能を測るために作られるのがFORTRANとC/C++コンパイラだ。FORTRANをコンピュータ史の遺物などと笑ってはイケナイ。
関連記事
Warning: strpos() expects parameter 1 to be string, array given in /home/eware/dajya-ranger.com/public_html/wp-includes/compat.php on line 498
Warning: preg_match_all() expects parameter 2 to be string, array given in /home/eware/dajya-ranger.com/public_html/wp-includes/shortcodes.php on line 155
Array
