对Eric Raymond的Why Python?的中文翻译

[ygao]

Why Python?
By Eric Raymond on Mon, 2000-05-01 01:00.
Cardinal Biggles had Eric in the comfy chair for over four hours
before wringing this confession from him...
在获得这篇自述之前，Cardinal Biggles
让Eric坐在舒适的椅子上思考了4
个多小时...
My first look at Python was an accident, and I didn't much like what
I saw at the time.It was early 1997, and Mark Lutz's book
Programming Python from O'Reilly & Associates had recently come
out. O'Reilly books occasionally land on my doorstep, selected from
among the new releases by some mysterious benefactor inside the
organization using a random process I've given up trying to
understand.

我首次注意Python是偶然的，在那时我并不太喜欢我所看到的Python。1997
年初，Mark Lutz 的书 <<Programming Python>> 刚由O'Reilly &
Associates出版。在O'Reilly
由一些不可思秘的赞助者经过一些我不想去理解
的选择过程之后，新书会不时被送给我。

One of them was Programming Python. I found this somewhat
interesting, as I collect computer languages. I know over two dozen
general-purpose languages, write compilers and interpreters for fun,
and have designed any number of special-purpose languages and
markup formalisms myself. My most recently completed project, as I
write this, is a special-purpose language called SNG for manipulating
PNG (Portable Network Graphics) images. Interested readers can surf
to the SNG home page at http://www.catb.org/~esr/sng/. I
have also written implementations of several odd general-purpose
languages on my Retrocomputing Museum page,
http://www.catb.org/retro/.

其中一本就是<<Programming
Python>>。由于我喜欢收集计算机语言，
我发现Python比较有趣。我知晓数十种通用语言，把写编译器和解释器当作乐
趣，也曾自己设计过许多种专用语言和标记形式语言。在我写这篇文章时我刚完
成的一个项目是一个用来操作PNG(Portable Network
Graphic：便携式网络
图像)图像的叫做SNG的专用语言。感兴趣的读者可以访问SNG的主页
http://www.catb.org/~esr/sng。在我的Retrocomputing Museum网
页（http://www.catb.org/retro.）上有我写过的一些罕见的通用语言的实现。

I had already heard just enough about Python to know that it is what
is nowadays called a ``scripting language'', an interpretive language
with its own built-in memory management and good facilities for
calling and cooperating with other programs. So I dived into
Programming Python with one question uppermost in my mind: what
has this got that Perl does not?

我听说过的关于Python
的足够多的了解是仅仅知道它是一种所谓的"脚本语
言"，一种内建内存管理和容易调用其它语言代码和与其进行协同操作机制的解
释型语言。于是，头脑中带着一个最迫切的问题："Python
什么地方比Perl更
有成效？"我深入研究了<<Programming Python>>。

Perl, of course, is the 800-pound gorilla of modern scripting
languages. It has largely replaced shell as the scripting language of
choice for system administrators, thanks partly to its comprehensive
set of UNIX library and system calls, and partly to the huge collection
of Perl modules built by a very active Perl community. The language is
commonly estimated to be the CGI language behind about 85% of the
``live'' content on the Net. Larry Wall, its creator, is rightly
considered one of the most important leaders in the Open Source
community, and often ranks third behind Linus Torvalds and Richard
Stallman in the current pantheon of hacker demigods.

众所周知，Perl是现代脚本语言的巨无霸。它在很大程度上取代了shell成为用
于系统管理的脚本语言的选择。
这部分归功于它有广泛的对于Unix 库和系统
调用的工具集，部分归功于活跃的Perl社区构建的巨大的Perl模块的汇集。这
个语言通常被认为是网上使用CGI
语言的地方它占85%。它的创建者Larry
Wall理所当然地被公认为开源社区最重要的领导人之一，在当前黑客名人录上
仅次于Linus Torvalds和Richard Stallman。

At that time, I had used Perl for a number of small projects. I'd found
it quite powerful, even if the syntax and some other aspects of the
language seemed rather ad hoc and prone to bite one if not used with
care. It seemed to me that Python would have quite a hill to climb as
yet another scripting language, so as I read, I looked first for what
seemed to set it apart from Perl.

