エドガー・W・ダイクストラ: 謙虚なるプログラマ (The Humble Programmer)

エドガー・W・ダイクストラ (Edsger W. Dijkstra)
1972年 ACM チューリング賞受賞講演

度重なる偶然の連鎖により、1952年はじめの春の日に、わたしは公式にプログラマという職業につくことになりました。思い出せるかぎり、私はこの仕事を始めた最初のオランダ人です。今から考えてみますと、もっとも驚くべきことは、少なくともわたしのいた世界では、この職業が登場するのがいかに遅かったかということです。この遅さは今からみると信じられないほどのものですが、わたしはこの疑いもない遅さを確立した、あのころの2つの思い出に深く感謝しています。

プログラミングというものを始めて3年かそこらたったころ、わたしは自分のいたアムステルダム数学研究所^(*1)で上司だった A. van Wijngaarden と話をしました。この会話は、わたしが生涯にわたって感謝すべきものでした。内容は… そのときわたしはライデン大学で理論物理学の研究も並行してやることになっていたのですが、この2つを同時にやるのは次第に大変になってきたと感じていました。そこで私はどちらかに心を決めなければならなかったのです。プログラミングをやめて、本物の、尊敬されるような理論物理学者になるか、あるいは物理の研究は最低限の労力で形式的に終えるだけにしておいて、かわりに…え、何? プログラマ? それって尊敬されるような職業ですかね? そもそもプログラミングって何です? これを知的かつ尊敬される職業たらしめるような知識の体系というのは、一体どこにあるんでしょう? わたしはいまでも、ハードウェアをやっていた同僚をうらやましく思ったことをはっきり覚えています。少なくとも彼らは自分の職能とは何かと問われれば、それは真空管について、あるいは増幅器その他もろもろについて、万全な知識を身につけていることだ、と答えることができました。いっぽう私はといえば、そんなものは何もないのです。私はじつに不安な気持で van Wijngaarden のオフィスのドアをたたき、彼に「ちょっと話がある」と切り出しました。そして数時間後、彼のオフィスを出たとき、私は違う人間になっていました。彼は私の抱えている問題を辛抱づよく聞いてくれ、たしかに今までプログラミングをする職業分野というものはあまり聞いたことがないと言いました。しかしその後、彼は落ちついて、自動計算機というものは将来にわたっても存在するものだし、我々はまだ最初の段階にいるのだから、今後わたしがプログラマを尊敬できる職業にした人間、と呼ばれるようになってはどうかと言いました。これがわたしの人生におけるターニングポイントだったと思います。わたしは物理の研究をできるかぎり早く、形式的に、終わらせました。以上の話から得られる教訓というのはこうです — 若い人にアドバイスを与えるときは、当然のごとく慎重にならなければいけない。なぜならときに人はそれを真に受けてしまうのだから!

(*1: "Mathematical Centre in Amsterdam")

わたしはその2年後、1957年に結婚したのですが、オランダでは婚姻届を出す際に、自分の職業を申告する必要があります。わたしは自分はプログラマであると言いました。しかしそんな職業はないということで、これはアムステルダムの市役所から拒否されてしまいました。そこで、信じられないかもしれませんが、わたしの婚姻届は間抜けにも「職業」欄のところに「理論物理学者」と書いてあるのです!

わたしの国でプログラマという職が現れるのがいかに遅かったかについてはこれくらいにしておきます。その後、世界をいろいろ見てきましたが、わたしの印象では、時期の差こそあれ、どの国でも進みぐあいはだいたい同じようでした。

今日の状況をよりよく理解してもらうために、こうした過去の日々がどんなものであったかをお話ししましょう。この分析を進めていくうちに、私たちは、プログラミングという仕事の本質に対する誤解が、いかに今となっては遠い過去の時代にまでさかのぼるのかを知ることになるでしょう。

最初の自動計算機というものはどれもみなユニークで、一台しかなく、どれもみなわくわくする実験室のような環境に置かれていました。自動計算機の構想ができてからも、当時の電子技術にとって、それを実現するのは大変な難問でした。ひとつ確かなことは、当時これらのすばらしい機械を製作しようと決心した人々がいたのであり、わたしたちは彼らの勇気を認めなくてはならないということです。それがどれほどすばらしい機械かというと、そもそもこれら初期の機械が、いったいなぜ動いたのか — 少なくとも時々は — 動いていたのか、いまから考えるとまったくもって不思議なほどです。とにかく大変なのは、この機械を正しく動かすことでした。こうした自動計算機の物体としての存在感は、この分野で古くからあった学術団体の名前にも影響を与えています。「計算機械協会 (Association for Computing Machinery)」とか「英国計算機学会 (British Computer Society)」とかいった名前は、みな明確にこの物理的な機械のことをさしているのです。

