王垠最近的一篇文章中，提出了很多有趣的观点。其中最核心的一点，就是 *NIX 系统的设计哲学非常糟糕，而 Windows 系统才是真正为开发者设计的系统。凡是涉及到哲学层面的争论，最后都是以谁也说服不了谁收场。我相信王垠有足够的理由来证明 UNIX 设计哲学的糟糕，但遗憾的是，他的文章并没有表现出这一点。我摘抄一些论点并作答复。

Unix 的 shell，命令，配置方式，图形界面，都是非常糟糕的。每一个新版本的 Ubuntu 都会在图形界面的设计上出现新的错误，让你感觉历史怎么会倒退。但是这只是表面现象。Linux 的图形界面（X window）在本质上几乎是不可治愈的恶疾。

以现在的眼光看，X Windows 是一个设计过于繁复的系统。实际上，20年前出版的 The Unix Haters Handbook 里，就有专门的一章论述为什么 X Window 的 client-server 架构是糟糕的。可是，这和 Ubuntu 的设计演化之间似乎没有太多关联。Ubuntu 所谓的图形界面设计的错误（以 unity 为例），都是桌面环境层面的问题。一个设计师在这个层面犯错误，就像一个画家因为构图不够工整就去怪画布不行一样，之间还相差不少逻辑链条。

X Window 和其他操作系统上的 GUI 系统最大的不同，是它和宿主操作系统的松耦合。因为这种松耦合的存在，在不需要图形界面的地方，操作系统可以不带 X Window。很多云服务的服务器，都是没有 X 的。当下如日中天的移动操作系统如 Android 和 iOS 都是 UNIX 家族操作系统，而这两者都没有用 X Window 提供 GUI 支撑，而是另外开发了一套专门适合触摸式移动设备的图形界面系统。图形系统和操作系统间的松耦合，使得操作系统可以从头搭建适合具体设备的图形界面交互(如 Cocoa Touch)，并且快速的迭代（如 Project Butter）。

在 GUI 和内核的耦合关系上，架构的确决定了产品的形状。我们都知道，微软 NT 内核和 Widnows UI 系统是绑定在一起的。Windows Phone 8 要和 Windows 8 共享内核和其他组件的结果，就是它们都必须兼顾桌面和移动平台。为此，微软做出了两个可以做榔头也能做螺丝刀的东西。一个是 Windows 8，支持触摸屏，Modern UI 界面长得像手机界面；一个是 Windows Phone 8，界面很适合触摸设备，却又同时支持移植来的桌面程序，造成有的程序界面长得像桌面。无论你认为哪个操作系统的图形界面漂亮，哪条路更加有光明的未来，微软的这些系统之间的关系之繁复，开发迭代的周期如此之长，都是客观事实。

UNIX 系统的Unix 的 shell，命令，配置方式的确有不少的问题，在痛恨者手册里也有详细的论述，我以前也写过，就不一一列举了。

Unix 依靠自己的“宗教”和“哲学”，“战胜”了别的系统在设计上的先进，统治了程序员的世界。胜者为王，可是 Unix 其实是一个暴君，它不允许你批评它的错误。它利用其它程序员的舆论压力，让每一个系统设计上的错误，都被说成是用户自己的失误。其它系统里面某些优秀的系统设计，也许就要被历史掩埋……

一个操作系统，是不可能凭着“宗教”和“哲学”就能统治程序员的世界的。程序员不是天主教徒，UNIX 也不是程序员世界的教皇。实际上，所谓的 UNIX 系统，不是一个特定的系统，而是一个家族的系统。这个家族的系统包罗万象。不喜欢微内核的做了宏内核，不喜欢一切还不都是文件的做了 Plan 9, 不喜欢 X Window 慢如蜗牛的做了 XGL 加速。优秀的设计不断地加入这个系统，改造这个系统。UNIX 来源于 Bell 实验室，X Window 却是 MIT 的，BSD 来自于 Berkeley, Solaris 来自于 SUN, Mac OS 来自于 Apple。如果说这里面有宗教的话，这一定是世界上最诡异的宗教，里面的教徒还天天打架。

在 UNIX 系统中，所有的设计，都在开放的环境下竞争。我们可以说 UNIX 不是一个设计良好的系统，但是它的设计哲学在竞争中获胜的原因，不是因为它是“暴君”，控制了程序员的思想，而恰恰是因为它的开放，所以最终汇总了很多优秀的东西。至于 UNIX 这种不怎么好的系统为何最终获胜，20年前的一篇文章也讲得很清楚了。

因为 TeX 的语言是非常糟糕的设计。它的设计者几乎完全不明白程序语言设计的基本原则，不明白什么叫做“抽象”。

而这些源于 Unix 的工具却像是“魔鬼棋”或者“三国杀”，有太多的，无聊的，人造的规则。有些人鄙视图形界面，鄙视 IDE，鄙视含有垃圾回收的语言（比如 Java），鄙视一切“容易”的东西。他们却不知道，把自己沉浸在别人设计的繁复的规则中，是始终无法成为大师的。就像一个人，他有能力学会各种“魔鬼棋”的规则，却始终无法达到象棋大师的高度。

这里，王垠把两个不相关的东西放到了一起。一个是工具的设计哲学，一个是我们如何学习知识。魔鬼棋本身是一种工具设计哲学，和成为大师无关。

在军刀工具一文中我提过，面向特定领域的软件工具之所以让人觉得复杂，是因为这个问题本身复杂。我们把解决特定领域问题而所需的知识叫做”领域模型“(domain model)。如果我们不了解领域模型，就不能理解为什么 Photoshop 比系统自带的 Paint 复杂几千倍, 或者为什么我们需要正则表达式这种诡异的东西。我们讲的复杂与简单，都是工具设计哲学层面的。

以王垠说的 TeX 为例。写出《计算机程序设计艺术》的 Knuth 到底知不知道程序语言设计的基本原则我们可以不加讨论。了解一点字体设计和排版的都知道，计算机排版问题是个复杂的问题。的确，软件工具的设计目标，是把复杂的问题简化。然而，大多数人不知道的是，简化问题是一个两步过程。第一步，我们需要把现实的问题映射到一个领域模型。第二步，是把这个模型简化到我们人可以处理的地步。很多时候这两步合并起来了，让我们觉得这两步好像是一步，并且认为所有的设计，都应该朝简化的方向走。这是一个对设计的错误认识。

举个非计算机领域的例子：用电饭锅煮饭非常简单，加米加水再按个按钮就行了。电饭锅的设计者的设计目标是操作简单且能完美地煮米。作为工具的设计者，它一方面需要了解大米是怎么煮熟的，另一方面需要提供给用户一个简单的按钮。TeX 作者，从一开始就不是设计一个电饭锅，而是一个精确的温控炉子。有了这个精确的温控炉子，想烧饭的可以把它封装成电饭锅，想做蛋糕的可以把它封装成蛋糕烤箱。设计电饭锅的人的设计，并不比设计精确的温控炉子的人好，或者差。设计者的初衷决定了产品的形状。 Kunth 的初衷，正是设计一个可以让他人排版出任何想排版的东西的系统。也就是说，做出一个最终非常简单的，只有一个按钮的排版系统不是他的设计目标。做出一个可以高度定制的系统才是他的目标。

