January 2009 Archives

尽量减少阅读科技资料，把重点放在人文、哲学方面的文章上。

理由：训练思维。语言上的逻辑思维和公式上的逻辑思维有区别。

This article is my first assignment of "Computer Ethics". The assignment asked us to read Bill Joy's article "Why the future doesn't need us" and write a summary. Also, our opinion of this article is also required. The following word is my work.

In this article, Bill Joy discussed the negative possibilities of the improvement of the genetics, nanotechnology, and robotics (GNR) technologies.

The speed of computer processor has growth exponentially in a few last years, and the developing new technologies will keep the growth speed or even exceed it. The enormous computing power may make the intelligent robot in scientific fiction possible. And it may eventually cause the mergence of human being and robots or even the replacement for human being.

The same dangerous also exists in genetics and nanotechnology areas. With the development of nanotechnology already made nanoscale molecular electronics possible. And nanotechnology will be greatly growth in the next 20 years. But as Bill Joy said, “it is far easier to create destructive uses for nanotechnology than constructive ones”. And the result if we don’t consider about the ethics issue of nanotechnology, is “the risk that we might destroy the biosphere on which all life depends”.

The improvement of genetic technology had already bring us some ethics issue. As Bill Joy said, “the general public is aware of, and uneasy about, genetically modified foods, and seems to be rejecting the notion that such foods should be permitted to be unlabeled”. Bill Joy’s concern was genetic technology may give the power to bad person and help them to do some really destructive act, such as creating a “White Plague”.

What makes Bill Joy even worrier is the price of using GNR technologies to do bad things is much cheaper than in the NBC era. While building mass destruction weapon with NBC technology need rare raw materials and highly protected information with large-scale activities, the abuse of GNR technologies is way easy. According to Bill Joy, “They will not require large facilities or rare raw materials. Knowledge alone will enable the use of them”.

Bill Joy’s article is really thought-provoking. Undoubtedly, I think, the improvement of GNR technologies will change our life hugely. Genetic technology will cure disease which are not able to cure today. Nanotechnology will give us some industrial materials. Robotics technology will greatly free human being from work. The negative effect is also remarkable. Each of these is able to bring human being to extinction. Bill Joy was right on this part.

But some of Bill Joy’s grounds of argument is not very adequate. Also, I doubt whether the future is that pessimistic if we don’t control the growth of GNR technologies. Firstly, I don’t think the GNR technologies abuse can be made by only knowledge. Just like we need tools to build mass destructive weapon with NBC technology, we also need corresponding tools for applying GNR knowledge. Especially in genetic and nano-tech area, high-preciseness tools are required.

Second, I’m not sure if the future will be so pessimistic if we care less about the ethics in such area. Bill Joy said that people may merge with robots and become Borg-like new species. The question is, who knows if that’s human’s destiny of evolution?

On the just finished "Professional Practice in Computer Science" class, my instructor shared us a better example of the difference between ethics and moral.

On the yesterday's CBC News, he heard that a Manitoba lesbian couple was rejected by a family doctor from Egypt for religious reasons. This matter happens in Winnipeg, the city I'm living in. It is so near for me to feel such a news.

Morally, the Egyptian family doctor can't accept a lesbian couple. But as a doctor, she has obligation to serve patients. The same-sex-marriage was considered legal since September 16, 2004, and the couple was legally married. A doctor don't have excuse to refuse such a couple under the law and ethics.

I've mentioned a similar example of ethics and moral impact in a previous post. Should a Catholic doctor do an abortion operation for a unmarried girl? When I wrote that post, I was pretty clear that the answer was "yes". If I were the doctor, I could easily put my moral thought aside and do the operation.

But I found the situation is more complex in the new case. If I were the family doctor, I won't know if I can serve the lesbian couple normally. The big difference between the two case is, abortion operation is just once, while serve a lesbian couple is a long time job. As an Egyptian, I feel very disgusted to get in touch with gay or lesbian. That will make me unwell during the work. It's really an obvious dilemma.

Fortunately, doctors have their ethics to follow. Sometimes it much easier if there is rule to follow. On other hand, computer workers don't have their ethics. Not only a policy vacuum, there's a definition vacuum about "What is computer ethics". Hard work to make the law or rules to let computer workers to follow.

What's worse, there are extremely few people to think about it.

As I told you before, for finishing my assignment of the "Computer Ethics" course, I'm keeping reading and thinking about Bill Joy's article "Why the future doesn't need us". This article is really thought-provoking. Today, I get confusing about how critical is the spreading of genetics, nanotechnology, and robotics (GNR).

Obviously, GNR will bring us some change to our life. Joy believed the negative effect of GNR is way greater than positive. I don't think he is wrong. But I doubt the degree.

Joy discussed the serious degree of GNR by comparing it with NBC (nuclear, biological, and chemical) technologies. Here are how he said about the comparison,

What was different in the 20th century? Certainly, the technologies underlying the weapons of mass destruction (WMD) - nuclear, biological, and chemical (NBC) - were powerful, and the weapons an enormous threat. But building nuclear weapons required, at least for a time, access to both rare - indeed, effectively unavailable - raw materials and highly protected information; biological and chemical weapons programs also tended to require large-scale activities.

The 21st-century technologies - genetics, nanotechnology, and robotics (GNR) - are so powerful that they can spawn whole new classes of accidents and abuses. Most dangerously, for the first time, these accidents and abuses are widely within the reach of individuals or small groups. They will not require large facilities or rare raw materials. Knowledge alone will enable the use of them.

What is doubtful for me is, is knowledge enough for making such destructive thing by GNR? Building NBC weapons need rare raw materials and tools, so it is relatively safer than GNR. But don't we need some highly precise tools to operate GNR stuffs in a microscopic view? One who has GNR knowledge may be able to build such tool, just as one who has NBC knowledge can build tool for implement nuclear bomb. But that's extremely hard.

So, my conclusion is, a thought that GNR is very dangerous just because it can make destructive affect when people only have such knowledge is over worrying.

Maybe that made me happier about human's future.

This post a a Chinese translation of Guido van Rossums’s article “Personal History - part 2, CNRI and beyond” on his blog named “The History of Python”.

原文地址：http://python-history.blogspot.com/2009/01/personal-history-part-2-cnri-and-beyond.html

