特別インタビュー Niklaus Wirth（月刊ASCII 1985年10月号5）

ニクラウス・ヴィルト先生の特別インタビューがあった。Pascalのヴィルト先生だ。スクラップする。

――Pascalは,あなた自身の個人的な方法論を反映していますか?
Wirth　もちろん、そればかりか,わたしの特殊な仕事の分野も反映していますよ. 最も普及しているプログラミング言語はみんなそれぞれ,得意なアプリケーションの分野を持っていると思います。
　例えば,BASICはかなり前にダートマス・カレッジで開発されたのですが,そのときは主にプログラミングの初歩を教えるという目的を持っていたのです. この言語はある水準まではかなりよくこの仕事をこなす言語だとわたしは思いますが,きわめて根本的な,ある概念が欠けているのです.
　C.A.R.Hoareは,BASICによるプログラミングを,2本の指でピアノを弾くようなものだといっています.ごく初歩的で簡単なメロディーなら,非常に早く弾けるようになるけれども,それ以上進もうとすると難しくなるのです.現在のところ,プログラミングを習おうという人々の多くは,いくつかの簡単なメロディーを弾くところから先にいこうとはしていないのです.また,多くの分野ではみんな簡単な問題を一度解いただけで,すっかり満足してしまって,問題を忘れてしまうのです.
　ところが,わたしがめざしているのは,コンパイラやオペレーティング・システム,テキスト・エディタなどのように,多くの人が長年にわたって毎日使えるようなシステムなのです.これらは複雑なシステムです。複雑なシステムを、構造的なやり方で組み立てるために,よいツールを持つのは非常に重要なことなのです。
――最近はみんなが「構造化」ということをいいますが,本当にこれは,プログラミングのアプローチで最もよい方法なのですか?
Wirth　プログラミングの様式に,世界中で通用する法則のようなものを持ち込もうとするのは、不遜のそしりを免れないでしょう.プログラミングは,なんらかのドグマに集約するには,あまりにも多様な分野です.しかし,もちろん,他のものより上に置くべきであることがはっきりしている原則というのはあります.
　基本的に,プログラムを構造化しようという考え方は、プログラムのテキストの構造によって,アルゴリズムの構造をそっくり写しとろうということなのです.われわれはアルゴリズムを理解するために,それを構造化する必要があります.意味を構造のある部分にくっつけた形で理解しようとするからです。ある構造は,さらに個々の部分も含んでいます.もし,10ページにもわたるアルゴリズムがあったら,われわれは,それを管理できる程度の小さな部分に分解する術を知らないかぎり,理解することはできないでしょう.
――プログラマーの中には,線形(linear)のアプローチの方がいいという人もいるでしょう。構造化という仕事には制限が多いですから、
　Wirthもちろん,真に表現したいことを表現するのに、できるだけ自由でいるというのはいいことです.しかし,新しいプログラムを設計・開発するとき,考えを秩序立ったものに保ってくれるような,しっかりした指針があって,それに頼れるというのもまたいいものです.つまり,そうしないとわれわれは,あまりに多くのミスを犯してしまうということなのです。
　どのアルゴリズムにも持って生まれた構造があります.ネストしたループを含んでいることもあるでしょう。コンパイラがこれをビットの列に翻訳する.マシンは元のテキストの構造には気づかない.膨大なビットの集まりを見るだけです.しかし,われわれ人間は,元のテキストの構造を知らないと,アルゴリズムを理解することができないのです.
　非常に一般的な話になりますが,ほとんどの人は、努力して作ったプログラムをマシンが解釈しただけで,何か結果が得られたと思い込んでしまいます.一度マシンがちゃんと動くと、仕事は終わったのだと思ってしまうのです.これは恐ろしく誤った態度だと思います。なぜなら,マシンは一度正確な解を出しても,入力のパラメータが変われば,次にまた正解を出すという保証がないからです.
　わたしがいいたいのは,プログラムは人間に理解されなければならないということです.プログラミングは、マシンにではなく,人間に向けられた行為であるべきなのです.最低限,書いた人間以外-に一人は,そのプログラムが何をするのか知っているべきです.すべてのプログラムは,同僚に見せて,理解してもらい,評価を受けることができるような環境で書かれるべきなのです.

