2007年的某天，韩磊给我发来一段古怪的文字，讨论翻译。说古怪，因为诗意的笔下，分明是技术的文字： Public static void：无数个Java程序代码块中，都有这串密语存在。这串词有特别的技术含义。不过我常常把它看作一首机器诗篇，在它召唤出的冷宫里面，多少软件项目一开始雄心勃勃，最终却未结善果。 “这是什么书？”，我不禁好奇。 “Dreaming in code，第0章，我正在翻译。” 第0章？是了，了解计算机的人，看到这样的编号，多半能会心一笑吧。 软件工程的课本大都会讲到IBM那个失败的工程：巨额的资金，大量的开发人员，漫长的开发周期，却不能避免失败的命运——到最后，项目就像在泥沼里挣扎的恐龙，越挣扎，身上的泥就越多，陷得就越深。没有亲身体验过的人，往往会觉得不可思议，念书的时候，我就是这么想的。2005年春夏，延庆的某家宾馆里，程序员聚在一起，夜以继日地封闭开发，期限到了，预期目标相差甚远。撤退那天，大雪纷飞，被挫败感包围的我，无比真切地怀念泥沼里挣扎的恐龙。 然而，慢慢的经历多了，却发现，能够按时、按质、按预算交付的项目，往往是异数；所以Software Craftmanship的作者，不会说“投入”人力、物力、财力，他的用词甚为传神：throw in。播下龙种，收获跳蚤，这在软件世界竟是个常见的现象——两打程序员，3年时间，4732个Bug，只为打造超卓软件，却不得善终；所以Dreaming in Code的作者要问： 编程已不再处于萌芽期。我们的世界依赖于无穷复杂的软件。在长达半个世纪的研究和实践之后，为什么还是很难做到按时限、按预算做出计算机软件？为什么还是很难让软件可靠而安全？为什么还是很难把软件做得易于学习使用，且具备按需修改的灵活性？这只跟时间和经验有关吗？是否有出现某种根本性突破的可能？在软件的本质特性（抽象性、复杂性及延展性）上，是否存在某种总能打倒我们的无常之物，将开发者咒入充满不可挽回的延误和根深蒂固的缺陷的世界？ “软件难做，”编程界经典教科书的作者高德纳（Donald Knuth）这样写道。但原因何在？ 关于这本书，尤其要提到的是，作者罗森伯格，编程写作，两手俱佳；这悲壮的故事，由他剥茧抽丝，娓娓道来，独具魅力；故事之内，更穿插关于技术的精当点评，教普通人能看个热闹，内行人能看个门道，各取所需，各得所乐。译者韩磊亦是文理兼修，笔法精纯；去年，我多次向他抱怨翻译《精通正则表达式》之枯燥，他也谈起自己正在翻译Dreaming in…
文学与其它艺术形式的区别之一就是，在文学中，除了文字所要传达的意图可以构成审美对象之外，文字（也就是介质）本身，也可以构成审美的对象；也就是说，意象和介质（目的和手段）构成了文学的双重审美。很多时候，我们说文章写得“漂亮”，就是针对手段（文字）本身而言的。 这也就造成了翻译中的一大困难：既要保证传达意义（目的），又不能丢失文字（手段）本身的美感。想要做到两全其美，许多情况下是不可能的，只能在二者间权衡、取舍。若过于看重形式，极有可能严重损失原文的信息，下面举几个常见的例子。 我思，故我在 这是笛卡尔的名言，英文版本是 I think, therefore I am “我思，故我在”凝练大方，有格言的味道，又契合乐府的节律，往往被奉为经典，然而它其实是不对的。 因为这里的am（也就是be），并非“在”的意思，即便是如今学界通行的译法“存在”，也不宜被简化为“在”。况且，be翻译为“存在”，是否合适，还值得商榷。 如果完全抛弃形式的束缚，这句话的意思大概是“我思考，因此才成为本体（真正意义上的自我）”，王太庆先生翻译为“我思，所以我是”，这建议是不错的。 权力导致腐败，绝对权力导致绝对腐败 这是阿克顿勋爵（Lord Acton）的名言，琅琅上口，雄辩有力，如今广为引用。不幸，这翻译有两处错得厉害。 原文是 Power tends to corrupt;…
按：这两篇文字是2005年所作，今天意外收到一封来信，说“忽然见到此文，有豁然开朗之感”，于是转过来，放在自家园地。 关于翻译的一点杂感 (more…)