《Unix程式設計藝術》重讀筆記(三)多道程式設計：分離程序為獨立的功能微型語言：尋找歌唱的樂符

題外：從老家從早到晚總算折騰回了杭州，進站太早，火車晚點，提包帶斷，什麼倒黴事也遇上了，先發個已經整理好的部分，後續仍待整理。

無論在協作程序還是在同一程序的協作子過程層面上，unix設計風格都運用“做單件事并做好的方法“，強調用定義良好的程序間通信或共享檔案來連通小型程序，提倡将程式分解為更簡單的子程序，并專注考慮這些子程序間的接口，這至少需要通過以下三種方法來實作：

2、提供方法（shellout、io重定向、管道、消息傳遞和socket）簡化程序間通信

3、提倡使用能由管道和socket傳遞的簡單、透明的文本資料格式

unix ipc方法的分類：

1、将任務轉給專門程式，如system(3)，popen調用等，稱為shellout

2、pipe、重定向和過濾器，如bc和dc

3、包裝器，隐藏shell管線的複雜細節。

4、安全包裝器和bernstein鍊

5、主/從程序

6、對等程序間通信：

(1)臨時檔案

(2)信号

(3)系統守護程式和正常信号

(4)socket

(5)共享記憶體，mmap

遠端過程調用(rpc)的缺憾：

1、rpc接口很難做到可顯，如果不編寫和被監控程式同樣複雜的專用工具，也難以監控程式的行為。rpc接口和庫一樣具有版本不相容的問題，由于是分布式的，是以更難被追查。

2、類型标記越豐富的接口往往越複雜，因而越脆弱。随着時間的推移，由于在接口之間傳遞的類型總量逐漸變大，單個類型越來越複雜，這些接口往往産生類型本體蠕變問題。這是因為接口比字元串更容易失配；如果兩端程式的本體不能正确比對，要讓它們通信肯定很難，糾錯更是難上加難。

3、支援rpc的常見理由是它比文本流方法允許“更豐富”的接口，但是接口的功能之一就是充當阻隔點，防止子產品的實作細節彼此洩漏，是以，支援rpc的主要理由同時恰恰證明了rpc增加而不是降低了程式的全局複雜度。

unix傳統強烈贊成透明、可顯的接口，這是unix文化不斷堅持文本協定ipc的動力。

esr在這裡還談到xml-rpc和soap等協定，認為是rpc和unix對文本流支援的一種融合，遺憾的是soap本身也成為一種重量級、不那麼透明的協定了，盡管它也是文本協定。

線程是有害的：

線程是那些程序生成昂貴、ipc功能薄弱的作業系統所特有的概念。

盡管線程通常具有獨立的局部變量棧，它們卻共享同一個全局記憶體，在這個共享位址空間管理競争和臨界區的任務相當困難，而且成為增加整體複雜度和滋生bug的溫床。除了普通的競争問題之外，還産生了一類新問題：時序依賴。

當工具的作用不是控制而是增加複雜度的時候，最好扔掉從零開始。

（注，這裡談的微型語言，就是現在比較熱門的詞彙dsl）

對軟體錯誤模式進行的大量研究得出的一個最一緻的結論是，程式員每百行程式出錯率和所使用的程式設計語言在很大程度上是無關的。更進階的語言可以用更少的行數完成更多的任務，也意味着更少的bug。

防禦設計不良微型語言的唯一方法是知道如何設計一個好的微型語言。

語言分類法：

對微型語言的功能測試：不讀手冊可以編寫嗎？

現代微型語言，要麼就完全通用而不緊湊，要麼就非常不通用而緊湊；不通用也不緊湊的語言則完全沒有競争力。

設計微型語言：

1、選擇正确的複雜度，要的是資料檔案格式，還是微型語言？

2、擴充和嵌入語言

3、編寫自定義文法，yacc和lex

4、慎用宏，宏的主要問題是濫用帶來的奇怪、不透明的代碼，以及對錯誤診斷的擾亂。

5、語言還是應用協定

<b>文章轉自莊周夢蝶  ，原文釋出時間</b> 2010-02-22