1974 年 ACM 圖靈獎演講

[1974 年圖靈獎委員會主席 Bernard A. Galler 於 11 月 11 日在聖地亞哥舉行的 ACM 年會上宣讀圖靈獎引文，並介紹本次演講。]

ACM 的 A.M. Turing Award 每年由 ACM 頒發給對計算領域做出技術性貢獻的個人。特別是，這些貢獻應對電腦領域的主要部分產生了重大影響。

「1974 年 A.M. Turing Award 頒發給史丹佛大學的 Donald E. Knuth 教授，以表彰他對演算法分析和程式語言設計做出的諸多重大貢獻，特別是他通過其系列知名著作對『電腦程式設計的藝術』做出的最重要貢獻。這些書籍中彙集的技術、演算法及相關理論，已成為學科課程發展的焦點，並對電腦科學起到了組織性的影響力。」

這樣正式的陳述無法充分體現 Don Knuth 在電腦科學乃至整個電腦產業中所扮演的角色。根據我對圖靈獎首位得主 Alan J. Perlis 教授的經驗，他參與的每次會議中，他總能對正在討論的問題提供深入見解，成為會議其餘時間討論的焦點。類似地，Donald E. Knuth 在他優秀的書籍和論文集中提供的詞彙、範例、演算法和見解，已開始滲透到該領域幾乎所有領域的許多討論中。這並不容易實現。正如每位作者所知，即使是單一著作也需要大量的細心組織和艱苦工作。我們更應欣賞 Knuth 必須具備的清晰視野、耐心和精力，才能規劃七卷書籍並如此細緻周密地實施其計畫。

值得注意的是，這項獎項和他一直在接受的其他獎項，是在他的作品已出版三卷後頒發給他的。我們顯然已準備好向所有人表達我們對 Donald E. Knuth 獻身於我們學科並做出貢獻的肯定。我非常高興擔任委員會主席，該委員會選擇了 Donald E. Knuth 接受 ACM 1974 年 A.M. Turing Award。

電腦程式設計的藝術性

作者：Donald E. Knuth

當 Communications of the ACM 於 1959 年開始發行時，ACM 編輯委員會成員在描述 ACM 期刊的宗旨時曾發表以下評論 [2]：「如果電腦程式設計要成為電腦研究和開發的重要部分，程式設計必須從一門藝術轉變為一門有紀律的科學。」

這個目標在隨後的幾年中一直是重複出現的主題；例如，我們在 1970 年讀到「將程式設計的藝術轉變為科學的第一步」[26]。同時，我們實際上已經成功地將我們的學科變成了一門科學，而且是以一種非常簡單的方式：僅僅通過決定將其稱為「電腦科學」。

這些評論中蘊含的觀念是，被歸類為「藝術」的人類活動領域似乎有些不盡人意；它必須是一門科學才能擁有真正的地位。另一方面，我已經花了超過 12 年的時間撰寫一系列名為《電腦程式設計的藝術》的書籍。人們經常問我為什麼選擇這個標題；事實上，有些人似乎不相信我真的這樣做了，因為我至少看到過一份書目參考資料，稱我的書為《電腦程式設計的行為》(The Act of Computer Programming)。

在這次演講中，我將嘗試解釋為什麼我認為「藝術」是恰當的詞彙。我將討論某件事物作為藝術意味著什麼，與作為科學相對照；我將嘗試檢驗藝術是好事還是壞事；我將嘗試表明，對這個主題的適當觀點將有助於我們所有人改進我們現在所做事情的品質。

我第一次被問及我的書籍標題之一是在 1966 年，當時恰逢上一次在南加州舉行的 ACM 全國會議。那時我的書都還沒有出版，我記得當時和一位朋友在會議酒店吃午餐。他知道那時的我已經很自負了，所以他問我是否打算將我的書命名為「An Introduction to Don Knuth」。我回答說，恰恰相反，我是以他的名字來命名我的書的。他的名字是：Art Evans。（電腦程式設計的藝術，本人登場。）

