Perl大师 - 与brian d foy的访谈

brian d foy是一位多产的Perl作者、程序员和培训师,他的新书《精通Perl》第二版最近由O'Reilly出版社出版。我们采访了brian,讨论了他的新书,他对技术写作的看法,以及他在从事的其他项目。

让我们谈谈大家都在关注的《精通Perl》的新封面。你喜欢它吗? 当这本书即将完成时,我看到了这个变化,因为通常他们会把这项活动留到出版过程的最后。我还没有看到印刷的版本,但我不认为它会影响人们太多,因为人们倾向于根据标题和内容而不是封面购买技术书籍。它似乎与苹果公司对iOS 7所做的相似——让一切都很薄和平面。我越来越老了,所以我需要所有东西都要更大!这和人们之前看到的不同,我认为这种风格需要一段时间才能流行起来,然后人们就会像之前那样将之与Perl系列联系起来。

最初,你为《精通Perl》设定的愿景是:“教会人们自己动手,让他们走上成为Perl大师的道路”——你认为《精通Perl》的新版是如何实现这一目标的?

第二版在结构上与第一版非常相似,尽管我更新了一些内容。第一版于2006年出版,现在已经过去了近10年。很多事物都发生了变化,比如我们使用的模块以及我们对细节的看法,但大的方面是一致的。

当我根据《精通Perl》授课时,这是人们从未真正思考过的问题。我们花了大量时间教人们如何处理语言本身在语句层面的内容,但很少涉及到更高层次的架构层面。在更高的层面上,人们会遇到真正的麻烦,因为他们创建了一些在语法上可行但在整体运行时却变得一团糟的东西。

我们花了大量时间教人们如何处理语言本身在语句层面的内容,但很少涉及到更高层次的架构层面

《精通Perl》涵盖了调试、性能分析、日志记录等主题,这些都是帮助人们完成任务的内容。我对从书中得到的反馈感到非常满意,现在我只是希望每个人都能阅读它!

我最近看到它在亚马逊Perl销售排行榜上名列第二,所以它似乎已经产生了积极的影响,对吗?

亚马逊的评分可以非常动态,因为人们购买书籍的频率很低,(尤其是技术书籍),如果我有一天卖出一本书,它就可以把我推得很高。此外,对于任何新书,最初都会有销售高峰,我认为预订在书籍发货时就被计算在内。由于《精通Perl》是一本高级书籍,所以它可能会流行一段时间,但永远不会像《学习Perl》《编程Perl》那样流行。

《学习Perl》一直是Perl最畅销的书籍。

我认为自从它出版以来,它一直是Perl最畅销的书籍。但销量远远不及Randal Schwartz在第一版中看到的。那真是太令人惊讶了。我希望有朝一日能写出一本如此受欢迎的书籍!

在《精通Perl》的新版中,有很多新的内容。你对其中哪些内容最满意或最想告诉其他人?

主要的变化发生在“轻量级持久化”和“正则表达式”章节中。在“轻量级持久化”中,我们终于向社区承认了Storable存在一个巨大的安全问题,因为在Storable格式中,我们可以注入各种东西让Perl执行操作,特别是重复的键和不存在的类名。我不得不重新编写书中所有关于Storable的内容,追踪这些信息很有趣。

从2005年到如今发生了许多变化;例如,JSON刚刚爆炸式增长。似乎每个人都在使用它,而不是那么多的YAML。所以我不得不加入JSON。在我的编程中,我现在正在做很多事情都涉及到JSON。它与其它语言交换很容易,可以抛给浏览器,而且阅读起来相当方便(至少,不是那么糟糕)。

正则表达式章节中的另一个重大变化。当我看到那个章节时,很多内容都已经移到了《学习Perl》或《中级Perl》中。我和Alison Randal共同撰写《精通Perl》的目标是,不要包含在其他书中已经有的内容,尤其是如果那是我的名字出现过的书籍。

我不得不删除很多这样的内容,比如非贪婪匹配和锚点,这些在其他书中都有。为了保留这个章节,我不得不用高级内容替换这些内容。

自从5.10以来,我们有了许多真正强大的新功能,没有人真正看到过;语法、新的标志,以及你可以用它们做的一些酷事情。

