冒号空间

冒号课堂§1.3：语言选择

郑晖 — Thu, 27 Aug 2009 10:28:50 +0800

冒号课堂

第一课开班导言(3)

1.3语言选择——合适的就是好的

尺有所短，寸有所长 ——《楚辞》

关键词：计算机语言,低级语言,高级语言,中级语言

摘要：简要回顾计算机语言

！预览

· 评判语言优劣，如同争论兵器高下，倘若撇开使用的主体和对象，皆为空泛之谈

· 高级语言好比长兵器，威力强大却难免滞重，长于大型应用，可谓“一寸长，一寸强”；低级语言好比短兵器，轻便灵活却难免风险，长于底层应用，可谓“一寸短，一寸险”

· 西门吹雪的西来一剑，那是C语言；李寻欢的小李飞刀，那是汇编语言；陆小凤的灵犀一指，那是机器语言

？提问

语言好坏的标准是什么？
计算机语言的发展经历了哪几个阶段？
第四代语言和第五代语言与前三代语言相比，有什么不同？
什么是低级语言和高级语言？各自的特点与应用范围是什么？
为什么称C语言为中级语言？

：讲解

问号觉得自己的问题并未解决，追问：“这么多种语言，仅凭流行度就能分出主次优劣吗？”

“流行度当然不是唯一的指标。”冒号答道，“语言的主次优劣因人而异，答案在你们自己身上。还是刚才那句话，真正的老师就是你自己。 ”

期待的目光如风中之烛般开始黯淡。

冒号又道：“评书里名师授艺时，常常要徒弟自己挑选称手的兵器。威武的刀，灵活的枪，飘逸的剑，浑厚的棍，粗犷的斧，霸道的锤，诡异的鞭，无不谙合武者的个性。评判语言优劣，如同争论兵器高下，倘若撇开使用的主体和对象，皆为空泛之谈。”

句号若有所悟：“所以好的语言就是适合编程者和解决对象的语言。”

“非常正确！”冒号赞许道，“这就是问号同学要的答案。”

引号并不满足：“可我记得评书里经常描述高手的一句话：十八般兵器样样精通。”

冒号一笑：“兵器虽多，其理相通，高手精通多种兵器何足为奇？但如果让赵云使锤，李元霸使枪，武力恐怕还是要大打折扣吧？”

逗号依然困惑：“我们如何判断一种语言是否适合自己，是否适合解决对象呢？”

冒号看出大家共同的疑惑，不紧不慢地说：“要想从中选择，自然先得了解，不然怎知兵器称不称手、合不合用？现在进入正题，我们先对计算机语言作个简要的回顾。”

大伙均想，总算要挠着痒处了。

“计算机语言按其发展历程通常分为五代。”冒号说完，在黑板上写下——

第一代语言（1GL）：机器语言

第二代语言（2GL）：汇编语言——IA-32 Assembly，SPARC Assembly等

第三代语言（3GL）：高级语言——Fortran，Pascal，C，Java，VB等

第四代语言（4GL）：面向问题语言——SQL，SAS，SPSS等

第五代语言（5GL）：人工智能语言——Prolog，Mercury，OPS5等

“谁能简要地谈谈这段历史？”冒号又开始踢回传球了。

“最新的两代语言我不是特别熟悉，就说一下前几代吧。” 一阵沉默后，引号终于毛遂自荐，“计算机语言是人用来指挥计算机的语言，而计算机只懂一种语言—— 由0和1组成的机器语言（machine language）。最初人们直接用这种语言下达指令，可它们实在太难记忆和阅读了，开发和维护起来既费时又易错，严重桎梏了程序员的生产力。后来人们发明了汇编语言（assembly language），用接近英语单词的助记码（mnemonic code）来代替0、1串，由助手——汇编器（assembler）将其转化为机器语言。这些助手很称职，但有两个缺点：一是毫无主见，基本上只会一一对应地翻译，程序员必须不厌其烦地交代每一个细节；二是不知变通，换种机器就傻眼了。于是人们陆续引进了各种高级语言（high- level programming language），同时启用更得力的助手——编译器（compiler）和解释器（interpreter）。这些助手除了能理解更简洁更抽象的高级语言外，还能因地制宜地对一些指令进行优化处理。程序员的劳动力得以极大的解放，生产效率得以大幅的提升。直到现在，高级语言还是最主要的开发语言，包括前面提到的十二种最流行的语言。”

引号发言甫毕，冒号立即献上溢美之词：“精彩！精当！一气呵成！看看，你还怀疑自己不够格作老师吗？”

一种晕眩感向引号袭来。

冒号继续引号的讲述：“从机器语言到汇编语言、再到高级语言的演变，堪比从徒步行走到乘自行车、再到乘汽车的变革，越来越省时、省力、省心。循此方向，第四代语言更专注业务逻辑和问题领域。程序员主要负责分析和描述问题，不再花大量时间去考虑具体的算法和逻辑。事实上，最初提出第四代语言的概念，就是希望非专业程序员都能做应用开发。”

逗号心下一惊：“那我等岂不是要失业了？”

