Perl使节：Damian Conway

2020年10月1日 by Mohammad Sajid Anwar

这个月，我采访了Perl守护者之一的Damian Conway。Damian是一位计算机科学家和优秀的沟通者——他的演示和课程在全世界广受欢迎。2001年至2010年，他是墨尔本蒙纳什大学信息技术学院副教授。

采访我心目中的偶像是一种荣幸。我很享受与他交谈，我确信你们会有很多“啊哈”的时刻。例如，Raku的内置语法结构受到了Damian的Parse::RecDescent工作的启发。

我还了解到，Damian从1998年到2000年连续三年获得了Larry Wall奖，以表彰他对CPAN的贡献。

他还撰写了一些最受欢迎的Perl书籍

• 面向对象的Perl
• Perl最佳实践
• Perl技巧

如果您想让我采访您，或者您知道我想采访的人，请告诉我。请提供相同的问答集并发送您的答案！

您是什么时候开始接触Perl的？

在20世纪90年代中后期，我是澳大利亚最大大学的一名学者。当时我正在从事一系列不同寻常的研究课题：教育技术、编程语言设计、软件工程、文档系统、人机交互、自然语言生成、涌现系统、图像变形、人机交互、API设计、几何建模、感知心理物理学、纳米尺度物理模拟和解析技术。我喜欢认为自己是一位博学者，但正确的词可能更像是“业余爱好者”。

无论如何，我在用C++实现我大部分的软件，我迫切需要另一种语言（任何其他语言！）来使文本操作和生成、界面设计以及编程语言研究变得更加容易。特别是，我试图解决自然语言文本生成中的问题，因此我在幼小的互联网上搜索一个编程平台，使这项任务（如果不是容易，至少不是痛苦）。在这次搜索中，我发现了Perl。

六个月内，我向第2届Perl会议提交了两篇论文（关于自动处理英语不规则变化，以及关于声明式命令行界面）。两者都获得了接受，所以我从我的机构获得了参加会议的资金。我想我在会议上最多待了半天，就意识到我终于找到了我的群体。其余的就是历史了。

是什么让您写了《Perl最佳实践》？

主要是由Perl的三个美德中的两个：急躁和自大。在21世纪初，我对Perl社区外的普遍观点感到极其不耐烦，即Perl是一种“只写”语言，它产生的代码难以阅读、理解或维护。我对Perl社区内的普遍观点同样感到不耐烦，即“有多种方法可以实现”是一种许可（或可能是挑战），以尽可能简练、狡猾和晦涩的方式实现。

这导致了自大：我认为我可以找到并教授一套更好的习惯，用于Perl编码；这些习惯可以自动生成比我所看到的Perl代码（说实话，主要是我在自己的简练、狡猾和晦涩的模块实现中看到的代码）更干净、更易于阅读、更易于理解、更健壮、更易于维护的代码。

所以我坐下来审查了我所写的每一行Perl代码，以及其他人写的许多Perl代码，试图找到导致优秀或糟糕代码的编码模式。在六个月内，我有了250多个这样的观察，并开始在两天课程中教授这些内容。在那之后不久，奥莱利出版社联系我，建议这可能是一本很好的书。

你在书中遵循自己的建议吗？

是的。我觉得如果不这样做，我就会非常虚伪。

然而，我必须承认，一开始，吃自己的狗粮纯粹是一种痛苦。我250多条建议中，绝大多数建议的行为我当时并没有遵循。我几乎不得不改变我的所有习惯，从我的花括号风格（我是一位坚定的BSD布局支持者，但《Perl最佳实践》（PBP）倡导K&R风格），到我的标识符命名约定（我最初根本没有，并且极度沉迷于单字母变量），到我的注释风格（“注释？我的代码自我说明！”），到我的面向对象Perl编写方式（通常没有框架，并且始终没有适当的封装）。

我花费了数月时间用更好的习惯替换所有不良习惯，甚至更长的时间将这些新习惯融入到我的指尖，以至于它们“自然而然”地发生，每次我编写代码时都会出现。但这一切都非常有价值。我清楚地看到了我《PBP》之前和之后的代码之间的区别。我实际上喜欢维护和改进较新的代码，而我会不断推迟深入到旧的代码库的需要。

在几个例子中（例如，Lingua::EN::Inflect 或 IO::Prompt），完全重写模块（分别创建 Lingua::EN::Inflexion 和 IO::Prompter）比处理那令人厌恶的《PBP》之前的代码要容易得多。

当然，书中特定的建议并没有什么内在的神奇之处。事实上，在我目前的课程版本中，大约有20%的建议实际上已经从《PBP》中改变。神奇之处在于采用和实践任何一套一致、经过深思熟虑且富有成效的编码习惯。

你对当前广泛讨论的“Perl 7”有什么看法？

我认为看到Perl走出“Perl 6”的阴影真是太好了。并且看到这样积极的正向运动声明，希望不会引起太多的破坏性影响，从而破坏大量现有的代码。

