Sep 7, 2009 - 八月所读书目

Comments

编程

Software Tools in Pascal

是 Software Tools 的 Pascal 版本,除了编程语言不一样以外,其他都一样

UNIX for FORTRAN Programmers

工作可能需要, 每天翻几页

Artificial intelligence with Common Lisp: fundamentals of symbolic and numeric processing

为了写最近的几篇番外篇,把这本书从头到尾翻了一遍。

The Art of UNIX programming 第2遍

好书,值得每年读一遍

**开始读但是还没看完的

**

[

TAOCP Vol4 F1, Binary Decision Diagram](http://www.amazon.com/Art-Computer-Programming-Fascicle-Techniques/dp/0321580508/ref=pd_sim_b_4)

想研究一下 BDD, Knuth 大神的风趣和平实依旧。

Submodular Functions and Optimization

作研究用的

**其他看得差不多的闲书

**

A People’s History of the Supreme Court

一本讲最高法院和美国历史的书,角度非常接近群众,而不是帝王将相传,很推荐。

Everyday American History

一本搞笑的讲美国历史的书,搞笑之余学到了很多以前不知道的美国历史。 和上面的书对照着看,对于美国早期历史更加明白了。

Understanding Human Communication

一本大学教科书,旧书摊上几毛钱淘的。 看了之后对人际交往和对话的理解立即上了一个台阶,很推荐给自认为“情商”不高的老师们。 我看了之后说话就觉得有方法多了。

Games People Play: The Psychology of Human Relationships

也是旧书摊上淘宝淘到的,是一本 60 年代的畅销书,算是我之前提到的 Freud 和 Jung 的精神分析的后续作品,据说是当时很划时代的作品。

The Seven Principles for Making Marriage Work: A Practical Guide from the Country’s Foremost Relationship Expert

也是旧书摊上的。 要结婚的人了,看看这个估计对将来有好处。

Sep 3, 2009 - 《小小鸟》书外的故事

Comments

这是一篇关于《我是一只 IT 小小鸟》的书背后的故事

霍炬

2007年冬天的,圣诞节,我从美国飞到北京,航班延误了8个小时,等我到北京的时候,已经是凌晨一点多了。我在机场给霍炬打了个电话,一个小时之后,我第一次见到了这个传说中的很义气的哥们,睡他们家客厅。2009 年夏天,敏感词那一天,在他的婚礼上,几乎有7,8个人都提到“第一次到北京就是睡在霍炬家客厅”。 霍炬就是这样一个人际关系的中心结点,三教九流的人他都认识,所以只要认识霍炬,就可以认识很多有趣的人。比如,我就认识了余晟,戴飞等一群人,其中有一个和这篇文章有关的,就是博文视点的周筠老师。

周筠

其实我连周筠老师面都没有见过,但是可以从各个侧面体会到她的人格魅力。 记得我写的文章第一稿交上去,周筠老师就大大的夸奖我错字很少。 我是羞愧难当的。我写中文文章有两个毛病: 老用英文标点;的地得不分。 周筠老师倒没责怪我,还夸了我一顿。 这以后,我每次修改文章的时候,都小心翼翼,害怕把当时的美好形象给破坏了:)

刘未鹏

那个冬天,我也顺便去了一趟南京,见到了当时刚刚开始做 TopLanguage 论坛的刘未鹏师兄。 我们在南大旁边的一家咖啡馆聊了很多。 当年刘师兄满腹的书积累的功底已经开始显山露水,和他说话我已经感觉是和阅历比我大好几岁的人说话,虽然我们年龄上几乎没有区别。 这两年,我就看他的豆瓣的读过的书单一天一天的往上加。 从两年前写了著名的 “我们都是信息时代的远古人” 开始,转型到专门写学习方法和认知科学的内容,从此一发不可收拾,成了很多我周围认识的人必看的博客。

西乔

西乔是霍炬的夫人。 我是见证了他们从开始到结婚的几个关键时刻的。 她现在给《程序员》杂志画漫画。 这次小小鸟书里面我的那篇文章前面的一个兔子洞的插图,画得很有灵气,就是西乔同学亲自绘制的。 她是在去香港的飞机起飞之前4个小时的时候赶工完成的。

