程式設計語言與自然語言

轉載請註明出處:http://blog.csdn.net/horkychen

 

程式設計語言的發展和自然語言是相似的，根本上都是以滿足溝通需求為驅動力的。其中也不乏溝通的障礙，這裡做個簡單的探討！

 

1. 語言是什麼

語言是溝通工具，是為了交流資訊而產生的。(語言套件含說和寫兩個方面，這裡主要探討寫。)

 

從結繩記事到現代語言，語言(包含文字)的每一次變革都是為了促進交流而進行的。最初是不需要語言和文字的，沒東西可記。 再後來，打到的獵物多了，有些東西需要記下來，以便總結經驗，所以在草繩打結表示一下。這就像二進位的機器碼。打個結表示1，沒有結為0。在一條繩上打結和以前在紙帶上打孔是多麼的相似。
 

後來，物質豐富起來，部落間的交流產生許了問題，可能需記下禮尚往來，甚至戰事等事情，打結肯定會把人搞糊塗了。於是聰明的人類發明了表意字元。表意字元是少數人的專利，而且不通用。這就像是組合語言，各系統下的指令集不同。他們有個共同特點，難讀！當然也有牛人至人仍對使用組合語言寫程式而津津樂道，也正說明那是少數人的專利。

 

繼續發展，要記錄的事情越來越多，人與人的交流也日益密切，表達方式越來越豐富。紙和印刷術的出現促進了文字的發展，文言文的推廣，都大大促進了語言的發展。這個階段相似於進階語言出現的時代，如C/Fortran等等。但是整篇之乎者也的文言文和日常生活太遠，所以到近代又開始出白話文，因為這更接近於人的日常思維。對應的Java/C++的時代來臨了。

（OOP更加切合人的思維習慣，最明顯的例子就是社會分工細化後，人格獨立、契約精神等就成了自然而然的事情。這些內容都被體現到了程式設計語言的發展上了。）

 

如果現在朋友聚會，你站出來要給大家默誦一篇《如夢令》，要麼被令人仰慕，要麼被人鄙視。但一見面就要來一篇，那肯定只有鄙視了。因為這已經不是良好的溝通方式了。聽眾的需求決定了你應該怎麼說話。而寫代碼時，強調編碼通訊協定是不是也一種需求？

 

經我這麼一拉扯，程式設計語言和自然語言就變得十分相似了，本質上都是為溝通服務的，只不過前者的溝通存在兩個構面：人與機，人與人。所以編程語和自然語言就將現實世界和軟體世界串連起來了，也等同數學符號的作用。

 

2. 語言的溝通難題

既然是溝通，就一定存在溝而不通的障礙。

a. 語言差異

首當其衝的就是語言間的差異。語言不通就找個翻譯嘛！所以軟體世界裡就有了各式的代理、IPC等等。為了達到同聲翻譯，就有了混編。

 

b. 方言

日常生活中遇到的方言的問題，在程式設計語言的世界裡也時有發生。下面是我以前工作中遇到一個資料庫欄位名稱，以拼音縮寫命名：

  [CJSJ]

你能猜到這是出勤時間(ChuQinShiJian)的縮寫嗎? 這樣的欄位還很多，我一直很困惑！後來終於發現原來系統的第一開發人員是個四川人。

 

c. 混編

現在在口語中將中文與英文"混編"的人越來越多，特別是IT男。這在程式設計語言裡也是很常見。再舉資料庫建表的例子(因為表與商務邏輯的對應關係導致它是高發地區)：

CREATE TABLE [dbo].[Doormm] (

  [Bh] [varchar] (3) NOT NULL ,

  [Mc] [varchar] (8) NULL ,

  [Mm] [varchar] (16) NULL ,

  [Manager] [bit] NULL ,

  [Report] [bit] NULL ,

  [QzPass] [bit] NULL

) ON [PRIMARY]

 

初看，你一定是覺得和門(Door)有關係，裡面還有經理(Manager)。第一個欄位應該是BianHao，來作主鍵的。

……

不猜了！ 這個表的功能只有開發人員才知道了。

 
d. 領域中專業詞彙

另外在聚會時還會有所謂共同語言的問題，舉個例子，下面這個笑話我婆看完後覺得很無聊：

某兩程式員夫妻新婚,一年之後喜得貴子,起名“靈靈”；又過一年又得一女，起名“靈伊”；兩年之後得子“伊靈”；複過兩年，夫妻商定為得圓滿最後再生一子，取名“伊伊”。不料產檢發現所懷的乃是雙胞胎，夫欲減胎，妻不允，冥思許久，對夫曰：“老五就叫‘憶初’吧”……

不懂這些專業名詞，顯然不知所云。這就是領域知識的專業詞彙構成的障礙。再比如，一般都知道"Subject"是"主題"或"科目"的意思，但在統計學裡面，它還有"受測試者"的意思。面對函數arrangeSubject()是不是很難"望文生義"呢?

 

e. 文法

最後，是文法問題。有人說話簡潔清晰，有人則囉囉嗦嗦讓人不知所云。還有一種覺得實在不知道怎麼說，那就不說了。這叫一言難盡！ 寫文章也一樣， 好的文章看起來行雲流水，很順暢！當然也有文章出現“此處省略500字！”！

把說不清楚的說清楚是科學，把不好說的說好是文學。關鍵是一個組織圖的問題。對應程式設計語言的世界裡，這相關的詞很多：結構化、設計、層次、抽象…… 

我們來對比一下HelloWorld 和 一篇日記:

HelloWorld.cpp int main(int argc, char *argv[]) {    int i=0;    printf(" Hello, World! [%d]\n",i);    Do something else......    return 0; }

早上，xxxxxxxx 協助老大爺過馬路 xxxxxxxx 啊，真是快樂的一天！

 

結構上都有三個部分：

  i. 交待條件

  ii. 發現些一些事情

  iii. 收尾，返回

 

 

結論：

Beck在<<實作模式>>中提倡的編碼三個價值觀：溝通、簡潔和靈活。也確實很有道理。

 

把寫代碼當成寫作，先求有再求好，然後思考別人看My Code能看懂嗎？有幾個簡單Tips:

a. 由上及下細化，

  也就是寫作時先有大綱的做法。

 比如上班路上，思路可以簡化為:下樓，坐車，步行到公司。然後再細化一些細節，對重要的地方，再加以修飾。

 

  思維導圖之所以受到重視，正因為它順應了人的這種思維習慣。

 

b.學英語，抓關鍵字

當你看到一個詞的時候，一定要想到它背後的知識圖譜。就像Google推出的這個功能(LINK)。可以使用思維導圖的方式記錄下來，形成一個系統，非常有利於知識的掌握。

 

在國內，英文書的翻譯經常可以看到有若干人。以趕工的方式，每人分一兩章就開工了，然後起個驚世駭俗的名字就拿出來賣了。結果下來，翻出來書自然品質不高，更不用說能系統一點了。詳細的討論可以看這篇(程式員談如何掌握電腦英語)。

 

平時花些時間學英語，盡量用英語來捕捉最新的資料，以免被誤導。

 

c. 注重實踐細節
 養成好的命名與注釋的習慣很重要。特別是注釋，如果描述的不好，甚至沒有和代碼同步，它所造成的困惑可能會很大。這些資訊可以<<代碼大全>>中找到，可以看一下這篇資料(編碼工藝:命名與注釋)。

 *順便提一下<<代碼大全>>和<<程式員修鍊之道>>都是好書，但書名起得實在讓人接受不了!

  寫得有些浮淺，歡迎指正！