從這個故事我們可以得出結論，「藝術」這個詞有多重含義。事實上，這個詞最美妙的一點是它有許多不同的用法，而每種用法都與電腦程式設計非常契合。在準備這次演講時，我去了圖書館查閱多年來人們對「藝術」這個詞寫了些什麼；在圖書堆中度過了幾個引人入勝的日子後，我得出結論，「藝術」必定是英語中最有趣的詞之一。

往昔的藝術

如果我們追溯到拉丁詞根，會發現 ars, artis 意為「技能」。也許值得注意的是，對應的希臘詞是 τέχνη (techne)，它是「技術」（technology）和「技巧」（technique）的詞根。

現今，當有人談論「藝術」時，你首先可能會想到「美術」（fine arts），例如繪畫和雕塑，但在二十世紀之前，這個詞通常是以一種完全不同的意義使用。由於這種「藝術」的舊有意義仍然存在於許多習語中，特別是當我們將藝術與科學對比時，我想花幾分鐘時間談談古典意義上的藝術。

在中世紀時期，第一批大學成立是為了教授七種所謂的「博雅藝術」（liberal arts），即文法、修辭學、邏輯學、算術、幾何學、音樂和天文學。請注意，這與現今博雅大學的課程安排完全不同，而且至少其中七種最初的博雅藝術中的三種是電腦科學的重要組成部分。在那時，「藝術」指的是人類智力所創造的事物，與源於自然或本能的活動相對；「博雅」藝術是自由的，與耕作等手工藝術形成對比（參見 [6]）。在中世紀，「藝術」這個詞本身通常指的是邏輯學 [4]，而邏輯學通常是指三段論的研究。

科學與藝術之比較

「科學」這個詞似乎已經使用了很多年，其意義與「藝術」大致相同；例如，人們也談論七種博雅科學，它們與七種博雅藝術相同 [1]。十三世紀的 Duns Scotus 稱邏輯學為「科學之科學，藝術之藝術」（參見 [12, p. 34f]）。隨著文明和學習的發展，這兩個詞帶有了越來越獨立的含義，「科學」被用來代表知識，而「藝術」則代表知識的應用。因此，天文學這門科學是航海這門藝術的基礎。情況幾乎與我們現在區分「科學」和「工程學」的方式完全相同。

許多作者在十九世紀寫作關於藝術與科學之間的關係，我相信最好的討論是由 John Stuart Mill 所給予的。他在 1843 年說了以下這些話 [28]：

一門單一的藝術常常需要多門科學來構成基礎。人類事務如此複雜，要使一件事完成，常常需要了解許多事物的本質和特性......藝術總體而言由科學的真理組成，這些真理按照最方便實踐而非最方便思考的順序排列。科學對其真理進行分組和排列，以便我們能盡可能地概觀宇宙的普遍秩序。藝術...則將科學領域中最遙遠的部分聯繫起來，彙集與實踐生活需求所需的各種異質條件的產生相關的真理。

當我查閱這些關於「藝術」含義的資料時，我發現作者們至少在兩個世紀前就一直在呼籲從藝術向科學轉變。例如，一本寫於 1784 年的礦物學教科書的序言中說了以下這段話 [17]：

在 1780 年之前，礦物學雖然許多人作為一門藝術相當了解，但幾乎不能被視為一門科學。

根據大多數詞典的解釋，「科學」指的是以普遍的「定律」形式邏輯地排列和系統化的知識。科學的優點在於它使我們不必在每個個別情況下都進行思考；我們可以將我們的思緒轉向更高層次的概念。正如 John Ruskin 在 1853 年所寫 [32]：「科學的工作是用事實取代表象，用證明取代印象。」

在我看來，如果我研究的作者今天寫作，他們會同意以下特徵描述：科學是我們理解得如此透徹以至於可以教給電腦的知識；而如果我們不完全理解某事，處理它就是一門藝術。由於演算法或電腦程式的概念為我們提供了一個極其有用的測試，以衡量我們對任何特定主題知識的深度，從藝術轉變為科學的過程意味著我們學習如何自動化某些事物。