では気の毒なプログラマはどうだったでしょうか? 正直なところ、プログラマ達はろくな扱いをうけていませんでいた。これら初期の機械というものはあまりにもかさばる代物だったので、これを移動させたりすることはできなかったし、加えてあまりに綿密な保守作業を必要としていたので、機械が開発されたのと同じ場所で人々がそれを使う、という状況が普通だったのです。また、わりと見えにくいプログラマの仕事というものは、まったくもって魅惑的ではありませんでした。お客さんたちが来たときには機械を見せたほうが、数枚のコーディングよりも何倍も効果があったでしょう。しかしもっとも重要なこととして、当時のプログラマというものは自分自身の仕事についてとても控え目な見方をしていました。彼の成果のすべてはこの素晴しい機械が存在しているおかげで達成されたのです。そしてこのマシンは世界に一台しかないのですから、彼はこのプログラムがこの場所だけでしか通用しないことをよく知っていました。そしてまた、この機械が限られた寿命しかもたないことは明白でしたから、彼は自分の仕事がほとんど後世に残らないものだということも知っていたのです。そして最後にもうひとつ、プログラマの態度に深く影響していた状況がありました。一方では、これらのマシンはふつうあまりにも遅く、あまりにもメモリが少なく、つまりプログラマはつねに困窮した状態だったのですが、他方でプログラマはおよそ変てこな命令コードを使って、このもっとも予想のつかない人造物を飼っていたのです。この時代、多くの賢いプログラマたちはこうした仕事に深い知的満足をおぼえていました。つまり、不可能な仕様を今あるものの中につめこむ、という離れ業をやってのけることに対して、です。

当時から、プログラミングに関してはふたつの意見がありました。後でまた言及しますが、とりあえずそれをここでお話しします。ひとつは、有能なプログラマというものはパズル的な頭脳をもつべきであり、巧妙なトリックに長けているべきだというものでした。もうひとつの意見は、プログラミングというのはただ一方から他方に効率よく計算過程を移しかえるだけのものにすぎないというものでした。

後者の意見は、当時のよくある状況を反映したものでした。使える装置があまりにも貧弱なものであったため、この時代にはよく次のような安直な意見が言われていました。つまり、もっとマシンがパワフルになれば、プログラミングなどは問題ではなくなるというのです。なぜならこのような無理なつめこみ作業はもうなくなるのであり、プログラミングとは結局のところそれだけなのだから。違うでしょうか? しかし次の数十年間にはまったく別のことが起こりました。以前よりもひとまわりどころか、ふたまわり、三まわりもパワフルなマシンが利用できるようになったのです。しかし私たちがすべてのプログラミングから解放された至福の状態になったかというと、そうではなく、かわりにこのソフトウェア危機とやらにどっぷり首までつかっているのです! これはいったいどうしたわけでしょう?

小さな要因はあります: いくつかの点では、現代のマシンは基本的に古い機械よりも扱いにくいといえるでしょう。ひとつめとして、 I/O による割り込みがあります。これは予想できず、しかも再現できないタイミングで起こるものです。完全に決定論的な機械であるかのようにふるまっていた往年の逐次型マシンと比べると、これは劇的な変化といえるでしょう。多くのプログラマの白髪は、この機能がひきおこした論理的な問題について軽々しく語るべきでないということを物語っています。ふたつめは、複数の階層からなる記憶領域をもったマシンの登場です。これによって、それらをどのように管理すべきかという問題が生まれました。この主題に関しては多くの文献が出ているにもかかわらず、依然としてつかみどころのない話題です。実際のマシンにもたらされた構造的な変化による問題を差し引いたとしても、です。

しかし、わたしは以上のことをささいな要因と申しました。大きな要因は…これらのマシンは、以前よりも何倍もパワフルになっていたということです! とても大ざっぱに言ってしまうと、もしコンピュータというものが存在しなかったら、プログラミングはまったく問題とはなりません。何台かの非力なコンピュータが存在する状況では、プログラミングは軽めの問題になります。そして今のように、巨大なコンピュータがある場合は、プログラミングの問題もまた同じくらい巨大なものになるのです。この意味では、電子業界というものは問題をまったく解決していません、むしろ問題を作っているだけです。自分たちの製品を使って問題を作りだしているのです。別の言い方をしましょう: 使用可能なマシンの能力が数千倍という規模で増えるにしたがって、これらのマシンの能力を引き出したいという社会的な野心も増大します。そして、この手段と目的のはざまで爆発している業界で職を見つけるのは、気の毒なプログラマその人なのです。増大するハードウェアの能力と、それにあいまってさらに飛躍する信頼性とがあれば、プログラマが数年前は夢にも見なかったようなソリューションが実現可能になります。そして数年ののち、彼はそれを夢に見なければならなかっただけでなく、さらに悪いことに、いまや彼はそれを現実にしなければならないのです! 今日、わたしたちがソフトウェア危機のただ中にいるのは驚異でしょうか? いえ、まったく違います。すでにご存じの方もいるでしょうが、これははるか以前から的確に予言されてきたのです。しかしもちろん、傍流の予言者たちにとっての問題は、彼らが正しかったということを知るのにたった 5年しかかからなかったということです。

そして、60年代中期に、おそろしいことが起きてしまったのです。いわゆる第3世代コンピュータと呼ばれるものの登場です。公式な文献によれば、これらの設計上の目標はおもに価格/性能比であったとされています。もし“性能”というものをそのマシンの各構成部分の駆動サイクルだと定義すれば、おそらくその目標性能の大部分は、必要かどうかも疑わしい内部処理によって達成される設計になってしまうでしょう。また、“価格”というものをハードウェアの値段だと定義すれば、おそらくそれは非常にプログラムしにくい設計になってしまうに違いありません。たとえば、その命令コードはプログラマまたはシステムのどちらかに対して、早いうちからがんじがらめの決定を強制するものになるかもしれず、それが生みだす対立はとうてい解消できなくなってしまうかもしれません^(*2)。そして、これらの不愉快な可能性は、おおむね現実のものとなってしまったようでした。