更重要的是，我认为应该在新版本的Perl中默认启用现代Perl程序广泛接受的样板组件（如 use strict、use warnings、声明式子程序参数、后缀解引用）。当然，一些特别有问题和过时的组件（间接对象方法调用、隐式哈希键连接、裸词文件句柄）应该被极度贬低。

当然，这样一个大胆且出乎意料的计划不可避免地会引发焦虑和不满。而且，并非所有这些恐惧和分歧都是无端的。尽管如此，Perl 7（无论最终证明是什么）最好的地方是，仅仅是为了引入这样的基本变化而进行重大版本升级的想法，就产生了与Perl社区的大量富有成效的讨论和辩论，注入了大量新能量，这无疑最终将导致更好的结果，为Perl开辟一条更好的道路。

你关注“Cor”的发展吗？

是的，我过去六个月左右一直非常关注Cor项目。我偶尔也会就这个拟议的新机制的设计提供咨询，讨论特定问题，并在设计的几个方面向Ovid提出建议。（编辑：参见我们之前对Ovid的访谈）

不用说，我对将真正声明式接口直接添加到语言核心的展望感到无比兴奋！即使这一天可能还要几年才能到来。

你在CPAN上发布了大量实用的模块。你排名前五的贡献是什么，为什么？

不分先后

Lingua::EN::Inflexion

这是我的第一个公开Perl模块（Lingua::EN::Inflect）的继承者，我在我的第一个Perl会议上展示了这两个模块之一，因此可以说为后来的所有模块铺平了道路。原始模块及其继承者都试图解决一个非常具有挑战性的问题：在英语中产生和识别正确的词形变化（“cat”→”cats”，“box”→”boxes”，“ox”→”oxen”，“fish”→”fish”，“goose”→”geese”，“maximum”→”maxima”，“penny”→”pennies”，等等。）

我之所以提名继承模块而不是原始模块作为我前五名之一，是因为Lingua::EN::Inflexion的功能强大得多，可靠性更高，可维护性更好，并且反映了我在过去二十年里学到的关于设计良好API的大量知识。

Parse::RecDescent

这是另一个早期模块，提供了我认为是语言第一个真正Perl式的语法解析引擎。在它的发布之前，Perl已经有了lex/yacc的移植版本，但Parse::RecDescent允许你直接在程序中，直接在Perl中定义语法。它还会立即执行这些语法，而不需要单独的预编译阶段。该模块在过去二十年中被广泛用于无数的商业和学术项目。最后，我在Parse::RecDescent中开创的许多想法最终被纳入了Raku的内置语法结构中，这是我非常自豪的贡献。

Quantum::Superpositions

同样，我对我的Quantum::Superpositions模块情有独钟。不仅因为我关于该模块的演讲总是那么令人愉快，而且还因为该模块直接导致了Raku的基本概念“连接符”，我认为这可能是我在计算机科学领域的唯一有意义的贡献。

Regexp::Debugger

我在我的Perl解决方案中使用了大量的正则表达式。当它们正确时，正则表达式是解决复杂数据处理问题的强大而高效的工具，但当它们出错时，它们变成了一个令人困惑和沮丧的漩涡。这就是为什么我认为Regexp::Debugger可能是我最有用的模块。它将调试复杂正则表达式的任务从多级、多日、多痛苦药剂的噩梦转变为简单、快速、突然领悟的“哦”时刻。这个模块仅通过让我们的正则表达式错误直接在代码中可见，就为我（以及希望为许多其他Perl用户）节省了成千上万小时的痛苦。

PPR

谈到复杂的正则表达式，我非常喜欢PPR模块，因为它几乎完全由一个正则表达式组成；一个由70000个字符组成的正则表达式，可以解析绝大多数有效的Perl文档。这是一个如此简单明了的想法；然而，实现它却非常困难。但这值得每一个漫长夜晚的奋斗。能够编写一个匹配完整代码块、变量声明、'for'循环、'use'语句或其他Perl构造的正则表达式，为验证、修改和重构Perl代码开辟了一个全新的可能性领域。PPR是许多其他我非常自豪的CPAN模块的基础，尤其是Keyword::Declare（允许您使用Perl本身安全地扩展Perl语法）、Dios（将Raku的强大OOP模型和语法的大部分内容引入Perl）和Code::ART（为Vim编辑器提供Perl重构工具）。

您经常访问欧洲，并在Perl/Raku相关主题上进行演讲。您有没有什么难忘的故事可以分享？

我认为我在欧洲最难忘的经历是在2015年于日内瓦的CERN进行关于Raku（或者更确切地说，是那时的Perl 6）的演讲。

与这么多杰出的人同在一个房间里，与他们讨论我过去20年深深投入的项目，是一件纯粹的快乐。看着这些杰出的人开始克服最初的犹豫，开始欣赏这种新语言有多么强大……这是一个伟大的时刻。

当然，为了鼓励他们放下怀疑，首先出现在那里，我不得不耍一些花招。具体来说，我调整了我的标准演讲，以至于在近九十分钟内完全没有使用“Perl”这个词。实际上，我直到倒数第二个幻灯片才以任何方式提及这门语言。