人工智慧取得了顯著進展，但在可預見的未來電腦能做到的事情與普通人能做到的事情之間存在巨大差距。人們在說話、聽取、創造，甚至在程式設計時擁有的神秘洞察力，仍然超出科學的範疇；我們所做的幾乎一切仍然是一門藝術。

從這個角度來看，將電腦程式設計變成一門科學無疑是可取的，而且自從我在演講開頭引用的評論發表以來，我們在過去 15 年中確實取得了長足的進步。15 年前，電腦程式設計的理解程度之差，以至於幾乎沒有人考慮過證明程式的正確性；我們只是修修改改程式，直到我們「知道」它能工作。當時，我們甚至不知道如何以嚴格的方式表達程式是正確的概念。直到近幾年，我們才開始學習關於程式編寫和理解的抽象過程；關於程式設計的這種新知識目前正在實踐中產生巨大的回報，即使程式實際上並未完全嚴格地證明正確性，因為我們正在開始理解程式結構的原理。重點在於，當我們今天編寫程式時，我們知道原則上我們可以構建它們的正式證明，如果我們真的想這樣做的話，因為我們現在已經理解了如何制定這些證明。這種科學基礎正在使程式比我們以前僅憑直覺判斷正確性時編寫的程式顯著更可靠。

「自動程式設計」領域是當今人工智慧研究的主要領域之一。其支持者非常樂意能夠發表一篇題為「電腦程式設計作為一種人工產物」（意思是程式設計已經成為過去的遺物）的演講，因為他們的目標是創造出僅憑問題規範就能比我們更好地編寫程式的機器。我個人認為這個目標永遠不會完全實現，但我確實認為他們的研究極其重要，因為我們學習到的關於程式設計的一切都有助於提升我們自身的藝術性，在這個意義上，我們應該不斷努力將每一門藝術轉變為科學：在這個過程中，我們推動了藝術的發展。

科學與藝術

我們的討論表明，電腦程式設計現在既是一門科學也是一門藝術，並且這兩個方面相得益彰。顯然，大多數研究這個問題的作者都得出了相同的結論，即他們的學科既是一門科學也是一門藝術，無論他們的學科是什麼（參見 [25]）。我找到了一本寫於 1893 年關於基礎攝影的書籍，其中寫道「攝影影像的顯影既是一門藝術也是一門科學」[13]。事實上，當我第一次拿起詞典研究「藝術」和「科學」這兩個詞時，我偶然看到編輯的序言，開頭就說：「編寫詞典既是一門科學也是一門藝術。」Funk & Wagnall's 詞典的編輯 [27] 觀察到，對詞語數據的 painstaking 累積和分類具有科學性質，而選擇恰當的定義措辭則需要以經濟和精確的方式寫作的能力：「沒有藝術的科學可能無效；沒有科學的藝術肯定不準確。」

在準備這次演講時，我查閱了史丹佛大學圖書館的卡片目錄，看看其他人如何在書名中使用「藝術」和「科學」。這非常有趣。

例如，我找到了兩本名為《鋼琴演奏的藝術》（The Art of Playing the Piano）的書 [5, 15]，以及其他名為《鋼琴技巧的科學》（The Science of Pianoforte Technique）[10]、《鋼琴練習的科學》（The Science of Pianoforte Practice）[30] 的書。還有一本名為《鋼琴演奏的藝術：一種科學方法》（The Art of Piano Playing: A Scientific Approach）[22] 的書。

然後我找到了一本不錯的小書，名為《數學的溫柔藝術》（The Gentle Art of Mathematics）[31]，這讓我有點難過，因為我無法誠實地將電腦程式設計描述為一門「溫柔的藝術」。

幾年前我就知道一本名為《計算的藝術》（The Art of Computation）的書，由 C. Frusher Howard 於 1879 年在舊金山出版 [14]。這是一本關於實用商業算術的書，到 1890 年在各種版本中已售出超過 40 萬冊。我很高興閱讀了這本書的序言，因為它顯示 Howard 的哲學和他的標題意圖與我的完全不同；他寫道：「了解數的科學是次要的；計算藝術的技能是絕對不可或缺的。」