许莹编辑

许莹编辑是专门负责修改润色我文章的编辑,也是一直负责和我联系所有的事情的编辑。 在北京的时候和她见过一面。 她做事很认真,我文章里面的错别字,不优雅的语法等等,都是她负责改正的。 最后书里的稿子和我博客上的稿子有比较多的区别,很多是许莹编辑的功劳,周筠老师也亲自操刀修改了一些。

硬币的反面

文章贴到 TL 的时候,就有读者说我的这篇光写了光鲜的一面,没写失败的一面。 其实我只不过才二十几岁的人而已,哪有什么巨大的失败呢,即使是一些不顺意的事情,过去之后都觉得不过如此,因此觉得很琐碎,不愿意花笔墨提了。不过如果非要写的话,我简略的补充两个吧。 第一个是高中,我花了很多的精力去准备计算机竞赛和数学竞赛,结果高二都没得到任何奖;我高三的水平和高二区别并不大,却一下子都得了奖。可以想象,我的高二到高三那段日子是极其苦闷的。 这种苦闷,和在单人牢房里的人的心境其实并无区别,而不亲自体会过的人是不知道的。 好在当时我有话就写在日记上,调节自己的心理状态,慢慢也就熬过来了。还有就是大学的数学建模竞赛了。 所有我认识的同学都认为我肯定会得奖的,偏偏就没有。 当时也是意难平,几个月过去之后也就毫无所谓了。 这两个硬币的反面,尤其是第一个,让我较早的就知道,没必要把所谓的”失败”看那么重,说不定几个月之后你当时苦苦追求的东西回头看来也是若有若无的东西而已,所以不要太执着什么成功失败。 如果这些所谓的失败让我学会了什么,我觉得就这个。 至于勤奋啊,专注啊这些,其实何必要失败教会你呢,只要勤奋一个月就知道勤奋的好处了,远不需要失败来刺激。

推广

因为我也参与了,所以也就厚颜无耻的鼓励大家去买这本书了 :) 人的经历本身不见得能够完全复制,但是这本书可以作为一手的资料,作为一种好的读品来消费。 我们这些作者的美好愿望是,写下最真实的经历,或许这些经历和感想能够帮后人吧。但是怎么读,读出什么,也就是看各人了。

另外,按照稿酬分配方案,我应该会拿到大约 6% 左右的稿酬。 我能拿到的这笔钱,会捐献给 OCEF(海外中国教育基金会)。 这个基金会的好处是,可以保证每笔钱都交给贫困的学生,然后把有着学生歪歪扭扭签字的领取资助的名单交给捐助人,有些捐助人甚至可以和学生直接通信询问情况,所以,最多只有 0% 的捐款会流向贵国政府。 我平均每年给这个基金会捐100美元的样子,今年因为经济危机的影响,前些天刚刚收到他们的邮件,说今年捐款下降,可能有孩子要被义务辍学。因此,我就拿着帮助贫困小朋友的高尚旗号,为这本书推广推广,恳请广大觉得这本书不错的朋友掏掏钱包。 我们都是有能力读书的人,但还有很多没能力读书的小朋友。或者你可以直接通过 OCEF 资助他们,不买这本书也成,就是出版社和周筠老师会比较伤心。不论买与不买,资助一下别人总是功德无量的,所以原谅我在这里唠唠叨叨的给大家说这些。

OCEF 的网址是:  http://www.ocef.org/newocef/en/

我已经和这个基金会打了好几次交道了,收到过地址姓名日期详细的受资助人名单 。他们非常值得信赖。

杂七杂八的堆一块儿不成文章了,对这本书感兴趣的国内读者留意各大书店的书架吧。

Aug 31, 2009 - 编程珠玑番外篇-H. 高级语言怎么来的-4

Comments

LISP 语言是怎么来的–LISP 和 AI 的青梅竹马 A

LISP 语言的历史和一些番外的八卦和有趣的逸事,其实值得花一本书讲。 我打算用三篇文章扼要的介绍一下 LISP 的早期历史。 讲 LISP, 躲不过要讲 AI (人工智能)的,所以干脆我就先八卦八卦他们的青梅竹马好了。

