受到美国和伊拉克战争所带来的恐怖威胁影响，今年的奥斯卡颁奖典礼破天荒地取消星光大道，让许多喜欢在红地毯旁欣赏偶像风采的影迷，大失所望。

由张艺谋执导，颇受全球华人瞩目的电影英雄（Hero），入围今年奥斯卡最佳外语片。Hero 除了是「英雄」的意思，也常作「偶像」解，且比 idol 或 icon 更常用。例如，Bette Midler 在电影 Beaches（情比姊妹深）里面的那首「Wind Beneath My Wings」，有句歌词「Did you ever know that you're my hero? And everything I'd like to be?」，正是「偶像」的意思。

这次的文章要介绍的几个偶像，正是我努力学习的对象（everything I'd like to be）。他们共同具备的特色是：能够与时俱进，不会在新技术出现后被淘汰。

首先介绍的是大名鼎鼎的 Charles Petzold。他是 Windows 程序设计的鼻组，甚至是 OS/2 程序设计的鼻组。十多年前，在 Windows 3.0 的时代，我就已经开始买他的《Programming Windows》一书了，目前该书已经出版到第五版，我几乎是每一版都买，我甚至有幸在大学时期与人合译该书第三版。在进入 .NET 时代后，Charles Petzold 也写了一本《Programming Windows with C#》。这么多年过去了，Charles Petzold 依然维持 Windows GUI 程序设计首席作家的地位。

尽管 Charles Petzold 是 Windows GUI 程序设计首席作家，但是他显然对 MFC 很不捧场，他说：「I never like MFC. Ever since it was introduced, I thought it was poorly designed and barely object oriented.」（我从来就不喜欢 MFC，从一开始就不喜欢，我认为它的设计不良，且几乎不能算是对象导向）。也因此，他未曾写过 MFC 的书。

许多人都以为 Charles Petzold 只写 Windows 的书，其实他也写了一本计算器概论的书，名为《Code》，等于是把信息系好几门课的精华浓缩在一起，写得相当浅显易懂。如果你不是信息系科班出身，我建议你可以读一读这本书，会有很大的帮助。

第二位偶像是 Jeffrey Richter：Jeffrey Richter 是 Windows System 程序设计的头头。我记得他好像年轻时在 Borland 待过，但是未获重用，后来到 Microsoft 之后，反而开始窜红。从 Windows 3.0 开始到现在，Jeffrey 写书也超过十年了，每一本都对 Windows 核心有很精彩的剖析，显示出 Jeffrey Richter 真才实学，绝非光是吃技术老本或靠塑造形象的许多其它作家能比。

Jeffrey Richter 的主要领域是 Windows System Programming，是该领域最重要的作家。Jeffrey 的书提供许多不凡的见解，深入的剖析，和第一手的数据，所以他的书一直都是我的最爱。我无法一一介绍他的每一本书，因为他的书相当多，而且每一本都很深入，带给我很大的收获。

在进入 .NET 时代之后，Jeffrey Richter 依然以一本《Applied Microsoft .NET Framework Programming》让大家更深入了解 .NET，我认为这是 .NET 语言和 CLR 最重要的一本书。目前 Jeffrey Richter 是 Wintellect 的当家支柱。他经常在 MSDN 上发表文章，每一篇都是经典。

第三位偶像是 Jeff Prosise，他从 DOS 时代就开始写书了，早期写了好几本 DOS 领域的书，在 MFC 正流行的时候，他写了一本 MFC 的书《Programming Windows 95 with MFC》（1996 年出版），现在则是写 .NET 的书《Programming Microsoft .NET》。我最喜欢的 MFC 的书正是 Jeff Prosise 写的这本，而不是 David J. Kruglinski 所著的《Inside Visual C++》，我觉得前者写得比后者更平顺、好读、清晰。

Jeff Prosise 曾经写了一本《How Computer Graphics Work》，这是当时 Ziff-Davis 出版社很畅销的「How ...Works」系列。该系列以精致的插画，简单易懂的叙述著称，主要的读者对象是社会大众，而非信息专业人士。我想，或许「简单易懂」就是 Jeff Prosise 惯有的风格吧！

进入 .NET 的时代，Jeff Prosise 的定位似乎比较偏向 ASP.NET。他写的那本《Programming Microsoft .NET》里面有大半的章节是和 ASP.NET 有关，应该改名为《Programming ASP.NET》。Jeff Prosise 现在已经不像 90 年代初期那样多产，最近的这本 .NET 书距离他的上一本书《Programming Windows 95 with MFC》居然有六年之久。但无论如何，我还是很高兴看到 Jeff Prosise 又重出江湖。

第四位偶像是 Ted Neward。我超喜欢 Ted Neward 的，觉得有他一种亲切感，因为他的学习历程和我很像：先是 C++，然后 Win32，然后 Borland OWL，然后 Java，然后 Enterprise Java，然后 .NET。我常逛他的网站 The Mountain of Worthless Information，从哪儿得到不小的收获。我建议你有空也去逛逛。

Ted Neward 是 Manning 出版社的元老级作者，Manning 最早出版的书正是 Ted Neward 的《Core OWL》与《Advanced OWL》（一本入门，一本进阶）。有趣的是，当 Ted Neward 的 OWL 这两本书快出版时，Borland 居然宣布停止开发 OWL。Ted Neward 花了这么多心血，居然换来这样的结果。OWL 本来市场就很小，又被 Borland 宣布死刑，Ted Neward 的这两本书卖得奇惨。

后来，Ted Neward 转向 Java，在 Manning 出版了一本很受好评的 Server-Side Java 书籍。接着，Ted Neward 开始和 O'Reilly 合作，出版了好几本与他人合着的 .NET 书，包括了《C# in a Nutshell》、《VB.NET Core Classes in a Nutshell》、《C# Language Packet Reference》、《Shared Source CLI Essentials》。其中，《Shared Source CLI Essentials》一书是剖析 Rotor 的第一本书，2003 年三月底出版，目前我手上有此书的数个章节，读起来很过瘾，对于我的 .NET 功力提升也有帮助。

这次介绍的四位技术作家，都是属于长青树，在软件技术圈子，这可是很不容易的。我常常觉得，等到哪天 Java 功成身退，被其它技术取代之后，我或许会变成一只玩不出新把戏的老狗，就这么会被淘汰了也说不定。

想成为技术上的长青树，必须在既有的技术上持续钻研，还得随时留意新技术，并适时抛弃一些技术上既有的意识型态。唉！还真是挺辛苦的。

本文作者：蔡学镛
文章出处：Sleepless 2.0
张贴日期：2003/3/24

·   规格书或软硬件手册虽然推出较早，且内容详细完备，极具参考价值。并非依照循序渐进的方式编排，所以不容易阅读。而计算机技术书籍有循序渐进的内容，可以按部就班地学习。

·   计算机技术书籍的内容相当务实，有许多范例和说明，适合自我学习。

·   自我摸索的学习方式固然扎实，但也相对耗时费力。透过计算机技术书籍作者的经验传承，你可以轻易地从书上学到许多宝贵的知识，大大地缩短学习曲线。

书籍不断地上架，在逛书局的时候，你会迅速地浏览一下你感兴趣的书，在这短短的几分钟之内，你希望能判断出你手上这本书值不值得买。你当然不会因为书的印刷精美、 价格不菲，就认定它是一本好书，毕竟这年头「金玉其外，败絮其中」的例子所在多有，轻忽不得。你用来据以判断购买书籍与否的因素可能有：

书籍内容 ：内容讲的是操作还是程序设计？是用 C++ 还是 Java ？偏向网络还是数据库……？我有一个朋友想学 SQL Server 的操作，却不小心买了「SQL 的奥秘」，这是 一本专讲 SQL 语法的书，和 SQL Server 八竿子打不着，显然他没有评估到「书籍内容」，这本书注定要压箱底了。

读者定位：读者需要有什么样的基础？这是一本入门书、进阶书、还是专家级的书？即使是再好的书，如果读者定位不适合你，太深或太浅，买了对你的帮助不大，只是瘦了荷包 罢了。一些经典且相当深入的书，在 Amazon.com 上面常常会有一些搞不清楚状况的读者给它极差的评价，因为他们程度还不到所以看不懂。而像 Deitel & Deitel 的 「Java: How To Program」也常惹来有经验的 Java 程序员给予「没程度」之讥，他们却没想到这样的书对初学者有相当大的帮助。他们都是犯了没认清「读者定位」的毛病。

作者背景 ：作者有哪些技术背景？过去著作的风评如何？有些作者相当爱惜羽毛，所写出来的书不但内容充实、文字洗炼，更要求出版社要印刷排版精美、校稿确实， 这种作者的名字比「CAS 优良肉品」的标记更让人放心，通常这种书我是不会错过的。但有的读者为了赶着让书「上市」（我觉得这里用「上市」一词比「问世」来得恰当）， 不惜瞎拼乱凑就送印了。如果我一时失察，误上贼船买了这种书，通常很快就扔进垃圾桶了。（送人？转卖？这不好吧！别让他继续危害人间。）

译者背景 ：如果这是中译本，又会有译者（除非是翻译软件翻出来的。我以前有个同学还真的用翻译软件来翻译书呢！不过封面倒是不敢注明「译者：译得妙 1.0 beta 版」）。 翻译计算机技术书籍可不是翻译文学作品，如果译者没有技术背景，翻译出来的句子就很可笑；只有在译者是个技术专业人员的情况之下，才「有可能」掌握内容的精髓。我说「有可能」， 因为即使译者本身程度不错，但因为时间仓促，或者因为译者本身敬业态度不佳，翻译品质也就无法提升。关于译者不佳所翻译出来的可笑句子，我们见多了，却仍然无法习以为常。 再好的书籍，被不好的译者经手，仍是不忍卒睹的烂书一本。

出版社 ：出版社是出版品的最后一道关卡。品质不好的稿件，出版社有责任退搞；排版有任何瑕疵，出版社有必要修正。差劲的出版社甚至会在作者或译者还没完全修正 稿件之前就「偷偷」送印，连作者或译者都被蒙在鼓里。可喜的是，国内的信息图书出版社似乎已经开始为品质把关。告诉你们一个实际的例子：欧莱礼的 Enterprise JavaBeans 和 Java 2D 的稿子在半年前就已经译妥，但在确定品质之前，他们宁可搁着不出版，直到最近我比较有空他们才请我当技术编辑，修饰这两本书的中文稿件。讲到这里，也请您参考一下 Elliotte Rusty Harold 所写的「我为什么喜欢由 O'Reilly 出版我的书」一文。

出版年份 ：从软件上市的日期和书出版的日期来判断书的内容是否够新，常常可以让你筛选书籍的速度加快。在我使用 Java 1.1 的时候，我买 Java 原文书的第一件事 是翻开出版年份，如果是 1996 年出版的书，我马上放回书架。因为 Java 1.1 是在 1997 年初推出的，所以 1996 年出版的书肯定只有涵盖 Java 1.0。和买葡萄酒不同的是， 计算机书籍不会越陈越香，尽可能买新出版的书才是上策。那些过期很久的原文书，一本特价卖 x99，还能卖得掉，这就真的让我百思不得其解了。

读书时间 ：如果你最近是个大忙人，有一堆事情要做，就先别急着买计算机书籍。计算机书籍更新的速度很快，可不比四书五经，可以祖传父、父传子， 代代受用不尽。以前我也常冲动之下买了好书回家，然后忙得没空读它，等到空闲下来时，新版本也已经出现了，懊悔不已！如果不急着用的书， 千万别急着买，不然可能还没来得及看这本书，新版本又出来了，信息界不流行考古的。

书评推荐 ：好书是不寂寞的。有些人一看到好书，就会基于「呷好倒相报」的心理，广为推荐。有些原文书的封底或第一页会有杂志或期刊的主编或名作家的推荐， 这也可以作为「参考」。Bruce Eckel 的「Thinking in Java」，一打开书就看到近十页的推荐，声势吓人。不过，书评倒也不见得要尽信，还是有少数烂书会搞出一些睁着眼睛 说瞎话的书评或推荐当作促销手段。

其它书籍 ：即使经过种种判断，你发现这是一本适合你的好书，「见猎心喜」是难免的，但是先别急着兴冲冲地去付钱，你应该再花一些时间看看是不 是有其它更好的书值得让你舍弃手上的这本。俗话说：「天外有天，人外有人」，我说：「书外有书」。

我已经分析过买书时的判断方法，希望能减少你买书时的「天人交战」。下次买书时，你不妨试试看这些方法。

第一：英文能力

第二：中文能力

第三：专业能力