有幾本書的標題中同時提到了科學和藝術，最著名的是 Maharishi Mahesh Yogi 的《存在的科學與生活的藝術》（The Science of Being and Art of Living）[24]。還有一本名為《科學發現的藝術》（The Art of Scientific Discovery）[11] 的書，它分析了一些偉大科學發現是如何實現的。

關於「藝術」的古典含義就說到這裡。實際上，當我選擇我的書名時，我並不是主要考慮這個意義上的藝術，我更多地是在考慮它目前的內涵。在我搜索到的書籍中，最有趣的一本大概是 Robert E. Mueller 最近的一部作品，名為《藝術的科學》（The Science of Art）[29]。在我提到的所有書中，Mueller 的書最接近表達我今天演講的中心主題，即我們現在理解的真實藝術性。他觀察到：「過去人們認為藝術家的想像力對科學家來說是致命的。而科學的邏輯似乎宣判了所有可能的藝術奇思異想的滅亡。」他繼續探討了科學與藝術結合所帶來的實際優勢。

科學方法通常以邏輯的、系統的、客觀的、冷靜的、理性的詞語來形容，而藝術方法則以美學的、創造性的、人道的、焦慮的、非理性的詞語來形容。在我看來，這兩種看似矛盾的方法對於電腦程式設計都具有巨大價值。

Emma Lehmer 在 1956 年寫道，她發現程式編寫「既是一門嚴謹的科學，也是一門引人入勝的藝術」[23]。H.S.M. Coxeter 在 1957 年評論說，他有時感覺自己「更像一個藝術家而不是科學家」[7]。當時 C.P. Snow 正開始對受過教育人群中「兩種文化」日益加劇的兩極化表達擔憂 [34, 35]。他指出，如果我們要取得真正進步，需要結合科學和藝術價值觀。

藝術作品

當我坐在聽眾席上聽冗長的演講時，我的注意力通常在演講進行到這個時候就開始減弱了。所以我想知道，您是否對我關於「科學」和「藝術」的長篇大論感到有點厭倦了？我真心希望您能仔細聽完接下來的部分，因為現在到了我感受最深的部分。

當我談論電腦程式設計是一門藝術時，我主要是從美學意義上將其視為一種藝術形式。我作為教育者和作者的主要目標是幫助人們學習如何編寫優美的程式。正是因為這個原因，我最近得知 [33] 我的書籍實際上被放在 Cornell University 的美術圖書館時，我感到特別高興。（然而，這三卷書似乎整齊地擺在書架上，沒有被使用，所以我擔心圖書館員可能誤解了我的書名。）

我的感覺是，當我們編寫程式時，它可能就像創作詩歌或音樂；正如 Andrei Ershov 所說 [9]，程式設計能帶給我們智力和情感上的滿足，因為掌握複雜性並建立一套連貫的規則是一項真正的成就。

此外，當我們閱讀別人的程式時，我們可以將其中一些視為真正的藝術作品。我至今仍記得 1958 年閱讀 Stan Poley 的 SOAP II 組合語言程式碼清單時的巨大震撼；您可能會覺得我瘋了，而且風格自那以來確實發生了巨大變化，但在當時，看到一個系統程式能如此優雅對我意義重大，特別是與我當時正在研究的其他程式碼清單中笨拙的程式設計相比。即使是用組合語言，編寫優美程式的可能性，正是最初讓我對程式設計產生興趣的原因。

有些程式優雅，有些精緻，有些閃耀。我的主張是，編寫宏偉的、非凡的、真正壯麗的程式是可能的！

品味與風格

程式設計中的「風格」理念終於開始受到重視，我希望你們大多數人都看過 Kernighan 和 Plauger 撰寫的優秀小書《程式設計風格的要素》（The Elements of Programming Style）[16]。在這方面，對我們所有人來說最重要的是記住，沒有一種「最佳」風格；每個人都有自己的偏好，試圖將人們強行納入不自然的模式是一種錯誤。我們常聽到這句話：「我不懂藝術，但我知道我喜歡什麼。」重要的是你真正喜歡你正在使用的風格；這應該是你偏好表達自己的最佳方式。

