02.08.07
Posted in 旁观者语 at 1:14 am by 李建忠
我对查封最直观的感受来自于小时候小伙伴中有一个大个（乃因个头比较大而得名），只要有人说的话他不同意或者不高兴，他就会过来抱着对方的头捂住嘴，不让对方说话。不过由于我有一位哥哥，这位大个对我还有三分敬意，但是我对如此野蛮的方式记忆犹新，并且只至今天仍在延续。
1999年，五四前夕，我每期必买的《方法》杂志被查封。我给北京的编辑部打电话，与主编通话，给作者写信。尽管我知道我的努力无济于事。
2001年，五四前夕， 我一直认为是中国良心的《南方周末》被查封（虽然刊名得以保留，可是整个编辑部已经不复存在，整个报纸完全变味）。我在各个场合发泄愤怒。
没有什么报纸和杂志可读，索性只能读书。可是很快我发现我所读的一些书也不能幸免。《现代化陷阱》（何清琏），顾准文集（顾准），《耻辱者手记》（摩罗）…… 慢慢地，好书越来越少，我读书的时间也越来越少。
后来，我在美国读到更多的书，更多的历史呈现眼前。我愕然，惊怵，痛苦。
再后来，虽然已经将大多数时间投入计算机，仍然间或有查封的消息被我不幸撞上。
2004年，春季，《中国农民调查》（陈桂棣、春桃）；2005年，年底，《新京报》； 2006年，春节前夕，中国青年报《冰点》；2007年，春节前夕，《伶人往事》（章诒和）。
其实，不幸的岂止仅仅是报纸或图书。比如今晚就连我google河南（我深爱的故乡）艾滋病维权人士高耀洁，我的网络也随即惨遭不幸。
多少年了，这样的故事仍然在一遍遍上演……
每一个故事背后都有一群深爱这片土地的仁人志士，或摧毁、或受伤、或流离……
Permalink
11.11.06
Posted in 三味书屋 at 9:31 pm by 李建忠
这段时间比较忙，今天刚歇脚下来，课下几个学员聊天，发现5月份的一篇blog竟然引起一些风波。简单声明如下：
1。感谢大家对我的厚爱和信任，这让我走到天涯海角都很受感动，充满力量。但是，希望不要将对我的厚爱转化成语言暴力。在没有仔细看书之前，对图书的任何评判（尤其是大加鞭挞）都不公平。
2。希望大家关注书的质量，而不是译者的名字。我个人与这本书翻译上的不快 != 现在这个译版不可接受。如果书翻译的有问题，建议读者像我当年一样写一篇专业的书评；如果书的翻译不错，大家应该热情鼓励。
3。不希望《CLR Via C#》一书的出版风波来承担大家对中国计算机图书出版的整体痛恨情绪，这也不公平。
4。译者并不应该是书籍出版的重心，作者才是。读者对译者超乎寻常的关注实际上反映了国内出版界的病态与混乱。我希望出版界能够进步到随便一本书，大家都不再去关注是谁译的。
5。对于这本书的翻译风波无关稿酬高低的问题，我只是不喜欢谈判的角度、态度和立场，更不可接受这其中的道理。出版商应该走出自己的老大心态，给作译者以切实的尊重。真正搞计算机的专业人士不在乎稿酬。但是不在乎稿酬并不等于应该将此奉献给出版社。中国有很多的地方需要奉献，但不是出版社。
6。中国计算机图书市场混乱的原因不仅仅是出版社的责任，读者也要负很大责任。随意地掏钱，不负责任地买一些自己根本看不懂、最后导致不去看的书，就是在“鼓励劣币，驱逐良币”。
7。国内计算机图书界的混乱不是舆论问题能够解决的——尤其是这样的舆论最后往往转化成语言暴力。我更希望用市场经济的法则来解决，这个法则要靠读者的群体性觉醒，用自己的购买行动来投票。
8。慎重买书是对作译者最好的褒奖，净化出版环境的最佳手段——不要盲目买书，在购买图书之前，多听有经验的朋友之言、多看专业书评。如果真的不知道该购买什么书，给我写Email（联系方式），我会帮你推荐。
9。再次感谢大家的厚爱，在软件开发图书和培训教育方面，我会继续前行。在图书方面，我已有很多心得和积累，很多已成草案，我会倾全力用最精彩的原创书来回报大家。
Permalink
09.06.06
Posted in .NET技术 at 12:09 am by 李建忠
忙碌告一段落，终于有闲暇可以摊开时间来读一些书，另外除了补充以前草稿的同时，也开始考虑新的作品。
这两年来，越来越多的国内软件企业开始深入.NET底层开发，我也接到了不少企业的深度.NET培训邀约，在培训课程方面也有较为成熟的积累。决定动笔写作《.NET内核揭秘》（暂定名）一书。目前大致蓝图如下：
1. 对象里面到底装的是什么——揭秘.NET类型封装
议题：程序构造的历史；代码段与数据段；对象、数据成员与函数成员；.NET对象到底有多大；.NET对象布局；简单值类型；string揭秘；数组揭秘…..
2. 程序运行之来龙去脉 ——揭秘CLR虚拟机执行系统
议题：JIT编译如何进行；系统如何加载类型；堆栈模型；如何使用应用程序域隔离代码；异常如何层层抛出…..
3. 对象的前生后世 ——揭秘.NET类型继承
议题：子类从父类继承了什么；子类与父类之间的类型关联；为什么可以将子类看作一个父类；静态类型与动态类型……
4. 不要调用我，让我来调用你 ——揭秘.NET多态机制
议题：callvirt如何调用虚方法；虚方法表上都有什么；虚表指针什么时候使用；虚方法效率到底有多低….
5. 数据与代码的博弈 ——揭秘.NET委托调用
议题：委托如何实现动态调用；委托类型内部构造；委托调用的效率；异步委托调用……
6 托管对象的生与死 ——揭秘.NET垃圾收集
议题：垃圾收集器如何分配内存；垃圾收集器如何构造对象图；垃圾收集器如何搬移内存；垃圾收集器如何更新托管引用；垃圾收集器的性能到底如何…..
7. 插上元数据的翅膀 —— 揭秘.NET反射机制
议题：元数据是什么；元数据在哪里；如何反射类型；反射类型内部是什么；反射的效率到底有多低；反射的边界在哪里…..
8. 运行时泛型的算盘 ——揭秘.NET泛型实现
议题：泛型类型到底是什么；泛型类型与元数据；泛型类型到底如何实例化；泛型的约束与效率…..
如果这些问题是各位面临.NET所困惑的，我希望在本书中能够解答大家的疑惑。印象中有些读者对《.NET框架程序设计(修订版) 》深感不满，甚至有的大加鞭挞，感觉写的太浅。我想这本书能够满足这些读者的胃口。——不要误会，作为《.NET框架程序设计(修订版) 》早期的读者和译者，我对这本书当然心存敬意。我只是想以一种不同的视角来写作一本书，谈清楚一些模糊的东西。
这本书是像Bill Venners《深入Java虚拟机》那样的IL指令释疑手册么？不是，这是一本讲道理的书。这本书每一章我希望讲清楚一个普通的道理，当然证明这个道理的过程将扣人心弦——我不希望讲抽象的道理，而是直接展示相关数据结构——需要大家屏住呼吸来读:)
如果愿意，大家可以部分地将此书看作是Stan Lippman 《Inside C++ Object Model》的.NET版。但是，也不完全是，因为，.NET中复杂的将不仅仅是CLR Object Model，而是整个虚拟机平台。
一如既往，由于工作原因，我无法确定这本书的准确出版日期。但是，我对图书最后的品质一定高度负责，不到自己满意的地步，我不会贸然出版。
BTW，本来打算的书名为《不谈抽象，只谈底层》，但是考虑这样的书名本身过于“抽象”了:) 《.NET内核揭秘》虽然还算表述清楚，但是这样的名字在乌烟瘴气的国内出版界确有点俗不可耐:) 当然，如果有朋友有更好的书名建议，我非常乐意采纳，并在图书出版时赠送一本以表谢意。 当然更欢迎对图书纲要以及随后的内容提出修正意见。
Permalink
09.04.06
Posted in .NET技术 at 12:37 am by 李建忠
接到一位前不久C#培训学员的来信，这位学员虽然以前功底欠缺，但学习劲头很足，在培训中成长很快。即便基本吃透《.NET框架（修订版）》还嫌不够过瘾，一心要成为高手中的高手。来信的目的是希望我来指点进阶方向。
说实话，我一般不想在这些有关个人发展的大是大非的问题上给人指导，因为太多亲身或眼见的经历告诉我人生实在是很难捉摸，善良、智慧、勤奋这些我们珍视的品格常常会碰到可怕的现实。我感觉我鼓励一个人的时候，我只关注到了“程序正义”，并没有多大的信心向他保证“结果正义”。人生不像软件，可以在好的设计下有一个好的产出。
但我又不想让后学失望，也就冒昧地写下了下面一点个人浅陋的心得，摘录一段，接受各位朋友的检阅：
……
不谈具体领域（比如搜索，视频，网络等），单就编程语言这个垂直方向，我大体上对它有一个如下的层次划分。
1. 基本运用C#语法，在各种工具和示例代码的支持下，完成一些基本程序任务
2. 熟练掌握面向对象与组件构造，知其然亦知其所以然，完成一般小规模信息管理类软件项目开发任务
3. 深入理解CLR内核机制，对各种类型与.NET平台机制的优缺点、适用场合、效率有清晰把握，能够完成技术复杂度比较高的项目。
4. 能够游刃有余把握松耦合原则,精准运用各种语言构造，架构大型软件项目。
5. 能够站在计算机抽象、系统和历史发展的高度来理解和把握编程语言
我判断你现在大致介于2-3之间的位置，当然在这些方向上的成长，有些部分是培训能够大幅度帮助大家的，有些部分培训只能起辅助作用，经验和对技术的追求态度才更为重要
……
说实话，编程语言本来不该这么重要，但是现在接近两年的培训经验下来，接触的培训学员林林总总，从最底端几乎没有什么编程经验的，到高端的在企业担任关键开发任务的。发现在中国，编程语言事实上是大多数开发人员的硬伤，大部分程序员介于1-2之间——原因就不多说了，中国大学的计算机教育只有在一个人彻底理解了计算机之后才会深刻体认到它是多么的荒谬和失败。
可能是受早年蔡元培、梅贻琦等先贤的熏陶激情而发，两年前开始以做教育的心态趟上了软件培训这浑水，两年下来着实辛苦，然看着现实在努力下一点点改变，固然不大，却倍感欣慰。
Permalink
06.05.06
Posted in 程序人生 at 11:29 pm by 李建忠
今天看到《南都周刊》上一篇文章《文学界反击思想界：不懂就别瞎说》，文章挺长，读起来很累，不过挺着还是读完了。感觉这种声音肯定要有，但是具体有了又感觉挺可笑——在当下中国，谁又比谁更有资格指责别人脱离现实，缺乏思想呢？除了鲁迅那样一个野草丛生的时代，在中国历史上，文学大概从来都不是来源于现实，而是来源于需要；也只有宣讲，没有思想。中国文学也从来没有立足于世界之林。对于一个伟大的国度，想起来令人蒙羞。
不过想想也不能全怪没有好的作品。回头看看我的书架，技术书和经管书确实是在日积月累，但是新添的文学书已经很少很少了。这怪不得IT，也怪不得社会节奏。我记得前年Lippman在email中告诉我他在飞机上读一个小说，下了飞机仍然伤心的不得了。去年接待Bjarne，在房间也看到案头放着很隽永的文学书，不禁愕然。回头想想自己，已经很久没有碰到海子的诗集，路遥的《平凡世界》，余秋雨的《文化苦旅》那样的兴奋和沉浸了。以前珍藏的一些文学书，也送的送，丢得丢，借的借……
在技术的天地驰骋的越远，偶尔回首总会感觉到少些什么。今晚就是这样一个时候。
到底是因为我已经失去了文学的需要？还是当下已经很少有真正的文学？拟或二者进入了死循环？
Permalink
05.22.06
Posted in 程序人生 at 11:08 pm by 李建忠
接到一位读者朋友的来信，告诉我他在各个编程语言之间徘徊了很长时间，最后在Google Trends的启发下终于选择了Java。
事情缘于这位朋友大概一年前给我写了一封email，问我选择哪门语言合适，我当时给他的回答是“随便选择哪门语言都可以，关键是选好一个方向好好深潜下去”——虽然回答的很简单，但是我的回答并不随便，确实是我真心这样认为。
不过，这倒让我对Google Trends的这个语言分析产生了一定兴趣。我当然不会看到这个图就直截了当地认为Java最值得选择，C++就一文不值。我也担心这个Trends会误导人，因此提供以下各种不同思路的解释供大家咀嚼——首先声明，这是一个关键字搜索趋势图，哪个曲线代表的语言高（比如Java），表示哪个语言的搜索量大。
1. 搜索量大，表示这个语言有前途。搜索量少，表明这个语言正在没落。
据此的结论是：Java最有前途，VB，C# 次之, C++比较没落——想到我们可爱的Bjarne又要不高兴了:)
2. 搜索量大，表示这个语言网上相关的资料多。搜索量少，表明这个语言的资料少。
据此的结论是：Java免费学习资料最多，VB，C# 次之, C++比较少——C++阵营和微软阵营都要努力，差别在数量级啊！
3. 搜索量大，表明这个语言方面找工作的人比较多。搜索量少，表明这个语言方面找工作的人少。
据此的结论是：大家抢破头了去找Java的工作，VB, C#次之，找C++工作的人比较少——供求关系决定物价水平：搞Java的要小心了，身价要跌了；搞C++的尽管高枕着高薪无忧吧，掌握C++，走遍天下都不怕！
4. 搜索量大，表明外界对这个语言最陌生。搜索量少，表明外界对这个语言非常熟悉，不需要搜索——因为真正的程序员是很少去简单地搜索Java, C++这样的关键字的；搜索这些关键字的都是外行人。
据此的结论是：Java的普及工作做得最差，VB, C#还可以，C++嘛地球人都知道——姜还是老的辣！
5. 搜索量大，表示这个语言社区的人比较无能，因此只能依赖google来学习技术——依赖简单（而不是复杂的关键字）的关键字搜索，技术水平一定比较低。搜索量少，表明这个语言社区的人比较厉害，全靠自己研究捉摸，对google搜出来的技术知识不屑一顾。
据此的结论是：搞C++的人最牛，C#, VB 次之，搞Java的too simple, sometimes naive:) ——Java阵营的不要生气，C++阵营也不应该沾沾自喜
6. 搜索量混入了很多不相关的数据.
据此的结论是: 去“爪哇岛(Java Island)”旅游的人很多——Sun公司应该给爪哇岛(Java Island)政府捐助一些广告费。
各位看官，您认为那条分析正确呢？请在下面跟贴投票，或者你有更好的分析么？谢谢:)
特别声明：本人不提供正确答案:)
上面仅仅是调侃一下，只是想说明选择语言并不能人云亦云，google云亦云。话说回来，我没想到我看上去“随便”的回答，让这位朋友整整花了将近一年时间来选择编程语言的学习对象。我感到很惭愧，没有帮这位朋友节省宝贵的青春时间。
今天在Satyam Development Center做.NET培训，讲了整整7个小时，比较累了，不过很开心，和“企业级”学员讨论问题比较爽:) 不过我会在下面找个时间好好分析一下各种编程语言，帮助初学者节省一些时间，我觉得我应该有这个责任。
Permalink
05.17.06
Posted in 旁观者语 at 10:47 pm by 李建忠
除了计算机和数学，我对历史和法律比较感兴趣。无它，除了生活在数学与计算机的唯美空间之外，我更是生活在当下，生活在身边的乡土。在当下的中国社会，如果失去对历史和法律的认知，我便感觉失去了一种根植于这片土地的生命力。
在早年的学生时代，喜好历史可以说仅仅处于对故事的兴趣甚至谈资的需要，但当后来有一天我发现从正常渠道获得的是残缺不全、被阉割的历史之后，我便近似疯狂地用尽各种手段翻阅种种历史资料，了解越多的真相，越让人窒息。
我不喜欢中国文人的悲情主义，当我窒息于历史的阴霾中绝望时，我便寻求对这种阴霾的救赎之路。因为这种阴霾不仅仅存在于历史，更是存在于现实。我对法律的兴趣便来源于此，我甚至有一段时间一直想投身法律。这种想法虽然没有变成现实，不过却实实在在让我成为一个法律中人。
虽然无缘投身法律，我对于法律的进展和法律事件还是非常关注：第四次宪法修正案（人权概念首次入宪），物权法，孙志刚收容案，宝马车撞人案，刘涌黑社会案，湖南黄静被害案，等等。尤其是后面几项个案，每一个案情都触目惊心。不过我更关注的是“法律的缺位”，这些浮出水面的案件最后的解决（有的还未解决）都不是通过正常的法律渠道。我一直为此耿耿于怀，因为我知道肯定还有更多的没有浮出水面的案件。有接近法律圈的朋友告诉我，如今在中国没有人愿意做此类案件的律师，是绝对的“高风险，无回报”，与IT业的“低风险，高回报”天壤之别。但我总还对律师这个职业报有敬意，心存希望。
不过今天看到的一则新闻 《律师受理拆迁等群体性案件应告知政府》，赤裸裸的文字，开了法律一个大大的玩笑。终于让我明白了什么叫“高风险，无回报”。我没有为自己最终无缘法律工作而感到庆幸，只是感到一种更宏大的悲哀。
Permalink
05.08.06
Posted in C++技术 at 12:07 am by 李建忠
这两天抽空在审校邓际锋（soloist）先生翻译的Bjarne Stroustrup为Embedded software and systems. 2005写作的《 Abstraction and the C++ machine model》一文。结合自己一段时间的C++培训经验，对C++的抽象有了更多的思考，在此作一简单总结，与朋友们交流。
为了将问题谈清楚，首先来谈谈抽象（Abstraction）这个词，wikipedia对Abstraction有如下解释：
Abstraction is the process of reducing the information content of a concept, typically in order to retain only information which is relevant for a particular purpose.
简单来说，就是“去粗取精”，或者“去不相关，取相关”。
这“一去一取”的目的何在？wikipedia也给了很好的解释：
Complexity reduction
Abstraction typically results in complexity reduction leading to a simpler conceptualization of a domain in order to facilitate processing or understanding of many specific scenarios in a generic way
总体而言，前面摘自wikipedia的两段话非常扼要地说明了“抽象”在我们认识事物过程中所扮演的关键角色——推开来说，人对世界的认识，实际上就是一个不断“抽象”的过程。“抽象”的力量普遍存在于各种学科，各个领域中。当然，具体到各个学科领域还是有一些具体的差别。
好，下面来具体谈谈C++中的抽象，或者说编程语言的抽象。从最根本性的目的来言，计算机就是对人的一种抽象——当然Turing的这个美好愿望要靠程序员来慢慢实现。编程语言在这个过程中扮演的角色就是将 “计算机容易理解的东西”抽象为“人容易理解的东西”。结合目前主流的编程语言（C++, C#, Java, VB.NET 等），举些例子具体来谈其中的抽象，就是让程序员：
基本的编程抽象
* 忘掉数据（无论对象/指针/引用）在内存中的地址，将精力集中在数据所表达的类型实例概念上
面向过程编程的抽象
* 忘掉函数调用的压栈/出栈细节，将精力集中在函数之间的调用关系上
基于对象编程的抽象
* 忘掉对象中数据成员（字段）的内存布局，将精力集中在数据成员对对象状态的表达上
* 忘掉对象中函数成员（方法）的绑定机制以及this指针，将精力集中在函数成员对对象行为的表达上
面向对象编程的抽象
* 忘掉类继承下子类对象中数据成员的内存布局，将精力集中在继承所带来的子类化的概念上
*忘掉虚函数相关的虚表vTable结构，将精力集中在虚函数所带来的动态多态的概念上
泛型编程的抽象
* 忘掉模板的各种编译与绑定机制，将精力集中在用一组抽象的概念来表达一组类型的需求条件上
面向组件编程的抽象
* 忘掉组件平台背后的元数据等机制，将精力集中在组件化模块所表达的黑盒概念上
这些“忘掉…而将精力集中在…上”的“抽象”放到C#, Java, VB.NET 等其他语言中，很多程序员都可以轻易做到——换句话说，可以不关心“各种抽象背后所映射的底层机器模型”，只关心语言表达的“抽象”，而照样开发出合格甚至优秀的程序。这样，这些语言下的程序员基本上遵循下面的学习路径，就可以成为一个合格的程序员：
掌握语言语法构造–>掌握设计思想（即抽象）–>开发应用程序 或者 程序库
但是如果放到C++，一个程序员无论如何不能够做到“忘掉…而将精力集中在…上”的“抽象”，否则连写出哪怕是正确运行的程序都很难。一个合格的C++程序员必须遵循下面的学习路径：
掌握语言语法构造–>掌握各种抽象所映射的底层机器模型–>掌握设计思想（即抽象）–>开发应用程序 或者 程序库
这就是C++中“抽象”的问题！C++程序员无法摆脱“各种抽象所映射的底层机器模型”而将精力单独集中于“抽象”上——换句话说，C++的抽象性和它的底层性是C++的一体两面，不能够像其他语言一样轻易分开。
那么是什么导致了C++这种独特的“不够彻底的抽象”呢？这种“不够彻底的抽象”到底有什么优劣呢？
Bjarne Stroustrup 在《 Abstraction and the C++ machine model》一文中重复了他在设计C++时一贯的哲学：
* 在切实可行的最高抽象层次上编程 Work at the highest feasible level of abstraction
所谓“切实可行”就是不损及效率，灵活，管理……简单地说就是C++希望在获得“抽象”的同时，仍然尽可能地不损失任何效率。C++一路发展过来，确实达到了这个目标。这正是C++“不够彻底的抽象”之原因。
这种“不够彻底的抽象”当然为C++赢得了巨大的成功，使得C++成为系统级软件的首选语言，是任何其它一门语言都无法望其项背，参见这些重量级的软件http://public.research.att.com/~bs/applications.html。
但这也使得C++在程序员圈子里一直是公认的难学难用。孟岩在C++开源程序库评话（节选） 中谈到用C++写优秀的程序库非常难这一事实。可惜只谈了“难”的结论，没有谈“难”的原因。事实上，C++并不仅仅在写程序库时难，用C++写应用程序同样不会轻松–相对其他语言而谈，只是C++写程序库要同时考虑的“抽象性和底层性”思维力度更大罢了。所有的根源都在于C++这种“不够彻底的抽象”。
我不知道“C++的抽象性和底层性这种一体两面的紧密结合”会在多大程度上损伤C++程序员学习的积极性，并从而影响C++应用的popularity，以及影响软件项目的质量和进度。 但至少对于目前希望成为C++程序员的朋友来讲，必须认识到“需要同时掌握C++语言抽象性和底层性”这个事实，才能将C++彻底掌握好，这也是我在目前不管是给企业，还是个人学员讲授C++培训课程时经常强调的。
当然，C++社区也意识到了这个问题，C++0x 也确立了一项“同时为专家和新手提供支持”的原则，参见Bjarne Stroustrup在去年C++软件技术大会上的发言《C++0x概览》。但是从目前来看，这个原则贯彻的并不能令人满意。例如，我不太相信如果一个C++程序员不清楚理解指针，对象，模板，concept（C++0x中的新东西）等所映射的底层机器模型，就能够轻松写出Bjarne在《C++0x概览》一文中最后演示的那个draw_all()的例子——虽然Bjarne Stroustrup期望所有C++程序员都认为它“如此简单！”
也许我们本来就不应该对C++期望太多，既想让它有极致的效率来构造系统软件，又想让它有纯然的抽象来满足变化无常的一般性软件开发——世界上好像没有十全十美的事情，当然也没有十全十美的语言:)
Permalink
05.06.06
Posted in 三味书屋 at 5:03 pm by 李建忠
最近陆续有不少读者朋友写信来询问Jeffrey Richter的CLR via C#, Second Edition 一书译本的问题，也就是Applied Microsoft .NET Framework Programming-Microsoft .NET框架程序设计(修订版)一书第二版的翻译。我想在这里对此问题作一点交待。
Applied Microsoft .NET Framework Programming确实是可读性和教育性极高的一本.NET技术经典。第二版改名为CLR via C#。由于第一版为我所翻译，某出版社前段时间便和我联系翻译事宜。由于工作比较忙，便委托助理帮我谈。谈了几天后助理告诉我出版社坚持第2版的翻译以“整理费+翻译费”来结算，并且暗示如果我不翻译，那么出版社将找其他人来“整理”我的第1版中翻译的文字。
所谓“整理费”是指第一版我原来已经翻译的文字，由于同样出现在第2版，因此有“整理”之说，当然“整理”的报酬要远低于“翻译”的报酬，其逻辑在于“出版社认为我已经在第1版中获取了翻译的报酬”。所谓“翻译费”是指新添的文字，从目录判断（原文我没有看到）第2版整个篇幅确实修改不算大，大概100多页新添的东西。
出版社的逻辑是：既然译者已经在第1版中获取了翻译的报酬，那么第2版同样的文字便应该“奉献出来”，而不应该再领取报酬。我并非一定要计较其中的报酬得失，只是这样的逻辑和名堂让我感到非常可笑。
为什么我们的出版社总以“无私奉献的雷锋精神”去要求作译者，但实际上却将这种“别人无私奉献所获得的利益”收入自己的腰包？坦白来讲，我也很有奉献精神，也常常体会到奉献的快乐。但是这种在出版社“胁迫”下的“奉献”，我怎么也快乐不起来。如果出版社确实真有奉献精神，那可以在要求译者不收取合理的翻译费用的同时，是不是也应该将第2版的书直接免费赠送给购买了第1版的读者？如果真有这样的出版社，我非常乐意免费翻译。
在对此“奉献逻辑”感到可笑的同时，我也特意让助理查询《中华人民共和国著作权法》，事实证明法律支持我的看法——还好，中国确立了依法治国的方略。
自然，我无论如何也不会接受这种“奉献”+“胁迫”的谈判，因此我很干脆地放弃了CLR via C#, Second Edition的翻译，同时正告出版社，未经我的授权，没有理由在我第1版的基础上“整理”，因为我只授权《Microsoft .NET框架程序设计(修订版)》第1版采纳我的译文，没有授权第2版采纳我的译文。我也希望读者能够帮我监督。
其实有时候感觉去计较这些鸡毛蒜皮的小事情，真的挺损伤自我的高尚情怀和高远理想的——我不知道牛顿在写作《自然哲学的数学原理》，Donald E.Knuth 在写作《计算机程序设计艺术》，Bjarne Stroustrup在写作《The C++ Programming Language》时是否会有这样的出版社，是否会由这些令人惊诧的“奉献逻辑”，是否会斤斤计较于这些事情？
但是，在当下中国的环境中，分明就是这些事情常常让人很不舒服。我既非圣贤，写译的作品也不敢和这些圣贤大师比肩，但我想，合理的诉求，正当的抗争是必须有的。屈服于这种“奉献逻辑”是放弃自己的公民权利，只会助长不良风气，伤害出版环境，从而伤害整个公民社会（Civil Society）。
Permalink
04.27.06
Posted in 程序人生 at 11:22 pm by 李建忠
由于一些意想不到的事情发生，这段时间以来一直在忙碌，既无时间也无思绪写东西。有不少朋友都来信关心询问我是不是出什么事情了，既不写Blog，也不上MSN，也很少见Email。谢谢大家的关心，我情况还好，只是陡然增添了很多意想不到的事情，脱离了一段电子化的生活。现在情况好转，我又可以有一些时间来写一些心得和思考，与来自五湖四海的朋友分享。
由于原来的Blog空间http://blog.dreambrook.com/jzli/ 有很多麻烦的管理问题，常常不稳定。我也终于决定将Blog迁移到个人主页下。一方面这里将更加稳定，另一方面在自己主页下写东西的一个好处是随心所欲，无需局限哪一类话题，可以海阔天空地写。
Permalink