其实，TeX 本身也是一个由繁到简的软件系统。它把所有排版中的问题，都提炼成了一些控制原语。有了这些控制原语，针对特定领域做优化就不是问题了。现在通用的科学出版排版工具 LaTeX, 正是这样的一种优化。这是有心设计的结果。我们抱怨 TeX 复杂，其实是抱怨排版本身复杂。Windows 系统上有许多排版软件，可以毫不客气地说，没有一个可以达到 TeX 所能到达的精确控制。以此责怪 UNIX 下的软件工具是魔鬼棋，就类似于责怪 Photoshop 为啥不象 Paint 那样简单一样，有选择性地忽视了两者所要解决地问题不一样。

我欢迎所有的 UNIX 使用者加入痛恨者阵营，因为我也是 UNIX 痛恨者。只有成为了 UNIX 痛恨者，你才是一个真正的 UNIX 使用者。至于 Windows, 我们对它没有感情，无所谓爱恨。

日本禅宗的“枯山水”就是一种依赖于沙的园林艺术。枯山水在西方很有名，以至于在西方直接被称为禅花园(Zen Garden)。一般的园林都会通过假山和水构景，通过人造的山和水，来引起观者自然的联想，从而联系人与自然。而枯山水园林却反其道而行，不采用真正的山，也不摆放真实的树，竹等物。枯山水中的水，是细细耙制的静态的白色砂石，模拟水的动态形态；枯山水中的植物也极少或者没有。这种美学上的差异，其实是和中日两国禅宗在修行上的侧重不同有关的。

中国禅宗传统上就是位于名山大川，因此在修行时秉承了一种自然主义的路线，让修行者在见山是山，见水是水的自然景观或者园林中修行。日本的禅宗主要继承了曹洞和临济两家。曹洞侧重于打坐和冥想，即“只管打坐”（Shikantaza)。临济强调”心即是佛”，也是促使人向内求索。在这种思想指导下，园林就不再坚持自然主义，而转为为修行着提供安心之法。枯山水正是这种哲学的体现。一个枯山水园林一旦建成，一年四季景色完全相同，恒久不变，宁静无碍。在枯山水中修行，心不会四处乱走。

枯山水是用静态景观来展现这个大千世界动态的一瞬间，而藏传佛教里的坛城沙画 (Sand Mandala)，则是用动态的构建，来展现万事无常这个恒久不变的佛理。构建坛城沙画的目的，不是为了让它成为一项艺术品，而是为了最后摧毁它。这种最终什么也得不到的艺术创作，正是说明了佛教里一切无常的道理。

佛教的艺术家很早就意识到沙是彩色的。《大方广佛华严经》就提到过四条不同的大河流出不同颜色的细砂：“恒伽河口流出银沙，私陀河口流出金刚沙，信度河口流出金沙，缚刍河口流出琉璃沙”。结合华严经所说的恒河沙中的世界，用彩色的沙构建大千世界这种佛教艺术的出现是自然的。

为了构建坛城沙画，喇嘛们需要用尺子和圆规仔细的规划沙画的基本结构和几何形态。同时，所有的彩色沙都是仔细遴选甚至磨制而成。这些彩色的细沙被装入一个小口沙漏，然后由有经验的喇嘛，将这些细沙细细铺出。构建沙画是费时费力的，往往需要众多喇嘛们连续好天的工作。而不管花多少力气，多么美丽的沙画，只要沙盘倾覆，都一瞬间化为无形。从这个意义上来说，要揭示世事无常的道理，没有沙更加贴切的道具了。

坛城沙画

坛城沙画一旦建立，它的唯一命运就是被摧毁。高级别的喇嘛会先诵经一段，然后以一定的规则将沙画摧毁，将各色细沙汇作一堆，装入瓶中，撒入江河。就像熵只能增加一样，美丽的沙画的每一次破坏都是不可逆的。这种摧毁美丽艺术品的悲剧感和无力感，正是佛教想要说明的道理：诸行无常，是生灭法，生灭灭已，寂灭为乐。

佛经里对沙的数量，沙的色彩和沙的无常感都有论述。有趣的是，尽管大多数人认为“一花一世界，一沙一凡尘”出自于佛经，实际上佛经中从来没有明确的提出过这个论题。这个很有佛学意味的句子，实际上来自于英国诗人William Blake 的《纯真预言》：

To see a world in a grain of sand,
And a heaven in a wild flower,
Hold infinity in the palm of your hand,
And eternity in an hour.

SpaceX 的成功是美国社会一直引以为豪的企业家精神和创新精神的成功。2002 年，eBay 以 15 亿美元的价格购买了 PayPal，一家从事电子支付的公司。很多 PayPal 的员工一夜之间成为亿万富翁、PayPal 的共同创始人　Elon Musk　极具冒险精神，眼看 PayPal 已近逐渐成熟，便在 2002 年 eBay 收购还没定型之前，马不停蹄的创立了一家叫做 SpaceX 的公司，致力于民用航天探索。

和 Jobs 用自己的钱投资 NeXT 和 Pixar 一样，Musk 将自己口袋里的 １亿美元投给了 SpaceX。当时，Musk　同时主持两家创业公司，一家是 SpaceX，从事空间探索，另一家是 TelsaMotor，从事电动汽车生产。这两家公司都不是传统的软件或互联网公司，因为空间探索和生产汽车的成本，无需多说，公司的烧钱的速度远远快于硅谷的其他创业公司。可以想象，这两家公司在发展过程中屡屡不绝的资金不足的问题。最后问题严重到需要　Musk　将自己口袋里仅存的 70 万美元拿出来发工资的地步，这在投资人遍地的硅谷是非常少见的事情。

如果换到其他创业者，到了这种地步，可能唯一的路就是缴械投降了。和 Steve Jobs 一样， Musk 的过人之处之一，就在他不但毫不畏惧风险，而且还能说服别人和他一起冒险。通过与 PayPal 一帮一夜暴富的富翁之间的关系，SpaceX 从一家创业基金拿到了一笔钱，暂时保证了公司不会关门大吉。同时，他加快了说服军方和NASA与 SpaceX 签订合同的谈判。2005 年，在 SpaceX 最紧要的关头，美国空军与 SpaceX 签下了价值一亿美元的发射合同。随后，2006年，NASA　与 SpaceX 又签订了价值１０亿美元的向国际空间站运送补给的合同。这些合同带来的巨额项目投资，使SpaceX 终于摆脱了市场和资金的两大问题，成为民用航天的一家标杆，此后就是大家熟知的火箭发射，卫星回收等历史了。而 Musk 在 TeslaMotor 一侧的成功也非常耀眼。该公司是第一家量产锂电池汽车的公司，并在 2010 年成功上市。就像当年 Jobs 同时运营两家公司最后让 Pixar 上市一样。