冒号宽慰道：“倒不用太担心。正如引号所说的，语言越来越高级，背后靠的是越来越能干的助手。这些助手本身就是软件，还是需要专业程序员开发的。更何况，这种理想的全面实现依然任重而道远。”

问号百思莫解：“第四代语言到第五代语言的发展路线似乎不够清晰，在逻辑上如何解释呢？”

冒号作出解答：“第四代语言虽然足够强大，但过于局限某些特定领域，基本上属于领域特定语言^[1]（Domain Specific Language，简称DSL），而不是我们所熟悉的通用编程语言（General- Purpose Programming Language，简称GPPL）。专门用于数据库操作的SQL、用于统计分析的SAS和SPSS、用于科学计算的Mathematica都是典型的第四代语言。然而一个系统往往横跨多个领域，如果每个领域使用不同的语言，并且不同领域的语言在概念和方法上也不统一，必然会给集成和整合带来的困难。第五代语言在保持第三代语言的通用性的前提下，继承了第四代语言的优点，即重在目标而非过程、重在描述而非实现。如果把这种优点用在汽车上，那么下一代的交通工具也许是无人驾驶的智能汽车。只要输入目的地，它会自动通过GPS寻找最佳路径，自动根据路况变速转向，一直驶到终点。”

叹号身形微颤：“坐这种车我可不放心。”

冒号一撇嘴：“这当然只是一种假想。同样地，第五代语言号称人工智能语言，虽然雄心勃勃，试图让机器理解人类的自然语言，并且具备人类的思维能力，但目前看来这一目标还显得遥不可及。”

句号很赞同：“是啊，超级计算机虽然可以战胜国际象棋的世界冠军，但在围棋上弱智得很。”

冒号提纲挈领：“也有人简单地将前两代语言统称为低级语言，其他的统称为高级语言。语言从低级到高级，离机器语言更远，离人类语言更近，因而更易读写、调试和维护，安全性、通用性和可移植性更强，开发效率更高，更加抽象和宏观；但同时运行速度和效率下降，用法和功能上局限性更大。如果拿兵器作比，高级语言好比长兵器，威力强大却难免滞重，长于大型应用，可谓‘一寸长，一寸强’；低级语言好比短兵器，轻便灵活却难免风险，长于底层应用，可谓 ‘一寸短，一寸险’。”

大伙心里话，敢情来这儿不是学编程，是学武术的。

叹号说道：“我看还是高级语言好，现在谁还学低级语言啊？”

冒号纠正道：“低级语言并不低级，只是随着高级语言的出现，计算机硬件性能的提高，渐渐有些边缘化了。虽然几乎没有人再用机器语言编程了，汇编语言仍有其用武之地。常见的有：包括嵌入式系统在内的系统开发，如操作系统、编译器、驱动程序、无线通讯、DSP、PDA、GPS等；其他对资源、性能、速度和效率极为敏感的软件开发；以信息安全、软件维护与破解等为目的的逆向工程等等。即使你不打算从事系统开发，也不想作红客、黑客或骇客，掌握汇编语言对你深入了解计算机内部运行机制、调试软件和改进程序中某些关键代码的算法也是有帮助的。 ”

引号提出：“好像有些书上把C语言称为中级语言。”

冒号答道：“这是因为C兼具高级语言和低级语言的特征。一方面它提供了高层抽象和可移植性，使程序员更多地专注问题逻辑而不是机器逻辑；另一方面它也提供诸如指针、位字段（bitfield）等工具进行底层操作，甚至可直接内嵌汇编代码。C语言既简洁灵活又高效强大，是迄今为止最具影响力的语言。几乎所有的操作系统和大多数高级语言都用它来实现，C家族的语言C、C++、Java、C#、D、Objective C等占据主流语言的半壁江山。如果再拿兵器作比，C语言就是一把剑，轻灵飘逸、锐利快捷。一名武将无论擅用什么兵器，往往都会腰悬宝剑。不会C的程序员正如不会使剑的武将，无论如何都是一种缺憾。相比之下，汇编语言就像小刀匕首，而机器语言则近乎赤手空拳了。 ”

句号灵光一闪：“我明白了——西门吹雪的西来一剑，那是C语言；李寻欢的小李飞刀，那是汇编语言；陆小凤的灵犀一指，那是机器语言。”

大家会心地笑了。

逗号冷不防冒出一句：“我会跆拳道哦！”

句号一乐：“哈哈，等你打赢了陆小凤，就封你为机器语言。”

冒号也笑言：“这位是古龙的粉丝吧？武侠小说里的侠客多轻功高绝且喜单打独斗，故使用轻、短兵器居多；而历史小说里的战将多骑马进行大规模作战，故除了佩剑外，使用重、长兵器居多。这就是前面提到的，中低级语言更适合中小型或底层应用，高级语言更适合大型应用。 ”

众人活跃起来，开始议论纷纷。冒号放耳听去，净是些古龙金庸、三国水浒里的人物情节，暗想：通俗小说到底比计算机编程更吸引人啊。

，插语