Python研讨会（参看之前的文章）的结果是一份在CNRI（the Corporation for National Research Initiatives，国家研究研发公司）的工作。CNRI是位于维珍尼亚州来斯顿的一个非盈利的研究实验室。我在1995年四月份加入。CNRI的主管Bob Kahn是第一位向我指出Python与Lisp之间共同点的人，尽管两者从外表（语法）上完全不同。在CNRI，DARPA授权的移动媒介研究间接的给Python工作提供经济支持。尽管有DARPA支持的项目在使用Python，但没有太多对编程语言本身的直接支持。

在CNRI，我领导并帮助雇佣了一个小的开发小组来用纯的Python语言开发一个移动媒介系统。最初的小组成员是Roger Masse和Barry Warsaw，他们在NIST的Python研讨会上指出Python的bug。另外，我们还雇佣了Python社区的成员Ken Manheimer和Fred Drake。MIT的毕业生Jeremy Hylton原本是被雇佣来做文本检索工作的，也加入了团队。最初团队由Ted Strollo和Al Vezza管理。

这个团队帮助我创建和管理了另外的Python社区的基础，比如python.org站点，CVS服务器和不同的Python特殊兴趣小组的邮件列表。Python的1.3到1.6版本都出自CNRI。在很多年里Python 1.5.2版本是最流行和最稳定的版本。

GNU mailman也在这里诞生：我们最早用一个叫Majordomo的Perl工具，但Ken Manheimer发现它不容易管理，于是就找一个Python方案。他找到John Viega写的一些东西并接手管理。当Ken离开CNRI去了Digital Creations，Barry Warsaw接手了它，并说服了自由软件基金会（Free Software Foundation）采用它作为官方的邮件列表工具。因此Barry把它按照GPL（GNU Public Licence）许可发行。

Python研讨会仍然继续着。开始是一年两次，但由于工作量呈指数性的增长，它编程了年会。最初这些研讨会是自愿组织的，就像NIST（第一次），USGS（第二次和第三次），以及LLNL（第四次，并且开始了年度系列）。最终CNRI接手了组织任务，后来（和WWW及IETF会议一起）这些成为了Fortec商业行为的副产品。很快的参与人数达到了数百人。当我离开CNRI后一段时间后Fortec逐渐消失，全球Python会议成为了O'Reilly开源会议（OSCON）的一部分，但同时Python软件基金会（Python Software Foundation，见下）开始了一个名为PyCon的新的草根研讨会。

我们也在CNRI建立了第一个Python周边协会。为了回应Mike McLay和Paul Everitt创建一个后来结束在法规起草流沙中的“Python基金会”的努力，Bob Kahn出钱成立了“Python软件行动”（Python Software Activity），它是一个合法的独立实体，只是一个简单的工作在CNRI（非盈利）法律保护伞下的小组。PSA成功的聚集起大量的Python用户，但它缺乏独立性限制了它的效率。

CNRI也用DARPA的钱来资助JPython（以后会简单介绍Jpython）。JPython是一个在Java上的Python实现。Jim Hugunin最初在做MIT毕业设计时创立了JPython。他后来说服CNRI雇佣他来完成这项工作（或者是CNRI说服Jim加盟──事情发生在我度假的时候）。当Jim离开CNRI后不到两年加入Xerox PARC时，Barry Warsaw继续了JPython的开发。（很久以后，Jim也是IronPython的作者。IronPython是微软.NET平台上的Python。Jim也写了Numeric Python的第一个版本）。

CNRI的其它项目也开始使用Python。许多新的Python核心开发者都来自于此。特别是在MEMS Exchange项目工作的Andrew Kuchling、Neil Schemenauer和Greg Ward。（Andrew甚至在来CNRI之前就为Python做贡献了；他的第一个主要的项目是Python加密工具箱，一个第三方的给Python用户提供许多基础加密算法的库）。

在Python成功的过程中，CNRI尝试着提出一个更直接的而不是通过DARPA研究授权的资助Python开发的方式。我们建立了Python集团，就像X集团那样，最小加盟费是20000美元。然而，除了一个在惠普的小组，我们没有获得更多的牵引力，最终由于缺乏活力，集团倒闭了。另一项寻找资金的尝试接受DARPA资助的是全民编程（Computer Programming for Everybody，CP4E）。然而，它的资金不足以支持整个团队，而且它是一个让钱实际流动数年的完全的老男孩网络。那里没有我感兴趣的，我于是开始寻找新的机会。

最终在2000年dot com的极速发展还没有破灭的时候，我和CNRI Python团队的另外的三名成员（Barry Warsaw、Jeremy Hylton和Fred Drake）被说服加入了BeOpen.com，一个加利福尼亚刚起步的招聘开源开发者的公司。一个Python社区主要成员Tim Peters，也加入了。

如预期的那样，在跳槽到BeOpen.com后，出现了关于未来Python所有权的难题。CNRI坚持修更改许可协议并请求我们按照新的许可协议发布Python 1.6版本。我还在CWI时使用的旧许可协议有一个MIT许可协议版本。CNRI创立的许可协议对那份许可协议作了轻微的修改，主要是加上一句话说明CNRI放弃多数责任。在CNRI的律师修改后的1.6许可协议变的又长又罗唆。

我们和自由软件基金会的Richard Stallman及Eben Moglen有了几次关于这份新许可协议的一些部分的讨论。他们担心它将不与GPL兼容，因而威胁到GNU mailman的发展，因为mailman现在已经成了FSF的重要工具。在Eric Raymond的帮助下，CNRI Python许可协议被修改到FSF和CNRI双方都满意的程度，但最后的语句不容易被理解。关于它我唯一可以说出的好的方面是（再次感谢Eric Raymond的帮助）它是开放源代码首创的完全开源的许可协议。为反应两个后继产品的所有权变更，只对许可协议的文本做出了轻微的更改，先是BeOpen.com，然后是Python软件基金会，但事实上CNRI律师的手工工作仍然成立。

就像那时候的许多开始的公司一样，BeOpen.com的商业计划华丽的失败了。它留下了一大笔债，一些人严肃的怀疑一些公司长官的参与角色，和我的团队外的一些非常失望的开发者。

我的团队的幸运年，现在的PythonLabs，相当受欢迎。我们被数字创新公司（Digital Creations），最早的使用Python的公司之一，雇佣成为一个单元（Ken Manheimer在几年之前就去了那里）。数字创新很快把它们的名字改成他们的主要开源产品，Zope网络内容管理系统的名字，成了Zope Corporation。Zope的创始人Paul Everitt和Rob Page，以及他们的CTO，Jim Fulton，参加过NIST在1994年举办的早期的Python研讨会。