(*2: この部分の訳は自信がない。 "the order code might be such as to enforce, either upon the progrmmer or upon the system, early binding decisions presenting conflicts that really cannot be resolved.")

これらのマシンが公開され、その性能仕様が明るみに出ると、わたしたちのかなり多くが悲惨な気分になりました。すくなくとも私はそうでした。いまやこれらのマシンがコンピュータ業界全体をあふれさせてしまうのは目に見えており、したがってその設計はできるかぎり健全であることがいっそう重要となったのでした。しかし、これほど重大な欠陥を内在した設計では、私にとっては、これまで少なくとも 10年にわたって計算機科学の進歩はただの一撃で使いものにならなくなってしまうように感じたのです。これは私の職業人生の中でもっとも暗い一週間だったと言わざるをえません。おそらく、いまもっとも哀しいことは、これまで何年にもわたる重苦しい体験のあとでさえ、マシンがこのようになるのは、何らかの自然の法則により運命づけられているのではないか、と多くの人々が素直に信じこんでいることです。かれらはこれらのマシンがどれほど売れているかを見るや、自分たちの疑念を飲み込んでしまいました。そして、この観察からつまり結局のところ設計はそんなに悪くないんではないかという間違った安心感を得てしまったのです。しかし注意ぶかく見れば、この種の思考は、こんなに多くの人々が吸っているのだからタバコを吸うことは健康上問題がないに違いない、というのと同程度の説得力しかありません。

この点で、私はこんにちの学術論文誌が、新しく発表されたコンピュータを、学術論文と同じような扱いでレビューする習慣がないのを残念に思っています。マシンをレビューすることは、少なくとも同じくらいに重要なはずなのです。そしてここに告白しておかねばなりませんが、60年代初頭には私もそのようなレビューを CACM に送るつもりで書いたことがありました。しかし、この原稿のコメントを求めた数人の同僚らはみんな送るように言ってくれたにもかかわらず、私はそれをやらなかったのです。私にとって、あるいは審査委員にとって障壁が大きすぎるように思えたからでした。この自粛は私の臆病さのためであり、私には自責の念が日増しに大きくなっています。私が予期していた障壁とは、一般的に受け入れられた基準がないために起こる帰結でした。そして私は自分の選んだ基準が妥当であることを確信していましたが、それでも私は自分のレビューが「個人的な好み」ということにされ棄却あるいは却下されてしまうことを恐れたのです。私はいまでもこのようなレビューは非常に有益であると思っていますし、こうしたものが現れてくるのを願ってやみません。もしそうしたものが出てくれば、それはコンピュータ業界のたしかな成熟さを示すものとなるだろうと思います。

私がこのようにハードウェアというものについて注意している理由は、次のような考えからです。どんな計算ツールにおいても一番重要なことは、それを使おうとする者の思考習慣に対してツールが与える影響です。そして私はその影響というものは、一般に考えられているよりもずっと強力だと信じているからです。では次にソフトウェアというものについて考えてみましょう。

ここではあまりにも事情が多様なので、いくつかの点にしぼってお話しすることにします。私の選択が恣意的なものであることは重々承知していますので、私がここで触れない多くの努力に感謝していることに対して、どうか早急な結論を出さないようお願いします。

はじめ、イングランドのケンブリッジに EDSAC がありました。そして私はこのことに非常に感心するのですが、このマシンの設計と、これがどう使われるべきかということに対して “サブルーチン”という考えが最初から中心的な役割を占めていたということです。あれから 25年近くたったいま、計算機科学は劇的に変わりましたが、ソフトウェアの基本的な考えはまだ変わっていません。閉じたサブルーチンという考え方はいまだプログラミングの中心的なコンセプトとなっています。私たちはこの閉じたサブルーチンという考え方を、ソフトウェア上のもっとも偉大な発明のひとつとして認める必要があると思います。これは三世代にもわたるコンピュータの中で生きのび、さらにもう数世代先まで生きるでしょう。なぜならこの概念は私たちの抽象化の基本的パターンのひとつを実現する仕組みだからです。残念なことに、この重要性は第3世代コンピュータの設計の中では軽んじられていました。その算術ユニットの中にある、おびただしい数の名前つきレジスタは、サブルーチンという機構にとって重荷となってしました。しかしそれでもサブルーチンの概念は死ななかったのであり、われわれとしてはこの突然変異が遺伝とならないことを祈るばかりであります。