BASICでも大きなプログラムは書ける。BASICインタプリタでBASICコンパイラを書き、そのインタプリタ上のBASICコンパイラでBASICでコンパイラのソースをコンパイルしてBASICコンパイラのオブジェクトを作り、機械語化したBASICコンパイラを有償で配布した人もいた。プロならそれができるのだろうが、アマチュアプログラマはBASICで大きなツールは書けない。１月前に書いたルーチンが１月ぶりに読むと訳が分からない状態になっているからだ。変数の衝突とか開発期間が長くなるとデバッグが収拾付かなくなる。

――Donald　Knuthは,「文芸的な(literate)」プログラミングといったものを,提唱していますね.これは、他人が読んでわかるようなプログラミングということなんですが．
Wirth　わたしはいつも彼の仕事に感心しています。彼はおそらくわたしほど構造化のさしせまった必要性を強調していません.しかし,Knuthは傑出した特別な人です。彼はおそらくアルゴリズムを明瞭かつ丁寧に構造化するようなことをしなくても,ちゃんと意味をたどっていけるのです.こういういい方が許されるなら,彼はわたしよりやや無頓着な方法でいける人なのです.
　つい最近,彼はWEBのプログラムでやっていることを,わたしに見せてくれました.これはプログラミングとテキストの処理を統合したものなのです.わたしは,とても面白いやり方だと思いますが,それについて何か語ることは難しい.それにかかわってきたわけではないので,それに対する感覚を発展させることができなかったのです.しかし,そのときわたしの頭に浮かんだのは,これは本の著者がやるようなプログラミングだなということです。なぜなら、彼は本の形でアルゴリズムを表現しようとしていたからです.それによって彼はアルゴリズムをあっという間に作ってしまいましたし,好きなところをあちこちぱっと参照することができるのです.
　今のところ,わたしはこのクロス・リファレンスが非常によいアイデアであると断言できるほど強い確信を持っているわけではありません.コンピュータにとってはやりやすいでしょうが,人間にはちょっとやっかいなのです.もちろん,われわれは,基本的には同じ方式を使っています。わたしは自分の本でも同じことをしているんですから、
――プログラミングを教えるときは,どういうやり方をとっていますか?
Wirth　よい例をあげて教えるというのが,わたしが知っている中では,非常に有効な唯一の方法だといっていいでしょう.いうまでもなく,これに関しては、わたしは友人のE.W.Dijkstraと意見を異にしています。彼は,具体例を完全に避けて,一般的な規則から教えるべきだといっています.しかし,わたしの経験からすれば,特に工科系の学校では,特殊例からスタートして,学生に勉強の動機づけをあたえてから,次に一般論へ進むべきなのです.Dijkstraは,数学者として教育を受けた人ですから,考え方が違うのでしょうね。

尊敬すべきビックネームが登場していた。一人目がTeXのドナルド・クヌース先生。私はTeXが使いたくて数学を勉強した。TeXで美しい式を文章の中に埋め込みたかった。私がTeXを使い始めたマシンはエプソンのPC486-GR3だった。1120×750ドットのハイレゾ画面でTeXの出力を見るのが楽しかった。
ハイレゾマシンを買った→美しい文字等を表示したい→TeXを使って表示したい→数学を勉強する
という順番が逆転しているポロロッカ現象をやっていた。

「構造化プログラミング」のエドガー・ダイクストラ先生。本は読んだが
書籍を捨てる(構造化プログラミング他)
私の能力が低く上辺しか身に付かなかった。ダイクストラ先生は一般的な規則から、ヴィルト先生は特殊例から教えるというが、私は特殊例、具体例からしかコーディングできなかった。特殊からいきなり一般を解くことができず、特殊を作りテストし、それを徐々に拡張していき、最終的に一般に持っていく。優秀な人から見ると何をまだるっこしいことをしているのかと思われるような方法しか取れなかった。

