Perl Should Stay Perl

RFC 28–Perl 应该留在 Perl 中 #

最初由 Simon Cozens 提交，RFC 28于2020年8月4日，这个 RFC 要求社区确保无论做什么更新，Perl 6 仍然绝对可以被识别为 Perl。经过20年的设计、概念验证、实现、两个发布的语言版本，我们最终得到了一个绝对是 Perlish 的东西，即使我们不再是一个 Perl。

在提交 RFC 的时候，我们认为这个语言会是下一个 Perl，Perl 6。随着时间的推移，在正式发布语言之前，Perl 5 的开发又有了起色，而那个团队&社区也想继续走自己的路。几个月前，Perl 6 正式更名为 Raku–不是为了摆脱我们 Perl 的传统，而是为了解放 Perl 5 社区，让他们也继续走自己的路。走向 Raku 的道路是艰难的，但我们对我们所运载的语言很满意，即使我们确实怀念锡纸上的 Perl 名字。

“吸引人的滋扰” #

让我们来研究一下 Simon 在他的 RFC 中提到的一些细节。

我们有一个黄金机会，可以把 Perl 变成我们喜欢的任何东西。我们不要错过这个机会。

这是一条很好的线，我们最终还是越过了这条线，甚至在重命名之前。具体的设计决定被改变了，我们从一个新的实现开始（如果你算上 Pugs & Parrot & Niecza……的话，不止一次）。我们是 Perlish，受到 Perl 的启发，但 Raku 绝对是不同的。

如果我们把 Perl 语言弄得面目全非，没有人会赢，因为它不再是 Perl 了。

我认为，最终大家都赢了–我们得到了一个新的、经过改进的 Perl 5 (很快就会有7)，我们在 Raku 中得到了一种全新的语言。20年前的道路并不清晰，但我们最终还是走到了一个好地方。

有些东西就是不需要沉重的面向对象。

Raku 的 OO 无处不在：但它不是必需的。虽然你可以把所有的东西都当做一个对象。

3.sqrt.say;

你仍然可以使用熟悉的 Perlish 形式来实现大多数功能。say sqrt 3;。

即使是原生标量(没有对象的开销)，如果你想的话，你也可以把它们当作 OO 来处理。

my uint32 $x = 32;
say $x;
$x.^name.say;

尽管这里的 $x 一开始并不是一个对象，但通过对它调用一个元方法，编译器就会替我们作弊，在这里输出 Int，一个最接近我们原生int的类。

但我们避免了去 Java 的程度，比如，我们不必为了执行程序而定义一个有主方法的类。

强类型不等于合法性。

类似于 OO 的方法，我们不要求类型化，但允许你逐渐添加类型化。你可以从一个无类型的标量变量开始，但随着你进一步开发你的代码，你可以给那个声明的变量添加类型，以及给子与方法的参数添加类型。类型可以是单类、子集、结点、复杂逻辑的子句：你可以使用尽可能多或尽可能少的类型。Raku的多例程（具有相同名称但不同参数的子或方法）给你提供了一种基于类型分割代码的方法，然后由编译器进行优化。但你可以随意使用它的少部分或多部分。

仅仅因为 Perl 有一个映射操作符，这并不能使它成为一种函数式编程语言。

我认为 Raku 忠于这一点–虽然有功能元素，但多语言的方法（支持多种不同的范式）意味着任何一种范式，包括功能范式，都不会接管语言。但你可以声明例程是纯粹的，允许编译器在编译时已知args时不断折叠调用该例程。

Perl 对于机器来说真的很难解析。……它的目的是让人类容易理解。

Raku 的开发绝对秉承了这个思想–“代表用户折磨实现者”。这也是我们花了一段时间才走到今天的原因之一。但是在这个过程中，我们设计和开发了新的语言解析工具，我们不仅用这些工具来构建和运行 Raku，而且还向我们的用户开放，允许他们在我们的编译器之上实现自己的语言和 “Slangs”。

fin #

最后，既然 Perl 团队提议版本跳转到7，我猜测 Perl 社区会提出类似 Simon 提出的担忧。Raku 和 Perl 7 走了两条不同的道路，但对于20年前的Perl 5 RFC 贡献者来说，这两条道路都是可以识别的。