专业能力会影响对于文章的理解，所以专业能力不足的人，即使英文能力很好，可能无法很好地理解原文。中文写作能力不好的人，即使英文能力和专业能力都很好，也无法很流畅地用中文表达出来。英文能力不好的人，即使中文能力和专业能力都很好，可能一开始就无法很好地理解原文。

如果你问起这三者何者较重要，我认为依序是：专业能力大于中文能力大于英文能力。英文的听说读写不用样样精通，只要看得懂基本的英文句子就可以，反正随时可以查字典。中文能力就比英文能力重要了，表达成中文句子时，需要信、雅、达。而专业能力又比中文能力重要一些，特别是在文章的技术门坎很高时。

而软件的迁徙（ migration ）也和翻译文章相彷佛。由于信息产业变动很快，技术改朝换代是常有的事。有时候我们想把旧技术换到新一代的技术（例如 Visual Basic 到 Visual Basic .NET ），有时候我们想把甲公司的技术换到乙公司的技术（例如 Java 到 C# ，或 Visual Basic 到 Java ），这些都算是软件的迁徙。不管你是从 Visual Basic 迁徙到 Java 或 Visual Basic .NET 或 C# 、或者从 Java 迁徙到 C# ，都必须具备三种能力：

第一：原始语言能力

第二：目标语言能力

第三：专业领域能力

我认为这三者的重要性也是：专业领域能力大于目标语言能力大于原始语言能力。原始语言不需要太精通，只要能看得懂原始语言的程序逻辑就可以，反正随时可以查原始语言的 API 文件。目标语言能力就比原始语言能力重要了，而且还必须很熟悉目标语言的 API ，这一点非常麻烦，要花很多力气和时间。专业领域的能力是最重要的，该程序到底是涉及数据库、图学、 Web Services… 等，技术人员必须先具备该领域的知识。所以，对于负责进行软件迁徙的技术人原来说，首重目标语言能力和专业领域能力。

软件迁徙的工作，如果需要技术人员一行一行地转换，就太辛苦了。所幸，市场上有许多工具可以帮忙转换，但是这样的转换工具并不能让我们高枕无忧，他们通常具有下面的特色：

? 通常能很完整的转换程序语言的逻辑

? 通常者能转换一部份的 API

? 通常不能转换编程模型，与系统架构

也因此，软件迁徙的难度颇高，必须审慎评估。甚至许多人为，重写一套会更简单。评估软件迁徙若有确切的必要性之后，除了择定工具之外，也可以寻求技术顾问公司的服务。例如 ArtinSoft 就有提供 Java 转 .NET 的技术服务。

软件的迁徙绝对不是一件简单的事。我最近动手进行了一些例子，发现这需要高度的能力，也需要许多人投入。绝对是一件苦差事！

• 不重视研发
• 不重视专利
• 不重视软件工程

不重视研发

研发是一种长期的投资，因研发而来的收益往往要数年后才「有可能」逐渐看到成果，研发在短期内一定没有太多收益，长期也不一定会有收益（可能会研发失败，也有可能市场变迁）。「聪明的」台湾软件公司是不做赔本生意的，所以不会进行对他们来说犹如钱坑的研发。

你可能对我的说法不以为然，因为许多公司都有研发部。是呀！我不否认有些公司的研发部的确是在做研发，但是大多数公司的研发部都只是一个自我陶醉（抑或自我安慰）的名称罢了，他们做的事情和研发沾不上边。

不重视专利

手中握有许多实用的专利，会带来许多好处：

1. 部署专利地雷，避免其它公司的竞争
2. 别人要采用此专利，就必须付费给你
3. 踩到别的公司的专利地雷时，或和其它公司竞争时，手上的专利可以作为谈判交换的筹码，而对方如果也踩到己方的专利地雷，更可以在法律上反控对方，以战逼和。

专利不难申请，但也不是每个申请到的专利都有价值。如果不仔细评估专利的价值，就胡乱申请专利，一点意义都没有。台湾的软件公司掌控多少有价值的专利？我不知道，我也鸵鸟心态地不愿意去查。

不重视软件工程

台湾根本没几家软件公司把软件工程当一回事。不采行一套适当的软件工程程序（process），就不可能做出稳定的中大型软件系统。我知道的许多公司，软件工程几乎都只是拿来当做幌子，写在计画书里做做样子，实际上整个软件还是胡乱拼凑出来的。中国大陆的软件产业开始相当重视 CMM 的软件工程，反观我们呢？

不采行软件工程、懒得学 design pattern、不肯「浪费时间」refactor 软件、有一搭没一搭的 test...，这样子开发出来的软件，不会是「Write Once, Run Anywhere」(tm)，恐怕是「Write Everywhere, Run Nowhere」。

在信息产业的硬件方面，我们就算没有研发能力，至少还能帮人代工，并透过代工来累积能力逐渐茁壮。软件产业方面，我们没有研发能力也就算了，连帮人代工的能力都没有，因为我们没有采行软件工程。专门帮欧美软件大厂代工的印度最大软件公司 Wipro 已经登陆台湾了，而 Wipro 已经是 CMM5（最高）的软件公司了，我们台湾的软件公司都还在睡觉，没一点自觉呢！

当洪水来袭

不重视研发、不重视专利、不重视软件工程，想一想，我们的软件产业还真是悲情，这正预言着我们的软件产业未来很可能会遭到洪水吞噬 ...... 如同台湾遭到此次纳莉（以及往后无数个纳莉）的豪雨吞噬一样。

看多了洪水等灾难，我打算去买大楼逃生索以便发生大火时逃生（如果以后住的楼高十层以上，我还会考虑买降落伞）、买一个充气泳池以便被水围困时充当橡皮艇逃生，我还要在屋内囤积一周的粮食与水、备妥灭火器、电池、手电筒、雨衣、雨鞋、大型塑料袋（大火逃生时避免被浓烟呛倒）、打火机、蜡烛、皮鞭（别想歪了！皮鞭可是用来击退趁火打劫的人渣）。Hay! 不要笑我杞人忧天，毕竟这几年住在台湾，谁不是水里来火里去的，灾难发生在身边是迟早的事，别说我没警告过你。

什么是 Pattern

Pattern 最简单的定义是：只要是一再重复出现的事物，就是 Pattern。依照此定义，生活中就可以找到一堆 Pattern 的例子：

第四台广告中的 Pattern：

1. 原价 ... ，现在购买只要 ... ，还送你一组 ... ，请马上来电 ... ，如忙线中请稍后再拨。
2. 利用分割画面显示出使用前使用后的差别，来加强说服力。例如：由 C 升级到 E （注： C 和 E 不是指程序语言）。
3. 找人现身说法：「杰瑞！感谢你介绍这套欧莱礼 Java 系列，让我在短短的三个月内成为公司内首屈一指的 Java 专家，这实在是太神奇了！」

选举时的 Pattern：

1. 质疑对手 A 钱或搞婚外情
2. 把家人通通拉上台痛哭一场以示选情告急
3. 开口唱「爱拼才会赢」

其它像是金光党的手法，刮刮乐诈财的技俩 ... 等，也都具有一再重复出现的特性，所以都可算是 Pattern。

电影中的 Pattern

电影中也有大量的 Pattern，请看下面的例子。

提高追杀时紧张程度的 Pattern

1. 坏人追杀好人时，好人躲进车子，却发现车子发不动，引擎嘎嘎作响，一面努力地继续发动，一面念念有词「 Come on, Come one 」。
2. 坏人追杀好人时，好人冲进电梯，死命地押着 close 按钮，脱口而出「 Come on, Come one 」。

许多电影都会使用上述两个 Pattern ，虽然是老掉牙的 Pattern ，但每次看到这里，总是让我紧张得心脏病差点发作，我不得不承认这两个 Pattern 实在是挺有效的。

增加主角杀死坏人合理性的 Pattern

电影最后，坏人和好人大对决，最后好人胜利，但是好人如果直接把坏人宰了，那好人在观众心中的形象就会受损，所以好人先饶坏人一条生路，但是坏人却坏到骨子里了， 偷偷拿出一把枪瞄准好人，说时迟那时快，好人机警地察觉，为了自保于是将坏人一枪毙命。这个 Pattern 可以让好人有人性，又让坏人死有余辜。

床戏的 Pattern

不管和剧情有没有关系，编剧和导演总爱加上一段激情的床戏。这个 Pattern 相当困扰我和我的家人，因为每次看到这里，我们保守的一家人往往觉得很尴尬，我们所反应出来的 Pattern 是：借口倒茶水，上厕所，打电话 ... 而离座避风头 ... 但眼睛仍不时偷瞄。

恐怖片的 Pattern

无须我举例，电影惊声尖叫（ Scream ）第一集就为我们剖析出恐怖片的一大堆 Pattern 。

公式化

好莱坞的电影比较多 Pattern，而欧洲的电影比较少 Pattern。至于昆丁塔伦提诺（Quentin Tarantino）编导的电影，完全是不按排理出牌，很难找到 Pattern。正因为好莱坞的电影很容易就可以找出 Pattern，所以常常会有似曾相似的感觉。许多人批评好莱坞的电影很「公式化」。

基本上，Pattern 就是一种公式化的表现。那么，究竟公式化是不是好事？

以艺术来说，公式化的结果会造成僵化，所以负面效果居多。电影号称是「第八艺术」，也是一种艺术创作，所以最好不要出现太多 Pattern，否则肯定被影评人痛批「了无新意」。

以工程来说，公式化是好事。这些公式都是「千锤百炼」的结果，运用这些公式可以确保工程具备一定的品质，并加快工程的进行。而软件开发也是一项工程，也需要尽量运用公式。 （软件另有需要艺术的一面，这不在本文的讨论范围）。

什么是 Design Pattern

所以，Pattern 就是一种「千锤百炼」的智能结晶。有经验的专家和没经验的新手，差别就在于：有经验的专家知道如何在适当的时机，套用某些公式（Pattern）以解决特定 的问题，这是专家经年累月所培养出来的 Know-How（请参见「软件产业的知识经济」一文）。

一般来说，对象导向软件开发的程序可以粗略分成 OOA（对象导向分析）、OOD（对象导向设计）、OOP（对象导向实作）。在 OOD（Object-Oriented Design）阶段所采用的 Pattern 就称为 Design Pattern。运用良好的 Design Pattern，可以使得系统架构更优良（也更快完成），对于后续的 OOP、测试、维护，都会有很大的 帮助。Design Pattern 会告诉你，什么情况下用 Delegation 而不要用继承、什么情况下用 Interface 而不要用 Class... 诸如此类的知识。这些都是软件界前辈的智能结晶。

我要强调 Design Pattern 专指 Design 时期的 Pattern。但是 Coding 时的 Pattern（例如程序代码内缩）最好不要称为 Pattern，以免混淆。Coding 时期的 Pattern 最好称为 Coding Style（或 Code Style）。

Design Pattern 这个名词也可沿用到许多地方。我认为孙子兵法就是一本军事领域 Design Pattern 的书，它告诉你什么时候该采什么样的军事动作。至于怎么去砍人，则是属于 implementation 的部分，不属于孙子兵法的范围。

什么是 Anti-Pattern

并非所有的 Pattern 都是好的，不好的 Pattern 称为 Anti-Pattern。如果你的系统中出现了 Anti-Pattern，就表示你犯了别人「常犯的典型错误」。简言之，Anti-Pattern 就是错误的示范，要尽量避免。

让 Design Pattern 成为你的不时之需

许多人在设计阶段才来喟叹：「 Pattern 到用时方恨少。」其实你可以避免这样的情况。现在市面上有许多本 Design Pattern 和 Anti-Pattern 的书。只要好好把这些书读过，体会每个 Pattern 的真正涵义，你可以在短短的时间内，功力激增一甲子。即使读过的 Design Pattern，如果比较少用，一阵子之后也可能会忘记。 所以最好能隔一阵子就把 Design Pattern 的书拿出来复习。

1. 程序员要自行产生并丢出一个 Shit™ 对象。  
2. 发生这种问题时，通常是很严重的状况，不应该是 Runtime Exception ，应该是 Error 比较恰当。
3.   产品交付给客户之前，程序员必须手动将程序代码中所有的这些检查都删除，否则对于执行效率会有不好的影响。

Java™ 2 SDK 1.4 新增的 assertion 功能，和 Shit™ Exception 的目的一样，但可以免去 Shit™ Exception 的这些缺点。所以我已经开始改用 assertion，而不再使用 Shit™ Exception 了。

