>>>  讀書—連接古今充實信仰  >>>

簡體     傳統

九 源自Fetchmail的更多經驗
在我們回到廣義的軟件工程問題之前，還有幾條fetchmail開發中的獨特細節需要深思。非技術性的讀者可以安心跳過本章。
rc（fetchmail用戶配置）文件語法中包含了一些完全不需解析的，可選的“噪音”關鍵詞。與傳統“關鍵詞-對應值”匹配關系相比，它們所帶來的趨近于英語語法的配置文件更具可讀性。
這源自一個深夜的實驗，當時我注意到rc文件的配置命令非常像一門微型指令語言。（這也是我把關鍵字“server”改成“poll”的原因）[1]
在我看來，努力使這個微型指令語言更像英語可以讓其更便于使用。現在我雖然支持“讓它成為一門語言（make it a language）”的設計流派（諸如Emacs、HTML和很多數據庫引擎那樣），但是并不熱衷于“類英語”的語法。
傳統上，程序員們傾向選用簡潔緊湊、完全沒有冗余的語法。這是計算資源昂貴時期的文化遺留，以致解析過程必須盡可能的簡潔廉價。所以如果采用像英語這樣有50%冗余的語法建模，在當時顯然是很不合時宜的。
這并不是我通常避免使用“類英語”語法的原因。我在這里提及就是為了打破這種觀點。有了更廉價的緩存和處理器，簡潔就沒有必要稱為最終的追求了。現在一門語言的人性化遠比降低計算成本要重要。
然而，我們仍然有要謹慎為之的原因。其一就是解析過程的復雜度帶來的成本——你總不希望這個成本上升到足以滋養錯誤和迷惑用戶吧？另外，讓一門語法趨近英語的作法，通常會令其所謂的“英語”走形。以至于對自然語言的表面的模仿會導致如同傳統語法一般的混亂。（你可以在很多號稱“第四代”的和商業數據庫查詢語言中看到這種惡果）
Fetchmail的控制語法之所以能避免這些問題，是因為它的語言空間極為有限。它離一門多用途的語言還差得遠呢；其所描述的問題也很簡單。所以大可不担心穿梭于微小的英語子集和實際控制語言會造成什么迷惑。我覺得這里有一則可以推而廣之的經驗：
 
16.當你的語言還遠不足以達到圖靈完備的時候，不妨為語法蘸上一層“糖衣”。[2]
When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
 
另一則經驗是有關隱藏的安全性的。一些用戶要求我改寫軟件，以便能對rc文件加密。這樣入侵者就不會在無意間看到它們。
我沒有照做，因為這并不會帶來實際的保護。因為只要有人能獲得你rc文件的使用權，他就能和你一樣運行fetchmail查看郵件——如果真的想要你的密碼，他就可以從fetchmail代碼中剝離出必要的解碼器。
言而總之，在rc文件中注入密碼只是給那些沒有深入思考的人一種安全的假象。進而，我們得出通用的規則：
 
17.安全系統的效用只取決于對秘密的保護，謹防偽安全。[3]
A security system is only as secure as its secret. Beware of pseudo-secrets.

譯者按：
1.這個關鍵字后面對應的是郵件服務器名稱。計算機中，“Poll”是動詞“輪詢”的意思，也就是依次向服務器發送報文，收取郵件。而“Server”是名詞“服務器”。顯然使用“Poll”更符合英語語法。
2.圖靈完備：又稱圖靈完備性。如果一門語言達到“令一切可計算的問題都能計算”的程度就可以說其達到了圖靈完備或說具有圖靈完備性。
3.“秘密”是指所要隱藏的標的；“安全系統”是指保護這個標的不泄露的手段；“偽安全”是指將標的寫入手段的做法。讓我們以fetchmail為例，“秘密”就是要保護rc文件，“安全系統”就是密碼，把密碼寫入rc文件顯然就是偽安全。

埃里克.斯蒂芬.雷蒙 2014-07-01 18:21:53