――プログラミングに関して,現在おこなわれている論争の一つは、プログラマーの創造性に関するものです.ある人たちは,プログラマーはアーティストと見なされるべきだといいますし、他の人たちはそれに反対を唱えています.
Wirth　創造性については,一つ,こういうことを頭に入れておいた方がいいでしょう.この問題は,われわれが普段考えているよりはるかに些細なものなのです.プログラマーが書くプログラムのうち99%においては、創造性はほとんどないといっていいでしょう.まず1%くらいですねたいがいのプログラムにおいては,複雑なデータ構造やアルゴリズムは非常に少ないのです.しかし,プログラマーがもし高度なアルゴリズムを必要としているなら,サブルーチンのコレクションから持ってくればいいのです.
　ほとんどの部分はフレームワーク,つまりプログラムを入れる箱の問題です.ビジネスのデータ処理のような極端な例を考えてみるとよくわかりますが,分類,探索,計算といった仕事ばかりで,もっと高度なものにはほとんどお目にかかりません。
　わたしは,構造化言語を使うことが,オリジナリティーを減少させる危険をともなうとは思いません.逆に,集められたアルゴリズムをよりよいフレームワークにあてはめるうえで,構造化言語はよい手助けになるという利点を持っているのです.例えばストリング・サーチのような,非常に洗練されたアルゴリズムを開発したとします.あるいは,マトリクスの中での固有値をもとめる洗練された方法を、わたしは,プログラミング言語の問題が,アルゴリズムを形にする方法に干渉するとは思いません.
　工学におけるアート(技術)は,さして込み入ったものを作りだすわけではありません.アートとは、むしろ込み入った問題を単純化するものなのです.プログラムを開発しているときは,複雑な解より,簡単な解を工夫する方が,よほど難しいあいにく,われわれが持っているコンピュータは,恐ろしいほど批判というものを知りません.なんでも燕み込んでしまうのです.
　もちろん,非常に多くの人がこの問題について議論しています。わたしがいいたいのは,プログラミングという作業の大部分においては,高度な意味の創造性は,根本的な要素ではないということです.プログラミングで面白いのは,まさになんらかの創造性を必要とする類の仕事ですが,日常の仕事においては,それは当てはまらないのです.
　最初にスプレッドシートを創りだすのは,高度に創造的な仕事です.しかし,これほど想像力を駆使して創造的な仕事をやる人は,そんなにたくさんいるわけではないのです.

　有名な言葉に「車輪を２度発明する必要はない」がある。パズルを解くのが好きな人は、過去に解決済みの問題を自力で解決することは悪くない。趣味としてなら。ただし、仕事ならそれは時間の無駄だから再発明する必要はない。目的は、モノを完成させることだから。
　とはいえ、発想豊かな優秀な人ばかりではなく、何か作りたいけど誰も作ったことのないものを作るほどの能力はない。この無駄な創造意欲を解決するために、需要もないのに既存のアセンブラ、インタプリタと同じ機能のものを自分でも作ってみたいとなる。そこで使うルーチンも自己流のちんけなものになってしまう。
　Linuxは需要があったのでここまで成功した。
　ハッカーの言だったろうか。自分が欲しいと思ったツールは他の誰かも欲しいと思うに違いない。ならば、先人が作っているかもしれない。作っていなければ自分が作る。作ってあれば、それを使ってみて必要なら改良すればよい。
　私は凡人だったので、凡人しか必要のないものを作って、無駄な創造意欲をなだめていた。

