Perl之父Larry Wall专访：我的目标永远是让人开怀

Posted 2021-04-17 CSDN

倔强、天赋与让人开怀

《程序员》：你开始编程的原因是什么，为何将此作为事业？

Larry Wall：从某种意义上看，计算机仍是前沿，就像狂野的美国西部，在那里，牛仔或农夫在荒野中闯荡，在一片新土地上卓有成效地开始生活，帮助周围的人，开辟新天地。不过想把这些事儿做好，得善于解决问题。

我喜欢解决难题，因为我倔强又执着。对许多职业来说，倔强的性格比聪明的头脑更重要，计算机编程会回报那些倔强的人，即使万事开头难。

另外，我觉得我有这方面的天赋，而我受到的教育是“随天赋而来的是责任”——天赋越大责任就越大。这是从上几辈人那里传承而来的生活方式，我以此为准则，并把它传给下一代。

但这不仅仅与挑战或责任有关。在内心深处，编程带给我喜悦，让我由衷地欢笑。我将编程视为一种挥发创意的方式，像艺术家那样。我的朋友、《计算机程序设计艺术》作者Knuth同样认为编程既是科学也是艺术（你从书名就能看出）。有的艺术家使用油彩或黏土，而我凭借的则是计算机、语言，以及使用计算机语言的人组成的社区。这就是我的艺术媒介。

《程序员》：你提到了“天赋”。在你看来，编程的能力更多是与生俱来的，还是后天学习更重要？

Larry Wall：其实很多人并不觉得我那么有天赋。有人把我早期的代码作为过于精巧以至难于理解的范例。有时明明是将不同的关注点隔离开更好，我却总在同一段代码中做太多事情。年轻时的我，倾向牺牲可读性来换取速度。

我擅长什么呢？我善于发现不明确的东西。我知道什么时候一件事可通过多种方法完成，或至少我会察觉自己的做法不见得是唯一方法或最佳方法。实际上，之所以我还算一名不错的语言设计者，部分原因正在于此，因为我意识到了取舍在所难免，完美的语言并不存在。

我所做的事既需要先天能力又需要训练。先天能力之一就是认清自己的未知领域，不要装懂。再多的训练都不能代替这种能力，明晰已知与未知的关联——有时你以为尽在掌握，有时你以为一无所知，但实际情况并不如你所见这么简单。

所以这跟做具体的事情来提高自己关联并不大。开车时，我总在想怎样开得更好，这种求知欲不像开关那般说开就开，说关就关。学习无处不在，无时不在。

《程序员》：你生活的追求是什么？希望达成怎样的目标？

Larry Wall：我的目标永远是让人开怀，不管用什么方法。

开心好，让别人开心更好，教别人学会让别人开心还要好。然后，教别人学会教别人学会让别人开心……

让别人开心，最好的方式之一就是授人以创新的手段，提供新的游戏、新的题目，介绍新的朋友来交流，新的场所来娱乐，新的世界去探索并演绎新故事。创造一种编程语言很像创造一个奇幻世界，人们可以享受它的乐趣并将它继续延伸。创新其乐无穷，最能使人开怀。

《程序员》：对你影响最大的人和书分别是什么？

Larry Wall：我是一名基督徒，因此必须回答耶稣和《圣经》。

就个人而言，我从事计算机和语言学全都缘于我的朋友Gary Simons。他比我大几岁，大学时是学院里的主程序员，毕业时，学院让他找个人接替这一职位，他便选了我。后来他成为语言学者（如今他在国际语言暑期学院，负责民族语系，关于世界上到底有多少种人类语言，他可能是最权威的专家）。

我也从其他书籍和作者那里学会了如何生活与思考。年轻时我非常喜欢John Bunyan的《天路历程》和Jules Verne的《神秘岛》。年长之后喜欢Tolkien的《指环王》。非小说类喜欢Umberto Eco的《The Search for the Perfect Language》。

语言学家谈语言

《程序员》：如果作个比喻，你觉得自然语言（相对于数学或建筑）更贴近编程语言吗？如果不是，我们在谈论编程语言和自然语言的关系时，有什么需要特别注意的吗？

