我從Icon程式語言中所學到的

伯樂線上注：英文原文：格倫•範登伯格，感謝@dryrun 的熱心翻譯。如果其他朋友也有不錯的原創或譯文，可以嘗試推薦給伯樂線上。以下是譯文。

 

在20世紀70年代末和80年代初期，Icon 程式語言主要由拉爾夫•格里斯沃爾德（Ralph Griswold）所設計的。在60年代，格里斯沃爾德負責過第一個專門用於處理文字的程式語言 ――Snobol（String Orientated Symbolic Language）。Icon是基於Snobol思想而設計的下一代語言，然而它更加統一和完整。

在很多方面﹐Icon是第一個“指令碼語言”。它是一種非常高階別，具備出色的能力去處理文字資料並與其環境相結合的語言。迄今為止，它都是如此超前，這也許是它從沒有很流行的一個原因。早在Perl和TCL（這些語言開啟了指令碼語言的熱潮）崛起之前好幾年，它就已經出現了。

對於一個泡在BASIC、Fortran、PL/I、Pascal和C裡成長起來的人，Icon就是個徹頭徹尾的異類。然而它教會了我許多至今都很有用的東西。

 

空集（Nullology）

當你呼叫一個Icon函式，它會做以下兩件事之一：它可以返回一個值，或者它會失效。失效聽上去類似於現代的異常處理機制，但是Icon的失效有以下幾個不同。首先，當一個Icon函式失效時，沒有指標說明它為什麼失效。再者，失效是預期的。它總在發生，而且是Icon工作方式的一個重要部分。（它有一個單獨的、原始的、針對真正異常條件的錯誤處理機制。）

許多Icon的函式都是生成器（generator）――它們可以返回多個值。在某些情況下，Icon將持續呼叫該函式直到它失效。所以在Icon裡，失效真正的意思是“沒有更多的值”。例如，下面是一個完整的Icon程式，把它的輸入複製到它的輸出：

子句Every表示“這樣做直到它失效”。write()把它的引數寫到標準輸出，read()從標準輸入返回連續的行，最終在達到檔案結束時失效。

在C語言裡，失效通常被一些特殊保留的返回值，或者其他特設機制所表示（那些失效指標都太容易被遺漏）。直接從C轉到Icon後，上面那個小程式驚醒了我，讓我見識到了簡潔、傳神的美感。

 

第一課

重要的是去區分有和沒有。或者是一個函式的返回值，或者是一個變數的值，重要的是要能說“沒有一個”。

這一課幫我在幾年後認識到異常，也使我領會到其它語言，例如Lisp, Smalltalk, Ruby和（在某種程度上）Java，它們的變數包含可以為空的引用，而不是直接儲存資料。

 

一致性（Uniformity）

Icon是第一個讓我用表示式語言做嚴肅工作的語言。也就是說，Icon沒有語句，只有包含結果值的表示式。我第一次看到這個：

起初我真的很困惑，但很快我就明白是怎麼回事。在Icon裡，我所用來思考的“if語句”事實上只是一個“if表示式”，就像在別處一樣，它會有一個結果值。為什麼不應該呢？我曾經思考過這個問題，語句和我所熟悉的語言裡的表示式之間的區別好像是人為的和任意的。進一步使用Icon的經歷證明了這一點。這當然可能造成濫用構造，產生費解的程式碼。但是有時它們正是你做正確的事情所需要的。

 

第二課

通常情況下，你認為根本不相同的事情事實上完全相同。不要想當然認為你在某處學到的就是普遍真理。

這麼多年來，這一課幫助我用許多新東西迅速武裝我的頭腦，包括語言，工具，程式設計正規化和平臺。

 

事實（Truth）

我已經提到了生成器和失效的語義。然而一旦你有可以返回多個值甚至失效的表示式，就出現一個問題­――類似 E1 | E2 這樣的表示式是什麼意思？在多個值有意義的上下文，你可能需要一個定義；但是在傳統環境下，你可能需要一個不同的。所以看起來熟悉的結構就像人們所習慣的。我不會討論細節（畢竟這不是一節Icon課），但是Icon設計師們能夠找到一個能工作在傳統結構和新結構兩種情況下的表示式，Icon思路共存，沒有特殊情況。所以，你可以做所有這些事情：

並且它們實現你所期待的。在上例中，“|”像一個連線操作符，結果是連線那三個檔案。但是操作符的實際語義是不變的――所有這三個例子使用單一的“|”定義，結合生成器，表示式失效和目標導向評估。

 

第三課

我們所受的關於程式設計的教育正如我們所學的科學――很方便想到世界是如何真正運轉，但事實是我們就是不知道。科學給予我們的是似乎能解釋世界的理論，因為它們符合所有我們所能想到的實驗。但是隨著我們對世界的瞭解不斷擴大，遲早我們會認識到之前的理論只是一個近似。一旦事情變得足夠快，足夠大，牛頓是不夠的，我們需要愛因斯坦。（然後它們變得足夠小，我們就需要普朗克和波爾）。單值函式，布林邏輯是足夠的，但當把生成器投向混合後，你就需要更多地東西。

這節課已經幫了我很多次去處理複雜、混亂、有時前矛後盾的商業規則和需求。受Icon例子的啟發，我經常成功找到更深、更簡單、更普遍的規則，能作為純粹的變化支援所有表面的合併。

 

表達（Representation）

當遇到Icon時，我還是一個Unix使用者，我已經相當精通用作文字模式的正規表示式。Icon有一種極其複雜的文字模式機制，不是基於正規表示式，但是實際上更強大。（經過Perl 6幾層經典正規表示式新增，Perl的正規表示式最終實現了威力相當於Icon模式的功能。但那是另一個故事了。）

語言和協議往往用看起來像簡單的算數表示式的語法來描述：

（僅支援變數x, y和z的加法和乘法。）

儘管很強大，但不可能實現一個像使用經典的正規表示式那樣的語法解析器。（如果你以某種方式成功，也將會非常困難去維護和擴充套件該解析器。）

但是使用Icon的可程式設計模式機制，你可以實現這樣的解析器：

哇！這看起來就像語法！事實上會真的很容易去用語法編寫程式以生成解析器！

你可以這樣呼叫它：

Icon裡的yacc是一個為期一天的黑客。

 

第四課

語法很重要。如果語法適合問題域（problem domain），程式則很容易理解。這就是為什麼如果一種語言要很好的處理繁雜的資料時，即使它是一個危險的語言功能、容易被濫用，但操作符過載是必不可少的。強大的正規表示式看上去就像“正規表示式”。

這一課讓我知道什麼時候去寫一點特定領域語言，而不是試圖擠入我現有語言的領域。（通常這是一個很容易的事情。）它把我推向動態的、可塑的語言，如Ruby（我敢說還有Lisp）更主流的東西。

（語法很重要這一課也大大加強――但以消極的方式――在每次我使用XSLT時。幸運的是，很快我就能使用XQuery去做所有現在得用XSLT去做的工作。）

(全文完)

 

英文原文：Glenn Vanderburg，感謝@dryrun 的翻譯

譯文連結：http://blog.jobbole.com/42136/

【非特殊說明，轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】