Edsger Dijkstra 在他的《程式設計藝術簡介》（A Short Introduction to the Art of Programming）[8] 的序言中強調了這一點：

我的目的是傳達程式設計中良好品味和風格的重要性，[但] 所呈現的具體風格要素僅用於說明「風格」一般能帶來的益處。在這方面，我覺得自己像音樂學院的作曲老師：他不是教學生如何譜寫特定的交響樂，他必須幫助學生找到自己的風格，並向他們解釋這意味著什麼。（正是這個類比讓我談論「程式設計的藝術」。）

現在我們必須問自己，什麼是好的風格，什麼是壞的風格？在評判他人的作品時，我們不應該過於死板。十九世紀初的哲學家 Jeremy Bentham 這樣說 [3, Bk. 3, Ch. 1]：

審度優雅和品味的人自視為人類的恩人，而實際上他們只是妨礙人類樂趣的人……除非某種品味是為了那種能將實際產生的樂趣與某些偶發或未來功用結合起來的活動，否則它不配得到「好」的稱謂；除非某種品味傾向於某種有害的活動，否則它不配被稱為「壞」。

當我們將自己的偏見應用於「改革」某人的品味時，我們可能在不知不覺中剝奪了他完全正當的樂趣。這就是為什麼我不譴責許多程式設計師所做的事情，即使我自己永遠不會喜歡做這些事情。重要的是他們正在創造他們覺得美好的事物。

在我剛才引用的段落中，Bentham 確實給了我們一些關於某些美學原則比其他原則更好的建議，即結果的「功用」（utility）。我們在建立自己的個人美學標準方面有一定的自由，但如果我們視為美好的事物同時也被其他人視為有用，那就尤其美妙了。我必須承認，我非常喜歡編寫電腦程式；我尤其喜歡編寫在某種意義上能產生最大益處的程式。

當然，程式在許多方面都可以是「好的」。首先，能有一個能正確運行的程式尤其好。其次，有一個在需要修改時不易更改的程式通常也很好。當程式易於懂得相應語言的人閱讀和理解時，這兩個目標都能實現。

一個生產性程式好的另一個重要方式是它能與其用戶優雅地互動，特別是在從輸入數據中的人為錯誤中恢復時。編寫有意義的錯誤訊息或設計不易出錯的靈活輸入格式是一門真正的藝術。

程式品質的另一個重要方面是電腦資源的實際使用效率。我很抱歉地說，如今許多人正在譴責程式效率，告訴我們這是一種壞品味。這是因為我們現在正在經歷對過去效率是唯一可信標準的時代的反動，而過去的程式設計師傾向於過於關注效率，以至於他們產生了不必要的複雜程式碼；這種不必要複雜性的結果是，由於調試和維護的困難，總體效率反而下降了。

真正的問題是，程式設計師在錯誤的地方和錯誤的時間花了太多時間擔心效率；過早的最佳化是萬惡之源（至少是大多數惡的根源）在程式設計中。

我們不應該為了省小錢而花大錢，也不應該總是將效率僅僅視為總運行時間或空間中損失或獲得的百分比。當我們購買汽車時，我們許多人幾乎不介意其價格相差 50 美元或 100 美元，而我們可能會專程去某家商店購買一個 50 美分的商品，只為了 25 美分。我的意思是，效率有其適當的時間和地點；我在我關於結構化程式設計的論文中討論了它的適當角色，這篇論文發表在最新一期的 Computing Surveys [21] 上。

設施越少，樂趣越多

我注意到關於美學滿足感的一個相當奇特的現象是，當我們用有限的工具完成某件事時，我們的樂趣會顯著增強。例如，我個人最滿意和最引以為傲的程式是我曾經為一台只有 4096 個字，每個字 16 位元的原始微型電腦編寫的編譯器。在如此嚴格的限制下取得成就讓人感覺自己像個真正的演奏家。