ソフトウェア業界における 2つめの大きな発展は、FORTRAN の誕生です。当時、このもくろみは向こう見ずなものととらえられており、これに関わった人々は多大な尊敬を受けるべきです。これが広範に使われて 10年かそこらたったあとで初めて明らかになった欠点について、彼らを批判するのはまったくフェアではありません。 10年先を見通せる人々の集団など、きわめて稀なのですから! 今からふりかえって、わたしたちは FORTRAN を成功したコーディング技術とみなさなければなりませんが、概念化のためのツールがほとんどなく、そういったツールが今やあまりにも深刻に不足しているため、 FORTRAN は時代遅れのものとみなす時が来てしまいました。 FORTRAN が存在していたということを忘れるのは早ければ早いほどよいのです、なぜなら思考の道具としては、これはもはや適切ではないからです。これは私たちの脳を浪費し、使うにはあまりにもリスキーで高額なしろものとなってしまいました。FORTRAN の悲劇は広く知られるところとなっています。何千人というプログラマが過去の誤ちに精神的な鎖でつながれているのです。私は同僚のプログラマたちが互換性の呪いから彼ら自身を解き放つ方法を見つけられるようにと、毎日のように祈っています。

触れないわけにはゆかない 3つめのプロジェクトは、LISP です。まったく異なった魅惑的な企てです。わずかな数の原則だけを基本にしながら、これは非常に安定したものになっています。それはさておいても、 LISP はある意味でもっとも洗練されたコンピュータの応用に使われています。LISP は冗談まじりに「コンピュータを誤用するための、もっとも知的な方法」と言われることがありますが、私はこれはすばらしい褒め言葉だと思います。なぜならこれはあらゆる種類の自由を可能にしているからです。 LISP は私たち人類のうちもっとも才能ある人々が、それまでは不可能だったような方法で思考することを支援してきました。

4つめの言及すべきプロジェクトは ALGOL 60 です。今日にいたるまで、FORTRAN プログラマはいまだに自分たちのプログラミング言語というものを、特定の実装に結びつけて考えるくせがあります — こうして、いたるところ8進ダンプや16進ダンプばっかりとなるわけです — LISP の定義が、まだ言語が意味するところとその実装の興味ぶかいミックスであるのに対して、かの有名な「アルゴリズム記述言語 ALGOL 60 報告書^(*3)」は、抽象化をさらに一段とおしすすめた、プログラミング言語というものを実装から独立した方法で定義するという真摯なこころみから得られた成果といえましょう。この点に関しては、著者の成功があまりに偉大であったために、そもそもこれが本当に実装可能なのかという真剣な疑いが生まれたほどです! この報告書は、いまではバッカス・ナウア記法として知られる、形式的手法 BNF のもつ力と、緻密につくられた英文のもつ力を華麗に示しました。少なくともピーター・ナウアーほど知的な人が使う限りではそうでした。私は、これほどの分量でコンピューティング業界にこれほどの深い影響を与えた文書は他にほとんどないといっていいと思います。後年、 ALGOL や ALGOLライクな名前が自由に使えるトレードマークとして、いくつもの、時にはまったく関連のない若いプロジェクトがその栄光の一部にあやかっていたという事実は、これがもつ名誉に対するある種ショッキングな賛辞となっています。ものごとを定義する装置としての BNF の強みは、私がこの言語の弱みとみなすものにつながっています。つまり、細かすぎるわりには体系的とはいえない文法が、いまやたかだか数ページの中につめこまれてしまうのです。 BNF ほどのパワフルな装置をもってすれば、アルゴリズム記述言語 ALGOL 60 報告書はもっと短くするべきでした。それはそうと、私は ALGOL 60 の引数メカニズムには非常な疑いを抱いています。これはプログラマにあまりにも多大な組み合わせの自由を与えてしまうため、これを自信をもって使えるようになるにはかなりの鍛錬が必要になります。また、この実装にはコストがかかるため使うのは危険だと思っています。

(*3: "Report on the Algorithmic Language ALGOL 60")

最後に、楽しい話題ではありませんが、PL/1 について触れないわけにはゆきません。PL/1 は、その定義文書が戦慄を覚えさせるほどのサイズと複雑さをもったプログラミング言語です。 PL/1 を使うのは、コックピットに 7000個ものボタンやらスイッチやらハンドルがある飛行機を操縦するようなものです。私は、肥大するプログラムを私たちの理解力でいったいどのようにしてとらえうるのか、まったく理解できません。とりわけそのプログラミング言語の奇怪さが — いいですか、これは私たちの基礎的な道具なんですよ! — 最初から私たちの知的理解を超越している場合にはなおさらです。 PL/1 の影響を言おうとするとき、私の頭にうかぶもっとも近い比喩がドラッグです。私は覚えているのですが、高水準プログラミング言語に関するあるシンポジウムで、PL/1 を擁護する講演が、この言語の熱心なユーザであると自称するひとりの人物によってなされました。しかし1時間におよぶ PL/1 の賛辞の中で、彼はなんと約50個もの、新しい“機能”を要求したのです。彼は、自分のかかえる問題のおもな原因が、すでにそれらの“機能”が多すぎるために生じているかもしれない、というありがちな可能性についてはほとんど意識していないようでした。この講演者は中毒患者がしめすあらゆる憂鬱な兆候を示していました。すでに彼の精神状態はただひとつの要求が「もっと、もっと、もっと…」というところまで落ち込んでいたのです。FORTRAN が小児期の病気だとすれば、フルの PL/1 は悪性腫瘍にも似た成長の速さを示しており、このままいけば死に至る病にもなりかねない危険をもっていたのです。