SpaceX 用很少的钱，在极短的时间里完成了某些号称体制优越的国家举国都不能完成的事情（我说朝鲜呢，不许联想），最重要的当然是 Musk 的远见，无数的工程师杰出贡献。这里，美国政府和 NASA, 也起到了锦上添花的作用。美国政府不敢擅自夸耀自己，但公平的说，SpaceX 的成功离不开美国的航天政策调整。

美国政府在空间探索上的策略虽然一个总统一变，但因为 NASA 具有较大自主性，因此空间政策大体上还是很有政策的延续性的。因为航天飞机的退役日程，小布什政府一直在规划如何在航天飞机退役后继续维护国际空间站。当时小布什政府的设想是一箭双雕，既要国际空间站，又要重返月球。这样，NASA　就提交了一个双火箭的星座计划。因为该计划预算巨大，而美国政府又面对巨大的预算压力，因此联邦政府要求　NASA　同时也寻找其他替代方案，而 SpaceX 的火箭和龙舱，即在当时被　 NASA 选中。

奥巴马政府的空间政策比小布什政府更有远见。因为预算问题，奥巴马政府取消了星座计划的登月部分。NASA 内部的一些专家早就预言过，现在已经不是冷战时期，美国公众根本不想和中国比赛登月。如果美国想再次登月，就要消减国际空间站。而且即使美国登月，中国不会因为美国再次登月了就放弃登月，所以美国和中国竞赛登月连政治意义都没有，美国就应该放弃登月。奥巴马政府采纳了这样的建议，让NASA跳过月球，除国际空间站外，把眼光放在 James Webb 太空望远镜等太阳系尺度的空间探索上。因为这样的政策调整，NASA　得以缓出人员和精力从事更加深度的空间探索，而将给国际空间站运输货物这样“技术含量较低”的项目，交给 SpaceX 这样的私人公司完成。NASA 和美国政府都不顾及所谓的面子问题，在航天飞机退役后，委托俄罗斯用联盟号飞船运送美国宇航员和货物。从短时间来看美国好像丢了人，而长时间来看，是省了NASA的预算，并给了 SpaceX 等私人航天巨大的成长空间（美国私人航天领域公司很多，不限于 SpaceX，SpaceX 是领跑者）。

按照 NASA 的计划，SpaceX 需要先将龙舱发射到国际空间站附近，伴随飞行。然后下一步设计出能够于国际空间站对接的龙舱，最终完成飞行，对接，分离的三步目标。随着 SpaceX 的成功发射，未来已经离我们不远，航天历史正在翻开新的一页。

设计者和使用者

从某种意义上来说，工具是个联系使用者和设计者的桥梁。工具的设计者为解决一类问题而设计工具，工具的使用者也是为了解决一类问题而使用工具的。这两者对于工具都有自己的理解。工具的设计者通常会预测此工具会被用来解决怎样的问题，在设计工具时预见使用者的偏好，而工具的使用者则根据所面临的问题选择合适的工具。

在理想情况下，设计者和使用者对问题的理解 (Vision) 是类似或者重叠的。这时候，工具的设计者能够完全理解使用者的需求，而使用者完全理解这个工具的长处和短处。成语“得心应手”说的就是这样的一种情况：掌握了一样工具，因此使用起来非常顺利。

在现实中，设计者和使用者对问题的理解可能是有差异的，随之对工具的使用方法的理解也有所不同。有时候，工具的使用者能够将工具用到远超出设计者想象的地步。有两个著名的例子可以说明这个问题。第一个例子是出自 Bell 实验室的 AWK 语言。从 AWK 的三位作者的角度看，这是一个与 sed 互补的，处理文本记录的语言。而AWK在贝尔实验室内部推广开来后，三位作者发现其他团队用 AWK 来写作大的数据管理系统，而三位作者本人从来没有写过超过一百行的 AWK 脚本。第二个例子是 C++ 的模版　(template)。模版的设计者的初衷是让 C++ 在处理对象时更加灵活，而自从C++模版的图灵完全特性被发现后，写作一些通用的库成为可能。如C++的Boost库，即重度依赖于模版。设计模版的人未必想到 Boost 库那样对模版的奇妙运用。这两个例子，都充分说明了工具的设计者未必能够充分体验到自己设计的工具的强大之处。

另一种情况是工具的设计者是解决问题的专家，对问题有深刻的理解，而工具的使用者则没有能够完全体验到工具的强大。工具的使用者因此需要学习如何使用工具，学会像工具的设计者那样思考，从而领略到工具的强大之处，达到得心应手的地步。对于完成学校教育后的成人来说，大多数学习都是在学习工具的使用。那么，如何学习软件工具呢？

在我看来，虽然工具千差万别，学习工具的用法也大相径庭，不过如果细细总结，工具的设计者所奉行的套路无非就两种，所对应的学习方法也有两种。我把这两种设计讨论形象地称为瑞士军刀和工具链。这两种设计哲学背后的假设，以及相应的学习曲线是不同的。

设计者的哲学一：瑞士军刀

瑞士军刀以方便著称，一把军刀包含了很多小部件，配合使用能够解决很多野外生存问题。不少计算机工具借用了这个类比。在Google 上搜索 “The swiss army knife of”　会发现很多软件工具号称某领域的瑞士军刀（见表一）

从表一我们不难发现，这些宣称为“瑞士军刀”的工具有一个共同特点：都是针对某个特定领域的问题而设计的。这一点和瑞士军刀是相似的。瑞士军刀的多功能，并不是指这是一把砍树修桥盖房子的万能刀，而是说在野外生存这个领域内，军刀能够解决许多问题。回到表一，用过这些工具的读者一定有所体会：这些工具解决所在领域的复杂问题的能力是非常强的。比如，FFMpeg 内置多种视频编、解码器，众多格式能够相互转换，支持的视频编码格式比任何商业软件都要多。这些优势让 FFMpeg 几乎能解决所有现实中遇到的视频处理问题。因为这些工具针对特殊领域，且功能强大，用瑞士军刀做比喻是很形象的。

除了自称为“军刀”的这些工具外，还有许多耳熟能详的工具属于此类。如平面设计软件 Photoshop，是融许多复杂图像算法和插件于一体的图像处理之瑞士军刀；GNU 的 GCC 编译器，是集语法分析，代码优化，代码生成等功能于一体的专门负责程序编译的瑞士军刀。这些软件包的内部结构，都不是一个单一的程序，单一的部件，而是一揽子的部件，一箩筐的功能模块。

