題外：從老家從早到晚總算折騰回了杭州，進站太早，火車晚點，提包帶斷，什么倒霉事也遇上了，先發(fā)個已經(jīng)整理好的部分，后續(xù)仍待整理。
多道程序設(shè)計：分離進程為獨立的功能
無論在協(xié)作進程還是在同一進程的協(xié)作子過程層面上，Unix設(shè)計風(fēng)格都運用“做單件事并做好的方法“，強調(diào)用定義良好的進程間通信或共享文件來連通小型進程，提倡將程序分解為更簡單的子進程，并專注考慮這些子進程間的接口，這至少需要通過以下三種方法來實現(xiàn)：
1、降低進程生成的開銷(思考下Erlang的process)
2、提供方法（shellout、IO重定向、管道、消息傳遞和socket）簡化進程間通信
3、提倡使用能由管道和socket傳遞的簡單、透明的文本數(shù)據(jù)格式
Unix IPC方法的分類：
1、將任務(wù)轉(zhuǎn)給專門程序，如system(3)，popen調(diào)用等，稱為shellout
2、Pipe、重定向和過濾器，如bc和dc
3、包裝器，隱藏shell管線的復(fù)雜細節(jié)。
4、安全包裝器和Bernstein鏈
5、主/從進程
6、對等進程間通信：
(1)臨時文件
(2)信號
(3)系統(tǒng)守護程序和常規(guī)信號
(4)socket
(5)共享內(nèi)存，mmap
遠程過程調(diào)用(RPC)的缺憾：
1、RPC接口很難做到可顯，如果不編寫和被監(jiān)控程序同樣復(fù)雜的專用工具，也難以監(jiān)控程序的行為。RPC接口和庫一樣具有版本不兼容的問題，由于是分布式的，因此更難被追查。
2、類型標(biāo)記越豐富的接口往往越復(fù)雜，因而越脆弱。隨著時間的推移，由于在接口之間傳遞的類型總量逐漸變大，單個類型越來越復(fù)雜，這些接口往往產(chǎn)生類型本體蠕變問題。這是因為接口比字符串更容易失配；如果兩端程序的本體不能正確匹配，要讓它們通信肯定很難，糾錯更是難上加難。
3、支持RPC的常見理由是它比文本流方法允許“更豐富”的接口，但是接口的功能之一就是充當(dāng)阻隔點，防止模塊的實現(xiàn)細節(jié)彼此泄漏，因此，支持RPC的主要理由同時恰恰證明了RPC增加而不是降低了程序的全局復(fù)雜度。
Unix傳統(tǒng)強烈贊成透明、可顯的接口，這是unix文化不斷堅持文本協(xié)議IPC的動力。
ESR在這里還談到XML-RPC和SOAP等協(xié)議，認(rèn)為是RPC和unix對文本流支持的一種融合，遺憾的是SOAP本身也成為一種重量級、不那么透明的協(xié)議了，盡管它也是文本協(xié)議。
線程是有害的：
線程是那些進程生成昂貴、IPC功能薄弱的操作系統(tǒng)所特有的概念。
盡管線程通常具有獨立的局部變量棧，它們卻共享同一個全局內(nèi)存，在這個共享地址空間管理競爭和臨界區(qū)的任務(wù)相當(dāng)困難，而且成為增加整體復(fù)雜度和滋生bug的溫床。除了普通的競爭問題之外，還產(chǎn)生了一類新問題：時序依賴。
當(dāng)工具的作用不是控制而是增加復(fù)雜度的時候，最好扔掉從零開始。
微型語言：尋找歌唱的樂符
（注，這里談的微型語言，就是現(xiàn)在比較熱門的詞匯DSL）
對軟件錯誤模式進行的大量研究得出的一個最一致的結(jié)論是，程序員每百行程序出錯率和所使用的編程語言在很大程度上是無關(guān)的。更高級的語言可以用更少的行數(shù)完成更多的任務(wù)，也意味著更少的bug。
防御設(shè)計不良微型語言的唯一方法是知道如何設(shè)計一個好的微型語言。
語言分類法：
對微型語言的功能測試：不讀手冊可以編寫嗎？
現(xiàn)代微型語言，要么就完全通用而不緊湊，要么就非常不通用而緊湊；不通用也不緊湊的語言則完全沒有競爭力。
一些引申想法：我認(rèn)為這個評判標(biāo)準(zhǔn)也可以用在任何編程語言上，以此來判斷一些語言，C語言既通用又緊湊，Java是通用而不緊湊，ruby、Python之類的腳本語言也是如此，正則表達式（如果也算語言的話）是不通用而緊湊，Erlang也是通用而緊湊，awk卻是既不通用也不緊湊，XSLT也可以歸入不通用不緊湊的行列；Javascript是個另類，按理說它也是不通用不緊湊，說它不通用是因為它的主要應(yīng)用范圍還是局限在web開發(fā)的UI上，實際上Javascript也是門通用語言,但是很少會有人會用javascript去寫批處理腳本,Javascript顯然是不緊湊的，太多的邊邊角角甚至奇奇怪怪的東西需要你去注意，然而就是這樣一門不通用不緊湊的語言現(xiàn)在卻非常有前途，只能說時勢所然。
設(shè)計微型語言：
1、選擇正確的復(fù)雜度，要的是數(shù)據(jù)文件格式，還是微型語言？
2、擴展和嵌入語言
3、編寫自定義語法，yacc和lex
4、慎用宏，宏的主要問題是濫用帶來的奇怪、不透明的代碼，以及對錯誤診斷的擾亂。
5、語言還是應(yīng)用協(xié)議。