翻开任何一本介绍各种编程语言的书,都会毫无惊奇的发现,每每说到 LISP, 通常的话就是”LISP 是适合人工智能(AI)的语言”。 我不知道读者读到这句话的时候是怎么理解的,但是我刚上大学的时候,自以为懂了一点 LISP 和一点人工智能的时候, 猛然看到这句话, 打死我也不觉得”适合”。 即使后来我看了 SICP 很多遍, 也难以想象为什么它就 “适合” 了, 难道 LISP 真的能做 C 不能做的事情么? 难道仅仅是因为 John McCarthy 这样的神人既是 AI 之父, 又是 LISP 之父, 所以 AI 和 LISP 兄妹两个就一定是很般配? 计算机科学家又不是上帝,创造个亚当夏娃让他们没事很般配干啥? 既然本是同根生这样的说法是不能让人信服的, 那么到底这句话的依据在哪里呢? 我也是后来看 AI 文献, 看当年的人工智能的研究情况,再结合当年人工智能研究的指导思想, 当年的研究者可用的语言等历史背景,才完全理解“适合” 这两个自的。 所以,这篇既是八卦,也是我的心得笔记。我们一起穿越到 LISP 和 AI 的童年时代。 虽然他们现在看上去没什么紧密联系, 他们小时候真的是青梅竹马的亲密玩伴呢!

让机器拥有智能, 是人长久的梦想, 因为这样机器就可以聪明的替代人类完成一些任务。 二战中高速电子计算机的出现使得这个梦想更加近了一步。二战后,计算机也不被完全军用了,精英科学家也不要继续制造原子弹了,所以, 一下子既有资源也有大脑来研究 “智能机器”这种神奇的东西了。 我们可以随便举出当年研究繁盛的例子: 维纳在 1948 年发表了<控制论>, 副标题叫做 <动物和机器的控制和通信>,  其中讲了生物和机器的反馈,讲了脑的行为。 创立信息论的大师香农在 1949 年提出了可以下棋的机器,也就是面向特定领域的智能机器。同时,1949年, 加拿大著名的神经科学家 Donald Hebb 发表了“行为的组织”,开创了神经网络的研究;  图灵在 1950 年发表了著名的题为“计算的机器和智能”的文章,提出了著名的图灵测试。如此多的学科被创立,如此多的学科创始人在关心智能机器, 可见当时的确是这方面研究的黄金时期。

二战结束十年后, 也就是 1956 年, 研究智能机器的这些研究者, 都隐隐觉得自己研究的东西是一个新玩意,虽然和数学,生物,电子都有关系, 但和传统的数学,生物,电子或者脑科学都不一样, 因此,另立一个新招牌成了一个必然的趋势。John McCarthy 同学就趁着 1956 年的这个暑假, 在 Dortmouth 大学(当年也是美国计算机科学发展的圣地之一, 比如说, 它是 BASIC 语言发源地), 和香农,Minsky 等其他人(这帮人当年还都是年轻人),一起开了个会, 提出了一个很酷的词, 叫做 Artificial Intelligence, 算是人工智能这个学科正式成立。  因为 AI 是研究智能的机器, 学科一成立, 就必然有两个重要的问题要回答, 一是你怎么表示这个世界,二是计算机怎么能基于这个世界的知识得出智能。 第一点用行话说就是”知识表示”的模型, 第二点用行话说就是“智能的计算模型”。 别看这两个问题的不起眼, 就因为当时的研究者对两个看上去很细微的问题的回答, 直接造就了 LISP 和 AI 的一段情缘。

我们各表一支。 先说怎么表示知识的问题。 AI 研究和普通的编程不一样的地方在于, AI 的输入数据通常非常多样化,而且没有固定格式。 比如一道要求解的数学题,一段要翻译成中文的英文,一个待解的 sodoku 谜题,或者一个待识别的人脸图片。 所有的这些, 都需要先通过一个叫做“知识表示”的学科,表达成计算机能够处理的数据格式。自然,计算机科学家想用一种统一的数据格式表示需要处理多种多样的现实对象, 这样, 就自然的要求设计一个强大的,灵活的数据格式。 这个数据格式,就是链表。

