Real Programmers Don't Use PASCAL 本物のプログラマーはPASCALなど使わない Ed Post エド・ポスト Tektronix, Inc. テクトロニクス社 P.O. Box 1000 m/s 63-205 私書箱 1000/ms 63-205 Wilsonville, OR 97070 ウイルソンビル、オレゴン州 97070 Copyright (c) 1982 著作権表示 (c)1982年 (decvax | ucbvax | cbosg | pur-ee | lbl-unix)!teklabs!iddic!evp 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 that understood computer programming, and the Quiche Eaters were the ones that 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.) 古き良き時代――コンピューターの「黄金時代」、一人前の男と子供(人によっては文学的に「本物の男」と「キッシュ喰らい【Quiche Eater。Quicheは甘くないパイ菓子のようなもので、Quiche Eaterは軟弱な男というイメージ】」と表現する。)を区別するのは簡単だった。この時代、本物の男はコンピューター・プログラミングを理解しており、キッシュ喰らいはそうではなかった。ある本物のコンピューター・プログラマーは次のように話した。「DO 10 I=1,10【それを10回繰り返せ】」あるいは「ABEND【異常終了。ABnormalENDのこと。IBM/360のエラーメッセージ】」。(お察しの通り、彼等は実際に大文字で話した。)一方、普通の人々は「コンピューターは自分には複雑すぎる。」とか「コンピューターとは協調できない。非人間的すぎる。」などと話していた。(以前に指摘されている通り本物の男は何者とも「協調」しないし、非人間的になることを恐れもしない[1]。) 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. しかし、当たり前の事だが、時代は変わる。我々は今や、老婦人が持つ電子レンジにコンピューターが搭載されている世界に直面している。12歳の小僧がアステロイドやパックマンでは本物の男を叩きのめすことができるし、誰でも自分自身のコンピューターを買うことや、それを理解することすらできる。本物のプログラマーは絶滅の危機にさらされており、ゴミ80【TRASH-80。パソコンTRS-80への悪口】を持っている高校生に置き換えられる危険に瀕している。 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). 典型的な高校二年生のパックマン・プレーヤーと本物のプログラマーの違いを明確にする必要がある。この違いが明確になれば、そんな小僧どもに自分は将来こうでありたいと熱望するような姿−−人生のお手本、父親像を示すことができるだろう。また、本物のプログラマーの雇い主たちに(相当な額の人件費を押さえるために)12歳のパックマン・プレーヤーを本物のプログラマーと入れ替えることは間違いである理由を示すこともできるだろう。 LANGUAGES 言語 --------- 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 from 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. その他大勢の中から本物のプログラマーを見つけだす最も簡単な方法は、彼(あるいは彼女)が使うプログラミング言語を見ることだ。本物のプログラマーはFORTRANを使う。キッシュ喰らいはPASCALを使う。PASCALの設計者であるNicklaus Wirthは「あなたをどうお呼びしたら良いでしょうか?」という問いに対して次のように答えた。「どちらでもかまいませんが、発音で呼ぶなら『バート』、価値で呼ぶなら『ワース』【Worth、より悪い】ですね。」このコメントを聞くや否や誰でもNicklaus Wirthはキッシュ喰らいであるとを指摘できる。本物のプログラマーに承認される唯一のパラメーター伝達機構は、IBM/370 FORTRAN GもしくはHコンパイラーに実装されているような、値で呼び出されるリターン【call-by-value-return。『価値で呼ぶ返答』、と解釈できる】だからである。本物のプログラマーは仕事を仕上げるのに抽象的な意味付けなど必要としない。キーパンチとFORTRAN IVとビールがあれば最高に幸せなのだ。 ・Real Programmers do List Processing in FORTRAN. ・本物のプログラマーはリスト操作をFORTRANで行う。 ・Real Programmers do String Manipulation in FORTRAN. ・本物のプログラマー文字列操作をFORTRANで行う。 ・Real Programmers do Accounting (if they do it at all) in FORTRAN. ・本物のプログラマーは(もし必要ならば)会計処理をFORTRANで行う。 ・Real Programmers do Artificial Intelligence programs in FORTRAN. ・本物のプログラマーは人工知能プログラムを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. もしFORTRANでできないのならば、アセンブリ言語で行う。もしアセンブリ言語でもできないのならば、やる価値のないことだろう。 STRUCTURED PROGRAMMING 構造化プログラミング ---------- ----------- 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 examples 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: コンピューター科学の研究活動はここ何年か「構造化プログラミング」にのめり込んでいる。連中はある種の言語構造や技術を使うことでプログラマーはより容易にプログラムを理解できると主張している。もちろん、全員が特定の構造を支持しているわけではなく、たとえばいいかげんな機関誌とか何とかに相も変わらずぴったり1ページにおさまるように書かれた彼らの特殊な見解が掲載されているが、誰でも納得させられるにはとても及ばない内容だ。私は卒業したときには世界一のプログラマーだと自負していた。私は無敵の三目並べプログラムを書けたし、5種類のプログラミング言語を使いこなしていたし、ちゃんと動く1000行のプログラムを作ることもできた(本当だ!)。そして、私は現実の世界に直面した。現実の世界での初めての仕事は20万行のFORTRANプログラムを読んで理解し、2倍以上に動作を速めることだった。本物のプログラマーなら誰でも、どんな構造化プログラミングでもこんな問題を解決する助けにはならないことが分かるだろう。この仕事には本当の才能が必要だ。本物のプログラマーと構造化プログラミングについてちょと考えてみよう。 ・Real Programmers aren't afraid to use GOTOs. ・本物のプログラマーはGOTOを使うことを恐れない。 ・Real Programmers can write five-page long DO loops without getting confused. ・本物のプログラマーは混乱することなく5ページにまたがるDOループを書ける。 ・Real Programmers like Arithmetic IF statements -- they make the code more interesting. ・本物のプログラマーは算術的IF構文を好む。これはコーディングをより楽しくする。 ・Real Programmers write self-modifying code, especially if they can save 20 nanoseconds in the middle of a tight loop. ・本物のプログラマーは、たとえばループ中で20ナノ秒【1億分の2秒】節約できるのならば、自己改編型コードを書く。 ・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. ・FORTRANには構造化IF、REPEAT〜UNTIL、CASE宣言などが無いため、本物のプログラマーはこれらを使うかどうか悩む必要がない。その上、どうしても必要ならばこれらの機能を割当型GOTOで模倣することができる。 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 programing 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. データ構造もまた、最近大きくマスコミに取り上げられている。抽象データ型、構造体、ポインター、リスト、そして文字型はある種のグループでは一般的となっている。(キッシュ喰らいとして言及した)Wirthは実際に、他の方法を使わずデータ構造を基本とした形でプログラムが書けることを示した本[2]を書いている。本物のプログラマーは皆知っていることだが、唯一有効なデータ構造は配列である。文字列、リスト、構造体、データ・セット――これらはすべて配列の特殊な形式であって、あらゆる種類の混乱に陥ることなく、配列としてとても簡単に扱うことができる。妙なデータ型式の最も悪い点はそれを宣言しなければならないことだが、我々が知っている通り、本物のプログラミング言語は(6文字の)変数名の最初の文字によってあらかじめ型が決まっている。《Iは整数型(Integer)、などFORTRANには暗黙の型宣言がある。》 OPERATING SYSTEMS オペレーティング・システム --------- ------- 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. 本物のプログラマーはどんなオペレーティング・システムを使うだろうか? CP/M? 神がお赦しにならない――CP/Mは基本的におもちゃのオペレーティング・システムだ。老婦人でも小学生でも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. Unixはもちろんずっと複雑であるが――典型的なUnixハッカーはPRINTコマンドが今週どう呼ばれたのかを思い出すこともできない――しかし、うまく行ったとしてもUnixはよくできたテレビ・ゲームに過ぎない。人々は困難な仕事をUnixシステムでこなすことはない。UUCPネットを使って世界にジョークをばらまいたり、アドベンチャーゲームを書いたり、ちょっとした論文を書くのがせいぜいだ。 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/370だ。良いプログラマーは手に入れたばかりのJCL【Job Control Language。スクリプトでバッチ・システムをコントロールするIBMマシンのツール】のマニュアルを読んでIJK305Iエラーについての記述を見付け、理解することができる。偉大なプログラマーはマニュアルを一切見ること無くJCLを書くことができる。本当に驚異的なプログラマーは16進計算機を使わなくても6メガバイトのコアー・ダンプ【エラーでプログラムが落ちた時に残されるバイナリー・コード】の中に潜むバグを探し出すことができる。(私は実際にその様子を見たことがある。)《私(翻訳者)も見たことがある。ただし、UNIXマシン上のCプログラムのコアー・ダンプについてであるが。》 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. OS/370は本当に非凡なオペレーティング・システムだ。これはわずか一つのスペースの配置を間違っただけで数日分の仕事を壊すことができるので、プログラマーの集中力を強化する。システムに近付く最適な方法はキーパンチである。OS/370にはタイム・シェアリング・システム【略称TSS】があると指摘する人もいるが、注意深く調べた結果私はそれが間違っていると結論した。《当時のIBMマシンでは一般にカード入力によるバッチ処理の方がTSSより優先順位が高く、さらにはTSSの設定をいじってCPUの占有率を自在に設定することもできた。この手で自分の好みのプログラムを優先的に処理するシステム管理者がけっこう多かったらしい。最近のシステムも同じで、BSD系システムでは管理者によるナイス・レベルの調整がそれにあたる。教訓:システム管理者とは親しくなった方が何かとお得。》 PROGRAMMING TOOLS プログラミング・ツール ----------- ----- 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 Seymour 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. Seymour, needless to say, is a Real Programmer. 本物のプログラマーはどんなツールを使うのだろうか? 理論的には、本物のプログラマーはコンピューターのフロント・パネルに入力することでプログラムを走らせることもできる。かつてコンピューターがフロント・パネルを備えていたころには、時々行われていたことだ。典型的な本物のプログラマーはブートストラップ・ローダー【メイン・プログラムを起動するための小さいプログラム。編み上げ靴の紐を結ぶ動作のイメージから】全部を16進法で覚えていた。そして、彼のプログラムでブートストラップ・ローダーが壊れたときにはいつでもトグルから入力して再起動した。(その当時、メモリーは実際に記憶だった――動力が切れても消えなかった。現在、メモリーは望まない時に消え、必要がなくなっても存在し続けるものになっている。)伝説によれば、Cray Iスーパーコンピューターやコントロール・データ社のコンピューターのほとんどの発明者であるSeymore Crayは、CDC7600がはじめて動力を与えられたとき、実際にフロント・パネルのトグルを記憶にのみ頼って操作することで最初のオペレーティング・システムを入力したと言う。Seymoreは、言うまでもないが、本物のプログラマーである。 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 lineprinter in his toolkit, he can get along with just a front panel and a telephone in emergencies. 私が大好きな本物のプログラマーの一人がテキサス・インスツルメンツのシステム・プログラマーだった。ある日、彼はある重要な仕事を保存している最中にシステム・クラッシュに見舞われたユーザーからの遠距離電話を受けた。ジムは電話上の指示で障害を直すことができた上、ユーザにフロント・パネルのトグルでディスクI/O命令を入れさせ、16進命令でシステムを修理して、電話だけでレジスターの内容を読み取ることができた。この物語の教訓:本物のプログラマーはキーパンチやライン・プリンターを道具として常時使いこなしているが、緊急の際に電話とフロント・パネルでコンピューターを操作することもできる。 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. いくつかの会社では、029キーパンチを使うために10人のエンジニアが並んで待ってテキスト・エディティングをする必要はない。実際のところ、私が働いているビルではキーパンチはひとつもない。この状況では本物のプログラマーも「テキスト・エディター」プログラムで仕事をする必要がある。ほとんどのシステムはいくつかのテキスト・エディターを提供してくれるので、本物のプログラマーは彼自身の流儀に見合うものを注意深く選ぶ必要がある。多くの人はゼロックス社のパロ・アルト研究所でAltoとDoradoコンピューターを使うために開発されたもの[3]が世界一のテキスト・エディターだと信じている。残念なことに、本物のプログラマーはオペレーティング・システムがSmalTalkであるコンピューターを使うことは考えられないし、マウスを使ってコンピューターに語りかけることもあり得ない。 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. ゼロックスのエディターに含まれる概念のいくつかは、より妥当な名前をつけられたオペレーティング・システム上のエディターに統合された。EMACSとVIの二つである。これらのエディターの問題は、本物のプログラマーは「見ているものが手に入るもの」というテキスト・エディターの概念は女性がそう【欲しいものについて「見つめていれば手に入る」と】考えるのと同じくらい間違っていると受け取ることである。そうだ、本物のプログラマーは「求めたからこそ手に入った」となるテキスト・エディターを必要としている。――複雑で、不可解で、強力で、無慈悲で、危険なもの。つまりTECOである。《TECOはTape/Text Editor and COrrectorの大文字の部分。MITで開発されたもので、プログラミング言語に似た機能を持ち、あらゆる文字列がプログラムとしても解釈され得る。後述の名前をプログラム扱いしてみる遊びはこの機能に依る。》 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. TECOのコマンド・シーケンスは読める文章よりもライン・ノイズに近いことが分かっている[4]。TECOを使ったとても面白いゲームは名前をコマンドとして入力して、それがどんな動作をするかを見ることだ。TECOと会話している際にはあらゆるタイピング・エラーがそのプログラムを破壊するか、あるいはさらに悪いことには――微妙で不思議なバグが一度は動いたサブルーチンに忍び込むことになる。 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: このため、本物のプログラマーたちは、ほぼ動作するプログラムを実際にエディットすることには気が進まない。むしろSUPERZAP(非IBM機種ではこれに相当するもの)という素晴らしいプログラムを用いてバイナリー・オブジェクト・コードで直接パッチを当てる方がずっと楽だと感じている。これは非常にうまく行くため、IBMシステムで動作する多くのプログラムはオリジナルのFORTRANコードとはほとんど関係なくなっている。また、多くの場合は、オリジナルのソース・コードはすでに入手できなくなっている。このようなプログラムを修正する必要が生じた場合には、本物のプログラマーと呼ぶに値しない者を送り出そうとするマネージャーはいない――キッシュ喰らいの構造化プログラマーはどこから手をつけて良いのかすら分からない。これは「ジョブ・セキュリティー」と呼ばれている。本物のプログラマーが使わないプログラミング・ツールを見てみよう。 ・FORTRAN preprocessors like MORTRAN and RATFOR. The Cuisinarts of programming -- great for making Quiche. See comments above on structured programming. ・MORTRAN【構造化プログラミング言語の一種。FORTRANとはあまり似ていない】やRATFOR【RATional FORtran。FORTRANに構造化の文法を加えたもの】のようなFORTRANプリプロセッサー。プログラミングの調理器−−キッシュを作るのには最適だ。構造化プログラミングについての先のコメントを参照のこと。《MORTRAN、RATFORのいずれも実行の際にはソース・コードをFORTRANコードに変換するコンバーターを介してFORTRANコンパイラーを利用しオブジェクトを生成するため、FORTRANプリプロセッサーとみなすことができる。当然ながら、直接FORTRANコードを書いた場合にくらべて最適化の度合いが甘い。ちなみに、現在のUNIX系システムではFORTRANプログラムはF2C【Fortran to C】でCコードに変換してからCコンパイラーに食わせる仕組みになっているので、今はFORTRANがCのプリプロセッサーに成り下がっている。》 ・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. ・配列境界チェックを行うコンパイラー。これは創造性を抑圧し、EQUVILANCEの面白い使い方の大半を破壊し、また負値のサブスクリプト【配列要素の添え字。普通は0以上の整数】を使ったオペレーティング・システム・コードの変更を不可能にする。最悪の点は、境界チェックは非効率的であることだ。 ・Source code maintainance 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]. ・ソースコード・メンテナンス・システム。本物のプログラマーはコードをカード・ファイルに封じている。そうすることで大事なプログラムがいじられることがないようにできるからである[5]。 THE REAL PROGRAMMER AT WORK 仕事中の本物のプログラマー --- ---- ---------- -- ---- 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!). 典型的な本物のプログラマーはどこで働いているだろうか? 豊かな才能に恵まれている個人が力を傾けるに値するプログラムとはなどんなものだろうか?COBOLで会計処理プログラムを書く、とかピープル誌のメーリング・リストをソートするプログラムを書く、とかいったことに没頭していたい本物のプログラマーなどいないと断じて良い。本物のプログラマーは地球を揺さぶるほど(文字通りに!)重要な仕事を求めている。 ・Real Programmers work for Los Alamos National Laboratory, writing atomic bomb simulations to run on Cray I supercomputers. ・本物のプログラマーはロス・アラモス国立研究所で、Cray Iスーパーコンピューターで走る原子爆弾のシミュレーションを書いている。 ・Real Programmers work for the National Security Agency, decoding Russian transmissions. ・本物のプログラマーは国家安全保障局【略称NSA】でロシアの通信を解読している。 ・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. ・我々の宇宙飛行士がロシア人よりも先に月に行って帰って来たのはNASA【アメリカ航空宇宙局】で働いている数千もの本物のプログラマーの努力に負うところが大である。 ・The computers in the Space Shuttle were programmed by Real Programmers. ・スペース・シャトルに搭載されているコンピューターは本物のプログラマーがプログラムした。 ・Real Programmers are at work for Boeing designing the operating 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. 真に驚異的な本物のプログラマーの幾人かはカリフォルニアのジェット推進研究所【略称JPL。カール・セーガンが勤務していたことで有名】で働いている。彼らの多くは宇宙探索機パイオニアやボイジャーのオペレーティング・システムをすべて暗記していた。地上の巨大なFORTRANプログラムと探索機上の小さなアセンブリ言語プログラムの連携により、彼らは操縦と即興の操作で信じられないほどの離れ業を行った−−6年間の宇宙飛行の後に10km枠の誤差内で土星軌道を通過させ、故障したセンサー機器、無線、バッテリーを修理したり回路を迂回させたりした。真偽のほどは分からないが、ある本物のプログラマーはボイジャー宇宙探索機の数百バイトの未使用メモリーにパターン・マッチング・プログラムを滑り込ませ、そのプログラムが木星の新しい月を探し出し、位置を確認して写真を撮影したと言われている。 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. 現在のガリレオ宇宙探査機の計画では、火星を使った重力カタパルト【惑星軌道を後方から掠めることで重力効果による加速を行うこと。スイング・バイとも言う。】で木星に向かう軌道をとることになっている。この軌道は火星表面から80±3kmを通る。このような許容誤差の飛行にPASCALプログラム(あるいはPASCALプログラマー)を信頼することはできない。 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" ((r), 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 has enough interesting features to make it approachable -- it's incredibly complex, includes methods for messing with the operating system and rearranging memory, and Edsgar 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. ご存知の通り、多くの本物のプログラマーがアメリカ政府のために働いている−−主として国防部門で。当然そうなるべきだろう。しかしながら、最近になって本物のプログラマーの地平に暗雲が立ちこめ出した。国防部門の高位にあるキッシュ喰らいどもが、すべての国防プログラムは「ADA【世界初のプログラマーと考えられているAda Lovelaceにちなんで名づけられたPASCAL起源のプログラミング言語】(DoD【Department of Defense、国防総省】の登録商標)」という名前の、強力に統合された言語で書くべきだと決めたように思われる。ところで、ADAは本物のプログラミングのあらゆる要諦に反する言語になることが運命付けられていたように思われる−−構造を持つ言語、データ型式を持つ言語、強力な型指定能力、そしてセミコロン。簡単に言えば、典型的な本物のプログラマーの創造力を損なうよう設計された言語なのだ。幸運なことに、国防総省によって採用されたこの言語は使ってみたいと思わせるいくつかの面白い仕様を持っている−−信じ難いほど複雑で、オペレーティング・システムと再配置可能なメモリーをごちゃまぜにする方法を含み、そしてEdsgar Dijkstraはこれを好いていない[6]。(ご存知のことと思うがDijkstraは次の本の著者だった。「GoToは危険である【GoTos Considered Harmful】」−−歴史に残るプログラミング論であり【もちろん本物のプログラマーに絶賛されたが】、PASCALプログラマーやキッシュ喰らいにも賞賛された。)しかしながら、決意を固めた本物のプログラマーならばどんな言語上でもPORTRANプログラムを書けるのだ。 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 people doing Graphics in order to avoid having to write COBOL programs. 本物のプログラマーは、自分の主義を多少曲げて先に論じた生命の破壊【前述の原爆シミュレーションや巡航ミサイル・プログラムを指す】よりももう少しくだらない仕事をするかもしれない。充分な稼ぎになるのならばだが。たとえば、Atari社でコンピューター・ゲームを作っている本物のプログラマーも幾人かはいる。(しかし、自分で遊びはしない−−本物のプログラマーはどうやって毎回機械を打ち倒すのか知っている。そこには挑戦の要素がない。)ルーカス・フィルム社で働いているのはすべて本物のプログラマーである。(5,000万人のスター・トレック・ファンの金を拒絶するのは馬鹿げているだろう。)コンピューター・グラフィクス界における本物のプログラマーの割合は他の分野に比べて低い。まだコンピューター・グラフィクスの真の使い道がみつかっていないからだ。一方、すべてのコンピューター・グラフィクスはFORTRANでなされているので、COBOLプログラムを書くのを避けるためにグラフィクスをやる人もかなりいる。 THE REAL PROGRAMMER AT PLAY 娯楽中の本物のプログラマー --- ---- ---------- -- ---- 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: 一般論として、本物のプログラマーは働くのと同じやり方で遊ぶ−−コンピューターを使って。彼は自分にとって楽しみになるのと同じことをやっているだけなのに雇い主が報酬をくれることを常に不思議に感じている。(しかし、その考えを大きな声で言うことは注意深く避けている。)本物のプログラマーも新鮮な空気を吸うためや、ビールの1〜2杯のためにたまには外出することがある。コンピューター・ルーム以外の場所で本物のプログラマーを見つけ出すにはいくつかのコツがある。 ・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. ・フットボール場で。本物のプログラマーとは11×14インチの折りたたみ用紙に印刷したシミュレーションと実際のゲームを比較している人である。 ・At the beach, the Real Programmer is the one drawing flowcharts in the sand. ・海岸で。本物のプログラマーとは砂にフローチャートを描いている人である。 ・A Real Programmer goes to discos to watch the light shows. ・本物のプログラマーは照明が動くさまを観察しにディスコへ行く。 ・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. ・食料品店で。本物のプログラマーは自分の手で会計のレーザー・スキャナーに缶を通したいとこだわる人である。彼はそもそもレジ打ちの人が正確な入力をできるなどと信じていないからである。 THE REAL PROGRAMMER'S NATURAL HABITAT 本物のプログラマーの習慣 --- ---- ------------ ------- ------- 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. ・冷たくなったコーヒーが一部残っているカップ5〜6個。たまには、タバコの吸殻がコーヒーに浮いているかもしれない。あるいは、カップにオレンジ・クラッシュ【炭酸飲料の商品名】が入っているかもしれない。 ・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. ・彼が非常に優秀ではない場合、OS/370のJCLマニュアルや、「オペレーションの原理」のコピーのとりわけ面白いページが開いているかもしれない。 ・Taped to the wall is a line-printer Snoopy calender for the year 1969. ・壁にテープで貼られた、ライン・プリンターで打ち出した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 maintenance 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 inpresses 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: 本物のプログラマーは極度のプレッシャーのもとでは30時間、40時間、ときには50時間休みなしに働くことができる。実際、本物のプログラマーはそういったやり方を推奨する。応答が悪いことは本物のプログラマーの妨げにはならない−−コンパイルの間にちょっと寝る時間が得られるかもしれない。もしスケジュール上のプレッシャーが充分でない場合には、ものごとをより挑戦的にするために、小さいけれど面白い問題に最初の9週間を費やし、それから最後の1週に2〜3回の50時間マラソンをして残りのすべてを片付ける傾向がある。これは仕事が間に合わないかもしれないと絶望的になっていた上司に深い印象を与えるだけでなく、文書を書かない理由付けにもなる。一般論として: ・No Real Programmer works 9 to 5. (Unless it's the ones at night.) ・本物のプログラマーで9時から5時まで働く者はいない。(それが夜ならば話は違う。) ・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. ・本物のプログラマーは妻の名前を知っているかもしれないし、知らないかもしれない。しかし、間違いなくASCII(あるいはEBCDIC)コード・テーブルすべてを知っている。 ・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. ・本物のプログラマーは調理の仕方を知らない。食料品店は朝3時には開いていない。本物のプログラマーはツインキーズ【芯にクリームが詰まっている筒状のスポンジケーキの商品名】とコーヒーで生き延びている。 THE FUTURE 未来 --- ------ 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? 未来はどうだろうか? 最新の世代のコンピューター・プログラマーたちがその先輩たちと同じ世界観で育てられてはいないことは本物のプログラマーにとっていくらか気がかりなところだろう。彼らの多くはフロント・パネルを持ったコンピューターを見たことがない。この頃は計算機なしで16進計算ができる卒業者を見つけることはほとんどできない。この頃のカレッジの卒業者たちは軟弱で−−ソースレベル・デバッガーや、括弧を数えるテキスト・エディターや、「ユーザー・フレンドリー」なオペレーティング・システムによってプログラミングの現実から守られている。最悪なことに、いわゆる「コンピューター科学者」たちの一部はFORTRANを学ぶことなく学位を得ている! 我々はUnixハッカーとPASCALプログラマーの産業になるべく運命付けられているのだろうか? 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 PASCAL 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. 私の経験から、未来は本物のプログラマーにとって明るいとだけ言っておこう。OS/370もFORTRANも消え去る兆候は見せていない。世界中にいるPASCALプログラマーの努力にもかかわらずだ。さらに、狡猾なたくらみ、たとえばFORTRANに構造化プログラミングを組み込むこと、は失敗に終わっている。もちろん、FORTRAN 77コンパイラーを出荷するコンピューター・ベンダーもいるが、どのFORTRAN 77コンパイラーもオプション・カード1枚を加えることでFORTRAN 66コンパイラーとして振舞う−−神がそうあるよう決められた通り《DO〜WHILEといった構造一切なしの単純なDOループとして》動作すべくDOループをコンパイルする−−ようにできる。 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.) Unixでさえ、本物のプログラマーには、かつてそうであったほどには悪くない。Unixの最新リリースは本物のプログラマーが使ってみるかと考えるオペレーティング・システムになる可能性がある。−−ふたつの異なる、そしていくらか互換性のないユーザー・インターフェース、難解で複雑なテレタイプ・ドライバーと仮想メモリー。もし、それが「構造化されている」こと無視するならば、「C」プログラミングも本物のプログラマーの評価を得ることができる。いずれにせよ、型式のチェックはないし、変数名は7文字(10文字?8文字?)であるし、おまけに付いているポインター・データ・タイプはプログラム本体に組み込むことができる−−ちょうどかつてFORTRANとアセンブラーの最良の部分ををひとつに纏め上げたように。(#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 M.I.T. 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! そうだ、未来はそんなに悪くない。なぜ、ここ数年、大衆紙はスタンフォードやマサチューセッツ工科大学【略称MIT】のようなところから巣立ったコンピューターおたくとハッカーたちの輝かしく新しい会社を取り上げ続けているのか([7]、[8])。あらゆる証拠が、本物のプログラマーの精神がこれらの若い男女に宿っていることを示している。間違ったゴールが設定される限り、奇妙なバグが存在する限り、そして非現実的なスケジュールが示される限り、そこには本物のプログラマーが、あとで文書化をするのを避けるための努力も込めて、解決しようと飛び込む問題が存在するだろう。FORTRANに栄えあれ! 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 inspriration. 以下の人たちに感謝をささげる。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, Massachusetts Institute of Technology, May 1980. 5. Weinberg, G., The Psychology of Computer Programming, New York, Van Nostrabd Reinhold, 1971, page 110. 6. Dijkstra, E., On the GREEN Language Submitted to the DoD, Sigplan notices, Volume 3, Number 10, October 1978. 7. Rose, Frank, Joy of Hacking, Science 82, Volume 3, Number 9, November 1982, pages 58 - 66. [8] "The Hacker Papers", Psychology Today, August 1980.