本物のプログラマはPASCALを使わない (Real Programmers Don't Use PASCAL)のコピーです。
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
古き良き時代にたちかえってみよう ‐ コンピュータの「黄金時代」‐ 男たちと少年たちを区別するのは簡単であった (文学的には "本物の男たち"
と "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年頃には日本でも人気があった。
大衆の中から本物のプログラマを選り分けるには、彼(彼女)の使う言語をきいてみたらよい。本物のプログラマは 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 コンパイラ、そしてビールがあれば完璧に幸福になれるのだ。[訳注 3]
本物のプログラマは FORTRAN でリスト処理を'する(do)'。
本物のプログラマは FORTRAN で文字列操作を'やる(do)'。
本物のプログラマは FORTRAN で経理処理を(必要ならば)'する(do)'。
本物のプログラマは人工知能プログラムを FORTRAN で'する(do)'。
もし FORTRAN で出来なければ、アセンブリ言語でやる。アセンブリ言語で出来なきゃ、それはやる価値がないのだ。
[訳注 3] 「私の名前をヨーロッパ人はたいがい「ニクラウス・ヴィルト」と正しく発音してくれるが、アメリカ人は必ず「ニッケルズ・ワース」と発音する。つまり、ヨーロッパ人は名前呼び(call by name)をして、アメリカ人は値呼び(call by value)をしているわけだ」
コンピュータサイエンスの学者連中は、過去何年にもわたってさかりがついたように"構造化プログラミング"にのぼせ上がっている。
連中は、プログラマが特製の言語構成と技法を使えば、プログラムはもっと解りやすくなるのだ、と主張している。
連中は、どういう構成が一番良いのかはいうまでもなく、特定条件下での知見をわかりづらい学術誌の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文字に基づいた明示的な型設定を備えているものだ。
本物のプログラマは、どんなオペレーティングシステムを使うのだろうか? CP/M? 禁断のCP/M は、なんといっても基本的に玩具OSである。CP/M など、ちっちゃなおばあちゃんや小学生でも理解して使うことが出来る。
もちろん、Unix はもう少し複雑だ ‐ 典型的な Unix ハッカーは、今週の PRINT コマンドがなんて名前になってるか憶えていられない ‐ しかしはっきり言って、
Unix はテレビゲームの豪華版だ。Unix システムで本気で仕事をする奴はいない：UUCPネットでジョークを世界中に飛ばし、冒険ゲームとリサーチペーパーを書くだけの話だ。
いいや、本物のプログラマはOS/370を使うのだ。良きプログラマなら、IJK305I というエラー出力の意味するところを JCL マニュアルから導き出すことが出来るだろう。
優れたプログラマなら、JCL をマニュアルをまったく見ずに書くことが出来よう。真に傑出した能力を持つプログラマなら、6メガバイトのコアダンプに埋もれたバグを、
16進計算機を使わずに見つけ出すことも出来よう。(著者は実際にその現場を目撃したことがある)
OSは間違いなく素晴らしいオペレーティングシステムだ。スペースの位置をたった1箇所間違えるだけで、過去何日分もの仕事をすべて消滅させてしまうことも出来る。
だからプログラミング要員への注意喚起もスムーズだ。このシステムを扱うには、キーパンチを使ってやるのが一番いい。
OS/370で走る時分割システムがあるなどと主張する輩がいるが、著者は慎重に研究を重ねた結果、彼らが誤っていると結論づける。
本物のプログラマは、どんなプログラミングツールを使うのだろう? 理論的には、本物のプログラマはその手になるプログラムを、コンピュータの前面パネルから直接入力して動かすことができる。
コンピュータが前面パネルを備えていた頃、これは時おり、一般的に行なわれていたのだ。典型的な本物のプログラマはブートストラップローダの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]。
典型的な本物のプログラマは、どこで働いているのだろうか? これほど有能な人物が努力してなすに値するプログラムとは、
一体どんなものだろうか? 本物のプログラマの誰一人として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 プログラムを書くはめになるのを避けてグラフィックをやっている人が存在する。
一般に、本物のプログラマは仕事するのと同じように遊ぶ ‐ コンピュータで。彼は、仕事であれ遊びであれ、
いずれにせよ楽しんでやっていることなのに雇用主が金を払ってくれることに、常に驚きを感じている (しかし、彼はこの意見を大声で表明しないよう注意を払っている)。
本物のプログラマはたまにオフィスの外へ出て、新鮮な空気と1、2杯のビールを取り込む。コンピュータ ルームの外で本物のプログラマを識別するコツを以下に記す：
パーティーでは、部屋の隅でオペレーティングシステムのセキュリティとその実現方法について話してるのが本物のプログラマだ。
フットボールの試合観戦では、11x14 インチのファンフォールド紙に出力したシミュレーションと実際のプレイと比較してるのが本物のプログラマだ。
ビーチでは、砂にフローチャートを描いてるのが本物のプログラマだ。
本物のプログラマがディスコへ行くのは点滅するライトを眺めるためだ。
葬儀では、"可哀想なジョージ。心臓病になるまではソートルーチンもちゃんと動いていたのに" と言ってるのが本物のプログラマだ。
雑貨屋では、缶詰をレジのレーザー読みとり機に自分の手でかけると言い張ってるのが本物のプログラマだ。彼はキーパンチ係が一発で入力に成功するなんて絶対に信じていないからだ。
本物のプログラマがその機能を最大限に発揮するのは、どんな環境だろうか? 本物のプログラマのマネージャーにとって、これは重要な問題だ。
要員を 1人雇用するのにかかる費用を考えてみてほしい。彼(または彼女)を、仕事ができるような環境におくのが、一番良いのだ。
典型的な本物のプログラマはコンピュータ端末の前に生息している。
端末の周りには、以下のようなものがある：
本物のプログラマがいままでこなしたプログラムのリスト。各部門ごとに、おおまかな時系列順に束ねられている。
冷めたコーヒーがカップに半分ほど入っている。たまに、コーヒーにタバコの吸殻が浮いていたりする。場合によってはオレンジスカッシュが入っていることもある。
よほど優秀でない限り、OS JCL マニュアルとPrinciple of Operationが、とくに興味のあるページを開いて置いてある。
壁に止めてあるのは、ラインプリンターで出力した1969年用のスヌーピーのカレンダー。[訳注 4]
床にばらまいてあるのはピーナツバター入りチーズバーの包装 ‐ パン屋で腐る直前にしてあるタイプのやつで、自販機で並んでも、これ以上傷むことはないだろう。
机の左上の引出しに隠してあるのは、オレオの2枚重ねタイプ。何かあったときのために備えてある。
オレオの下にあるのはフローチャート用定規で、この職場の前任者の忘れものだ。(本物のプログラマはプログラムを書くのであって、書類を書くわけではない。そんなのは維持管理屋にやらせろ。)
本物のプログラマは30や40時間、50時間でも、連続して強い緊張のもとで働くだけの能力を持っている。実際、そうすることを望んでいる。
本物のプログラマにとっては、トロい反応速度もたいした問題ではない ‐ それは彼に仮眠をとるチャンスを与えてくれるのだ。スケジュールの密度が充分でない場合、
本物のプログラマは細々としてはいるが面白いと思う部分を最初の 9週間をかけてやってしまい、それから最終週に50時間マラソンを 2、3発こなして残りの全部を仕上げる。
こうしたやりかたは、プロジェクトを締切どおりに仕上げるのに汲々とするマネージャーから地獄のような言葉を浴びることになるが、文書化してないことの格好の言い訳となる。
一般に以下のことがいえる：
本物のプログラマは9時から5時まで働いたりしない(夜の、なら働く)。
本物のプログラマはネクタイをしない。
本物のプログラマはハイヒールを履かない。
本物のプログラマは昼食時間に合わせて出勤する。
本物のプログラマは妻の名を知らないかもしれない。しかし、ASCIIコードテーブル(か EBCDIC)はしっかり憶えている。
本物のプログラマは料理の仕方を知らない。食料品店は午前3時に開いてはいないからだ。本物のプログラマは Twinkies [訳注 5]とコーヒーで生き延びる。
[訳注 4] 最初のフリープログラム。1969年のスヌーピーのカレンダーを出力する Fortran コード。
[訳注 5] Twinkies は、一口サイズのスポンジケーキにクリームをつめたようなお菓子。
未来だって? 何の? 本物のプログラマは、最近の若い世代のコンピュータプログラマが古い世代と必ずしも同じようには育ってきていないことに、少々危惧しているのだ。
彼らの多くはフロントパネルのついたコンピュータを見たことがない。最近学校を卒業した連中には、計算機なしで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])。
一体なぜだ? その理由はつまり、本物のプログラミングの精神はこうした若い"男たち女たち"に受け継がれてるからなんだ。
この世に悪夢のような仕様要求や、奇怪なバグや、非現実的なスケジュールがある限り、本物のプログラマが存在して、問題を解決し、後世のために文書を残しておこう[訳注 6]と飛び込むんだ。FORTRAN 万歳!
[訳注 6]:(プログラマーはドキュメントを書かないので) 後々の(役に立たない)ドキュメントの(増殖の)節約ができるとも解釈できる。または、ドキュメントは書かないけどね。（ドキュメンテーションは後に残しておく）とも解釈可能。
本物のプログラマの性格描写は Jan E., Dave S., Rich G., Rich E. に、実例は Heather B. に、その練り上げは Kathy E. にご助力いただきました。
また、atd!avsdS:mark には、最初の着想でご助力いただきました。記して感謝します。
Feirstein, B., Real Men Don't Eat Quiche, New York, Pocket Books, 1982.
Wirth, N., Algorithms + Datastructures = Programs, Prentice Hall, 1976.
Xerox PARC editors . . .
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.
March 24, 1983
Real Programmers Don't Use PASCAL
Ed Post
Tektronix, Inc.
P.O. Box 1000 m/s 63-205
Wilsonville, OR 97070
Copyright (c) 1982
Real Programmers Don't Use Pascal
[ A letter to the editor of Datamation, volume 29 number 7, July 1983. I've long ago lost my dog-eared photocopy, but I believe this was written (and is copyright) by Ed Post,
Tektronix, Wilsonville OR USA. The story of Mel is a related article. ]
Back in the good old days-- the "Golden Era" of computers-- it was easy to separate the men from the boys (sometimes called "Real Men" and "Quiche Eaters" in the literature). During this period, the Real Men were the ones who understood computer programming, and the Quiche Eaters were the ones who didn't. A real computer programmer said things like "DO 10 I=1,10" and "ABEND" (they actually talked in capital letters, you understand), and the rest of the world said things like "computers are too complicated for me" and "I can't relate to computers-- they're so impersonal". (A previous work [1] points out that Real Men don't "relate" to anything, and aren't afraid of being impersonal.)
But, as usual, times change. We are faced today with a world in which little old ladies can get computers in their microwave ovens, 12 year old kids can blow Real Men out of the water playing Asteroids and Pac-Man, and anyone can buy and even understand their very own personal Computer. The Real Programmer is in danger of becoming extinct, of being replaced by high school students with TRASH-80s.
There is a clear need to point out the differences between the typical high school junior Pac-Man player and a Real Programmer. If this difference is made clear, it will give these kids something to aspire to-- a role model, a Father Figure. It will also help explain to the employers of Real Programmers why it would be a mistake to replace the Real Programmers on their staff with 12 year old Pac-Man players (at a considerable salary savings).
The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses. Real Programmers use Fortran. Quiche Eaters use Pascal. Nicklaus Wirth, the designer of Pascal, gave a talk once at which he was asked, "How do you pronounce your name?". He replied, "You can either call me by name, pronouncing it 'Veert', or call me by value, 'Worth'." One can tell immediately by this comment that Nicklaus Wirth is a Quiche Eater. The only parameter passing mechanism endorsed by Real Programmers is call-by-value-return, as implemented in the IBM/370 Fortran G and H compilers. Real Programmers don't need all these abstract concepts to get their jobs done-- they are perfectly happy with a keypunch, a Fortran IV compiler, and a beer.
Real Programmers do List Processing in Fortran.
Real Programmers do String Manipulation in Fortran.
Real Programmers do Accounting (if they do it at all) in Fortran.
Real Programmers do Artificial Intelligence programs in Fortran.
If you can't do it in Fortran, do it in assembly language. If you can't do it in assembly language, it isn't worth doing.
The academics in computer science have gotten into the "structured programming" rut over the past several years. They claim that programs are more easily understood if the programmer uses some special language constructs and techniques. They don't all agree on exactly which constructs, of course, and the example they use to show their particular point of view invariably fit on a single page of some obscure journal or another-- clearly not enough of an example to convince anyone. When I got out of school, I thought I was the best programmer in the world. I could write an unbeatable tic-tac-toe program, use five different computer languages, and create 1000 line programs that WORKED (Really!). Then I got out into the Real World. My first task in the Real World was to read and understand a 200,000 line Fortran program, then speed it up by a factor of two. Any Real Programmer will tell you that all the Structured Coding in the world won't help you solve a problem like that-- it takes actual talent. Some quick observations on Real Programmers and Structured Programming:
Real Programmers aren't afraid to use GOTOs.
Real Programmers can write five page long DO loops without getting confused.
Real Programmers like Arithmetic IF statements-- they make the code more interesting.
Real Programmers write self-modifying code, especially if they can save 20 nanoseconds in the middle of a tight loop.
Real Programmers don't need comments-- the code is obvious.
Since Fortran doesn't have a structured IF, REPEAT ... UNTIL, or CASE statement, Real Programmers don't have to worry about not using them. Besides, they can be simulated when necessary using assigned GOTOs.
Data structures have also gotten a lot of press lately. Abstract Data Types, Structures, Pointers, Lists, and Strings have become popular in certain circles. Wirth (the above mentioned Quiche Eater) actually wrote an entire book [2] contending that you could write a program based on data structures, instead of the other way around. As all Real Programmers know, the only useful data structure is the Array. Strings, Lists, Structures, Sets-- these are all special cases of arrays and can be treated that way just as easily without messing up your programming language with all sorts of complications. The worst thing about fancy data types is that you have to declare them, and Real Programming Languages, as we all know, have implicit typing based on the first letter of the (six character) variable name.
What kind of operating system is used by a Real Programmer? CP/M? God forbid-- CP/M, after all, is basically a toy operating system. Even little old ladies and grade school students can understand and use CP/M.
Unix is a lot more complicated of course-- the typical Unix hacker never can remember what the PRINT command is called this week-- but when it gets right down to it, Unix is a glorified video game. People don't do Serious Work on Unix systems: they send jokes around the world on UUCP-net and write Adventure games and research papers.
No, your Real Programmer uses OS/370. A good programmer can find and understand the description of the IJK305I error he just got in his JCL manual. A great programmer can write JCL without referring to the manual at all. A truly outstanding programmer can find bugs buried in a 6 megabyte core dump without using a hex calculator. (I have actually seen this done.)
OS is a truly remarkable operating system. It's possible to destroy days of work with a single misplaced space, so alertness in the programming staff is encouraged. The best way to approach the system is through a keypunch. Some people claim there is a Time Sharing system that runs on OS/370, but after careful study I have come to the conclusion that they were mistaken.
What kind of tools does a Real Programmer use? In theory, a Real Programmer could run his programs by keying them into the front panel of the computer. Back in the days when computers had front panels, this was actually done occasionally. Your typical Real Programmer knew the entire bootstrap loader by memory in hex, and toggled it in whenever it got destroyed by his program. (Back then, memory was memory-- it didn't go away when the power went off. Today, memory either forgets things when you don't want it to, or remembers things long after they're better forgotten.) Legend has it that Seymore Cray, inventor of the Cray I supercomputer and most of Control Data's computers, actually toggled the first operating system for the CDC7600 in on the front panel from memory when it was first powered on. Seymore, needless to say, is a Real Programmer.
One of my favorite Real Programmers was a systems programmer for Texas Instruments. One day, he got a long distance call from a user whose system had crashed in the middle of saving some important work. Jim was able to repair the damage over the phone, getting the user to toggle in disk I/O instructions at the front panel, repairing system tables in hex, reading register contents back over the phone. The moral of this story: while a Real Programmer usually includes a keypunch and line printer in his toolkit, he can get along with just a front panel and a telephone in emergencies.
In some companies, text editing no longer consists of ten engineers standing in line to use an 029 keypunch. In fact, the building I work in doesn't contain a single keypunch. The Real Programmer in this situation has to do his work with a "text editor" program. Most systems supply several text editors to select from, and the Real Programmer must be careful to pick one that reflects his personal style. Many people believe that the best text editors in the world were written at Xerox Palo Alto Research Center for use on their Alto and Dorado computers[3]. Unfortunately, no Real Programmer would ever use a computer whose operating system is called SmallTalk, and would certainly not talk to the computer with a mouse.
Some of the concepts in these Xerox editors have been incorporated into editors running on more reasonably named operating systems-- EMACS and VI being two. The problem with these editors is that Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in Women. No, the Real Programmer wants a "you asked for it, you got it" text editor-- complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.
It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text[4]. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse-- introduce subtle and mysterious bugs in a once working subroutine.
For this reason, Real Programmers are reluctant to actually edit a program that is close to working. They find it much easier to just patch the binary object code directly, using a wonderful program called SUPERZAP (or its equivalent on non-IBM machines). This works so well that many working programs on IBM systems bear no relation to the original Fortran code. In many cases, the original source code is no longer available. When it comes time to fix a program like this, no manager would even think of sending anything less than a Real Programmer to do the job-- no Quiche Eating structured programmer would even know where to start. This is called "job security".
Some programming tools NOT used by Real Programmers:
Fortran preprocessors like MORTRAN and RATFOR. The Cuisinarts of programming-- great for making Quiche. See comments above on structured programming.
Source language debuggers. Real Programmers can read core dumps.
Compilers with array bounds checking. They stifle creativity, destroy most of the interesting uses for EQUIVALENCE, and make it impossible to modify the operating system code with negative subscripts. Worst of all, bounds checking is inefficient.
Source code maintenance systems. A Real Programmer keeps his code locked up in a card file, because it implies that its owner cannot leave his important programs unguarded [5].
Where does the typical Real Programmer work? What kind of programs are worthy of the efforts of so talented an individual? You can be sure that no Real Programmer would be caught dead writing accounts-receivable programs in COBOL, or sorting mailing lists for People magazine. A Real Programmer wants tasks of earth-shaking importance (literally!).
Real Programmers work for Los Alamos National Laboratory, writing atomic bomb simulations to run on Cray I supercomputers.
Real Programmers work for the National Security Agency, decoding Russian transmissions.
It was largely due to the efforts of thousands of Real Programmers working for NASA that our boys got to the moon and back before the Russkies.
The computers in the Space Shuttle were programmed by Real Programmers.
Real Programmers are at work for Boeing designing the operation systems for cruise missiles.
Some of the most awesome Real Programmers of all work at the Jet Propulsion Laboratory in California. Many of them know the entire operating system of the Pioneer and Voyager spacecraft by heart. With a combination of large ground-based Fortran programs and small spacecraft-based assembly language programs, they are able to do incredible feats of navigation and improvisation-- hitting ten-kilometer wide windows at Saturn after six years in space, repairing or bypassing damaged sensor platforms, radios, and batteries. Allegedly, one Real Programmer managed to tuck a pattern matching program into a few hundred bytes of unused memory in a Voyager spacecraft that searched for, located, and photographed a new moon of Jupiter.
The current plan for the Galileo spacecraft is to use a gravity assist trajectory past Mars on the way to Jupiter. This trajectory passes within 80 +/- 3 kilometers of the surface of Mars. Nobody is going to trust a Pascal program (or Pascal programmer) for navigation to these tolerances.
As you can tell, many of the world's Real Programmers work for the U.S. Government-- mainly the Defense Department. This is as it should be. Recently, however, a black cloud has formed on the Real Programmer horizon. It seems that some highly placed Quiche Eaters at the Defense Department decided that all Defense programs should be written in some grand unified language called "ADA" ((C), DoD). For a while, it seemed that ADA was destined to become a language that went against all the precepts of Real Programming-- a language with structure, a language with data types, strong typing, and semicolons. In short, a language designed to cripple the creativity of the typical Real Programmer. Fortunately, the language adopted by DoD had enough interesting features to make it approachable-- it's incredibly complex, includes methods for messing with the operating system and rearranging memory, and Edsger Dijkstra doesn't like it [6]. (Dijkstra, as I'm sure you know, was the author of "GOTOs Considered Harmful"-- a landmark work in programming methodology, applauded by Pascal Programmers and Quiche Eaters alike.) Besides, the determined Real Programmer can write Fortran programs in any language.
The Real Programmer might compromise his principles and work on something slightly more trivial than the destruction of life as we know it. Providing there's enough money in it. There are several Real Programmers building video games at Atari, for example. (But not playing them-- a Real Programmer knows how to beat the machine every time: no challenge in that.) Everyone working at LucasFilm is a Real Programmer. (It would be crazy to turn down the money of fifty million Star Trek fans.) The proportion of Real Programmers in Computer Graphics is somewhat lower than the norm, mostly because nobody has found a use for Computer Graphics yet. On the other hand, all Computer Graphics is done in Fortran, so there are a fair number of people doing Graphics in order to avoid having to write COBOL programs.
Generally, the Real Programmer plays the same way he works-- with computers. He is constantly amazed that his employer actually pays him to do what he would be doing for fun anyway (although he is careful not to express this opinion out loud). Occasionally, the Real Programmer does step out of the office for a breath of fresh air and a beer or two. Some tips on recognizing Real Programmers away from the computer room:
At a party, the Real Programmers are the ones in the corner talking about operating system security and how to get around it.
At a football game, the Real Programmer is the one comparing the plays against his simulations printed on 11 by 14 fanfold paper.
At the beach, the Real Programmer is the one drawing flowcharts in the sand.
At a funeral, the Real Programmer is the one saying "Poor George. And he almost had the sort routine working before the coronary."
In a grocery store, the Real Programmer is the one who insists on running the cans past the laser checkout scanner himself, because he never could trust keypunch operators to get it right the first time.
What sort of environment does the Real Programmer function best in? This is an important question for the managers of Real Programmers. Considering the amount of money it costs to keep one on the staff, it's best to put him (or her) in an environment where he can get his work done.
The typical Real Programmer lives in front of a computer terminal. Surrounding this terminal are:
Listings of all programs the Real Programmer has ever worked on, piled in roughly chronological order on every flat surface in the office.
Some half-dozen or so partly filled cups of cold coffee. Occasionally, there will be cigarette butts floating in the coffee. In some cases, the cups will contain Orange Crush.
Unless he is very good, there will be copies of the OS JCL manual and the Principles of Operation open to some particularly interesting pages.
Taped to the wall is a line-printer Snoopy calendar for the year 1969.
Strewn about the floor are several wrappers for peanut butter filled cheese bars-- the type that are made pre-stale at the bakery so they can't get any worse while waiting in the vending machine.
Hiding in the top left-hand drawer of the desk is a stash of double-stuff Oreos for special occasions.
Underneath the Oreos is a flow-charting template, left there by the previous occupant of the office. (Real Programmers write programs, not documentation. Leave that to the maintenence people.)
The Real Programmer is capable of working 30, 40, even 50 hours at a stretch, under intense pressure. In fact, he prefers it that way. Bad response time doesn't bother the Real Programmer-- it gives him a chance to catch a little sleep between compiles. If there is not enough schedule pressure on the Real Programmer, he tends to make things more challenging by working on some small but interesting part of the problem for the first nine weeks, then finishing the rest in the last week, in two or three 50-hour marathons. This not only impresses the hell out of his manager, who was despairing of ever getting the project done on time, but creates a convenient excuse for not doing the documentation. In general:
No Real Programmer works 9 to 5. (Unless it's the ones at night.)
Real Programmers don't wear neckties.
Real Programmers don't wear high heeled shoes.
Real Programmers arrive at work in time for lunch.
A Real Programmer might or might not know his wife's name. He does, however, know the entire ASCII (or EBCDIC) code table.
Real Programmers don't know how to cook. Grocery stores aren't open at three in the morning. Real Programmers survive on Twinkies and coffee.
What of the future? It is a matter of some concern to Real Programmers that the latest generation of computer programmers are not being brought up with the same outlook on life as their elders. Many of them have never seen a computer with a front panel. Hardly anyone graduating from school these days can do hex arithmetic without a calculator. College graduates these days are soft-- protected from the realities of programming by source level debuggers, text editors that count parentheses, and "user friendly" operating systems. Worst of all, some of these alleged "computer scientists" manage to get degrees without ever learning Fortran! Are we destined to become an industry of Unix hackers and Pascal programmers?
From my experience, I can only report that the future is bright for Real Programmers everywhere. Neither OS/370 nor Fortran show any signs of dying out, despite all the efforts of Pas- cal programmers the world over. Even more subtle tricks, like adding structured coding constructs to Fortran, have failed. Oh sure, some computer vendors have come out with Fortran 77 compilers, but every one of them has a way of converting itself back into a Fortran 66 compiler at the drop of an option card-- to compile DO loops like God meant them to be.
Even Unix might not be as bad on Real Programmers as it once was. The latest release of Unix has the potential of an operating system worthy of any Real Programmer-- two different and subtly incompatible user interfaces, an arcane and complicated teletype driver, virtual memory. If you ignore the fact that it's "structured", even 'C' programming can be appreciated by the Real Programmer: after all, there's no type checking, variable names are seven (ten? eight?) characters long, and the added bonus of the Pointer data type is thrown in-- like having the best parts of Fortran and assembly language in one place. (Not to mention some of the more creative uses for #define.)
No, the future isn't all that bad. Why, in the past few years, the popular press has even commented on the bright new crop of computer nerds and hackers ([7] and [8]) leaving places like Stanford and MIT for the Real World. From all evidence, the spirit of Real Programming lives on in these young men and women. As long as there are ill-defined goals, bizarre bugs, and unrealistic schedules, there will be Real Programmers willing to jump in and Solve The Problem, saving the documentation for later. Long live Fortran!
References:
[1] Feirstein, B., "Real Men don't Eat Quiche", New York, Pocket Books, 1982.
[2] Wirth, N., "Algorithms + Data Structures = Programs", Prentice Hall, 1976.
[3] Ilson, R., "Recent Research in Text Processing", IEEE Trans. Prof. Commun., Vol. PC-23, No. 4, Dec. 4, 1980.
[4] 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.
[5] Weinberg, G., "The Psychology of Computer Programming", New York, Van Nostrand Reinhold, 1971, p. 110.
[6] Dijkstra, E., "On the GREEN language submitted to the DoD", Sigplan notices, Vol. 3, No. 10, Oct 1978.
[7] Rose, Frank, "Joy of Hacking", Science 82, Vol. 3, No. 9, Nov 82, pp. 58-66.
[8] "The Hacker Papers", Psychology Today, August 1980.
ACKNOWLEGEMENT
---------------------------------
I would like to thank Jan E., Dave S., Rich G., Rich E. for their help in characterizing the Real Programmer, Heather B. for the illustration, Kathy E. for putting up with it, and atd!avsdS:mark for the initial inspiration.
本物のプログラマは仕様を書かない
本物のプログラマは仕様書を書かない。ユーザーはどんなプログラムも手に入る身の上を幸運と思い、ありがたくおしいただくべきである。
本物のプログラマはコードにコメントを入れない。書くのが難しいプログラムは、読むのも難しいのだ。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
本物のプログラマは quiche を喰わない。本物のプログラマは quiche のスペルも知らない。Twinkies と、コーラと、焼けるように辛い四川料理を喰う。
本物のプログラマはフローチャートなぞ書かない。フローチャートは、結局のところ文盲のための文書フォームである。穴居人はフローチャートを描いた；どれだけ描いたか見てみるがいい。
本物のプログラマはマニュアルなぞ読まない。リファレンスへの依存度は初心者と臆病者のバロメーターだ。
本物のプログラマのプログラムは、けっして最初からまともに働かない。しかしマシンに投げ込むと、30時間の連続デバッグをほんの何度か繰り返してパッチが当たり、動くようになる。
本物のプログラマは Fortran を使わない。Fortran は白靴下を履いた臆病者のエンジニアや、パイプ圧フリークや、結晶解析のチビどもが使うものだ。奴らは有限要素解析と核反応炉シミュレーションで喜ぶ。
本物のプログラマはCOBOLを使わない。COBOL はちんけなアプリケーションプログラマが使うものだ。
本物のプログラマは9時から5時まで働かない。もし本物のプログラマが朝 9時に居たら、それは徹夜していたのだ。
本物のプログラマはBASICなど書かない。一般に、12歳以上になってBASIC を書くプログラマはいない。
本物のプログラマは文書を書かない。文書は一覧表や object deck を読めない馬鹿のためにあるのだ。
本物のプログラマは Pascal だの Bliss だの Ada だの、その他もろもろのアカじみたコンピュータ科学用言語は使わない。強力な変数型はオツムの弱い奴らのためのものだ。
本物のプログラマは、必要としているユーザーより、よく解っている。
本物のプログラマは構造化プログラミングを共産主義者の陰謀だと考えている。
本物のプログラマはスケジュールを使わない。スケジュールはマネージャーのゴマすりのためにある。本物のプログラマはマネージャーを未決箱の中に置いておくのを好む。
本物のプログラマは冒険すると気分が良くなる。
本物のプログラマは PL-I など使わない。PL/I は COBOL と Fortran のどちらも選べない過保護なガキのためにあるのだ。
本物のプログラマは APL など使わない。(プログラム全体を 1行で書けない限りは)。
本物のプログラマは LISP など使わない。実際のコードより多くの括弧を使うのは女々しいのだ。
本物のプログラマは構造化プログラミングを潔しとしない。構造化プログラミングは強迫症で、早期にトイレを躾られ、ネクタイを締めてよく削った鉛筆を机の上にきれいに並べておくような神経症のためにあるのだ。
本物のプログラマはチームプログラミングという概念を好まない。もちろん、自分がチーフプログラマなら別だ。
本物のプログラマにマネージャーは無用の長物だ。マネージャーは必要悪。マネージャーは同僚連中や小言の生成装置や、上級プランナーやその他の精神欠格者と付き合うときのためにある。
本物のプログラマは浮動小数点演算を軽蔑する。浮動小数点は "器の小さい" ニヤけた寝小便たれどものためにあるのだ。
本物のプログラマはオンボロのマーヴェリックなど運転しない。BMWやリンカーンや、フロアシフトのピックアップトラックを好む。かっ飛べるバイクは高く評価される。
本物のプログラマはスケジュールを信用してない。プランナーがスケジュールを作る。マネージャーはスケジュールを "引き締める"。コーダーは恐がって、スケジュールに合わせようとがんばる。本物のプログラマはスケジュールを無視する。
本物のプログラマは自販機のポップコーンを好む。並のコーダーはそれを電子レンジで熱するが、本物のプログラマはCPUの熱を使う。コーンの破裂をきいて、いまどのジョブが走っているかが解るのだ。
本物のプログラマはインストラクション1つ1つのニュアンスを区別して、どのプログラムでも実際に使い分ける。仔犬並の設計では、例外インストラクションが他の実行プログラムをターゲットインストラクションとしてアドレスするのを認めないだろう。本物のプログラマは、こうしたセコい制限を軽蔑する。
本物のプログラマは茶色いランチバッグを職場に持ち込まない。自販機があればそこで買う。自販機がなければ食べない。自販機は quiche を売ったりしないからだ。
本物のプログラマはディスクが diskであり、disc でないと知っている。Disc と書くのは泣き虫の quiche eater に後押しされたアカの陰謀だ。
本物のコンピュータ科学者はコードを書かない
本物のコンピュータ科学者はコードを書かない。たまにプログラミングシステムをいじり回すが、レベルが高すぎるのでけっしてカウントしない。(そしてめったに正しくカウントできない、正確さはアプリケーション次第)。
本物のコンピュータ科学者はコードにコメントを入れない。識別子が長すぎて、ディスク容量が足りないのだ。
本物のコンピュータ科学者はユーザーインターフェースを書かない。見ためについて考えるなど、滅多にない。
本物のコンピュータ科学者は quiche など食べない。彼らは四川料理を避ける。ハッカーどもが見つけたからだ。本物のコンピュータ科学者の多くは実装のディテールを食べようとする。(その他は切り刻んでハッカーと一緒に食べるが、それはデザートにアイスクリームが出るときだけだ)
対話式のデバッガと、構造エディタと、拡張されたクロスモジュール形式のタイプチェックが完全に揃っていないプログラミング環境では、コンピュータ科学者は手も足も出ないだろう。でも連中は、こうした環境で小切手の収支計算をしなければならないかもしれない。自分のシステムではできないからだ。
本物のコンピュータ科学者はアセンブラでプログラムしない。彼らは2Bの鉛筆以上にポータブルなものでしか書かないのだ。
本物のコンピュータ科学者はプログラムをデバッグしない。動的に変更していくのだ。FORTRAN でも COBOL でも BASIC でも、動的変更の方法を誰も開発していないので、この方が安全なのだ。
本物のコンピュータ科学者はCの構造化のコンセプトを好むが、これに懐疑的でもある。コンパイルされて構造が消えてしまうからだ。(バッチ処理フリークと効率気違いはコンパイラーに腹をたてている。ぜんっぜん動的じゃないからだ。)
本物のコンピュータ科学者は囲碁を好む。山登りに反対する気はないが、実際に登るのは仕様の実装であって、プログラマに任せて放ってある、というわけだ。
本物のコンピュータ科学者はADAをその高い美学的価値ゆえに尊敬する。しかし実際にプログラムするのが至難だとわかった。実装するにはあまりに大きすぎたのだ。ほとんどのコンピュータ科学者はこのことに気づいていない。ADAに追加すべき機能をまだ探しているのだ。
本物のコンピュータ科学者はPM5時からAM9時まで働く。仕様変更に必要な 8メガバイトの主記憶は、その時間にしか使えないからだ。(本物の仕事は動的システムに必要なMIPSが得られる午前2時に始まる)。本物のコンピュータ科学者は、3081s をシェアしていては本物の仕事ができないと知ってるのだ。
本物のコンピュータ科学者は、未来のハードウェアで動く言語の仕様しか書かない。ホモサピエンスなるハードウェアが、たかだか1個の惑星に適合するための仕様でさえ、彼らが書けるかどうか疑わしいのだが。
本物のコンピュータ科学者は、自分の環境でビットマップグラフィックスを使えるように計画をたてるのを好む。ビットマップグラフィックスは素晴らしい。高すぎて誰も買えないだろうから。したがって、彼らのシステムは試作品で終るだろう。
本物のコンピュータ科学者は、PL/1 や PASCAL、LISP などが世に出たことを後悔している。ADAもまたその中に入ろうとしているが、Ada 女史はまだ人々が過ちをおかすのを黙って見ている。
本物のコンピュータ科学者はユーザーのコンセプトを愛する。ユーザーはいつも、同僚のコンピュータ科学者が語ることに驚嘆する；たしかに、それはいま彼らのシステムを使うよう強制されているスタッフの言い分よりは美しく聞こえる。
本物のコンピュータ科学者は現行ハードウェアのアイデアを嫌う。ハードウェアには制限があるが、ソフトウェアにはないからだ。チューリングマシンなど、I/Oまわりがおそろしく貧弱で、実に恥ずかしい代物だと思う。
本物のコンピュータ科学者は会議を愛する。3081 にビットマップスクリーンをつなぎ、それを会議場まで引きずっていくなど、誰も想像できないだろう。だから、連中のシステムがどれだけ遅いか、誰も知らないのだ。
本物のソフトウェアエンジニアはダンプを読まない。
本物のソフトウェアエンジニアはダンプを読まない。ダンプなど絶対にできないし、ごくまれにダンプに出くわしたときは、喜んでヒマつぶしの道具にしてしまうからだ。
本物のソフトウェアエンジニアはコードにコメントを入れない。識別子はコメントする必要がないところまでニーモニックにされてるからだ。
本物のソフトウェアエンジニアはアプリケーションプログラムを書かない。アルゴリズムを実装するのだ。誰かが自分のアルゴリズムを使えそうなプログラムを抱えていたら、喜ぶのだ。だが、彼らにユーザーインターフェースを書けと頼んではいけない。
本物のソフトウェアエンジニアは quiche を喰う。
再帰的な関数呼び出しがないと、本物のソフトウェアエンジニアはプログラムを書かない。
本物のソフトウェアエンジニアは、アセンブラでプログラムを書かない。考えただけでも吐き気がするのだ。
本物のソフトウェアエンジニアはプログラムをデバッグしない。プログラムの妥当性を確認するのだ。このプロセスでは、必ずしもコンピュータ上で何かを実行するわけではない。おそらく、妥当性確認支援パッケージを走らせる以外は。
本物のソフトウェアエンジニアは C の構造化のコンセプトを好むが、懐疑的でもある。C は"よりマシンに近い"ところをいじれると聞いているからだ。
本物のソフトウェアエンジニアはテニスをする。一般に、彼らは体が熱くなって汗をかくようなスポーツを嫌い、シャワーに当たれないほどデブだ。(だから登山は論外)。たまに職場でもテニスシャツを着ているが、それはよほど熱い日だけだ。
本物のソフトウェアエンジニアは、その理念と徹底した純粋性ゆえに PASCAL を尊ぶが、実際にプログラミングするのは難しいとよくわかった。だがそうなると自分が無価値だということになってしまう。だから、このことは友達にも言っていない。
本物のソフトウェアエンジニアは9時から5時まで働く。仕様だからだ。夜中に働くのは、文書化されてない外部手続きを使うようなものだと感じてるのだ。
本物のソフトウェアエンジニアはどんなマシンにも現実に実装されていない言語で書くが、その言語は公式仕様だけが (BNFで) 決まったものだけだ。こうすることで、彼らはマシン依存性を考慮する煩わしさから逃れているのだ。マシン依存性は本物のソフトウェアエンジニアを憂鬱にする。
本物のソフトウェアエンジニアは ADA を書かない。標準文法が公式な仕様として全然決まってないからだ。
本物のソフトウェアエンジニアは自分専用のコンパイラーを書くのを好む。それも出来ればPROLOGで。(PROLOG 自身を、それも実装されてない言語で書くのも好むが、実際に走らせるのが難しいということがわかったのだ。)
本物のソフトウェアエンジニアは、COBOL と FORTRAN と BASIC が世に出たことを残念だと思っている；PL/1 もその中に入ろうとしているが、批判するほどのものじゃない；組み込み関数が多すぎるのだ。
本物のソフトウェアエンジニアはユーザーの存在にもそれほど幸せを感じていない。ユーザーはアルゴリズムの実装とその検証について、いつも間違ったアイデアを抱えているみたいだからだ。
本物のソフトウェアエンジニアは通路の向うに鎮座していつも仕事を中断させる、不可解で脂ぎったハードウェアを好まない。彼らはハードウェア屋をまったく信用しておらず、マシンがあらゆる階層で仮想化できればいいと思っている。彼らはパーソナルコンピュータを好むかもしれない (こいつらは転送途中に DFA を killして他へ移ったりできないって知ってるね)。もっとも、妥当性検証支援パッケージを走らすには、8メガバイト必要だということを除けばだが。
本物のソフトウェアエンジニアは、WFF 'N' PROOF で遊んでるときに気分が良くなる。
本物のプログラマは仕様を書かない。
本物のプログラマは仕様書を書かない -- ユーザーはどんなプログラムも、それが手に入る身の上を幸運と思い、ありがたくおしいただくべきである。
本物のプログラマはコードにコメントを入れない。書くのが難しいプログラムは、読むのも難しいのだ。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属版にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
本物のプログラマは quiche を喰わない。Twinkies と四川料理を喰うのだ。
本物のプログラマは COBOL を使わない。COBOL はちんけなアプリケーションプログラマが使うものだ。
本物のプログラマのプログラムは、けっして最初からまともに働かない。しかしマシンに投げ込むと、"たった30時間"のデバッグ作業をほんの何度か繰り返すだけでパッチが当たり、動くようになるのだ。
本物のプログラマは Fortran を使わない。Fortran はパイプ圧フリークや、結晶解析のチビどもが使うものだ。
本物のプログラマは9時から5時まで働かない。もし本物のプログラマが朝 9時に居たら、それは徹夜していたのだ。
本物のプログラマはBASICなど書かない。一般に、12歳以上になって BASIC を書くプログラマなどいない。
本物のプログラマはPL/1など使わない。PL/1 は COBOL と Fortran のどちらも選べないプログラマのためのものだ。
本物のプログラマは APL など使わない。どんな馬鹿でも APL を隠れみのにして潜んでいられるからだ。
本物のプログラマはテニスみたいな、いちいち服を着替えなきゃならないスポーツはしない。登山は OK だ。本物のプログラマはマシンルームが突然盛り上がって山になったときに備えて、いつも登山靴を履いている。
本物のプログラマは Pascal だの Bliss だの Ada だの、その他もろもろのアカじみたコンピュータ科学用言語は使わない。強力な変数型はオツムの弱い奴らのためのものだ。
本物のプログラマは、やるべきことをユーザーよりよく知っている。
本物のプログラマは構造化プログラミングを共産主義者の陰謀だと思っている。
本物のプログラマはスケジュールなどたてない。スケジュールはマネージャーのゴマすりの道具だ。
本物のプログラマはマネージャーを不安の中に置いておくのを好む。
本物のプログラマは冒険の最中でこそ、よく考えられる。
本物のプログラマは半分がた仕事を済ませたときに、そうしたがる。
本物のプログラマは自分のマイコンでPASCALコーディングして楽しむ。だが、それは改良するためであって自分自身はけっして使わない。
本物のプログラマは 370 マシンで CP/M を動かしたり、自分の ZX81 マイコンに MVS を載せたりして遊ぶ。
本物のプログラマは自分専用のアセンブラを書く。それもできれば LISP で。
本物のプログラマはセキュリティーシステムを恐れない。セキュリティーデータセットでも RACF ビットを切り、未署名のメッセージを残すのだ。
本物のプログラマはソースをアップデートして ZAP に反映したりしない。つまり ZAP も明日には変更されるわけだ。
T h e V O G O N N e w s S e r v i c e
VNS TECHNOLOGY WATCH: [Mike Taylor, VNS Correspondent]
===================== [Littleton, MA, USA ]
COMPUTERWORLD 1 April
作者が認めた UNIX と C のウワサ
そのアナウンスがあったとき、コンピュータ産業は凍りついた。ケン・トンプソン、デニス・リッチー、そしてブライアン・カーニハンが Unix オペレーティングシステムとプログラミング言語C を作ったのは、
エイプリルフールの手の込んだ悪ふざけで、どうしたことか20年も続いてしまった、と認めたのだ。最近の UnixWorld ソフトウェア開発フォーラムで、トンプソンは以下のことがらを明らかにした：
"1969年、AT&T は GE/ハネウェル/AT&T 共同の Multics プロジェクトを打ち切ったところだった。ブライアンと私はちょうど、スイスのチューリヒ工科大学の Nichlaus Wirth 教授が作成した Pascal の 早期リリースに向けて、仕事を始めたところだった。
私たちはそのエレガントなまでのシンプルさと能力に感銘を受けた。デニスはちょうど、トールキンの有名な 'Lord of the Rings (指輪物語)' の爆笑モノ政治風刺パロディー 'Bored of the Rings (指輪は飽きた)'を読み終えたところだった。
そこで私たちは、Multics 環境と Pascal のパロディーという悪ふざけを考えることにした。デニスと私はオペレーティングシステムを担当した。
私たちはまず Multics を見て、それから新しいシステムは普通のユーザのフラストレーションができるだけ溜るように、できるだけ複雑怪奇な代物になるようデザインした。
これに Multics をもじって Unix という名前をつけ、きわどいけども遠回しにパロディーだとわかるようにもしておいた。それから、デニスとブライアンは Pascal を本当にひねったものを作り、
'A' という名前をつけた。他の連中が'A'をもとにして本気でプログラムを書き始めてしまったので、私たちはあわててもっと複雑怪奇な機能を追加していって、B から BCPL、そしてついに C へと進化させた。
下に示す文がきっちりコンパイルできるのを確認すると、私たちは進化を止めた：
for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);
こんな文法を許容してしまうような言語を、まさか現代のプログラマが使うだろうとは、私たちは思っていなかったんだ! 私たちはただ、このシステムをソ連に売れば、連中のコンピュータサイエンスは少なくとも20年ほど退化するだろうなぁ、
とか考えてたんだ。AT&T その他の米国企業が本気で Unix と C を使いはじめたときは、驚いたのなんの! この1960年代の技術のパロディーを使って、ほんのちょっとでもまともなプログラムを書こうと思ったら20年の経験がいるんだから。
だけど、私たちは Unix と C プログラマの不屈の精神を思い知ることになった (ふつうそんなことはしないが)。
ブライアンとデニスと私は、ここ数年来どんな場合でも、ずっと Apple Macintosh 上の Pascal で仕事してきたし、この私たちがずっと昔やったバカなイタズラが、混沌と混乱と、じつに無作法なプログラミングを生んだ責任を痛感してたんだ。"
AT&T、マイクロソフト、ヒューレット-パッカード、GTE、NCR、DECなど、主要な Unix ベンダーとその顧客は、現在のところコメントを控えている。
ボーランドインターナショナルは Turbo Pascal、Turbo C、Turbo C++ など著名な製品を擁する Pascal と C 開発環境の最大ベンダーだが、この件については数年前から疑惑を持っており、
今後は Pascal 製品の増強をさらに進める一方で、Cの開発は行なわない方針だと語った。IBMのスポークスマンは大笑いを止めることができず、RS-6000 の運命に関する緊急招集会議のニュースは聞くことができなかった。
ただ、'VM は本当に、もうすぐ、出る'とだけ伝えた。Pascal や Modula 2、Oberon など構造化言語の生みの親である、チューリヒ工科大学の Wirth 教授は、ただ "P. T. バーナムは正しかった"とだけ答えた。
関連する最新情報：信頼できる情報筋(ふだんは)によると、上記と同様の告白が、今度はウィリアム・ゲイツ氏の口からMS-DOSとウィンドウズオペレーティングシステムについて行なわれる模様だ。
IBM スポークスマンは仮想マシン (VM) 関連製品は内輪の冗談が誤って外部に洩れたものだという噂を否定している。
{COMPUTERWORLD 1 April} {contributed by Bernard L. Hayes}
[][][][][][][][] VNS Edition : 2336 Tuesday 4-Jun-1991 [][][][][][][][]
初出公開： 2000年01月05日、 最終更新日： 2000年02月25日
Copyright Ed Post 1982.
この文書は、かつてUSENETを通じて世界中に無償配信されたものの翻訳である。訳者の意向としては内容を不当に改竄しない限り自由に複写、再配布、再利用を認めるものだが
(つまり翻訳の改良ならＯＫってことだ)、原著者の意向については不明である。この点を知った上で、読者の責任において利用してほしい。
もし原著作権者から何らかのクレームがついた場合は、ただちに削除する予定であることを、あらかじめおことわりしておく。