那个时候，我已经在一些小型项目上使用过Perl。我发现这个语言非常强大，
即使它的语法和其它一些方面显得过于特别，而且一不小心的话容易带来麻烦。
看来，Python
成长为另一种脚本语言似乎还有不小的困难需要克服，当我阅读
这本书时，我首先注意了它和Perl的区别。

I immediately tripped over the first odd feature of Python that
everyone notices: the fact that whitespace (indentation) is actually
significant in the language syntax. The language has no analog of the
C and Perl brace syntax; instead, changes in indentation delimit
statement groups. And, like most hackers on first realizing this fact,
I
recoiled in reflexive disgust.

我在首个Python
的新奇的大家都注意得到的特性上犯了差错：事实是空白符
（缩进）在这个语言的语法里实际上是有重要的意义的。这个语言没有类似于C
和Perl中使用括号的语法。取而代之的是，缩进的变化能够界定语句块。并且，
和大多数黑客最初了解这一特性时一样，我在自发的厌恶中退却了。

I am just barely old enough to have programmed in batch FORTRAN
for a few months back in the 1970s. Most hackers aren't these days,
but somehow our culture seems to have retained a pretty accurate
folk memory of how nasty those old-style fixed-field languages were.
Indeed, the term ``free format'', used back then to describe the
newer style of token-oriented syntax in Pascal and C, has almost been
forgotten; all languages have been designed that way for decades
now. Or almost all, anyway. It's hard to blame anyone, on seeing this
Python feature, for initially reacting as though they had unexpectedly
stepped in a steaming pile of dinosaur dung.

作为一个老一代的程序员，我曾经在20世纪70年代有数月在批处理FORTRAN
下编写过程序。虽然大部分的黑客并没有经历那个时代，但我们的文化中还是保
留了一些对于那些丑陋的固定领域语言的记忆。事实上，那时被用来形容在
Pascal和C中面向标记语法的新风格-自由格式（Free
Format）早已被遗忘，
早在十年以前，几乎所有的语言就被以这种方式设计。总而言之，对于
Python
的这一特性，很难责怪任何一个人，尽管最初我们的反应就好象走入一堆恐龙粪
中一样。

That's certainly how I felt. I skimmed through the rest of the
language description without much interest. I didn't see much else to
recommend Python, except maybe that the syntax seemed rather
cleaner than Perl's and the facilities for doing basic GUI elements
like
buttons and menus looked fairly good.

那当然是我个人的感受。我没有多大兴趣地浏览了对这个语言介绍的其余的部
分。除了那些比起Perl十分简洁的语法和很容易地做出按键和菜单等GUI元素
的外，我并没看出其它推荐Python 的理由。.

I put the book back on the shelf, making a mental note that I should
code some kind of small GUI-centered project in Python sometime,
just to make sure I really understood the language. But I didn't
believe what I'd seen would ever compete effectively with Perl.

我把书放回了书架，在心理上我记下了：我以后或许会用Python
做一些以GUI
为中心的小型项目-仅仅为了确定我确实知晓了这门语言。而那时我并不相信我
在python上的所见到的东西能与Perl有力地竞争。

A lot of other things conspired to keep that note way down on my
priority list for many months. The rest of 1997 was eventful for me; it
was, among other things, the year I wrote and published the original
version of ``The Cathedral and the Bazaar''. But I did find time to
write several Perl programs, including two of significant size and
complexity. One of them, keeper, is the assistant still used to file
incoming submissions at the Metalab software archive. It generates
the web pages you see at
http://metalab.unc.edu/pub/Linux/!INDEX.html. The other,
anthologize, was used to automatically generate the PostScript for
the sixth edition of Linux from the Linux Documentation Project's
archive of HOWTOs. Both programs are available at Metalab.

