侯捷先生谈程序员与编程
关键词: 侯捷,语录,编程,程序员
急功近利是大忌
一位读者写信给我，说他非常着急。他一个月挣300元人民币，家里情况又不好。他希望赶快把 VC/MFC 学会，进入 IT 产业挣钱。信写得很长，看着看着，我也不禁为他着急起来。
有许多读者，虽然情况没有那麽急迫，燃眉之情却也溢於言表。不外乎都是希望能够尽快把某技术某技术学习起来。
但是哪一样东西哪一样技术是可以快速学成的呢？能够快速学成的技术，人才也就必然易取易得，根据市场供需法则，也就不可能有很好的报酬。所以诸君当有心理准备，门槛高的，学习代价高，报酬高；门槛低的，学习代价低，报酬低。
说起来是老生常谈了。这其中最可怕的心理在急功近利。从读者的来信，以及从 CSDN 上的众多帖文，我感觉，许许多多人学习 IT 技术，进入 IT 产业，是认为 IT 产业可以助你脱困，远离贫穷。
是的，IT 产业有这个「钱」景，但你得有那份实力。要吃硬核桃，也得先估量自己的牙口。
「好利」是基本人性，Acer 总裁施振荣先生大力提倡「好逸恶劳」之说，视为人性之本，进步的原动力。谁能说不是呢？好利可以，近利就不妙了。近利代表目光浅短，一切作为都因此只在小格局中打转。
梨园有句话：要在人前显贵，就要在人後受罪。台上一分钟，台下十年功。老祖宗这方面的教诲太多了，身为中国人的我们，应该都耳熟能详。
对於心急的朋友，我只有一句话：勿在浮沙筑高台。你明明很清楚这个道理，为什麽临到自己身上，就糊涂了？急是没有用的，浮躁更会坏事。耐住性子扎根基吧。做任何事都要投资，扎根基就是你对自己的未来的投资。如果想知道如何按部就班扎根基，侯捷网站上有一篇文章：「97/06 选义按部 考辞就班」，请你看看。
口舌之战有何益
最常在程序技术相关论坛上看到毫无价值而又总是人声鼎沸的口舌之战，就是诸如「VB 和 Delphi 谁好」、「BCB 和 VC 谁优」、「Linus 和 Windows 谁棒」、「Java 和 C++ 谁强」这种题目。每次出场都一片洋洋洒洒，红红火火急速窜升为超酷话题。众人各拥所好，口沫飞扬，但是从来说服不了任何异阵营的人，话都只说给自己人听，给自己人爽。
这样的论战有何意义？许多人在重组自己的偏见时，还以为自己在思考呢。战到最後，就只是争谁说最後一句话而已。而且，擦伤引起的争吵几乎总是以刺伤结束。
工具与技术的评比，是一场高水准的演出。真有能力做评比，侯捷是很尊敬的。但是这些各拥所好，口沫飞扬的人，真的对评比两造都有深刻的了解吗？很多时候我们看到的只是无知，而无知是这麽一种东西 : 当你拥有了它，你就拥有巨大的胆量。
很多人喜欢某种工具，只不过因为那是他的初体验。他玩它玩出了一点心得，可以说出它的某些好，就开始做「评比」了。你只看到牡丹的艳丽，又怎知寒梅的清香，幽兰的空灵？
绝大多数人使用某种工具，不是因为它最好，不是因为众里寻它千百度，仅仅只是因缘际会。虽然说不同的应用环境选择不同的工具，是最伶俐的作为，但我真的怀疑，在现今工具（以及工具背後反映的技术）如此繁复的时空下，有多少人能够同时精通一个以上的同质工具？追二兔不得一兔，我还是认为你精专一样工具，把它发挥到最高效能，获得的利益多些。被大家拿来评比的，都是市场上的佼佼者，还能差到哪里去？能够两雄相争，必然是在技术面、非技术面（资源的普及、品牌的可靠度）各有一片天，你的评比意义大吗？全面吗？
大多数人没有能力同时精通两种同质工具，初学者听了网路上不知名大侠的高论，也不可能有所选择（如果有，怕也只是蒙着头瞎选）。这种没有提供数据，评论者也没有显示任何信誉（credit）的论战，没有任何意义，纯粹只为自己爽。浪费网路资源！
C++ 之父 Bjarne Stroustrup 曾经在他自己的网页上的 FAQ （以及其他许多场合）中回答如下问题。虽然其中谈的是语言，但是扩大到其他层面仍然合适，值得大家好好咀嚼（注：全文由孟岩先生译出，可自侯捷网站浏览）：
Q: 你愿不愿意将C++与别的语言比较？
A: 抱歉，我不愿意。你可以在The Design and Evolution of C++的介绍性文字里找到原因。有不少人邀请我把C++与其它语言相比，我已经决定不做这类事情。在此我想重申一个很久以来我一直强调的观点：语言之间的比较没什麽意义，更不公平。主流语言之间的合理比较要耗费很大的精力，多数人不会愿意付出这麽大的代价。另外还需要在广泛的应用领域有充份经验，保持一种不偏不倚客观独立的立场，有公正无私的信念。...
人们试图把各种语言拿来比较长短，有些现像我已经一次又一次地注意到，坦率地说我感到担忧。作者们尽力表现出公正无私，但最终都是无可救药地偏向于某一种特定的应用程序，某一种特定的编程风格，或者某一种特定的程序员文化。更糟的是，当某一种语言明显地比另一种语言更出名时，一些不易察觉的偷梁换柱就开始了：比较有名的语言中的缺陷被有意淡化，而且被拐弯抹角地加以掩饰；同样的缺陷在不那麽出名的语言里就被描述为致命伤。同样的道理，较出名的语言的技术资料经常更新，而不太出名的语言的技术资料往往是陈年老酒，试问这种比较有何公正性和意义可言？
Q: 别人可是经常拿他们的语言与C++比来比去，这让你感到不自在吗？
A: 当这些评比不够完整，或者出於商业目的，我确实感觉不爽。那些散布最广的比较性评论大多是由某种语言，比方说Z语言的拥护者发表的，其目的是为了证明Z比其它语言好。由於C++被广泛运用，所以C++通常成了黑名单上的头一个名字。通常这类文章被夹在Z语言供货商提供的产品之中，成了其市场竞争的一个手段。令人震惊的是，相当多的此类评论竟然引用的是那些Z语言开发厂商的员工的文章，而这些经不起考验的文章无非想证明Z是最好的。尤其当评论之中确实有一些零零散散的事实...，特意选择出来的事实虽然好像正确，有时却是完全误导。
以後再看到语言评比文章时，请留心是谁写的，他的表述是不是以事实为依据，以公正为准绳，特别是评判的标准是不是对於所引述的每一种语言来说都公平合理。这可不容易做到。
我说过了，真正精譬的技术评比，对於相当程度的研究者，是很有价值的，但我很少在论坛上看到精品 ─ 论坛还能有什麽精品，99% 是打屁闲谈没有营养的文字。我们每每在其中看到偏见、我执、以及最後免不了因擦伤而引起的刺伤。这真令人伤感。这些人把时间拿来学习，多好。奉劝各位少花时间瞎打屁，多花时间学习，看些真正的精典，别动不动就在论坛上提问，也别动不动就挂在论坛上看别人的瞎打屁。
不但评比性的话题，大家喜欢强出头，其他话题，情绪性的反应也很多。中国强盛之道，眼前彷佛全压宝在 IT产业（尤其软件工业）上面。程序员被赋予了过多的期许，程序员也自我膨胀了许多。夹杂着民族主义或个人好恶，看到不满意的人事物，就号召大家「黑（hack）」过去。这是什麽心态？比拳头吗？说实话，就算要比拳头大小，「黑」个网站算是什麽尺寸的拳头？网路是个大暗室，君子不欺暗室。
杂志定位在哪里
CSDN上头，前一阵子曾经请大家就《程序员》的定位问题给意见。很热闹。我不知道刊物掌门人在看了那麽多建言之後，有没有收获。猜想是没有 ─ 就算有也恐怕不大。
就像面对书籍一样，读者最直观的感觉，就是要看他所需要的东西。100个人有100种需求，这样的询问得不出总结。隐性读者、不上网的读者、不投票的读者、不写帖文的读者，你又如何知道他的想法。
我以为，只需把握一个原则：永远比大众水平高一个档次，扮演引导者，带领读者接触前沿思想与宏观视野，那就是了。读者本身会成长，不论你把刊物定位在实质技术的哪一个层次，都会有人不满足；今年的读者成长了，不见得明年还是你的读者。唯有保持前沿思想与宏观视野，时常导入新的技术形式、新的思维、专家的见解、意见领袖的看法，才能够长期吸引读者，并对许多人以及整个技术开发环境做出长久的贡献。
美国大物理学家费曼，曾经批评物理课的教学。他说老师老是在传授解物理习题的技巧，而不是从物理的精神层面来启发学生。这一点是不是可以给刊物经营者和刊物读者一点点启发？
以此观之，就我个人的专长领域，STL 之父访谈录、算法大师 Donald Knuth 采访、C++/OOP 大系、GP/STL 大系、将标准C++视为一个新语言┅以及一些总括性、大局观的文章，是我认为最好的主题。此中有侯捷自己的作品，唔，我向来不客气。
当然啦，太形而上的东西是不行的，太过抽象的东西不容易被接受。抽象层次愈高，人的自由度愈大，但抽象思考是层次高的人的专利，要普罗大众能够接受，还需具象细节稍做辅助。
如何长期保持具有前沿思想与宏观视野的稿源？与外国杂志合作是一个既快又好的办法。每一期《程序员》最前数页都有当期重要外文期刊的前沿摘要，可见《程序员》编辑群一直与外文专业期刊保持着阅读上的接触。要挑选合作夥伴，心中一定有谱。
当然啦，与国外合作涉及经费问题。旁人（尤其读者）很难体会或换位思考经费上的种种困难。就像有人痛心疾首义正词严地埋怨 CSDN 速度慢得像蜗牛，却可曾想过网站的资源从哪里来。向你收费，你接受吗？台湾已经倒掉很多很多家着名的网站，我等着看免费的服务撑到几时。
要刊物宏观耐读，读者们也得成熟些。一群很好的读者，才拱得起一本很好的刊物。
下面是一封读者来信：。
软件工程对整个软件工业的提升，至为重要。但是一个程序员要修练到对「软件工程」这个题目感兴趣，非三五载（甚至更多）不为功。我的意思是什麽呢？我的意思是，这类书籍、这类工具、这类网站、这类刊物，在一个嘈嘈切切、急功近利的环境中难有生存空间。这是为什麽蒋涛先生想要将《程序员》杂志导向软件工程主题时，我对他兴起巨大的尊敬与忧虑的原因。
现在技术发展太快了，国外（甚至印度）在实现「软件工业化」的时候，大陆（至少我周围是这样）还停留在小作坊手工打造的水平。我认为未来的世界不再属于「个人数字英雄」，软件工程似乎比一两项技术更迫切。以您的大局观和丰富的阅历，对这个问题是否有不同的看法，不知您是否愿意就此从技术（或其他）角度写篇文章发表您的见解
顺带一提，《程序员》的文字水平一直以来带给我「阅读的乐趣」。这个评语我从来少有机会用在台湾的电脑刊物或电脑书籍上。比起台湾的电脑读物，这里的文字有深度多了。
轻浮躁进没信心
只要上网看看程序员出没的论坛，你就会看到一片浮躁与焦虑。反映出来的就是没有信心。
「C# 推出，Java 将死」，「Java 演进，C++ 将亡」，「.Net 推出，VB程序员死定了」，「Kylix 推出，大夥儿快学」，「Delphi 持续新版，哥儿们别怕」，「我刚学VC，怎麽它就出场了」，「MFC 真的要过时了吗」┅。诸如此类的问题，不知该归类为谣言还是童语？
很奇怪也很感叹，为什麽大家对这类问题如此感到兴趣。那透露出一种肤浅 ─ 没有深刻了解技术本质，因而汲汲营营慌慌张张惶惶惑惑於新工具、新事务、并且认为新的大概一定都是好的。对自己没有信心，对整个环境也没有信心。
有深度的程序员绝对不会在意这种事情。当然，并不是早晚三柱香就万事保平安。并不是告诉自己别在乎别在意，就真的能够不在乎不在意了。那必需是发自内心，胸中自有丘壑的一种笃定，有着好的本质学能做靠山。
台湾 BBS（连线）前阵子也有许多热烈讨论 Java, C#, C++, .NET 的贴信。我把我最欣赏的一封引於下。其最後结语，扩张到任何领域都是合适的。
发信人: [email protected] (流云), 看板: programming
标 题: 一些想法Re: 不懂,业界一直喊Java,在喊些什麽..."
发信站: KKCITY (Sun Feb 18 12:55:49 2001)
以目前台湾业界的情形来看，C\C++ 应该是想成为一个软体工程师的基本技能；至於 Java，如果熟悉 C++，学 Java 应该花不了一个月的时间。
以我个人的观点，Java 的 OO 程度是胜於 C++ 的，而且在这个 Internet盛行的年代，效率的瓶颈在於网路本身的频宽而不在单机执行时的效率，Java 所提供的 Collection framework 是非常威力强大的程式设计工具，又内建了对 Multi-thread 程式的支援，丰富的 class library 让人在设计网路、资料库┅的相关软体时无後顾之忧。
C++ 可能是过去十多年以来最重要的程式语言之一，它的效率显然较Java为佳，但在撰写需要安装在Internet上成千上万种不同厂牌的机器上执行的程式时，相对於Java可能就不是最好的解决方案。
「目前」不需要以 Java 来开发 DeskTop 上的应用程式，因为「当下」而言 Java 撰写的程式相对於 C++ 会占据更多的记忆体且执行效能不彰。
我们不能期待免子游得比鱼快，也不能期待鱼飞得比鹰高。
工程上的需求使得各种场合有不同的适合的程式语言，不必费心去批评 A、推崇B、打压 C。基本的理论比这些事重要多了。
VB 将死？Java 将亡？C++ 将被 Java 取代...，这很重要吗？我用Java 也用 C++，即使明年它们全都被 Java++、C++++、Lisp++、Forth++取代，何有於我哉？FFT 还是 FFT、Dijkstra algorithm 还是Dijkstra algorithm...还是别太担心这些事了...
侯捷除了偶在 BBS 上自说自话外，绝少回应或叁与讨论。看了上封信，忍不住回了一帖：
作者: jjhou (jjhou) 看板: programming
标题: 一些想法Re: 不懂,业界一直喊Java,在喊些什麽..."
时间: Fri Feb 23 21:12:14 2001
同意你的看法。写得非常精采。
人到了一个层次，才会去思考事物的本质是什麽，不被浮面的工具所系绊。
熟练工具是必要的，但工具的演化汰换，不是大家在这里关起门来喊爽就好。
Donald Knuth 说：「语言持续演进，那是必要的。不论现在流行什麽语言，你都可以肯定十年二十年之後它不再风光。我总是在自己的书中写些不时髦的东西，但这些东西却值得後代子孙记取。」（注：以上局部是《程序员》2000/12 的译文）
DDJ 1996/04 p18:
"Language keep evolving, and that is necessary. ...Whatever computer language is in fashion, you can guarantee that whitin a decade or two it will be completely out of fashion. In my book, I try to write things that are not trendy, but are things that are going to be worth remembering for other generations."
追求新知固然是一个计算机从业人员该有的态度，但是追求新工具与充实固有知识两者之间，应该取得一个平衡。过犹不及！
再说，凡走过必留下足迹。你现今的任何努力，只要它是扎扎实实的，就绝不至於落空。技术是有累积性的呀，技术总是触类旁通的呀。你说 MFC 和 OWL 就没有累积性，我说有，message map 的原理不一样吗？framework 的工作原理不一样吗？
我个人并非任何语言或任何工具或任何技术的狂热者，我是务实派。对於自称熟稔多种（属性不同的）语言的人，我充满敬畏并保持工作上的距离。要精通一个语言，使自己能发挥其最大效能，不是件容易的事，需要不少精力的投注。99.99% 的人都是凡人，身为凡人的我们，把时间用来精通一（或二）种适合其工作性质的「语言」，比泛泛认识多种「语法」，要高明得多，回报也大得多。
真的，还是别太担心谁将兴起谁将亡的事了吧。
天才的沃土
教育永远是我最关心的议题。教育的重要性绝对不亚於产业。没有好的教育，何来好的产业人才？
学校教育就不提了，那不是侯捷能够着力的地方。虽然我也在大学教书，但一年不过教育数十位学生，影响能有多大？书籍的读者动辄数万人，刊物的读者动辄数十万人，这才是有大影响力的地方。
自修教育如影随形，打你离开学校就跟随你一辈子，重要性远胜於学校教育。谈到自修，离不开读物 ─ 各种型式的书籍和刊物。在咱们程序员这一行，书籍和刊物的情况如何？
下面是一封读者来信：
我记得您说过，到一个地区的书店去逛逛，对这里的IT技术水平就知道大概。这话太得我心了。我学习软件技术5年，花在买书的钱有一万二千（人民币）以上，如今回头来看，绝大部份是垃圾。以前曾经担心：若要到外地工作，这麽多书怎麽带走？现在则是一种心痛的轻松，因为值得带走的书只够一提。学习IT之初，谁不想在产业上做出一番成成绩？但多年之後回首，则恐怕都会为自己当时所处的教育环境痛心。
关於计算机书籍的浮滥、低劣，我收到太多太多的读者反应了。以上只是冰山一角，有兴趣的读者请上侯捷网站看个饱。有些出版社甚至以出烂书闻名，看看这封信：
您想必看过蒋先生在《程序员》上写的文章，知道所谓IT出版四大家。蒋先生可能碍於礼仪，有些地方还没讲透。例如其中的XXX出版社，在译作方面现在已经是一块榜样粗制滥造的榜样。
再看这封信：
我在您网站中看到了有关对关於xxx 出版社的评价，深有感慨。其实该出版社是大陆IT业引进外文书籍的鼻祖，我们这一辈程序员(92年以前的)就是读该出版社的译着成长起来的（我至少还有两大纸箱xxx出版社的旧书），在那个时候，差不多所有的计算机类图书都是它们引进并翻译的，现在看来，那个时候的翻译质量差得无法忍受（比Incide VC++ 5/e还差许多），但我们那个时候已经很满足了，毕竟有比没有好。现在大家对xxx出版社的批评，我想是竞争的结果，因为大家看到了更好的译着，有了比较。总而言之，xxx 出版社当年的特点是大量翻译，草草出版，让科技人员能够在尽快的读到优秀作品。这种作风显然已经不合时宜了，或者说它已经完成了它的历史使命。我现在当然也不象从前那样狂买xxx 出版社的书了，因为有了更多的选择。
这封信让我跌入回忆。台湾也曾有两家出版社，有过同等劣质的作法。这两家恶贯满盈的出版社，一名莹圃，一叫松格。两家都关门了。他们的作法都是，快速而大量地翻译外文书。由於速度快，也由於选材之中不乏好书，所以曾经拥有一定的市场。怎地都关门了？因为读者只能被欺负一次两次，不会永远当傻瓜。这样的出版心态摆明没有长远打算，只想捞一票走人，不关门才怪。
我们可能因为，垃圾堆中多少捡过一些经过修补尚称堪用的东西，而对刻意制造这些垃圾的人产生一种奇怪的情愫。东西明明不好，但我们从中吸收了一点点养份。该谢他还是该恨他？
该唾弃他！
这些商人之所以大量而快速地引进外文书，因为有利可图。有利可图是好事，但他没把他该做的事做好。他们放弃品质而无所惧，因为他们知道，在怎样的时空背景下可以怎样轻松地赚钱。大陆出版界朋友告诉我，谁谁谁（都有名有姓）很轻松地在几年里就这样积聚了几百万人民币的身家。几百万人民币呀，我的天。这也算 IT 产业吧，果然是一片红火，鸡犬升天。
因努力做事而致富，应该得到我们的赞美和祝福。可这样的出版社，花更大的功夫赚更多更长远的钱他们不要，因为轻松钱赚起来不费劲儿。百分之一的人可能从这些垃圾中吸收到一些养份，百分之百的人从中感受了阅读的痛苦。谁知道从中被误导的人又有百分之几？买书的钱我们没少花，得到的正价值却是那麽少，痛苦指数那麽高。
这位读者说『总而言之xxx 出版社当年的特点是大量翻译，草草出版，让科技人员能够尽快的读到优秀作品』，又说『它们引进并翻译的，现在看来，翻译质量差得无法忍受』。喔，一本优秀的原作，经过无法忍受的翻译质量洗礼後，还会是一本优秀的作品吗？待人宽厚是美德，但是刻意制造馊水油让人吃坏肚子者，不值得为他们说话。你说『它已经完成了它的历史使命』。不，他们从来就没有历史使命，也没有使命。
如此「仁厚自持」而且忍耐度奇佳的读者，相当稀少。绝大部份程序员谈到计算机图书，都是斑斑血泪的控诉。《程序员》2001/03 p119 可不就有一篇「计算机图书出版商的陷阱」。
读者来信写道：
鲁迅说，未有天才之前，应该要先营造天才的土壤。...您的心情我确实能够深刻理解（这大概就是堆在墙角那几百本垃圾书的最大贡献吧）。
「天才的土壤」，嗯，鲁迅说得好。不正应该是出版社的职志吗？我们却能向谁说去？其实我们也只是希望有一些好书造就一些资质不错的程序员而已。前一阵子才沸沸扬扬於印度程序员与中国程序员的比较，我们哪企望天才？不过就是希望培养一些扎实的人才而已。
看倌也许奇怪，书不好，侯捷为什麽不把矛头对准作者，却大骂出版社。哇勒，我早就抱着「得之我幸，不得我命」的卑微态度，不敢期望创作性中文好书。上面我说的，以及读者最痛心疾首的，是翻译书的低劣水平。人才济济的中国，怎麽可能找不到够格的译者？如果不是出版社的抢钱抢短心态，会造就出这一大批劣品吗？我能不怪罪出版社吗？
到头来，还是要靠自己。「计算机图书出版商的陷阱」一文最终是这麽说的：『记住，您花的是自己辛苦挣来的钱，所以千万不要浪费在没有用的东西上。对於出版了优秀图书的出版公司要有所回报。买他们的书，给他们写信，让他们知道你在想什麽，你需要什麽。』
良性循环
一个体系的建制，需要从底层到顶层的坚实构筑。不论是 C++, Java, .Net, OO, UML, Windows programming, Linux programming，每一个主题欲成就一个完整体系，都需要一大套书。拿C++/OOP 来说，就得涵盖语法语意的、物件模型的、专家经验的、设计样式（design patterns）的、入门的、进阶的，作为叁考工具的┅。拿 GP/STL 来说，就得有 GP 泛论型的、STL 源码剖析的、STL 应用大全的、STL 规格大全的、STL 组件设计的、其他泛型技术的┅。拿Java 来说，就得有语言核心的、物件导向的、多绪编程的、图形介面的、网路应用的┅。对生手而言，不先把底层的东西弄清楚就学习高层的抽象，必会成为空中楼阁，流于形式。对熟手而言，缺乏抽象思维，意味层次上的停滞。
写作、翻译、乃至於出版全体系好书，真的是一件需要目光长远、意志坚定、带点理想色彩的人，才做得起来的志业。
如果这样的人，这样的出版社，没有得到大家理念上和实质上的支持，谁会投入这种傻事？
我个人一向是高品质高价位的坚定信奉者。高品质高价位是生产者经营的最大诱因。因为努力做出了高品质，所以得享高价位带来的高利润，天经地义。否则谁要费心去做高品质？慈善家吗？傻瓜吗？
对於消费者，高价位当然令他不舒服。但是你应当思考是否物有所值，甚至物超所值。拿英文书为例，USD 49.95 一本的 The C++ Standard Library，或是 USD 49.95 一本的 Generic Programming and the STL，完全物超所值。当我了解这些书的价值，就算他们再贵两倍，我也要买。有人拼死吃河豚，我可是要拼命买好书。现实地说，眼下「知识经济」喊得震天响，好书带来的知识不正是赚钱工具吗？对赚钱工具小气，是不是和自己过不去？
下面是一封读者来信：
相较日本无论是漫画作家、文学作家或是偶像歌星、影星的客观条件来比较，在台湾，身为专业作家竟如此难为？有人可以连夜搭帐篷排队买票看演唱会，有人却可以论斤计两地讨论页数与书价高低。或许他们不知道，一本介绍C程式语言的入门书，在德国索价100 DM (约NT$2000)。因此我的德国同事们购书前必定徵询意见或叁考书评。书价虽不低，但其读书风气仍不亚於日本。
这里点出了一个重点：书价很高，於是大家慎选好书，重视书评。下面是另一封读者来信：
我是一名大陆的读者，同时也是一名计算机的初学者。我在网上看到网友都十分推崇您的着作及译作。知道您的作品《深入浅出MFC》第二版即将在内陆出版，我决定买这本书，并与华中科技大学出版社取了联系。从那里知道您今年还会在大陆出几本书，我非常高兴，但在知道了您对价格的看法後，又有些失望。
大陆与台湾的经济水平是不同的，作为普通的工薪阶层，购买力也是有限的。我们这里，各类图书中计算机类图书的价格是最高的，图书页码的最高位与书价的最高位基本相同 -- 700页的书，价格在70到80元之间，1000页以上的，价格在100元以上。这是目前大陆书价的大体情况。如果按您所说，350页，书价80元，在这里算是很高的价格了，这种价格的书，只能看，不能买。
"春蚕到死丝方尽，蜡炬成灰泪始干"，教师工作被我们看成很神圣的职业，燃烧自己，照亮别人。我想您出书的目的，也是想让更多渴望知识的人受益于它，少走弯路。作为读者，我们也希望能够看到更多更好的书。但是在一定历史时期内，购买力与价格应当有一个平衡，350页80元的价格确实太高了，如果能够降到60元以内，我相信大多数读者可以接受。
您的书的品质很高这是大家的共识，从价格上应当与其它书区别开来，但书价也不宜太高。名牌服装走高价位的路线，当然可以提高它的身价，显得它档次很高，但是太高的价格使它脱离了主要的消费群体，大多数人只能在口头上谈论它，却只有极少数的人会把它穿在身上。书籍与名牌服装不同，只有经过很多读者长时间的阅读之後，才能够证明它的价值，如果很多人都知道侯先生的书质量很好，但是却很少有人读过（因为价格问题），那岂不是一种悲哀。
我最不乐意看到「xxx 页的书，售价 xxx 元」这种观念。一本书的价值在内容，不在页数。真要这麽算，每本书我们都应该检视一下其字型大小、行距字距、硬拷图多寡、留白多寡 -- 因为这些都关系着页数。如果大家都接受页数和书价的固定比例，肯定会有大量浮滥的书跑出来（不就是现在的情况）。
不必这麽累。一本书值它的价，就买；不值它的价，就别买。很简单的逻辑。
我们难道能够拿着尺衡量一件亚曼尼用了多少码布，来决定它的价格吗？或是拿着尺衡量一张梵谷是几号，来决定它的价格？我能够说因为我画的绣球花比梵谷的鸢尾花大两倍，所以我应该卖他的两倍价？
买东西不能光看有形；那无形的往往更重要。买书不是买纸。正确价值观必须建立起来。
当然很有可能你认为买名牌服装或名画的人都是疯子。你要的只是布和框。那表示那些物品在你心中不值那个价。很好，你有你的评价，你有你的选择。
我不打算在「引喻」（例如名牌服装或名画）上面多着墨。引喻有顾此失彼的时候，笔战都是这样打起来的。各位知道我要强调的是什麽。
350 页的书，不应该一定卖 80元，也不应该一定不卖 80 元。这要看350页的含金量有多少。况且我从没说过侯捷有 350页的书要卖 80元。但所有的可能都存在。350页可以是180元，也可以是80元，也可能 530 页连 18 元都不值。请不要再以页数做为书价的依据了。
教师的工作很神圣，但「燃烧自己，照亮别人」太沉重。「燃烧自己」，呵呵，说起来多麽容易，做起来多麽痛苦。某人的工作对众人有益，他会很开心。但你要他燃烧自己照亮别人，除非圣人，否则不干的。我很乐意照亮别人，却不想燃烧自己。燃烧自己，我只能照亮别人五年；把自己照顾好，我可以一辈子照亮别人。抬出大帽子，会让有能力写作好书的人畏惧不前。
请大家接受这样的观念吧：书的价值在内容，不在厚薄，不在页数。价值影响价格，价值带动价格。接受这样的观念，便是对好书的所有出力者致上敬意与实质支持。如果大家慎选好书，10 本垃圾书的价格支撑两三本高价（其实是适价）好书绰绰有馀。走编程这条路，谁手上没有 10 本 20 本垃圾书！当大家慎选好书，支持好书（尽管它价格较高），就会带动书评风气，带动优良写译风气。这对所有的人都好。不需有人燃烧自己，大家都被照亮了。
当然，高价位的薄书很可能带来盗印与影印的歪风。但无论如何，我是坚持己见不会退缩的。如果大环境真的无法提升，好书离开了，好人退出了，最後损失的是谁？
不论各位相信不信，侯捷企图以个人影响力（如果有的话）建立优良的技术写作大环境，对台湾如此，对大陆也是如此。「问渠安得清如许，为有源头活水来」，要让大家有更多好书可读，就要有源头活水注入；要有源头活水，就要有更多诱因吸引更多才能之士到技术写译领域来。更多的诱因是什麽？让他们知道，好作品可以突出，可以区隔（讲白了就是有好价格），不会牛骥同一皂，这就是一种诱因。不，这不算诱因，这根本是一种基本道理。
优质的书使读者受惠，优质书籍所带来的高报酬使作者、出版社受惠，并吸引更多优秀人才到这个领域。形成一个良性循环，大家都受惠。
另外我要建议大陆出版社，善用你们独特的「影印版」。台湾的计算机类翻译书，由於也是良窳不齐，窳多於良，曾有读者开玩笑建议，出版社取得授权後，不要译了，直接以原文出版，读者看得高兴，售价又得以大幅下降。想来这就是大陆的影印版（在台湾是不许的）。既然翻译书已到了千夫所指的地步，何不乾脆多多引进影印版？不是要抢短抢快吗？这个最快了，读者也多一种选择。
翻译出了什麽问题
计算机翻译书的一个大问题是，译者没有时间（或正确的心态，或足够的中文能力）将译稿一看再看，一改再改。中文有一个缺点，那就是名词本身表现不出复数，动词本身表现不出时态。多数时候这可能不是很重要，因而可以忽略。但某些时候它们占有关键地位，於是一个精准的英文句子，往往需要译者额外花很大的心力，才能精准地以中文表达出来，那麽译者就得有足够的时间和足够的中文能力。而唯有译者在专业技术上具备足够的素养，才能够看出某些隐微地方对理解之正确性有关键性影响。
英文里头的子句如果又臭又长，别说中国人，老外也得费一番手脚才看得懂。看看这个（C++ Primer 3/e, p730）：
[code..] where the conditional test if (this != &rhs) prevents assigning a class object to itself. This is particularly inappropriate in a copy assignment operator that first frees a resource currently associated with the class in order to assign the resource associated with the class being copied.
我的译文是：
[code..] 其中的条件测试 if ( this != &rhs ) 避免将 class object 指派给自己，因为「自己指派给自己」这个动作，对於那种「先将目前系结於自己身上的资源释放掉，以便稍後将该份资源再系结於即将被拷贝的那个 object 身上」的 copy assignment 运算子而言，尤其不合适。
只需加几个引号，标示出子句，就好看多了。寻常一样窗前月，才有梅花便不同。如果没有引号辅助，你试译看看会是什麽样子。别对我说「根据教育部规范，上下引号只适用於强调专有名词或特殊语气┅」，规范是死的，人是活的呀。只要能够灵活而正确地表现出文意，就是好办法。小Ping同志不是说，管它黑猫白猫，会抓老鼠的就是好猫吗。阿波罗13号登月计划失败时，太空舱内的备用排气罩规格不符，地面控制中心要求宇航员必须想办法将方形罩子塞进圆形的排气管中，否则大家都得因为饱食二氧化碳而死於太空。这时候还想什麽规范？脑筋灵活点。
另一个中文表达的大缺点是：动名词不分。操作是名词（operation），也可以是动词（operate）；实现是名词（implementation），也可以是动词（implement）；叁考是名词（reference），也可以是动词（refer）；请求是名词（request），也可以是动词（request）；委托是名词（delegation），也可以是动词（delegate）。当动词名词混杂一起的时候，就造成阅读上的错乱。於是你可以看到这样的句子（取材自《设计模式》p14，李英军等译，机械工业出版社）。请诸位先看原译，能否就中文语句结构分析出其大致意思：
(1)原译：只有当委托使设计比较简单而不是更复杂时，它才是好的选择。
(1)侯译：只有当「委托方式」简化了设计，它才是一个好的选择。
(1)原文：Delegation is a good design choice only when it simplifies more than it complicates.
(2)原译：委托方式为了得到同样的效果，接受请求的对象将自己传给被委托者（代理人），使被委托的操作可以引用接受请求的对象。
(2)侯译：为了以「委托方式」获得相同效果，「请托（request）受理者」将自己传给被委托人，使自己得以让「被委托之操作行为」取用。
(2) 原文：To achieve the same effect with delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver.
我没有一别苗头之意。我的译法不见得最高明。况且翻译一整本书所需的各种前後呼应的考量，远比光译一两个句子复杂许多。只是既然我提出了问题，我总要提出自己的解法，给大家叁考评量。对於机械工业出版社愿意出版这样一本经典，李英军先生等人愿意翻译这样一本高阶而吃力不讨好的书，我是带有敬意的。
另一个翻译上的问题就是大家往往在计算机类书中硬套一般字典查来的词汇，没人敢突围。要知道，一般字典并未考量电脑技术，更不可能考虑到上下文（context）。太多人抱着少做少错，不做不错的心理，一昧紧跟字典，不敢变动，才会造成目前许多译词不够理想，却动弹不得。我印象最深刻的是这几个字：
instance：台湾和大陆均有不少人译为「实例」。这个「例」字根本不好。台湾甚至有人译为「案例」，更不妥当。为什麽这麽译，因为字典查来的现成词汇是这样。所谓 instance 就是根据某个东西（可能是实物，可能是某种表述）产生出来的一份实际物体。我认为译为「实体」是很合适的。根据 class 产生出来的便是object实体，根据 class template 产生出来的则是class 实体，根据 function template 产生出来的是function 实体。根据可执行档（executable files）产生出来的，则是一份 process 实体。
paradigm：台湾常译为「典范」。为什麽？喔，字典查来的现成词汇。有时候这样译有点道理，例如 paradigm shift 叫做「典范移转」。问题是，何谓「典范移转」？很难望文生义是吧。把 generic paradigm 译为泛型典范，更是令人不知所以。我们日常用语里也有「典范」一词，我们会说某某人是国家社会的典范，那和计算机术语里头的 paradigm 根本不是同一个意思。根据 paradigm 在计算机术语中的实际意义，我把它译为「思维模式」 ─ 典型的、根本的思维模式。
读者来了这样一封信：
我向您讨教一个翻译风格的问题。正如您所说，英文技术书籍最难在长句子，因为英文的句式组合形式比中文大大丰富，理解起来已经费力，翻译成顺口的中文更难。我有时遇到这种句型，切分组合，翻来覆去掂量，还是觉得中文不忍卒读。您认为此时 (1) 我可不可以放弃 "信" 而求 "达"，也就是说略掉部份句子成份以保全译句的通顺？还是 (2) 务求将原义表达出来，宁可中文句子不顺畅也在所不惜？更有甚者，有时 (3) 某些句子无关宏旨，却异常难译，可不可以乾脆略过不译？您的看法是什麽？
（各位有没有注意到，这位读者的中文很好。「切分组合，反覆掂量」这几个字用得多精简传神）我的看法是，译者有权利也有义务通权达变，但也必须有这份能耐才行。因此你的第一个问题我认为可以，你的第二个问题我认为不可以。你的第三个问题我认为可以，但需谨慎为之，莫因译者本身水平，牺牲了某些东西。
科技翻译应该务求义译而非字译。信与达，应从整个句子或甚至整个段落来看，不是从一个个单字来看。技术文章和文学多有不同，译者最重要的任务是正确传达知识，并尽量减少读者的吸收困难。
到底弹性的底限在哪里？我这麽认为，译者於技术层次上愈有把握，便享有愈大的弹性。只要技术层次够，有把握正确了解并传达了原作者要表达的技术，那麽，文字上不必字字拘泥。
中文在科技表达中并非一无是处。中文有一个优点，就是资讯密度高，很多时候精简漂亮的一行中文，可以表达出「子句夹带子句再夹带子句」的三行冗长英文。中文有优美的词藻与取之不尽用之不竭的典故、成语、俗谚，如果善用它们，冰冷的技术文字一下子就能有阅读的乐趣。一本烂译本，会让读者诘屈聱牙，痛苦至极；但是一本好译本，能使人如沐春风。
容我说一句，正确的心态、足够的时间、充裕的中文表达能力、水平以上的专业素养，是造就好译本的基本元素。现今情况如何？话说回头，好译者的报酬几何？你愿意多花点钱表示你对他们的付出的认同吗？
健康的选书心态
以下谈到选书的心态和作学问的态度，由於都以读者来信展开讨论，因此避免不了提到我写的《深入浅出MFC》。我要谈的问题，其实不局限於某一本书，或某一种技术。就像这篇文章先前举的许多例子一样，都是可以放大来看的。
读者修书一封如下：
2 个星期前好不容易读完了您的大作，让我对MFC的认识多了不少，不过一点遗憾的是从您的书里并不能学到如何写一个具体的程序，仅仅是明白了MFC的“包装技术”。本来我还以为又上当了呢因为我买这本书的目的就是要学习用MFC来做程序的...一个偶然的机遇让我得到了 Jeff Prosise的《programming windows with MFC》，这才发现老师您的书是多麽的重要，假如没有您的《深入浅出MFC》我又怎麽可能programming with MFC呢？...您的书救我于水深火热之中，带领我冲破MFC的条条封锁线。
虽然这位读者最终对侯捷和侯捷的书以感谢和赞美作收，但我颇有感慨。
读者往往以最直观的态度来审视一本书的价值，以最直接的方式来表达他的爱憎。但不能凡是不需要的，一律视为灌水；凡不符合需求的，一律视为欺骗。这不是一种健康的选书态度。即使你最後并没有发现《深入浅出MFC》「是多麽的重要，救我于水深火热之中，带领我冲破MFC的条条封锁线」，这本书又何尝在书名或内容欺骗过你，使你「以为又上当了呢」。再者「我买这本书的目的就是要学习用MFC来做程序的」，可是你若连MFC与application 的第一线接轨都不了解，照着葫芦画瓢，能写出多好的程序？
我不是责怪这位读者，只是这封来信代表某些现象，让我心有感慨。下面是另一种偏激：
您的书我觉得有些无用的原理讲的太多了! 你所写的并不是真正的教人怎麽用VC,而是教人VC运做是怎麽样进行的! 其实很多读者真正关心的问题并不是在这里! 而是在怎麽对用VC设计出真正出色的程序!
读者永远只想要看自己想看的内容，这一点很自然。但是你不想看到的东西并非就是「无用」，它对别人可能「很有用」。再说，连MFC与application 的第一线接轨都不了解，照着葫芦画瓢，我不知道你能写出什麽「出色的程序」。只要出一点差错，你连除错的能力都没有。开车是很简单的，开车上路遇到各种突发状况而能应付并排除障碍，才是困难的地方，才是技术的表现。
下面是两封台湾读者的意见，有点年代了。当然我必得先说明，抱持这种态度的读者，比例大约在百分之零点零一。
读者意见一
这本书包装太厚。不该有的东东太多，附录A所列的无责任书评，在我想来也是多馀。因为这篇书评在RUN!PC早有提及，後来也出了无责任书评第三集，因此实在没有这个必要。想来是侯先生要增加书的厚度，有以致也。
读者意见二
书评不应该放在这本书里吧! 因为这些东西而让书太厚实在有点┅这些灌水的东西共计有：
(a)1-16页的读者来函：共16页
(b)超长的序，嗯，这应该没有关系
(c)843-872页的无责任书评：共30页(其实里面有一些发人省思的东西，还好)
(d)873-914页的Scribble原始码：共42页(这最严重，几乎没必要的东西)
(e)915-920页的VC范例程式一览：共6页(很可惜，如果再多加发挥的话很有用，
但是侯Sir只是列个标题，连说明都是英文，和看Help档没什麽差别)
共计：94页
不是我无聊找碴，您可曾看到有哪本书有将近一百页的赘肉?更别题书中动不动就列出四五页的原始码了。这些在光碟上都有，何必浪费纸张? 不过消掉这些赘肉，这本书还是有它的价值┅至於书中缺少的部份，我认为要看您如何去定位这本书。
总不能要求一本书把所有Program的东西讲完吧! 以探讨MFC的内部而言，本书没什麽好批评的了。总而言之，这本书该不该买，我想还是肯定的。但是如果书能瘦点、售价能低点，那就更好了。
说来说去，原来是为了「如果书能瘦点、售价能低点那就更好了」。这便是页数和售价牵扯观念下的可怜受害者，他们扭曲了书籍的价值，也严重扭曲了自己该有的正确价值观。如果我告诉这些读者，少掉那100页的所谓「赘肉」，售价一样是 NTD 860，恐怕他们又要对这些「赘肉」热情拥抱来一个亲亲了。真的是这样，这本书是先确定价格，最後为了给读者更多资讯和更大的方便，我才加上那些「赘肉」的。
这一类读者，站在敌对的立场，看待出版社和作者，幻想每一个人都在觊觎他的钱包，并且认为对他无实质帮助的每一页（可能只是因为他已看过）都是被刻意灌水的结果，都是为了欺骗他的钞票。这样的读者在杯弓蛇影的压力之下，忘记了没有任何一本书是为个人量身打造的，也忘记了其他人可能有不同的需求，完全以自我为中心。
这一类不成熟的读者，实在是当前劣品充斥下的牺牲者。老实说我个人并不喜欢他们成为我的读者。只是，读者有选择作者的权利，作者却没有选择读者的机会。
正确的作学问态度
前面两篇来信透露出一个疑惑，《深入浅出MFC》是不是一本对VC编程有帮助的书。我不是要在这里夹带推荐该书（相信我，我不需要如此），而是想透过MFC与VC的关系，引申谈谈作学问的态度。如果「作学问」太高远了，那我们来谈谈「学习」的态度吧。
以下是一封读者来函：
我有个疑惑，想请你帮助。我们今天学C/C++，明天学MFC，OWL(如果流行的话)
後天学C#，JAVA...如果 WINDOW 被 X WINDOW 淘汰，岂不是都要从头学过？有没有必要把一切搞得如此精通？同样的目的，为什麽不用更方便简单的快速RAD开发工具？而非要以钻研繁杂作为乐趣？和体现水平？是否搞错了方向和目标？我认为这正是目前大陆（台湾我不了解）软件开发的一个错误的方向。
所有同质的技术都有累积性与共通性。信中提到的三组东西：MFC, OWL, 或是 Windows, X Window, 或是 C++, Java, C#, 都有类似性与共通性。技术是会累积的，有了某种经验，学习新技术会快很多。经验愈多，学习愈快。所以我常喜欢说「触类旁通」。如果每种技术都得从新学习，大家三五年就得归零一次，人类世界就不会在 20 世纪像爆炸似地进步这麽快。
「有没有必要把一切搞得如此精通？」我的回答是：看个人需求与定位。基础知识的精通，是做为应用的一种过程与手段，而不是目的。如果你不需要通过这样的过程，就可以把你要做的事情做得很好，那麽当然你可以跳过这个过程。我所知道的是，许多许多人必须先有这样的过程，才能够良好达成期望目标。我自己也需要通过这样的过程（否则写不出这样的书）。这不是你所谓的「钻研繁杂」或「体现水平」。
既然信中提到RAD，我也谈谈我的看法。我曾经写过一篇文章，把RAD喻为「匹夫无罪，怀璧其罪」（见侯捷网站 1999/01/26 怀璧其罪 RAD），建议各位看看。我很赞成使用RAD。我书写MFC书籍，探讨MFC技术，但从来没有认为它最好，或不好，我只是要帮助那麽多使用MFC的人。和 Bjarne 的态度一样，我对诸如此类的工具评比活动一点兴趣都没有。我乐意当一名观众，但从来不评比（应该可以说，也没有能力评比）。
RAD 的情况，可以拿汽车做比喻。现今谁开车还需要知道齿轮箱、传动轴、离合器、引擎点火原理、火星塞呢？但是满街开车人谁又能够表演360度大回旋？要到达「车手」的程度，就必须对车子的原理有相当程度的了解。同样是开车，洗拿（F1方程式冠军车手）和侯捷两人发挥车辆功能的程度，绝对有天壤之别。我认识的所有惯使RAD 的高手，无一不是有底层深厚功力。以RAD始，以RAD终，断不能在技术上有所太大长进。你的生涯将是空白的五线谱，没有高音，没有低音，永远的水平┅。
RAD是要用的，有好工具不用，和自己过不去。但是使用RAD的同时，对底层做更多的了解才有助於在某种情况下脱困或自助。这和 STL 的运用也一样。会用STL，是一种档次。对STL原理有所了解，又是一个档次。追踪过STL源码，又是一个档次。第三种档次的人用起 STL 来，虎虎生风之势绝非第一档次的人能够望其项背。
学习某种工具，及其背後代表的某种技术，究竟要钻研到什麽深度？唔，答案视你想扮演什麽角色而定。「F1方程式车手」和「半夜三点才敢上台北大马路的用车人」之间，有许多许多的层次，你自己定位自己。
有些人绝对拥护RAD，有些人又重新反省RAD。下面是另一封信：
我在「怀璧其罪 RAD」一文中是这麽回答的：
1. RAD 并非罪恶，而是优点。要怎麽用它则是你自己的问题。我有两位朋友是 Delphi 专家，他们可以使用 Delphi 做任何事情，没有任何你想像中 RAD「该有」的限制。
2. 果真能够「写一个程式，比使用 Office 还要简单，深入的思考几乎是零」，并不是坏事。大家都能够随手写个小程式解决手边几个小问题，是为component software 以及 RAD 的大贡献。但你的形容太夸张了，目前的 RAD 还不至於美好若此，总还需要一些程式逻辑和程式语言的基本训练。真到了你说的那一天，我觉得是件好事而不是坏事。只不过，那样子完成的程式，都需藉助现成的元件。如果要突破现成的框框，就得有更深的功力。无论如何，RAD 不会是你的绊脚石。
这类话题很难一言以蔽之。总之，优秀的技术者一定需要一个向下沉淀的历练，通过了这层历练，有了扎实的基础，就可以向上浮升，开始以抽象的思考，抽象的语言、快速开发工具来进行高层次的开发工作。这时候运用 RAD 工具，当能如虎添翼。
所谓百炼成钢；钢的形成，是将铁块不断锤打，不断回火，不断淬炼。做为一个程式员，本身技能的层次，和回火淬炼的次数有密切关系。
让我们再回头谈谈基础建设。很多资讯科系在学学生对学校所开的课程，非常不服气，非常不屑，认为对编程能力一点帮助也没有。首先我要说，编程、软件开发并不是资讯系学生的唯一出路。资讯领域何其广泛，编程只是其中小小的一支而已（但对就业市场而言则是大大的一脉）。其次我要说，基础理论课程并非对你的编程一无是处 ─ 不是无用，只是未到用时。有些科目的影响非常直接而深远，例如对编程最重要的两门课：资料结构（data structure）和演算法（algorithm），这两门课对逻辑思考与实现能力的训练，有关键性的价值。没有这两门课做底，任你 C/C++/Java 多强多行，也写不出个好程式。其他基础理论课程也都各有用途，会不会在你未来的编程生涯中带来帮助，那得看你编哪一种程。就业与学校所学，不必然会发生关系，不必然不会发生关系。
编程能力强的年轻同学，容易孳生一种趾高气扬的恶习，看这不顺眼，看那不顺眼，教授都老朽，同学都可笑。问他为什麽，哦，因为「他们的编程功力都不如我」。可笑的正是你自己呀。
编程实力的培养其实很容易的。我所谓容易，是指不需借助外力，纯粹自修就几乎可以做到。再没有比这更幸运的事了。当然你的进修必须按部就班（在我的专长范围内，我写了很多让你前进时有所依循的文章，都在侯捷网站上）。任何高深的理论，只要实际操作过都可以霍然理解，编程的实作又有什麽难的。数本好书，一部电脑，一些必要的工具，全部搞定，只欠一股「头悬梁锥刺股」的苦读精神。实力进展到一个阶段後，我非常鼓励你追踪名家源码（有人指导更好）。司马相如说：能读千赋则善赋，能观千剑则善剑。侯捷说：读过千赋亦能赋，观过千剑亦能剑。
最後我还要说，学校（尤其大学）原本不是职训所。但是关於人格的培养，思想的启迪，视野的开拓，现今言之，恐怕是陈义过高，没人爱听了。
学校肯定有学校的缺失。其一是课程太过理论，高来高去。以大学生的程度而言，太过抽象的东西他们是没有能力接受的。但是要化抽象为具象，化繁为简，可得有非常深厚的实力才行。其二是教材、教具、教师太过陈旧，跟不上时代。我印象最深刻的是，台湾BBS时常有学生问 Turbo C 3.0 上的问题。我的妈呀，C++ Standard 都出来两年了，学校还在用TC3.0。倒不是说一定要追最新最炫的工具或产品，但是TC3.0 距离 C++ Standard，有月球到地球的距离吧。用这个编译器，可想而知老师教的是什麽内容，可想而知老师本身跟上外界脉动的程度。如果新工具新产品都很贵，顾及学校经费，我们也能体谅。可 Borland C++ 5.5, GNU C++ 2.96, TAI C++ 都是可以免费下载或限期试用的呀。它们对 C++ Standard 的实现，比TC3.0 好太多太多了。
这就涉及学校教育里头最重要的关键：师资。说句实在话，大学里头有不少老师，书是念得很棒，就是没有实作经验，更没有业界经验。因循苟且之念一动，万年教材一摊，同学们就只有自求多福。
自救之道当然有：你必须更勤奋。勤奋看书，勤奋发问。勤奋搜寻好的导师和好的读物。或许天道酬勤，就让你碰上一个传道授业解惑的贵人，就让你知道一本必读的经典，并且就让你找到它。
说到勤奋发问，让我发出本文的最後一声感叹做为结束。台湾大学生在「表达能力」这一点，程度普遍低下幼稚。能够条理分明把自己的意思表达清楚的，十分罕见。反映出来的，就是怯怯懦懦，理不直而气不壮。私底下声若洪钟，要他站起来公开表示意见，却如细蚊之嗡嗡。不论口语或文字，用词普遍地「俗」。大陆情况，就我的印象，以及我收到的读者来信，感觉好很多。以前台湾的说法是，因为大陆斗争厉害，人人得有一口利嘴以求自保。但文革已过数十年，我看大家的表达能力普遍还是很不错，是不是求学阶段中曾经特别重视这个？
发问的能力影响学习甚巨。善问者使人继其声，善教者使人承其志。我常自诩为一名善教者，但如课堂上兼能有一名善问者，高潮迭起，全班受惠。
我原本是一个一天到晚使用RAD工具的人...但是历经了三个版本之後，我有一种被骗的感觉，因为处在这个环境中，似乎是投身在别人设好的一个圈套里！这种东西会让人对於『了解 OS 内部运作以及各种规范与协定的基础层面』的欲望慢慢减低至零。今天为了突破某一个元件的限制而自己写了一个元件，明天新版RAD内附元件就出现了比自己写得还要好的东西。到了最後，自己不想写，只想等别人写给你
；要是别人不写，你就彻头彻尾地丧失了一项能力...(天晓得要等到何年何月)，要不然就是官方给的元件功能少东少西。不只这些！最让我受不了的是，我竟然发现：程式用这种方式去写，简直就比用Office 还要简单，深入的思考几乎是零...。
急功近利是大忌
一位读者写信给我，说他非常着急。他一个月挣300元人民币，家里情况又不好。他希望赶快把 VC/MFC 学会，进入 IT 产业挣钱。信写得很长，看着看着，我也不禁为他着急起来。
有许多读者，虽然情况没有那麽急迫，燃眉之情却也溢於言表。不外乎都是希望能够尽快把某技术某技术学习起来。
但是哪一样东西哪一样技术是可以快速学成的呢？能够快速学成的技术，人才也就必然易取易得，根据市场供需法则，也就不可能有很好的报酬。所以诸君当有心理准备，门槛高的，学习代价高，报酬高；门槛低的，学习代价低，报酬低。
说起来是老生常谈了。这其中最可怕的心理在急功近利。从读者的来信，以及从 CSDN 上的众多帖文，我感觉，许许多多人学习 IT 技术，进入 IT 产业，是认为 IT 产业可以助你脱困，远离贫穷。
是的，IT 产业有这个「钱」景，但你得有那份实力。要吃硬核桃，也得先估量自己的牙口。
「好利」是基本人性，Acer 总裁施振荣先生大力提倡「好逸恶劳」之说，视为人性之本，进步的原动力。谁能说不是呢？好利可以，近利就不妙了。近利代表目光浅短，一切作为都因此只在小格局中打转。
梨园有句话：要在人前显贵，就要在人後受罪。台上一分钟，台下十年功。老祖宗这方面的教诲太多了，身为中国人的我们，应该都耳熟能详。
对於心急的朋友，我只有一句话：勿在浮沙筑高台。你明明很清楚这个道理，为什麽临到自己身上，就糊涂了？急是没有用的，浮躁更会坏事。耐住性子扎根基吧。做任何事都要投资，扎根基就是你对自己的未来的投资。如果想知道如何按部就班扎根基，侯捷网站上有一篇文章：「97/06 选义按部 考辞就班」，请你看看。
口舌之战有何益
最常在程序技术相关论坛上看到毫无价值而又总是人声鼎沸的口舌之战，就是诸如「VB 和 Delphi 谁好」、「BCB 和 VC 谁优」、「Linus 和 Windows 谁棒」、「Java 和 C++ 谁强」这种题目。每次出场都一片洋洋洒洒，红红火火急速窜升为超酷话题。众人各拥所好，口沫飞扬，但是从来说服不了任何异阵营的人，话都只说给自己人听，给自己人爽。
这样的论战有何意义？许多人在重组自己的偏见时，还以为自己在思考呢。战到最後，就只是争谁说最後一句话而已。而且，擦伤引起的争吵几乎总是以刺伤结束。
工具与技术的评比，是一场高水准的演出。真有能力做评比，侯捷是很尊敬的。但是这些各拥所好，口沫飞扬的人，真的对评比两造都有深刻的了解吗？很多时候我们看到的只是无知，而无知是这麽一种东西 : 当你拥有了它，你就拥有巨大的胆量。
很多人喜欢某种工具，只不过因为那是他的初体验。他玩它玩出了一点心得，可以说出它的某些好，就开始做「评比」了。你只看到牡丹的艳丽，又怎知寒梅的清香，幽兰的空灵？
绝大多数人使用某种工具，不是因为它最好，不是因为众里寻它千百度，仅仅只是因缘际会。虽然说不同的应用环境选择不同的工具，是最伶俐的作为，但我真的怀疑，在现今工具（以及工具背後反映的技术）如此繁复的时空下，有多少人能够同时精通一个以上的同质工具？追二兔不得一兔，我还是认为你精专一样工具，把它发挥到最高效能，获得的利益多些。被大家拿来评比的，都是市场上的佼佼者，还能差到哪里去？能够两雄相争，必然是在技术面、非技术面（资源的普及、品牌的可靠度）各有一片天，你的评比意义大吗？全面吗？
大多数人没有能力同时精通两种同质工具，初学者听了网路上不知名大侠的高论，也不可能有所选择（如果有，怕也只是蒙着头瞎选）。这种没有提供数据，评论者也没有显示任何信誉（credit）的论战，没有任何意义，纯粹只为自己爽。浪费网路资源！
C++ 之父 Bjarne Stroustrup 曾经在他自己的网页上的 FAQ （以及其他许多场合）中回答如下问题。虽然其中谈的是语言，但是扩大到其他层面仍然合适，值得大家好好咀嚼（注：全文由孟岩先生译出，可自侯捷网站浏览）：
Q: 你愿不愿意将C++与别的语言比较？
A: 抱歉，我不愿意。你可以在The Design and Evolution of C++的介绍性文字里找到原因。有不少人邀请我把C++与其它语言相比，我已经决定不做这类事情。在此我想重申一个很久以来我一直强调的观点：语言之间的比较没什麽意义，更不公平。主流语言之间的合理比较要耗费很大的精力，多数人不会愿意付出这麽大的代价。另外还需要在广泛的应用领域有充份经验，保持一种不偏不倚客观独立的立场，有公正无私的信念。...
人们试图把各种语言拿来比较长短，有些现像我已经一次又一次地注意到，坦率地说我感到担忧。作者们尽力表现出公正无私，但最终都是无可救药地偏向于某一种特定的应用程序，某一种特定的编程风格，或者某一种特定的程序员文化。更糟的是，当某一种语言明显地比另一种语言更出名时，一些不易察觉的偷梁换柱就开始了：比较有名的语言中的缺陷被有意淡化，而且被拐弯抹角地加以掩饰；同样的缺陷在不那麽出名的语言里就被描述为致命伤。同样的道理，较出名的语言的技术资料经常更新，而不太出名的语言的技术资料往往是陈年老酒，试问这种比较有何公正性和意义可言？
Q: 别人可是经常拿他们的语言与C++比来比去，这让你感到不自在吗？
A: 当这些评比不够完整，或者出於商业目的，我确实感觉不爽。那些散布最广的比较性评论大多是由某种语言，比方说Z语言的拥护者发表的，其目的是为了证明Z比其它语言好。由於C++被广泛运用，所以C++通常成了黑名单上的头一个名字。通常这类文章被夹在Z语言供货商提供的产品之中，成了其市场竞争的一个手段。令人震惊的是，相当多的此类评论竟然引用的是那些Z语言开发厂商的员工的文章，而这些经不起考验的文章无非想证明Z是最好的。尤其当评论之中确实有一些零零散散的事实...，特意选择出来的事实虽然好像正确，有时却是完全误导。
以後再看到语言评比文章时，请留心是谁写的，他的表述是不是以事实为依据，以公正为准绳，特别是评判的标准是不是对於所引述的每一种语言来说都公平合理。这可不容易做到。
我说过了，真正精譬的技术评比，对於相当程度的研究者，是很有价值的，但我很少在论坛上看到精品 ─ 论坛还能有什麽精品，99% 是打屁闲谈没有营养的文字。我们每每在其中看到偏见、我执、以及最後免不了因擦伤而引起的刺伤。这真令人伤感。这些人把时间拿来学习，多好。奉劝各位少花时间瞎打屁，多花时间学习，看些真正的精典，别动不动就在论坛上提问，也别动不动就挂在论坛上看别人的瞎打屁。
不但评比性的话题，大家喜欢强出头，其他话题，情绪性的反应也很多。中国强盛之道，眼前彷佛全压宝在 IT产业（尤其软件工业）上面。程序员被赋予了过多的期许，程序员也自我膨胀了许多。夹杂着民族主义或个人好恶，看到不满意的人事物，就号召大家「黑（hack）」过去。这是什麽心态？比拳头吗？说实话，就算要比拳头大小，「黑」个网站算是什麽尺寸的拳头？网路是个大暗室，君子不欺暗室。
杂志定位在哪里
CSDN上头，前一阵子曾经请大家就《程序员》的定位问题给意见。很热闹。我不知道刊物掌门人在看了那麽多建言之後，有没有收获。猜想是没有 ─ 就算有也恐怕不大。
就像面对书籍一样，读者最直观的感觉，就是要看他所需要的东西。100个人有100种需求，这样的询问得不出总结。隐性读者、不上网的读者、不投票的读者、不写帖文的读者，你又如何知道他的想法。
我以为，只需把握一个原则：永远比大众水平高一个档次，扮演引导者，带领读者接触前沿思想与宏观视野，那就是了。读者本身会成长，不论你把刊物定位在实质技术的哪一个层次，都会有人不满足；今年的读者成长了，不见得明年还是你的读者。唯有保持前沿思想与宏观视野，时常导入新的技术形式、新的思维、专家的见解、意见领袖的看法，才能够长期吸引读者，并对许多人以及整个技术开发环境做出长久的贡献。
美国大物理学家费曼，曾经批评物理课的教学。他说老师老是在传授解物理习题的技巧，而不是从物理的精神层面来启发学生。这一点是不是可以给刊物经营者和刊物读者一点点启发？
以此观之，就我个人的专长领域，STL 之父访谈录、算法大师 Donald Knuth 采访、C++/OOP 大系、GP/STL 大系、将标准C++视为一个新语言┅以及一些总括性、大局观的文章，是我认为最好的主题。此中有侯捷自己的作品，唔，我向来不客气。
当然啦，太形而上的东西是不行的，太过抽象的东西不容易被接受。抽象层次愈高，人的自由度愈大，但抽象思考是层次高的人的专利，要普罗大众能够接受，还需具象细节稍做辅助。
如何长期保持具有前沿思想与宏观视野的稿源？与外国杂志合作是一个既快又好的办法。每一期《程序员》最前数页都有当期重要外文期刊的前沿摘要，可见《程序员》编辑群一直与外文专业期刊保持着阅读上的接触。要挑选合作夥伴，心中一定有谱。
当然啦，与国外合作涉及经费问题。旁人（尤其读者）很难体会或换位思考经费上的种种困难。就像有人痛心疾首义正词严地埋怨 CSDN 速度慢得像蜗牛，却可曾想过网站的资源从哪里来。向你收费，你接受吗？台湾已经倒掉很多很多家着名的网站，我等着看免费的服务撑到几时。
要刊物宏观耐读，读者们也得成熟些。一群很好的读者，才拱得起一本很好的刊物。
下面是一封读者来信：。
软件工程对整个软件工业的提升，至为重要。但是一个程序员要修练到对「软件工程」这个题目感兴趣，非三五载（甚至更多）不为功。我的意思是什麽呢？我的意思是，这类书籍、这类工具、这类网站、这类刊物，在一个嘈嘈切切、急功近利的环境中难有生存空间。这是为什麽蒋涛先生想要将《程序员》杂志导向软件工程主题时，我对他兴起巨大的尊敬与忧虑的原因。
现在技术发展太快了，国外（甚至印度）在实现「软件工业化」的时候，大陆（至少我周围是这样）还停留在小作坊手工打造的水平。我认为未来的世界不再属于「个人数字英雄」，软件工程似乎比一两项技术更迫切。以您的大局观和丰富的阅历，对这个问题是否有不同的看法，不知您是否愿意就此从技术（或其他）角度写篇文章发表您的见解
顺带一提，《程序员》的文字水平一直以来带给我「阅读的乐趣」。这个评语我从来少有机会用在台湾的电脑刊物或电脑书籍上。比起台湾的电脑读物，这里的文字有深度多了。
轻浮躁进没信心
只要上网看看程序员出没的论坛，你就会看到一片浮躁与焦虑。反映出来的就是没有信心。
「C# 推出，Java 将死」，「Java 演进，C++ 将亡」，「.Net 推出，VB程序员死定了」，「Kylix 推出，大夥儿快学」，「Delphi 持续新版，哥儿们别怕」，「我刚学VC，怎麽它就出场了」，「MFC 真的要过时了吗」┅。诸如此类的问题，不知该归类为谣言还是童语？
很奇怪也很感叹，为什麽大家对这类问题如此感到兴趣。那透露出一种肤浅 ─ 没有深刻了解技术本质，因而汲汲营营慌慌张张惶惶惑惑於新工具、新事务、并且认为新的大概一定都是好的。对自己没有信心，对整个环境也没有信心。
有深度的程序员绝对不会在意这种事情。当然，并不是早晚三柱香就万事保平安。并不是告诉自己别在乎别在意，就真的能够不在乎不在意了。那必需是发自内心，胸中自有丘壑的一种笃定，有着好的本质学能做靠山。
台湾 BBS（连线）前阵子也有许多热烈讨论 Java, C#, C++, .NET 的贴信。我把我最欣赏的一封引於下。其最後结语，扩张到任何领域都是合适的。
发信人: [email protected] (流云), 看板: programming
标 题: 一些想法Re: 不懂,业界一直喊Java,在喊些什麽..."
发信站: KKCITY (Sun Feb 18 12:55:49 2001)
以目前台湾业界的情形来看，C\C++ 应该是想成为一个软体工程师的基本技能；至於 Java，如果熟悉 C++，学 Java 应该花不了一个月的时间。
以我个人的观点，Java 的 OO 程度是胜於 C++ 的，而且在这个 Internet盛行的年代，效率的瓶颈在於网路本身的频宽而不在单机执行时的效率，Java 所提供的 Collection framework 是非常威力强大的程式设计工具，又内建了对 Multi-thread 程式的支援，丰富的 class library 让人在设计网路、资料库┅的相关软体时无後顾之忧。
C++ 可能是过去十多年以来最重要的程式语言之一，它的效率显然较Java为佳，但在撰写需要安装在Internet上成千上万种不同厂牌的机器上执行的程式时，相对於Java可能就不是最好的解决方案。
「目前」不需要以 Java 来开发 DeskTop 上的应用程式，因为「当下」而言 Java 撰写的程式相对於 C++ 会占据更多的记忆体且执行效能不彰。
我们不能期待免子游得比鱼快，也不能期待鱼飞得比鹰高。
工程上的需求使得各种场合有不同的适合的程式语言，不必费心去批评 A、推崇B、打压 C。基本的理论比这些事重要多了。
VB 将死？Java 将亡？C++ 将被 Java 取代...，这很重要吗？我用Java 也用 C++，即使明年它们全都被 Java++、C++++、Lisp++、Forth++取代，何有於我哉？FFT 还是 FFT、Dijkstra algorithm 还是Dijkstra algorithm...还是别太担心这些事了...
侯捷除了偶在 BBS 上自说自话外，绝少回应或叁与讨论。看了上封信，忍不住回了一帖：
作者: jjhou (jjhou) 看板: programming
标题: 一些想法Re: 不懂,业界一直喊Java,在喊些什麽..."
时间: Fri Feb 23 21:12:14 2001
同意你的看法。写得非常精采。
人到了一个层次，才会去思考事物的本质是什麽，不被浮面的工具所系绊。
熟练工具是必要的，但工具的演化汰换，不是大家在这里关起门来喊爽就好。
Donald Knuth 说：「语言持续演进，那是必要的。不论现在流行什麽语言，你都可以肯定十年二十年之後它不再风光。我总是在自己的书中写些不时髦的东西，但这些东西却值得後代子孙记取。」（注：以上局部是《程序员》2000/12 的译文）
DDJ 1996/04 p18:
"Language keep evolving, and that is necessary. ...Whatever computer language is in fashion, you can guarantee that whitin a decade or two it will be completely out of fashion. In my book, I try to write things that are not trendy, but are things that are going to be worth remembering for other generations."
追求新知固然是一个计算机从业人员该有的态度，但是追求新工具与充实固有知识两者之间，应该取得一个平衡。过犹不及！
再说，凡走过必留下足迹。你现今的任何努力，只要它是扎扎实实的，就绝不至於落空。技术是有累积性的呀，技术总是触类旁通的呀。你说 MFC 和 OWL 就没有累积性，我说有，message map 的原理不一样吗？framework 的工作原理不一样吗？
我个人并非任何语言或任何工具或任何技术的狂热者，我是务实派。对於自称熟稔多种（属性不同的）语言的人，我充满敬畏并保持工作上的距离。要精通一个语言，使自己能发挥其最大效能，不是件容易的事，需要不少精力的投注。99.99% 的人都是凡人，身为凡人的我们，把时间用来精通一（或二）种适合其工作性质的「语言」，比泛泛认识多种「语法」，要高明得多，回报也大得多。
真的，还是别太担心谁将兴起谁将亡的事了吧。
天才的沃土
教育永远是我最关心的议题。教育的重要性绝对不亚於产业。没有好的教育，何来好的产业人才？
学校教育就不提了，那不是侯捷能够着力的地方。虽然我也在大学教书，但一年不过教育数十位学生，影响能有多大？书籍的读者动辄数万人，刊物的读者动辄数十万人，这才是有大影响力的地方。
自修教育如影随形，打你离开学校就跟随你一辈子，重要性远胜於学校教育。谈到自修，离不开读物 ─ 各种型式的书籍和刊物。在咱们程序员这一行，书籍和刊物的情况如何？
下面是一封读者来信：
我记得您说过，到一个地区的书店去逛逛，对这里的IT技术水平就知道大概。这话太得我心了。我学习软件技术5年，花在买书的钱有一万二千（人民币）以上，如今回头来看，绝大部份是垃圾。以前曾经担心：若要到外地工作，这麽多书怎麽带走？现在则是一种心痛的轻松，因为值得带走的书只够一提。学习IT之初，谁不想在产业上做出一番成成绩？但多年之後回首，则恐怕都会为自己当时所处的教育环境痛心。
关於计算机书籍的浮滥、低劣，我收到太多太多的读者反应了。以上只是冰山一角，有兴趣的读者请上侯捷网站看个饱。有些出版社甚至以出烂书闻名，看看这封信：
您想必看过蒋先生在《程序员》上写的文章，知道所谓IT出版四大家。蒋先生可能碍於礼仪，有些地方还没讲透。例如其中的XXX出版社，在译作方面现在已经是一块榜样粗制滥造的榜样。
再看这封信：
我在您网站中看到了有关对关於xxx 出版社的评价，深有感慨。其实该出版社是大陆IT业引进外文书籍的鼻祖，我们这一辈程序员(92年以前的)就是读该出版社的译着成长起来的（我至少还有两大纸箱xxx出版社的旧书），在那个时候，差不多所有的计算机类图书都是它们引进并翻译的，现在看来，那个时候的翻译质量差得无法忍受（比Incide VC++ 5/e还差许多），但我们那个时候已经很满足了，毕竟有比没有好。现在大家对xxx出版社的批评，我想是竞争的结果，因为大家看到了更好的译着，有了比较。总而言之，xxx 出版社当年的特点是大量翻译，草草出版，让科技人员能够在尽快的读到优秀作品。这种作风显然已经不合时宜了，或者说它已经完成了它的历史使命。我现在当然也不象从前那样狂买xxx 出版社的书了，因为有了更多的选择。
这封信让我跌入回忆。台湾也曾有两家出版社，有过同等劣质的作法。这两家恶贯满盈的出版社，一名莹圃，一叫松格。两家都关门了。他们的作法都是，快速而大量地翻译外文书。由於速度快，也由於选材之中不乏好书，所以曾经拥有一定的市场。怎地都关门了？因为读者只能被欺负一次两次，不会永远当傻瓜。这样的出版心态摆明没有长远打算，只想捞一票走人，不关门才怪。
我们可能因为，垃圾堆中多少捡过一些经过修补尚称堪用的东西，而对刻意制造这些垃圾的人产生一种奇怪的情愫。东西明明不好，但我们从中吸收了一点点养份。该谢他还是该恨他？
该唾弃他！
这些商人之所以大量而快速地引进外文书，因为有利可图。有利可图是好事，但他没把他该做的事做好。他们放弃品质而无所惧，因为他们知道，在怎样的时空背景下可以怎样轻松地赚钱。大陆出版界朋友告诉我，谁谁谁（都有名有姓）很轻松地在几年里就这样积聚了几百万人民币的身家。几百万人民币呀，我的天。这也算 IT 产业吧，果然是一片红火，鸡犬升天。
因努力做事而致富，应该得到我们的赞美和祝福。可这样的出版社，花更大的功夫赚更多更长远的钱他们不要，因为轻松钱赚起来不费劲儿。百分之一的人可能从这些垃圾中吸收到一些养份，百分之百的人从中感受了阅读的痛苦。谁知道从中被误导的人又有百分之几？买书的钱我们没少花，得到的正价值却是那麽少，痛苦指数那麽高。
这位读者说『总而言之xxx 出版社当年的特点是大量翻译，草草出版，让科技人员能够尽快的读到优秀作品』，又说『它们引进并翻译的，现在看来，翻译质量差得无法忍受』。喔，一本优秀的原作，经过无法忍受的翻译质量洗礼後，还会是一本优秀的作品吗？待人宽厚是美德，但是刻意制造馊水油让人吃坏肚子者，不值得为他们说话。你说『它已经完成了它的历史使命』。不，他们从来就没有历史使命，也没有使命。
如此「仁厚自持」而且忍耐度奇佳的读者，相当稀少。绝大部份程序员谈到计算机图书，都是斑斑血泪的控诉。《程序员》2001/03 p119 可不就有一篇「计算机图书出版商的陷阱」。
读者来信写道：
鲁迅说，未有天才之前，应该要先营造天才的土壤。...您的心情我确实能够深刻理解（这大概就是堆在墙角那几百本垃圾书的最大贡献吧）。
「天才的土壤」，嗯，鲁迅说得好。不正应该是出版社的职志吗？我们却能向谁说去？其实我们也只是希望有一些好书造就一些资质不错的程序员而已。前一阵子才沸沸扬扬於印度程序员与中国程序员的比较，我们哪企望天才？不过就是希望培养一些扎实的人才而已。
看倌也许奇怪，书不好，侯捷为什麽不把矛头对准作者，却大骂出版社。哇勒，我早就抱着「得之我幸，不得我命」的卑微态度，不敢期望创作性中文好书。上面我说的，以及读者最痛心疾首的，是翻译书的低劣水平。人才济济的中国，怎麽可能找不到够格的译者？如果不是出版社的抢钱抢短心态，会造就出这一大批劣品吗？我能不怪罪出版社吗？
到头来，还是要靠自己。「计算机图书出版商的陷阱」一文最终是这麽说的：『记住，您花的是自己辛苦挣来的钱，所以千万不要浪费在没有用的东西上。对於出版了优秀图书的出版公司要有所回报。买他们的书，给他们写信，让他们知道你在想什麽，你需要什麽。』
良性循环
一个体系的建制，需要从底层到顶层的坚实构筑。不论是 C++, Java, .Net, OO, UML, Windows programming, Linux programming，每一个主题欲成就一个完整体系，都需要一大套书。拿C++/OOP 来说，就得涵盖语法语意的、物件模型的、专家经验的、设计样式（design patterns）的、入门的、进阶的，作为叁考工具的┅。拿 GP/STL 来说，就得有 GP 泛论型的、STL 源码剖析的、STL 应用大全的、STL 规格大全的、STL 组件设计的、其他泛型技术的┅。拿Java 来说，就得有语言核心的、物件导向的、多绪编程的、图形介面的、网路应用的┅。对生手而言，不先把底层的东西弄清楚就学习高层的抽象，必会成为空中楼阁，流于形式。对熟手而言，缺乏抽象思维，意味层次上的停滞。
写作、翻译、乃至於出版全体系好书，真的是一件需要目光长远、意志坚定、带点理想色彩的人，才做得起来的志业。
如果这样的人，这样的出版社，没有得到大家理念上和实质上的支持，谁会投入这种傻事？
我个人一向是高品质高价位的坚定信奉者。高品质高价位是生产者经营的最大诱因。因为努力做出了高品质，所以得享高价位带来的高利润，天经地义。否则谁要费心去做高品质？慈善家吗？傻瓜吗？
对於消费者，高价位当然令他不舒服。但是你应当思考是否物有所值，甚至物超所值。拿英文书为例，USD 49.95 一本的 The C++ Standard Library，或是 USD 49.95 一本的 Generic Programming and the STL，完全物超所值。当我了解这些书的价值，就算他们再贵两倍，我也要买。有人拼死吃河豚，我可是要拼命买好书。现实地说，眼下「知识经济」喊得震天响，好书带来的知识不正是赚钱工具吗？对赚钱工具小气，是不是和自己过不去？
下面是一封读者来信：
相较日本无论是漫画作家、文学作家或是偶像歌星、影星的客观条件来比较，在台湾，身为专业作家竟如此难为？有人可以连夜搭帐篷排队买票看演唱会，有人却可以论斤计两地讨论页数与书价高低。或许他们不知道，一本介绍C程式语言的入门书，在德国索价100 DM (约NT$2000)。因此我的德国同事们购书前必定徵询意见或叁考书评。书价虽不低，但其读书风气仍不亚於日本。
这里点出了一个重点：书价很高，於是大家慎选好书，重视书评。下面是另一封读者来信：
我是一名大陆的读者，同时也是一名计算机的初学者。我在网上看到网友都十分推崇您的着作及译作。知道您的作品《深入浅出MFC》第二版即将在内陆出版，我决定买这本书，并与华中科技大学出版社取了联系。从那里知道您今年还会在大陆出几本书，我非常高兴，但在知道了您对价格的看法後，又有些失望。
大陆与台湾的经济水平是不同的，作为普通的工薪阶层，购买力也是有限的。我们这里，各类图书中计算机类图书的价格是最高的，图书页码的最高位与书价的最高位基本相同 -- 700页的书，价格在70到80元之间，1000页以上的，价格在100元以上。这是目前大陆书价的大体情况。如果按您所说，350页，书价80元，在这里算是很高的价格了，这种价格的书，只能看，不能买。
"春蚕到死丝方尽，蜡炬成灰泪始干"，教师工作被我们看成很神圣的职业，燃烧自己，照亮别人。我想您出书的目的，也是想让更多渴望知识的人受益于它，少走弯路。作为读者，我们也希望能够看到更多更好的书。但是在一定历史时期内，购买力与价格应当有一个平衡，350页80元的价格确实太高了，如果能够降到60元以内，我相信大多数读者可以接受。
您的书的品质很高这是大家的共识，从价格上应当与其它书区别开来，但书价也不宜太高。名牌服装走高价位的路线，当然可以提高它的身价，显得它档次很高，但是太高的价格使它脱离了主要的消费群体，大多数人只能在口头上谈论它，却只有极少数的人会把它穿在身上。书籍与名牌服装不同，只有经过很多读者长时间的阅读之後，才能够证明它的价值，如果很多人都知道侯先生的书质量很好，但是却很少有人读过（因为价格问题），那岂不是一种悲哀。
我最不乐意看到「xxx 页的书，售价 xxx 元」这种观念。一本书的价值在内容，不在页数。真要这麽算，每本书我们都应该检视一下其字型大小、行距字距、硬拷图多寡、留白多寡 -- 因为这些都关系着页数。如果大家都接受页数和书价的固定比例，肯定会有大量浮滥的书跑出来（不就是现在的情况）。
不必这麽累。一本书值它的价，就买；不值它的价，就别买。很简单的逻辑。
我们难道能够拿着尺衡量一件亚曼尼用了多少码布，来决定它的价格吗？或是拿着尺衡量一张梵谷是几号，来决定它的价格？我能够说因为我画的绣球花比梵谷的鸢尾花大两倍，所以我应该卖他的两倍价？
买东西不能光看有形；那无形的往往更重要。买书不是买纸。正确价值观必须建立起来。
当然很有可能你认为买名牌服装或名画的人都是疯子。你要的只是布和框。那表示那些物品在你心中不值那个价。很好，你有你的评价，你有你的选择。
我不打算在「引喻」（例如名牌服装或名画）上面多着墨。引喻有顾此失彼的时候，笔战都是这样打起来的。各位知道我要强调的是什麽。
350 页的书，不应该一定卖 80元，也不应该一定不卖 80 元。这要看350页的含金量有多少。况且我从没说过侯捷有 350页的书要卖 80元。但所有的可能都存在。350页可以是180元，也可以是80元，也可能 530 页连 18 元都不值。请不要再以页数做为书价的依据了。
教师的工作很神圣，但「燃烧自己，照亮别人」太沉重。「燃烧自己」，呵呵，说起来多麽容易，做起来多麽痛苦。某人的工作对众人有益，他会很开心。但你要他燃烧自己照亮别人，除非圣人，否则不干的。我很乐意照亮别人，却不想燃烧自己。燃烧自己，我只能照亮别人五年；把自己照顾好，我可以一辈子照亮别人。抬出大帽子，会让有能力写作好书的人畏惧不前。
请大家接受这样的观念吧：书的价值在内容，不在厚薄，不在页数。价值影响价格，价值带动价格。接受这样的观念，便是对好书的所有出力者致上敬意与实质支持。如果大家慎选好书，10 本垃圾书的价格支撑两三本高价（其实是适价）好书绰绰有馀。走编程这条路，谁手上没有 10 本 20 本垃圾书！当大家慎选好书，支持好书（尽管它价格较高），就会带动书评风气，带动优良写译风气。这对所有的人都好。不需有人燃烧自己，大家都被照亮了。
当然，高价位的薄书很可能带来盗印与影印的歪风。但无论如何，我是坚持己见不会退缩的。如果大环境真的无法提升，好书离开了，好人退出了，最後损失的是谁？
不论各位相信不信，侯捷企图以个人影响力（如果有的话）建立优良的技术写作大环境，对台湾如此，对大陆也是如此。「问渠安得清如许，为有源头活水来」，要让大家有更多好书可读，就要有源头活水注入；要有源头活水，就要有更多诱因吸引更多才能之士到技术写译领域来。更多的诱因是什麽？让他们知道，好作品可以突出，可以区隔（讲白了就是有好价格），不会牛骥同一皂，这就是一种诱因。不，这不算诱因，这根本是一种基本道理。
优质的书使读者受惠，优质书籍所带来的高报酬使作者、出版社受惠，并吸引更多优秀人才到这个领域。形成一个良性循环，大家都受惠。
另外我要建议大陆出版社，善用你们独特的「影印版」。台湾的计算机类翻译书，由於也是良窳不齐，窳多於良，曾有读者开玩笑建议，出版社取得授权後，不要译了，直接以原文出版，读者看得高兴，售价又得以大幅下降。想来这就是大陆的影印版（在台湾是不许的）。既然翻译书已到了千夫所指的地步，何不乾脆多多引进影印版？不是要抢短抢快吗？这个最快了，读者也多一种选择。
翻译出了什麽问题
计算机翻译书的一个大问题是，译者没有时间（或正确的心态，或足够的中文能力）将译稿一看再看，一改再改。中文有一个缺点，那就是名词本身表现不出复数，动词本身表现不出时态。多数时候这可能不是很重要，因而可以忽略。但某些时候它们占有关键地位，於是一个精准的英文句子，往往需要译者额外花很大的心力，才能精准地以中文表达出来，那麽译者就得有足够的时间和足够的中文能力。而唯有译者在专业技术上具备足够的素养，才能够看出某些隐微地方对理解之正确性有关键性影响。
英文里头的子句如果又臭又长，别说中国人，老外也得费一番手脚才看得懂。看看这个（C++ Primer 3/e, p730）：
[code..] where the conditional test if (this != &rhs) prevents assigning a class object to itself. This is particularly inappropriate in a copy assignment operator that first frees a resource currently associated with the class in order to assign the resource associated with the class being copied.
我的译文是：
[code..] 其中的条件测试 if ( this != &rhs ) 避免将 class object 指派给自己，因为「自己指派给自己」这个动作，对於那种「先将目前系结於自己身上的资源释放掉，以便稍後将该份资源再系结於即将被拷贝的那个 object 身上」的 copy assignment 运算子而言，尤其不合适。
只需加几个引号，标示出子句，就好看多了。寻常一样窗前月，才有梅花便不同。如果没有引号辅助，你试译看看会是什麽样子。别对我说「根据教育部规范，上下引号只适用於强调专有名词或特殊语气┅」，规范是死的，人是活的呀。只要能够灵活而正确地表现出文意，就是好办法。小Ping同志不是说，管它黑猫白猫，会抓老鼠的就是好猫吗。阿波罗13号登月计划失败时，太空舱内的备用排气罩规格不符，地面控制中心要求宇航员必须想办法将方形罩子塞进圆形的排气管中，否则大家都得因为饱食二氧化碳而死於太空。这时候还想什麽规范？脑筋灵活点。
另一个中文表达的大缺点是：动名词不分。操作是名词（operation），也可以是动词（operate）；实现是名词（implementation），也可以是动词（implement）；叁考是名词（reference），也可以是动词（refer）；请求是名词（request），也可以是动词（request）；委托是名词（delegation），也可以是动词（delegate）。当动词名词混杂一起的时候，就造成阅读上的错乱。於是你可以看到这样的句子（取材自《设计模式》p14，李英军等译，机械工业出版社）。请诸位先看原译，能否就中文语句结构分析出其大致意思：
(1)原译：只有当委托使设计比较简单而不是更复杂时，它才是好的选择。
(1)侯译：只有当「委托方式」简化了设计，它才是一个好的选择。
(1)原文：Delegation is a good design choice only when it simplifies more than it complicates.
(2)原译：委托方式为了得到同样的效果，接受请求的对象将自己传给被委托者（代理人），使被委托的操作可以引用接受请求的对象。
(2)侯译：为了以「委托方式」获得相同效果，「请托（request）受理者」将自己传给被委托人，使自己得以让「被委托之操作行为」取用。
(2) 原文：To achieve the same effect with delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver.
我没有一别苗头之意。我的译法不见得最高明。况且翻译一整本书所需的各种前後呼应的考量，远比光译一两个句子复杂许多。只是既然我提出了问题，我总要提出自己的解法，给大家叁考评量。对於机械工业出版社愿意出版这样一本经典，李英军先生等人愿意翻译这样一本高阶而吃力不讨好的书，我是带有敬意的。
另一个翻译上的问题就是大家往往在计算机类书中硬套一般字典查来的词汇，没人敢突围。要知道，一般字典并未考量电脑技术，更不可能考虑到上下文（context）。太多人抱着少做少错，不做不错的心理，一昧紧跟字典，不敢变动，才会造成目前许多译词不够理想，却动弹不得。我印象最深刻的是这几个字：
instance：台湾和大陆均有不少人译为「实例」。这个「例」字根本不好。台湾甚至有人译为「案例」，更不妥当。为什麽这麽译，因为字典查来的现成词汇是这样。所谓 instance 就是根据某个东西（可能是实物，可能是某种表述）产生出来的一份实际物体。我认为译为「实体」是很合适的。根据 class 产生出来的便是object实体，根据 class template 产生出来的则是class 实体，根据 function template 产生出来的是function 实体。根据可执行档（executable files）产生出来的，则是一份 process 实体。
paradigm：台湾常译为「典范」。为什麽？喔，字典查来的现成词汇。有时候这样译有点道理，例如 paradigm shift 叫做「典范移转」。问题是，何谓「典范移转」？很难望文生义是吧。把 generic paradigm 译为泛型典范，更是令人不知所以。我们日常用语里也有「典范」一词，我们会说某某人是国家社会的典范，那和计算机术语里头的 paradigm 根本不是同一个意思。根据 paradigm 在计算机术语中的实际意义，我把它译为「思维模式」 ─ 典型的、根本的思维模式。
读者来了这样一封信：
我向您讨教一个翻译风格的问题。正如您所说，英文技术书籍最难在长句子，因为英文的句式组合形式比中文大大丰富，理解起来已经费力，翻译成顺口的中文更难。我有时遇到这种句型，切分组合，翻来覆去掂量，还是觉得中文不忍卒读。您认为此时 (1) 我可不可以放弃 "信" 而求 "达"，也就是说略掉部份句子成份以保全译句的通顺？还是 (2) 务求将原义表达出来，宁可中文句子不顺畅也在所不惜？更有甚者，有时 (3) 某些句子无关宏旨，却异常难译，可不可以乾脆略过不译？您的看法是什麽？
（各位有没有注意到，这位读者的中文很好。「切分组合，反覆掂量」这几个字用得多精简传神）我的看法是，译者有权利也有义务通权达变，但也必须有这份能耐才行。因此你的第一个问题我认为可以，你的第二个问题我认为不可以。你的第三个问题我认为可以，但需谨慎为之，莫因译者本身水平，牺牲了某些东西。
科技翻译应该务求义译而非字译。信与达，应从整个句子或甚至整个段落来看，不是从一个个单字来看。技术文章和文学多有不同，译者最重要的任务是正确传达知识，并尽量减少读者的吸收困难。
到底弹性的底限在哪里？我这麽认为，译者於技术层次上愈有把握，便享有愈大的弹性。只要技术层次够，有把握正确了解并传达了原作者要表达的技术，那麽，文字上不必字字拘泥。
中文在科技表达中并非一无是处。中文有一个优点，就是资讯密度高，很多时候精简漂亮的一行中文，可以表达出「子句夹带子句再夹带子句」的三行冗长英文。中文有优美的词藻与取之不尽用之不竭的典故、成语、俗谚，如果善用它们，冰冷的技术文字一下子就能有阅读的乐趣。一本烂译本，会让读者诘屈聱牙，痛苦至极；但是一本好译本，能使人如沐春风。
容我说一句，正确的心态、足够的时间、充裕的中文表达能力、水平以上的专业素养，是造就好译本的基本元素。现今情况如何？话说回头，好译者的报酬几何？你愿意多花点钱表示你对他们的付出的认同吗？
健康的选书心态
以下谈到选书的心态和作学问的态度，由於都以读者来信展开讨论，因此避免不了提到我写的《深入浅出MFC》。我要谈的问题，其实不局限於某一本书，或某一种技术。就像这篇文章先前举的许多例子一样，都是可以放大来看的。
读者修书一封如下：
2 个星期前好不容易读完了您的大作，让我对MFC的认识多了不少，不过一点遗憾的是从您的书里并不能学到如何写一个具体的程序，仅仅是明白了MFC的“包装技术”。本来我还以为又上当了呢因为我买这本书的目的就是要学习用MFC来做程序的...一个偶然的机遇让我得到了 Jeff Prosise的《programming windows with MFC》，这才发现老师您的书是多麽的重要，假如没有您的《深入浅出MFC》我又怎麽可能programming with MFC呢？...您的书救我于水深火热之中，带领我冲破MFC的条条封锁线。
虽然这位读者最终对侯捷和侯捷的书以感谢和赞美作收，但我颇有感慨。
读者往往以最直观的态度来审视一本书的价值，以最直接的方式来表达他的爱憎。但不能凡是不需要的，一律视为灌水；凡不符合需求的，一律视为欺骗。这不是一种健康的选书态度。即使你最後并没有发现《深入浅出MFC》「是多麽的重要，救我于水深火热之中，带领我冲破MFC的条条封锁线」，这本书又何尝在书名或内容欺骗过你，使你「以为又上当了呢」。再者「我买这本书的目的就是要学习用MFC来做程序的」，可是你若连MFC与application 的第一线接轨都不了解，照着葫芦画瓢，能写出多好的程序？
我不是责怪这位读者，只是这封来信代表某些现象，让我心有感慨。下面是另一种偏激：
您的书我觉得有些无用的原理讲的太多了! 你所写的并不是真正的教人怎麽用VC,而是教人VC运做是怎麽样进行的! 其实很多读者真正关心的问题并不是在这里! 而是在怎麽对用VC设计出真正出色的程序!
读者永远只想要看自己想看的内容，这一点很自然。但是你不想看到的东西并非就是「无用」，它对别人可能「很有用」。再说，连MFC与application 的第一线接轨都不了解，照着葫芦画瓢，我不知道你能写出什麽「出色的程序」。只要出一点差错，你连除错的能力都没有。开车是很简单的，开车上路遇到各种突发状况而能应付并排除障碍，才是困难的地方，才是技术的表现。
下面是两封台湾读者的意见，有点年代了。当然我必得先说明，抱持这种态度的读者，比例大约在百分之零点零一。
读者意见一
这本书包装太厚。不该有的东东太多，附录A所列的无责任书评，在我想来也是多馀。因为这篇书评在RUN!PC早有提及，後来也出了无责任书评第三集，因此实在没有这个必要。想来是侯先生要增加书的厚度，有以致也。
读者意见二
书评不应该放在这本书里吧! 因为这些东西而让书太厚实在有点┅这些灌水的东西共计有：
(a)1-16页的读者来函：共16页
(b)超长的序，嗯，这应该没有关系
(c)843-872页的无责任书评：共30页(其实里面有一些发人省思的东西，还好)
(d)873-914页的Scribble原始码：共42页(这最严重，几乎没必要的东西)
(e)915-920页的VC范例程式一览：共6页(很可惜，如果再多加发挥的话很有用，
但是侯Sir只是列个标题，连说明都是英文，和看Help档没什麽差别)
共计：94页
不是我无聊找碴，您可曾看到有哪本书有将近一百页的赘肉?更别题书中动不动就列出四五页的原始码了。这些在光碟上都有，何必浪费纸张? 不过消掉这些赘肉，这本书还是有它的价值┅至於书中缺少的部份，我认为要看您如何去定位这本书。
总不能要求一本书把所有Program的东西讲完吧! 以探讨MFC的内部而言，本书没什麽好批评的了。总而言之，这本书该不该买，我想还是肯定的。但是如果书能瘦点、售价能低点，那就更好了。
说来说去，原来是为了「如果书能瘦点、售价能低点那就更好了」。这便是页数和售价牵扯观念下的可怜受害者，他们扭曲了书籍的价值，也严重扭曲了自己该有的正确价值观。如果我告诉这些读者，少掉那100页的所谓「赘肉」，售价一样是 NTD 860，恐怕他们又要对这些「赘肉」热情拥抱来一个亲亲了。真的是这样，这本书是先确定价格，最後为了给读者更多资讯和更大的方便，我才加上那些「赘肉」的。
这一类读者，站在敌对的立场，看待出版社和作者，幻想每一个人都在觊觎他的钱包，并且认为对他无实质帮助的每一页（可能只是因为他已看过）都是被刻意灌水的结果，都是为了欺骗他的钞票。这样的读者在杯弓蛇影的压力之下，忘记了没有任何一本书是为个人量身打造的，也忘记了其他人可能有不同的需求，完全以自我为中心。
这一类不成熟的读者，实在是当前劣品充斥下的牺牲者。老实说我个人并不喜欢他们成为我的读者。只是，读者有选择作者的权利，作者却没有选择读者的机会。
正确的作学问态度
前面两篇来信透露出一个疑惑，《深入浅出MFC》是不是一本对VC编程有帮助的书。我不是要在这里夹带推荐该书（相信我，我不需要如此），而是想透过MFC与VC的关系，引申谈谈作学问的态度。如果「作学问」太高远了，那我们来谈谈「学习」的态度吧。
以下是一封读者来函：
我有个疑惑，想请你帮助。我们今天学C/C++，明天学MFC，OWL(如果流行的话)
後天学C#，JAVA...如果 WINDOW 被 X WINDOW 淘汰，岂不是都要从头学过？有没有必要把一切搞得如此精通？同样的目的，为什麽不用更方便简单的快速RAD开发工具？而非要以钻研繁杂作为乐趣？和体现水平？是否搞错了方向和目标？我认为这正是目前大陆（台湾我不了解）软件开发的一个错误的方向。
所有同质的技术都有累积性与共通性。信中提到的三组东西：MFC, OWL, 或是 Windows, X Window, 或是 C++, Java, C#, 都有类似性与共通性。技术是会累积的，有了某种经验，学习新技术会快很多。经验愈多，学习愈快。所以我常喜欢说「触类旁通」。如果每种技术都得从新学习，大家三五年就得归零一次，人类世界就不会在 20 世纪像爆炸似地进步这麽快。
「有没有必要把一切搞得如此精通？」我的回答是：看个人需求与定位。基础知识的精通，是做为应用的一种过程与手段，而不是目的。如果你不需要通过这样的过程，就可以把你要做的事情做得很好，那麽当然你可以跳过这个过程。我所知道的是，许多许多人必须先有这样的过程，才能够良好达成期望目标。我自己也需要通过这样的过程（否则写不出这样的书）。这不是你所谓的「钻研繁杂」或「体现水平」。
既然信中提到RAD，我也谈谈我的看法。我曾经写过一篇文章，把RAD喻为「匹夫无罪，怀璧其罪」（见侯捷网站 1999/01/26 怀璧其罪 RAD），建议各位看看。我很赞成使用RAD。我书写MFC书籍，探讨MFC技术，但从来没有认为它最好，或不好，我只是要帮助那麽多使用MFC的人。和 Bjarne 的态度一样，我对诸如此类的工具评比活动一点兴趣都没有。我乐意当一名观众，但从来不评比（应该可以说，也没有能力评比）。
RAD 的情况，可以拿汽车做比喻。现今谁开车还需要知道齿轮箱、传动轴、离合器、引擎点火原理、火星塞呢？但是满街开车人谁又能够表演360度大回旋？要到达「车手」的程度，就必须对车子的原理有相当程度的了解。同样是开车，洗拿（F1方程式冠军车手）和侯捷两人发挥车辆功能的程度，绝对有天壤之别。我认识的所有惯使RAD 的高手，无一不是有底层深厚功力。以RAD始，以RAD终，断不能在技术上有所太大长进。你的生涯将是空白的五线谱，没有高音，没有低音，永远的水平┅。
RAD是要用的，有好工具不用，和自己过不去。但是使用RAD的同时，对底层做更多的了解才有助於在某种情况下脱困或自助。这和 STL 的运用也一样。会用STL，是一种档次。对STL原理有所了解，又是一个档次。追踪过STL源码，又是一个档次。第三种档次的人用起 STL 来，虎虎生风之势绝非第一档次的人能够望其项背。
学习某种工具，及其背後代表的某种技术，究竟要钻研到什麽深度？唔，答案视你想扮演什麽角色而定。「F1方程式车手」和「半夜三点才敢上台北大马路的用车人」之间，有许多许多的层次，你自己定位自己。
有些人绝对拥护RAD，有些人又重新反省RAD。下面是另一封信：
我在「怀璧其罪 RAD」一文中是这麽回答的：
1. RAD 并非罪恶，而是优点。要怎麽用它则是你自己的问题。我有两位朋友是 Delphi 专家，他们可以使用 Delphi 做任何事情，没有任何你想像中 RAD「该有」的限制。
2. 果真能够「写一个程式，比使用 Office 还要简单，深入的思考几乎是零」，并不是坏事。大家都能够随手写个小程式解决手边几个小问题，是为component software 以及 RAD 的大贡献。但你的形容太夸张了，目前的 RAD 还不至於美好若此，总还需要一些程式逻辑和程式语言的基本训练。真到了你说的那一天，我觉得是件好事而不是坏事。只不过，那样子完成的程式，都需藉助现成的元件。如果要突破现成的框框，就得有更深的功力。无论如何，RAD 不会是你的绊脚石。
这类话题很难一言以蔽之。总之，优秀的技术者一定需要一个向下沉淀的历练，通过了这层历练，有了扎实的基础，就可以向上浮升，开始以抽象的思考，抽象的语言、快速开发工具来进行高层次的开发工作。这时候运用 RAD 工具，当能如虎添翼。
所谓百炼成钢；钢的形成，是将铁块不断锤打，不断回火，不断淬炼。做为一个程式员，本身技能的层次，和回火淬炼的次数有密切关系。
让我们再回头谈谈基础建设。很多资讯科系在学学生对学校所开的课程，非常不服气，非常不屑，认为对编程能力一点帮助也没有。首先我要说，编程、软件开发并不是资讯系学生的唯一出路。资讯领域何其广泛，编程只是其中小小的一支而已（但对就业市场而言则是大大的一脉）。其次我要说，基础理论课程并非对你的编程一无是处 ─ 不是无用，只是未到用时。有些科目的影响非常直接而深远，例如对编程最重要的两门课：资料结构（data structure）和演算法（algorithm），这两门课对逻辑思考与实现能力的训练，有关键性的价值。没有这两门课做底，任你 C/C++/Java 多强多行，也写不出个好程式。其他基础理论课程也都各有用途，会不会在你未来的编程生涯中带来帮助，那得看你编哪一种程。就业与学校所学，不必然会发生关系，不必然不会发生关系。
编程能力强的年轻同学，容易孳生一种趾高气扬的恶习，看这不顺眼，看那不顺眼，教授都老朽，同学都可笑。问他为什麽，哦，因为「他们的编程功力都不如我」。可笑的正是你自己呀。
编程实力的培养其实很容易的。我所谓容易，是指不需借助外力，纯粹自修就几乎可以做到。再没有比这更幸运的事了。当然你的进修必须按部就班（在我的专长范围内，我写了很多让你前进时有所依循的文章，都在侯捷网站上）。任何高深的理论，只要实际操作过都可以霍然理解，编程的实作又有什麽难的。数本好书，一部电脑，一些必要的工具，全部搞定，只欠一股「头悬梁锥刺股」的苦读精神。实力进展到一个阶段後，我非常鼓励你追踪名家源码（有人指导更好）。司马相如说：能读千赋则善赋，能观千剑则善剑。侯捷说：读过千赋亦能赋，观过千剑亦能剑。
最後我还要说，学校（尤其大学）原本不是职训所。但是关於人格的培养，思想的启迪，视野的开拓，现今言之，恐怕是陈义过高，没人爱听了。
学校肯定有学校的缺失。其一是课程太过理论，高来高去。以大学生的程度而言，太过抽象的东西他们是没有能力接受的。但是要化抽象为具象，化繁为简，可得有非常深厚的实力才行。其二是教材、教具、教师太过陈旧，跟不上时代。我印象最深刻的是，台湾BBS时常有学生问 Turbo C 3.0 上的问题。我的妈呀，C++ Standard 都出来两年了，学校还在用TC3.0。倒不是说一定要追最新最炫的工具或产品，但是TC3.0 距离 C++ Standard，有月球到地球的距离吧。用这个编译器，可想而知老师教的是什麽内容，可想而知老师本身跟上外界脉动的程度。如果新工具新产品都很贵，顾及学校经费，我们也能体谅。可 Borland C++ 5.5, GNU C++ 2.96, TAI C++ 都是可以免费下载或限期试用的呀。它们对 C++ Standard 的实现，比TC3.0 好太多太多了。
这就涉及学校教育里头最重要的关键：师资。说句实在话，大学里头有不少老师，书是念得很棒，就是没有实作经验，更没有业界经验。因循苟且之念一动，万年教材一摊，同学们就只有自求多福。
自救之道当然有：你必须更勤奋。勤奋看书，勤奋发问。勤奋搜寻好的导师和好的读物。或许天道酬勤，就让你碰上一个传道授业解惑的贵人，就让你知道一本必读的经典，并且就让你找到它。
说到勤奋发问，让我发出本文的最後一声感叹做为结束。台湾大学生在「表达能力」这一点，程度普遍低下幼稚。能够条理分明把自己的意思表达清楚的，十分罕见。反映出来的，就是怯怯懦懦，理不直而气不壮。私底下声若洪钟，要他站起来公开表示意见，却如细蚊之嗡嗡。不论口语或文字，用词普遍地「俗」。大陆情况，就我的印象，以及我收到的读者来信，感觉好很多。以前台湾的说法是，因为大陆斗争厉害，人人得有一口利嘴以求自保。但文革已过数十年，我看大家的表达能力普遍还是很不错，是不是求学阶段中曾经特别重视这个？
发问的能力影响学习甚巨。善问者使人继其声，善教者使人承其志。我常自诩为一名善教者，但如课堂上兼能有一名善问者，高潮迭起，全班受惠。
我原本是一个一天到晚使用RAD工具的人...但是历经了三个版本之後，我有一种被骗的感觉，因为处在这个环境中，似乎是投身在别人设好的一个圈套里！这种东西会让人对於『了解 OS 内部运作以及各种规范与协定的基础层面』的欲望慢慢减低至零。今天为了突破某一个元件的限制而自己写了一个元件，明天新版RAD内附元件就出现了比自己写得还要好的东西。到了最後，自己不想写，只想等别人写给你
；要是别人不写，你就彻头彻尾地丧失了一项能力...(天晓得要等到何年何月)，要不然就是官方给的元件功能少东少西。不只这些！最让我受不了的是，我竟然发现：程式用这种方式去写，简直就比用Office 还要简单，深入的思考几乎是零...。