[討論] 文字流介面：得與失兼其它

想要進行的討論源自王垠的博文：Unix的缺陷。
其核心觀點是“文字流不是可靠的介面”，換言之，“採用文字流作為資訊交換協議暗藏隱患”。
下面整理一下我個人的理解脈絡和觀點，提出來供討論。

[原點] UNIX為何要採用文字流作為介面？
一個合理解釋是，UNIX是一個“原型系統”，或“第一版系統”。其初始設計目的並非為了投入生產環境使用，而是為了探索新的系統設計思想、驗證可行性，並通過實踐修正設計錯誤。基於這一理念和需求，使用文字流作為介面無疑比二進位制位元流更具優勢，體現在1）無需專用編解碼工具，2）隨時可讀可寫，3）具備天然的跨平臺移植性。

1)大部分時候，無需專用編解碼工具可以節約相當多的時間成本，因為“不需要存在的程式碼就是好程式碼”。通過複用Shell與各種現成的文字處理工具，可以很便利地達成這一目的。只不過，這種方式適用於“搭建原型、驗證可行性”更多一些，畢竟試驗差錯可以容忍，正是這一點使得UNIX易於定製，最終演變成了生產環境（不會有人想去改動一個工作中的系統，對吧？）。

2)隨時可讀可寫也是需要著重考慮的一個方面。只著眼於是否人類可讀，而不著眼於是否人類可寫，有失偏頗。事實上寫文字流可能比讀文字流更重要，畢竟一個系統在設計之初不可能面面俱到，所有後續變更與修改都要通過寫新程式碼、新資料來達成。讓所有編輯工具都支援結構化資料並非不可能，只是成本會相當的高，後文會再展開這一點。如果輸入不夠簡潔明瞭，使用再好的工具都將只是徒增疲勞。下面試舉一例：

[代詞]我 [動詞]想 [量詞]這篇 [名詞]文章 [動詞]不是 [副詞]有點 [動詞]扯淡 [連線詞]而是 [副詞]有點 [名詞]理想主義 [標點]。

3)具備天然的跨平臺移植性，這一點的重要性無需多言。文字流表示極少涉及位元組序、字長之類與硬體細節相關的特定知識，僅僅表達人類共同理解的意義。如果使用二進位制位元流，要達到相同的便利性可能代價非常高。可供參考的一個例子是X Window協議與HTTP協議。

[逆向思考] 如果採用標準的結構化文字或者資料結構本身……
現在反過來看看，如果採用標準的結構化文字，或者資料結構本身，需要什麼樣的投入，會有什麼樣的產出，以及帶來什麼樣的新問題。

“標準”是否意味著需要建立一個委員會來討論哪些功能或特性需要加入到這一介面中？標準確立後進行功能增減、修訂、再發布是否容易？是否會帶來版本依賴問題？
“標準”是否意味著需要建立一套公用函式庫？誰來負責開發和維護？誰來負責編寫文件和手冊？誰來保證每個釋出版的可用性？釋出版是否跟得上標準的演進速度？是否會帶來版本依賴問題？

“結構化”是否能帶來切實好處？會不會影響人眼閱讀和手寫的效率？是否足夠通用？是否可以在本地擴充套件語義，同時能透明地穿越不支援這些語義的其它程式或工具？

兩個典型例子是XML與JSON。前者是個悲劇，後者也有悲劇化的趨勢，但不管怎樣兩者都是權衡與妥協的產物。

“（二進位制的）資料結構”是跨語言的嗎？如果要跨語言支援，需要付出什麼代價？是否具備跨平臺可移植性？是否易於理解？是否易於臨時修改？是否在概念上是統一的？（Perl裡叫雜湊表，Python裡叫詞典，Ruby裡又叫雜湊表，AWK裡叫關聯陣列……對了，Java裡沒有原生對應物：）

[例項] LISP裡的巨集
LISP裡的巨集是一種用於臨時定義某種“習慣用法”的便利工具。不需要提交委員會修訂，不需要跟所有程式設計師溝通協定。僅僅需要接手的人懂得相同的LISP語法就可以理解（這一點的人力成本很高得離譜）。它是文字化的，結構化的，未經語法糖包裝的，“不自然的”，形式化的，天然有專用編解碼工具支援的一種本地協議。但它某種程度上並非可移植的資料結構，而且（沒有良好的工具支援時）編寫起來有點繁瑣。

[個人觀點] 文字流介面：得與失兼其它
其實我覺得只要考慮以下幾個問題就好了：
1. 學習成本高嗎？是否一次投入學習成本能收穫多次使用效益？
2. 理解成本高嗎？是否需要額外的文件輔助理解？
3. 修正成本高嗎？是否需要很多操作（編解碼、格式轉換）才能達成目的？
4. 替代成本高嗎？是否總有其它可選工具替代使用（比如更換成Ruby SH或者LISP的REPL直譯器）？