[1] 领域特定语言，简称DSL。它区别于通用语言，一般用于特定的问题领域，多属于第四代语言。比如SQL是专门针对数据库的语言，LaTeX是专门用于排版的语言，正则表达式（regular expression）是专门处理字符匹配的语言。

。总结

评判语言优劣，不能离开使用语言的主体和对象。好的语言就是适合编程者和解决对象的语言。
计算机语言按其发展历程分为五代，依次为：机器语言、汇编语言、高级语言、面向问题语言和人工智能语言。通常，前两代统称为低级语言，后面的统称为高级语言。
第四代语言和第五代语言与前三代语言最大的不同在于：重目标轻过程、重描述轻实现。
C兼具高级语言和低级语言的特征，因此也被称为中级语言。
计算机语言从低级发展到高级，渐渐远离机器，靠近人类，以牺牲部分性能和效率为代价，换来更高的开发效率和可维护性。中低级语言更适合中小型或底层应用，高级语言更适合大型应用。

冒号课堂§1.2：首轮提问

郑晖 — Wed, 26 Aug 2009 13:18:17 +0800

冒号课堂

第一课开班导言(2)

1.2首轮提问——什么语言好？

敬畏老师莫如敬畏真理 ——题记

关键词：计算机语言,程序语言

摘要：讨论流行的计算机语言

！预览

· 真正的老师是你自己

· 没有激情作氧气，灵感的火花注定转瞬即灭

？提问

谁是你真正的老师？
程序员是吃青春饭的吗？
计算机语言这么多，到底学哪个好？

：讲解

众人面面相觑，一阵沉默后开始窃窃私语，显然有些不太习惯这种教学方式——笔记本上还没写两个字呢，老师就把球给踢回来了。

冒号也不说话，只是微笑地望着大家。

还是问号打破僵局，开始发问：“老师——”

冒号扬手打断他：“请不要管我叫老师，真正的老师是你自己。本班的一个特色是：师生角色模糊，大家自主学习，相互启发，教学相长。”

“老冒——”问号顿了顿，全班哄堂大笑，“学软件开发，当然得先学语言，计算机语言这么多，到底哪个好，或者说学哪个好？”

冒号笑道：“这个问题很典型，很实在，也很初级。”

问号被“初级”这个字眼刺得面上一红。

“如果信奉流行的就是好的，那么也许可以给你一个参考答案。”冒号转身在黑板上写下一串清单——

Java(19.40%) C(15.84%) C++(9.63%) VB(8.84%) PHP(8.78%) C#(5.06%)

Python(4.57%) Perl(4.12%) Delphi(3.62%) JavaScript(3.54%) Ruby(3.28%) D(1.26%)

“根据TIOBE^[1]截至2009年2月份的统计结果，选出以上流行度超过1％的12种程序语言。从中可以看出，它们的总占有率接近90％，应该算得上是当今主流语言的代表。尽管有人置疑TIOBE排名的权威性和合理性，但这份名单应该还是八九不离十的。”

引号很疑惑：“怎么可能那么流行的ASP和JSP都不在其中呢？”

“对啊，”逗号附和着，“还有HTML和XML怎么不算呢？”

冒号解释道：“ASP、JSP和PHP是动态网页最流行的三种解决方案。动态网页的实现方式很多，但它们采取的几乎是同样的方式——在静态网页中植入一些能在服务器端运行的代码。在ASP和JSP中，这些代码并不涉及新的语言，故称之为模板、框架或脚本环境更合适些。PHP则不同，本身是一种新的程序语言，并且除了应用于服务端外，还能编写命令行脚本和桌面应用程序。至于HTML和XML，还有XHTML、WML等，均为SGML（Standard Generalized Markup Language）的子集，属于标记语言（Markup Language）。与通常意义上的程序语言有所不同，它们是处理的对象而不是处理的主体。可以说它们更接近数据格式标准，正如CSV和JSON一样。当然也不绝对，XSLT是一种特殊的XML，但却包含变量定义和处理逻辑，更学术地说，它是图灵完备的（Turing-complete）^[2]，应当属于程序语言。”

问号杀了个回马枪：“那CSS、RSS算是程序语言吗？”

冒号从容作答：“与XSLT类似，CSS是一种样式语言（Stylesheet Language），但不是以XML的形式出现。它将传统的HTML中的样式逻辑提炼出来，大大丰富和简化了HTML。不过它没有执行指令或运算，更谈不上图灵完备，因此不属程序语言。至于RSS，只是一种用XML来描述的数据交换规范，甚至连语言都算不上。”

叹号也插了进来：“近来网络开发语言AJAX特别火，难道不算程序语言吗？”

冒号摇头道：“的确有不少人以为AJAX是一门语言，但如果知道AJAX是Asynchronous JavaScript.And XML的简称，便知其谬矣。事实上，它是综合了JavaScript、XML、HTML、CSS等多种语言的一种网络应用技术。”

“就算这些不是程序语言，那也是计算机语言或者与语言密切相关的技术，该学的还是得学。”句号想起问号开始问的是计算机语言，老冒有偷换概念之嫌。

“不错，”冒号点点头，“不仅要学语言，还要熟悉相应的开发环境和开发工具等等，当然最重要的是学习其中的思想。 ”