你可以在 Java™ 程序 method 内的任何地方插入 assertion 叙述来做检查。Assertion 叙述（statement）的方法是在 assert 这个关键词（keyword）之后加上一个布尔（boolean）判断式，然后以分号结束此叙述。如下例所示：

assert size() == 0;

程序中如果使用到 assertion，编译时必须加上「-source 1.4」的选项来告诉 javac 编译器，否则 javac 预设的状况是不支持 assertion 语法的。执行的时候必须以「-ea」的选项设定来告诉 JRE 必须执行 assertion，当程序执行到 assertion 叙述时，如果布尔判断式不成立，系统会丢出 AssertionError 的错误对象。如果不用「-ea」选项，执行时会忽略 assertion 叙述不予执行。

Assertion 看起来很神奇，其实骨子里很平庸。透过编译器和 class loader 的合作就可以达到 assertion 的支持，根本不需要 JVM 在指令集（instruction set）中新增 opcode。举例来说，「assert size() == 0;」这道叙述会被编译器当成下面的程序代码来编译：

if (ea) {
   if( size() != 0 ) {
     throw new AssertionError();
   }
}

编译器并会在此 class 的 bytecode 中插入一个类似下面的私用静态合成字段（private static synthetic field）： 

private static boolean ea = false;

因为 ea（意思是 enable assertion）的默认值是 false，所以预设情况下是不会执行 assertion 的。如果你透过「-ea」选项来执行，那么 class loader 会在加载此 class 的时候，将 ea 设为 true，所以就能执行 assertion。

执行程序时，如果把 assertion 功能打开，会造成执行时效率稍微变差，而且不管有没有透过「-ea」来把 assertion 功能打开，assertion 的程序代码都会一直存在 bytecode 中，会造成体积的增大，这两点是使用 assertion 要付出的代价，所以在程序中使用 assertion 的时机，仍须仔细斟酌。只要使用得宜，assertion 可以是程序员很好的除错帮手。

商标声名：
Java™ is a trademark of Sun Microsystems.
Shit™ is a trademark of Jerry Tsai.

不要用鄙夷的眼光看待这个标题。其实「Shit Happens」是个名言，而且还是个具有禅意的名言。 电影阿甘正传（Forrest Gump）中，阿甘在跑步时踩到 shit，旁边一位失意的商人问他对此事的看法，阿甘表情轻松地说：「Shit Happens.」 ，这句话的意思是「人生偶而会有不顺遂的事发生，没什么值得大惊小怪的」。这个商人于是将「SHIT HAPPENS」做成标语，结果大卖。 电影下一幕镜头出现一台后面贴有「SHIT HAPPENS」标语的汽车，飞来横祸地被后面的另一台车子撞了……果真是「Shit Happens」。

「…… 这和本文章有什么关系？？？」别急，继续看下去吧！

Java 程序员对于例外处理机制（exception handling mechanism）应该都不陌生，因为 Java 语言强制程序员必须使用例外处理来捕捉（catch）非执行时期（non-runtime）的例外。所以你一定用过 try，catch，finally 这三个 Java 语言的关键词，而且你也很有可能用过 throw 这个关键词来将未处理的例外再转出去给 call stack 的下一层 method。但是，你很有可能未曾主动 new 一个例外对象，然后将其丢出。你更有可能未曾定义过自己的例外类别。

在用 Java 设计中大型系统的时候，常常有必要定义自己的例外类别，并在适当时机主动地丢出例外。如此一来可以使得程序更稳固。

对于定义自己的例外类别，我的习惯是：

1. 如果此例外属于 runtime 性质，且可以补救，则此例外继承自 java.lang.RuntimeException 。
2. 如果此例外不属于 runtime 性质，且可以补救，则此例外继承自 java.lang.Exception 。
3. 如果此例外不可以补救，则此例外继承自 java.lang.Error 。

上述这三点完全是依照 Java 语言对于例外处理的建议，相当直觉，我也就不多解释了。除此之外，我还定义了一个我常用的例外类别，叫做 Shit，其定义如下：

package com.skittles;

public class Shit extends RuntimeException {

    private String whatHappened;

    private Shit() {}

    public Shit(String whatHappened) {

        this.whatHappened = whatHappened;

   }

   public String toString() {   

       return whatHappened;

   }

}

在程序中，对于一些我认为绝对不可能会发生的情况，我会丢出 Shit，代表程序出现了绝对不应该发生的状况。如果出现这个例外，表示程序内部有奇怪的错误。在测试程序时，如果 Shit Happens，我会去追查其源头，将错误找出来订正。

之所以让 Shit 继承自 RuntimeException，就是因为它应该不可能发生，将它定成 RuntimeException 可以使得程序不用去 catch 它。

在程序的撰写与测试阶段，Shit Happens 是免不了的。但是，在程序交给客户或上线之后，就得确定程序正确无误。No more shit happens.

• Java 虚拟机器（ Java Virtual Machine ， JVM ）
• Java 操作系统（ Java Operating System ）
• Java 芯片（ Java Chip ）

以下就此三种 Java 平台提出解说，并比较之。

Java 虚拟机器

所谓的 Java 虚拟机器，指的是在操作系统上执行的一种程序，此程序可以解读 Java bytecode，并在操作系统的帮助下执行 Java bytecode。这样的执行架构，大致上可以分成四层，分别是：

• 第一层（最上层）的 Java bytecode
• 第二层的 Java 虚拟机器
• 第三层的操作系统
• 第四层（最底层）的芯片

芯片执行上面的操作系统，操作系统执行上面的 Java 虚拟机器，Java 虚拟机器执行上面的 Java bytecode。对于 Java bytecode 来说，它只接触到 Java 虚拟机器，所以当然「误以为」Java 虚拟机器就是它的平台。

实例：Pentium III Chip + Windows 2000 OS + Sun HotSpot Client VM + Together/ Java Application。

Java 操作系统

如果把 Java 虚拟机器整合进既有的操作系统中（例如：Mac OS X），或是打造一个全新的操作系统专门执行 Java bytecode（例如：JOS），这类能直接执行 Java bytecode 的操作系统也可视为 Java 平台。这样的执行架构，大致上可以分成三层，分别是：

• 第一层（最上层）的 Java bytecode
• 第二层的 Java 操作系统
• 第三层（最底层）的芯片

Java 芯片

如果把 Java 操作系统和既有的芯片整合起来成为一组新的芯片（例如：ARM 7、ARM 9），或者打造一个全新的 Java 专用芯片（例如：aJile aJ-100）那么此一种类的芯片也是 Java 平台。这样的执行架构，大致上可以分成两层，分别是：

• 第一层（最上层）的 Java bytecode
• 第二层（最底层）的 Java 芯片

三种方式的比较

这三种都是 Java 平台，各有优缺点，很难说那一种方式比较好，必须看你的需求而定。

透过虚拟机器来执行 Java 是最常见的架构方式，一方面是因为虚拟机器的 Java 平台最容易被实作出来（相较于 Java 操作系统和 Java 芯片而言），二方面是因为只要有虚拟机器就可以让在不更动实体平台（操作系统和 CPU）的情况下多了执行 Java 程序的功能。目前，多数主流的实体平台（包括 Windows、Linux、Mac、Solaris、PalmOS、EPOC...）都已经有 Java 虚拟机器了。

虚拟机器的架构因为分了太多层级，所以效率上当然会比较差，这是虚拟机器架构最为人所抨击的地方。但是由于虚拟机器的技术一直在进步，所以执行效率一直都有持续的提升。目前已经相当逼近 Java 操作系统的架构方式，所以虚拟机器的方式应该会继续成为 PC 上的 Java 平台主流。

一般来说，透过 Java 操作系统来执行 Java bytecode，效率会比虚拟机器的方式好。所以 Java 虚拟机器被整合进操作系统中，来提升该操作系统的附加价值，这种作法有可能会成为一种趋势（例如 MacOS X 就把 Java 和操作系统作了很好的整合）。但如果设计一套只能执行 Java 的全新操作系统，可能不容易成功，因为全新的操作系统势必面临驱动程序（device driver）不足的严重困扰。因为此原因，加上事实证明操作系统的 Java 平台，比虚拟机器的 Java 平台效率提升不如预期多，所以 IBM 和 Sun 合作的纯 Java 操作系统「JavaOS」计画已经停摆。

利用芯片的方式来实作 Java 平台，对于 Java 程序的执行速度会有很大的提升，毕竟硬件的速度比软件快许多。这种方式以后会成为嵌入式系统的主流，许多 Java 的 IA 产品（例如：Set-Top Box）都会开始使用 Java 芯片。但是这种方式已经把 Java 整个变成硬件平台，不适合再称为跨平台了。

MyBigObject obj = new MyBigObject();
// do something here...
delete obj;

如果你也这么希望的话，我劝你早点死了这条心吧！Java 语言的主要精神之一是 robust，如果 Java 同时支持这两种内存管理的话，可能会造成程序中有许多潜在的 Bug，内存不当存取的问题会比 C/C++ 更严重，所以是不可能这么做的。

java.lang.System.gc() 或 java.lang.Runtime.gc() 的 gc 指的就是 garbage-collection，不过根据文件的说明，它的作用只是「建议」Java 虚拟机器快去收垃圾，而不「保证」会去收垃圾。文件都写得如此谦虚了，你也不应该对它寄予太多厚望。对于内存资源消耗太多的缺失，目前你能做的是：

1. 改用一个内存管理方式好一点的虚拟机器：垃圾收集是一个丰富又庞大的主题。垃圾收集的算法有数百种可能，而且各有专长。许多虚拟机器采用的算法都不太一样，建议各位多去比较几家。
2. 少制造垃圾：许多时候你制造了一堆不该制造的垃圾，比方说：该用固定式数组的时候却用 Vector ，该用 StringBuffer 的时候却用 String...... 等等。这么会制造垃圾，再多内存也不够用。
3. 不再使用的对象要尽早设定为 null ，以便早点被当成垃圾清掉。
4. 花钱多买一些 RAM （砸钱解决问题，这是我最爱用的方式）。

垃圾，真的这么让人讨厌吗？那倒不尽然，我最喜欢的乐团之一就叫做垃圾（Garbage），主唱雪莉曼森（Shirley Manson）的声音真是迷死人了。比起名字很嚣张，但歌声是垃圾的那些偶像，这时候雪莉曼森的垃圾俨然成了一种讽刺。

JIT 编译器

传统的 Java 虚拟机器很愚蠢，将一道 bytecode 的指令翻译成机器码之后，马上执行这些机器码，执行完这批机器码之后，就把这些机器码丢了，接着再翻译下一道 bytecode 的指令，继续下去 ...。即使下次执行到以前执行过的 bytecode 指令，依然要重新翻译成机器码才能执行，如此一来，效率当然不好。

使用 JIT 编译器（Just-In-Time compiler）技术的虚拟机器比较聪明，会把常常执行的部分在第一次先翻译好放在内存，以后再次执行到这里时，就不用再翻译，直接从内存取出机器码即可执行。这么一来，只要你的内存够大，JIT 编译器的技术够好，你的 Java bytecode 执行速度也可以逼近纯编译式的程序。

其它程序语言的编译器

任何档案只要符合 Java bytecode 的格式，就可以被 Java 虚拟机器执行。制造出 Java bytecode 的方式有许多种，不一定要使用 Java 语言来写程序，才能编译成 Java bytecode。Java 是语言也是平台，你可以不使用 Java 语言（也就是 Java 编译器），只使用 Java 平台（也就是 Java 虚拟机器）。只要某语言有提供编译器，能将该语言的原始码编译成 Java bytecode 格式，就可以在 Java 平台上执行。

据我所知，目前已经有下列语言提供兼容于 Java 平台的编译器（以英文字母顺序排列）：Aardappel，Ada，Agora 98，BAMBOO，Basic，Bistro，Bolero，C，C++，CLIPS，COBOL，Correlate，Dawn，E，EcmaScript，Eiffel，Foo，Forth，Fortran，Funnel，Haskel，Hojo，JavaScript，Jickle，JIF，Jinni，Lisp，LL，LLP，Logo，Luck，MINERVA，Mini，ML，Modula-2，NetRexx，Nice，Oberon-2，Pascal，PLAN，Pnuts，Prolog，PS3I，Python，Sather，Scheme，SELF，Simkin，Small Talk，Tcl，WebL，Yassl，Yoix，Yoyo。

原生编译器

如果你不在乎 Java 程序能否跨平台，你希望 Java 程序能如同 C/C++ 一般被编译成机器码而非 Java bytecode，那么你可以使用 Java 原生编译器（native compiler）。目前已经有不少这样的产品可以使用。