過去のことについてはこれくらいにしておきましょう。しかし、間違いというものはそこから学べなければ意味がありません。実際のところ、私たちはあまりに多くのことを学んでしまったため、プログラミングは、今から数年のうちにはこれまでとはまったく違った活動になる可能性があります。それはあまりに違っているため、私たちはショックに対する準備をしておいたほうがいいでしょう。一見したところ、近い将来のプログラミングに関する見通しはまったく素晴しいものとして映るかもしれません。では、その予想が本当に現実になりうるかもしれないという考察についてお話ししましょう。

その予想とはこうです。70年代が終わるよりもかなり前に、いま私たちのプログラミング能力をフル活用しているようなシステムが、いまの数パーセントの人月で設計および実装できるようになっているでしょう。しかも、これらのシステムは事実上バグがないのです。これら2つの改善は同時に起こることになるでしょう。後者の点に関して、他の多くの製品では高品質が高価格につながるという暗黙の前提がありますが、ソフトウェアはそうではないようです。本当に信頼性の高いソフトウェアが欲しい人々は、はじめから多くのバグを避けるような手段が必要であることを理解するかもしれません。その結果として、プログラミングの過程はより安価になります。もし効率のよいプログラマが欲しければ、そのプログラマはデバッグに時間を費やすべきではなく、はじめからバグを入れるべきではありません。つまり、これら2つの目標は同じ変化を表しているのです。

このような短期間の劇的な変化は革命と呼ばれることになるでしょう。そして、最近の出来事をそのまま延長することで未来を予測している人々 — それは明文化されていない、社会的・文化的な慣例という法則に頼ったものですが — にとって、この劇的な変化が起こるであろう見込みはほとんど無視できるほど小さいに違いありません。しかし私たちはみな知っているのです、ときに革命というものは本当に起こるのだということを! ではその見込みはいくらくらいなのでしょうか?

そのためには、3つのおもな条件が満たされている必要があります。まず、世界がおおむね変化の必要性を認識していること、つぎに、それに対する経済的な需要が十分に強いこと、そして最後に、その変化が技術的に可能であることです。ではこれら 3つの条件について、いま挙げた順序で見ていくことにしましょう。

ソフトウェアにより高い信頼性が求められることについては、もはや異論はあるまいと思われます。ほんの数年前まで状況は違っていました。ソフトウェア危機について語ることは、罰当たりなことだと思われていたのです。転換は、1968年ガーミッシュで行われたソフトウェア工学会議^(*4)でした。この会議で、はじめてソフトウェア危機をオープンに認めようという議論がまき起こったのです。そしてこれまでに、大規模かつ複雑なシステムを設計することは、どれも大変な仕事であるという認識されるようになっています。そのような仕事にかかわっている人々を見れば、彼らがいかに信頼性の問題について頭を悩ませているか見てとることができるでしょう。そしてそれは当然なのです。つまり、先ほどの第一の条件は満たされているといってよいでしょう。

(*4: "Conference on Software Engineering")

では次に、経済的な需要についてです。こんにち、 60年代のプログラマの給料は高すぎた、だから今後プログラマの給料は下がるであろう、といった意見をよく見かけます。このような意見は、よく景気に対する不安とともに語られますが、この意見はなにかまったく異なる、まったく健全な兆候であるかもしれません。つまり、過去10年のプログラマは本来すべきよりもたいした仕事をしてこなかったということです。社会はプログラマたちの能力と、その成果について不満をもっているのです。しかしこれよりずっと大きなウェイトを占める要素があります。こんにちの状況では、ある特定のシステムに対して、ソフトウェア開発に支払われる値段が、ハードウェアに必要とされる値段とほぼ同規模かかるということは、普通にあることです。そして社会はそれをだいたい受容していました。しかしハードウェアメーカーの言うところによれば、次の10年でハードウェアの値段は10分の1倍にまでも下がるというのです。もしソフトウェア開発が、いまと同じように不器用かつ高価なままだとしたら、物事のバランスは完全に崩れてしまいます。おそらく社会はこれをよしとしないでしょう。ですから、私たちはいまより何倍も効果的にプログラミングをする方法を知る必要があるのです。別の言い方をしましょう。マシンがいちばん金のかかる物品であるあいだは、プログラマたちはその不器用な方法でもなんとかやりおおせていました。しかしこの傘はもはや閉じられようとしており、端的にいえば、先ほどの第二の条件も満たされつつあるのです。

そして 3つめの条件です。それは技術的に可能なのでしょうか? 私はそれは可能かもしれないと考えており、以下にこれを支持する 6つの議論をお話ししようと思います。

プログラム構造の研究が明らかにしたところでは、プログラムというものは — たとえ同じタスク向けの、同じ数学的内容をもつ代替品であっても — その知的な扱いやすさにかけては途方もなく異なっているということでした。いくつもの規則が発見され、これらに違反すると、そのプログラムの知的な扱いやすさを深刻なまでに損なうか、あるいは完全に破壊してしまうことがわかりました。これらの法則には 2種類あります。最初のものは、機械的に制限できるもの、すなわち適切なプログラミング言語を選ぶことによって可能になるものです。例としてgoto文の排除や、複数の出力パラメータをもつ手続きの排除があげられます。しかしふたつめの規則は — 私の能力が足りないだけかもしれませんが — 少なくとも私にとっては、機械的な制限をかけることが不可能なように見えるものです。なぜならそれはまだ存在するかどうかわからない自動定理証明器を必要とするからです。したがって、当面あるいは永久に、これらの規則はプログラマにとって訓練が必要なものとして残るでしょう。これらの規則のうちいくつかは私の頭の中では非常にはっきりしており、人に教えることができ、与えられたプログラムがそれに違反しているかどうかに議論を余地を与えないものです。たとえば、いかなるループも、終了することが証明され、その繰り返し処理のあいだ破られることのないような不変条件が与えられない限りは書かれるべきでない、といったことです。