这里我就不自量力的凭我有限的学识, 追寻一下为啥链表正好成为理想的数据结构的逻辑线。我想,读过 SICP 的读者应该对链表的灵活性深有感触。为了分析链表的长处,我们不妨把他和同时代的其他数据结构来做一比较。 如我在前面的一个系列所说,当时的数据结构很有限,所以我们不妨比较一下链表和同时代的另一个最广泛使用的数据结构-数组-的优劣。 我们都知道,数组和链表都是线性数据结构,两者各有千秋,而 FORTRAN 基本上是围绕数组建立的,LISP 则是围绕链表实现的。通过研究下棋,几何题等 AI 问题的表示,我们的读者不难发现, AI 研究关心于符号和逻辑计算远大于数值计算,比如下棋,就很难抽象成一个基于纯数字的计算问题。 这样,只能存数字的数组就显得不适合。 当然我们可以把数组扩展一下,让这些数组元素也可以存符号。不过即使这样,数组也不能做到存储不同结构的数据。 比方说棋类中,车马炮各有各自的规则,存储这些规则需要的结构和单元大小都不一样,所以我们需要一个存储异构数据单元的模块,而不是让每个单元格的结构一样。 加上在AI 中,一些数据需要随时增加和修改的。 比如国际象棋里,兵第一步能走两步,到底部又能变成皇后等等,这就需要兵的规则能够随时修改,增加,删除和改变。 其他问题也有类似的要求,所有的这些,都需要放开数组维度大小一样的约束,允许动态增加和减少某一维度的大小,或者动态高效的增加删除数组元素。 而一旦放开了单元格要同构和能随时增加和删除这样两个约束,数组其实就不再是数组了,因为随机访问的特性基本上就丢失了,数组就自然的变成了链表,要用链表的实现。

所以,用链表而不是数组来作为人工智能的统一的数据结构,固然有天才的灵机一动,也有现实需求的影响。当然,值得一提的是,在 Common LISP 这样一个更加面向实践而不是科学研究是 LISP 版本中,数组又作为链表的补充,成了基本的数据结构,而 Common LISP,也就能做图像处理等和矩阵打交道的事情。这个事实更加说明,用什么样的数据结构作为基本单元,都是由现实需求推动的。

当然,科学家光证明了列表能表示这些现实世界的问题还不够, 还要能证明或者验证额外的两点才行, 第一点是列表表示能够充分的表示所有的人工智能问题,即列表结构的充分性。 只有证明了这一点,我们才敢放心大胆的用链表,而不会担心突然跳出一个问题链表表达不了;第二是人工智能的确能够通过对列表的某种处理方法获得,而不会担心突然跳出一个人工智能问题,用现有的对链表的处理方法根本没法实现。只有这两个问题的回答是肯定的时候,列表处理才会成为人工智能的一部分。

对于这两个问题,其实都并没有一个确定的答案,而只是科学家的猜想,或者说是一种大家普遍接受的研究范式(paradigm)。 在 1976 年, 当年构想 IPL, 也就是 LISP 前身的两位神人 Alan Newell 和 Herbert Simon ,终于以回忆历史的方式写了一篇文章。 在这篇文章中,他们哲学般的把当时的这个范式概括为: 一个物理符号系统对于一般智能行为是既充分又必要的( A physical symbol system has the necessary and sufficient means for general intelligence action)。 用大白话说就是,“智能必须依赖于某种符号演算系统,且基于符号演算系统也能够衍生出智能”。 在实践中,如果你承认这个猜想,或者说这个范式,那你就承认了可以用符号演算来实现 AI。 于是,这个猜想就让当时几乎所有的研究者,把宝押在了实现一个通用的符号演算系统上,因为假如我们制造出一个通用的基于符号演算的系统,我们就能用这个系统实现智能。

上面我们说过, 链表的强大的表达能力对于这个符号演算系统来讲是绰绰有余的了,所以我们只要关心如何实现符号演算,因为假如上面的猜想是对的,且链表已经能够表示所有的符号, 那么我们的全部问题就变成了如何去构建这样的符号演算系统。后面我们可以看到, LISP 通过函数式编程来完成了这些演算规则的构建。