瑞士军刀巧妙地将众多小工具紧凑地组合到了一起。同样，我们说的军刀工具的一大优雅之处也是类似的，即通过一个统一的控制界面，将这一揽子的部件有机地组合在了一起。设计模式里，这种组织功能的方式称作为 Facade 模式，具体指以一个命令或者一个统一的界面抽象内部复杂的操作。如 FFMpeg 和 GCC 这样几乎无所不能的软件包，都可以通过一个单一的命令 (ffmpeg 或 gcc) 加不同的参数调用。在 GUI 程序的世界，所有的 Photoshop 插件都可以通过 Photoshop 的图形界面菜单调用。Facade 模式隔开了用户和“军刀”工具复杂的内部逻辑，让用户从一个”抽象”的层面理解工具。正如我们开车并不一定要了解引擎是怎么工作一样，工具的使用者不需要关系这些工具的内部是如何运转的。

总结这类工具的特点，瑞士军刀是一种把各种工具组合到一起，一起解决一个复杂问题的设计哲学。核心是。设计模式里的facet 模式，一个领域的问题，而不是一个特定的工具。这里实际上是一类工具，而非一个单独的工具。这一类工具被精巧地安排在一起，对外提供一个一致的服务接口，让用户以简单的控制方式完成相对复杂的任务。

领域知识假设和学习曲线

“瑞士军刀“工具都是面向特定领域的。无论是图片，视频处理，还是查看TCP包信息，这些工具都假设了使用者知道图片处理，视频处理或者TCP包的结构等知识。心理学上把这些为了解决特定领域问题而所需的知识叫做”领域模型“(domain model)。工具的设计者是不负责教授这些知识的。因此，作为工具的使用者，掌握这些特定领域的知识就成了使用工具的前提。一般的软件都是基于领域模型的。比如，平面图形处理工具 Photoshop 假设图片是个多层次的物体，如果我们不了解这个模型，就完全不知道为啥这个软件为啥比系统自带的 Paint 复杂几千倍。

因为军刀背后蕴含着领域知识假设，学习军刀工具就不仅仅是学习工具的使用本身，而是学习背后的领域知识。如果不了解背后的领域知识，即使我们会操作这样工具，依然谈不上是个熟练的使用者。相信诸位读者都属于“懂计算机”的一类人。现实中，我们这类人常常因为“懂计算机”，而被家人和朋友要求编辑图像，做个视频或者做个网页等等。有些要求还特别专业，让只会写程序的人非常吃力。究其原因，是因为程序员群体掌握的，只是编程的领域知识。如图像，视频处理所需要的领域知识，均是编程之外的了。即使像 Eclipse 这样专门给程序员用的软件，也隐含假设了使用者需要重构，设计模式等等的知识。不掌握这些知识的程序员用 Eclipse 也仅仅是将其当成一个花哨的编辑器使用而已。

因为需要领域知识做铺垫，军刀工具的学习曲线是因人而异的。对于有的人来说，如果本来就知道工具背后的假设，学习计算机操作就毫不费力。以我爸爸为例，本身用计算机并不熟练，但他学过画画，作图感一流，若干年前从书店随便买了一本 Photoshop 入门后就把 Photoshop 玩得很熟。而我知道这个软件每个选项的意义，却处理不出什么像样的图。对于我爸来说，他的学习曲线就很平缓，而对于我来说，就很陡峭。

学习曲线不一样这一点在计算机语言的学习上尤为明显（计算机语言是众多编程特性的大糅合，是典型的军刀设计）。像 Google 这样的公司面试时完全不考察语言细节，很多人入职的时候都不会 Java。因为我们相信任何合格的程序员都能很快学会 Java 这个语言。道理很简单，只要考察一个人掌握了Java 语言背后的领域知识，即面向对象的设计，数据结构，控制结构等等，就有充分理由相信这个人学 Java 毫不费力。但是，话说回来，每个语言背后的领域假设都有细微的差别。比如 Lua 只支持哈希表，Awk 支持哈希表也支持记录处理，Vim 里一切都是文本对象等等。真的领会这些领域模型并且将这些语言用得纯熟，没有长时间的投入是不可能的，这就是为何 Peter Norvig 强调“十年学会程序设计”。这两种对待编程语言的态度是不矛盾的。引申出来，对于语言或者工具的初学者来说，要分情况学习军刀工具。在不熟悉领域知识的情况下，应该找一本非常简单的书熟悉领域模型，获得一个 Big picture，而非上来就想着要解决手头的问题。而对于已经熟悉领域模型的人，比如会了一个 MVC 框架再学另一个的人，随便捡起一本 In Action 或者 Cookbook 也能事半功倍；有人甚至书都不需要买，看看文档就可以了。不清楚内情的可能会把这类人叫做强人，其实了解了背后的底细后，所有人都可以如此。

最后谈一下军刀工具的设计策略。我们说了，军刀工具背后蕴含的是领域知识。因此，设计军刀工具的人，必然需要是对问题有深刻理解的领域专家。这一点很好理解，因为很难想象一个不懂图像处理的人会指导 Photoshop 的设计，或者一个不懂统计的人会设计 R。不过，即使是最资深的专家，也未必能设计出一个能覆盖到所有问题的工具。这时候，工具的扩展性就成了一个重要的考量。可以这么说，几乎所有成熟的军刀工具，最后一定会进化出一个插件系统，用以扩展功能。插件系统的好与坏是考验设计者功力的时候。像 Firefox 和 Photoshop 这样的工具，若不是第三方插件，至多是一个普通的软件。加入插件系统后，这些工具成为了一个平台，从而衍生出了无数的新用例。即使像功能小巧和 Emacs 格格不入的 Vim, 最终也进化出了插件系统。这是一样工具成熟的体现。

总结一下军刀工具的特点如下：

•  面向特定领域，覆盖该领域大部分问题
• 由领域专家设计，使用者需要了解该领域的基本知识才能熟练运用工具
• 内部由众多小模块组成，对外提供一致，简单的控制界面
• 常常具有强大的插件系统，以方便用户扩展现有系统

进程间通信的技术细节繁杂，以Linux 系统为例，就有文件，管道，消息队列，信号量，RPC，UNIX Socket,　RPC　等等多种方式。Windows 系统还有邮件槽, COM 对象等等。Mac OS 则有 AppleEvent 等等。在这里我们介绍 Plan 9 系统中一个不太为人所知的 IPC 机制：Plumber，或者叫做管道工。我在”开发人员为何应该使用 Mac OS X 兼 OS X 小史“中曾赞扬过 Mac OS X 系统中的 AppleEvent 进程间通信机制对工作效率的提升。和AppleEvent 类似，管道工也是对图形界面下进程间通信的一个尝试，不过在通信的粒度上有所区别。