历史可以容易的走向非常不同的方向：除了数字创新公司，我们也考虑过VA Linux和ActiveState的工作。当时VA Linux在股票市场上是一颗升起的新星（曾经让Eric Raymond名义上成为了数百万富翁），然后戏剧性的倒闭了。回看过去我想如果ActiveState不位于加拿大的话，它不会是一个不好的选择，除了它的创始人Dick Hardt的饱受争议的个性。

我们在2001年创立了Python软件基金会，它是一个非盈利性的组织。它的初期成员是当时Python的主要贡献者。Eric Raymond是创立成员之一。我以后会再写这一段历史。

For finishing my assignment of the "computer ethics" course, I'm reading Bill Joy's great article "Why the future doesn't need us". In this article, Joy talked about a situation that, human beings may be displaced by robotics, along with the growth of GNR (genetics, nanotechnology, and robotics) technologies.

In the section of "The Short Run (Early 2000s), by describing how the placental species from North America displaced and eliminated the marsupials in South America after the Panama isthmus rose ten million years ago, Moravec came to the conclusion that the robots would eventually succeed us and humans clearly faced extinction.

At the very moment when I read this, the idea which the title of this post said slipped into my mind.

It is a fact that human beings is evolving on and on. Even before our ancestors said "goodbye" to their orangutan friend and became human, the evolution didn't ever stopped. During the evolution, livings change from dinosaur to human. And where are those dinosaurs? Died.

Think about a question. When the dinosaurs were going to be displaced by some higher-class living, were they willing to be extinction? I don't think so. If they could think, or we could know what they thought at that time, we may be told that they had thought about "why the future doesn't need us" and wanted to find out a way to stop the displacement happening. And we are about doing the same thing at the the very present days.

No matter we are right or wrong, will we get the same ending as dinosaur have? The dinosaurs are all dead. Is that means human beings will be also dead and give the new era to robots? That could happen.

The above words are what I was thinking about 10 minutes before.

英语应该怎样学，如何实践，通过最近的阅读，我有了新的理解。

依然按照传统的听、说、读、写来把整个英语时间划分成四个方面。我现在的理解是，国内学习英语应当把重心放在“说”和“读”上。正好两方面分别处于输出信息和接受信息的角度上。

先说“说”。主要是基于国内有名的“哑巴英语”的考虑，许多人无法有效的用嘴巴来有效的表达自己。我在加拿大也见过有的人，即使后来通过努力，能够有足够的逻辑来用英语表示思想的时候，他的发音依然令人发指。有的人认为只要能做到有效的沟通，不必在意发音是否标准。这一点我自己不赞同，但找不到反驳的理由，不做评论。

我仍然清除的记得在国内和外教讨论的时候，他怎么也听不懂我说的“nerd”这个词。我给他拼写出来后，他才明白我说的是什么。他说我的发音不标准。因为语系不同，英文里有的发音，中文里完全没有，相反也是同样。这样导致经常双发听对方讲自己的语言感觉很别扭。那天，老外纠正了我半天的发音，反复让我发“nerd”这个词，不下30遍。我在2007年4月份写过文章讲述这件事。而我到这里后，也和老外交流过，每当想到老外有可能对我发音的感觉就像我们感觉老外一样，我就感到脸红。

当然，既然练习“读”，就应该争取把音发标准，这离不开“听”的帮助。但我现在感觉不用花费太大的力气去练习听力，如果“说”的部分过关了，听力应该不成问题。我们决不会听不懂自己说的话，英语也应该是这个道理。从我在加拿大的经历来看，我到了英文环境里进步最大的就是听力。这就是“耳濡目染”的作用。

“读”是我最近的最新感受。“读”一直是我四项中最薄弱的一项。虽然到了加拿大两年，但我仍然不习惯阅读英文文章。每当需要阅读英文的时候，我一定要正襟危坐，全神贯注，否则一不留神思维就跑了。相反中文资料我读的特别多，不仅速度快，理解也不成问题，印象也挺深刻，经常见到比较好的句子，多看两遍就基本上会背了，虽然不一定一字不差，但用在写作里当引用是没有问题的。而我在不能全神贯注的时候，只能做到“读”，但做不到“理解”。但正如李笑来说的：

“阅读理解”本质上是两个过程的叠加：“输入”与“理解”。“输入”有很多种方法，“理解”是需要积累才能获得的能力。要能够理解已输入的信息，才能够真正做到“阅读理解”。

而我的情况是可以“朗读”。过去在课上老师让读课文我从来不怕，但读完了文章，总结一下意思，完全没有头绪。

这学期我有一门专业课名字叫“Professional Practice in Computer Science”。本来我以为内容是编程之类的联系，结果上了课后才知道讲的是关于“Computer Ethics（计算机伦理）”方面的内容。我最近写的一些英文post就是关于“Computer Ethics”方面的思考。这种类似“哲学”方面的课，老师就会给我们布置阅读的作业。第一次作业老师给我们布置了几篇文章，我打印出来后发现有一厘米多厚。结果只有硬着头皮读。

我之前毕竟上过阅读课，之前上写作课写论文的时候也通读过一小本天主教方面的书，专心致志的情况下还是有一定基础的。读的过程中我发现，我是由于平时阅读太少而导致思维迟钝的。通过阅读的量的增加，我的阅读速度已经不知不觉的提升了不少。当然这次的“阅读”是包括了“理解”的。而开始的时候为了克服读完后没有印象的问题，每读一句话就要思考一下，读完一段一定在旁边注明意思。但到后来不用总结每段的段意，文章的意思也能串起来了。

我在阅读中间休息的时候，按照李笑来的思路，对比我中文阅读和英文阅读的差异。仔细回忆了一下我的阅读历史：小学阶段仅限于课文，那时候还不知道什么是小说；从初中开始才真正开启了阅读的大门。那时候的阅读可以用“如饥似渴”来形容，无聊的时候我会一页一页的翻《思想政治》课本，把里面小字写的故事实例都读完。小说之类的就更不用说了。然后不知不觉间，我读书的效率就相当高了。

对比我的英文阅读水平，我觉得我的阅读量才刚到小学水平。通过读一些长文，现在估计能到小学高年级水平了。我目前希望的理想状态是：这次作业结束后，继续保持阅读的习惯，坚持一阵子，争取把阅读能力提升到初中水平。