Larry Wall：太有趣了，我刚提到Umberto Eco的书就是关于你的这个问题。他认为完美语言不可能存在，因为完美的语言不适合用于沟通。自然语言太过复杂，不适合做任何东西的完美比喻。通常，最好的比喻就是最简单的比喻，同时也是不完美的。

甚至可以说比喻必须不完美，否则就不是比喻了。比喻的全部意义在于说一件事指另一件事，依赖听者的智力取走上下文中成立的部分，忽略不成立的部分。

我想有人会声称人类语言在处理近似方面远胜数学和建筑，尽管数学能够描述近似，而建筑学家一直都在近似——只要大楼别倒下就行。

然而，数学和建筑学的目标跟语言很不一样。数学和建筑意在构造坚实不倒之物，沟通和艺术只是其次要目标。而对语言来说，沟通是首要目标，构筑经得起时间检验的东西却是次要的，除非你是诗人、小说家或剧作家。

因此，计算机语言实际是介于二者之间的，一方面，你不想程序失败；另一方面，程序又承担着困难的任务——同时与两种截然不同的听众沟通。程序必须与机算机沟通，又不得不与其他程序员沟通，最好两者都不要困惑。

《程序员》：有一种观点，编程语言就像物种，会形成进化树，有的分支会死掉。你认为Perl处在什么位置？多年之后，你觉得语言会演化成什么样子？哪些特性会繁荣，又有哪些会枯萎？

Larry Wall：这好比讨论未来哪种基因会繁荣，答案是不可知的。我们知道的是，有的语言专长于一个小生态位而获得了成功。类似于吃竹子的熊猫，php“吃”初级用户设计的网页，而且只要这个Web编程的生态位存在，它就可能继续成功下去。竹子没有了，熊猫也就没有了。但在地球的历史上，最成功的机体大多是通才，而不是专才。鸟类当中，企鹅更像专才，只在一个地方生活，而乌鸦却遍布世界，因为它们几乎能生长在任何地方并找到食物，此外它们还非常聪明。这也是我们为Perl 6设置的目标。

在“The Hundred-Year Language”一文中，Paul Graham说得很好：我们无法知道一种延续了100年的语言到那时会是什么样子，但我们确定，它将从一种可演化的、能在一百年间满足新需求的语言起步。Perl 6的设计秉持了这种可进化性的理念，那些最严格的规则多数都刻意保持语言对新需要的适配（严格的一遍解析和自时序语法便是两个例子）。当前的设计就大量使用了从内部派生新语言的方法，处理诸如引号和模式匹配等次级语言，针对外部意图派生新语言也是一回事。

至于Perl 5会不会很快消失，我想指出的是，细菌、鱼类、蠕虫和各种简单的古生物依然遍布世界，尽管更复杂、更聪明的生命体已演化出来（至少我们自认为自己更聪明，可有时我并不十分确定）。

《程序员》：跟刚起步时相比，你在编程观念上最大的变化是什么？

Larry Wall：开始时，业内的程序设计几乎全是命令式和过程式的，甚至用所谓的高级语言也是一样。我们花费大量的时间告诉计算机按何种次序做事，即使那些事情不一定非要按序执行。为此，优化器必须格外努力地工作，弄清楚哪些地方我们把次序定得过于死板，从而重新排列代码，让程序运行得更快。

如今我写的程序少了些命令式，多了几分声明式。我更愿意找到一种方法，告诉计算机我期望发生的事情，让计算机自己确定事件的次序。不同人类语言之间的主要区别并不在于你能说什么，而在于你必须说什么。例如在英语中，你总要说清事物是单数还是复数，而汉语中却不需要。同样，什么事情是我不应该告诉计算机的？我的语言是否允许我不说？这方面我想了很多。

举个例子，并行编程时，我尽量不写显式的循环，因为显式循环隐含着次序。Perl 6中我们有用于声明无须关心次序的并行机制。

有时，为了模拟现实，我们关心状态信息的位置，为此我们使用OO把那些状态隔离成对象。“有状态的对象”即是管理对不断发生的副作用。