我们从一个简单的例子入手。在如今网络普及的时代，几乎所有的软件都能自动识别链接。只要打入 http:// 开头的一串字符，就立即转化为一个可点击的链接，点击这个链接则自动召唤出浏览器。我们对此毫不感到新鲜，因为这功能再自然不过。其实这些功能在上世纪９０年代还是很少见的。 Plan 9 的管道工，在当时就前瞻地提出一套匹配字符串和自动投递给指定应用程序的机制。我们只需要告诉管道工，用户选中字符串匹配某类型的时候就交由某应用程序处理，管道工即负责具体的程序间的通信。这是对 UNIX　管道机制的一个革新。如我在Mac OS 一文中所说，纯粹的管道机制在图形界面程序中已经不再适用了。

我们所熟悉的URI 处理仅限于浏览器，且只能处理由 RFC 2396 预先定义的 URI 模式。即便如此，我们也能体会到 URI 处理器的方便。像大家熟悉的电驴链接实际上是 ed2k:// 打头的 URI。在浏览器点击后就自动用电骡打开；苹果的 iTunes 的链接实际上是 itms: 打头的 URI；Android 商店的链接其实是 market:// 打头的 URI 等等，都是让用户更加方便的例子。有了这些机制后，我们难以想象没有这些机制而需要拷贝粘贴的日子是如何度过的。

管道工是 URI 处理器的推广形式。在管道工里，不仅仅是 URI，一切的字符串都可能匹配。因为读者可能没有用过管道工，我们仍然以大家熟悉的例子来说明。安装了 Skype 浏览器的插件会自动把网页上的电话号码变成一个特殊的“用 Skype 拨打该电话”的按钮，在 Gmail 里开启一些插件后 FedEx 和 UPS 的包裹号码能自动变成链接直接转到包裹查询网站等等。管道工的功能，就是让我们可以很方便的自定义这些转发功能，而不依赖于应用程序的实现。在 Plan 9 系统中，即使你不装 Skype, 不用 Gmail, 用户依然能够通过制定正则表达式匹配规则，来决定如何处理电话号码和包裹追踪号码等等。

管道工的原作者用编译器和编辑器的例子来说明管道工的作用。我们知道编译器报错语法错的时候，会以一定格式报出发生错误的文件和行号，如

Line 43: Hello.cc syntax error.

我们可以设定规则，在用户点击这些错误信息的时候，让管道工自动匹配和提取文件名，行号，并自动发给编辑器，就省却了我们人工打开编辑器跳到某行这个繁琐的步骤。尽管 IDE 已经通过集成编辑器和编译器的方式绕开了这种进程间通信，这种匹配/转发的通信方式仍然用在不少地方。比如 Vim 就引入了一个叫 errorformat (错误格式)的机制，让编辑器能够理解和匹配“错误格式”，并跳到指定的行。

通过 Plan 9 from user space 这个开源实现，我们可以在 Mac 和 Linux 上使用管道工。不过我们已经有了很多现成的工具能够部分实现管道工的功能。因为我日常只用浏览器和shell，因此简略介绍一下我是如何在浏览器和shell中实现类似于管道工的功能的。

用油猴子或者其他浏览器插件，我们可以将网页中某特定的字符串转变成一个定制的链接。然后，取决于所在平台，我们可以将这些链接和预定义的应用程序挂钩。Mac 下一个好用的工具是 RCDefaultApp ，Linux/Gnome 下的 gconftool-2　也直接支持对 URL-handler 的修改。Windows 下的方法则是修改注册表。（当然这些方法都有安全隐患，所以只适合个人使用）。

在终端里，对于 Linux 用户，urxvt 这个终端非常强大，可以使用 perl 扩展来匹配和执行命令，基本上可以完全实现管道工的这种匹配任意字符串且发送给其他程序的功能。在 Mac OS X 中，iTerm 2 是程序员应该用的终端。该终端目前还没有 urxvt 的强大扩展性，不过也能完成大部分匹配任务。比如说，iTerms 的最新版本支持一个叫做 Sementic History 的功能 (Preference -> Profile -> Advanced)。这个功能使得我们可以直接点击 Terminal 里面的文件名召唤出 Finder。用苹果的可能都知道 Mac 里有个 Proxy Icon （应用程序标题栏里面的小图标）的概念，我们可以直接把这个小图标当成文件的代表，拖来拖去，甚至可以直接拖到 Gmail 中当附件。我们其实可以把 iTerms 2 里面的文件名直接当成一个对象拖来拖去。

因为我日常只使用浏览器和终端，Plan 9 的管道工给我的启发是，如果有一套好的进程间通信机制，拷贝粘贴是完全没有必要的。如果你和我一样基本不用鼠标，并且认为拷贝粘贴是一个降低工作效率的事情，那么我建议你尝试一下用管道工的思想去改善你的工作流，看看哪些拷贝粘贴是可以由计算机完成的。

尽管这本书视角独特，以现在的眼光看，作者的抱怨中，真正属于 UNIX 固有问题的只占 50%，其他如对 sendmail 排山倒海的批评，对 C＋＋ 的尽情嘲弄，实际上都不属于 UNIX 系统特有的。其他的 50%，则颇有历史意义，可以看到当年的 UNIX 系统是何其的“原始”。特别是对照现在的 Linux 来看，可以看出 Linux 作为当年 UNIX 的继承人，在文件系统，安全性，稳定性等等方面的巨大的进步。

除去一些对 UNIX 中具体 BUG 的批评，这本书的背后实际上是三种设计哲学间的交锋，我把这三种哲学叫做 MIT 哲学，UNIX 哲学和 GUI 系统哲学。“MIT 哲学”这个词，是借用那篇著名的 Worse is better 文章中的叫法。MIT 哲学的代表是 LISP 机器，即提供一个 LISP 环境的机器。这个机器提供给用户的，是优雅的编程环境，如统一的内存管理，统一的函数式接口，良好的文档等等，一切程序员所需要的，都给准备好了。但这个系统不管是作为个人计算机还是作为工作站都没有获得成功。

GUI 系统哲学从施乐的 Alto 开始，到90年代中期 Windows 95 出现之前，已经颇有气象，特别是在个人计算机领域，几乎所有的个人计算机厂商都在提供自己的图形界面操作系统。GUI 系统的哲学，是友好的用户界面和一致的使用体验。至于具体的功能，则委托给具体的应用程序实现。

而 UNIX 哲学，则像是一种开放式系统的哲学：除去提供统一的系统调用和标准工具外(POSIX)，不强调系统的一致性。UNIX 像是一堆松散的积木堆起来的一个系统，在遵守 POSIX 标准的前提下（其实是个非常松散的标准）各个厂商都可以自己选择积木搭建系统。