ここで私は、私たちが知的に扱いうるプログラムの設計と実装のみにみずからの仕事を制限することを提案します。もしこの制限は厳しすぎてとても守れないという人がいるかもしれませんが、その心配はないといっておきましょう。知的に扱いうるプログラムというものは、それでもアルゴリズム的に扱える、非常に多くの現実的な問題を含むほどに奥が深いのです。忘れないようにしたいのは、私たちの仕事はプログラムを作ることではないということです。私たちの仕事は、望みどおりのふるまいを示す計算処理の一群を設計することなのです。自分たちを知的に扱いうるプログラムのみに制限するという提案は、私の6つの議論のうち最初の2つの基礎になっています。

第一の議論は、プログラマが知的に扱いうるプログラムだけを扱うようになれば、プログラマのとりうるさまざまの選択肢はずっと御しやすいものになるということです。

第二の議論は、私たちがみずからを知的に扱いうるプログラムのサブセットに制限することで、私たちは考えうる解決策の空間を一斉に、劇的に減らすことができます。そしてこの議論は、第一の議論とは異なるものです。

第三の議論は、プログラムの正当性に関する問題に対する建設的なアプローチにもとづくものです。こんにちよく使われているテクニックは、まずプログラムをつくり、それをテストするというものです。しかし、プログラムのテストはバグの存在を示すことにかけてはとても効率的な方法ですが、バグの不在を示すことにかけては絶望的なほどに不適切です。プログラムの信頼性を顕著に向上させる唯一の方法は、その正当性に対して説得力のある証明を与えることです。しかし、まずプログラムをつくり、その正しさを証明するといったことはすべきではありません。そんなことをしたら、証明の必要性はあわれなプログラマの重荷を増すだけとなってしまうでしょう。その反対です: プログラマは正当性の証明とそのプログラムが一緒に成長するようにさせなければならないのです。第三の議論は、基本的に次のような観察にもとづいています。まず人は最初に説得力のある証明とはどんな構造をしているものかを自問し、つぎにその構造を発見したら、その証明の要求を満たすようなプログラムを構築します。そうすれば、これら正当性に関する配慮は非常に有益な発見のためのガイドとなるでしょう。このアプローチは、定義により、私たちがみずからを知的に扱いうるプログラムに限定したときのみ適用できますが、それは満足いく構造を発見するための効果的な手段をもたらしてくれるでしょう。

第四の議論は、プログラムの設計に必要な知的労力は、その長さに依存するということに関してです。なんらかの自然の法則とでもいうものがあって、プログラムの設計に必要な知的労力は、その長さの二乗に比例するのだと言われていますが、ありがたいことに今までこの法則を証明した人は誰もいません。なぜならこれは必ずしも真ではないからなのです。私たちはみな、「抽象化」と呼ばれる、まったく有限回の推論をつかって、ほとんど無限個の場合分けを考えることのできる思考ツールを知っています。そのため、ある人がもつ抽象化の力をフルに使いこなすことは、有能なプログラマたるためのもっとも重要な活動であると考えられています。この点に関連して、次のことは指摘する価値があるかもしれません。抽象化とは物事を曖昧にすることではなく、むしろ人が絶対的な正確さを発揮できる新しい意味の段階をつくりだすことなのです。もちろん私もまた、人間の抽象化メカニズムが十分効果的に発揮できない根本的な要因がありうるものかを探しだそうとしてみました。しかし、どれほど努力してみてもそのような要因は見つかりませんでした。その結果、私は次のような仮定 — これまでのところ、まだ経験によって否定されてはいません — 私たちの抽象化の能力をふさわしい部分で使えば、プログラムの作成あるいは理解に必要な知的労力は、プログラムの長さの比例よりも必ずしも多くなるわけではないという仮定をもつに至ったのです。ですが、これらの調査の副産物はより多くの実用的な価値を持っているのかもしれません。そしてこれが私の第四の議論です。その副産物とは、プログラム作成全体をつうじて極めて重要な役割をはたす多数の抽象化パターンの発見です。いまでは、これらの抽象化のパターンのひとつひとつに対して、講義ができるくらいのことが知られています。これら抽象化のパターンを意識的に理解し、またそれになじんでおくことがどういう意味をもつか、私にはようやくそれがわかってきたところです。もしこれらが 15年前に知られていれば、たとえば BNF から構文主導コンパイラまでの道のりなどは、数年かかったところが数分になってしまうでしょう。したがって、私は近年における重要な抽象化パターンの普及を第四の議論として挙げたいと思います。