類似的現象也發生在許多其他情境中。例如，人們似乎常常愛上他們的 Volkswagen，但很少愛上他們的 Lincoln Continentals（後者大概運行得好得多）。當我學習程式設計時，流行的一種消遣是在只需單張打孔卡就能容納的程式中盡可能多地做事情。我想這正是讓 APL 愛好者珍視他們「一行程式」的同樣現象。當我們現在教授程式設計時，一個奇怪的事實是，我們很少能在學生上了允許親自操作微型電腦的課程之前，激發他們對電腦科學的熱愛。使用配有高級作業系統和語言的大型機器，似乎並不能真正激發對程式設計的熱愛，至少一開始不能。

如何應用這個原則來增加程式設計師工作的樂趣並不明顯。如果他們的經理突然宣布新機器只有舊機器一半的記憶體，程式設計師肯定會抱怨。而且我認為沒有人，即使是最敬業的「程式設計藝術家」，也會歡迎這種前景，因為沒有人喜歡不必要地失去便利設施。另一個例子可能會有助於澄清這種情況：電影製作人強烈反對 1920 年代有聲電影的引進，因為他們對自己無需聲音就能傳達訊息的方式感到由衷的自豪。類似地，一個真正的程式設計藝術家可能會對引進更強大的設備感到不滿；今天的海量儲存設備往往破壞了我們舊式磁帶排序方法的許多美感。但今天的電影製作人不想回到無聲電影時代，這不是因為他們懶惰，而是因為他們知道使用改進的技術完全有可能製作出美麗的電影。他們的藝術形式改變了，但藝術性仍有廣闊的空間。

他們是如何發展他們的技巧的？多年來最優秀的電影製作人似乎通常是在相對原始的環境中學習他們的藝術，通常是在電影產業有限的其他國家。近年來，我們學到的關於程式設計的最重要的事情似乎都源於那些無法接觸到非常大型電腦的人們。我認為這個故事的寓意是，我們應該在自己的教育中利用有限資源的概念。通過偶爾做一些「玩具」程式，設置人為的限制，迫使我們將自己的能力發揮到極限，我們都能受益。我們不應該一直過著奢華的生活，因為那會讓我們變得懶散。用我們的全部精力處理微小問題的藝術將磨練我們解決實際問題的才能，並且這種經驗將幫助我們在使用限制較少的設備完成工作時獲得更多樂趣。

類似地，我們不應該迴避「為藝術而藝術」；我們不應該對僅僅為了娛樂而編寫的程式感到內疚。我曾經寫一個只有一個陳述的 ALGOL 程式而感到非常興奮，它以一種非同尋常的方式調用了一個內積程序，結果計算出了第 N 個質數，而不是內積 [19]。幾年前，Stanford 的學生們很興奮地尋找最短的 FORTRAN 程式，這個程式可以列印出自己的原始碼。這個問題在許多其他語言中也得到了考慮。我不認為他們花時間在這上面是浪費的；我之前引用的 Jeremy Bentham 也不會否認這種消遣的「功用」[3, Bk. 3, Ch. 1]。「恰恰相反」，他寫道，「沒有什麼比這更有功用的了。如果不將功用歸於提供樂趣的事物，那將歸於什麼呢？」

提供美好的工具

現代藝術的另一個特點是強調創造力。如今許多藝術家似乎不太關心創造美麗的事物；只有想法的新穎性才是重要的。我並不是推薦電腦程式設計應該在這個意義上像現代藝術，但這確實讓我提出一個我認為重要的觀察。有時我們被指派一個幾乎無望地枯燥的程式設計任務，完全沒有任何創造力的發洩口；而在這種時候，一個人很可能會來找我說：「所以程式設計很美？你滔滔不絕地說我應該從創造優雅迷人的程式中獲得樂趣，這對你來說很容易，但我該如何將這個爛攤子變成一件藝術品呢？」

好吧，這是實話，並非所有程式設計任務都會有趣。考慮一下「被困住的家庭主婦」，她每天都必須擦同一張桌子：並非每個情況都有創造力或藝術性的空間。但即使在這種情況下，也有辦法做出很大的改進：如果我們有美好的工具來工作，做日常工作仍然是一種樂趣。例如，如果一張桌子設計精美，由優質硬木製成，一個人會真正享受日復一日地擦拭飯桌。