Java 原生编译器有两大类，一类可以把 Java 的原始码编译成机器码，另一类则可以把 Java bytecode 编译成机器码。

反编译与混淆器

Java bytecode 因为档案格式简单，信息保留完整，且指令是最简单的堆栈式（stack-based）架构等因素，所以很容易被反编译（de-compilation）。反编译指的是和编译相反的过程，对 Java 来说，反编译就是把 Java bytecode 转换成 Java 原始码的过程。

为了防止你辛苦地开发出来的 Java bytecode 被他人反编译成原始码，你可以透过混淆器（obfuscator）将你的 Java bytecode 转换成更混乱的 Java bytecode，执行起来效果一样，但是被混淆过的 Java bytecode 比较不容易被反编译。你通常要为此付出一点代价，因为混淆过的程序执行速度通常会变慢。且混淆器只能增加反编译的难度，不能保证你的程序一定无法被反编译成功。毕竟道高一尺，魔高一丈，如果有人愿意花许多时间和精力反编译你的 Java bytecode，你根本就无法拦阻。

组译与反组译

汇编语言（assembly）是一种非常接近机器码的语言。将汇编语言转成机器码的工具称为组译器（assembler），反过来将机器码转成汇编语言的工具称为反组译器（dissembler）

对于 Java 虚拟机器来说，Java bytecode 就如同它的机器码，有没有一种语言是很接近 Java bytecode 的呢？也就是说，Java 有没有的汇编语言呢？基本上，Sun 并未定义 Java 的标准汇编语言，但是有一些人定义了自己的 Java 汇编语言，并提供 Java 的组译器（甚至反组译器）。例如 Jasmin 以及 javaa 都是 Java 组译器。

前处理器

前处理器（pre-processor）也称为前编译器（pre-compiler）或前翻译器（pre-translator），其目的在将源码中不符合语言规范的部分转换成符合语言规范的形式。比方说：我们可能在 Java 源码中除了使用 Java 语言之外，还穿插使用自订的语法。这些自订的语法无法被 Java 编译器处理，所以我们必须先透过一个前处理器来将自订语法的部分转换成 Java 语言，然后就可以交由 Java 编译器处理。

目前有不少 Java 的前处理器，例如 iContract、SQLJ，都是用来扩充 Java 语言之用的。

最佳化工具软件

一般来说，最佳化有两种：
1. 让档案体积变小，可以节省储存空间并加快网络传送速度。
2. 让执行速度变快。
对于 Java 来说，还有第三种最佳化：
3. 让程序结构变乱，不容易被反编译。也就是前面提到过的混淆（obfuscation）。

这三个目的之间常常互相排挤：结构变乱，通常会使得程序变慢，且体积变大；体积变小，通常会使得速度变慢，且结构变整齐；速度变快，通常会使得体积变大，且结构变整齐。

这次来台参加 WCIT（世界信息科技大会）的众多贵宾中，大家目光的焦点都集中在 HP 女总裁菲奥莉娜的身上。菲奥莉娜以女性的身份，领导着这样大型的公司，在男性为主的商场上实属不易。在看过菲奥莉娜的谈吐之后，更觉得她迷人，她还帮咱们台湾的信息产品拍摄形象广告呢！真是个好人。我觉得她可以说是集美丽、智能、优雅、亲切、还有大权于一身的女总裁。菲奥莉娜的现身台湾，一定可以让大家体会到：女性领导人不见得要集不美丽、不智能、不优雅、不亲切、还有黑脸于一身（嘿！我可没在影射谁）。

商场上的女性虽然少，但工程界的女性就更少了。以我比较熟的信息圈子来说，软件公司内部从事 coding 的女性比例很低，这到底是为什么呢？我认为原因可能有二：

1.       传统的观念认为女生不适合读自然组，所以信息系的女生很少，一班通常只有 0~5 个。

2.       偏偏这 0~5 个女生又常常被班上当成宝，所以不太需要写程序，男生常常都会主动捉刀帮忙。

这两个原因结合在一起就严重了。

况且，许多女生一直都有错误的观念，认为自己「逻辑观念又没男生强」，所以「程序作业当然是找男生帮忙」，也因此信息系的男学生都很抢手。大一时女生多的科系喜欢找男生当学伴（或称学友），因为他们认为男生可以帮他们写计算器概论的程序作业。没有学伴，或者学伴自己也写不出来，女生只好上网求救。这些求救的 post 分为几种风格：

·         比较古典的标题「小女子有难，请程序高手拔刀相助」

·         比较新潮的标题「美眉需要各位葛格帮忙写一个程序」

·         比较淑女的标题「请各位大哥帮小妹解决程序问题好吗」

·         比较情色的标题「需要有人帮忙写程序，我愿意以身相许」

·         比较怨天的标题「我是女生，所以不会写程序，请帮帮忙」

·         比较尤人的标题「老师出的程序好难，害人家都不会写」

不管标题风格为何，这些女生无非是来要作业的，绝对不是自动自发练习时遇到问题为求甚解而主动发问。

女生真的比较不会写程序吗？我可不这么认为。女生学习外国语言的能力比较强，学习程序语言应当如是。而且女生的心思比较细腻，不若男生的粗心，所以写出来的程序可能比男生的程序 bug 更少。

诸位女性们，你们应该从今天起，卯起来写程序，好改变大家对你们既定的印象。让大家知道，女生也会写程序，甚至写得比男生更好。套句南方四贱客（South Park）电影的歌词：「You can do it, it's all up to you, Mmmkay!」。你们应该拿菲奥莉娜当榜样。

又提到了菲奥莉娜，她已经离台了，徒增我无限的思念 ......。忽然想起，我上个月刚买的激光打印机是 Epson EPL-5700L 而不是 HP 的，真是懊悔。Oh！菲，Forgive me，虽然 HP 的打印机比较贵，但是下一次，再贵我还是一定要买 HP 的，I promise。

本文摘自Access中国网站版主李啸林的转帖与补充：

这一阵子，软件、网络大红，许多人对程序设计开始感兴趣，我收到好一些 Sleepless in Java专栏读者的来信，不少读者共同的问题是：如何进入程序设计的领域？所以我选这 个主题当作 Sleepless in Java 专栏「复刊」的第一篇文章。

写程序是很有趣的事，可以把自己的想法付诸实行。写程序的工具很简单，只要有一部PC，适当的开发环境，就可以上工了。这样有限的工具却可以创造无限的可能，这也正是程序设计迷人的地方。只要你能力够，你可以将你脑海中的创意写成程序，变成一套软件。

培养程序能力，不是一蹴可及的，下面提供我的一些建议，希望对有志进入程序设计领域的你有所帮助。

培养兴趣

把程序设计当成兴趣可以让你学得更快乐，学习效果自然会更好。在我到一个单位面试时，主管看了我的履历之后问我：「你怎么有这么多时间学会这么多东西、做这么多事？」我的回答是：「把工作、学习、和娱乐结合在一起，时间就会是别人的三倍。」

我承认我很幸运，可以把程序设计当作赚钱的工作，学习的题材，以及茶余饭后的休闲活动。不是每个人都像我这般幸运，但是我相信至少大家都可以把它当成兴趣。相信我，调整你的心境，把它当成是兴趣，而非苦差事，你非发现你的「程序功力」与日俱增。

慎选程序语言

慎选程序语言很重要，一开始就学太难的程序语言很容易让你遭遇到挫折而放弃。你可以挑比较容易且有趣的语言下手，建议您可以从下面的语言中择一：

VB：简单，好用，书籍多。
REBOL：使用上非常简单自然，各个平台都支持，然后尚未流行，可以到www.rebol.com 上下载，也可以在此处找一些学习资料。
Java：比VB稍难，比C/C++简单，书籍多，用途非常广，相当有前途。可以当作学习C++的跳板。
Python：简单，好用，各个平台都支持（包括Windows，Linux，MacOS，BeOS，...）。国外很红，国内较少人用。原文书不少，但中文书目前只有一本（欧莱礼出版）。我预期 Python 会是下一个热门的程序语言。 www.python.org

这三个语言只是我给各位的建议，你也可以多听听别人的意见。在选定一个程序语言之后，就要执着，不可以很快放弃，又改学另一个程序语言，否则永远都只懂皮毛。有句谚语是这么说的：「A jack of all trades is master of none」。如果你号称会C++、Java、…等十种程序语言，只不过每种程序语言都停留在Say Hello的阶段，相信面谈主管很快就会 对你 Say Goodbye。

当你学精某程序语言，然后想再学另一个程序语言，你会发现有了前一个程序语言札实的根基，学任何新的程序语言都很快。

使用适当的开发工具

现在RAD工具软件盛行，Visual Basic、Delphi、JBuilder、VisualAge、VisualCafe都是。有了RAD工具，只要「拉一拉，选一选」程序就完成一半了。许多硬底子的程序员颇不以为然，认为初学者使用RAD工具不是好习惯，不过我倒不这么认为。我认为RAD工具可以降低初学者学习的门槛，提高兴趣。只是，在你学会「拉一拉，选一选」的简单步骤之后，应该要找机会精进自己，弄懂内部的机制，不然不仅会有一种不踏实的感觉，甚至有许多程序会写不出来。我再强调一次：RAD可以当初学者入门的工具，但小心不要使它变成让你停滞不前的借口。

另外也要学会使用开发工具所附的诸多功能（特别是除错功能）。许多人买了昂贵的 Enterprise 版开发工具，却只用到copy-paste功能，那么这套开发工具和 Windows 所附的 记事本就没有两样了。建议您开始使用一套新的开发工具前先花些时间把 User Guide 翻一翻。

现在许多开发工具都有免费版本可以下载，初学者不妨多多利用。

多读好书，少上课

大量阅读好书，是精进自己的不二法门。在这种快餐时代，许多人没耐心读书，反而喜欢到处上课，所以现在到处都是计算机班。如果遇到厉害的好老师，当然上过他（或她）的课会收获很大，只是目前好老师的比例实在不高（虽然我自己也在开 Java/Enterprise Java/Java Swing 的课，但我还是得这么说）。我曾在网络上看到有人说：「没听过补习班教出什么程序高手」，这倒也有几分真实性。不过一方面要归咎老师之外，一方面也要归咎学生，因为我发现通常上课的学生会在家里读书和写程序练习的比例不高。

相较于上课动辄花费上万元的高代价，买书只需要区区几百上千，划算多了，更何况书上的内容又比上课来得多且详细。不过「买书容易，看书难」。怕自己偷懒的话，找志同道合的朋友组织「读书会」，彼此加油打气，还可以互相切磋。最好是像我前面提到的：把它变成兴趣。

加强英文阅读能力

加强英文和崇洋无关，而是有它实际的价值。许多信息都是要直接看英文的资料，因为没有中文版可看。

「可是我的英文很烂！」

这不是理由。没人生下来就能阅读英文，都是一点一点累积起阅读能力的。给自己一个机会，找一本单字文法都比较简单、且页数又少的书籍下手，很快地，你会发现技术书籍的单字就是哪几个在重复出现，阅读这样的书一点都不难。

请注意：原文书的写作风格也有相当大的差异，有的书的确是不好读。所以，如果你刚开始要尝试阅读原文书，不要挑到像 Bjarne Stroustrup 所写的 The C++ Programming Language 这类难懂的书……尽管它是经典。

问人之前，先问自己

遇到问题，可以到国内外的程序设计相关讨论区去请教别人，如果态度谦逊，且问题叙述清楚，相信许多有经验的前辈会很乐于参与讨论。不过，凡是遇到问题就发问，这不是好事，因为你会因此越来越依赖别人，而失去了自我解决问题的能力。自己应该尝试着查书、写程序测试、甚至阅读原始码，来找出答案。如此一来，真的没办法而请教别人时，也才能 比较深入地讨论。

多写程序

学程序设计不可以只看书，将随书光盘的程序执行一次，就认为自己已经学会了。应该开始写一些程序，且由小到大，由简单到复杂。找一些有趣的题目（比方说：计算器，踩地雷，小画家，俄罗斯方块），可以提升写程序的动力。

我看到许多学生大一的程序作业都是copy同学的，失去了练习的机会。等到二年级之后，想开始写程序，却写不出来了。初学程序设计的阶段，应该给自己多一些机会写程序。

向上延伸，向下延伸，向旁延伸

当你发现你已经可以掌握此程序语言之后，你可以选择：

向上延伸：学习对象导向分析设计、Design Patterns、以及软件工程。让自己具有做大型计划的能力。

向下深入：深入了解内部底层的机制，例如操作系统（甚至硬件）内部。

向旁延伸：学习不同的API，例如：多媒体、数据库、企业运算…。

