想要进行的讨论源自王垠的博文: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解释器)?