启示录1：丑陋的，坏的和好的 （上）

答案：启示录1：丑陋的，坏的和好的 （上） 

Apocalypses I: The Ugly, the Bad, and the Good 
By Larry Wall 
April 02, 2001 

当听到启示录这个词的时候，人们往往会感到害怕，但是此时，我赋予了它好的意思：启迪。用好的思想来启迪好的人，这就是启示录的作用。 

在这篇文章里面我要揭示的，是关于Perl6的设计。或者，更精确的说，是最初的设计，因为，在当我把我最初说的话付诸于实际之后，设计过程会依然进行。我不是一个先知，同上帝的游戏对我来说有些难以承受。但无论如何，有些人必须去这么做，所以，我会尽我的全力。我希望你们所有人能够帮助我来创造历史。 

“如果你着眼于Perl6的历史，你就能发现为什么这篇文章的幅标题是“丑陋的，坏的和好的”了，从好的意义上来说，去年的RFC过程(RFC=The Requests for Comments )甚是丑陋。它是一个自由讨论的过程(brainstorming process)，这就意味着它的丑陋——并不是指粗野，因为RFC过程实际上是相当文明的，而是指在RFC中的各种意见是些毫无联系的构思。坦白的说，RFC完全偏离了原来的计划。(Frankly, the RFCs are all over the map, without actually covering the map)。有的RFC是矛盾的，而有的RFC丢失了。很多的RFC本来着眼于现实的问题但却用好笑的角度试着提出解决方案(Many of the RFCs propose real problems but go off at funny angles in trying to propose solutions)。 

我也发现了Larry的语言重新设计的第一准则：Everyone wants the colon. 

刚才讲的是丑陋的部分。而坏的部分是我被期望获取这些RFCs，在两个星期内建立起一个一致的设计方案。开始的时候，我打算将那些RFC分成好的，坏的和丑陋的三类，而最终，他们中的大多数被归为了丑陋的，因为好的那些通常存在一些错误，而即使坏的那些通常指出了一个问题，其思想还是不错的，即使，这个解决方案完全就是杜撰的。 

现在，五个月过去了，我一直都在思考一致性（连贯性）的问题。你们很多人都知道，当你的Perl程序超过了你的物理内存的时候什么会发生——你开始抓狂了。我也会这么做。我无法很好的一次在头脑里面处理很多的问题，而且我不是一个善于细分问题的人。我的长处在于综合，而非分析。我无法忍受生活中有许多让我分心的事情，有一些是我自己造成的，有一些不是。我不会更多的谈这些。留在我的还未发表的自传里面吧。 
但是现在，我们谈谈好的部分。（我希望）经过考虑了许多许多单独的RFCs，不知道如何开始将他们作为一个整体来思考，我终于发现了用来思考这些问题的恰当的顺序，或多或少，就是Camel Book（应该是指Programming Perl, 3rd Edition，译者注）的章节的顺序，用大概同样的顺序来思考Perl6，将减少在我已经决定之前必须去决定的事情（比较绕口，原文：...,so considering Perl6 in roughly the same order will tend to reduce the number of things that i have to decide before i've decided them.) 

所以，我已经愉快的将所有的RFC按照章节顺序进行了分类，现在，他们看起来更容易管理了。我打算为每一章写一个“启示录”，所以，启示录I将对应着第一章：Perl概述(An Overview of Perl)。（当然，在这本书中，“概述”更象一个短小的教程，而非真正完整的分析Perl的哲学基础。） 
所以今天，我将谈谈下面的RFC: 

RFC PSA Title 
--- --- ----- 
16 bdb Keep default Perl free of constraints such as warnings and strict. 
26 ccb Named operators versus functions. 
28 acc Perl should stay Perl. 
73 adb All Perl core functions should return objects. 
141 abr This Is The Last Major Revision. 

PSA等级代表着"Problem（问题）, Solution（解答）, Acceptance（接受）".问题(problem)和解答(solution)的等级为a-f, 通常，你将发现我对问题(problem)的评级高于解答(solution)。接受(acceptance)评级是以下之一： 

a Accepted whileheartedly 
b Accepted with a few "buts" 
c Accepted with some major caveats 
r Rejected 

某些时候，我会用d表示延期(Deferred)，如果我真的认为有些东西不应该过早决定。 

RFC 141: This is The Last Major Revision 

最初，我倾向于接受这个RFC，但是最终，在神学的立场上(on theological grouds)，我决定否决它。在关于启示录的文学作品中，7是一个代表完美的数字，而6则代表着瑕疵。实际上，就像RFC暗示的，我们可能不会结束对2*PI这样一个版本号的收敛，不过不是6.6.6这样一个倒霉的数字。(In fact, we probably would not end up converging on a version number of 2*PI as the FRC suggests, but rather on 6.6.6, which would be rather unfortunate)。 

所以，Perl7将是最后一个主要的修订版本。实际上，Perl7将会非常完美，它将不会再需要任何修改。Perl6就是Perl7的原型。:-) 

实际上，我同意这个RFC的潜在的情感——我只是出于其娱乐成分而否决了它。我想让Perl继续演变，能够更好的解决问题。出于那样的原因(to that end)，如果你细读RFC，你会发现我的一些设计目标并非十分的清晰。 

首先，Perl将会支持映射于单语义模型(single semantic model)的多重语法(multiple syntaxes)。其次，单语义模型将会反过来映射到多平台。 

多重语法听起来象一个易做图之物，但是他们对于语言的演化是非常需要的。某种程度上来说，我们已经有了多重语法模型；每次你使用一个pragma或者module，你就在扭曲你正在使用的语言。只要在module的开头声明是清晰无误的，这就没有问题。 

有一个例子是很特别的，它能用来说明支持多重语法如何允许(Perl的)继续的演化，那就是从Perl5移植到Perl6本身。详见下面关于RFC 16的讨论。 

Multiple backends对于我们如今居住的世界很重要。Perl6绝对不能限制在那些能够进行C编程的平台上运行。它必须能够在其他的虚拟机上运行，比如说那些支持Java和C#的。 

上一个：Parrot 常见问题
下一个：中文版 Perl CGI 程式写作常问问题集(一）