另外，数据结构、算法等基础也很重要。

结论
一分耕耘，一分收获，用对方法，持之以恒。每半年检阅自己这段期间以来的进步，相信你也会很高兴地说「我做到了」！

--------------------------------------------------------------------------------------------

李啸林的补充：

   蔡先生是位编程高手。他写的这篇文章我已经看过许多遍。每一次都有新的启发。在这里我有一点补充，就是关于英语，也许在十年前学计算机不学英语是不可思议的事情，但是现在不同了，随着中国计算机书籍市场的不断扩大，几乎所有著名的计算机书都有了中译本，而且同步的速度也在不断加快。除非你想成为和蔡先生一样的顶尖高手（这是一定要会英语），一般的编程应用可以不用学英语。与其把大量时间花费在拗口难懂的英语学习上，还不如踏踏实实的编几个程序（当然，如果你喜欢英语，又当别论）。我这里说点题外话，其实搞普及性，全民英语教育，是中国教育最大失误之一。

   当然，我们也不好因此责怪程序员，毕竟软件技术变动得太快。公司不可能给程序员足够的训练之后才开始做计画。程序员一下子被指派使用 A 技术，还没弄懂 A 技术是怎么回事，又被指派使用 B 技术，而且都是缝缝补补的方式边学边用，每次都像是全新的开始，遑论技术能量的累积。

  我很庆幸的是，我不太有这样的困扰。因为我是资讯工程系出身（而且我大学时上课一向很认真），所以理论基础稳固，学习新技术对我来说不是难事。我就读大学时，周遭许多同学都瞧不起数据结构、程序语言、操作系统这些所谓「学院派」的课程，以为这些课程一点都不实用。他们认为到了外面公司，这些信息科系所学的一切都派不上用场，「只要会 Visual Basic 和数据库就够了」。这种偏差的心态，恐怕会使得他们在知识经济时代吃足了苦头。

  另外还有一派同学很瞧不起程序设计工作，他们告诉我，像我这样会写程序的人，未来进了社会「还不是被他们这些走管理的人踩在脚下」。所以，他们很轻忽理工课程的学习，甚至还有人相当热衷「成功学」，认为这是迈向成功的快捷方式，却因此把学校的课业弃之不顾。我不敢相信有人竟然如此地本末倒置。

  前一类的人太过于短视近利，后一类的人太过于好高骛远。我一直很不能理解这些人的想法为什么会这样，或许是因为社会环境的风气使然。我很庆幸我到目前还没被社会的大染缸给玷污了（最好这辈子都不要）。我不认为我的学习方式是一种典范，但是一路走来，倒也颇有进展。许多读者来信问我的学习历程，虽然我个人的学习方式不见得适用于每个人，但或许还有一些参考价值（特别是对于那些有志进入信息行业的年轻学子），我想透过本文简短地叙述一下。

   我一向是采用先深后广（也称为 Bottom-Up ， Deep-First ）的学习方式。比方说，当我在学 A 技术的时候，学到一半发现需要 B 技术的基础，我会到书局找出一两本 B 技术的书，然后把 A 先搁着，开始看起 B 技术的书。甚至，我在技术书籍上看到不太熟悉的英文句构时，我会找出一本英文文法书详细读过。这种先深后广的学习方式，适合学生时代全面地自我能力提升，但不适合业界人士。试想，老板要你开发的 ERP 系统已经延迟了，你怎有空研究 J2EE 原文书中的英文文法。先深后广的好处是，学习很扎实；缺点是有时候会偏离主题太多。有一次我发现我原本是要学某软件技术，几次「先深后广」下来，我居然看起老子的道德经了。

  在技术上，我一直都是一个喜新厌旧的人，很少有软件技术能让我持续研究半年以上，我几乎每隔几个月就要换一次领域。 Java 能让我持续这么久，也正是因为 Java 的领域广。透过 Java ，我的技术视野变开阔了。这些年来，我换过的 Java 相关领域包括了：虚拟机器、数据库、企业运算、多媒体、 2D/3D 图学、网络 . … .. 。

  我的学习完全是兴趣导向的，所以压力并不大。因为有兴趣，所以我会很想充分理解一切细节。又因为理解，所以许多原本片片断断的知识都可以渐渐互相融会贯通，累积技术能量，理论和实务之间的藩篱被打破了，学习效率倍增。

  我多年来的学习触觉很敏锐，我常常会抢先一步学好有前瞻性的技术。比方说， Java 还在 beta 时、 UML 还在 0.8 时、 XML 还在 draft 时，我都已经透过网络下载技术文件回来每天抱着猛读了。而在 Java 、 UML 、 XML 当红之后，我已经差不多把这些技术都摸熟了。

  至于该学什么技术，我的判断方式是以技术的优劣来决定。优秀而有独到之处的技术是我的最爱，虽然这类的技术不见得会在市场上胜出，但学习这些技术所得到的启发，对于技术能量的累积与能力的提升会有相当大的助益。至于技术差，但市场需求甚殷者，我还是懒得碰。（好吧！我承认我曾因为市场需求的缘故而学过 MFC 。越清楚 MFC 的技术细节，越是讨厌它，这真是个不堪回首的经验。）

  我通常只看英文技术资料，毕竟大部分第一手的技术信息都是以英文来传播。所以我很早就开始阅读英文技术资料。读英文技术资料的好处是，就算没有学到书中的专业知识，至少也累积培养了英文阅读能力，我一直都是抱着这样的态度。一开始是正襟危坐的看英文技术书籍，字典、翻译机随侍在侧；几年下来，现在是躺着看、趴着看、很随性地看英文技术书籍，因为看英文技术书籍变成一种习惯了。现在，我可以用很快的速度吸收英文技术书籍的知识（有人叫我「吃书的机器」，我把这称号当作是一种恭维）。
  

  近年来，我花在写程序的时间不多，因为时间对我来说很宝贵，而写程序很浪费时间。对初学者来说，大量地写程序是必要的，但过了某个阶段之后，写程序所带来的技术能力成长已经到了极限，还不如多花一点时间看书，学新技术和新观念。  

  我从国小时期开始学习写程序，迄今已有近十八年的时间；采取上述的方式密集学习，迄今也有近十年的光景。迩来数年，我接触的领域越来越广，而且学习速度正在加快，我认为是以前那些努力植下的根苗开始成长了。看看现在的我，或许你会觉得羡慕，但回顾这段学习的岁月，何尝不是一条漫长的道路。

      根据最近的统计显示，最常见的浏览器plug-in是Macromedia公司的Flash Player（http://www.macromedia.com/），安装率高达约98%以上，所以Flash的SWF格式几乎已经成为多媒体Web client的业界（de facto）标准。另外，Java Plug-In【注】也算热门，约有七八成的安装率。

【注】在Java Plug-In内执行的Java程序，称为Java Applet。对于Java感兴趣者，可以造访http://java.sun.com/

      在2004/03/01，REBOL公开了REBOL/Plug-In alpha版【注1】。让REBOL script也能像Flash SWF或Java Applet一样，被嵌入（embed）到网页中。嵌入到网页的REBOL script，可以被称为Reblet【注2】。目前的REBOL/Plugin alpha是以REBOL/View 1.3版为基础，所以你会发现，在REBOL/Plugin上面执行的REBOL程序，比起目前在REBOL/View 1.2.x上执行的程序，更美观。

【注1】所谓的alpha版，指的是非常早期的雏形版本，可能相当不稳定，所以使用上有风险。REBOL Technologies公司提醒用户，使用此alpha版必须“风险自负（at your own risk）”。通常，alpha版的软件不会发布给大众，而是在alpha之后的beta版才发布给大众，beta版的质量通常已经很稳定。

【注2】英文单字字尾加上let，表示“小”的意思。

      目前，在动画制作上，REBOL远比不上Flash方便，因为REBOL没有动画制作辅助工具，我认为利用Reblet取代Flash，短期内并不恰当。但是对于程序员来说，REBOL应该比Flash好用，毕竟Flash是美工导向，而REBOL是程序导向。如果拿Reblet和Java Applet比较，REBOL在开发上比Java Applet更方便，REBOL/Plugin的启动时间比Java Plug-In快，且Reblet比Java Applet体积小许多倍，所以Reblet相当适合取代Java Applet。虽然REBOL/Plug-In的安装率是0%（哎哟！毕竟是新技术嘛！），但是可以随选下载（download on demand），而且只有数百KB，下载时间超短。

      目前，REBOL Technologies公司仅提供Windows/IE版的REBOL/Plugin。其它操作系统与浏览器均未支持。如果你是Windows/IE的用户，请到下面的网址：http://www.rebol.net/plugin/tests/test.html即可随选下载安装REBOL/Plugin【注】。在图1的对话框中，按下【是】，立刻开始下载与安装。

图1  下载REBOL/Plugin

【注】REBOL/Plugin是ActiveX程序，所以你必须先确定，你的IE设定允许执行ActiveX。从菜单中选择【工具】à【Internet选项】à【安全】，如果因特网（Internet）的安全等级是【高安全性】（high）的话，请调低一个等级到【中安全性】（medium）。

            REBOL/Plugin安装完毕之后，你可以看到网页中间有一个如图2的画面，这正是一个Reblet。以后逛到任何内嵌Reblet的网页，REBOL/Plugin就会自动启动。

图2  REBOL/Plugin的测试程序

      你可以在http://www.rebol.net/plugin/demos/index.html找到更多有趣的Reblet。

      因为Reblet本身就是源码，所以用户可以轻易地看到Reblet源码内容。REBOL Technologies公司预计未来会发行REBOL/Plugin Developer’s Kit（开发人员套件），利用此工具，可以将Reblet加密，让REBOL源码比较不容易流出【注】。

【注】我还是要提醒你，这只能增加难度，无法保证源码一定不会被他人取得。

发表日期： Mar. 28, 2004

l           REBOL因为是解释型语言，所以源码就是执行文件，任何人取得REBOL的执行文件就等于取得REBOL的源码，完全不设防。如果你担心你的程序被人窥视，你需要利用REBOL/SDK来将程序加密处理。

l           当你把REBOL程序交给别人时，别人可能因为没有REBOL解释器而无法执行。你可以利用REBOL/SDK来将REBOL解释器和REBOL程序代码结合成一个执行文件，以方便执行。

l           你的REBOL程序可能是由许多文件所组成，比较不方便传送给别人。你可以利用REBOL/SDK来将这些文件全都整合成一个文件。

REBOL/SDK是商业软件，需要向REBOL Technologies公司购买，请参考网页：http://www.rebol.com/purchase.html。

REBOL/SDK的内部组成，如图1所示。

Kernel

            REBOL/SDK的Kernel内包括了三个精简版的解释器，分别是：/Base、/Pro、/Face（另有两个非精简的解释器：/Command与/CommandView）。其中/Base是最简单的版本，比REBOL/Core更小。而/Pro比/Base多了一些功能，/Face也比/Base多了一些功能，如图2所示。

图1  REBOL/SDK的内部组成

图2  三个精简版Kernel的关系

            REBOL/Core中有太多东西，许多程序都用不到（例如辅助说明文件，各种通信协议），如果将这些用不到的功能通通包进执行文件，会导致执行文件体积太大。所以REBOL/SDK设计出此三个精简版的解释器，并将许多原本REBOL/Core或REBOL/View内建的功能和通讯协议以源码的方式公开（图1中的Source Code Module），需要这些功能或通信协议的话，将其含入（include）即可。

Encapsulation

           REBOL/SDK提供许多工具，可以将REBOL脚本和REBOL Kernel包在一起，成为一个执行文件。这些工具统称为EnCap，是Encapsulation（封装）的意思。EnCap系列的工具命名方式一律以En开头，包括了：EnBase、EnPro、EnFace、EnCmd、EnCmdView，分别用来包装/Base、/Pro、/Face、/Command、/CommandView。包装的方式如图3所示。

     从图2中，我们可以发现，EnCap程序，会将主要脚本（Main Script）、相关的文件（影像、声音或其它数据），连同REBOL/SDK的一个Kernal以及被含入的源码（included source），包在一起，成为一个执行文件。

图3  EnCap将程序执行时所需要的一切通通包进一个执行文件中

     比较特别的是，EnCap会对这些包装内容进行压缩和加密【注】，所以也会把key和解密算法包进执行文件中。执行此程序时，会先将这些脚本和数据解密、解压缩、然后才执行。

【注】还是要提醒你，这种加密其实效果不大。只能防一般人，不能防专家。千万别认为经由EnCap处理过的程序可以绝对防止他人取得源码。

发表日期： Mar. 21, 2004