――　PascalとModulaがPL/IやAdaといった他の言語と違う点は,その単純さです.これもあなた自身の哲学の一部なのでしょうか?
Wirth　特に教師としては、単純さを尊重するように教えます.しかし,それは単細胞的な単純さではありません.この2つを同じことだと考える人もいますが,同じではないのです.論理的な演繹をおこなうとき,自由に組み合わせられるような,明快で単刀直入な原理を教えることができたら素晴らしいとは思います.そうすれば,学生は適当なところで,自分が選んだ組合せを使えるのです.
　Adaも同じようなことをめざして作られたのだと思います.しかし,当然ながら,その要求事項はすでに古くさいものになってしまいました。非常に込み入っているし,矛盾もないわけじゃない.もっとも,この要求事項を検討してみると,Adaの設計者は,実に素晴らしい仕事をしたといえます.PL/IやALGOL-68は,この点ではるかに劣っていますから.
　ALGOL-68は構造のきっちりした言語です。このことはわたしを別の問題に直面させます.Adaは非常に複雑な言語で,大きなコンピュータと複雑なコンパイラを必要とします.違ういい方をすれば,これは非常に高くつくということです。
　しかし,Adaには、他にももっとずっと高くつく要素があります.それは,これからの世代のプログラマーにとって,この言語を完全に理解するのに時間がかかるということです.特にわれわれのような仕事では、ツールを完璧に理解していなければなりません.そうでなければ,どうしてプログラムが理解できるでしょう?
　こうしたこともあって,Adaは不経済な言語といえるのです。あまりにもいろんなことをユーザーに背負わせすぎます.Adaを3分の1習うだけでも大変だと思いますね.この言語には、落とし穴がいろいろあって,習っていないことにぶつかると,ひどいことになるのです.

――しかし,当然,機能をたくさん持っているのはいいことだと主張する人たちもいますよね。そこには,必要とされるツールがすべてそろっている.PascalやFORTHでやるように,ツールをいちいち自分で作るようなことがないというわけです.
　Wirth　ModulaがPascalより優れているのは、オペレータをモジュールに入れた形で宣言できることです.これを個々別々にコンパイルして,ライブラリにつけ加えることができるのです.これで例えば、ストリング・パッケージを10個以上持つことができ,その中から一番目的に合ったものを選べるのです.
　言語があらかじめ備えている機能と,ユーザーが構築できる機能を区別することが大切です。よい言語ほどユーザーは自分で機能を構築でき,その言語の持っている機能に頼らなくてもすむものです.Adaは潜在的に,強力でよくそろった機能に支えられています.というのは,この言語が,何千人ものプログラマーを動員して,豊かなライブラリを作り出せる環境で使われることを前提としているからです.その点,Modulaは,初期のPascalと同様,もっとユーザーの「自発的な」努力に依存する性格を持っています.
――わたしの知っている人で,COBOLはソートのコマンドをはじめ、あらゆる機能が備わっているから好きだという男がいます.また,これもわたしの知人で,PL/Iのプログラマーなんですが,彼は,これより少ないユーティリティーしか使えない言語はいやだといっています.
Wirth　まず,その人がそんなにCOBOLとうまくいっているのなら、やはり,そっとしておいてあげるべきです.一方,他のシステムは,さっきいったようなライブラリを持つことができるというのも事実なのです.しかし,これは大切なことだと思うのですが,言語というのはソーティングのような複雑なオペレーションを背負わされるべきではないのです.Modulaで行われているように,ソーティングは単純なオペレーションの形をとるプログラムとして表現できます.言語に内蔵されたソートのコマンドのようなものは必要ないのです.そんなことをいっていたら切りがありません.
　同じことが入出力にもいえます.Modulaのように厳格な言語には,I/0は存在しません.しかし,デバイスの基本ドライバを作れる人,数値変換やフォーマッティングなどのためのルーチンを作れる人には,それでも十分な機能を提供しているといえるでしょう.
　われわれはみんな、どのプログラムでもこうしたオペレーションを使っています.これらはサブルーチンとしてライブラリに記憶されています.