也有时，我们想做数学式的思考，完全不想讨论计算的状态，为此我们使用FP（函数式编程）范式，而不是OO，来把计算的状态隐藏在调用栈和持续的运算中。我们使用函数和其他抽象来隐藏副作用，从而不必考虑它们。与OO不同的是，FP把副作用藏在对象之外，而不是对象之内。

Perl 6——既是“入门语言”也是“关门语言”

《程序员》：我们知道，一门计算机臻于成熟需要漫长的时间，在Perl 6的设计过程中，哪些部分花费的精力最多？

Larry Wall：这取决于如何定义“精力”。很多设计工作只是坐在椅子上思考，这既困难又容易。牵涉的人更多时，事情会变得更困难。很多工作都是讨论不同的设计选项，理清需要权衡的因素。并非所有设计思想都来自于我；别人也会有些有趣的想法，但我们必须把这些想法整合进一个协调框架，有些想法不做修改很难并入，也有些想法问题太多只能舍弃。拒绝想法而不拒绝提想法的人是一项困难的工作。

但我认为设计工作中的大多数困难不在于提出想法，而在于说服别人，让别人足够理解并喜欢这些想法，从而把它们再传播给其他人。当新的设计跟计算机科学或者其他计算机语言（包括Perl 5）的传统理念相悖时尤其如此，因为即使我们说服了现有的（例如#perl6 irc频道里的）听众，又总会有新人到来，他们也需要说服。这是一项永不结束的工作，我一个人无法应对。幸运的是，到某个时间，社区里就会有其他人接过这项持续的教育工作，但走稳第一步很不容易。

除此之外，你的设计越大胆，就需要越多的工作来启动社区的自我教育。从这个意义上，Perl 6的设计非常大胆。写书会有帮助，但在这个过程中你不可能很早就开始动笔，否则不等出版就过时了（这样的书我们已有好几本）。对Perl 6来说，wiki也不总是最新的。现在设计趋于稳定，情形会有所改观，我希望一年内就出“骆驼”书。

Perl 5仍然是很多企业的首选，使用率依然很高。它非常稳定，这为我们赢得了充分的时间完善和重新设计Perl 6。我们不学Python 3仅对Python 2动了一点点皮毛，我们觉得要一次性、彻底地把需要打破的东西一次性全部打破，这样就能得到一种事后好多年都满意的语言。假如我没有任何包袱，有机会从头设计一门新语言，这门语言也不会跟Perl 6有任何不同。

《程序员》：我们知道Perl最擅长文本处理，那Perl 6的杀手级应用会是什么？如何预测未来的情形，并做到“好多年都满意”？

Larry Wall：预测杀手级应用是不可能的，会不会有都不好说。我就不曾料到Perl 5的杀手级应用——万维网。我只是确保Perl 5做某些事能比已有的其他语言都好，这时杀手级应用就会找上Perl，或许Perl 6也会这样。

但我觉得会有些因素能助一臂之力，让语言和它的杀手级应用更易结合。从不曾有一种语言对其潜在的杀手级应用完美无瑕，因此，要把语言修整成针对杀手级应用的领域特定语言，可扩充性和灵活性都至关重要。在设计中，我们已从多个层面将尽可能多的扩展性加入Perl 6。我们倾向把其他所有计算机语言都看作Perl 6的方言。

另一个重要的问题是市场，在我们还不知道杀手级应用是什么时，就让人们把Perl 6用于他们原本可能用其他语言实现的任务。除非他们已在这些应用中使用了Perl 6，否则即使某天Perl 6已经尽善尽美，也不会有人将它用于这种杀手级应用。Perl 5最初的市场空间是系统管理，因为1987年Unix和Windows上都没有像样的系统管理语言。用生物学的术语说，系统管理扩大了Perl 5用户的“基因库”，然后当WWW这一生态位打开时，Perl已为向着这一生态位的进化做好准备，尽管它最初是针对其他目的设计的。就像羽毛，原本进化出来是为了保暖，鸟儿们却发现它对飞行也有好处。

《程序员》：最近Emacs正在将版本控制系统由Bazaar改为Git，以吸引更多年轻黑客。你是否觉得在年轻程序员中的流行度对Perl也同样重要？如果是，你有这方面的计划吗？