さて、第五の議論です。この議論は、私たちの使おうとしている道具が、私たち自身の思考習慣に影響しているということについてです。これはおそらくルネサンス期にまでさかのぼるでしょうが、私の見るところ、人間はこの影響を無視し、人間の精神というものは、人工物よりも高度で、かつ自律した存在であると考える伝統があるようです。しかし私が自分自身および仲間の人間の思考方法を分析するようになってから、私は自分の好き嫌いにかかわらず、まったく違う結論に落ちついてしまいました。それは、私たちが使おうとしているツールや言語や、私たちが自分の思考を表現したり記録したりする記法というものは、私たちが何を考え、表現するかということを決定づけてしまう大きな要因だったのです! プログラミング言語が私たちの思考習慣に及ぼしている影響を分析し、これまでのところ私たちにとってもっとも不足している資源は頭脳だという認識をあわせれば、これは様々なプログラミング言語を比較検討するときの尺度として使えることでしょう。有能なプログラマは自分の脳味噌のサイズがいかに制限されたものであるかをよく心得ています。したがって、彼はプログラミングの仕事にまったく謙遜の気持ちをもってあたっており、中でもこざかしいトリックなどは忌避するのです。よく知られている対話型プログラミング言語の場合、プログラミング・コミュニティがその端末を手にするやいなや、私はある特定の現象が起こるということをいくつもの筋から聞いております。それにはもはや名前がついているほどで、「ワンライナー」と呼ばれています。これは2つの異なる形をとります。あるプログラマが1行のプログラムを別のプログラマのデスクの上において、それが何をするか説明してから — まるでそれが概念的に有用でもあるかのように — 「これをもっと少ない文字数で書けるかい?」と尋くか、あるいはただ「このコードが何をするか当ててごらん!」と尋くかのどちらかです。私は、以上の観察から、道具としての言語というものは、巧妙なトリックへのあけすけな誘惑であると結論できます。そして、自分がいかに賢いかを見せつけるのが大好きな人々に対しては、これこそがまさにその魅力を説明しているかもしれないのです。申しわけありませんが、これがプログラミング言語に関して言えるもっとも罪なことのひとつであると言わざるをえません。最近の出来事からもうひとつ私たちが学ぶべきことは、「リッチな」あるいは「よりパワフルな」プログラミング言語の開発は間違っていたということです、それはこれらの言語のバロック的なぶかっこうさと、それらの奇怪さがないまぜになったものは、機械的にも心理的にもまったく私たちの手に負えないものだからです。私は体系立っていて、ひかえめなプログラミング言語にこそ未来があると思います。ここでいう「ひかえめ」とは、たとえば ALGOL 60 の for節だけでなく、 FORTRAN の DOループまでも、あまりにバロック的であるとして却下されてしまうようなものです。私はかなりの経験をつんだボランティアに対して、すこしばかりプログラミングの実験をやってみましたが、意図せず、予期していなかったことが起こったのです。ボランティアのうち、もっとも明白かつエレガントな解法を見つけた人は誰もいませんでした。よく調べてみると、これらには同一の源があることがわかりました。彼らにとっての繰り返しの概念は、制御変数をひとつ増やすというアイデアとあまりにきつく結びついていたために、彼らは明白な答えから心理的にブロックされてしまっていたのです。彼らの解法はより効率が悪く、不必要にわかりづらく、またこれを見つけるまでにえらく時間がかかりました。これは私にとって、はっとする経験でしたが、同時にショックでもありました。最後に、明日のプログラミング言語は、私たちがこんにち使っているものとはある点で非常に異なっていると期待できます。ここでは私たちの設計しようとするものの概念的な複雑さをやりすごすために書き出された、あらゆる抽象化の構造について熟慮することが、今までよりもずっと求められるであろう、ということです。私たちが将来使うツールのすばらしさについては、これくらいにしておきましょう。以上が第五の議論でした。

ここでちょっとお断りをしておきたいと思います。プログラミングの難しさというものを、現在私たちが使っているツールの不備のせいであると考え、より優れたツールがひとたび開発されれば、プログラミングはもはや問題ではないと考える人々がいますが、プログラミングは依然として非常に難しい問題でありつづけるでしょう。なぜなら、私たちがこうした偶発的な不便さから解き放たれれば、私たちはその後よりいっそう現在のプログラミング能力を超えた問題に向かうだろうからです。

私の第六の議論には、異論があるかもしれません。なぜならこれを支持する実験的な証拠、私にこの正当性を疑わせることのないような事実を集めるのは、そう簡単ではないからです。これまで私は“階層化”という言葉を使わずにきましたが、この概念は、適切に分割された解をあらわすすべてのシステムにおいて、鍵となっていると言うことができます。それどころかもう一歩進んで、私はこの概念を信条としているとさえ言えるかもしれません。すなわち、私たちが本当に満足いくやり方で解けるような問題というのは、最終的にこの適切に分割された解を許すようなものだけである、ということです。一見するとこのような人間知性の限界は、かなり憂鬱なものとして映るかもしれませんが、私はぜんぜんそう思ってはいません。むしろその逆です! 自分たちの弱点とうまく生きるコツは、それについて知ることなのです。私たちがいずれ十分に謙虚になって、細分化された答えのみを探すようになれば — なぜならそれ以外のやり方はみな私たちの頭からこぼれ落ちてしまうので — 私たちはシステムを理にかなった方法で分割する能力を削ぐ、あのインターフェイスをひとつのこらず避けるために、ありったけの力をさくようになるでしょう。そしてこのことで、最初は不可能に見えた問題でもいずれ分割できてしまうような発見につながるだろう、という期待を持たずにはいられません。これまでコンパイラの「コード生成」と呼ばれる段階で発生するトラブルのうち、どれほど多くが命令コードの奇妙な癖に端を発しているかをご存じの方なら、私が考えているような例をわかっていただけるのではないでしょうか。うまく分割された解法をより広く応用すること、これが私の 6番目の議論であり、これをもって、以後10年のあいだに革命が起こりうるかもしれないという技術的な論拠とします。

