程式設計大師智慧結晶：與主流程式語言的創始者對話

　　《程式設計大師智慧結晶》專訪了多位程式語言的創始者，他們每一位都極具歷史意義及影響力。在這本獨特的訪談錄中，你將瞭解具體的設計決策過程，包括創始人心中所描繪的目標，他們如何權衡折衷，以及他們的經驗如何影響現今的程式設計。

　　受訪者包括：
　　Adin D. Falkoff: APL
　　Thomas E. Kurtz: BASIC
　　Charles H. Moore: FORTH
　　Robin Milner: ML
　　Don Chamberlin: SQL
　　Alfred Aho, Peter Weinberger, Brian Kernighan: AWK
　　Charles Geschke, John Warnock: PostScript
　　Bjarne Stroustrup: C++
　　Bertrand Meyer: Eiffel
　　Tom Love, Brad Cox: Objective-C
　　Larry Wall: Perl
　　Simon Peyton Jones, Paul Hudak, Philip Wadler, John 　　
　　Hughes: Haskell
　　Guido van Rossum: Python
　　Luiz Henrique de Figueiredo, Roberto Ierusalimschy: Lua
　　James Gosling: Java
　　Ivar Jacobson, James Rumbaugh, Grady Booch: UML
　　Anders Hejlsberg: Delphi發明者和C#的主要開發者

　　如果你有興趣瞭解這些見識卓越又致力於電腦工業發展的人，你將發現《程式設計大師智慧結晶》非常引人入勝。

　　關於採訪者：

　　Federico Biancuzzi是自由採訪者，他的訪談錄已發表於多個線上刊物，包括ONLamp、NewsForge、TheRegister、ArsTechnica等。

　　Shane Warden是自由軟體開發者，對程式語言設計和虛擬機器很感興趣。業餘時，他還經營著獨立出版商Onyx Neon Press的小說部。他也是《The Art of Agile Development》（O’Reilly）的合著者。

第十章 SQL

即使擁有結構化資料的集合，如果不知道人們所需要的資料操作類型與方式，你如何能提供有效的方式來收集、存取和更新資訊？關聯模式的基本概念是由 E. F.(Ted)Codd發明；SQL則是關聯模式最著名的執行成果－－一種陳述性的語言，用來描述人們想要從資料庫存取的內容為何，而不是描述如何存取。基於 Codd的原始概念，Donald Chamberlin和 Raymond Boyce進而開發了SQL。

一篇具開創性的文章
請問 SQL是如何設計的？

Don Chamberlin：整合的資料庫系統於1970年代早期開始廣泛地部署。科技和經濟的趨勢使企業開始正視資料為公司的重要資源，必須在許多應用之間共享。以資料為中心的新觀點開創了發展新一代資料管理科技的機會。

1970年代，IBM主流的資料庫產品為IMS，但是除了IMS開發團隊之外，幾個IBM區域的小研究團隊也同步進行資料庫問題的研究。E. F. (Ted) Codd博士是其中一個研究團隊的領導者，他的研究實驗室位於加州聖荷西市。Ray Boyce和我則是位於紐約Watson研究中心的研究團隊成員。Ray和我負責研究資料庫查詢語言，嘗試改善當時通用查詢語言的技術。

在1970年6月，Ted Codd發表一篇具有開創性的論文，介紹資料關聯模式，並且描述模式中資料獨立性和應用開發的優點。Codd的論文吸引許多來自IBM內部和外部的關注。

1972年，Ray Boyce與我參加一個在Watson研究中心舉辦，由Codd主持的關聯資料模式的專題座談會。那場座談會對於Ray與我而言是個生涯的轉捩點。我們對於以關聯形式儲存資料的優雅和簡潔性印象深刻，也看出在關聯模式中，多數的查詢能夠更容易的表達。在座談會後，Ray與我開始投入我們自創的「查詢遊戲」挑戰彼此，以設計擁有充分彈性、能表達更多種查詢類型的語言為目標。

1973年，Codd的傑出構想獲得肯定，IBM決定在Codd領軍的研究實驗室地點，聖荷西市，鞏固強化公司的資料庫研究，並且計畫開發一個產業適用的系統原型作為關聯模式的驗證，稱為System R。Ray Boyce與我，以及幾位來自約克鎮和劍橋的IBM資料庫研究人員，搬到加州，加入System R專案團隊。因為Ray與我對程式語言有興趣，我們的第一個任務是設計查詢語言，作為操作System R的使用者介面。在學習、研究Codd和其他研究員提出的關聯式語言之後，我們設定下列工作目標：

‧我們想設計一種基於英文關鍵字的查詢語言，容易在鍵盤上輸入。我們希望語言以熟悉的概念為基礎，如：擁有行與列的資料表格。如同Codd原始的語言計劃書，我們希望語言是容易陳述的，而不是程序性的。我們想要借重關聯模式的力量，但同時避免某些艱澀的數學概念和術語，例如Codd早期論文中的通用量詞與關聯除法運算。我們也想納入某些高階的查詢概念，例如：分群，這類我們認為不是很容易在其他關聯式語言中表達的概念。