Larry Wall：当然。新的蝴蝶吉祥物——Camelia，就是有意设计成吸引年轻人的，同时吓跑那些讨厌可爱事物的男人们，因为那些男人常常吓跑我们这个行业的女人。我们正尝试确立这样的理念——Perl 6的文化对于女性和儿童都是安全的，而对于既不讲究卫生，又缺社交技能的传统男性黑客则不那么安全。能被卡通蝴蝶吓到的人也会被妇女和儿童吓到，所以我们要吓跑这些家伙，直到他们学会收敛一点攻击性。

Perl 6吉祥物Camelia，一对翅膀上的“P6”图案，象征着Perl 6

在这之外，我们还需要编写能说服教师和教授们的手册和教材，说服他们Perl 6适合各种计算范例的教学，包括函数式和面向对象编程。要说服教师们Perl 6既适合做“入门语言”，又适合做“关门语言”。到目前，Perl 6的很多设计都在强调把它用作一门强大的、可伸缩应对任何问题规模的多范式语言（“关门语言”）。但我们也一直考虑如何将语言设计得容易上手，这样你只要学习马上需要的部分，更加精巧的东西可以以后需要时再学（“入门语言”）。我们小时候也是这样学习自然语言的，后来还是这门语言，我们却可能成为诗人。这是我们尝试让Perl像自然语言一样运作的另一途径。

编程原则与感悟

《程序员》：编程时你坚持哪些原则？

Larry Wall：当然，我有很多原则。

• 隔离不同关注点。

• 不要重复，使用适当的抽象层次。

• 工作正常的前提下尽量简单。

• 编写测试，从而知道代码真正工作正常。

• 编写测试，从而可以一点一点地修改程序，同时知道它仍然工作正常。

• 程序会随时间变得更加复杂，对此要有计划。

• 不到需要时不要引入复杂性。

• 学习新的抽象方法，但别在不需要的地方使用它们。

• 为将来需要读你代码的人考虑考虑，他可能是你自己。

• 用视觉化的格式把相关的或需要看成整体的东西组织到一起。

• 有些失败无关紧要，另一些却是灾难性的；要清楚这种区别。

• 代码怎样失败常常比它如何成功更重要；向用户提供查找问题所需的全部信息。

• 但最重要的原则是没有最重要的原则。

因此，要平衡这些相互竞争的原则，直到1. 你开心；2. 用户开心；3. 计算机没有特别不开心，以及，4. 读你代码的程序员没有愤怒到想找到你，掐死你。

把所有这些目标记在心里，希望在老板决定开掉你之前糅合出一个合理的方案。如果没有，那也不错——你永远可以自由地为开源工作。:-)

《程序员》：设计软件系统时你会采用何种过程？

Larry Wall：对我来说，设计通常是从自底向上的过程中浮现出来。因此，我通常先做自己理解的部分，同时把不理解的记在心里。到理解的部分做完时，我常常已知道得足够多，可以将它与不理解的部分联系起来了。当然，由于起初的误解，最终必须考虑舍弃当前的设计进行重构。但这比通过自顶向下的设计来处理误解更有效，因为后者常常延误你的理解，直到你已设计出一个复杂得难以重构的架构。拼装积木总比已黏在一起的模型更易重构。

考虑数据和事件在系统中如何流动时，自底向上的方法同样有效，因为设计模块时，一边理解一边设计常会导致发送者和接收者解耦，这也遵循了隔离关注点的原则。自顶向下的设计方法容易给数据流模式加上太多层次，有时明明横向的数据流动更自然，却要在层次树中上蹿下跳地发送数据。

《程序员》：从新程序员身上，你看到的常见误区有哪些？

Larry Wall：新程序员总想毕其功于一役，把程序作为一种“完成的壮举”呈现。程序完成之前他们不想让任何人看到。然而在行进中不断获得帮助通常更好。我们的口号是：“早发布，常发布”。