我不得不非常努力地完成这个章节,幸运的是,当我正在写作它时,Randal Schwartz提出了这个正则表达式,它使用了很多新功能来解析JSON。我不知道我是否真的会像他那样用它来解析JSON,因为他是以最小的方式为特定的客户问题编写的,这对他们来说很有效。但它展示了我想要讨论的一堆东西。所以我围绕这个主题构建了章节。我不得不研究很多这些功能的作用:在Perl文档中(至少在我看来)它们并没有很好地解释。将新功能和它们进行实验以理解它们,为《精通Perl》做出贡献,是我非常享受做的事情。

关于这个话题,你为各种受众写作,但你会说,你更享受为高级(Perl)受众写作,因为这给你更多的机会做类似的事情吗?

我喜欢以不同的方式享受它。因为,正如我在引言中所说,我假设你已经知道Perl,或者你知道如何通过文档查找信息以及去哪里提问。我不会一步一步地解释map函数是如何工作的;读者应该已经知道它是如何工作的。

这种假设让我能够扩展我们试图实现的想法,而不是语法。而在《学习Perl》中,你必须做一些非常简单的事情,因为读者将不得不面对他们所使用的特定功能的理念。

我不知道我会说更享受哪个,这是一种不同类型的享受。我真的喜欢基础知识。你可以从激发某人进入语言并为他们指明正确的道路中获益很多,然后他们可以成为一名程序员。我认为这对我来说可能比编写高级材料更有回报。这并不是说一个比另一个更好,只是将人们变成新的Perl程序员比提升现有程序员的水平更有满足感。但我认识到需要做这两件事。

《精通Perl》的章节结构基本上与之前相同,你认为你第一次就做得正确了吗?我知道其中涉及了一个公开的开发过程。

我认为我们做到了。在《精通Perl》的第一版中,我得到了Alison Randal(编辑)的很多反馈,她是Perl社区的大人物。不幸的是,她现在已经转向其他事情,但她确实非常了解Perl、社区以及如何用Perl编程。因此,当我们坐下来讨论这本书时,她提出了很多关于如何组织内容、该包含什么和省略什么的想法和意见。

我们完全在公开的环境中进行了这本书的编写。我写东西的时候,让人们看到它(这是一件非常危险的事情!)人们也不害羞地告诉我他们的想法。这很好,因为您希望他们在书出版前说出来,而不是在亚马逊的评论中说出。所以这个过程真正塑造了这本书。

当我开始写《精通Perl》的第二版时,我又把它放到了网上,并为此收到了很多很好的反馈。没有人说“你需要有一个关于x的章节”(之前没有这个章节)。我认为这是因为大多数主题已经在其他地方有所涉及。例如,我们没有关于XS的章节,因为它已经在Tim Jenness的书中有所涉及,或者你需要与perl5-porters交谈,因为他们甚至没有一套好的文档来解释所有内容。你只需要亲自动手。而且XS会随着Perl的发布而不断变化,他们正在改进Perlguts接口,使其更容易使用(这太棒了)。XS是促使Perl 6出现的原因之一,因为Perl 5的核心很难修改。我认为对于《精通Perl》,我们做得很好。

对于任何一本书来说,要记住的是,没有一本书会给你所有内容。《学习Perl》是一本非常专业的书。有Randal Schwartz的这句话:“Perl的80%的行为可以用20%的文档来描述”[1]。

在《中级Perl》中,我们继续探讨如何在团队中编写Perl、可重用代码、如何共享和引用。但它们都是非常短的书籍,每本书大约有300页,而《精通Perl》的大小也差不多。

如果你看看其他语言及其书籍,它们都有这些巨大的东西,有1000页或更多。我知道在《编程Perl》中,我们被限制在一定页数,因为否则它们无法物理装订。

但不是每个人都需要1200页。有些人会使用《学习Perl》并停止,因为这就是他们需要的。所以对于那些说“为什么不能把这些材料都合并成一本大书”的人,答案是你可以,只需购买单独的书籍,把它们的后封面粘在一起,这就是你的那本大书。章节顺序无论如何都会是一样的!

对于那些说“为什么不能把这些材料都合并成一本大书”的人,答案是你可以,只需购买单独的书籍,把它们的后封面粘在一起