原則として、私の考えをどれほど真に受けていただくかは、みなさんにおまかせします、自分の意見を他人に押しつけることはできないということは知っていますから。本物の革命とは、いつも熾烈な妨害にあうものであり、保守的な勢力がこのような進歩をどこで妨害してくるかを考えてみますと、それらは基本的に大企業ではないと思います。コンピュータ業界ですらないでしょう。私はむしろ、現代の養成をおこなっている教育機関であると思っています。これら保守的なコンピュータ・ユーザは、自分たちの古いプログラムがあまりにも重要であると考えていて、その結果、書き直したり改良したりということをしたがりません。これに関連することですが、多くの大学キャンパスで計算機センターを作ろうというときに、高度な応用をしようというごく少数の既存勢力の要求だけが聞き入れられて、それ以外の、自分でプログラムを書いている幾多の「ちっぽけなユーザ」がこの決定でどれほど苦しむかちっとも考慮されていない、という光景をあまりに多く見るにつけ、じつに悲しくなります。たとえば、高エネルギー物理学はいつもそれが持っている実験装置の値段でもって、科学全体をゆすりにかけているようです。もちろん、いちばん簡単なのはこれが技術的に可能だということを頭から否定すればいいだけですが、そのためには非常に強力な論拠が必要であろうと思います。今日の平均的プログラマの知的能力の上限を考えてみればそんな革命は起こりっこないといってみても、悲しいかな、それは慰めにはなりません。他の人々がよりいっそう効率的にプログラミングしている中で、彼らはこの構図から徐々に押し出されてしまうわけですから。

また、ここには政治的な障害もあるでしょう。たとえ私たちが明日のプロフェッショナルなプログラマを養成する方法を知っていたとして、私たちの住む社会がそれを許してくれるかどうか定かではありません。知識をばらまくのではなく、方法論を教えるということにはまず、すでにできる人間の能力を高め、つまりは知性の差を広げるという効果があります。教育というものが、均一化された文化を確立するための道具として使われている社会では、出る杭はつねに打たれてしまい、有能なプログラマになるための教育は潜在的に容認されないものになりかねません。

結論を言わせてください。自動計算機は、四半世紀ほどのあいだ私たちとともにありました。これらはその道具としての能力によって、私たちの社会に多大な影響をおよぼしてきましたが、この機能が私たちの文化に与えた影響というものは、もっとずっと深遠な、人類の歴史上、これまで前例のない知的挑戦を与えたという事実に比べれば、ほんのさざ波にすぎません。階層的なシステムというものは、あるレベルで見ればそれは不可分の要素に見えますが、その下のレベルから見ればいくつもの細かな要素から構成された複雑なものと考えることができます。したがって、各レベルで自然に思える時間や空間といった性質は、階層をあるレベルから下のレベルへと降りるごとに、数倍のスケールで小さくなっていきます。私たちは壁というものをブロックの集まりとして考え、ブロックを結晶の集まりとして考え、結晶を分子の集まりとして考える、といったことをしています。その結果、階層的なシステムにおいて、意味のある階層として区別できるレベルは、およそその最大部分と最小部分の比率の対数になります。計算機プログラミングにおいては、私たちの基礎的な構成要素がもつ時間は1マイクロ秒以下なのに対し、プログラムは何時間も走りつづけることがあります。私は 10¹⁰かそれ以上の比率をカバーする技術をほかに知りません。コンピュータは、そのあまりにもすばらしい速度という特性によって、私たちが非常に階層化された人工物をつくることができ、またそれが必要になるような環境を最初に提供してくれるものとなるでしょう。この挑戦、すなわちプログラミング・タスクとの対決というものはこの上なくユニークであり、この新しい経験は私たちに多くのものを教えてくれることでしょう。そしてこれは設計プロセスや、物事の創造に対する私たちの理解をより深め、また私たちが自分の思考をどのようにまとめるかについて、よりよい方針を提供するものでなければなりません。もしそうでないとしたら、私が思うに、人類はコンピュータを使うにまったく値しない存在になってしまいます!

すでに私たちは多くの教訓を学んできましたが、私がここで強調したいのは次のようなことです。私たちはプログラミングで、いまよりもずっとよい仕事をしなければなりません。それは私たちが、この仕事のとてつもない難しさを真摯に認め、質素かつエレガントなプログラミング言語を駆使し、そして私たち人間の知能の本質的な限界に気づき、自分の任務に対して “いとも謙虚なるプログラマ”の一員としてあたることによってのみ、可能になることなのです。