UNIX 这种开放的，允许自由搭积木的做法，是和信奉MIT哲学的人水火不容的。这些用户在 UNIX 的因为开放造成的不一致性上尽情吐槽。比如说，UNIX 一个饱受诟病的缺憾是其命令行参数不统一。在命令行下，有的命令加 -h 是显示帮助，有的却是显示隐藏文件，还有的命令压根不接受 -h 参数。这样的问题，反映了 UNIX 在演化过程中缺少一个统一的规划。这在演化路径单一的其他操作系统上是不可想象的。再比如，UNIX 的计算模型很简单，即用 C 语言和 shell 对系统调用做一个胶水包装，不提供内存管理也不提供异常处理，文件系统也很低级，不支持文件恢复也不支持文件的元信息存储。而 MIT 的LISP 机器的计算模型和存储系统看上去都更加高级，统一的函数式接口，自动内存管理等等。用过 LISP 机器的人自然不习惯 UNIX 这种看上去“低级”的操作系统。结果是，用过 LISP Machine 的用户除了抱怨 UNIX 外，只能寻求在 UNIX 上构建一个新的层，来弥补 UNIX 的不足。这事情的一个结果就是造就了Emacs 这个怪兽，到最后几乎所有能在 UNIX 里做的事情，都能在 Emacs 里完成。这样，除了操作系统内核外，Emacs 完全取代了 UNIX 环境。Emacs 功能强大到大家都同意 Emacs 是个万能软件，而 vi 用户则开玩笑说 Emacs 是个缺少一个好编辑器的操作系统。大家都知道，Emacs 的作者正是从 MIT 出来的 Richard Stallman。

痛恨者手册的作者也是在 MIT 的 AI 实验室工作多年的技术人员。为了解释 UNIX 的成功，他借用了 Worse is better 中的说法（Garbriel 断言 C 语言和 UNIX 是终极计算机病毒），把 UNIX 归类为世界上第一个计算机病毒。书中提到，UNIX 和病毒的共同特征为：体积小，可传染多种宿主（可移植），变异快速等等。书中说， UNIX 的普及并不是因为它在技术比其他操作系统更加优越，只是因为可移植，可传染和变异快，才占据了很大一块用户份额。

这个解释我认为是相当精当的。相对于其他操作系统，UNIX 基于C书写，可移植和早期的免费分发方式，即使技术上不够好，仍然像流行性感冒一样蔓延。一传十，十传百，快速攻城略地。当时 UNIX 的风行程度可以从几个侧面来证明。八十年代初雨后春笋一般地冒出了很多新的UNIX公司，SUN 和 SGI 就是是借着 UNIX 成长起来的典型例子。他们短短几年间就靠 UNIX 工作站业务跑上了纳斯达克。微软和苹果是靠个人电脑业务起家的，各自都有自己的操作系统，却也跑到UNIX世界下注，都曾经推出过自家的UNIX发行版（分别叫做 Xenix 和 A/UX)。UNIX这个”病毒”在工作站和服务器上的寄生能力极强，直到后来演化能力和传播能力更强的“病毒” Linux 的出现，加上 .COM 泡沫破裂的一场大洗牌，才把 UNIX 的市场份额压了下去。Linux 则彻底继承了所有的“病毒”特性，除去原有的体积小，可移植外，通过开放内核源代码，造就了现在从超级计算机服务器到嵌入式系统无处不在的现状。从设备总量来说，世界上从未有一个操作系统如 Linux 如此成功。

可惜的是 MIT 哲学派本身没有成功的操作系统产品用来作为比较（除了Emacs这个运行在UNIX上的程序外），因此在批评 UNIX 上火力就欠缺了一分。为了写出一本厚厚的痛恨者手册砸向UNIX，就需要来自另外一派，即信奉GUI哲学的用户的愤怒。

这些用户的愤怒，主要集中在易用性上。图形界面操作系统的出现，本质上就是为了解决计算机的可用性问题。在图形界面系统出现之前，掌握计算机的使用需要的是阅读厚厚的手册。图形界面出现后，只需要几分钟的演示，普通用户即可操作计算机完成一些简单的任务。这种效率的本质提升，正是施乐的 Alto 和苹果的 Macintosh 的革命性所在。而 UNIX 所拥有的，是一堆两个字母的命令，不一致的命令行参数，和一个实际上不是为 GUI 系统设计的 X 图形系统。命令难记，X 又臃肿，即使有了这些仍然没有构成一个统一的桌面系统（所以后来才有KDE 和  Gnome)，也难怪用户吐槽不已了。

在这类来自 GUI 用户的抱怨中，出乎我意料的一条是对UNIX管道的抱怨。主要的批评点在于管道作为一种 IPC 机制本身不够强大，包括管道不支持双向数据流（双向管道的用例也极少)，只能把数据作为字节流而不能传递结构化数据，和指针等等。从传统 UNIX 用户的眼光来看，这些指责是很不公平的。管道的作用是串接程序的输入输出，将小工具串成强大的工具链。但管道并不是 UNIX 上唯一的 IPC 机制，UNIX 有其他的 IPC 机制来支持管道之外的功能。换一个角度看，要求管道支持双向通信，结构化通信等等，正是从 GUI 哲学出发的对管道的批判。在 GUI 世界，进程间的通信有了两种新的方式：1、把小程序全部集成到一个大的多线程窗口程序中来进行线程间通信； 2、通过在不同程序间复制粘贴对象。从这两个角度考虑，自然会要求 UNIX 管道能像线程间通信一样双向，以及支持有结构的对象而不是单纯的字节流。

GUI 程序的这一套新的进程间通信机制，改变了所在平台的软件架构。UNIX 的软件架构，是围绕软件工具(Software Tools) 的概念展开的，归结起来就是每个工具做一件事情，且做到最好的哲学。因为 GUI 程序本身的复杂性，把林林总总的功能，放入一个大程序中让各模块直接在一个进程空间里互相通信成了一个通行的做法。比如电子表格软件中的公式计算，无需代理到 bc 这样的外部计算器中，直接由内置的模块完成。在这种哲学的指导下，为了给提供全面的解决方案，各种商业程序都追求大而全，内置各种可能用到的功能，因此体积也越来越大。几百兆大小的商业软件不足为奇了。UNIX 痛恨者手册推崇这种只能算局部最优的程序构建方法，而反过来抱怨管道这个另一个局部最优不够好，在我看来是有历史局限性的。

总的来说，这本书代表了 UNIX哲学以外的其他两种哲学对 UNIX 尖锐的批评，是值得当成UNIX 发展史的一部分而一读的。

LISP 语言前传

Lisp 的主要设计者 John McCarthy 曾经就 Lisp 的发展史，专门写过一篇 History of Lisp 的文章。这里介绍的历史，基本史实部分参照了 John McCarthy 的这篇文章，以及同时期 MIT 的关于 Lisp 的技术报告。