那里有一个伟大的Perl书籍市场。Perl社区非常擅长传播信息。有很多初学者Perl书籍,也有足够的进阶书籍。我的想法是,如果我教你如何做某事,你不需要每项特定主题的书籍。一旦你学会了如何使用文档,你就可以快速掌握细节。

你已经写了很多关于Perl的文章,并且已经在许多不同的格式和媒介上发表。你认为好的技术写作有哪些关键考虑因素?

我始终记得Randal在我刚开始写Perl书籍时对我说的话。他指导我,并解释了如何成为一名优秀的技术作家。你始终至少有三个读者:那些一无所知、从未听说过你所谈论的事物的人;那些理解了概念,但需要阅读理由的人;以及高级用户(他们可能不是很大比例的读者),他们想学习新或巧妙的东西。

以《精通Perl》中的JSON解析器为例,我在想三个人。从未见过这些功能的人;他们没有见过递归正则表达式,所以我必须像对初学者一样解释它。有些人见过它,知道它,但从未使用过。所以,我得为他们做一些有趣的事情,因为他们知道它是如何工作的,但从未有理由将其付诸实践。然后我想到了那个高级群体,他们知道所有这些,但想以某种方式感到惊讶。这就是Randal最终的JSON解析器示例所做的。

Randal还深入我心的事情是,你必须意识到你的起点和终点在哪里,你必须引导读者到那里,因为你在讲故事;有一个叙事。你可以在我的书中看到这一点。并不是说有一节,然后在下节我们完全忘记了上一节的内容。我们始终在某种进步中。在我的写作中,我从某个点开始,写一个故事,把你引导到一个最终点,把所有东西都联系在一起。你必须记住那条故事线,这样你就知道你需要强调什么,不需要强调什么,需要包括什么,需要排除什么,以及引导人们沿着你希望他们走的路径。

关于代码示例呢?这是技术写作中总是出现的事情。你在写作中包含代码示例时,有没有遵循任何指南、规则或经验法则?

我试图编写最少干扰的代码示例。我可以编写一个Perl::Critic干净的程序,并使用所有现代Perl便利性,但这会分散我对所传达概念的关注,所以我编写了非常简化的程序。我不记得我在《精通Perl》中是否这样做过,但我不认为我在代码示例中使用了strict或warnings包。我不想总是有那两行额外的代码。我认为我在那里有shebang行,但没有那两行。这并不是说我建议不要使用strict或warnings,只是我现在没有考虑。在代码示例中,我试图关注一个特定的概念,尤其是在《精通Perl》中,我假设人们知道如何使用良好的实践编写自己的完整Perl程序,所以我不纠缠于strict和warnings。

这是Perl社区自己杀死了自己的事情之一,因为每当有人带着一个随意的问题进来时,他们得到的反馈就是:“除非你使用strict在你的程序中,否则我们不会帮助你”,即使他们的问题中没有strict问题。

我还尝试考虑的其他一些事情:代码看起来如何,它们是如何结合在一起的?我尝试将代码写成段落:将会有一些没有空行的语句放在一起,然后我会添加空行,开始编写下一个段落。不同的人有不同的想法,但在《精通Perl》中,我是唯一一个名字,所以我可以决定风格!

不同的人对代码风格有不同的看法,但在《精通Perl》中,我是唯一的名字,所以我可以决定风格!

我认为很重要的一点(我试图在我的课堂上传达这一点)是,无论如何你都将不得不查看各种不同的风格。所以让每一本Perl书籍都保持一致的样式并不会真正帮助读者。当读者坐下来打开一个由C程序员编写的Perl程序时,它看起来会非常不同,他们将没有风格支柱来帮助他们。在这种情况下有一些工具可以帮助你,在《精通Perl》中我们介绍了perltidy,它可以按照你定义的编码风格格式化Perl代码。它也像小说一样:侦探小说的写作风格与高级文学不同,因为作者试图达到不同的目的。我认为技术书籍中使用的编码风格与这种风格非常相似。我不想在编码风格上说得太多,否则我可能会引发一场关于它的在线战争。

考虑到Perl的座右铭TIMTOWTDI(有不止一种方法),你是否觉得写关于Perl很有挑战性,因为似乎无论你怎么写,总有人会有另一种方法来做到这一点?