我在这里倒一直不怕写作，可以说写作课是我最喜欢的课程之一。之前还有偿为同学写过paper，虽然同学挑选的题目对我来说有点偏，是关于维他命D的，但我写完后，同学也过关了（同学的语言学校的毕业paper，要求不高，专业的维他命D的论文我肯定搞不定）。

我觉得写作和阅读有差别，因此不需要花太多时间在训练写作上。阅读算是一项技能，需要特殊的训练；但写作算是说话和逻辑的表达，很难做到专项专练。英语写作方面，只要不怕中文写作，再注意一下英语写作中结构的设定之类的细节，基本上就没有问题了。我个人在小学阶段非常害怕写作文。那时交的作文作业基本上是母亲给我打好的草稿，我再抄到本子上。上了初中，肯能由于阅读量加大的关系，我就不害怕作文了，不仅不像小学一样根本不知道有什么好写，反而经常超出老师的字数要求。我的解释是年纪大了后逻辑思维培养了起来，通过阅读的培养学会了语言表述，作文自然不成问题了。我在新东方听了杜昶旭的写作课后，就能拿到托福写作5/6分了。

而我现在就很后悔当年不清楚情况，为什么到了大学后还把阅读水平练在小学等级上。如果当时能明白，能做到相应的训练，现在该多爽啊。不过我的情况还好一点，在大学时读过一些科技画册，关于电子管的发明历史、动物构造之类的，比其他人的情况能稍微好一点。而且我现在觉得阅读课上分析什么教材上的文章纯属浪费时间，直接找篇general文章，10页以上的给学生读去，读完了用英文写报告的效果应该也比精度文章要好。至于该读什么样的文章，我也有点想法，会在另一篇post中讨论。

My instructor assigned me some articles to read and some videos to watch about computer ethics. One of the video is Kevin Kelly on the next 5000 days change of our web at EG 2007 Conference in Los Angeles, California.

At the beginning of Kelly's speech, he said we will have only one machine exists in our world. All of personal devices, such as computer, cell phone, etc., are just the terminals of that machine. The machine is more reliable than we have ever met. It never crash. And I suddenly thought something other than his topic about a never crashing machine.

First, is such a machine able be built? As we known, computers are one of the most complex things in the world. Nobody can build even a cheapest personal computer nowadays himself, even Steve Woz. The reason is the present computers are so different than the computers in the Apple II days. An article named "What Is Computer Ethics?" by James H. Moor also discussed the complexity of computer programs. We know some easy part of a program is perfectly correct. But we can't guarantee the whole program after we assembled each part. That issue of software can also be applied to hardware. Another idea about this is "there doesn't exist a program without bug". So we can simply suppose that we can't build a 100% reliable machine.

So what our goal is to reduce the possibility of the machine crash as hard as we can. How?

You may think a lot of ordinary ideas such as use things like test-driven design, quality control, etc. I can tell you a story of Kai-fu Lee, a vice-president of Google.

According a book named "Follow the Wisdom -- Chinese at Microsoft" by Ling Zhijun, when Kai-fu Lee invented a system that can recognize human's voice and talk with people at Apple Computer in around early 1990s, he was invited to Good Morning America to show his work. That was a big chance to promote Apple's brand. Kai-fu's boss don't want the presentation system crash during the show. So he asked Kai-fu the percentage that the system would be crash. Kai-fu answered 10%. The boss asked him if he can reduce the possibility. Kai-fu said yes.

The boss thought Kai-fu would use lot's of ordinary ways to archive the goal. But Kai-fu used an unordinary way. His method was to use two system. When one system crashed, there was another one. The possibility of one system crash was 10%, and the possibility of two system crash was 10% * 10% = 1%.

We may get some insight from this story. What we want is to build a never crash machine. To achieve that goal is very difficult. So by Kai-fu's idea, how about we just use two machine? For continuing reducing the crash possibility, we simply increase the number of machine.

What amusing me is, Kevin Kelly's goal is to reduce the machines in the world to one never crashed machine and we gain data from that machine; what we get is we increase the number of machine to achieve the goal. And that is like the Internet today. What if what we find followed Kevin Kelly's road and finally get the result that the future machine is the present machine?

Are we coming to an antinomy?

Photo @ University Centre at University of Manitoba.

Google最近（也不是那么近啦）升级了CalDAV服务，支持了iCal和Google Calendar的双向同步。过去有文章介绍过CalDAV，但按照文章的说明设置后，只能把Google Calendar上的日历给保存到iCal里，没法把iCal里添加的项目“反向”同步到Google Calendar服务器上。这样的功能几乎没什么用。现在已经没有问题了，经我测试，无论在Google Calendar上还是在iCal上添加一个新事件，在设定的时间后，事件就会出现在对方的日历上。

不仅如此，Google似乎加大了Mac相关软件的开发力度。最近Google还推出了一款名为calaboration的小工具，可以自动完成iCal和Google Calendar同步的设定。这样一来就不用为那些服务器参数伤脑筋了。calaboration同样支持托管到Google Apps上的个人服务。

calaboration是绿色软件。运行后输入Google帐号和密码，calaboration会连接到Google Calendar服务器上取得日历列表，然后在想要同步的日历前面打上勾，点“Add to iCal”按钮就OK了。然后calaboration功成身退，完全可以将之删除了。

通过calaboration完成了设置后，我便删除了BusySync了，效果没有影响。要是这些能早点出来就好了，我就不用注册BusySync了。

calaboration的地址在这里：http://code.google.com/p/calaboration/

另外，使用Mac机器的Google用户可以关注一下这个Official Google Mac Blog。Google发布for Mac的软件后会在这里介绍。calaboration就是我今天从这个blog上看到的。

This post a a Chinese translation of Guido van Rossums's article "Personal History - part 1, CWI" on his blog named "The History of Python".

原文地址：http://python-history.blogspot.com/2009/01/personal-history-part-1-cwi.html

Python的早期开发始于位于阿姆斯特丹的一个名为CWI的研究机构。CWI是Centre for Mathematics and Computer Science的荷兰语拼写的首字母。CWI是个有趣的地方，它接受荷兰政府的教育部门和其它研究拨款，做学术等级的计算机科学和数学研究。任何时间那里都有很多博士生，老辈的人或许还能记得它的原始名称：数学中心。在这个名字下，最有名的发明或许就是Algol 68了。