Lisp 的历史要从 IBM 的神奇机器 704 说起。此时是 1954 年，尽管距离 1946 年第一台计算机 ENIAC 的出现已经八年了，商用计算机市场还仅仅起步。很早就进入计算机市场的 IBM 做出了一个影响深远的决定：发布一台可以进行浮点计算的，面向科学和工程的电子计算机。这台计算机，很朴素地跟着 IBM 之前发布的 701，702 后，被编号成 704（不知为什么 IBM 从来没公布过 703）。说 704 是神奇机器，是因为这台机器在计算机科学发展史上意义重大：世界上最早的语音合成程序就是由 Bell 实验室的科学家在 IBM 704 上完成的。 Fortran，Lisp 也是最早在 IBM 704 上实现的。

和当年的所有计算机一样，IBM 704 是个百万美元级别的大玩具，不是一般人甚至一般大学能够买得起的。好在 IBM 和大学的关系一向很紧密，在 1957 年的时候，决定捐一台 704 给 MIT。当时在 Dartmouth 教书的 John McCarthy 和在 MIT 教书的 Marvin Minsky 关系很好，因此这台即将到达的 704，即将成为 McCarthy 的新玩具。

当年部署一台计算机的周期很长，为了不让自己闲着，McCarthy 决定一边等机器部署，一边研究一下如果有了这台机器，可以做点什么。当时 Minsky 手里有一个 IBM 的项目，内容是使用计算机证明平面几何问题。既然计算机没来不能写程序，他们就只能从抽象的层面思考问题的解决方法。这个思考的结果，是开发一套支持符号计算的 Fortran 子系统。他们的基本想法是，用一系列的 FORTRAN 子程序，来做逻辑推理和符号演绎。

回头看，这条路的确绕开了没有 704 就写不了程序的路障。因为我们只需要大致了解 Fortran 能够做什么，不能做什么，无需实际 Fortran 编程，就可以假想我们已经有了一系列未来可以实现的子程序，然后只要在数学上证明这些通过子程序的组合，加上自动逻辑推理，就可以证明平面几何定理。这就把一个计算机工程学问题，抽象成了一个数学问题（日后这个领域被正式划归到人工智能的学科中，但在当时这还是属于数学问题）

这样，计算机没来之前，McCarthy 的最终结果，是一个用 Fortran 子程序做列表处理的简单系统。McCarthy 的这条路很现实的做法——如果不用 Fortran 而是自己写一个新的语言的编译器话，可能需要好几年的时间。而 McCarthy 当年还不是终身教授，投入到写作新语言这样旷日持久且不能保证成果的项目中去，不会对他的职业生涯有太大的正面作用。

704 送到 MIT 后， McCarthy 带着两个研究生，将之前计划的 Fortran 列表处理子程序实现了，并命名为 Fortran 列表处理语言 (FLPL) 。然而，因为 Fortran 语言本身的限制，McCarthy 对 FLPL 并不满意。他在写作自动求函数导数的程序时[a]，发现 FLPL 的弱点集中体现在两个地方。

第一个问题是递归。我们在 Fortran 语言怎么来的这一节已经提到，704 上的 Fortran 语言是不支持递归的。而 McCarthy 心中所设想的语言，很重要的一条就是递归：没有递归，很多列表处理的函数只能用循环来实现，而循环本身并不是 McCarthy 设想的语言的一部分。熟悉函数求导的链式法则的读者可以想像，没有递归的求导程序是何其难写，因为函数求导过程本身就是递归定义的。

第二个问题是 Fortran 的 IF 语句。IF 家族的分支语句，在计算机程序设计中可以说必不可少。在 McCarthy 那里 IF 就更重要了，因为几乎所有有递归函数的地方就有 IF（因为递归函数需要 IF 判断结束条件）。相信读者都很熟悉这种 IF 结构

IF 条件 THEN

    一些语句;

ELSE

    另一些语句;

END IF

这是从 ALGOL 语言一脉相承下来的，很“自然”的 IF 写法。而早期的 FORTRAN 的 IF 写法却不这么直观，而是

IF (表达式) A B C

取决于表达式的值是小于零，等于零还是大于零，分别跳到（等价于 goto）标签 A， 标签B 或者标签 C。这个 IF 隐含了三个 Goto，可以说和结构化编程的实践截然相反，降低了程序的可读性。 Fortran 首创的这个三分支跳转的 IF 饱受诟病，Fortran 77 开始支持结构化的 IF，而 Fortran 90 标准进一步宣布三分支跳转的用法已经“过时”，不支持使用。

在 McCarthy 那里，Fortran 的三分支跳转 IF 也不方便。为此，在 FLPL 中，他试图用一个叫 XIF 子程序完成类似于 IF 的分支功能，用法是：

XIF(条件, 表达式A, 表达式B)

取决于条件的满足与否，XIF 返回表达式A 或者表达式B 的值。很快，他发现，用子程序的方法实现 XIF，在语义上并不正确。我们知道，在 Fortran 和其他高级语言中，函数参数的值在进入函数之前必须全部确定。在 XIF 这里，不难看出，不管条件满足与否，我们都先要计算表达式A 和表达式B 的值。而 IF 是个分支逻辑，从语义上来说，应该只计算满足条件的分支的值。因此，用函数来实现 IF 是不正确的 [b]。

作为一个旁注，尽管 John McCarthy 早在50多年前就发现了函数实现 IF 是语义错误的，现代的程序员还常常犯这个错误。一个值得一题的例子是 C++ 逻辑运算符重载和短路表达式的不等价性。我们都知道，在 C 语言中，逻辑与 (&&) 和逻辑或( || ) 都隶属于短路表达式，也就是说，对于 A && B 这样的表达式，如果 A 已经确定为 false，就无需计算表达式 B 的值，即 B 的计算被”短路”。以 C 为蓝本的 C++ 一方便保留了这些短路表达式，另一方面在面向对象的特性中，引入了运算符重载。具体来说，只要一个对象定义了 operator&& 成员函数，就可以进行 && 运算。乍一看，这是一个很酷的特性，可以让程序员用 A&&B 这样的数学表达式表达复杂的逻辑关系。然而，仔细想想，  A.operator&&(B) 在语义上并不等价于 C 所定义的 A&&B，原因在于 A.operator&&() 是个函数，在求值之前需要先计算 B 的值，而后者是个短路表达式，本质上相当于

IF A:

 return True

ELSE:

 return B

因为短路表达式不一定会对 B 求值，这两者从语义上就是不等价的。如果 B 不是一个简单的对象，而是一个复杂表达式的时候，对 B 求值可能有副作用，而这个副作用，是写 A && B 并把它当做短路表达式的程序员所没有预见的。按照 C++ Gotcha 的说法，这很容易造成潜在的程序 Bug。实际上，C++逻辑运算符重载是一个危险的特性，很多公司的编程标准都禁止使用逻辑运算符重载。