的确，正是那次特定的经历——看到如何轻易地避开对“Perl”相关事物的普遍偏见——让我去年非常渴望支持将“Perl 6”更名为“Raku”。

那次访问CERN对我来说还有另一个特殊的原因。在我的演讲之前，我有幸被带去参观该设施。尽管我没有机会进入LHR（当时它因翻新而关闭），但我被允许在看起来像是直接出自科幻小说的建筑中漫步：反物质工厂。

您简要地博客介绍了每周挑战，您是如何得知它的？

我从许多参与者的博客文章中了解到每周挑战，这些文章突然开始出现在我的blogs.perl.org和reddit.com/r/perl+rakulang博客订阅中。他们看起来玩得很开心，我忍不住想亲自尝试。

您对它的体验如何？

我喜欢参加这项活动。不仅因为它给我提供了个人挑战，还因为它给了我展示如何在Raku中解决这些谜题的力量、表达性和便利性的机会。通过这样做，我超越了Perl和Raku社区，短暂地吸引了更广泛的开发者的注意。

众所周知，我非常喜欢教学，每周挑战给了我另一个机会和渠道来满足我的热情。

您从哪里得到您为CPAN贡献下一个项目的想法？

我认为我的大部分想法直接来源于我极低的烦恼阈值。每当我试图解决Perl中的某个特定问题时，如果找不到足够简单的方法，我通常会非常不合理地沮丧。我的直接反应是问自己：“如果我可以以任何我想要的方式让它工作，我会怎么做？”

然后我想起来，因为我对Perl有适度的能力，所以我可以按自己的意愿让它以任何方式工作。所以我就是这样做的。

我实现的多数实际想法和解决方案都来自我称之为“编码设计”的过程。也就是说，当某件事不够容易时，我就直接按照我希望的方式解决问题，编写我希望编写的代码。

当然，这实际上并没有解决问题，因为这种“思想代码”实际上无法运行。但那时我只需要花费大量的时间和精力，让这种假设的代码在现实中运行。通常，这需要的时间和精力远比直接以困难的方式去做要多得多。

但好处是，在花费了那么多小时创造更好的解决方案之后，之后我再也不需要以困难的方式去做。而且因为我总是把那些解决方案放在CPAN上，其他人也不再需要这样做。

在更深层次上，我认为我之所以在职业生涯中能想出这么多不同寻常的想法，是因为我花了大量时间“充实自己”。我的妻子是一位艺术家，她向我介绍了这个概念：为了创新，你必须不断地用大量新颖而随机的知识、观察和想法来充实你的头脑。创新就是在这些想法之间寻找新的和意外的联系。你拥有的想法越多，你就能更容易地找到联系，因此你就能更有创造力。

这就是我试图去做的事情。我尽可能地广泛阅读，给我的创造性过程提供尽可能多的构建块和尽可能多的合理（甚至不合理！）的联系。

对于刚开始学习Perl的人来说，你有什么建议？

三点

1. Write bad code.
2. Study better code.
3. Read great books.

然而，我认为大多数初学者犯的基本错误是，他们试图以错误的顺序去做这三件事：首先读书籍，其次是别人的代码，最后是自己编写代码。

我认为从一开始就自己编写代码是无法替代的。你需要立即面对新语言带来的挑战和谜题。这是真正提高编程能力的唯一途径，尤其是在像Perl这样杂乱无章且具有特定风格的编程语言中。

只有在你自己努力编写Perl之后，你才能开始欣赏其他人可能编写的更好的代码。一旦你开始能够识别好的Perl代码，你就可以开始有成效地学习Perl，了解为什么那些代码是好的。

Perl有很多优秀的教科书，但如果你对语言本身不太熟悉，那么它们中的大部分都是不够的。没有先前的斗争，我认为你无法真正欣赏到一本真正优秀的教科书所能提供的“啊哈！”时刻，以及那些突然的深入理解的机会。

我还要说的是，Perl几乎有太多的优秀入门教材……这使得任何初学者都很难找到最适合自己背景、个人学习风格和目标的那一本。

《学习Perl》可能适合某个人，但另一个人可能更适合《现代Perl》。有些人会发现像《Impatient Perl》这样的实用案例方法最能满足他们的需求，而其他人可能更受益于一种与《Elements of Programming with Perl》这样的基于计算机科学的理论框架几乎相反的文本。

重点是：如果您正在寻找一本帮助您理解Perl的书籍，您应该首先尝试至少几本众多优秀替代品，以便找到那本能帮助您理解Perl的书籍。

我注意到您最近与Raku有关联。您还在使用Perl吗？

几乎每天都是。我非常喜爱Raku，并且我开始在日常生活中越来越多地使用它，但当我需要尽快实现一些关键功能，并尽可能在尽可能广泛的平台上演示最快速度时，Perl仍然是我在几乎所有情况下都会选择使用的工具。

对于大型项目，Raku有一些无与伦比的优势，在未来几年内，我预计它的性能将更具竞争力，但对于快速且简陋的“现在就要完成任务”的任务，Perl仍然是我首选的电锯。

而且我怀疑它将永远是。