在写书或阅读别人的代码方面,这并没有让我太烦恼,但是当我们有TIMTOWTDI时,还有对应的“但大多数都是错误的”(我不记得是谁发明了这个说法)。我认为TIMTOWTDI很棒;它让那些知识有限的人能完成任务。他们不需要学习一个最优的函数调用,他们可以用其他东西来应付。你可以用索引繁琐地解析字符串,或者使用split或正则表达式捕获。对于那些只需要在一天结束时完成任务的人来说,这很棒,因为他们可能只需要知道这些方法中的一两个,而不必花时间去找出他们不知道的一个正确的方法。以后他们如果需要的话,可以回头优化代码。所以我对TIMTOWTDI不太在意。

我来自物理世界,在那里我见过比社区通常批评的例子更糟糕的代码。我见过这种糟糕的代码在大实验室和专用设备上运行并起作用。我不愿意自己编写这样的代码,但有时你必须完成工作,我无法期望每个人都整天都在想Perl。

我确实欣赏漂亮的代码——有些人编写的代码看起来很棒,读起来也很有趣,因为他们的思考方式和使用的特性都交织在一起,创造出真正有趣的东西。但我不会期望每个人都这样,因为这不是大多数人的目标。如果我想让人们成为Perl程序员,我不能把这一点作为目标,我不是试图让他们在会议上赢得代码阅读比赛。我想要他们成为这样的人:说“我用了Perl,我完成了工作,我还有时间去干别的事情”。

我不是试图让他们在会议上赢得代码阅读比赛。我想要他们成为这样的人:说“我用了Perl,我完成了工作,我还有时间去干别的事情”。

关于代码可读性,大多数教科书都打印不带语法高亮的纯文本代码(为了节省成本或其他原因)。你认为这是错失了良机吗?