因此，我想把我的結束語獻給那些生產我們其他人必須使用的系統的系統程式設計師和機器設計師。請給我們提供用起來令人愉悅的工具，特別是對於我們的日常任務，而不是提供一些我們必須與之搏鬥的東西。拜託了。請給我們提供鼓勵我們寫出更好程式的工具，通過增強我們這樣做時的樂趣。

我很難說服大學新鮮人程式設計是美麗的，當我告訴他們的第一件事是如何打孔「斜線斜線 JOB 等於某某某」時。即使是工作控制語言也可以設計成用起來令人愉悅，而不僅僅是功能性的。

電腦硬體設計師可以讓他們的機器用起來更令人愉悅，例如通過提供滿足簡單數學定律的浮點算術。目前大多數機器上可用的功能使得嚴格的誤差分析工作幾乎不可能實現，但設計得當的操作會鼓勵數值分析師提供經過認證精度的更好的子程序（參見 [20, p. 204]）。

讓我們也考慮一下軟體設計師能做些什麼。保持系統用戶士氣的最佳方法之一是提供他可以互動的例程。我們不應該讓系統過於自動化，讓操作總是在幕後進行；我們應該給程式設計師用戶一個機會，讓他將創造力引導到有用的渠道。所有程式設計師的共同點是他們喜歡與機器一起工作；所以讓他們保持在迴圈中。有些任務最好由機器完成，而有些則最好由人類的洞察力完成；一個設計得當的系統會找到正確的平衡點。（多年來我一直在努力避免誤導的自動化，參見 [18]。）

程式測量工具是一個很好的例子。多年來，程式設計師一直不清楚在他們的程式中，計算的實際成本分佈在哪裡。經驗表明，幾乎每個人對他們程式中的真正瓶頸都有錯誤的想法；當程式設計師從未獲得根據他編寫的程式碼行數進行的成本明細時，效率的嘗試常常事與願違也就不足為奇了。他的工作有點像一對新婚夫婦試圖規劃一個平衡的預算，卻不知道食物、住房和衣物等個別項目的花費是多少。我們一直給程式設計師的只是一個最佳化編譯器，它神秘地對它翻譯的程式做了些什麼，但從未解釋它做了什麼。幸運的是，我們現在終於看到了一些系統的出現，這些系統賦予用戶一些智慧；它們自動為程式提供儀器和關於實際成本的適當反饋。這些實驗性系統取得了巨大的成功，因為它們產生了可衡量的改進，特別是因為它們使用起來很有趣，所以我相信這些系統的應用普及只是時間問題。我在 Computing Surveys [21] 中的論文進一步討論了這個問題，並提出了一些其他想法，說明恰當的互動式例程如何能增強用戶程式設計師的滿意度。

語言設計師也有義務提供鼓勵良好風格的語言，因為我們都知道風格很大程度上受到表達它的語言的影響。目前對結構化程式設計的濃厚興趣表明，我們現有的語言沒有一種是真正理想的用於處理程式和數據結構的，也不清楚理想的語言應該是什麼樣的。因此，我期待未來幾年語言設計方面有許多仔細的實驗。

總結

總結來說：我們看到電腦程式設計是一門藝術，因為它將累積的知識應用於世界，因為它需要技巧和創造力，特別是因為它能產生美麗的事物。一個潛意識裡將自己視為藝術家的程式設計師會享受他所做的事情，並且會做得更好。因此，當在電腦會議上演講的人們談論「藝術的狀態」（State of the Art）時，我們可以感到高興。