新程序员步入的另一个误区是倾向用已知工具解决问题，即使那是错误的工具。我们把这称为“XY问题”，通常它的说法是“如何用X解决Y？”有时，他们是如此痴迷于工具X，以至于干脆不提Y，直接说“我正在尝试用X，但结果总是不对。”我们必须问他们“你真正想做的是什么？”通常，我必须多问几次，他们才肯说出想要解决的Y且不基于他们认为必须使用的X。一旦真正理解了Y，我们就能指给他们正确的X去解决。这时程序员通常惊讶于存在解决问题的更好办法。他们只是从来没想到可能有更好的办法。

最主要的问题是，新程序员似乎觉得电脑应该能读取他们的思想，并以人能做到的某种方式处理模糊性，抑或处理人类都不能处理的模糊性。讽刺的是，他们向别人寻求帮助时，会再次假定别人也能读取他们的思想，即便他们还没向别人传达想要解决的问题、已尝试的办法、错误消息、输入数据、机器和系统或其他任何与程序不工作可能真正相关的东西，例如程序使用的语言。他们说的话听起来就像：“我写了这个程序，而它不工作，现在你有义务告诉我如何修正它，尽管我没有告诉你关于它的任何信息。”

程序员只需要对问题做足够的思考，从而向别人解释明白，答案常常就会显而易见。但程序员在状态最佳时也是懒人，而新程序员还不知道自己有多少不懂的，也就不知道如何寻求帮助。他们还处在婴儿水平：“只要哭得够大声，妈妈就会来做好一切。”学会高效地沟通真的会更好。但很多人认为沟通仅仅意味着说出自己所想，却没有认识到它意味着必须考虑怎样才能在别人脑子里产生你希望的结果。你理解自己所说的并不意味着别人也理解。无法沟通时人们应该责怪自己，而不是听的人。当然，与计算机沟通也一样。“为什么这台愚蠢的电脑不肯做我想让它做的？”或许你需要先学会理解计算机。

《程序员》：与你相似的这一代早期程序员身上有哪些不同之处？

Larry Wall：我觉得自己并不属于最早的一代程序员，我问我的岳父谁是第一代计算机程序员，他看着我，仿佛我是个外星人。因此，我也只能看着你，仿佛你是个外星人。

说认真的，早期的计算机局限太大，以至于那一代人对于计算机未来的设想都落入了科幻小说的范畴。没有人想到计算机会变得越来越小，以为只会越来越大——最终会有一台巨大的计算机，跟地球一样大。有趣的是，如今你可以将互联网看作一台跟地球一样大的计算机。只是它具有的CPU数目远远超出我们最初的设想，它也比我们曾经设想的计算机更健忘。

第一代程序员的确读了不少科幻小说，而且明白计算机如果能像我们一样聪明，很可能也会跟我们一样疯狂。现代的人工智能支持者仿佛觉得计算机相对人类能更加准确地思考，但我怀疑，一旦机器能强大到跟我们一样聪明地思考，我们就会发现：它也会和我们一样蹩脚地思考。人工智能将和我们犯一样的错误，只不过犯得更快。希望它们认错也能更快。

《程序员》：我们的技术世界似乎常被时髦的词汇包围，比如“云计算”。在你看来，它们是真正的技术革新并能成为我们的未来吗？如果不是，怎样才能纠正这一些题？

Larry Wall：这些问题会自我纠正，它们离真正的革新有多远便会纠正多远。文化总有发散的力量和凝聚的力量，许多文化问题都会像钟摆一样来回摆动。在我的生涯中，集中式还是分散式的问题已前后摆动了很多次，我预期它还会继续。

《程序员》：中国的这段经历带给你怎样的感受？

Larry Wall：我和我妻子在北京度过了一段美好的时光，也见到了你们中的一些人，发现你们跟世界上其他地方的开发者一样的奇特和了不起。大家彼此不同是好事，如果我们都一样，就不能互相学到任何东西了。一个拥有各种不同人物的社区就好比一个拥有巨大基因库的物种，能应对各种不同的生物学挑战而不被灭绝。互联网让世界显得越来越小，我希望，就像植物和动物那样，我们也能在自己的文化中保持这种健康的多样性。我们不需要全都一样，不一样会带来更多乐趣。

本文为《程序员》原创，点击“阅读原文”可查看全文并参与讨论。