“唉，学完这些头发都白了，程序员可是吃青春饭的。”叹号叹息道。

冒号扫视了一下，说道：“现在班上每个人都尊口已开，这是一个很好的开始。开放言论才能解放思想，思想解放了才能产生灵感和激情。缺乏灵感和激情的程序员，学习起来吃力，工作起来辛苦，最后就会感慨这是吃青春饭的职业。”

叹号不好意思地挠了挠头。

逗号接言：“灵感嘛，偶尔也许能闪一下，激情可就难喽！

冒号注视着他，一字一顿地说：“没有激情作氧气，灵感的火花注定转瞬即灭。”

，插语

[1] TIOBE（http://www.tiobe.com）是一家评估编程语言流行度的权威机构，每月公布一次编程语言排行榜。

[2] 一个能计算出每个图灵可计算函数（Turing-computable function）的计算系统被称为图灵完备的。一个语言是图灵完备的，意味着该语言的计算能力与一个通用图灵机（Universal Turing Machine）相当，这也是现代计算机语言所能拥有的最高能力。

。总结

本班倡导自主学习、相互启发，真正的老师不是别人，正是自己。
当今主流语言的代表：Java，C，C++，VB，PHP，C#，Python，Perl， Delphi，JavaScript， Ruby和D。
“程序员是吃青春饭的职业”出自那些缺乏灵感和激情的人之口。

冒号课堂§1.1：开班发言

郑晖 — Mon, 24 Aug 2009 22:38:57 +0800

冒号课堂

第一课开班导言(1)

课前导读

第一课为整个课堂学习的内容和风格定调，主要围绕三个问题进行展开：要成为一个优秀的程序员，最需要学习什么知识？领会什么思想？具备什么精神？

本课共分五节——

1.开班发言——程序员的四层境界

2.首轮提问——什么语言好？

3.语言选择——合适的就是好的

4.初识范式——程序王国中的世界观与方法论

5.软件技术——实用还是时髦？

1.1开班发言——程序员的四层境界

授人以鱼不如授人以渔 ——古语

关键词：程序员,学习,知识,思想,精神

摘要：对程序员的一些忠告和建议

！预览

· 学会不如会学，会学不如会用，会用不如被用

· 如果知识是水，我们要挖掘最先涌动的泉眼

· 如果知识是火，我们要捕捉起初点燃的火花

· 如果知识是树，其树大根深，不究立固之本则无以知过去；其枝繁叶茂，不握支撑之干则无以知当下；其蓬勃旺盛，不察生长之点则无以知将来

· 越是喧嚣的世界，越需要宁静的思考，让躁动的心灵得以平息，让蕴藏的灵性得以释放

· 知识之上是思想，思想之上是精神

？提问

软件开发者的成长需要经历有哪些阶段？
要想在IT业中生存与发展，传统的学习方式是否够用？
优秀程序员应该具备哪些素质？

：讲解

冒号开了个程序员提高班，今天迎来了首期学员，他们是问号、句号、逗号、引号和叹号，皆为IT业的新兵。望着台下洋溢着青春与渴望的脸庞，冒号开始了他的开班发言——

大家好！先自我介绍一下，本人姓冒名号字解之。诸位不必叫我老师，就叫老冒好了。比在座各位痴长几岁，“老”是担得的，“师”却不敢妄言。在下编程多年，自觉小有所成，不敢专藏，特开此班与众共享。虽系一家之言、一孔之见，若能抛砖引玉，又何惧方家之哂？疏谬之处，还望海涵斧正，不致自误误人。

客套已毕，言归正传。本班主要采取讨论的形式，只要是软件开发中值得讨论的，但凡本人力之所及，均可共同探讨。

本班的宗旨是：学会不如会学，会学不如会用，会用不如被用。对于一个软件开发者来说，这意味着四个阶段：

学会（知其所然）——掌握一些具体编程知识的初级程序员

会学（知所以然）——能快速而深刻地理解技术并举一反三的程序员

会用（人为我用）——能将所学灵活运用到实际编程设计之中的高级程序员

被用（我为人用）——能设计出广为人用的应用程序（application）、库（library）、工具包（toolkit）、框架（framework）等的系统分析师和架构师

至于被用的更高层次，如发明出主流的设计模式、算法、语言乃至理论等，则可称得上计算机专家了。本班的目的，正是为各位向更高阶段的提升助一臂之力。

大家可能都习惯了在小学、中学和大学里的课堂，那里的知识大多是系统而完备且貌似终极的，那里的学习大多是单向而被动的。但习惯并不意味着享受，更多的是因为别无选择。你们曾被引入一座座知识殿堂，被告知它们如何美轮美奂、巧夺天工，尽管很多时候你们或不以为然、或不解其妙，但还是不得不记下每一处被指点的细微结构。很少有人带你们看看当初为建造这些殿堂而打下的地基、搭设的脚手架，哪怕只是上漆前的模样也好，更遑论一瞻数易其稿的设计图纸了。那些与殿堂相比显得有些原始、甚至丑陋的东西，被有意无意地挡在视线之外。可没有那些，你们将来如何为这些宫殿添砖加瓦，又如何另起楼阁呢？