我认为我的书《有效Perl编程》(http://www.effectiveperlprogramming.com)有语法高亮,但说实话,我并不关心我的书出版后发生了什么,因为我不想看到编辑对它做了什么。我最初写了这本书,但有一大批人进来,把它变得更好。有时他们会以我不喜欢的方式改进它,可能需要几年时间我才会意识到这可能是一个好的改变。

语法高亮是个人的选择。例如,在我的终端中,背景是黑色,透明度为30%,文字是黄色。我主要在BBEdit中工作,我只使用默认的语法高亮设置。关键词是蓝色,注释是红色,文档是灰色(我想)。但是当我看到在会议上展示的代码时,会出现各种情况:花括号是特定颜色等。每个人都期待以自己的方式看到事物,所以如果我选择了一种语法高亮方案,可能对任何人都不适用。即使是《有效Perl编程》中的高亮也没有成功,因为他们不希望使用红色墨水,因为他们担心有红绿色盲的人(它可能看起来是灰色)。因此,出版社改变了颜色,现在那些通常会是红色的部分现在是青色,这让我阅读起来感到有些不舒服。语法高亮是个人的偏好,选择任何特定的风格可能都不会适用于大多数读者。

我一直认为人们应该使用他们想要的任何工具和设置。只要他们的选择不影响其他人即可。如果我用BBEdit那很好,只要使用VI、Emacs或Komodo或其他他们想要使用的工具的人不受影响。

如果我们真的有很花哨的电子书——我现在还在等,因为现在的电子书仍然大多是静态内容——但是如果我们真的有那种可以加载我们的代码设置到其中的花哨电子书,我们可以看到我们偏好的语法高亮风格的代码。但我们还没有办法在电子书中注入个人CSS。我认为这里有很多错过的机会,并且我认为现在史蒂夫·乔布斯已经去世,没有人会像他那样关心事物的外观。

关于不在乎别人使用什么,只要它不影响你使用的立场。最近在CPAN上关于Dist::Zilla作者的争议。你怎么看这件事?我们应该都采用MakeMaker方法,还是你有不同的看法?

我对MakeMaker没有太多感情,但这是我们最好的选择。Module::Build解决了许多问题,但在某些情况下它不起作用,所以我们现在又回到了MakeMaker。我希望有更好的选择,但到目前为止还没有。

关于Dist::Zilla,我真正的问题是在你进入一个Dist::Zilla项目,而你又不是Dist::Zilla的作者时,绝对没有任何提示告诉你该怎么做。很多时候甚至没有readme。曾经有一段时间,readme的流行做法是复制主模块中的pod。但我一直希望readme是“这是你可以从这个目录开始的方式”。所以在我的readme文件中,我解释了如何构建程序。Dist::Zilla方法去掉了所有这些。有一个dzil.ini文件和许多目录,但没有任何提示“这是你需要做什么”。我认为很多人甚至不知道应该安装哪个模块才能开始安装过程。当我在推特上提出这个问题时,有些人认为包含一个解释使用Dist::Zilla安装过程的文件是个好主意。然后我又进一步想,如果有一个程序可以为此过程管理用户会很好,但这与Makefile.PL路线拓扑相似。

我真正的问题是在你进入一个Dist::Zilla项目而你又不是Dist::Zilla作者时,绝对没有任何提示告诉你该怎么做。

我明白里卡多为什么开发Dist::Zilla,我明白为什么有些人会使用它,但是当人们把他们的特定活动偏好强加给他人时,我会感到很烦恼。里卡多和David Golden是高产量的CPAN作者,Dist::Zilla帮助他们管理这些。但是,他们的工作方式不必成为单个模块维护者的工作方式。我并不是说我们不应该使用Dist::Zilla,而是每次我们使用一个工具时,我们必须弄清楚它带来了多少帮助,带来了多少伤害。

我认为在很多情况下,人们告诉我,当他们进入一个git仓库(为了贡献一个更改)时,只有dist.ini文件,他们找不到需要更改的地方,所以他们就会放弃。我做的事情中有很多是文档补丁,例如,但使用Dist::Zilla,一些文本来自作为分发的一部分创建的插件。所以错误可能在上游工具链中,但我不知道是哪个工具,我也不想去寻找它。我会grep分发,如果我没有找到我想更改的东西,我就继续。这是我的个人决定——它不值得我付出努力。有些人可能会对此感到满意,他们可能认为他们本来就不太可能得到很多贡献,或者他们的用户都是Dist::Zilla用户,所以他们会得到他们需要的贡献。这是社区尚未真正讨论过的问题,而且当这个问题被提出来时,它会很快变得很激烈。

很多人出于各种特定原因不想使用Dist::Zilla。对我来说,这并不是关于Dist::Zilla,而是关于我的工具哲学:你的个人工具选择是否会影响我?我喜欢使用我使用的工具,如果我要用VI,我可能不会想进行很多编程。例如,如果你和Ovid(Curtis Poe)交谈,他几乎生活在VI中,如果他不能使用它,他可能也不想编程。所以当我们谈论构建系统时,如果Perl带有与使用Dist::Zilla构建的分发交互所需的所有内容,那么这可能是一场完全不同的游戏,但事实并非如此。

我不想告诉人们使用Dist::Zilla或不使用它,我想让人们思考(这也是精通Perl的目的),有很多工具可用,但这工具是否适合你特定的状况?除非你指定上下文,否则没有什么是最佳实践的。所以当我们讨论一个工具是好是坏时,我们需要有情境上下文。

作为程序员,我们真正喜欢做的是找到“唯一的方式”,即使Perl有“TIMTOWTDI”(There's More Than One Way To Do It),我们仍想找到一种正确的方式来完成它,然后告诉每个人都要这样做(尽管我们不太喜欢Java,它通常遵循这种方法)。Perl社区的做法是“正确的模块”。例如,就在过去几周发生的事情,我们已经告诉人们多年使用File::Slurp。它包含在文档中,包含在FAQ中。每次有人问“如何将文件读入字符串”时,他们都会被告知使用File::Slurp。结果是File::Slurp总是希望对输入文件假设特定的编码,因此如果读取不遵循预期编码的文件,会发生各种坏事。《这是一个RT的工单》,人们说这个模块“从根本上来说是损坏的”——没有一种方法可以绕过它。我们一直在推广这个工具,但它严重损坏了。它是不是很好?当然,它节省了一些打字,稍微快一点,并且可以在某些文件上工作,但它真的比本地化$/并手动读取文件好得多吗?这样我就没有依赖性,如果模块失败,我不需要回去更改任何东西。它可能慢一点,但如果我在做任何有趣的事情(在代码中),时间差异不会很大。

作为程序员,我们真正喜欢做的是找到“唯一的方式”……Perl社区的做法是“正确的模块”

上下文非常重要,这就是为什么,在90年代,我选择了Perl。Perl充满了这样的人。在这方面做得最好的人之一是Mark Jason Dominus。如果你去听他的讲座,他拥有如此广泛的编程知识,他可以真正回答“这是不是一个好主意?”这个问题,因为他了解ML、Java或其他我们大多数人从未听说过的语言的不同实现,他了解这些决策的后果。

看起来你总是在写东西,所以我肯定你不会让笔停太久。在Perl写作方面,你接下来打算做什么?

我正在写一本书,而且它的进度比我预期的要慢得多。我想写一本关于Perl在Windows上的非常薄的书。这比我想的要痛苦得多。并不一定是指写作,而是处理Windows。部分原因是我对Windows不太熟悉(这也是写一本书的原因之一),但也是因为Perl来自一个非常不同的领域,我想忠于Perl在Windows的概念(而不是Perl在Cygwin上,这只是Unix)。Windows有一个与Unix文件系统完全不同的文件系统,可以获取的元数据不同,命名文件的方式也不同等等。我以为我可以在两个月内完成,但现在快两个月了,我刚刚写完第一章,只是关于如何在Windows上安装Perl。

除此之外,我想进行一系列实验,在短书中涵盖一个主题,比如50到100页,并为它筹集一些众筹资金。也许甚至是一个众筹竞赛,其中筹款最多的项目获胜。想法是筹集足够的资金来证明花时间在这件事上是合理的,我可以在公共场合开发它,人们可以对此进行评论。然后我会以一些荒谬的低价格在亚马逊上提供这本书。我希望能有价格为一美元、销售一万册的书,而不是十美元、销售一千册的书。我并不真的在乎我能卖出多少,只是我需要足够的钱来生活并写下一本书,那将是了不起的。我会在某个时候做这个实验,我只需要先完成这本关于Windows的书!

为Windows书籍有一个网站,它是WindowsPerl.com。目前上面还没有太多内容,但我正在从人们那里收集建议,并让他们了解开发过程的情况。我不知道谁会出版这本书,我有一个想法,但我们还没有签订合同(但这不会是O'Reilly)。我会在通常的地方谈论这本书,如果人们想跟进进度或发表评论,他们可以。

你还有其他正在做的工作,想让人们知道吗?

有一件事我考虑了很长时间,我觉得我应该开始行动了。我一直在举办白骆驼奖,它在Perl的生日(12月18日)宣布,用于表彰Perl领域的杰出非技术成就。我们想认可那些做了一些永远不会被记住的事情的人——比如在用户组社区工作的人、组织会议和Perl monger活动的人、做一般Perl推广的人,比如PerlTricks。

我想创建一个新奖项,就像一个有形的奖项,他们可以用它来展示社区对他们所做事情的支持。这将是一个技术成就奖项。我在想,比如一个勋章,我不知道,我们不用胸针,如果我们发放胸针,我们就不知道把它放在哪里!

我刚刚完成了“极客荣誉徽章”,我在想也许可以在这方面做一些事情。我不知道具体怎么操作,但每隔一段时间,我只想让社区说出,是时候以某种方式发放这个奖项了,并决定谁可以获得它。比如当宫川发布cpanminus时,这是一项具有划时代意义的成果,如果每个人都这样说“这个人应该得到一个奖项”,如果我们有提供这个奖项并展示我们欣赏他们做酷事情的方法,而不仅仅是拍拍他们的背或提到他们的博客。这是一件他们可以展示给朋友或任何人的有形的东西。我考虑了这个问题很多年,我觉得我应该开始做,但我不太清楚具体怎么操作。我们太专注于算法、代码和大想法。但事实上,这只是人。我们越能表现出我们的感激之情,我们就会感觉越好,我们之间就会越友好,我们就能一起做更多的事情。

[1]Randal的引用来自《Perl入门》第三版

brian的《精通Perl》第二版现在可以购买(联盟链接)。


这篇文章最初发布在PerlTricks.com

标签

David Farrell

David是一位职业程序员,他经常推文博客关于代码和编程艺术。

浏览他们的文章

反馈

这篇文章有什么问题吗?请在GitHub上打开一个问题或拉取请求来帮助我们。