ユーザが多くなると、必要なルーチンは誰かが作ってくれていて、昔なら書籍の形で共有するしかなかったが通信が発達するとファイルの形で入手できるようになった。今あるというか広く使われている言語は、言語仕様がユーザが好きになってというかファンになってライブラリを作りたいと思うようなものだと思う。

――みんなが自分のツールを持つと,ツールの数は増えるけれども,移植性(ポータビリティー)は小さくなるのではないですか?
Wirth　この手の議論の最も顕著な例は,ModulaのI/Oですから,これを例にとってみましょう。およそ考えられるすべての用途に適合するようなI/Oルーチンを,たった1セットの形で定義するというのは、わたしにいわせれば順序があべこべなのです。だからわたしは、まず基本的な機能を作るべきだといったのです。わたしは、大体誰もが妥当だと認めるような、単純な機能の1セットを示しました.しかし,これとて適切とはいえないアプリケーションもあるのです.このセットを活用するのもその人の自由だし,また,他人のものを使ってもいいし,あるいは自分で作りだしてもいいでしょう.移植性は大切ですけど,細かいところまでいちいち標準化しない方が賢明といえるでしょう.
　わたしは,自分が世界中のすべての人々の問題を解決できるとは思いません.I/Oはそうした解決できないものの一つです。
　Pascalの標準化について見てみましょう.このドキュメントを作るのには約6年間かかりました.こんなに長くかかったのは,非常に厄介なディテールがいろいろあって,これを一致させることができなかったからです.I/Oもその中の一つだったと思っています.Modulaに関しても,同じことをやるのに,また6年間かかるでしょう。こういう厳密な標準なしにすませられるなら,それにこしたことはないのですがね.
――データのタイプ(型)付けを強くすることのメリットは何ですか?
Wirth　タイプというのは,われわれが自分のデータのためにデザインする,構造的なテンプレートです.タイプ・チェッキングとは、オペランドにそって自分のオペレータや手続き(procedure)を用いることです.2つの論理値の足し算をしたり、キャラクタの符号を反転することはできません.タイプを明確に宣言することで,コンパイラはこうした矛盾がプログラムにないかどうかチェックできるわけです。そして,これこそ、ミスをなくそうとするわれわれの努力の中で,必要とされるものなのです.
――しかし,あまり徹底したタイプ化が望ましくない場合もあるでしょう.タイプ・チェッキングにかかずらわっていると,非常に手間を食うこともしばしばありますからね。
Wirth　そのとおりです.例えば、データをディスクに書き込んでくれる,ある種の汎用的なルーチン(generic　routine)を使いたいとします.このルーチンにとってデータは論理型であろうと、算術型であろうと何だろうと関係ありません.それで,汎用的なリード/ライトのルーチンが必要になるのです.
　データのタイプを指定してプログラミングするということは,データを抽象化して扱うことになるわけです.これは非常に重要です.例えば,1つのキャラクタが7つか8つのビットで表現されることを知っていても,何の役にも立ちません.小文字を対応する大文字に変換するのは,基本的なオペレーションです.データをディスクに書き込むルーチンは、下位の抽象化に属しています.一つのレベルから他のレベルへ移るためには,データ・タイプの規則をゆるくしておく必要があるのです。
――しかし,みんな言語をもてあますと,何か抜道はないかと探しますよね、ときには,言語の制約を回避しようとして,とんでもない遠回りをしてしまう.
Wirth　まさにそのとおりです.アセンブリ言語でのコーディングを避けるのは,非常に遠回りです.そして,抜道を使うと今度はプログラムが根本的にポータブルでなくなってしまう.この抜道というやつは,まったく個々のマシンに依存してしまう問題なのです.

この辺も深く反省している。8086憎しで80286を使ったとき8086では動かないようCPUチェックをしていたし、I/Oポートへのアクセスのタイミングもキツキツに合わせて自分のマシンでしか動かないが高速なプログラムを作り悦に入っていた。