‧除了查詢之外，我們希望語言能提供其他功能。最顯而易見的擴充功能是加入新增、刪除、和更新資料的操作。此外，強調某些傳統上需由資料庫管理者處理的任務，例如：創造新的資料表和視觀表、控制資料存取權限、與界定限制和觸發器等，希望這方面所有的任務皆能按照統一的語言句法架構完成；因此，授權的使用者能自行進行管理任務，例如定義新的資料視觀表，而不須要停止系統並啟動特別的工具來執行。換言之，我們視查詢、更新、管理資料庫為語言的不同層面；因為我們的使用者從零開始建立關聯式資料庫，而且沒有先前版本相容性的限制，我們在開發上擁有獨特的機會。

‧我們希望語言的用途，能同時兼顧決策使用的單一查詢語言，與更複雜應用的開發語言。後者的目標需要找到介面的設計方法，讓我們的新語言能適用於多樣化的應用程式語言。

根據我們早期挑戰自創的「查詢遊戲」經驗，Ray與我將開發初期的關聯式查詢語言命名為SEQUEL，並於1954年5月在ACM SIGFIDET（SIGMOD的前身）年會發表一篇十六頁的論文。不幸的是，發表論文後沒多久，Ray Boyce突然因為腦動脈瘤而過世。

發表初版的 SEQUEL論文後，從1974年到1979年，SEQUEL歷經驗證和改善的階段。在這段期間，SEQUEL曾在IBM聖荷西研究實驗室參與部分實驗性 System R資料庫專案的執行工作；System R研究資料庫管理的不同面向，包括：B-tree索引、聯結方法、成本為基礎的優化，與交易一致性等。這些執行經驗對語言的設計演進提供許多回饋資訊。此外，SEQUEL也同時深受三家安裝 System R原型的 IBM企業客戶使用意見影響；System R團隊每季與顧客群開會一次，雙方針對改善語言及其執行的方法進行討論。

SEQUEL語言在參與 System R專案期間的演進十分顯著：為避免商標侵權爭議，語言的名字從 SEQUEL縮短為 SQL；在初版中缺席的通用聯結功能，也已增補；改善分群的功能，並且透過新增 Having子句來過濾分群；為了處理遺失資訊，將null數值與三值邏輯加入語言。另外加入一些新類型的邏輯謂語，包括：Like指部分內容相符；Exists指非空的子查詢。後續發表的幾篇論文則記錄語言演進的過程。在語言設計過程的階段，主要的決策傾向實用性，同時依據我們執行的經驗與實驗客戶的需求而調整。

SQL在 IBM的研究階段，隨著System R專案的完成，於 1979年宣告結束。接著，語言發展的責任移交至開發團隊，將 System R原型轉變升級為 IBM多樣化平台的商用產品。

然而，以 SQL為基礎的第一個商用產品 Oracle，是由一家名為Relational Software的小公司於 1979年推出，而不是 IBM。後來，產品的名稱 Oracle取代公司的名稱，而且那家公司現在的規模已不可同日而語。 Oracle的產品很快就成為各個 SQL執行的公司仿效追隨的對象，包括 IBM和其他主要資料庫廠商。 SQL現在已成為世界上最廣為使用的資料庫
查詢語言。

為了提倡各種 SQL執行應用的可攜性，美國國家標準協會（ANSI）著手制定 SQL標準規格的專案，稱為資料庫語言 SQL，並且於 1986年將結果制定成為 ANSI標準；也於 1987成為世界標準組織（ISO）的標準。當新功能陸續加入 SQL，以實現改變中的需求時，SQL的標準化儼然成為SQL持續演進的重心； SQL的更新版本陸續於1989年、1992年、1999年、2003年，和2006年由 ISO發表。

Adin Falkoff與 Ken Iverson合作創造APL，他們的作品與您的 SQL類似，兩者皆源自嚴格定義的模式表達。形式主義，體現於 Iverson的數學標記或 Ted Codd的關聯模式，是否對於創造成功的程式語言有助益呢？

Don：我認為關聯資料模式是SQL設計的基礎，任何計算確定性結果的程式語言都需要一系列定義清楚的物件和運算子，或許可稱為形式資料模式；這是確定性最優化程式設計的基礎。

即使像 Python那一類型的鬆散型別語言（loosely typedy languages），你會發現它們仍擁有定義明確的資料模式；它比關聯模式更有彈性，但是必須定義清楚，才能作為語言語義的
基礎。

如果由我創造新語言，您會推薦我從嚴謹的資料模式開始，或是逐步翻新改進舊語言？

Don：原則上，我認為兩種途徑都可行，但是你不可能同時擁有設計新資料模式與定義新語言的彈性。例如，XQuery的設計者並未從事發明 XML的工作－－他們必須處理 XML Schema已經定義的資料模式與其他的 W3C標準。