这里,需要提请读者注意的是, LISP 的全称是 LISt Processing, 即列表处理,但实际上 LISP 是由两种互相正交的哲学组合形成的, 一个是列表处理,另一个是函数式编程。 虽然在下面以后,我们会介绍 S-Expression 这样美妙的把两者无缝结合在一起的形式,但是为了清晰我们的概念,我要强调一下列表处理和函数式编程是两个正交的部分。实际上,我们完全可以用其他的不是函数的方式构建一个列表处理语言。在历史上,早在 FORTRAN 出现之前,Alan Newell 和 Herbert Simon 就用汇编实现了一个叫 IPL 的语言,而这个 IPL 语言就是面向过程的对列表处理的,而后,McCarthy 一开始也是用一系列的 FORTRAN 子程序来做列表处理的。比如 LISP 里面的 CAR 操作,其全成实际上是 Content of the Address portion of the Register, 顾名思义,寄存器的地址单元内容,也即列表的第一个元素(和C表达数组的方式类似,这里寄存器中存着指向列表第一个元素的指针)。 函数式的却不以列表为基本数据单元的语言也很多,比如 Scala ,就是以对象为基本数据单元。 因此,函数式和列表处理是不一定要互相耦合的。 那么,到底是什么原因使得 LISP 选择函数式,这样的选择又为啥更加适合当时 AI 的研究呢, 我们下节将继续介绍当时 AI 的研究范式,强弱 AI 之间的辩论和函数式编程在当年 AI 研究上的优点。

(待续)

Aug 19, 2009 - 编程珠玑番外篇-G. 程序员心底的小声音

Comments

(“高级语言怎么来的“ 系列仍然有后续,这篇是临时插入)

程序员心底的小声音

编程大约有三个境界,新手,高手,和高不成低不就的中手。这三个境界,大致和王国维先生划定的做学问的三个境界一一对应。 一般来说,如果不经过几十万行的代码的锤炼(衣带渐宽终不悔,为伊消得人憔悴),或者长期在一个高手团队里面打磨切磋,那么无论怎么样的理论熟悉,打字熟练,考试全A,编程起来,都应该算是中手。一个中手如果机缘很好,得到高人亲自指点,则能很快成长为高手,如果没有这样的机缘,那就要在“众里寻她千百度”这个层次苦苦的求索锤炼很久,才能“蓦然回首”。

读书是一种很好弥补没有高手在场的方法,都说书是最好的老师嘛。 可是现实是,高手写给中手的书很少。 在任何行业,适合新手的入门的书很多,适合中手的书就很少。 原因有两个,一来高手极少愿意耐心的的指点成长秘诀,就算写了,也是蜻蜓点水,因为这些经验啊结论啊,都被他们本身提炼成了珠玑,他们觉得最重要的也就是这么寥寥几句,也没有太多的废话好写。 而读者如果没有类似的经历,则看到这些珠玑,只是觉得把玩颇为有趣而已,极少能有同感。 鲜有高手,能把技术书写成散文集,如 Brooks 一样,在《人月神话》中把经验教训和经历背景等一一道来,并且从这些经历中抽出一般性的知识。 所以,高手的风格一般是浮光掠影概括一下大致自己领会到的几个原则和教训。 这些寥寥数语的珠玑,对于其他高手来说一看就懂,但是对于中手来说就很难以理解。 所以很多高手写出来的给中手看的书就曲高和寡。 二来,中手其实水平差异巨大,偏好也各不一样,有的或许根本认识不到自己应该走的成长轨迹,有的认为这些书籍是片面知识,所以把不喜欢的书都给扔垃圾堆了,光捡自己喜欢的书看;有的未必看得上高手的经验,认为高手说的那些自己也早就领悟到了。所以,也不喜欢购买这些书籍。这两个原因,就造成了高手提携中手的书在市场上很少见到。

不过这样的书倒不是没有,比方说在编程领域, 我至少可以推荐四本这类的书,这四本分别是

《Pragmatic Programmer》, 《The Art of UNIX Programming》, 《Elements of Programming Style》 和 《The Productive Programmer》. 这四本书,都是高手所写,都属于高手指导中手的典范。第二第三本我原先都介绍过。 而第四本余晟同学的书评比我写得好几百倍,所以我就以 《Pragmatic Programmer》 为例说明这个问题。