參考文獻

  1. Bailey, Nathan. The Universal Etymological English Dictionary. T. Cox, London, 1727. See "Art," "Liberal," and "Science."
  2. Bauer, Walter F., Juncosa, Mario L., and Perlis, Alan J. ACM publication policies and plans. J. ACM 6 (Apr. 1959), 121-122.
  3. Bentham, Jeremy. The Rationale of Reward. Trans. from Thdorie des peiltes et des rdcompenses, t811, by Richard Smith, J. & H. L. Hunt, London, 1825.
  4. The Cetmry Dictiotlary atd Cyclopedia 1. The Century Co., New York, I889.
  5. Clementi, Muz[o. The Art of Playing the Piano. Trans. from L'art de ]ouer le pianq/brte by Max Vogrich. Schirmer, New York, 1898.
  6. Colvin, Sidney. "Art?' Eircyclopaedia Britatmica, eds 9, 11, 12, 13, 1875-1926.
  7. Coxeter, H. S. M. Convocation address, Proc. 4th Canadian Math. Congress, 1957, pp. 8-40.
  8. Dijkstra, Edsger W. EWD316: A Short lrtrodaction to the Art 02/ Programmitg. T. H. Eindhoven, The Netherlands, Aug. 1971.
  9. Ershov, A. P. Aesthetics and the human factor in programming. Comm. ACM 15 (July 1972), 501--505.
  10. Fielden, Thomas. The Science o/" Piano/brte Technique. Macmillan, London, 1927.
  11. Gore, George. 771e Art of Scientific Dis'covery. Longmans, Green, London, 1878.
  12. Hamilton, William. Lectures on Logic 1. Wrn. Blackwood, Edinburgh, 1874.
  13. Hodges, John A. Elementary Photography: The "Amateur Photographer" Library 7. London, 1893. Sixth ed, revised and enlarged, 1907, p. 58.
  14. Howard, C. Frusher. Howard's Art of Computation and golden rule for equation of payments for schools, business colleges and seligculture .... C.F. Howard, San Francisco, 1879.
  15. Hummel, J.N. 17re Art o/" Playing the Piano Forte. Boosey, London, 1827.
  16. Kernighan B.W., and Plauger, P.J. The Elements oJ" Program-milrg Style. McGraw-Hill, New York, 1974.
  17. Kirwan, Richard. Eleme,Tts o/" Mineralogy. Elmsly, London, 1784.
  18. Knuth, Donald E. Minimizing drum latency time. J. ACM 8 (Apr. 1961), 119-150.
  19. Knuth, Donald E., and Merner, J.N. ALGOL 60 confidential. Comm. ACM 4 (Jane 1961), 268--272.
  20. Knuth, Donald E. Seminumerical Algorithms: The Art o/" Computer Programming 2. Addison-Wesley, Reading, Mass., 1969.
  21. Knuth, Donald E. Structured programming with go to state-ments. Computbrg Surveys 6 (Dec. 1974), pages in makeup.
  22. Kochevitsky, George. The Art of Piano Plwing: A Scientific Approach. Summy-Birchard, Evanston, II1., 1967.
  23. Lehmer, Emma. Number theory on the SWAC. Proc. Syrup. Applied Math. 6, Amer. Math. Soc. (1956), 103-108.
  24. Mahesh Yogi, Maharishi. The Science q/'Being and Art qf Living. Allen & Unwin, London, 1963.
  25. Malevinsky, Moses L. The Science of Playwriting. Brentano's, New York, 1925.
  26. Manna, Zohar, and Pnueli, Amir. Formalization of properties of functional programs, d. ACM 17 (July t970), 555-.569.
  27. Marckwardt, Albert H. Preface to lqmk and Wagnall's Stan-dard Colh, ge Dictionary. Harcourt, Brace & World, New York, 1963, vii.
  28. Mill, John Stuart. A System off Logic, Ratiocinative and brductive. London, 1843. The quotations are from the introduction, §2, and from Book 6, Chap. 11 (12 in later editions), §5.
  29. Mueller, Robert E. The Science of Art. John Day, New York, 1967.
  30. Parsons, Albert Ross. The Science of Piano/brte Practice. Scbirmer, New York, 1886.
  31. Pedoe, Daniel. The Gentle Art of Mathematics. English U. Press, London, 1953.
  32. Ruskin, John. The Stones of Venice 3. London, 1853.
  33. Salton,. G.A. Personal communication, June 21, 1974.
  34. Snow, C.P. The two cultures. The New Statesman and Nation 52 (Oct. 6, 1956), 413-414.
  35. Snow, C.P. The Two Cultures: and a Second Look. Cambridge University Press, 1964.