――非常にタイプ化された言語は普遍的なマシンのモデルというものを可能にします.これはつまり,ユーザーが,実際のマシンの動きから離れてしまうことを意味しますね.これはプログラマーの能力を制限してしまうのではないでしょうか?なぜなら、マシンの中で何が起こっているか知らないということになりかねないわけですから。
Wirth　そう.これはたしかに問題です.高級言語だけを勉強するように指導していると,学生たちはたいてい不満を感じます.彼らは実際に何が行われているのかを,もっと知りたがります.コンピュータ・サイエンスを学ぶ学生に,わたしは、マシンの構造とアセンブリ言語でのコーディングを勉強することが大切だといいたい.もちろんそれは,アセンブリ言語のプログラマーになるためではなく,洞察力を身につけるためです.
　優秀なエンジニアは,使っているツールに関して,単に見かけを知っているだけでなく、深い理解を持っていなければなりません.表面の下に何があるのか知っている必要があるのです.しかし,マシンの中のことを理解しているからといって、アセンブラでシステムを作る必要はありません。「私は必要なことはマスターした。私はハイレベルの命令文でプログラムを書いて,あとはコンパイラにおまかせする.コンパイラはこれをうまくローレベルの命令に翻訳してくれるだろうわたしが自分で細心の注意を払っても,コンパイラのようにはいかないだろうから」という具合でよいわけです.
　しかし,コンピュータの中で何が行われているかを知っていると,高級言語を使う場合でも,プログラマーはより優れた仕事ができます.例えば,手続きの呼び出しが,加算や乗算に比べてどれだけ時間を食うかを知っていると,状況に応じて手続きの呼び出しを多く使ったり少-なく使ったりの加減ができるのです.もちろん,初心者には無理ですが,システム・プログラムやコンパイラを書くようになると、より優れた洞察力がものをいうのです。
――FORTHやCのようにタイプ・チ・ェッキングの機能を少ししか持たない言語もありますね.この場合,プログラマーは起こることに全面的な責任を負わなければなりません.しかし,そのかわり,高いパフォーマンスと全面的な適応性が得られます。
Wirth　特にエンジニアは,フリーハンドな力を持ちたがる傾向があるようですね.彼らは、バスをどんな信号が通るかとか,どのレジスタが何に使われるかを知ろうとする.だから、彼らにとっては,よりローレベルの言語の方が魅力的なのです.しかし,この傾向は,システムをどんどん複雑にしていく危険性をはらんでいます.しかもこの傾向は,冗長検査(redundancy　checking)機能を豊富に備えた高級言語を使えば有益であるばかりでなくその使用が不可欠であることが明らかなケースでさえも、起こっている現象なのです。
　わたしも,FORTHとまったく同じとはいいませんが,多少似た考え方の言語を作ったことがあります.それは1965年,スタンフォードで初のIBM360に使うALGOL-Wのコンパイラをインプリメントしていたときのことです。使える言語といえばアセンブラしかなく,わたしはそれがあまり気に入りませんでした。
　それでわたしは急いで中間言語を一つ作りました.これはPL360と呼ばれています.これはぼとんどタイプのない言語ですが,for,while,ifのステートメントのような,プログラム構造は持っています.その意味でこの言語はFORTHや,おそらくC言語に似ています.データについてはよりマシンに近く,プログラム構造は高級言語の性格を持っているのです.わたしは、現在はこれを使おうとしません.できるだけ多くのチェック機能が使える高級言語の方がはるかに使いやすいのです.
　例えば,わたしたちが設計したLilithマシンは多くのチェックを行います。インタープリンタ/コンパイラはできるかぎりのチェックを行い,そこでできないチェックはランタイムで行うのです.これによって,配列の添字の値が指定した範囲を超えてしまうような状況もチェックされます。ハードウェアがちゃんと働いていれば,これはたいして手間を食いません.チェック機能を使わなくても,プログラムの実行速度はたかだか数パーセント上がるだけです。
　しかし,データ・タイプの本質は、ほとんどのチェックがコンパイラでできて,実行時間をそこなわないという点にあるのです.
　C言語はこの点でFORTHに似ています。ところで,Dennis　Ritchieもわたしと同じ考えのようです.彼も,われわれは,より構造化された,より冗長度を持つ言語へと進んでいくべきだと感じています.C言語はUNIXがこれで書かれているので普及しつつあります.UNIXを使っているのなら,C言語を覚えるのもいいでしょう.しかし,わたしはそれが前進的なことだとは思いませんね.
　できの悪い言語というのは本当に恐ろしいものです。われわれはこれを使ってコミュニケーションを行っているわけですからね。ところでプログラミングの世界では“言語”という用語を使います.が,これは形式的な用語で,表記法を記述する方法に関するいくつかの研究で,この用語が用いられていたからです。例えば,Noam　Chomskyが自然言語を用いて行うことを提唱したようにです.もっともChomskyは手痛い失敗をしたわけですが,しかし,こうして今日われわれはプログラミング“言語”を得たというわけです.
　わたしとしてはプログラム“記法”と呼ぶ方が好きなのですが、いまさら定着してしまった言葉を覆すことはできません.