我们前面说了,对于中手,特别是在“寻她千百度”这个层次的中手来说,或许本身已经捡到了一些珠玑,或许对于像 《Pragmatic Programmer》 里面说的那些 Tip,有的是深有同感的。 比如 DRY (Don’t Repeat Yourself 不要重复你自己), 基本上大家都知道,可是在实际中(至少我自己)还是不停的一次一次的犯错误,做事情不符合 DRY 原则(一次一次犯这个错误本身也是一个 DRY 错误, 因为 DRY 原则要求你对于每种错误你只能犯一次)。 读到的时候深有同感, 写代码的时候却忘到 Java 国去了,这还真不是个案,是非常普遍的现象。

能不能让正确的原则指挥正确的行动本身,其实就是区分是否是高手的一个显著标志。 试想,两个都了解 KISS 原则的程序员在一起写代码,高手的代码必然是自然流露出 KISS 的优雅,而中手或许需要旁人提醒和多次重构,才能达到理想的状态。 出现这个问题的原因很明显–中手没有完全内化 KISS 原则,所以尚且不能“运用自如”。 内化是一个非常复杂的认知过程,本身涉及到大脑中 mind set 和 paradigm 的切换, 所以必然不是一个简单的隔夜就能完成的过程,这也就是为啥能够“消得人憔悴”,但是切换一旦完成,实践中就会自然流露出这种新的认识,也就是到了一个新的境界,发现灯火阑珊处。

那么原则和知识的内化这个过程怎么能够加速呢?也就是说,怎么较快的到达高手境界呢? 可以肯定的说,光靠对自己说我“下次一定按照这个原则这样做”是不行的。认知科学认为,频繁的高强度的外部刺激和自主的有意识的反复提醒是加速内化的两个重要方法。 第一个方法需要外部环境的支撑。 试想,如果一个程序员不是天天和复杂文本处理打交道,他必然没有足够外部刺激来熟悉和内化正则表达式; 如果一个程序员不是天天和极度复杂的大项目打交道,用全自动编译环境和自动单元测试也显得无甚必要,所以,除非你正好掉进了一个天天有高强度训练的环境,否则全靠第一点是不可能的。 尤其是自学一门语言和一门技术的程序员,往往在没有高强度训练之前就拿着这些技能投入工作了,因此想成为某方面的高手,只能采取第二条路,就是有意识的强化实践和反复提醒。

《圣经》里有个故事,说一个人在沙漠里,信心丧失的时候,突然听到 “A Still Small Voice” (平静的小声音), 即上帝的启示。这个平静的小声音把他从绝望中拉了回来。 其实对于这个人来说,他本身的实践能力在 “平静的小声音” 出现前后并没有多大的改变,唯一的不同就是他知道该怎么做了。

内化一个知识或者认识的时候所循的路径也是一样的。 我们常常会“忘了”应该怎么正确的做一件事情(这个地方的“忘了”,指我们之前从书中或者其他渠道读到看到了正确的原则或方法,但是在那一刻脑子里压根没考虑这个原则或方法,因为这个原则或方法压根没有亲自实践过,所以根本不是自己的一部分,不属于自己)。 在这个时候, 如果突然有一个平静的小声音跳出来,说,“嘿,你是不是该遵循这个原则,用这个方法?” 无需说,我们对问题的思考就能顿时全面起来, 也会更加深刻的理解原先读到看到的不属于自己的原则和方法。当然,我们更加感兴趣的是,如何能够在身边没有高手和上帝发出这样的平静的小声音的时候,自己发出这样的小声音?