1982年晚期我大学毕业后开始在CWI工作，在Lambert Meertens和Steven Pemberton领导的ABC小组当程序员。四、五年后ABC项目被终止，因为它缺乏显著的成就。然后我又到了Sape Mullender领导的CWI的Amoeba小组。Amoeba是一个基于微内核分布式系统，由CWI和阿姆斯特丹VU大学联合开发，由Andrew Tanenbaum领导。1991年Sape离开CWI去Twente大学当教授，我结束了CWI的由Dick Bulterman领导的一个新生多媒体小组的工作。

Python是我在CWI的一个直接产品。正如我将会在后面介绍的那样，ABC给了我Python的关键灵感、Amoeba给了我马上的动力、多媒体组让它成长。然而，就我所知，没有任何一笔CWI的基金是正式赞助Python的。事实上，Python仅仅是Amoeba和多媒体小组的一个重要工具。

我最初想创建Python的动机是Amoeba项目需要一个高级语言。我意识到用C语言来开发系统管理工具太费时间了。而且，在Bourne shell下做这个不能保证在其它的shell下也能正常工作。最重要的是作为一个完全新设计的分布式微内核系统，Amoeba的原子操作和其它能运行Bourne shell的传统操作系统相比是非常不同（而且更出色）的。所以我们需要一个语言来作为“C语言和shell之间的桥梁”。很长一段时间里，这就是Python的主要任务。

在这一点上，你或许会问“为什么不移植到已经存在的语言上？”我的观点是，那个时候没有许多合适的语言。我比较熟悉Perl 3，但它与UNIX的联系比与Bourne shell还要紧密。我也不喜欢Perl的语法──我对编程语言的口味受Algol 60样式的语言比如Pascal、Algol 68（都是我早期学的语言）和ABC这个我花费了生命中四年时间的语言影响很大。所以我决定设计一门我自己的新语言，借鉴所有ABC中我喜欢的东西并且修正我意识到的所有问题。

我第一个决定修正的是名字！就像事实那样，ABC小组没有给他们的语言取好名字。他们最初的名字是B，后来被放弃，因为会和另一个也叫B的语言混淆，而且那个B更古老，也更有名的。无论如何，B代表只是一个意义上的工作标题（这是一个玩笑，B是包含语言名字的变量名称，因此用斜体）。小组曾经举办过一个公开竞赛来征一个新名字，但没有一个是满意的。最后选用了内部的备用方案。这个名字想传达一个让语言和字母表一样简单的想法，但它从来没有让我感到信服。

所以，没有在上面分析名字问题，我决定在下面分析它。我选择了第一个想到的名字，从Monty Python’s Flying Circus来的，那是我最喜欢的喜剧演出之一。这点引用让我感觉非常适合一个“实验项目”。“Python”一词也是一个好记的不错的名字，而且也适合用名人命名语言的传统，就像Pascal、Ada、Eiffel那样。Monty Python团队或许在科技人群中不那么著名，但他们是极客们的最爱。它也同样适合CWI的传统──Amoeba小组用电视节目的名字来命名语言。

很多年我都抵抗住要把语言和蛇联系起来的诱惑。当O’Reilly想在他们的第一本关于Python的书《Programming Python》的封面上放上一条蛇的时候，我最终放弃了。用动物图像做书籍封面是O’Reilly的传统，如果要在Python的书的封面上印上动物，蛇是最合适的了。

决定了名称后，我于1989年十二月末开始了Python的工作，在1990年的头几个月有了一个可以运行的版本。我没有记笔记，但我清楚的记得我为Python写的第一份代码是一个我称作“pgen”的简单的LL(1)语法分析生成器。这个语法分析生成器仍然是Python代码的一部分，而且或许是所有代码中需要修改的最后一部分。Python的早期版本被CWI的一群人使用，但在1990年时还仅限于Amoeba小组内部。除我之外的核心开发者是我的同事Sjoerd Mullerder（Sape的弟弟）和Jack Jansen（在我离开CWI多年后他仍然领导Macintosh移植的开发）。

在1991年二月20日，我第一次通过alt.sources新闻组向世界发布了Python（我用uuencode分成21个包发布然后用户要用uudecode来合并成一个压缩的tar文件）。这个版本被标记为0.9.0，几乎是原字照抄了当时MIT给X11项目用的许可证，署名“Stichting Mathematisch Centrum”（CWI的上级组织）作为法律实体。所以，就像我写的其它东西一样，Python在Eric Raymond和Bruce Perens在1997年末推广“开源”一词之前就开源了。

当时立刻就有了很多回复。在这些回复的鼓励下，我在后几年定期的发布新版本。我开始使用CVS来跟踪更新和更容易的管理Sjoerd和Jack贡献的的代码（CVS最初是Dick Grune开发成一组shell脚本，他是ABC小组的早期成员）。我写了FAQ，定期发布到某个新闻组，来回答在web上常见的问题，并建立了邮件列表。1993年三月comp.lang.python在我的鼓励下建立了，但不是我亲自参与的。新闻组和邮件列表通过现在还在的一个双向网关联系在一起，尽管现在是mailman的一个功能了──mailman是一个优秀的开源邮件列表管理器，它本身也是用Python写的。

