谈到写作，大家都公认“文笔”很重要。写出好文章，离不开好的文笔。大家也认为，文笔是种天赋。如果自觉没有这种天赋，也就和写作没什么机缘了。
在过去很长的时间里，我也是这么认为的。上学时每次老师夸奖“文笔好”的同学，我都很羡慕，也惋惜自己沾不上写作的边。然而这些年来根据自己写作、学习的经验和思考，我逐渐发现，文笔对写作确实很重要，但好文章要求的“文笔”，却不等于天赋的“文笔”。
按照传统的理解，“文笔”侧重于对文字、语词自身的优美的感知和运用能力。从小到大我们受到的语文教育中，“好的文笔”大概就是气势的排比、形象的比喻、优美的搭配……，总而言之，就是能让文章“漂亮”起来的手段。所以很多老师会鼓励学生用一个小本子记录“好词好句”，写作文的时候才有资料可用，才能体现好的“文笔”。好的段落之所以被挑出来，也是让大家学习这种“文笔”。目前许多中文写手所擅长的，也正是这个方面，甚至可以说“语感超强”，阅读他们的作品，常常可以被层出不穷的好词好句弄到眼花缭乱。这样漂亮的“文笔”可以通过积累背诵得到，但非原创的“文笔”常常不够新鲜、生动，好的“文笔”多是灵光闪现、语感爆发的结果。大家认为文笔离不开天赋，或许就是这个道理。
但是我们仔细思考就会发现，写作是将作者所想的内容表达出来的过程，所以“文笔”就是将这些内容具象为文字的本事，其实并不稀奇。传统上说的天赋的“文笔”（词句优美），其实不等于文笔的全部——好词好句或许能解决“漂亮”的方面，但表达不是只有“美”的部分，还包括“对”的部分，即规范性的成分。
写作的历史悠久，经过历代作者的贡献和积累，已经形成了相当多的规范性知识。如词语是否准确，句意是否流畅，段落衔接是否自然等等。它们好像刚性的骨架，深埋在文字里，虽然没有“天赋文笔”的美丽光环，却深深影响着作者意思的传达和读者的阅读情绪，保证整篇文字不会误入歧途，不会成为畸形。如果忽略了对这些规范性知识的学习和训练，写作时很难单纯依靠优美的文字“一俊遮百丑”。道理很简单——词句再优美，缺乏了“对”的基础，都不算“好”的写作。
不幸的是，我们总是强调文笔中的天赋部分，太看重“优美”，而忽略了“对”的部分。基础语文教育中很少认真讲到准确用词、严格造句、段落衔接方面的内容，更不要说专门的训练了。在成人写作的世界里，又缺乏足够有分量的批评，即便有 这种文笔方面的建议或讨论，也会被视为“吹毛求疵”、“不上正板”，显得“不入流”。所以即便已经成名的写手，也不愿意时间来锻炼和改善，因为这“不是问题”。结果，天赋的“文笔”再好，华美的盖头之下，总是可见糟糕的质料、粗糙的针线。不少所谓“文笔不错”的文章，读过之后只能留下几缕空洞的感觉，完全经不起推敲。
在词语的准确方面，不少知名写手也常犯错误，用“甚嚣尘上”描述好消息的传播，用“狼奔豕突”形容车流的繁华（用成语没错，但要用对，即便作者不理解原成语的意思，基本的“语感”也应该足够判断出“嚣”、“狼”、“突”不是褒义）；在句意流畅方面，我随手摘录一段：“老白带着我在山林里行走，天色阴暗，草木茂盛，几下就晕头转向了，简直跟不上他的步伐”，因为主语错位，读者要想想才能明白，“晕头转向”的不是“老白”而是“我”，所以应该改为“我跟着老白在山林里行走……”。段落衔接的问题也相当常见，许多作品里都可以读到“石头里蹦出来”的生硬段落，或者毫无征兆的转折表述。限于篇幅，我在这里无法摘录，但我相信仔细阅读的人对这种现象不会陌生。
作为反面的例子，不妨看看美国文学的情况。20世纪30年代以来，美国文学在世界上的影响力迅速增加。其中一个重要的原因，就是美国普遍开展了创意写作的课程，让更多普通人学会了写作，提高了大众的写作水平。翻阅美国创意写作的教材就会发现，它们强调的是“写作是一种工作而不是天赋”，要想写好，应当如此这般遵照规范进行，甚至详细到哪个场合用多少什么性质的词语才合适，都有讲解。写出《浪潮之颠》的吴军先生，也要特别感谢美国的导师对他写作的专门训练——如果“文笔”仅仅与天赋有关，那么遇到有文笔天赋的理科教授几乎是不可能的事情，遇见这样的教授就开了文笔“天眼”的更加不可能。但大家都认为《浪潮之颠》的文笔不错，可见依照规范训练的重要性。有意思的是，中文写作里常见的用词错误、句意混淆之类问题，同等水平的英文作品里确实较少出现，这或许可以从另一个侧面印证写作规范和训练的重要性。
在我看来，对写作水平不满意，而强调“文笔优美”，实在是缘木求鱼。对当前的广大作者来说，写对比写好更重要。如果大部分文章都能遵循写作的规范，都能够写“对”，哪怕词句不那么漂亮，也已经是广大读者的福音了。
按：感谢图灵出版公司，我得以整理自己之前写的翻译感悟，并加上自己的经验总结和学习心得，结集为电子书。此书暂定名《翻译漫谈》，近期将可以购买。以下是书中的一篇文章，欢迎读者提出宝贵意见。
传统上，翻译与文学的关系很近。说起翻译，许多人首先想到的是“文笔要好”。近年来随着信息交流的发展，实用型文本尤其是科技文献的翻译越来越显得重要，许多科技领域的从业人员也有兴趣或有动力翻译科技文献，并取得了大量成果，突出表现之一就是IT类书籍的翻译质量有了很大的提升，这背后的功臣很多都是IT界的“翻译票友”。
科技翻译是大大繁荣了，科技翻译自身的学问却没有相应的进展，各种翻译教程和经验总结仍然侧重于一般的翻译或文学翻译。然而深入了解翻译的人都知道，不同文体、不同领域的翻译，是各有特点的。比如新闻翻译追求简洁、准确、吸引眼球，文学翻译更强调完整、流畅、意境贴切。这种差异贯彻到翻译实践当中，产生了很多讲究，所以新闻才能译得像新闻，小说才能译得像小说。同样的道理，科技翻译也不能完全照搬普通翻译的做法，要想做好它，还必须了解其自身的特点。根据我的总结，科技翻译大致有以下几个特点。
第一，科技文献通常是用来讲道理的，所以译者必须准确理解文字表达的道理。
这里说的“讲道理”不是狭义的“说理”，而包括讲解原理、研究论证、实验分析等等，换句话说，科技文献的内容是可以用理性分析的客观现实，所以读者的理解也应该可以客观衡量。文艺作品没有这个特点，经常是“言有尽而意无穷”，可以“一千个读者就有一千个汉姆雷特”，科技文章则要求“有九分把握不说十分话”，必须“一千个读者只能有一个汉姆雷特”。所以，科技文献的译者不但要懂得原文，还必须准确理解原文。以前有几家出版公司的IT类翻译图书之所以被大家痛骂，很大程度上并不是因为译者的文字水平不够好，而是因为译者根本不懂也不愿意弄懂作者在说什么，这样的译文会被读者痛骂。
科学技术本身有客观标准可循，所以科技文献的意思理解起来反而比文学作品更容易，因为译者不必拘泥于原文。假设原文先讲了甲乙两个算法，然后下了比较的结论，译者如果不能确认作者的褒贬，完全可以根据之前的讲解进行逻辑推理，甚至可以亲自动手编程实践。要知道，逻辑和程序是绝不会因人而异的。推而广之，译者完全可以独立验证自己的理解是否准确，而理解准确恰恰是译文合格的前提条件。所以我建议，科技文献的译者在翻译完成之后，应当抛开原文阅读译文，想想是否能明白作者要讲解的知识、原理、规律，如果做不到，那么译文多半不合格。
Continue reading 科技翻译的特点
说起翻译，许多人都有兴趣。但真正能动手去尝试的人，只占其中的一小半；能熬过尝试阶段的煎熬，真正入门的人，更是少之又少。这种现象给不少人造成了错觉，认为翻译是件看起来容易做起来难的事情。但是根据我自己的经历和其它做译友的反馈，这话其实只说对了一半，翻译“做起来”并没有那么难。翻译之所以给人“做起来难”的感觉，很大程度上是难在入门阶段，难在一些基本问题没有解决。所以，这篇文章来谈谈大家关心的两个基本问题：第一，翻译是怎样的工作；第二，直译更好还是意译更好。
翻译是怎样的工作？
谈到翻译，许多人之所以感兴趣又不敢尝试，是因为自认“文字天赋不够，文学造诣不足”，总之，就是艺术修养不够。翻译是与文字打交道的工作，而“文字”总让人联想到“文学”。毕竟，在相当长的时间里，只有少数受过教育的人才识字，他们所追求的只有“经世文章”，而且公众所知的“翻译家”无一不是以翻译文学作品而著称；故而“文字”常常与“文学”和“艺术”紧密起来，由此把众多感兴趣的潜在译者挡在门外。
那么，想做翻译真的需要很高的艺术修养吗？当然不是。
Continue reading 浅谈翻译的两个基本问题
2012年末，我定下一个目标，从2013年起阅读全面电子化，尽量不买或者少买纸版书。到今年已经2年多了，虽然有时候还会买纸版书，但Kindle已经成了阅读的绝对主力（并且把我爸也变成了Kindle的忠实用户）。今天，我想谈谈自己对电子阅读的感受。
2013年确定转向电子阅读时，有几方面的考虑：一是方便保存，在南方纸版书很容易受潮起皱；二是方便查询，纸版书的检索难度相当大，尤其中文书籍大都没有编制索引；最后一点也是最重要最“好玩”的一点是，我希望真正了解电子化阅读的感受——按照我的判断，阅读的电子化是未来的趋势，但它绝不是“下载PDF/ePub到iPad上看”那么简单，到底是怎么一回事，只有逼迫自己深入其中才能真正体会到。经验证明，这种尝试是值得的，而且感受会要新鲜和丰富很多。
Continue reading 电子阅读之我见
大概六年前，我在一家名为“抓虾”的在线RSS阅读网站工作（如果你不清楚RSS阅读网站是什么，可以参考Google Reader）。阅读器都需要显示当前用户的未读数，抓虾的做法是给出精确的数字，明确告诉用户“你还有2456篇文章没读过”，Google Reader则显示为10+、100+等形式，告诉用户“我还有十多篇/一千多篇文章没读过”。初看看来，这只是一种普通的差异，但产品人员提出10+、100+的形式更好，原因我如今记不太清楚了，似乎是说这样给用户的心理压力更小，因为如果数字比较大，用户就不需要知道具体的数值，所以阅读体验更好。虽然程序员都并不认同这种理论，但因为分工不同，最终做开发的大伙还是完成了这个功能。“可想而知”的是，这个功能上线之后并没有带来明显的正面反馈。更好玩的是，过了一周，Google Reader的未读数竟然改成了准确数字！
前几周，我在twitter上说起这个故事，本来只是凑兴当个玩笑，收到的反应却出乎我的意料，因为反馈大都是对产品经理一边倒的负面评价。我又想到自己的一个朋友，他在某家以产品经理文化著名的大公司做开发，谈到理想的工作，他的要求是“找个产品经理少的地方就好了”。这样看来，程序员和产品经理的矛盾是普遍而且深刻的。
Continue reading 做个懂产品的程序员
前些年互联网上有篇叫《降级论》，建议广大IT从业者不要削减了脑袋挤移动互联网等等热门方向，换种思路，在“不起眼”的传统行业中寻找IT技术应用的广阔天地。这篇文章一登出来吸引了大量关注，按照作者的说法，降级论俨然是条通往幸福的康庄大道：
“这些原始而纯粹的行业，正在等待IT精英们的降级，如同蒲公英一般的伞兵，在黑夜里从天而降，长驱直入，用最智慧的产品、最优质的服务拯救这些早就该死的行业，屌丝的生命将会绽放出银色的羽翼，无比丰满，无比性感”
不幸的是，我见到的现象却非常奇怪：许多尚未投身的读者谈起“降级论”却满怀憧憬，真正敢于“降级下凡”并成功的却寥寥无几。仔细想想，无论从逻辑上分析，还是从自身经验来看，“降级”之路都不算坦途。根据我的归纳总结，IT从业者（“精英”这个说法略带刺激性，我觉得“从业者”更合适）走上降级之路，有几大困难是必然要经历的。
Continue reading 漫漫降级路
人和人之间各种错综复杂的关系，归结起来，可以粗略分为两类：强关系，弱关系。典型的强关系有终日厮混的死党，还有无话不说的密友；而典型的弱关系，有远房亲戚，“知名但未谋面”的朋友等等。这么举例，大家都比较容易理解。在现实生活中，可能很难清楚地界定强关系和弱关系的标准。但如果把关系搬到虚拟世界里，或者说在（互联网上的）“社交网络”中，因为方便量化，两者的分别就要明确许多。用我的话说，能留出专属时间且保持比较密切频度联系的关系，都可归类为强关系。除此之外，又不同于“纯粹的陌生人”的关系，都属于弱关系。按照这种分类，QQ好友、MSN联系人，就属于强关系，而论坛版友、微博关注对象等，属于弱关系。我相信，这也符合大部分人的实际情况。
如果我们仔细观察就会发现，上面说的强弱关系是就关系本身而言，但最终体现出来是落实在具体工具上的。一般人与QQ好友、MSN联系人之间的联系，天然就比论坛版友、微博关注对象要密切很多；而且，无论用QQ、MSN来保持相对松散的联系，还是用论坛、微博持续高密度地联系，都会显得很别扭。所以大家会用合适的工具来保持合适的关系。经常看到的例子有，如果在论坛上聊得比较投缘，就加QQ或者MSN好友。再比如，“陌生人交友”应用中的好友往往很少加QQ好友，因为大家不愿意成为相对私密信任的强关系。
Continue reading 强关系，弱关系
前几天在Twitter上有朋友问：ln的参数顺序要怎么记忆比较好，因为总是搞错。这个问题我也遇到过，以前每次都记不住两个参数的先后顺序，最终办法是花了点时间背诵命令模板，每次用到时心里默念就好了：
ln option target linkname
我没想到的是，搞混顺序竟然是个普遍问题，我本来以为哪怕有疑问，背背模板也好了，大家都应该是如此。仔细了解才发现，有疑问的朋友确实背下了OS X中的man，但这份文档写的是：
ln source_file target_file
看起来区别不大，用起来差别不小。因为做链接时，target既可以指“被链接的对象”，又可以指“生成的链接名”，和source_file之后就更容易混淆了。参与讨论的几位推友都认为我背的模板更好用（其实是我的运气更好，背诵时遇到了写得清楚的文档），因为另一个参数名是linkname，意义非常明确，所以哪怕target的意义和OS X中的完全不同，也不影响理解和使用。
Continue reading 闲话命名
说起API，做开发的人大概都知道也用过，我也是如此。不过除去使用，我还亲眼目睹过API制定，参与搭建过开放API平台，也与合作方商量确定过API方案；算是各个方面都有了解和经历，感受过让人啧啧称奇的赞赏，也经历过举步维艰的尴尬。目睹还有很多同行在API的泥泞里挣扎，我把自己的经验写在这里与大家分享。
大家都知道，API是Application Program Interface，也就是应用程序接口，看起来非常容易理解，实际却并非如此。据我观察，不少API方案之所以陷入了泥潭，就是程序员对API理解错误，把它看成了“对外开放的函数”：某个动作可能之前需要用户鼠标点击触发，现在开个口子给程序用消息触发，这就是API了；推广开来，现在流行的API化、开放平台的潮流，无非是多开一些这样的口子而已。
Continue reading 迷失自我的API
几年前，我从温伯格的《技术领导之路》中学到一点：技术人员往往更喜欢和机器打交道，因为他们“认为”自己更适合和机器打交道；但是，优秀的技术人员必须（也必然）具备好的沟通能力。所以，温伯格鼓励各位技术人员多加练习和其他人打交道的能力。温伯格的这个观点我是非常赞成的，好的技术人员一定需要“勇敢”面对他人，不能被“自实现的预言”局限在机器的世界里。
不过我也发现，“技术人员（当然我主要说的是软件开发人员）不适合跟人打交道”的负面影响不止于此，它还成了一种刻板印象（stereotype），进而影响到开发团队之外的人。这个问题其实很严重，它会导致其他人和开发人员沟通时自觉或者不自觉地切换到“和机器沟通”的模式上来，比如单纯依赖邮件而避免见面沟通，比如“你只管这么做出来就好了，别管我用来干什么”。以面向机器的模式来与人沟通，结果往往是完整的项目（而不是狭义的“软件项目”）割裂开来，皆不欢喜。
Continue reading 软件开发的人文关怀