几个月来许多其他的事情让我把那件事抛在了脑后。1997年剩下的时间对我而
言具有重大意义，正是这一年我创作并发表了<<大教堂与市集〉〉。但我也抽
时间写了一些Perl程序，其中两个也具有一定规模和复杂度。其中之一是
keeper,
一个现在还被用来在Metalab的软件归档中对提交的进来的文件进行
归档。你在http://metalab.unc.edu/pub/Linux/!INDEX.html中看到的网
页就是由他生成的。另一个，anthologize，则被用来为Linux文档工程的
HOWTOs的Linux第六版自动生成PostScript。这两个程序都能在Metalab
得到。.

Writing these programs left me progressively less satisfied with Perl.
Larger project size seemed to magnify some of Perl's annoyances into
serious, continuing problems. The syntax that had seemed merely
eccentric at a hundred lines began to seem like a nigh-impenetrable
hedge of thorns at a thousand. ``More than one way to do it'' lent
flavor and expressiveness at a small scale, but made it significantly
harder to maintain consistent style across a wider code base. And
many of the features that were later patched into Perl to address the
complexity-control needs of bigger programs (objects, lexical scoping,
``use strict'', etc.) had a fragile, jerry-rigged feel about them.

写这些程序导致我渐渐对Perl产生了不满。大一些规模的项目似乎把Perl的烦
厌之处放大成了严重的，持续出现的问题。在100行中看起来古怪的语法象附
近围起来的篱笆上的1000个荆棘。"不止一种方法去实现"在小规模上提供了
风味和表现力。但在跨越一个大的代码基底中，使得它相当难地去保持程序风格
的始终如一。很多后来以补丁形式加进去的特色用以处理控制大的程序复杂性
（对象，作用范围，use strict
指令等）有一种脆弱的，草率的拼凑的感觉。.

These problems combined to make large volumes of Perl code seem
unreasonably difficult to read and grasp as a whole after only a few
days' absence. Also, I found I was spending more and more time
wrestling with artifacts of the language rather than my application
problems. And, most damning of all, the resulting code was ugly--this
matters. Ugly programs are like ugly suspension bridges: they're
much more liable to collapse than pretty ones, because the way
humans (especially engineer-humans) perceive beauty is intimately
related to our ability to process and understand complexity. A
language that makes it hard to write elegant code makes it hard to
write good code.

这些问题合并在一起造成大量的Perl代码仅在几天不去看之后变得过度难的以
阅读及领会为一个整体。我发现我花费越来越多的时间纠缠于语言造成的东西之
中而不是我的应用程序中的问题。在所有诅咒当中,那导致的代码是丑陋的，这
种东西。丑陋的程序看起来象丑陋的吊桥：他们比漂亮的更加容易倒塌,因为人
类领会美是与我们处理和了解复杂性的能力有密切的关系的。一门语言难以写优
雅的代码必定难以写出优秀的代码。.

With a baseline of two dozen languages under my belt, I could detect
all the telltale signs of a language design that had been pushed to the
edge of its functional envelope. By mid-1997, I was thinking ``there
has to be a better way'' and began casting about for a more elegant
scripting language.

凭着对大量的语言的基本的了解,我可以觉察全部的语言设计已经走向它的功能
的边缘。到了1997中期,我开始认为"必须有更好方法"，开始投向更为优雅
的脚本语言。.

One course I did not consider was going back to C as a default
language. The days when it made sense to do your own memory
management in a new program are long over, outside of a few
specialty areas like kernel hacking, scientific computing and 3-D
graphics--places where you absolutely must get maximum speed and
tight control of memory usage, because you need to push the
hardware as hard as possible.

我没有认为是要回到C作为默认语言。在一个新程序自己进行内存管理，象内
核改动，科学计算和3-D图形，在这些地方你必须独立的使得速度最大和紧紧
控制内存的使用，这种情况下做出一个有意义程序相当漫长。因为你需要考虑硬
件。