中国学生恐怕是世界上最擅长考试、最习惯考试、也最厌倦考试的群体了。你们告别了学生生涯，踏上了职业之旅。首先我要恭喜你们，脱离苦海了！同时也要悲告你们，掉进火坑了！危言耸听吗？如果你选择了做程序员，你时时都得学习，没有手把手教你的老师，没有指定的教科书和参考书，有的是层出不穷令人眼花缭乱的新概念、新技术、新问题，好不容易学到一些皮毛，有的已成明日黄花。你时时都得考试，每提交一段代码就是上交一份答卷，你不知道什么时候、什么人会批改，直到——开发组同事发现你的代码难以看懂，系统分析员指出你的程序不符合规范，测试工程师检验到你的软件有缺陷，客户抱怨你的产品太慢太难用，最后老板倒可能告诉你一个好消息：明天起放长假！

其实，又有哪行哪业的人不需要学习和考试呢？IT业只是相对更激烈、更富挑战性而已。在这个瞬息万变、适者生存的时代，如果还沿用封闭、被动的学习方式，恐有淘汰之虞。有鉴于此，本班的风格与你们习惯的课堂有所不同：这里的知识不一定是系统或完备的，但一定是生动鲜活的。如果知识是水，我们要挖掘最先涌动的泉眼；如果知识是火，我们要捕捉起初点燃的火花；如果知识是树，其树大根深，不究立固之本则无以知过去；其枝繁叶茂，不握支撑之干则无以知当下；其蓬勃旺盛，不察生长之点则无以知将来。这里的问题不一定是预设的，结论不一定是终极的，甚至不一定是正确的，但一定是有的放矢、发人深思的。由此决定了这里的学习方式将是开放多元、双向互动的。

越是喧嚣的世界，越需要宁静的思考，让躁动的心灵得以平息，让蕴藏的灵性得以释放。学习编程没有速成大法、没有必杀之技、没有锦囊秘笈、没有终南捷径，只有思考、实践、再思考、再实践。中国的IT界乃至整个学术界过于浮躁和急功近利了，既盲从又自大，缺乏务实精神与研究精神、独立精神与合作精神、批判精神与自省精神。如果一个程序员沾染这种风气，哪怕有再好的学习方法和学习能力，他都注定与“优秀”绝缘。这就是本班极力倡导并将贯穿始终的理念——知识之上是思想，思想之上是精神。

我的开场白到此为止，现在把话语权交给你们，大家自由发问吧。

。总结

软件开发者的成长阶段：学会->会学->会用->被用。

这是一个从“知其所然”到“知所以然”、从“人为我用”到“我为人用”的历程。

传统的学习方式大多有如下特征：

封闭——系统完备的终极式知识

单向——师教生学的单向式传输知识

被动——师命生从的被动式接受知识

静态——只注重知识的现状，忽略知识的起源、历程和未来趋势

继续沿袭这种学习方式，是很难在竞争日趋激烈、技术日新月异的IT业中求生存、谋发展的。开放多元、双向互动的现代课堂乃大势所趋。

“知识之上是思想，思想之上是精神。”

一个优秀的程序员，除了要迅速掌握知识、善于领悟思想外，还必须具备务实与研究精神、独立与合作精神、批判与自省精神。

《冒号课堂》目录

郑晖 — Fri, 21 Aug 2009 23:34:27 +0800

上篇：编程范式与编程语言
第一课开班导言
§1.1：开班发言——程序员的四层境界
§1.2：首轮提问——什么语言好？
§1.3：语言选择——合适的就是好的
§1.4：初识范式——程序王国中的世界观与方法论
§1.5：开发技术——实用还是时髦？
第二课重要范式
§2.1：命令范式——一切行动听指挥
§2.2：声明范式——目标决定行动
§2.3：对象范式——民主制社会的编程法则
§2.4：并发范式——合作与竞争
第三课常用范式
§3.1：泛型范式——抽象你的算法
§3.2：超级范式——提升语言的级别
§3.3：切面范式——多角度看问题
§3.4：事件驱动——有事我叫你，没事别烦我
第四课重温范式
§4.1：函数范式——精巧的数学思维
§4.2：逻辑范式——当算法失去了控制
§4.3：汇总范式——一张五味俱全的大烙饼
§4.4：情景范式——餐馆里的编程范式
第五课语言小谈
§5.1：教学计划——接下来的故事
§5.2：数据类型——规则与变通
§5.3：动态语言——披着彩衣飞舞的脚本语言
§5.4：语言误区——语言的宗教情结
第六课语言简评
§6.1：系统语言——权力的双刃剑
§6.2：平台语言——先搭台后唱戏
§6.3：前台语言——视觉与交互的艺术
§6.4：后台脚本——敏捷开发的利器