怎么靠自己呢,记得鲁迅小朋友破坏公物在课桌上刻的“早”么?是的,我们需要抽象出一些简单的词句和规则,靠记忆和不断的提醒,小规模的内化这些小声音,让这些简单的小声音能够时刻从大脑里跳到耳边,提醒自己。 具体来说,在阅读上面的几本书,尤其是阅读 《Pragmatic Programmer》 的时候,如果仅仅是以普通的浏览的方式阅读,就会很简单的陷入 “啊,这个我知道了,啊,那个我了解了,恩,这个以后要注意” 的套路中。 这样的阅读方式,只会强化原有的自己已经知道的部分,而不大可能把“以后要注意” 这部分全部内化。所以,自负的读者读完了之后必然觉得“哈哈,高手不过如此,大部分我也知道嘛”,而不是“是的,我还有不少要注意”。 这两个态度,就把高手和易于满足的中手永恒的隔开了。 我觉得,想要内化这些小声音,还是要靠实践,如果不实践,即使你把这些小声音写在 100 块钱的高档笔记本上也没有用。我个人觉得,理想的阅读状态应该是先大致理解和记住里面的 Tip, 然后每周争取实践 2-3 个 Tip。其实如此做完一圈也就是半年,在这一圈之后就会记住所有的 Tip 的内容,这时候,小声音就成了自己的一部分了。然后在剩下的几年里,只要时时有这些小声音挑出来,告诉你,“要自动频繁的测试”,或者“别手动做繁琐的工作”,你会很快的被强迫转换到高效而优雅的工作状态。 到了那个时候,这些小声音就再也不会跳出来了,因为你早就自然的遵守这些小声音的要求了。

《Pragmatic Programmer》 和 《The Elements of Programming Style》 这些书里面的 Tip 都不是来自上帝的话语,却都是值得随声带着的小声音。 其实只要是处理过实际问题,编过几万行程序,大多程序员都差不多都会有或深刻或浅显的对各个 Tip 都感悟,而且我相信或许对有些 Tip 的认识能比原书的作者还要深刻,这是很正常的。 事实上每一个 Tip 只是一句话而已,对这一句话的理解层次, 则完全不这一句话能够覆盖的。 比如说,一天写了两个 Hello Word 的程序员也会领悟到 DRY, 一个刚刚重构扔掉掉几千行重复代码的程序员也领悟到 DRY, 而这两个 DRY 所在的认识层面, 必然是不一样的。 再好比说我在“编程珠玑番外篇”这个系列里面写的有些文字,看上去很有道理,但我本人对这些文字的认识可能比我的读者要浅, 但是这倒不妨碍引发读者思考。 即使有些牛人觉得上面这几本书的作者在某些原则上的认识不够深刻,或者觉得作者只是在罗列一些小碎片,读这些书,特别是 《Pragmatic Programmer》 这本书的那些小 Tip,依然是有益的, 因为他或许能触发你高于作者的思考,然后在你脑中形成更加圆润的珠玑。而对于像我这样属于中手下游平时又没有大项目训练的人,《Pragmatic Programmer》 这本书,和其他的几本书一起, 实在是很好的“小声音汇编”。

Aug 10, 2009 - 第二批合租

Comments

今天检查了一下合租服务器, 还有很大的空间, 可以再容纳一些独立博客. 正好这几天好几个朋友问我什么时候放出第二批. 所以这次继续放出 10个合租名额.

附上次的六个要求(略有修改)

  1. 原先有网站或者博客在国内(任意 BSP 或者独立博客), 想移民的.

  2. 流量不会超过每月100G

  3. 自己有域名

  4. 我不对非人为原因造成的数据丢失或者连接被重置负责任

  5. 因为服务器在美国, 要遵守美国当地法律. 不许利用互联网煽动颠覆美国国家政权, 推翻美国资本主义制度,或者煽动分裂美国, 破坏美国统一. 不许恶毒攻击美国国家和地方政府领导人, 美国执政党和美国政府, 否则走人.

  6. 服务免费, 但是服务没其他人好. 如果要专业服务, 请访问周曙光或者数字游牧.

这次想合租的同学, 我有三个简单的额外要求 (基于第一次的经验):

  1. 我没有太多时间精力帮你解决技术问题, 有问题你只能自己看文档.

  2. 只限于搭建个人博客, 博客仅限用 WordPress 程序的(服务商只给了我WP程序), 如果自己装其他程序也可以, 但一定要提前告诉我一下.

  3. 遵守版权法, 不上传不符合美国法律的东西. 如果有这样的内容, 这个帐号有可能被服务商停掉.

(另外: 原来给我发邮件或者留言要求第二批合租的我刚才都发邮件回复了, 如果你还没有收到, 尽快给我发信)


(Update: 截至到目前,名额已经达到14个,我会一一用邮件确认,看上去14个都符合条件,所以只好请大家不要继续报名了)