For most other situations, accepting the debugging overhead of
buffer overruns, pointer-aliasing problems, malloc/free memory
leaks and all the other associated ills is just crazy on today's
machines.
Far better to trade a few cycles and a few kilobytes of memory for the
overhead of a scripting language's memory manager and economize
on far more valuable human time. Indeed, the advantages of this
strategy are precisely what has driven the explosive growth of Perl
since the mid-1990s.<}0{

大多数的其它的形势,接受调试器缓出溢出，指针－别名的用...进行交换问
题,malloc/free memory
内存泄漏诸如此类其它相关难以处理的在今天机器
是导致的问题多多。好得多是用一些机器时间周期和内存进行交换，脚本语言内
存管理节省了贵重的人类时间.甚至,自从-1990中期以来，这种策略优点精确的
驱动Perl迅速增长。.

I flirted with Tcl, only to discover quickly that it scales up even
more
poorly than Perl. Old LISPer that I am, I also looked at various
current
dialects of Lisp and Scheme--but, as is historically usual for Lisp,
lots
of clever design was rendered almost useless by scanty or nonexistent
documentation, incomplete access to POSIX/UNIX facilities, and a
small but nevertheless deeply fragmented user community. Perl's
popularity is not an accident; most of its competitors are either worse
than Perl for large projects or somehow nowhere near as useful as
their theoretically superior designs ought to make them.

我摆弄过Tcl
。很快就发现它比Perl更差,我是老的LISP爱好者，我关注现时
各种多样的Lisp和Scheme语言，由于通常的历史的原因,许多聪明的设计由
于缺乏或者不存在的文档几乎是无用的,不完善的对POSIX
/UNIX设备存取,
一些小而无组织用户社区。Perl的流行不是偶然;多数竞争者或是在大型项目劣
于Perl或者不知何故远不及象他们的高级设计那样使得它们有用..

My second look at Python was almost as accidental as my first. In
October 1997, a series of questions on the fetchmail-friends mailing
list made it clear that end users were having increasing trouble
generating configuration files for my fetchmail utility. The file uses
a
simple, classically UNIX free-format syntax, but can become
forbiddingly complicated when a user has POP3 and IMAP accounts at
multiple sites. As an example, see Listing 1 for a somewhat simplified
version of mine.

我再研究Python
几乎象我第一次一样意外。1997,十月一系列怀疑在
fetchmail－朋友邮寄列表文件宣告最终用户是已经越来越多的麻烦生成配置
文件使用我的fetchmail程序.当一用户有POP3和IMAP
帐目在多个站点，那
文件使用简单的经典的UNIX自由-形式语法,，就变成可怕的复杂.看一例
子,Listing 1是我的简化了的版本.<

Listing 1
I decided to attack the problem by writing an end-user-friendly
configuration editor, fetchmailconf. The design objective of
fetchmailconf was clear: to completely hide the control file syntax
behind a fashionable, ergonomically correct GUI interface replete with
selection buttons, slider bars and fill-out forms.

我决定写一个用户友好地编辑器－fetchm一ilconf以着手处理那问题。设计
fetchmailconf的目标是清楚的:以流行的,人与机械控制的正确的图形用户界
面界面带着选择按钮,滑动按钮和各种表单来完全的隐藏控制文件语法。

The thought of implementing this in Perl did not thrill me. I had seen
GUI code in Perl, and it was a spiky mixture of Perl and Tcl that
looked
even uglier than my own pure-Perl code. It was at this point I
remembered the bit I had set more than six months earlier. This could
be an opportunity to get some hands-on experience with Python.

在perl中实现这个工具的想法并没有让我发抖。我看到过Perl中图形用户界面
代码,它是混合有Perl和tcl，甚至那看起来比我自己纯粹-Perl代码还要丑陋。
正是在这一刻我记起了是在六月个我对自己的约定。这可能是我得以体验
python 时机。

Of course, this brought me face to face once again with Python's
pons asinorum< the significance of whitespace. This time, however, I
charged ahead and roughed out some code for a handful of sample
GUI elements. Oddly enough, Python's use of whitespace stopped
feeling unnatural after about twenty minutes. I just indented code,
pretty much as I would have done in a C program anyway, and it
worked.

当然,这些给我带来一次面对面python
对我的严格考验,那空白符的重要性。这
次,然而,我充满感情地写了一些图形用户界面元素代码。说也奇怪,大约二十分钟
使用Python
的空白符不自然的感情没有了。我只是缩进了代码,总之如同我在
C里面做的一样,它运行了。

That was my first surprise. My second came a couple of hours into the
project, when I noticed (allowing for pauses needed to look up new
features in Programming Python) I was generating working code
nearly as fast as I could type. When I realized this, I was quite
startled.
An important measure of effort in coding is the frequency with which
you write something that doesn't actually match your mental
representation of the problem, and have to backtrack on realizing that
what you just typed won't actually tell the language to do what you're
thinking. An important measure of good language design is how
rapidly the percentage of missteps of this kind falls as you gain
experience with the language.

那是我第一次吃惊。在这个项目上几个小时后我二次吃惊了。我注意到(允许在
Python
编程中停下来以便了解一些新的特性)，我产生代码几乎是与我敲入代
码的速度一样快的。当我认识到这一点,我是相当吃惊。事实上,当你写下的代码
不能完全表达你问题在你心中的想法时，不得不回头去看你的那些代码实际上与
你当时的想法的区别，这样的次数是编代码时努力程度的重要的量度标准.当你
增进这门语言的经验时，好的语言设计重要的标准之一是这种情况下所犯的错误
在百分比上减少的速度是多么快速。

When you're writing working code nearly as fast as you can type and
your misstep rate is near zero, it generally means you've achieved
mastery of the language. But that didn't make sense, because it was
still day one and I was regularly pausing to look up new language and
library features!

当你写代码时几乎与你打字的速度一样快时，你的错误率靠近零时，表明你
大体上精通了这门语言。那并没有什么了不起的，因为它仍是
刚开始时的那样，我有规则的停下来查找新的语言及库的特色。.

This was my first clue that, in Python, I was actually dealing with an
exceptionally good design. Most languages have so much friction and
awkwardness built into their design that you learn most of their
feature set long before your misstep rate drops anywhere near zero.
Python was the first general-purpose language I'd ever used that
reversed this process.

我是在与一个设计得异常优秀的语言打交道，这是我第一次在python
上体验
到。当你学习时，当你的错误率下降近乎零时以前，大多数的语言在它们的设计
中有那么多摩擦和别扭的地方。Python是我所使用过通用编程语言中第一个逆
转这种过程的.

Not that it took me very long to learn the feature set. I wrote a
working, usable fetchmailconf, with GUI, in six working days, of which
perhaps the equivalent of two days were spent learning Python itself.
This reflects another useful property of the language: it is
compact--you can hold its entire feature set (and at least a concept
index of its libraries) in your head. C is a famously compact language.
Perl is notoriously not; one of the things the notion ``There's more
than one way to do it!'' costs Perl is the possibility of compactness.

我掌握语言特点时没有花费我多少时间，我写了一个带图形用户界面可运行且有
用的fetchmailconf，6天中的两天我在学习Python
。这反映另一个有用的特
性。它是简洁的，你要可以随时在你的头脑中把握住它的整个特色(至少对它的
库也可以有一个索引观念)。C是一著名的简洁的语言。Perl众人皆知它不是，
它的一个口号是：有不止一种方法去实现。造成Perl是不简洁的可能。
.
But my most dramatic moment of discovery lay ahead. My design had
a problem: I could easily generate configuration files from the user's
GUI actions, but editing them was a much harder problem. Or, rather,
reading them into an editable form was a problem.But my most
dramatic moment of discovery lay ahead. My design had a problem: I
could easily generate configuration files from the user's GUI actions,
but editing them was a much harder problem. Or, rather, reading
them into an editable form was a problem.

但我最戏剧性的发现摆在了我的面前。我的设计有问题:可以容易地从用户的图
形用户界面的行为中产生配置文件。但是他们是一非常艰难的问题。把它们转为
一种可读的形式就更是一个问题。

The parser for fetchmail's configuration file syntax is rather
elaborate.
It's actually written in YACC and Lex, two classic UNIX tools for
generating language-parsing code in C. In order for fetchmailconf to
be able to edit existing configuration files, I thought it would have
to
replicate that elaborate parser in Python. I was very reluctant to do
this, partly because of the amount of work involved and partly
because I wasn't sure how to ascertain that two parsers in two
different languages accept the same. The last thing I needed was the
extra labor of keeping the two parsers in synchronization as the
configuration language evolved!

分析cfetchmail程序的配置文件语法程序是相当复杂的。它其实是用YACC
和
Lex写成的－两个经典的UNIX工具，用于生成分析语言的C
代码。为了使
fetchmailconf程序能编辑现有配置文件,我想在python
中必须复现那复杂的
分析程序。我是很不情愿做这些。部分因为工作量大，部分因为我不能确定该如
何使得在不同的语言中二分析程序能接受同样的数据。最后我需要额外的努力使
得随着配置语言的发展同步分析程序。.

This problem stumped me for a while. Then I had an inspiration: I'd
let fetchmailconf use fetchmail's own parser! I added a
--configdump option to fetchmail that would parse .fetchmailrc and
dump the result to standard output in the format of a Python
initializer.
For the file above, the result would look roughly like Listing 2 (to
save
space, some data not relevant to the example is omitted).

这问题暂时把我难住了。后来我有了灵感:我让fetchmailconf
程序使用
fetchmail的自己的分析程序。我为fetchmail程序增加了configdump
选项。
fetchmailrc前且在Python
初始化程序的形式转储结果到标准输出。上述的文
件而言，结果大致的如列表2(为了节省空间，有些数据与例子与没有关系的被
省略).
Listing 2
Python could then evaluate the fetchmail --configdump output and
have the configuration available as the value of the variable
``fetchmail''.
Python 能因此计算fetchmail--configdump的输出配置,
把fetchmail变量的值作为可用的配置。

This wasn't quite the last step in the dance. What I really wanted
wasn't just for fetchmailconf to have the existing configuration, but
to
turn it into a linked tree of live objects. There would be three kinds
of
objects in this tree: Configuration (the top-level object representing
the entire configuration), Site (representing one of the sites to be
polled) and User (representing user data attached to a site). The
example file describes five site objects, each with one user object
attached to it.

这不是成功的最后一步。我真正想要的不仅仅是fetchmailconf利用现存的配
置,而是要转变并连接到树形对象。在这树形对象有三个种类的对象:配置(最上
面-对象表示整个配置),站点(表示一个站点被轮询)和用户(表示用户数据附着
站点).例子文件描述五个站点对象,其中每个有一个用户对象附着于它。

I considered writing code that would explicitly know about the
structure of all three classes and use that knowledge to grovel
through the initializer creating matching objects, but rejected that
idea because new class members were likely to be added over time as
the configuration language grew new features. If I wrote the
object-creation code in the obvious way, it would be fragile and tend
to fall out of sync when either the class definitions or the
initializer
structure changed.

我考虑将写成的代码明白知道所有当中三个分类的结构，并使用这一点经过那初
始化程序创造相配对象,但是最后拒绝那想法，因为新类成员可能是随着那生成
那配置的语言有新的特色而变化。如果我写以那明显的方法创造对象代码,当类
定义或者初始化程序结构改变时，它将是脆弱，并不再同步。

What I really wanted was code that would analyze the shape and
members of the initializer, query the class definitions themselves
about their members, and then adjust itself to impedance-match the
two sets.

我实在想的代码能够分析初始化程序的形式和成员,通过自己查询类定义它们的
成员,于是使自己适应并配合那两种设置。

This kind of thing is called metaclass hacking and is generally
considered fearsomely esoteric--deep black magic. Most
object-oriented languages don't support it at all; in those that do
(Perl
being one), it tends to be a complicated and fragile undertaking. I had
been impressed by Python's low coefficient of friction so far, but here
was a real test. How hard would I have to wrestle with the language to
get it to do this? I knew from previous experience that the bout was
likely to be painful, even assuming I won, but I dived into the book
and read up on Python's metaclass facilities. The resulting function is
shown in Listing 3, and the code that calls it is in Listing 4.

这就是称作是元类的解决方法，通常有被认为是相当深奥的--深奥的邪法。大多
数的面象对象语言根本没有支持它。这一点上Perl也一样，它趋向复杂和脆弱。
迄今为止Python
低摩擦系数给了我很深的印象。这里是一个真的测试。全力对
付于语言以做到这一点是多么的艰难。我从早先的经验知道那一回合是痛苦的。
假定我赢了。但是我深入了到那书本中，研读python
元类机制。最后的功能在
列表3,调用代码在列表4。
Listing 3
Listing 4
That doesn't look too bad for deep black magic, does it? Thirty-two
lines, counting comments. Just from knowing what I've said about the
class structure, the calling code is even readable. But the size of
this
code isn't the real shocker. Brace yourself: this code only took me
about ninety minutes to write--and it worked correctly the first time I
ran it.

那技巧看起来不太糟糕吧，是吧？32行代码，注释也算在内。仅仅从我对类的
结构的知晓，调用代码是易读的。但代码的尺寸并不是真的很小。振作精神：这
代码只用了我大约九十分钟写的，在我第一次时我就能运行，并能工作得很好。
.
To say I was astonished would have been positively wallowing in
understatement. It's remarkable enough when implementations of
simple techniques work exactly as expected the first time; but my first
metaclass hack in a new language, six days from a cold standing
startEven if we stipulate that I am a fairly talented hacker, this is
an
amazing testament to Python's clarity and elegance of design.

一再地说我被震惊，肯定是一种保守的陈述。单纯的技术工作在第一次就能工作
得这么好，这就很足够了.从起步时用6天我首先在一种新语言中用元类来有创
意的解决，即使我们确定我是相当才能的电脑黑客,这也是一令人惊异的python
的透明和优雅的设计的证明.

There was simply no way I could have pulled off a coup like this in
Perl, even with my vastly greater experience level in that language. It
was at this point I realized I was probably leaving Perl behind.

在Perl上我决不可能做到如此漂亮的工作，即使我在它上面有丰富的编程经验。
正是在这一点时，我认识到我大概会把Perl放在后面。.

This was my most dramatic Python moment. But, when all is said and
done,
it was just a clever hack.The long-term usefulness of a language
comes not in its ability tosupport clever hacks, but from how well
and how unobtrusively it supports the day-to-day work of programming.
The day-to-day workof programming consists not of writing new programs,

but mostly reading and modifying existing ones.

这是我在python
上戏剧性的瞬间。但是,毕竟,它只是巧妙的有创意的解决。一
门语言的长期的有用性不仅表现在巧妙的的有创意的解决,而且表现在是多么有
效和不唐突上.日常编程工作不仅包含写新程序，更多的是阅读和修改现有的程
序。

So the real punch line of the story is this:after writing
fetchmailconf,
I could still read the fetchmailconf code and grok what it was doing
without serious mental effort. And the true reason I no longer write
Perl for anything but tiny projects is that was never true when I was
writing large masses of Perl code. I fear the prospect of ever having
to
modify keeper or anthologize again--but fetchmailconf gives me no
qualms at all.

因此上述故事的关键是这些:在写下fetchmailconf程序几个星期甚至几个月
之后,我仍可以阅读fetchmailconf代码和不需多少脑力便轻松理解它。除了微
小的工程外，我不会再写Perl代码了，真实的是我再也不用perl写大量的大块
大块代码了。我恐惧不得不修改以保持或者再一次编纂的图景，--但是
fetchmailconf根本没有给我疑虑。

Perl still has its uses. For tiny projects (100 lines or fewer) that
involve a lot of text pattern matching, I am still more likely to
tinker
up a Perl-regexp-based solution than to reach for Python. For good
recent examples of such things, see the timeseries and growthplot
scripts in the fetchmail distribution. Actually, these are much like
the
things Perl did in its original role as a sort of combination
awk/sed/grep/sh, before it had functions and direct access to the
operating system API. For anything larger or more complex, I have
come to prefer the subtle virtues of Python--and I think you will, too.

Perl仍然有它的用处。为微小的工程(100行或者更少)汲及大量文本进行模式
匹配,我是更可能调整基于Perl-regexp的解决方案而不是使用python。好的
例子是,看在fetchmail程序中timeseries 和growthplot
脚本。事实上,在它
有能力存取存取系统api前。这些很似Perl以一种awk/sed
/grep /sh联合
的角色所做的那样。对于任何在大型的或更加复杂,我更愿意使用Python
精致
的特性，我想你也会。