CSDN博客

img kxiangli

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

发表于2003/6/27 14:53:00  1576人阅读

刘天北

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

写程序的笔

在今天,程序员和笔的关系相当尴尬。每当快递公司送来邮件,整个办公室就会发生一次短暂的骚动:我们需要足够的运气,才能找到一支笔在回执上签字。就像一个势利的大家庭里那位不受欢迎的表舅,笔在程序员们中间已经没有容身之处。
麦克卢汉的名著《理解媒介》详尽地描述了工具对人性的塑造和颠覆。一件工具引入的不仅是其实用性,更是人与世界、人与自身的一组全新的关系。用笔写作,核心在于 “物质感”。键盘输入是抽象的,具有一种近乎透明的“精神性”:随着击键,心中的概念似乎直接跃上了屏幕。而用笔写作时,手会感到纸的阻力、墨水的扩散和转向,由此而形成了“字体”或“笔法”。所有的人打出的字都相同,但是没有两个人的笔体完全一致。与这种物质感紧密相关的,是写作的风格和修辞学。从拉丁文开始,多数西方语言就用“笔”来指代“风格”。懂法语的朋友至今还可以清晰地听到“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类命名时、在拼凑用户文档时能够突然停下来,感受一个词的色泽、重量和质感。或许他们能找回那支写程序的笔,或许,思维的另一种可能性将对他们开放。

0 0

相关博文

我的热门文章

img
取 消
img