递归和 IF 两个问题，使得 Fortran 从本质上就不符合 McCarthy 期望，以 Fortran 为宿主的开发列表处理语言也不可能达到 McCarthy 想要的结果。因此，唯一的解，就是抛开 Fortran，从头开始，设计一个新的语言。值得注意的是，此时 McCarthy 正好跳槽到了 MIT 做助理教授，MIT 有足够多的编程强人，可以帮 McCarthy 完成这个编写新语言的任务。这个强人，就是 Steve Russell；这个语言，就是 Lisp。

[a] 读过 SICP 的读者会发现这是一道习题
[b] 读过 SICP 的读者会发现这又是一道习题

男女童子军训练是很多国家儿童素质训练的重要一环。人的性格和习惯到了成年实习就比较难改变了。未成年时期的如童子军训练这样的项目，是培养一个“人”的很好的方式。人生中的最重要的好习惯，往往是在幼年少年时期，甚至在幼儿园学到的。实际上，对好习惯进行有意识的培养是社会教育应有的部分。因为这些好习惯不光可以塑造一个“人”，也能够让所在的社会更加美好。这些好习惯可以推广到生活和工作的很多方面。比如程序员们很熟悉的 Bob Martin 大叔，就围绕这一条男童子军的“整洁”的“军规”，硬生生写了本叫做 <Clean Code>。这条军规的背后，是童子军创始人 Baden-Powell 留给男童子军的最后的话，当你离开一个世界的时候，试着让这个世界比你发现他的时候更加好 (Try and leave this world a little better than you found it)。这句话的指导意义，既用在定义人生上，也可以用在整理房间上，或者对公共场所垃圾的处理上。当然，也可以像 Martin 大叔一样用在代码重构上。

因为内人是女童子军成员，最近准备搬家整理东西的时候，整理出了一大捆女童子军训练的材料，其中一本叫做“6-9年级女童子军手册”的书，我不经意瞄了一眼，觉得有些话写得真好，特别是女童军的“成功生活”的八个原则，因此简单的翻译一下。

女童子军的“成功生活”的八个训练：

1. 管理你的时间 (Managing Your Time)
2. 正确处理压力 (Handling Stress)
3. 学会表达自己 (Speaking up for yourself)
4. 时刻保持安全 (Stay safe)
5. 获取管理钱财 (Earning and managing money)
6. 注意合理消费 (Becoming a responsible consumer)
7. 准备满意职业 (Preparing for satisfying career)
8. 做负责任抉择 (Making responsible decision)

这八条原则如果孤立开来看，就和市面上大部分成功学书一样，并无特别之处。不过，考虑到这是未成年时期的训练，效果和成年之后再主动反向训练，难度是有区别的。现代认知心理学的一个基本假设是，人可以通过提高自己的认知能力（心智），改变自己的思维方式，对事情的看法，控制（相对难以控制的）感情，以及获得精神上的愉悦和在现实中的成功等等。少年时期的这些训练，正是对人认知能力的一种系统性的提升。成年之后用认知心理学方法反过来训练大脑和行为习惯，固然目标明确，却有事倍功半之感。

我觉得我小时候很幸运，有意无意的受到了多方面好习惯的训练。相信很多读者都受过类似的好习惯的训练，不过像童子军这样分门别类为这些好习惯设置配套训练项目还是第一次见到。如果将来我有小孩子，一定送他/她参加这样的童子军训练。诸位读者中有不少家长，想必也很注意对小孩的好习惯的培养，或许参阅美国的童子军训练的一些项目会有一些新的启发。

在 StarrySource 的文章中，推特的开放性是一个事实判断，但是不是因为推特刚开始太小所以才做 API 的就很难说了。要知道，推特做 API 的时候，正是 flicker 和 delicious 靠 API 赢得了大量用户的时候。我们很难反向的说当年做 API 不做客户端是人手不够，我们也没见到人手够的 flickr 做看图传图的客户端，即使是在被 Yahoo! 收购之后。小公司以开放式 API 起家的奇迹，推特是非常特别的一个。现在推特开始做客户端什么的也的确是一个事实判断，但是多大程度会影响它的开放平台就很难预测了。它提供一条龙的服务，不意味着初期的开放策略受到了影响，而仅仅是推特开始挤占一些上下游而已。

新浪出手做微薄的时候，也邯郸学步做了 API。StarrySource 文在这里试图通过对比推特和新浪的策略不同，来说明新浪的用户体验很好。新浪有图床有富媒体呈现是事实，遗憾的是新浪在所谓的开放式 API 上，也和当年没图床的推特一样，做出了一套不支持上传图片的 API，对富媒体的支持却和 Web 界面不相匹配，这就特别奇怪了。更加奇怪的是， GEO （用户地理位置）在微薄上根本就不是一个显著的特性，因为微薄用户不比推特这样，大部分是移动设备用户，况且中国的地理定位的基础设施几乎没有，但新浪偏偏和推特一样，有 GEO 部分的 API。要知道推特是靠 GEO 赚了钱的，所以这就奇怪到家了。 从这个例子不难看出，虽然事实是新浪做的东西是推特的超集，实际上还是跟在推特后面试图复制推特的特性，并加入自己擅长的特性。这里微薄从来就没有过一以贯之的想着“要提高用户体验”。我想整个新浪产品线都不是从提高用户体验出发设计的，这一点只要用户新浪产品的用户都体会到。

至于在产品设计这节的观点，和菜头和@virushuo 已经说的够多的了，无需多话。在用户这节作者对言论审查，言论，小圈子等等的阐述，只会让经历过推特的人觉得不值一驳罢了。虽然我不知道 StarrySource 推友的背景，但仅从这篇文章的内容看，抽取掉事实之后，得到的是几个零散的观点，不构成论证的观点；相比之下，霍炬这篇有完整的论据，论证，甚至还包括了不少从论证引出的可证伪的论断。我想，不能因为主观上喜欢新浪微薄，就说霍炬的文章写得烂吧。

推特上推友开玩笑说这文章好像可能吧的文风。可能吧的文风是什么样子的呢，我有体会。首先，文章有充足的事实和引用，就差直接引用原文了。其次，文章不管内容多少，总要组织成一小节一小节的，用写书的结构写一篇2000字的博客文章，这样给人的印象是思维清晰。然后，排版是所有的中文博客里不是最好就是第二好的。一篇技术评论，有了上面这三样，再有一些不太离谱的观点和文字填充一下，基本上就可以算是一篇在中文圈子里相对好的文章了。受众反正也极少看英文的东西，所以我想可能吧访问量还不错。我和可能吧没什么过节，以上就是说说而已。对于我个人来说，我不订阅那些一个月写三篇以上的“干货”博客，因为我不相信这些内容的质量。好文章需要有深度思考和长期观察，而很不幸，这两样是稀缺资源。一个月的阅读和思考的结果，说不定也就够写一篇文章。