那支写程序的笔：软件工业的修辞学

刘天北

...他的骨骼变成了珊瑚；那些珍珠曾是他的眼睛...
《暴风雨》第一幕，第二场

写程序的笔

在今天，程序员和笔的关系相当尴尬。每当快递公司送来邮件，整个办公室就会发生一次短暂的骚动：我们需要足够的运气，才能找到一支笔在回执上签字。就像一个势利的大家庭里那位不受欢迎的表舅，笔在程序员们中间已经没有容身之处。
麦克卢汉的名著《理解媒介》详尽地描述了工具对人性的塑造和颠覆。一件工具引入的不仅是其实用性，更是人与世界、人与自身的一组全新的关系。用笔写作，核心在于 “物质感”。键盘输入是抽象的，具有一种近乎透明的“精神性”：随着击键，心中的概念似乎直接跃上了屏幕。而用笔写作时，手会感到纸的阻力、墨水的扩散和转向，由此而形成了“字体”或“笔法”。所有的人打出的字都相同，但是没有两个人的笔体完全一致。与这种物质感紧密相关的，是写作的风格和修辞学。从拉丁文开始，多数西方语言就用“笔”来指代“风格”。懂法语的朋友至今还可以清晰地听到“le style（风格）”与“le stylo（笔）”之间那种内在的亲和性。用笔写作，意味着讲究语言的质感和修辞性。那么，当写作进入键盘输入的时代，笔逐渐向博物馆引退时，“风格”与“修辞”又还有意义吗？
 
对于当前流行的极限编程（XP）方法论，我至多是个同情的旁观者，但Addison-Wesley出版的那套XP丛书则一直是我钟爱的读物。Kent Beck和Martin Fowler写书，好比是“夏日朱红盘中，快刀切绿沉西瓜”，明晰、畅达。不少概念要是让我表述，肯定是一连串高难度的空翻和筋斗，在他们那里却能出之以亲切、平易的英语。我以为，这是大师名作的一种不容错认的特征。
很多人告诉我，在XP倡导的12项重要实践中，最难理解的就是“隐喻（metaphor）”。本来，隐喻作为一种修辞格，早该与其他花言巧语一起被逐出技术写作的领地了，又怎么能像Kent Beck所说的那样，取代系统构架设计（system architecture）？而在我看来，恰恰是在这里隐藏着大师们的部分魔术。对于软件开发来说，修辞学，特别是隐喻，远远不只是加在清晰的概念上的一层浮华的透明装饰，而是其根基和核心。软件系统作为抽象的逻辑模型，若要得到表达，就必须经过自然语言的滤波和转换。为了把程序员心中那个泛着钢蓝色的骨架用具体的文字再现出来，隐喻是最好的（有时是唯一的）工具。在日常语言里，我们说“针眼”、“桌腿”，而无法以非隐喻的方式指称这些对象，与此相似，在软件工业中，大量的概念原本也是取自其他领域的隐喻：“waterfall”，“bug”，“listener”等等，每一个都能追溯到日常语言中更平凡的用法，就连最常说的“architecture（系统构架）”，也清晰地打着来自建筑学的借条——抛开隐喻，你找不到更好的说法表达这些概念。《Software Craftsmanship》的作者甚至把“software engineering”本身也当成一个即将被取代的隐喻。
修辞学在软件开发中的意义，在于它为概念带来的“可见性”。就隐喻而言，它将抽象的置换为具体的，陌生的置换为熟悉的，由此让我们对全新的概念（和它们之间的关系）产生了直观和洞察。隐喻是光，缺少它，我们读到的就只是机械的符号和算子。在XP论著中，这种启发性的隐喻比比皆是：“coach”，“yesterday's weather”等等，其中最绝妙的一个可能是Kent Beck关于XP本身的“驾驶”隐喻（软件开发就像是开车，需要时时调整方向盘，而不是永远保持一开始对准的方向）。质言之，大师名作的可读性、大师们写作的举重若轻，并不意味着“平淡”和“平庸”，相反，这要求专门的艺术，要求对语言、修辞的倾心关注和磨炼（Kent Beck的一部新作就叫《The Principles of Writing Research Papers》）。

家中的流亡者