在1994年夏天，新闻组上的一篇名为“如果Guido被车撞了”的文章引起了关于成长中的Python社区对我本人贡献的依赖的讨论。讨论以Michael McLay邀请我到NIST做两个月的客座研究院而告终。NIST是the US National Institute for Standards and Technology（美国国家标准及技术研究所）的缩写，它的前身是National Bureau of Standards(国家标准局），位于马里兰州的Gaithersburg。Michael在NIST有许多“客户”对在标准相关的项目中使用Python感兴趣。我在那里帮助他们提高Python技术，并为他们的需要对Python做可能的改进。

第一次Python研讨会就是我在1994年十一月在那里召开的，NIST程序员Ken Manheimer提供了重要的协助和鼓励。当时有大约20名听众，其中半数仍然活跃在Python社团中，而其中的几人已经成为了开源项目的主要领导人（Jim Fulton领导了Zope，Barry Warsaw领导了GNU mailman）。在NIST的支持下，我也在Tom Christiansen组织的大约400人参加的Usenix Little Languages会议上做了主题演讲。Tom Christiansen是一位开明的Perl拥护者，他把我介绍给Perl的创始人Larry Wall和Tcl/Tk的作者John Ousterhout。

下一篇内容：我是如何在美国找到工作的……

This post is a Chinese translation of Guido van Rossum's article "A Brief Timeline of Python".

原文地址：http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html

Python的开发和流行是和许多其它的动态（和开源）编程语言如Tcl、Perl和后来的Ruby的同时代的。为了给Python一个更好的历史看法，下面这张表展示了Python的发布历史。在早期我没有严格的记录每件事，因此那时的日期并不精确。

发布日期	版本
December, 1989	开始实现
1990	CWI里内部发行
February 20, 1991	0.9.0 (发布到alt.sources)
February, 1991	0.9.1
Autumn, 1991	0.9.2
December 24, 1991	0.9.4
January 2, 1992	0.9.5 (只在Macintosh上)
April 6, 1992	0.9.6
Unknown, 1992	0.9.7beta
January 9, 1993	0.9.8
July 29, 1993	0.9.9
January 26, 1994	1.0.0
February 15, 1994	1.0.2
May 4, 1994	1.0.3
July 14, 1994	1.0.4
October 11, 1994	1.1
November 10, 1994	1.1.1
April 13, 1995	1.2
October 13, 1995	1.3
October 25, 1996	1.4
January 3, 1998	1.5
October 31, 1998	1.5.1
April 13, 1999	1.5.2
September 5, 2000	1.6
October 16, 2000	2.0
April 17, 2001	2.1
December 21, 2001	2.2
July 29, 2003	2.3
November 30, 2004	2.4
September 16, 2006	2.5
October 1, 2008	2.6
December 3, 2008	3.0

我给此时还在python.org网站上宣传的版本加上了链接。注意许多版本还有多个副版本，比如2.0.1。我没有把它们加上，否则这个表格就太长了。非常旧的版本的源代码包仍然可以从这里得到：http://www.python.org/ftp/python/src/。许多古老的二进制版本和其它的历史“文物”可以从上一个目录找到。

这篇文章几天前就想写了，可惜一直不知道从何说起。其实现在也不太清除该怎么说，但对一个将死之人的缅怀，总不能等人死后再说。

读的blog多了，就不容易对自己留下的评论进行有效的追踪。我是一个RSS的重度用户，几乎从来不亲自去blog页面上看文章，而且至今也不理解为什么有人会宁愿花费时间去一个一个blog的看。像我这种人，要让我找个地方记住我在哪个blog上留了言，并时不时的去看看有没有人做出相应的回复，是完全不可能的事情。因此当我知道有方法可以自动跟踪这些留言时，别提多高兴了。

当时从几个blog上找了些资料研究一番，发现总的有两种方法：一是blog的主人安装一个插件，会在别人回复了你的留言后给你发邮件；另一个就是用一款网络工具自动定时帮你看网页，有回复就保存下来，然后你只要定时的去这个网页上看看，就能获取你在所有blog的留言的最新情况。co.mments.com就是我找到的唯一一个提供这种服务的网站。

更好的是，co.mments.com提供邮件通知服务，这样连上它的页面上看一看也免了。再加上它提供了添加书签的方法，只要把它的书签托到书签栏里，想跟踪一个页面，就点一下书签就OK了。Safari给Bookmark Bar上的书签设定了command+数字的快捷键。我把co.mments.com的书签放到第二位，当我想跟踪一个页面时，按command+2就完全搞定。

我一直快乐的使用着它的服务，直到我上星期最后一次用它的时候，看到了在我跟踪的页面列表上方有了以下文字：

co.mments will be shutting down Jan 11, 2009. It’s been a wonderful ride, unfortunately regular upkeep, and our friendly spammers, have turned it into a chore. I need the time and energy to focus on other things, so sadly, I’m going to shutdown the site by the end of this week. Thank you all for your support, Assaf

总之就是co.mments.com在09年1月11日就关闭了。现在还能访问，服务也正常工作，估计是管理者不会再管理，直到它的空间和域名过期。

我的印象里，像co.mments.com这种网站，应该是会大受欢迎的，怎么会沦落到要关闭的程度呢？如果是由于经费问题，这种网站没有哪个大公司感兴趣吗？或许除了广告外，投资者找不到其它盈利的手段吧。至于会不会有奇迹发生，有Google或Yahoo对这个网站发生兴趣，就不甚了了了。

至于网站关闭后我的替代方案，还没有很明确的。我们老师让我们跟踪课程网页变化的工具Change Detection是个勉强可用的方案，虽然它跟踪的是页面，不是评论。

不管怎么样，一个将死之人总会给人些许的不舍，何况是一个如此有用的人。我是希望奇迹发生的。好在co.mments.com的管理者还抱有生存的希望，我在他的blog上看到他这么写的：

Update: I’m checking the possibility of another company taking over the site,  and will continue running it until that happens (or doesn’t).

This post is for translating an article named “Python’s Design Philosophy” by Guido van Rossum.

原文地址：http://python-history.blogspot.com/2009/01/introduction-and-overview.html

介绍

Python是目前最流行的几种动态编程语言（包括Perl、Tcl、PHP，以及新成员Ruby）之一。尽管它经常被认为是一门“脚本式”语言，但它确实是一门通用的编程语言，就像Lisp和Smalltalk以及其它语言一样。在今天，Python被用于从用一次就扔到的脚本到提供24×7小时不间断服务的大型服务器的各个领域中。它被用于GUI和数据库编程、客户端和服务器端的网络编程，以及程序测试。它既被科学家用来给世界上最快的超级电脑写程序，也被儿童用来学习编程。

在这个blog里，我将把焦点放在Python的历史上。特别是关于Python语言如何被开发、设计上的主要影响，犯的错误、学到的教训、以及未来的方向。

鸣谢：我欠了Dave Beazley很多这个blog的好的句子。（关于这个blog的更多的起源，请看我的另一个blog。）

鸟瞰Python

当人们第一次看Python时，他们常常对于代码的样子感到冲击，至少从表面上来看，很像常规的程序设计语言，比方C或Pascal。这并不是意外──Python从C上借鉴了很多语法。例如，许多Python的关键字（if、else、while、for等等）和C一模一样；Python的标识符和C有着同样的命名规则；大多数的基础操作符和C有着相同的含义。当然，很明显Python并不是C，一个主要的不同就是Python不是用括号而是用缩进来分组语句。例如，不是像C一样这样写语句

if (a < b) {
    max = b;
} else {
    max = a;
}

Python完全抛弃了括号（同样抛弃了句尾的分号）并且使用如下的结构

if a < b:
    max = b
else:
    max = a

其它Python和C样式的语言的不同是它使用动态类型绑定。在C中，变量永远必须被显式的定义像成某些特定的类型，比如说int或double。这个信息被用在进行程序的静态的编译期检查和分配用来存储变量值的内存地址。在Python中，变量只是简单的只想对象的名字。变量不需要在赋值前被定义，而且它们甚至可以在程序运行中间改变类型。像其它动态语言一样，所有的类型检查都是解释器在运行的时候进行的，而不是在每次的编译的时候。

Python的基本内建数据类新有布尔、数值（机器整数、任意精度的整数、以及实数和复数类型的浮点数），和字符串（8比特和Unicode）。这些都是不可变的类型，意思是他们是用创建后就不能改动的对象描述的。内建的复合数据类型包括元组（不可变的数组）、序列（可以改变体积的数组）和字典（哈希表）。

Python通过支持包（一组模块和/或包）、模块、类、方法和函数来组织程序。它提供if/else、while和可以循环所有“可迭代的”对象高级for语句来控制程序流程。错误处理方面，Python使用了（不可恢复的）异常。一条语句抛出了一个异常，try/except/finally语句来指定如何处理这个异常。当错误发生时，内建的操作就会抛出异常。

在Python中，所有可以被命名的对象都被称为“first class”。这意味着函数、类、方法、模块和所有其它的有名字的对象都可以在运行的时候被任意的传来传去、检查、并放在不同的数据结构（例如序列或字典）里。而且谈到对象，Python也有对面向对象编程，包括用户定义的类、继承、和运行期方法绑定的全面支持。

Python有多方面的标准库，是它能够流行的主要原因。标准库有超过100个模块而且还在继续增长中。这些模块包括正则表达式配对、标准数学函数、线程、操作系统接口、网络编程、标准互联网协议（HTTP、FTP、SMTP等等）、电子邮件处理、XML处理、HTML解析和GUI工具箱（Tcl/Tk）。

此外，还有数量相当庞大的第三方提供的模块和包，其中多数是开源的。其中有网络框架（要列出来就太多了）、更多的GUI工具箱、高效率数值库（包括对许多流行的Fortran包的封装）、关系型数据库接口（Oracle、MySQL和一些其它的）、SWIG（可以让任意C++库编程Python可使用的模块的工具）和更多。

Python（和其它动态编程语言）的一个主要的吸引力是看上去复杂的任务通常可以用非常短的代码表达。举例来说，这是一段简单的Python脚本，它抓取一个网页、扫描它并获取URL地址，然后输出其中的前10个：

# Scan the web looking for references

import re
import urllib

regex = re.compile(r’href=”([^”]+)”’)

def matcher(url, max=10):
    “Print the first several URL references in a given url.”
    data = urllib.urlopen(url).read()
    hits = regex.findall(data)
    for hit in hits(:max):
        print urllib.basejoin(url, hit)

matcher(“http://python.org”)

这个程序可以容易的修改成网络抓取器，而且Scott Hassan确实曾经告诉我他用Python写了Google的第一个网页抓取器。今天，Google使用了上百万行的Python代码来管理它的各方面操作，从自动化建立到广告管理（免责声明：我目前是Google的员工。）

在底层，Python是结合字节码编译器和解释器实现的。在模块导入时，他们被隐含的编译，而且许多语言的语句在运行时需要编译器。尽管Python的事实上的标准实现是用C写的，并且可以运行在每一个的可以想象到的硬件/软件平台上，一些其它的实现也开始流行。Jython是一个运行在JVM上的版本并且和Java无缝集成。IronPython是.NET平台的版本，它和其它运星在.NET平台上的语言一样的被集成。PyPy用Python写的优化了的Python编译器/解释器（它仍然是一个EU基金下管理的研究项目）。还有一个Stackless Python，一个C实现的减少函数/方法调用对C语言的栈依赖的变种，允许并行、连续以及微线程。

从LinuxToy上看到了Python的作者开blog写史的消息，马上进去看看，发现现在一共有两篇文章。因此想到现在做一个粗略的翻译可能会对中文读者有帮助，就抽了点时间翻译了其中的第二篇文章。我翻译的很不正规、也很不严谨。但对于不想做Python历史学家的普通读者应该能看通大略意思。

This post is for translating an article named "Python's Design Philosophy" by Guido van Rossum.

原文地址：http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html

后面的blog文章会讨论Python历史的（血淋淋的）细节。然而在那之前，我想详细的说一下在我设计和实现Python时帮助我做出决定的哲学上的指导方针。

首先，Python最初是被构思成一个个人的“实验”项目──没有官方预算，我希望能很快得到结果，以便说服我的老板支持这个项目（我做的相当成功）。这样产生了一些节省时间的规则：

• 从任何可以的地方借鉴思想。
• “任务应当尽可能简单的完成。”（爱因斯坦）
• 做好一件事（“UNIX哲学”）。
• 别过于担心效率──在最后需要的时候再优化。
• 不要随大流。
• 不要试图做到最好因为“足够好”就足够了。
• （因此）抄近路是可行的，特别是当你可以在将来再完善。

其它的原则不是为了节省时间。有时它们反而是恰恰相反的。

• Python的实现不应当限制在一个平台上。部分功能可以不跨平台，但核心一定要可以随处工作。
• 不要用机器可以处理的细节去打扰用户（我不总是遵守这点，后面的章节会讲一些惨痛的后果）。
• 支持、鼓励平台无关的用户代码，但不要切断访问平台特性的功能（这点与Java完全不同）。
• 一个大型的复杂的系统应当有不同层次的扩展性。这点最大化了用户的机会，或多或少的帮助了他们。
• 错误不应当是致命的。这样，在虚拟机还正常工作的时候，用户的代码可以从错误中恢复。
• 同时，错误应该给出提示。（这两点让我决定在实现中使用异常）
• 用户代码中的bug不应当导致Python解释器的异常行为。也就是说，解释器的崩溃与用户无关。

最终，我对好的编程语言的实现有了一些想法。多数是我在我的第一次语言实现与设计经验──ABC小组中获得的。这些想法很难用语言表达，因为他们多数是我对一些像优雅、简单、可读性之类概念的主管思考。

尽管我会讨论更多的ABC给Python的影响，我想先单独提出一条可读性的规则：应当保守的使用标点符号，就像在书面英语和高中代数一样。个别在编程语言中长期使用的符号是例外，比如“x*y”表示乘法，“a[i]”表示数组元素，或者“x.foo”表示属性。但Python不使用“$”来表示变量，或用“!”来表示带有副作用的操作。

Tim Peters是一位Python的长期用户并在最终成为了多产坚定的开发者。他在《Python之禅》一文中总结了我的一些未公开的设计原则。我全部引用在这儿：

• 漂亮比丑陋要好。
• 直接比含蓄要好。
• 简单比繁复要好。
• 繁复比复杂要好。
• 平铺比嵌套要好。
• 稀疏比密集要好。
• 可读性很重要。
• 特例不能破坏规则。
• 尽管实用优于纯正。
• 错误永远不能安静的通过。
• 除非明确的让它安静。
• 拒绝在模糊的地方猜测。
• 应当有一种，并且最好只有一种，明显的方法去做一件事。
• 尽管开始时那种方法并不明显，除非你是荷兰人。
• 现在要比永远不更好。
• 尽管永远不常常比当前要好。
• 如果一个实现很难解释，那么它就是一个不好的想法。
• 如果一个实现容易解释，那么它可能是一个好的想法。
• 名称空间是一个很伟大的想法，让我们做的更多。

尽管我在ABC的经验很大的影响了Python，ABC小组也有几条Python完全排斥的设计原则。许多时候，Python有意识的防止这样做：

• ABC小组努力的做到完美。例如，他们使用被证明为对处理大型数据有很高效率的基于树的数据结构算法（但对小型数据却不那么好）。
• ABC小组希望尽量完全的从“巨大、不好的计算机世界”中隔离用户。在那里，不仅数字没有限定的范围，字符串没有限定的长度，集合没有限定的体积（在可用内存之外），而且用户也不应该处理文件、磁盘、“存储”或其它程序。ABC应当是用户需要的唯一工具。这点也让ABC小组创建了一个仅仅用于ABC的完全集成的编辑环境（当然有从ABC环境中逃离的方法，但它们通常是些事后的观点，而不是直接通过语言本身来达到的）。
• ABC小组假定用户没有之前的计算机使用经验（或者他们希望用户忘记那些经验）。因此他们引入了一些新的“对初学者友好的”术语，而不是使用标准的编程语言的术语。例如，子程序被称为“how-tos”，变量被称为“locations”。
• ABC小组没有按照头脑进化的路线来设计ABC，也没有期待用户参与到语言的设计中来。ABC被设计成一个封闭的系统，以设计者的最大努力把它做到完美。用户不被鼓励去“看看盖子下面”。尽管在项目的后期有关于对高级用户开放部分实现的讨论，但永远没有实现。

从许多角度上来说，我在创建Python的时候用的设计思想大概是它获得巨大成功的主要原因。没有努力去做到完美，早期的使用者们发现Python工作的“足够好”的满足了他们的需求。通过用户的增多，对语言的改进建议被逐渐的吸收进来。就像我们将要在以后的章节中见到的那样，许多这些改进导致了重大的改进和语言核心部分的重构。哪怕是今天，Python也在继续演化中。

Today, on course COMP 3620, Professional Practices in Computer Science (actually, or to be more precisely, the course name should be Computer Ethics), we continue talking about the concepts about ethics vs morals but much deeper.

To tell you the truth, I still can't figure out how helpful of this course to your ability of computer science. Just think about our course topic today. It's hard to believe that knowing the difference between ethics and morals will promote your programming techniques. But undoubtedly, this course will totally wash my mind of perspective of computer science to our society. For example, without this course, I may never think about the differences between the two term. Anyway, thinking is not a bad thing, right?

Really, it's such a hard thing to tell them apart exactly that even our instructor can't do it. So, rather than trying to defining the two term for us, he chose to tell some properties about them.

Before he really did that, he showed us a transprency from a book, which tells the different between the two term by a picture. There are some balloons floating above a small viliage. The words under the picture said that morals are like the passages of the villiage, while ethics are like the balloons in the sky. That's even more abstract for us so we treated it like a joke.

Other than the properties of ethics and morals, what impressed me was the examples from our instructor. The most impressive one is about abortion. A woman comes to a hospital for abortion. Without doing this, she will be very hard for her life. Even she is going to die. But the doctor is a Catholic (Catholic don't allow abortion). For the doctor, abortion is morally wrong. But as a doctor, he has the obligation to serve the patient. So abortion is ethical not wrong.

Well, with this example, I feel better for the differences. But it's still hard to describe the differences. Maybe it makes you to think. As I said before, thinking is always a good thing. Do you agree with that?

I have a course this term named Professional Practice in Computer Science. It talks about the ethic issues in computer science area.

During the course, our professor read some paragraph from a book named Computer Ethics, written by Deborah Johnson. In the Preface, Johnson mentioned that the first edition of the book was released when she gave birth to her daughter about 25 years ago. And now (about 2001), her daughter had became a teenager and was much comfortable with computers than herself.

When our professor read this, he asked us "Where are WE?" Deborah Johnson is a philosopher and is not as good as her daughter at operating computer. Why all of the social issues about computer science are discussed by those who are not professional at computer at all? Lots of times those people, such as lawyers, philosophers or sometimes computer engineers, make technically wrong ideas. However, we don't see many computer scientists sit at the table and talk about their ideas.

Computer scientists always lock themselves in a dark basement and do the technical stuff. They have push the computer science forward a lot, indeed. But they seldom care about how do those techniques affact to our society.

Our professor's opinion is like we, as a computer scientist, should go out from our basement, discuss our right ideas with other people, and make some effects to the computer science in our society. While I have an opposite idea.

What I think is the power of people is limited. People who talk about society in public are most of those people because it their job. A lawyer or a philosopher are likely to talk with public and persuade others. But a computer scientist is different. As a scientist, we'd like to make as mush as affect to our own area, science, instead of social. Anyone can think about Donald Knuth coming out to talk about computer ethics when he is suppose to do as much work as possible on TAOCP?

Anyway, the society belongs to all of us, include computer scientists. What we need is to so as much as we can in our profession, and leave the social part to the people who are suppose to do it.