下篇：抽象机制与对象范式
第七课抽象封装
§7.1：抽象思维——减法和除法的学问
§7.2：数据抽象——“做什么”重于“怎么做”
§7.3：封装隐藏——包装的讲究
第八课抽象接口
§8.1：软件应变——随需而变，适者生存
§8.2：访问控制——代码的多级管理
§8.3：接口服务——讲诚信与守规矩
第九课继承机制
§9.1：继承关系——继承财富，更要继承责任
§9.2：慎用继承——以谨慎之心对待权力
第十课多态机制
§10.1：多态类型——静中之动
§10.2：抽象类型——实中之虚
第十一课值与引用
§11.1：语法类型——体用之分
§11.2：语义类型——阴阳之道
第十二课设计原则
§12.1：间接原则——柔胜于刚，曲胜于直
§12.2：依赖原则——有求皆苦，无欲则刚
§12.3：内聚原则——不是一家人，不进一家门
§12.4：保变原则——与魔鬼打交道的艺术
第十三课设计模式
§13.1：创建模式——不要问我从哪里来
§13.2：结构模式——建筑的技巧
§13.3：行为模式——君子之交淡如水
§13.4：闭班小结——软件无形，编程有道

关于信息系统组织方式的一个提案

郑晖 — Mon, 19 May 2008 10:05:21 +0800

关于信息系统组织方式的一个提案

序言

昨日整理Gmail信箱之时，觉有不便之处，于是进入“Suggest a feature for Gmail”的页面，准备提些建议。不意一只灵感的小虫悄悄爬上脑梢，急欲捕之而后快。遂作“A Proposal on Organization of Information System”一文，以备Gmail参考之用。甘冒不谦之嫌，窃以为该提案是对包括文件系统、邮件系统等在内的信息系统的组织方式的一种创新。为让更多的国内同仁了解，现将此文译成中文。仓促成文，还望诸位方家不吝赐教。

郑晖于2008年5月19日

1. 引言

我们生活在一个信息时代，但有时信息带来的负担甚至超过收益。从用户的角度看，大多数信息系统包括文件系统、邮件系统和各类基于菜单的系统本质上都是层级（hierarchical）结构的。随着信息量的递增，系统的可用性却在递减。这种结构的主要缺陷是它仅提供了通往目标信息的单一通道。用户在任何一个转角处走错都可能导致最终迷路。如果一个信息系统能支持多路通道，情况就会得到改善。有鉴于此，本文借助Gmail系统的一些思想提出了一个切实可行的方案。

2.信息检索之困

信息是个好东西，可储存和重新获取却令人头痛。日复一日地，一个典型的计算机用户浏览并保存网页，收集心仪的书签和RSS，从BT或emule上下载文件，收发电子邮件，编写文档或程序。他愉悦地享受着这一切，直到有一天他发现自己逐渐为信息超载所困扰。一个明显的迹象是他时不时感到有点头晕—— 他的桌面凌乱不堪，各种图标如沙丁鱼般“济济一堂”；他的书签菜单展开来如巨毯般一直拖到地上；他的信箱塞满邮件，鼓鼓囊囊、几欲暴裂。他开始意识到如果这种状况不改变，他的脑袋一定比硬盘或邮箱更早爆炸。此后，他养成了将文件、书签和邮件整理到层级文件夹中的习惯。情况果然大为改观。惜乎好景不长，文档数量增长迅猛，文件夹越来越多、越来越深。将一个文档保存到合适的地方需要花费时间，而找回当初下载或创建的文档则更花时间。整日在树状结构中穿梭，他有些倦恼和迷失了。他知道自己拥有一棵遮天蔽日的圣诞树，上面挂满了琳琅满目的礼物，可是没有多少是触手可及的。每每在掘地三尺仍一无所获之后，他不得不怀疑自己的记忆，偶尔也忍不住怀疑机器的记忆。明知那些失踪之物从来不会自动跳出来，他还是情不自禁地冲着电脑歇斯底里：那些该死的文档到底躲到哪里去了？时不时地，他又滑回老习惯：将所有最新的文件保存到桌面，不为别的，只是那里似乎更方便更令人放心。我们不禁要问：这种困境的根源是什么？

3. Gmail解决方案

问题出在传统的信息组织方式上，即树（或森林）型结构。这种层级结构应付大量信息尚胜任有余，但对于海量信息则有些不堪重负。随着信息量的膨胀，树型结构越来越力不从心。许多文件夹中的列表不可避免地变长，一些文件夹被深层嵌套。在文件系统中，通过在Windows中创建捷径或在Unix类的操作系统中创建符号链接（symbolic link）能一定程度上缓解一些症状，但显然不能根治。作为一种有趣的替代方案，Google的Gmail提供了他们称作“标签”（label）的工具。一个标签是一种文字标记，它能与其他的标签同时应用到一条信息上。开始许多用户抱怨它，因为他们习惯了文件夹风格。但这种抱怨慢慢减少，用户发现他们的信息不再是藏于密密丛林的游击队，而是一字排开等待检阅的正规军。所有最近的信息都在顶部，而这在精心组织的文件夹系统中是不可能的。用户不再为如何分类信息而犯难，他们可以在每条信息上贴上任意多的标签。找一个特定的信息也很容易，既可用自定义标签来过滤，也可用系统标签如inbox, sent, star, chat, trash等来过滤。他们还能通过收信人、发信人、主题和信息内容来搜索。更好的是，用户可定义过滤器自动为来信贴标签。这种解决方案，今后我们称为标签结构，不必囿于邮件管理系统，它能有效地用于文件系统和其他诸如知识管理系统之类的信息系统。