また登場したビッグネーム。UnixとC言語を作ったデニス・リッチー。
C言語の記法が好きだった。Pacalだとキータイプの量が多くちょっとイラっとした。Cはアセンブラというかコンパイルされる機械語が想像できてタイプ量も少なく好きだった。一番好きなのはこれ、アセンブラなら　INC A　とか DEC A とか書くのがCなら++a , ---a とか書く。この同じキーを連続させるというところがキータイプが速くなり、頭の中で浮かんでいるコードが速く入力でき、考えたことがすぐ画面に表示されるのが好きだった。また　 a += b という表記も気に入っている。 a = a + b よりよっぽどいい。

――優秀なプログラマーの条件とは何でしょう?この分野に創造的な人物はいるのでしょうか?
Wirth　わたしは最近,同僚の一人と,われわれの教え子たちに何を求めるべきかについて議論しました。そのときのわたしの意見は大体次のようなものでした.すtoD5,B.S.(Bachelor　of　Science)の段階では,学生は教えられたテクニックの応用の仕方を知っていること,さらにそれを意識的にできることが求められる.M.S.(Master　of　Science)の段階では,重要なこととより重要でないこと,本質的なことと些細なことを見分けられる能力が求められる.また,しっかりとした設計かどうかを吟味できる力も必要です.しかし,実際にはPh.D.(Doctor　of　Phirosophy)のレベルでも、びっくりするほどこうした能力が欠けている学生にお目にかかります.もしある人がよい仕事をしテクニックを身につけ,それを非常にうまく応用でき,さらに,重要なことと重要でないことを見分けられたら,それはもうPh.D.の水準に達しているといえます.
　さらに,これらのすべてを満たし,しかもイマジネーションと創造力に富んでいる人材はあまり多くありません。彼らは本当に例外的な存在です.たぶん彼らはアーチストと呼ばれるべき人々なのです.この,真に例外的な人物は,両方の資質を必要とします.まず,科学的な素養を持ち、ツールについて熟知しており,状況と概念を分析する能力を持っている必要があります.そして,そのツールを状況に応じて応用し,適切なツールがない場合は,それを自分で創り出さなければなりません.そして最後に,何か新しいものを創造する能力ですが,これは非常に大きな力を要求されます.
　明らかにだめなのは,自分を非常に創造的だと思い込んでいるくせに,見かけ倒しのものしか作れない人です.たぶん彼は,他の人がいい仕事をするための励ましにはなるでしょうが,わたしの経験からすると,真に創造的な人はたいてい,優れた,堅実な仕事をするものです.
　真のアーチストとは、ツールを創造的に,しかも効果的に使って,それ以前の限界を突破して可能性を広げるような,「類い稀れな人のことです。真のアーチストはみんな,自分のアートに必要なテクニックをマスターし,見かけだけの手際を忌み嫌うものです.
　(翻訳:原修二)