【注】利用CGI或Fast-CGI，也可以让REBOL程序在Server上执行。

          REBOL/IOS是架构在REBOL技术上的一个分布式系统（distributed system），IOS是Internet Operating System的缩写。IOS是商业软件，必须向REBOL Technologies公司购买（可以申请试用），请参考网址：http://www.rebol.com/express-form.html。

REBOL/IOS的架构如图1所示。

      在Client计算机上安装REBOL/Link，Web server上安装REBOL CGI Proxy，商业逻辑（business logic）的计算机上安装REBOL/Express。这刚好很接近目前最流行的四层式（4-tier）架构【注】：

l         第一层：REBOL/Link（Client端程序在此执行）

l         第二层：Web Server（+ REBOL CGI Proxy）

l         第三层：REBOL/Express Server（Server端程序在此执行）

l         第四层：数据库

图1  REBOL/IOS的四层式架构

【注】唯一的差别在于，一般我们提到四层的架构，指的都是第一层使用网页浏览器，而REBOL/IOS则是使用自己的软件：REBOL/Link。

      除了图1的四层式（4-tier）架构之外，也可以不经过Web Server，改用Client-Server的两层式架构【注】，如图2所示。

【注】其实，我刻意把图2中的数据库拿掉，免得被误认为是三层的架构。通常三层的架构指的是：第一层浏览器，第二层Web，第三层数据库。

图2  REBOL/IOS的两层式架构

REBOL/Link除了和Server连接之外，也可以和其它REBOL/Link连接，成为Peer-To-Peer（点对点）的架构，如图3所示。

图3  REBOL/IOS的Peer-To-Peer架构

      在安装REBOL/Link的时候，会同时安装IOS Desktop，这样的感觉有点类似在安装REBOL/View时，同时安装REBOL Desktop。事实上，REBOL/Link的功能和REBOL/View相差无几（但是REBOL/Link比起REBOL/View的功能更多），而且REBOL Desktop和IOS Desktop也是很神似（但是IOS Desktop比起REBOL Desktop更美观）。

      想在REBOL脚本中判断你的REBOL解释器是否为REBOL/Link，可以利用link?函数：

>> link?

== false

发表日期： Mar. 14, 2004

真正重要的是网络的设置与安全的设置，分成两小节来说明。

网络设置

      某些REBOL函数需要知道网络相关的设置，否则无法运作。例如send函数可以用来发送电子邮件。如果使用send，就必须先设置好外寄电子邮件服务器（SMTP Server）。如果没设置电子邮件服务器，就试图送出email，会得到下面的结果：

>> send jerrytsai@shinewave.com.tw "Hello"

** User Error: No network server for smtp is specified