“君子之德风，小人之德草”，所谓风动草偃，经典著作对于日常实践的带动作用也类乎此。我个人观察，在软件业较发达的国家中，从技术专著到实际开发，再到商业文档，存在着某种“修辞密度递减”。专著多是名师巨匠所为，并且大都要提出开创性的全新概念，所以要最密集地动用语言能力和修辞艺术，表达也最直观；而实际开发中由于专业规格限制，语言上就很难太讲究——但在一些细节，尤其是“命名”上往往还保留着名著的余韵；使用手册、在线指南之类的商业文档，目的全在介绍具体操作，所以只是平铺直叙，语言最是枯燥。
而从修辞学视角观察，国内软件行业的状况，当得起宋人所说的“语言无味、面目可憎”。我们的不少“专著”、“论述”，似乎要到国外的商业文档那里认祖归宗，风格上也袭承了人家的八股面孔；在实际开发中，我们拙于塑造自己的概念，就连命名都缺乏最起码的直观性——不少人会用汉语拼音首字给变量或数据库字段命名，“销售管理”和“在线注册”到了他们手上就是XSGL、ZXZC；最后，中文软件的用户界面和用户文档里的语言，就具有完全意义上的“用户不友好性”，国际软件的中文版往往比汉化前更难用（请比较“view”和“视图”，“cascade”和“层叠”）。另外，不妨对比一下国内外软件产品的名称：国外产品善于利用语词表面微弱的折光体现自身特性（Decaf、Espresso、Latte这些名称一望即知，都肯定与Java有关）；而我们呢？谁能告诉我最近有多少国内产品以“2002”、“XP”命名？
沿用上面的比喻，如果说健康的修辞为软件系统带来了“可见性”，那么国内常见的一些情形就只能用...沙尘暴来形容。人们把语言的机械、生硬当成“科学性”和“严谨”的同义词，谁能把问题讲得更枯燥，谁掌握了更多的三、四个字母的缩略语（acronym），谁就能获得加入这个隐形俱乐部的口令。是的，这里的情形就像是一个壁垒森严的俱乐部：难用的软件产品和难读的软件文献，在大众与软件业之间形成了令人生畏的隔阂，本该很容易上手的软件变成了冰冷的“高科技”产品，而很多人一旦入门，便自诩行家里手，开始复制自己摄入的陈词滥调，进一步加深这个险恶的分裂。

国内软件业的生态环境固然可悲，但我无意将此归结于任何人为的阴谋。多重因素与此有关：企业的急功近利，作者和开发者们长期以来忽视国外经典专著而偏好“简明教程（quick start）”，这些都导致了困境的形成。另外，我时常感到，翻译是国内开发者不得不面对的问题。归根结蒂，软件开发对我们还是一个新鲜的舶来品。不像数学、物理学中的语言因素已经近乎中性化，计算机科学有其自身的母语——英语。这一学科内的几乎所有概念都植根于英语丰厚的土壤中，并且还在不断地从母语中吸收养分。上述事实再加上技术上的滞后，造成了英美本土开发者相对于中国同行的天然优势：越是他们受益于修辞的力量，直观地把握前沿概念的地方，我们就越是感到枯燥甚至匪夷所思。国内的软件开发者是自己家中的流亡者，面对软件中的语言问题，我们忍受着双重的分裂：一方面，计算机科学说着别人的语言，原始文献中的概念都对我们疏而不亲；另一方面，当这些概念被搬回了家里，我们用中文接触它们时，我们又会觉得另一种生疏——这不是它们的原貌——很多次，我们甚至不得不将读到的中文回译为英语，再体会作者的“本意”。

重置感受力

如上所述，这里的困境是多重因素共谋的结果，因此摆脱这一困境也无法依靠任何“银弹”。一方面，软件工业无法绕开语言和修辞问题健康地运行，缺乏修辞素质的软件开发者，就像不会论辩术的律师，或是不会骗人的间谍，只能是可悲的赝品；另一方面，正如学者们指出的，语言是社会生活中最难控制的部分，兼具前卫和保守两张面孔，想要人为地扭转一种语言倾向，无异于徒手打开戈蒂乌斯之结（Gordian knot）。我尤其不是指每篇技术文章都要带上没来由的嬉皮笑脸（据说最近的一部译著中一个设计原则被翻译成“不要和陌生人说话”）——全然翻转一种错误的实践，得到的往往只是另一个错误。
在此我能谦卑地开出的药方只有“感受力（sensibility）”。我们的概念大厦，建筑在似乎已经死去的隐喻的珊瑚礁上，唯感受力，能使我们看到珊瑚中的骨骼、珍珠中的眼睛，唯有感受力能使我们直观到概念之下的修辞因素，在软件开发中把握活生生的语言。此外，究其本质，修辞特别是隐喻，意味着想象力，意味着探知事物间隐秘联系的能力。“Metaphor（隐喻）”在希腊语里是指“搬运”，用隐喻说话，就是要沟通相隔最远的两个王国，打破领域间人为、生硬的界限。我一直认为软件工业的活力，就在于它从其他领域不断地借用概念和方法论的能力。这也许是广义上的一种修辞学应用。
古语道，痴人面前不得说梦，在缺乏感受力和想象力，偏爱画地为牢的当代痴人面前，也许谈论健康的软件开发也是不可得的。但我仍幻想有一天，那些匆忙的IT人士在著译时、在给一个Java类命名时、在拼凑用户文档时能够突然停下来，感受一个词的色泽、重量和质感。或许他们能找回那支写程序的笔，或许，思维的另一种可能性将对他们开放。