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

多道程序設計：分離進程為獨立的功能

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

1、降低進程生成的開銷(思考下Erlang的process)

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。

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

語言分類法：

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

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

一些引申想法：我認為這個評判標準也可以用在任何編程語言上，以此來判斷一些語言，C語言既通用又緊湊，Java是通用而不緊湊，ruby、Python之類的腳本語言也是如此，正則表達式（如果也算語言的話）是不通用而緊湊，Erlang也是通用而緊湊，awk卻是既不通用也不緊湊，XSLT也可以歸入不通用不緊湊的行列；Javascript是個另類，按理說它也是不通用不緊湊，說它不通用是因為它的主要應用范圍還是局限在web開發的UI上，實際上Javascript也是門通用語言,但是很少會有人會用javascript去寫批處理腳本,Javascript顯然是不緊湊的，太多的邊邊角角甚至奇奇怪怪的東西需要你去注意，然而就是這樣一門不通用不緊湊的語言現在卻非常有前途，只能說時勢所然。

設計微型語言：

1、選擇正確的復雜度，要的是數據文件格式，還是微型語言？

2、擴展和嵌入語言

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

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

5、語言還是應用協議。