** Near: smtp-port: open [scheme: 'smtp]

either only

      我们可以先设置网络，再执行send，就不会有问题了：

>> set-net [jerrytsai@shinewave.com.tw
      smtp.shinewave.com.tw]

>> send jerrytsai@shinewave.com.tw "Hello"

connecting to: smtp.shinewave.com.tw

     set-net是一个函数，后面需要一个区块（block）参数（所谓的区块，指的是：用中括号[ ]包围的一群值），区块内放置“至少”两个值，第一个值是寄件者的电子邮件信箱，第二个值是外寄电子邮件服务器（SMTP Server）。如果你不知道你的SMTP Server为何，可以从你的收信软件（例如：Microsoft Outlook）中找到这样的信息。

      如果每次使用send前都要先利用set-net来设置网络，也实在是太麻烦了。你可以将这道set-net描述写在user.r中。前一节提到，REBOL解释器启动时，会自动读进user.r文件内的REBOL script，并执行之。

Set-net的参数区块内，最少要指定两个值，最多可以有六个值，这六个值的意义依序分别为：

1.         电子邮件帐号

2.         电子邮件发送服务器

3.         电子邮件接收服务器

4.         proxy服务器

5.         proxy port（默认值是1080）

6.         proxy type（默认值是“socks”）

      任何值如果不存在，可以利用none来表示。例如：

set-net [luke@rebol.com mail none our-proxy 1080 socks]

      这六个值中，第四到第六的值是和proxy有关。如果你是直接利用调制解调器（modem）或以太网（ethernet）联机到互联网（Internet），你不需要设置这三个值。如果你不确定这三个值应该么设置，你可以从你的网页浏览器（Web browser）中找到这些设置。以微软的Internet Explorer浏览器来说，在菜单中选择【工具】à【Internet选项】à【连接】à【局域网设置】，即可找到Proxy的相关设置值。

      对于REBOL来说，proxy类型可以是socks、socks5、socks4、generic。其中generic是generic CERN proxy的意思。

      其实，set-net这个函数会将这六个设置值依序放到下面的六个系统变量中：

SYSTEM/USER/EMAIL

SYSTEM/SCHEMES/DEFAULT/HOST

SYSTEM/SCHEMES/POP/HOST

SYSTEM/SCHEMES/DEFAULT/PROXY/HOST

SYSTEM/SCHEMES/DEFAULT/PROXY/PORT-ID

SYSTEM/SCHEMES/DEFAULT/PROXY/TYPE

      因此，我们也可以不使用set-net函数，而直接设置变量，例如：

>> SYSTEM/USER/EMAIL: jerrytsai@shinewave.com.tw

>> SYSTEM/SCHEMES/DEFAULT/HOST: smtp.shinewave.com.tw

     请注意，利用这种方法来设置变量时，冒号“:”必须紧接在变量后面，而冒号后面必须要有空格。

     你可以利用print来查看这些变量的值，例如：

>> print SYSTEM/SCHEMES/DEFAULT/HOST

msa.hinet.net

安全设置

          REBOL script执行时必须通过REBOL解释器，而REBOL解释器可以进行安全把关，如果解释器发现script试图进行一些“有安全疑虑”的动作时，就会显示出类似图1的对话框（dialog），警告用户。用户可以选择因应的方式：

l         Yes：允许script进行此次动作，继续执行

l         Allow all：允许script进行所有此类动作（以后不用再问了），继续执行

l         No：不允许script进行此动作，继续执行。这会产生Security Violation（违反安全）的Access Error（存取错误）。

l         Quit：将此script终止执行

图1  REBOL解释器询问我们，如何处置有安全疑虑的动作

      何谓“有安全疑虑”的动作？对于REBOL/Core、REBOL/View、REBOL/View/Pro、REBOL/Command、REBOL/Command/View这五个标准的REBOL解释器来说，如果没有特别设置安全，在解释器预定的情况下，如果script试图修改磁盘内容或试图执行磁盘内的文件，就会出现上述的对话框（dialog），来让用户自行决定。藉此保护用户的文件系统，免于受到破坏。

      但是上述的安全设置，只有针对这五个标准的REBOL解释器。对于REBOL/Base、REBOL/Pro、与REBOL/Face来说，完全没有安全的限制。因为这三个精简核心版（kernel）的解释器是给软件开发人员用的，而不是给一般的软件用户用的。软件开发人员只会使用REBOL/Base、REBOL/Pro、与REBOL/Face来测试自己开发出来的REBOL script，而不会用它们来执行其它的REBOL script。

      如果精简核心版的解释器想要和标准版的解释器一样，藉此保护用户的文件系统，免于受到破坏，可以利用下面的叙述：

secure [file [allow read  ask write  ask execute]]【注】

【注】secure后面中括号内的文字，就是一种很简单的方言，由security函数制订，专门用来描述对于网络和磁盘存取动作的限制。方言中出现的字，即使某些和REBOL语言的函数一样（例如此处的read、ask、write），但意义上完全是两回事。这就是方言！用来表达特殊领域，且不受到原本REBOL语法的规范。

      这里的意思是：对于文件的安全控管方式，允许文件被读（allow read）、写入的时候需要询问用户（ask write）、执行文件的时候需要询问用户（ask execute）。

      我们可以利用security函数来针对网络、整个文件系统、特定文件或目录，进行安全上的限制。为了方便起见，我们通常将安全设置的叙述，放在rebol.r中。

Security函数后面可以跟着一个字或一个区块。如果是一个字，则表示网络和文件系统都采用此种安全处理方式。如果是一个区块，可以做比较细微的更动。例如：

Security ask

      上面表示，不管对于网络或磁盘系统的存取，都必须先询问用户，取得同意。

Security [ net quit file ask %./ allow ]

      上面表示，对于网络的存取一概拒绝，且自动结束程序的执行。对于文件系统，必须先询问用户，取得同意。对于目前目录下（“%.”表示目前的目录）的所有文件，一律允许存取。

关于security函数的详细用法，你可以利用help函数（或?）来取得说明文件：

>> ? security

      如果你想执行某个可信任的REBOL脚本，想破除安全限制，你可以利用REBOL解释器的命令行选项“-s”【注】，如下所示。除了“-s”，还有一个“+s”的选项，其作用刚好和“-s”相反。

REBOL -s TrustWorthy.r

【注】这年头，凡事还是小心一点好，建议你不要轻易使用“-s”。

发表日期： Feb. 29, 2004

前述REBOL解释器依据功能的差异，有许多版本，其中REBOL/Core和REBOL/View是免费的。本次先介绍REBOL/Core的安装使用，下一篇文章再介绍REBOL/View。

下载与安装

      你可以从http://www.rebol.com/platforms.shtml下载适合你的REBOL/Core版本（请注意，此版本必须和你的操作系统相匹配）。REBOL/Core其实只有一个执行文件（exe file），你可以直接下载此一文件，或者你也可以下载压缩文件回来再解压缩。

      如果你下载的是一个执行文件，则此文件就是REBOL的解释器。如果你下载的是ZIP或GZ等压缩文件，就需要解压缩。此压缩文件内除了具有执行文件（解释器）之外，还有附上说明文件，以及几个简单的REBOL script程序。只有执行文件是重要的，其它文件都不重要，只要有解释器，就能使用REBOL语言。本节假设你取得的执行文件为rebol.exe（也有可能是其它文件名称，例如rebol031.exe）。

执行与结束

      直接用鼠标双击（double-click）rebol解释器的图标（icon），就可以进入REBOL的console画面。你也可以在DOS命令行窗口（command-line console）中下达命令来执行rebol，如下所示：

rebol

      如果你是采用下达命令的方式，你还可以指定选项（options）和参数（arguments），如下所示：

rebol –q myScript.r

      其中“-q”是选项，“myScript.r”是参数。如果你想知道可以用的选项和参数有哪些，可以用“-?”或“--help”选项，如下所示：

rebol -?

      你也可以在进入REBOL的console之后，再利用usage函数（function），来取得此信息。如下所示：

>> usage

rebol的选项有许多，后面的文章将会在适当的时机陆续介绍这些选项。

REBOL console是一个文字模式的交互接口，在默认（default）的状况下，提示符号（prompt）是“>>”，若有返回值（return value），则返回值的符号是“==”【注】。请看下面的例子：

>> 1 + 2 （注意：1与+与2之间，都必须要有空格）

== 3

【注】提示符号和返回值的符号不一定要是「>>」和「==」。以后我会介绍修改它们的方式。

利用quit函数或q函数【注】可以结束REBOL console，如下所示：

>> quit

【注】特别提醒，REBOL提供exit函数，但exit函数另做其它途之用，而不是用来结束REBOL console的。

发表日期： Feb. 15, 2004

REBOL是Relative Expression-Based Object Language的缩写（abbreviation）。顾名思义，REBOL是一种Relative Expression-Based Language，也是一种Object-Based Language，本节会解释这两者的意义。除此之外，我也说明REBOL的一些特殊之处。总而言之，REBOL是一个打破传统，不同流俗的编程语言【注】。

【注】正因为REBOL不同流俗，所以已经有编程经验的人，在学习REBOL的初期，可能会有一些不适应。我给你们建议是，学习REBOL时，最好暂时忘了其它语言。

方言

所谓的Relative Expression就是“方言”（dialect）的意思，REBOL能够如此简洁，一半功劳要归于方言。例如：写一个程序，来打开一个窗口（window），窗口上面显示红色的“Hello REBOL”字样，以及一个“OK”按钮（button），按下按钮之后，窗口会立刻关闭。对许多语言来说（包括Java和C#），要写出这样的程序，少则需要十几行源码，多则需要数十行源码。但是REBOL利用VID（Visual Interface Dialect视觉接口方言）只要下面一行就可以做到【注】，执行画面如图1所示。

view layout [ Title "Hello REBOL" red Button "OK" [quit] ]

【注】如果你想动手试试这一行程序，请记得使用含View功能的REBOL版本。也请注意，REBOL不区分英文字母大小写。

图1  只要一行，就可以写出这样的REBOL程序

这就是方言的威力。不同的应用领域（application domain）会有不同的方言，也就是行话（jargon）。例如：律师有律师的行话，建筑业有建筑业的行话，音乐家有音乐家的行话。这些行话不受一般语法的约束规范，自成一套体系，行话通常比正常的语言来得简洁、有力。举例来说，SQL（Structured Query Language）就可以算是一种方言，而不是一般的编程语言，SQL专门用来进行数据库查询。拿SQL来做别的事（例如设计游戏软件），SQL一定做不好，但是拿SQL来和数据库进行沟通，却没有其它编程语言（C#、Java）可以做得比SQL好，因为SQL的应用领域在数据库查询（query）。

REBOL已经有许多方言，每个方言的规模都不大，很容易学，最有名的REBOL方言是VID（Visual Interface Dialect），可以让我们很轻易地设计出窗口程序。除了REBOL内建（built-in）的方言之外，编程员也可以建立自己的方言。例如：有人用REBOL建立了一个REBOL/Flash方言，可以用来产生Flash的SWF档案格式（file format），请看网址：http://sweb.cz/oliva.david/swf/。

Object

REBOL是object language，因为它具备封装（encapsulation）的概念，可以把数据和动作包装在一个对象（object）中。但是REBOL只能算是object-based language，不是Object-Oriented Language（OOL），因为它不具有继承和多态【注】。学院派的定义是：同时具备封装、继承、多态的语言，才是OOL。

【注】本节一开始提到REBOL是一种多态的语言，这里却又说REBOL不具备多态。我没有自相矛盾，因为此多态非彼多态。REBOL支持参数式多态（parametric polymorphism），也就是通称的Overloading。但是REBOL不支持OO要求的多态（也就是Overriding / Virtual Method）。

OO是近年的显学，似乎大家都喜欢OO。乍闻REBOL不支持继承和多态，还真是让人无所适从，担心REBOL会不会是一个残缺不全的语言？事实上，因为REBOL设计的非常巧妙，没有继承和多态并无大碍。继承和多态的好处在于：程序代码的复用（code reuse），以及设计的复用（design reuse）。REBOL虽然不支持继承和多态，但是这两点都做得到。所以有没有支持继承和多态，也就不重要了。反倒因为不支持继承和多态，REBOL变得相当容易学习，因为继承和多态（特别是多态）一直都是OO编程入门者会遭遇到的学习瓶颈。

丰富的数据类型

C语言支持的类型有int、char等近十种，Java支持类型的数目稍多一点，C#支持类型的数目又比Java更多一点，但还是比不上REBOL。REBOL所支持的类型超过50个，传统的整数、浮点数（floating point number）、字符（character）、字符串（string）当然REBOL都有提供，更特别的是，REBOL提供许多现代化的类型，例如e-Mail、URL、HTML的卷标（tag）等，都是类型。请看下面的REBOL例子：

>> myEmail: xy.cai@msa.hinet.net

>> type? myEmail

== email!

我将myEmail设定为xy.cai@ msa.hinet.net，然后问myEmail的类型（type）为何，得到的答案正是email!类型。

想知道REBOL支持哪些类型吗？在REBOL的console中输入：

>> help datatype!

Reflectivity打破数据和程序的藩篱

在REBOL里面，一切都是“值（value）”，也就是数据。程序代码（code）和数据（data）之间没有明确的分际。这样的观念并非REBOL首创，毕竟早在1959年诞生的Lisp语言就是如此，只是这样的作法并非主流。

Reflectivity（反射）是一面照妖镜，所有事物的内在无所遁形。REBOL具有高度动态的reflectivity，所以数据和程序码的分际无须存在，数据可以是程序，程序也可以是数据，一切都被reflectivity所掌控，就好像孙悟空再怎么变，仍逃不出如来佛的掌心。

请先牢记一句话：任何东西，只要没被求值（evaluate）【注】，就只是数据，而不是程序代码。

内建分析器

REBOL内建分析器（parser），这个分析器相当好用，而且比Perl、Java、C#等语言所使用的Regular Expression【注】更简单易懂，还可以搭配REBOL的数据类型来使用。

【注】Regular Expression的功能强大，没人会否认；但是Regular Express不好学、容易忘记、容易犯错，这也没人能否认。

有了此分析器，搭配reflectivity，就能轻易地设计出方言解译器。如果你是其它语言的使用者，你可以告诉朋友，“我写了一个不错的C#程序库，你想不想试试？”。在REBOL世界，我们喜欢告诉朋友，“我设计了一个不错的REBOL方言，你想不想试试？”酷！

关于方言的其它解说，请参考本文章第一小节的叙述。

发表日期： Feb. 8, 2004

我为什么喜欢 REBOL ，因为她独特、单纯、娇小、善解人意还精通多种方言。我想要完成的事，她总是很快就帮我达成。与她在一起，每每让我体验到前所未有的愉悦快感。我祈求上天，不要让她离开我。我唯一的希望是，她能早一点学会中文，更快融入我们的社会。

REBOL 是一个编程语言（ programming language ）。由于 REBOL 程序执行时，需要解释器（ interpreter ），所以 REBOL 可以被视为是一种脚本语言（ scripting language ）。利用 REBOL 写出来的程序（ program ），也称为脚本（ script ）。【注】

【注】 REBOL 脚本的扩展名，通常是“ .r ”。

REBOL 第一版诞生于 1997 年，当时支持三个操作系统。现在是 2004 年， REBOL 已经推出 2.5.x 版，支持 43 个 CPU+OS 平台（ platform ），且具备 GUI 、数据库存取等功能。 REBOL 不是玩具语言， REBOL 已经具备项目开发（ project development ）的能力。 REBOL 也推出一个轻量级的（ light-weighted ）操作平台，名为 IOS （ Internet Operating System ，网络操作系统）。

历史

REBOL 语言的设计者是 Carl Sassenrath ，你可以在下列的网址看到他的详细自传： http://www.rebol.com/bio-carl.html 。 Carl Sassenrath 任职过 HP 、 Apple 等公司，他也是 Amiga OS 的设计者。 Amiga OS 是 八十 年代 （ 1985 年 ） 最早出现的 PC 多任务（ multi-tasking ）操作系统。

Carl Sassenrath 学习过数十种编程语言，也开发过许多语言的编译器（ compiler ）或解释器。这样的经验，使得他想要创造出一个与众不同的语言，而 REBOL 正是这样的产物。他也为此在 1996 年创立了一家公司“ REBOL Technologies ”，成为这家公司的 CTO 与总裁。 REBOL Technologies 的网址是：

http://www.rebol.com/ 。

“ Get The Message® ” 是 REBOL Technologies 公司的企业口号 （ slogan ）， 他们甚至将此口号申请为注册商标 ， 可见 messaging （消 息传送 ） 对于 REBOL 语言来说 ， 是一个多么重要的概念。 REBOL Technologies 公司认为， REBOL 是一种消息传送语言（ messaging language ），可以用来作为程序和程序、人和人、人和程序之间的沟通桥梁。

架构

刚刚也提到，利用 REBOL 语言写出来的程序，称为 REBOL script ，必须通过 REBOL 解释器才能执行。 REBOL Technologies 公司已经为 REBOL/Core 设计了许多平台的解释器，可以在下面的网址免费取得：

http://www.rebol.com/platforms.shtml 。

有了这些解释器， REBOL script 可以在许多不同的平台上执行。如图 1 所示。

除了不同平台的 REBOL 解释器之外，还有不同功能的 REBOL 解释器。目前常见的 REBOL 解释器的版本有 REBOL/Core 、 REBOL/View 、 REBOL/View/Pro 、 REBOL/Command 、 REBOL/Command/View 。每个版本的功能都不一样，如图 2 所示。

图 2 只是一个很简略的功能比较图。除了这里所列出的五个解释器之外，还有一个名为 REBOL/Link 的产品，必须搭配 IOS 使用。另外，在 REBOL/SDK 产品中，还有一些特殊的解释器（例如： REBOL/Base 、 REBOL/Face ）。

图 1  有了 REBOL 解释器， REBOL script 可以在不同的平台上执行

图 2  随着功能不同， REBOL 解释器分成五种

优缺点

REBOL 具有下列的优点：

1. 跨平台： REBOL 跨越的平台不会比 Java 少，请看此网址：
       http://www.rebol.com/platforms.shtml 。

2. 简单好学： REBOL 比起 Perl 、 C# 、 Java 等目前流行的语言更容易学习。

3. 易用好写：许多人（包括我自己）发现， REBOL 写出来的程序，长度只有 Java 的五分之一左右，大幅地提高生产力（ productivity ）。

4. 内建许多 Internet 通信协议（ protocol ）：包括 TCP 、 UDP 、 POP 、 FTP 、 HTTP 等十多个通讯协议，这使得处理网络的工作变得相当简单。

5. 免费： REBOL/Core 与 REBOL/View 是免费的。

6. 核心很小： 200+ KB ，比起 Java 的数十 MB ， REBOL 小了 100 倍。

7. 效率高： REBOL 虽然是解释型语言，但是执行效率相当不错，这一点也让我很惊讶。

8. 安全（ security ）： REBOL 解释器内建安全管理器。

9. 适合写 server 程序： REBOL 本来就相当适合处理 Internet 和文字，又能进行数据库存取，可以利用 CGI 或 Fast-CGI 来开发 Web 应用。

10. 适合写 client 程序： REBOL/View 可以用来开发 GUI 程序，而且 VID 方言使得 GUI 程序相当容易开发。

REBOL 为我带来的最大好处就是，节省时间，提高生产力。利用 REBOL ，我可以更快完成一些程序。一样的程序，如果改用 Java 来写，通常需要花费数倍的时间。使用 REBOL 所提升的生产力，有一点不可思议。

但是 REBOL 并不完美，我觉得目前 REBOL 有以下的缺点：

1. GUI 组件（ component ）尚未齐备，欠缺一些组件（例如： REBOL 没有 menu 与 tree ），欠缺常用对话框（例如打开文件、选择颜色），且未具备操作系统 GUI 组件的外观（ look-and-feel ）。

2. GUI 绘图功能相当阳春，例如：不支持粗线、贝兹曲线（ Bezier ）等。

3. 不支持中文。 REBOL 的核心仍是单字节（ single-byte ），而不是双字节（ double-byte ）。因为 REBOL 不支持 Unicode ，所以在 REBOL/Core 中处理中文变得很麻烦，甚至在 REBOL/View 中，任何中文字一律变成乱码，无法正确显示出来。

4. 欠缺 Web server 模块，目前只能使用 CGI 和 Fast CGI 来写 Web 应用。 REBOL Technologies 公司一直未推出 REBOL/Apache 。

5. 相当欠缺文件。文件过时（ out of date ）与欠缺的问题，相当严重。这对于推广 REBOL 相当不利。

其中第一点和第二点（ GUI ），在 REBOL/View 1.3 中应该会有很大的改进（目前 REBOL/View 的版本是 1.2.x ）。我认为 REBOL/View 1.3 应该在 2004 年会推出。而关于第三点（ Unicode ），最近 REBOL Technologies 公司给我的答案是，在 REBOL/View 1.3 推出之后，可能会开始进行 REBOL 核心的改写，以支持 Unicode 。我希望华人的读者，也能向他们施加压力，以促使他们加速支持 Unicode 。对 REBOL 公司有任何建议，到可以利用下面的网页发表意见：

http://www.rebol.com/feedback.html 。

发表日期： Feb. 1, 2004

       Debug 的过程分成两个步骤：

l         找到 bug 所在地

l         修正 bug

      事实上，真正困难的地方在第一点，如果你能找到 bug 所在地，应该就知道怎么修正 bug 了。本文章简单地介绍 debugger 的用法，希望你再次遇到 bug 时，能够不慌不忙地把这些技巧派上用场。

调整步伐

      最不花脑筋的 debug 方式就是：逐行执行，每执行一行程序代码就暂停，立刻观察这一行的执行结果是否如你所预期，没问题的话就继续执行下一行。

      当你在逐行执行的时候，如果遇到了 method invocation （方法调用），你可以选择要跳进此 method 或者不跳进此 method 。欲跳进此 method ，就使用 step in ；欲一口气执行完此 method ，就使用 step over 。至于要不要跳进去，你可以有自己的考量。一般来说，如果你认定该 method 应该不会有问题时，你就使用 step over ，否则使用 step in 。

      如果已经在某 method 内，但是认为此 method 后面的程序代码不会有 bug ，你可以透过 step out 来往上跳，跳离开这个 method 。

      在 debug 的时候，前进的步伐很重要， step over 、 step in 、 step out 三者必须好好搭配使用，才不会“自乱阵脚”。

控制疏密

      光靠上面三种 step 方式，要找到 bug ，就如同海底捞针一样，并不容易。你还需要 breakpoint （断点）的辅助。

      你应该先透过经验来判断， bug 最有可能出现在哪些地方。然后在这些地方的前后分别设定 breakpoint 。为了加快 debug 的速度，我们经常同时在程序中设定多个断点。

      在 debug 模式下执行程序时，遇到断点，程序就会暂停，我们可以利用这个机会检视目前的执行结果是否符合预期，如果有差池的话，就表示刚才执行过的程序代码有问题，你已经找到了 bug 的区域，立刻停止此次的 debug 执行模式。接着再重来一次，继续缩小范围。当范围已经很小时，可以改用 step 的方式来找 bug 。

分析观察

      不管是肇因于 breakpoint 或 step ，程序在 debug 模式下暂停时，我们都需要“观察”（ watch ）程序目前的状态（ state ），据以判断方才的执行过程有无错误。程序状态其实就是数据的集合，所以我们的“观察”对象就是程序中的变量值。 debug 工具可以让我们很方便地观察程序中各个变量的值，有些 debug 工具还可以让我们输入由变量组成的计算式（ expression ），输出计算结果以方便我们观察。

      某些 debugger 甚至具有修改变量值的功能，可以让你在程序暂停时，修改程序状态，然后继续执行。

理清头绪

      对于多线程（ multi-thread ）程序， debugger 依然能进行上述的 step 、 breakpoint 、 watch 。通常 debugger 会在 watch 窗口中以树状结构区分出线程，然后才个别列出各个线程的区域变量，以免混淆。

      为了因应撰写 client/server 程序的需求，有些 debug 工具甚至可以同时帮助多个 process 进行除错。

隔空抓药

      “捎来药丸的，可是白胡子的老公公？”我们姑且相信这个妖妇 [1] 的确具备隔空抓药的本事，但提到这样的本事，许多 debugger 也不多让。越来越多的 debugger 开始支持 remote debugging ，让程序员可以在一部 PC 上， debug 另一部 PC 上的程序。

      以 Java 来说，最早支持 remote debugging 的是 VisualCafe 。现在， Sun 的 JVM 都支持 JVMDI （ Java VM Debug Interface ）以及 JDWP （ Java Debug Wire Protocol ），所以想设计出一个能隔空抓药的标准 remote debugger 也不难，主流的 Java 开发工具也开始支持 remote debugging 。

de 程序中的 bug ，也 de 生活中的 bug

      我们除了 de 程序中的 bug ，也要 de 生活中的 bug （窃听器也被称做 bug ）。军政要人的座机可能被装满 bug ，美凤姊姊的座车和手机内也被装了 bug 。越是重要的人，周遭的 bug 就会越多，越是需要常常进行 debug 。

      如果无法确定生活中毫无 bug ，请各位务必要做最坏的打算，试图干扰任何可能存在的 bug ，做法很简单，例如：放大电视机音量、关灯，都很有效。那也就是为什么，我向亲近好友坦承“关灯版”的男主角其实就是我，至今仍然没有人相信的缘故。

单字：OOOO（Obsessive-Object-Orientation Obliquity）
发音：KK: [O`OOO] DJ: /O`OOO/
解释：n. 【医学】【计算机】过度对象导向偏颇症，是一种过度使用对象导向（Object-Orientation）的病症，好发于年轻的程序员身上。属于接触性传染，带原者包括了不良的程序设计书籍和不够专精的程序设计老师及同事同学。

例句：

1.      OO Advocates tend to be OOOO patients.（OO 拥护者很容易就会变成 OOOO 的病人。）

2.      People with a good understanding of computer science can get rid of OOOO.（对于信息科学有深入的了解可以避免 OOOO。）

3.      Most OO experts used to be OOOO victims.（大部分 OO 专家都曾经是 OOOO 的受害者。）

为了要有模有样，我发明 OOOO 这个词时，还特别参考了心理学的强迫症（obsessive-compulsive disorder），原本想叫做 obsessive-object-orientation disorder（OOOD），只是我不喜欢在这个词的最后使用 disorder，我于是用 O 开头的单字 obliquity 来取代 disorder，刚好形成四连 O 的词。

当今 OOOO 的感染者人数众多，数量直逼想靠乐透彩发大财的愚夫愚妇。他们常常有严重的幻想，认为全世界最了不起的东西就是 OO，成天开口闭口都是 OO，写程序时只管大用特用 OO，完全不管 OO 所带来的负面影响。

许多错误的信息，是造成 OOOO 普遍的原因。例如下面的说法，在许多书上都看得到：

对象导向是很自然的，教导一个小孩对象导向比教导一个计算机教授更简单，因为教授已经太熟悉计算机内的运作，所以比较难建立正确的对象导向观念。

上述的说法并不正确，但是许多人却都以为这样的说法是对的。我认为这样的说法错在于：

1.      只要对于计算机运作原理的认知不够，很难真的学会 OO，因为 OO 毕竟是用在计算机上的。许多人通常只能了解封装，对于继承不能完全掌握，对于多型更是难以捉摸。

2.      只要对于计算机运作原理的认知不够，规划出来的 OO 一点都不实用。可能是效率太差，可能是弹性太差，问题很多。

OOOO 患者写出来的程序常常会有下列的病征：

1.      太多类别：每个类别重用率极低，造成内存浪费太多。通常这样的状况，必须适当地利用继承来改写，或把功能类似的数个类别浓缩成一个类别。

2.      太多继承：继承固然可以提高重用率，但是也会使得对象体积变大许多，而且执行效率也会变差。继承被误用的情况一直很严重。更糟的是，继承是一种静态的关连，使得程序的弹性变差。许多时候，继承可以用 associate 来改写。

3.      太多物件：通常前述的「太多类别」会造成太多对象的状况，但是即使类别不多，也有机会造成太多对象的状况。一个程序使用太多对象会造成内存浪费。其实在许多时候，对象可以彼此共享的。

4.      太多短命物件：这会造成建构（construct）和回收（reclaim）花的时间太多，对于系统效率有很不好的影响。许多程序员的程序中有许多短命对象，但他们却完全不自觉。可以使用 Object Pool 等方式来改写。

5.      太多视觉组件：「太多对象」已经很不好了，如果这些对象是视觉组件，更是雪上加霜。视觉组件需要耗费 CPU 大量的运算能力。

6.      太多执行绪：其实从 OO 至上的角度来看，每个对象都是一个执行绪是最 OO 的，但是这样显然实际上不可行，因为占用太多 OS 的资源，效率会变很差。

想摆脱 OOOO，你需要花好几年的时间。建议各位好好研究 Java Swing，这是一个将 OO 发挥到极致又不失弹性和效率的 API。上述的六个 OOOO 的病征，Swing 完全都没有，足见 Swing 设计的巧妙。

OOOO 固然不好，但千万不要因噎废食而不用 OO，毕竟 OO 还是好东西，只是再好的东西都要适量。想摆脱 OOOO，您不妨多学习一些好的 design pattern，并认识操作系统、编译器、以及程序语言内部的原理。

语言与链接库

语言通常会伴随着链接库，没有链接库的语言，差不多什么程序都写不出来。比方说，用 C 语言写出一个印出 Hello 的小程序，你需要用到 stdio 的链接库。用 Python 写 GUI 程序，你需要 Tkinter 链接库。

平台与链接库

平台通常也会伴随着链接库，没有链接库的平台，等于是摆明了不希望别人开发此平台的程序。比方说，你想用 Visual C++ 6 开发 Windows 程序，你需要用到 GDI32 以及 USER32 或 MFC 等链接库。写 Mac OS 9 的程序，需要 Carbon 链接库。

平台的链接库 vs 语言的链接库

在 A 平台上用 B 语言开发软件，你会同时面对 A 平台的链接库和 B 语言的链接库，此二链接库因为是不同厂商所提供的，所以可能无法百分之百契合，特别是牵涉到内存管理、资源管理、执行绪等和操作系统有密切关系的主题时。如果你想进行的某功能在 A 平台的链接库和 B 语言的链接库都有提供，那么你应该使用 A 平台链接库的版本，通常比较安全些。比方说，用 C 语言开发 Windows 平台的程序，如果你想配置内存，那么你应该呼叫 Win32 API 的版本（比方说 GlobalAlloc()），而非 C 语言的版本（比方说 malloc()）。

跨平台的链接库

你为某平台所开发的程序，为什么不能在别的平台上重新编译之后就能执行？问题就出在平台的链接库上。比方说，你用 C 语言搭配 C 的标准链接库和 Win32 链接库，在 Windows 平台上开发出一个演示文稿软件 WeakPoint 2000；你将 WeakPoint 2000 的原始程序拿到 Linux 上编译，却无法编译成功，问题就出在 Linux 没有 Win32 的链接库。

那么，如果有一个链接库将各个主要平台的链接库萃取（abstract）出一个共通的链接库，不就可以解决这个问题了。例如 Qt 正是这么做，你的 C++ 程序如果只使用标准的 C++ 链接库和 Qt 链接库，你就可以把程序重新编译之后在不同的平台（Linux，Unix，Windows）上执行。

语言 + 平台 + 链接库

Java 就更了不起了，不但将链接库统一起来，更将平台统一起来，也就是说程序不用重新编译，就可以直接执行。但是也因此，多了一层 JVM，牺牲了一部分的效率。

跨语言的链接库

Borland 的 VCL 链接库是在 Windows 平台上相当受好评的一套链接库，可以被 C++ 和 Object Pascal（Delphi）使用。其实「跨语言的链接库」不是一种很好的说法，毕竟许多语言都可以连结外部原生链接库，两者不需要是同一种语言。但是这样的连结是否需要大费周章，则有相当大的差异。而 Delphi 和 C++ Builder 使用 VCL 则是相当方便的。

即将在本月底问世的 Mac OS X，提供了 Cocoa 链接库。Cocoa 链接库可以被 Objective-C 和 Java 语言使用。Objective-C 和 Java 语言版的 Cocoa 链接库相似性在九成以上。Java 在 Mac OS X 的原生程序设计上被简化成一个纯语言，完全不使用 Java 的 API，只使用 Cocoa 链接库，这倒是挺特别的。（当然 Mac OS X 也另外会有 JVM 来支持一般的 J2SE）

语言规格 + 平台 + 链接库 = 包山包海 ?

.NET 比 Java 的眼光更高，甚至准备将语言规格也统一起来。.NET 有一个 CLS（common language specification），任何语言只要符合 CLS 这个标准，就可以轻易地整合进 .NET 平台，享用 .NET 平台的资源。这一点就是 Java 比不上的。虽然别的语言一样可以设计出编译器来将程序编译成 Java bytecode，在 JVM 上执行，但 Java 并没有提供直接的支持，所以要移植一个语言到 Java，比移植一个语言到 .NET 来得困难。

.NET 虽然允许各种语言，但是为了因应 CLS，所以各个语言常常需要做出妥协更改语言本身，比方说 Visual Basic 的更改幅度就很大（Visual Basic 7 差不多是一个新的语言了），而 JScript 和 Visual C++ 的语言也都有改变。这种方式的语言中立性，无疑是削足适履。有了 CLS 的规范，这些语言会趋于一致，思维模式如出一辙，只有一些微不足道的小差异。历史会证明，C# 会是 .NET 平台上独大的语言，.NET 上的其它语言都将沦为点缀，这么一来，跨语言的宣示，竟成了一个幌子。虽然我对 .NET 的语言中立性这点颇有疑异，但我倒是挺喜欢 .NET framework 的，我忍不住竖起大拇指称赞 .NET framework 是「歹竹出好笋」。

.NET 的语言规格和链接库都是统一的。命运多舛的 Eiffel 将 .NET 视为救命的浮木，准备将 Eiffel 移植到 .NET，但这么一来，Eiffel 势必得放弃自行开发的 Windows 专用链接库 WEL（Windows Eiffel Library）与跨平台的链接库（比方说 EiffelVision 等）。难道 Eiffel 没有发现它所以为的浮木，其实是鳄鱼伪装的？

同样的问题也会发生在 Delphi 上，如果 Delphi 准备移植到 .NET，也必须更改一部分的语言特性，并可能要放弃在 .NET 上使用 VCL（CLX）。Delphi 这么做一点好处都没有。

最乱的时代，最好的选择

看完这篇文章，你可能已经头昏脑胀了。没关系，你只要记得下面这句话就好了：最乱的时代，最好的选择 ...Java。