超越阐释——技术文本的语言学解读

超越阐释——技术文本的语言学解读

■熊节

（本文首发于《中华读书报》2004年8月4日号）

---

　　 凡不可言说者，必保持沉默。

　　　　——路德维希·维特根斯坦　《逻辑哲学论》

　　圣奥古斯丁这样谈起人们学会自我表达的过程：“这样一再听到那些语言，按各种语句中的先后次序，我逐渐通解它们的意义，便勉

强鼓动唇舌，借以表达我的意愿。”在维特根斯坦看来，对世界的阐释如同孩童的一场游戏，而为这游戏制订规则的不是别人，恰好是语言，是人们言说事物的方式，是话语体系。如果赞同维氏的“语言游戏”论，作为读者的我们在阅读一部著作时，除了努力理解作者对世界的阐释之外，恐怕还有另一项任务：尝试解读支撑那阐释的话语体系——那游戏的规则。

　　在我们熟悉的领域里，一个最成功的话语体系就是模式（pattern）。“四人团”（Gang of Four，GoF）那本著名的《设计模式》让世界震惊的理由不是23个精巧的设计模式，而是一种对语言界限的超越——软件开发者们第一次认识到，有一种语言（即C.Alexander早在1970年代提出的“模式语言”）可以用于谈论他们的设计方案。诚如维特根斯坦所说，思想的界限只能由语言来划分，而界限之外的则是无法言说、因此也无法思考的存在。而模式语言的出现，让设计方案也成为了一种可以在会议室里讨论、在电子邮件里描述的东西。从那以后，并发模式、J2EE核心模式、分析模式、企业应用架构模式……人们开始用这个话语体系阐释越来越多的方案，就连不好的方案也被冠名为“反模式”（anti- pattern）。作为游戏规则的语言，其威力可见一斑。

　　话语的力量从何而来？很大程度上应该归功于隐喻（metaphor）。对于一个陌生的领域，人们总是用众所周知的事物来近似地影射这里的新事物，以期获得基本的感性认识——想想“Facade模式”和“Builder模式”，你便不难理解隐喻的价值。另一个司空见惯的隐喻就是“软件工程”。1960年代，当软件的危机表现为机械性生产效率低下时，人们睿智地采用了“工程学”的隐喻，并就此发展出一套软件工程的话语体系（譬如“分析师” 与“程序员”的二元对立）。然而，在享受一个隐喻带来的种种方便时，我们仍然需要时时牢记隐喻作为隐喻的本质——“光阴似箭”是一个隐喻，如果一定要在喻体的角度上对这个隐喻加以阐释，恐怕你很难说出这支箭是什么样子。同样，对于技术书籍中显而易见的隐喻，也存在着类似的误读。譬如FredBrooks所说的“没有银弹”，如果一定要从数字的角度去阐释它，又怎能把握住作者原本想要传播的理念呢？——即便真有某种技术能够以数量级提升生产率，难道软件的 “根本问题”（真实世界与软件模型的映射）就能一劳永逸地解决了么？

　　既然思想的界限由话语决定，顺理成章地，如果要提出新的思想，这位作者可能首先必须扮演“话语的颠覆者”——这恰好是Pete McBreen在他的《软件工艺》中扮演的角色。作为思想的传播者，他面临的第一要务不是阐释自己的理论，甚至不是以正确的方式提出自己的理论，而是为他的读者提供一套可以用于思考这种新思想的新话语，一个新的隐喻。譬如这本《软件工艺》，“工艺学”的隐喻真的优于“工程学”吗？甚至于，“工艺学”是一个好的隐喻吗？这并不重要。重要的是，Pete McBreen扩展了软件的语言界限，让他的读者有机会超越软件工程的阐释之外，从另一种角度去审视、去思索、去讨论软件开发的实践。

　　《软件工艺》对于话语体系的这一颠覆和扩展，即使从最保守的角度来说，也是意义深远的。因为“人”的问题——软件开发者的职业生涯规划、软件开发者的持续学习、软件开发者自身价值的诉求……这些明显个人性的、带有某种亚文化气息的问题，乃是软件工程的“不可言说之物”——软件工程并没有提供谈论这些问题所需的语词。而这本《软件工艺》的最大价值就在于它开宗明义地指出：软件工程本身并没有错，只是我们不能试图用它解决一切问题——尤其是那些位于软件工程话语体系之外的问题，也不能对这些问题置之不理，而是应该用一种恰当的方式、一个恰当的隐喻去谈论它们、解决它们。至于书中那些极富煽动性的观点和主张，在我看来只是——就像麦克卢汉所说——吸引注意力的诱饵。只要接纳了软件工艺的话语体系，是否赞同诸如“软件工匠应该拿到最高的薪水” 之类的观点又有何妨呢？

　　苏珊·桑塔格把她的一篇文艺评论命名为“拒绝阐释”——艺术的价值不在于“道德的感受力”所看到的内容，而在于“审美的感受力”所体味到的美感。同样，即便摆在面前的文本打上了“技术著作”的标记，当它的意图是要引介一种全新的思维时，我们也必须超越理性的阐释，用审美的眼光、用心去体验它带来的话语冲击。如果一位热心而谨小慎微的批评者尝试用现存的话语去阐释一位“话语颠覆者”带来的理念，恐怕他最好的选择也只能是保持理智的沉默了。因为，那是他的不可言说之物。