4. 改进方案

标签结构并非尽善尽美。尽管与信息数量比，标签要少得多，但依然会泛滥。在Gmail的标签结构中，所有用户定义的标签是独立而平等的，但事实上——不同的标签在重要性、紧急性和常用性上可能大相径庭；一些标签有着内在联系；同一信息上的不同标签在相关度上也有所不同。比如，“工作”或“家庭”的标签更重要，“待做”或“考试”的标签更紧急，“体育”或“电影”的标签对一个体育迷或电影迷来说更常用。当一个程序员将一些资料标记为“Java”或“C++”后，他很希望它们能自动加上“程序语言”和“OOP”的标签，以便今后它们能出现在一个列表中。最后，一些标签可能比另外的标签更能描述一条信息。综合以上考虑，我们提出如下可行方案。

在标签结构中引入层级结构。我们将标签视作信息的元数据，并将它们以传统的树型结构来组织。这样我们将两个世界最好的部分结合起来，取长补短。实际上我们可以走得更远。我们知道，层级树型结构在图论中是有向树，只要有意义，我们可以把标签结构推广为有向图（digraph）。这意味着一个标签可以有多个上级，有点类似一些OOP语言中的多继承。显然当所有的标签都是树根（即无子标签）时，就退化为Gmail的标签结构。
为标签引入重要性、紧急性和常用性权重，标签可按权重排序。Gmail的星号标签可作此用，但粒度过粗。常用性权重可在每次访问后自动增值，这样最常用的标签总在前面。标签还能按最近访问时间来排序。如是，用户最关心的信息抬眼即是、垂手可得。
引入主标签。一项信息的某个标签可设为主标签。从这种意义上讲，传统的树型结构是我们这种结构的特例：每个文件夹名正是一个标签名。（但有一个细微差别：同样的文件夹名在不同的路径下不会象标签名那样发生冲突）如果主标签的相关度是1，那么其他标签的相关度应在0和1之间，这为搜索和排序提供了新的准则。
引入别名标签。标签允许有多个名字，这些名字可以是同义词、缩写甚至是不同的语种。别名还能更强大：用户可一个标签定义为其他标签的逻辑组合。例如，“我的程序”可定义为“我的文档and程序”，“娱乐”可定义为“体育or小说or电影”等等。
引入线信（thread）。用户能建立thread将相关信息连接起来。Gmail中有会话（conversation），但用户无法自己合并相关邮件。thread 对信息跟踪和保留不同版本的信息非常有用，这种聚合使得信息系统更加紧凑连贯。

5. 结论

要定位一项信息，用户在层级系统中需要点击文件夹在展开，在标签系统中需要点击标签来过滤。我们没有提及搜索是因为搜索较慢且有些信息不以文本形式存在。标签系统是更好的解决方案，但仍有不足之处。为了进一步方便信息检索，我们设计了含权有向图标签结构（weighted diagraph tag structure），这是一种结合树型结构的优点的标签结构。一个具此结构的信息系统应该更加平易近人且令人愉快，它的用户可以象悠闲的养鱼人，不管往池塘里投入多少条鱼，只要一声口哨，他想要的那条就会摇头摆尾地游过来。

A Proposal on Organization of Information System

郑晖 — Sun, 18 May 2008 09:37:13 +0800

A Proposal on Organization of Information System （另见：中文版）

Authored by Hui Zheng on May 18, 2008

1. Introduction

We are living in an age of information, but sometimes information imposes more burden than benefit. From a user’s view, most information systems including file systems, mail systems and various menu-based systems are essentially organized in hierarchical structure. As information increases, yet the usability of the sytems decreases. The major flaw of this kind of structure is that it only provides a single path to the target information. If a user misses one corner, he will possibly lose his way. This situation could be improved if an information system supports multipath routing. Aiming at this, this article proposes a practical solution by borrowing some ideas from Gmail system.

2. Information retrieval problem

Information itself is great, but storing and retrieving information sucks. Day by day, a typical computer user browses and saves web pages, collects favorite bookmarks and RSS, downloads files from BT or emule, composes and receives email, writes documents or programs etc. He enjoys all of these until someday, he finds himself gradually suffering information overload. As an evidence, he now and then feels a little bit dizzy: his desktop is terribly messy with miscellaneous icons packed like sardines, his bookmark menu pulls all the way down like a huge blanket and his inbox is cluttered with mails like a bulging bag. He comes to realize that if this situation cannot be changed, his brains must explode before his hard disk or mailbox does. Thereafter, He cultivates the habit of organizing files, bookmarks and mails into hierarchical folders. As a result, things improve a lot. Unfortunately, good times don’t last long. He finds that as his documents grow rapidly, his folders become more and more, deeper and deeper. It takes some time for him to save a document to appropriate position, and it does even more time to find a document he downloads or composes. He tends to get tired, vexed and somewhat lost when he navigates the hierarchical trees. He knows he possesses a gigantic Christmas tree with tremendous gifts hanging on, but few of them are handy. Time and time again, he fails to find an important document after exhaustive search. He doubts his memory, and occasionally, he doubts machine’s memory. Although he knows those missing stuffs will never automatically jump upon to him, he still cannot help yelling at the machine: where the hell are the damn documents hiding? From time to time, he slips back to the old habit: saving all recent files to desktop, just for better convenience and confidence. So, what is the root of the plague?

3. Gmail’s solution

It turns out that the evil root is the traditional manner of information organization, namely, tree (or forest) structure. This hierarchical structure is reasonable for large but not huge quantities of information items. As the information volume swells, the tree structure becomes unmanageable little by little. The item lists in many folders are inevitably long and some folders are deeply nested. In file systems, this symptom can be alleviated to some degree by creating shortcuts in Windows or symbolic links in Unix-family OS. But that is not a final cure. As an interesting alternative, Google’s Gmail presents what they call “label”. A label is basically a tag which could be applied to a message together with other ones. Many users complain about it at the beginning because they are used to old folder fashion. But the complaints are waning as the time passes by. The users find that their messages are no longer like guerilla hiding in deep forest, instead, they are like regular army in one-line arrangement waiting for inspection. The most recent messages are on the top to access, which is impossible in the well-organized folder system; they won’t be bewildered where to sort the messages since they can apply as many labels as they’d like to the messages; finding a specific message is easy too: users can filter by user-defined labels, or system-defined labels like inbox, sent, star, chat, trash etc. They can also search by sender, receiver, subject and message content. Even better, users can define filters that automatically apply labels to the incoming mails. This solution, henceforth we call tag structure, is not necessarily limited to mail management system, it should apply well to file system and other information systems such as knowledge management system.

4. Our solution

However, tag structure doesn’t always suffice for our needs. Even though tags are much fewer than information items, they still can overflow. In Gmail’s tag structure, all user-defined labels are independent and equal, but as a matter of fact, they are very likely different in their importance, urgency, popularity; some labels have inherent relation; the labels for a given information item vary in correlation. For example, labels like “work” or “family” are more important; labels like “todo” or “exam” are more urgent; labels like “sports” or “film” are more popular if the user is a sports or film fan. It’s also desirable that after a programmer user labels some materials as “Java” or “C++”, those materials can be automatically labeled as “programming language” and “OOP” such that he can later get all programming language-related items or OOP items in one list. Lastly, among all labels for a given information item, one may be more correlative than the others. Taking all of these into consideration, we propose a feasible solution as follows.

Introduce hierarchical structure into tag structure. That is, we treat tags/labels as metadata of information, and organize them in the traditional tree structure. This way we combine two worlds’ best parts together. Actually, we can go further. As we know, hierarchical tree structure is a directed tree in graph theory, but we may generalize the tag structure to digraph as long as it makes sense. This will allow a tag have more than one parents, something like multiple inheritance in some OOP languages. Obviously the gmail’s tag structure is a special case of our structure when all labels are the roots(i.e. those having no sublabels).
Introduce weight of importance, emergency and popularity for each tag so that tags are sortable by any of these respects. Gmail’s star label can serve as this purpose, but it’s too coarse-grained. The popularity weight of a tag can be chosen to be auto-incremented by each visit of the tag, which ensures the most frequently used tags are always on the top. Besides, tags can be sorted by most recent visited time. Consequently, users will have more confidence that documents they really care are available to fetch, and accessing any interesting, active and important items in the system is just a piece of cake.
Introduce main label, i.e. one of an item’s labels can be specified as the main label. In this sense, the traditional tree structure can be viewed as a special case of our structure: any folder name is exactly a label name (There is one subtle difference, though: unlike label names, same folder names in different path wouldn’t clash). If the main label’s correlativity is 1, other labels’ should be between 0 and 1. This provides extra search and sort criteria.
Introduce alias tag. Tags are allowed to have more than one names, these names can be abbreviations, synonyms, or even in different languages. Furthermore, alias can be more powerful: users may define a label as the logical combination of existing labels. For example, one can define “myPrograms” as “‘my documents’ and ‘programs’”, define “entertainment” as “sports or novel or movie” etc.
Introduce thread. Users can create thread that link related message items. Gmail has conversation, but it doesn’t allow users to union mails by themselves. The thread is good for follow-ups and different document revisions. This aggregation makes information system more compact and coherent.

5. Conclusion

To locate an information item, users need click folders to expand in a hierarchical system, while they need click labels to filter in a tag system. We don’t mention search because search is slow and information content may be in binary form. The tag structure is conceivably a better solution, but it still has shortcomings. To further facilitate information retrieval, we’ve proposed a weighted diagraph tag structure, which is an improved tag structure integrating advantages of tree structure. An information system featuring this structure should be more accessible and enjoyable, and its users could be like pisciculturists, no matter how many fishes they have thrown into the ponds, any fish they desire will swim to them with waggly tail upon a single whistle.