• Larry Wall On Perl, Religion, and...
    时间:2008-11-18   作者:佚名   出处:互联网

    Larry Wall 不但回答你的问题,而且他还告诉你这都是很精妙的问题。你一定会喜欢上 Larry Wall,不只是因为他是一个好人,而且发明了 Perl ,而且还因为他是 Slashdot 的所有接受采访的人中第一个用 HTML 格式发送答复的。你不会相信我们有多么感激了。这都是很好的答复,直白、坦诚、有趣,慢慢享受吧!

    问:Perl 是脚本语言还是编程语言? by Marx_Mrvelous

    我使用 perl 很长时间了,但是主要是作为一种脚本语言。我用它来作分离数据和报表工作。然而在最近的 perl 的开发中,好像有一种趋势是 perl 在确保仍然只是一种脚本语言的情况下,还可以做越来越多的事情。

    你对于现在人们如何使用 Perl 有什么想法?你是否满足于现状(绝大多数人使用它来做简单的工作,比如日志分析)?你希望看到更多的高级应用程序用 Perl 写成,而不是用那些编译型语言么?

    答:
    我很高兴 Perl 仍然能够继续分析日志文件。 Perl 过去一直是,而且希望将来还是一个谦卑的语言。当我到了80岁时候,哪怕每个人都高举着我,认为我是有史以来最重要的复兴者时,我还是得帮我太太倒垃圾。我在学习日语也不意味着我要放弃英文。

    但是如同人在成长和延伸, Perl 也是这样成长和被延伸。这些年 Perl 学会了很多的新技巧,人们一直在尝试用 Perl 来做几乎超出它的能力范围内的各种事情。对这个问题的解决办法不是阻止人们这么做,而是拓展 Perl 的领域。

    实际上,人们早就在用 Perl 来开发高级的应用程序了。但是这个过程也不是在每个角度来看都非常简单,有时候很困难。过去我们时常以 Perl 5 使得很难的事情成为可能为荣,我们还反复念着:“容易的事情就该容易,困难的事情应该有可能。”

    但是如同任何谚语,这个信念背后也有一些值得探讨的前提。我们都假定可以一眼就看出哪些事情应该简单或困难,还有目前简单的那些事情本来就该简单。我们还假定把复杂的事情变得简单的同时也必然导致简单的事情变得复杂。但是有时候我们不能一眼就看出哪些事情是简单,哪些是复杂。有时候错误的事情很容易,还有时候可以把复杂的事情变得简单但不使简单的事情变复杂。

    Perl 5 里面有些复杂性是可以用这种方法来解决的,也有些不行。我们不能削减必须的复杂性,但是我们可以盼望削减不必的复杂性。这就(几乎)使得每件事情都更加简单。

    我从不奢望我们能够马上就让所有的事情变的更简单。并不存在所谓的完美语言。一定程度上, 在建立一个更加有表达能力语言的同时也代表着你可能会更难学会表达自己,这就是能量的代价。曼哈顿总是要比一串珠子更加难弄懂。

    但是无论如何,请相信我 Perl 6 会比日语学起来容易。:-)
     问: Perl 初学者 by KoopaTroopa

    我是一个计算机系的大学生,最近开始对 Perl 和其他的一些语言感兴趣。但是我不是每天都会找到使用 Perl 的机会。我倾向于那种为了学而学的那种人。

    我的问题是:因为我只是要简单的了解一些日常工作中用到的 Perl ,现在是否有必要花很多的时间去学习 Perl ,还是等待 Perl 6 出来了以后呢?
     答:

    我不认为你会后悔学习 Perl 5,然而我也确信有些人会反对这个说法,或至少持有疑意。

    我认为,这真的和你现在的好奇心相关。有的人同时学习 Perl 5 和 Perl 6 的目的在于想看到语言随时间的变迁。他们是真正的铁杆跟随者。如果你不是他们其中的一员的话也可以算作幸运。但是除了外表粗糙, Perl 5 并不是一个彻底糟糕的语言,我们希望能够在 Perl 6 中保留那些好的因素。从 Perl 5 迁移到 Perl 6 的人不应该觉得忘记那些不好的因素非常困难,尤其是那些让人困惑的因素。而且哪怕你真的需要用到 Perl 6,还是有可能要和 Perl 5 的老代码打交道。所以这个问题的答案是:“看情况”。

    Gildor 安静了一会后说:“我不喜欢这个消息。Gandalf 应该是迟了,这不是好兆头。但是有句话说:你不当和巫师搅和在一起,因为他们敏感而易怒。决定在你,走还是留。”

    Frodo 回答到:“另外还有句话。不要向精灵求告,他们的答案总是模棱两可”。

    Gildor 笑着说:“真的么?精灵很少没有准备就提建议,因为建议是很危险的天分,哪怕是智慧人之间的建议,开方子哪有不出错的。但是你想做什么呢?你还没有告诉我关于自己的信息,我怎么能替你做决定呢?但你如果热切的需要,我就看在朋友的情面上给你个建议。我认为你应该赶快走,不要等了。如果你准备好出发之前 Gandalf 还没来,我建议你不要一个人上路。带上这样值得信赖又热心的朋友。现在你总该知足了吧,我可不情愿给你这样的建议呢。”

    问: 结构化编程和 Perl by slashnot007


    我喜欢 perl 的原因是因为他不是一个结构化编程语言。我的工作中50%使用 Perl 作分析,25%的努力在于控制程序流转和进行后台服务,还有25%的面向对象的 CGI 编程。

    所以我想知道 perl 是否排斥 Python 。很多次我都尝试用 python 但是总是返回到 perl 。原因是我的日常工作大部分是解析数据, Perl 正是我偏好而且熟悉的工具。因为我不想同时熟练使用两种语言,当面对复杂的任务时,我也选择了用 perl 来解决,尽管 python 可能更加擅长结构化编程。

    我的问题在于: perl 6 是否会使 perl 成为类似 python 的结构化语言?是不是为了防止变得太复杂和无法管理,就不再进一步发展下去?( java 有一个好的开头但后来变成了一个带有参差不齐模块库的巨无霸的)。

    答:

    呃,你怎么定义“结构化”呢?25年前所有的语言都被认为是“结构化”的(一块代码只有一个入口)。曾经有人考虑过一个代码块也应该只有一个出口,谢天谢地这些人没有胜出,因为要表达决策树的程序块(函数)总是需要多个跳出点。

    但显然你的意思有所不同,也许还很不同。语法也是结构化的,每个语言有不同的语法,但是我想那也不是你的意思。

    我想你说的“结构化”是中学老师说的那个意思,就是说“结构化的游戏时间”是和“自由的游戏时间”相对的。 Python 的口号是“只有一个明确的办法来做事情”,从计算机的角度来说是很好的,但是从人性化的角度来看就不怎么样了。“只有老师允许,你才可以玩自己喜欢的游戏 ”。

    从这个角度来讲, java 远不如 Python 结构化。这是 java 成功的原因之一,但这也是有代价的。 Java 的问题之一是他们在众多库组成的地毯下面隐藏了太多复杂的东西,所以现在他们已经必须换了好几次地毯了。

    所以,尽管 java 有一个好的开头,但是那是太小的一步(至少我看来)。至于 Java 里面的“结构化游戏时间”,更多的是因为文化标准的干涉使这个语言结构化,而不语言本身的原因。

    对于 Perl 来说,它从来就没有成为结构化的语言,当然你还是可以用它来建立你所喜欢的结构化的构架。总体来说这个结构化是可选的,不是外部强迫来的。就好像如果你想和同学在下课时间玩足球的话,老师从来不需要强逼你们。

    踢足球和写程序在道理上相通。你需要有些共同的规则来和他人一起玩。 Perl 5 还没有使这个达成共同规则的工作简易到极致,我们计划在 Perl 6 里面进一步简易化。编程需要有个大体的规范,但是你得自己旋开编程规范的门把手,而不是让其他人帮你打开。 Perl 6 会给你这个的把手。

    我不喜欢帮你转门把手,因为我不知道你要怎么转,转多快。( Perl 6 也会帮你自动打开一点点,如果你写一个模块或类,他会自动套用比主程序更加严格限制语法的模式。)但是我不帮你开门的原因是因为你可以自己选择学习的速度,我不知道你想学多快。就如 Gildor 所说,你还没有告诉我足够多的关于你自己的情况,所以我还不能给你建议。如果我不知道你冲浪的本事如何,我不能告诉你多大的浪适合你,我们就得从小浪开始。

    我们教孩子读书的时候会遇到同样的问题。有的人上来就说“所有的语言”,有的人从发音开始。他们都有点太简化了。你得学点发音,然后在这个基础上学其他的,最后你发现你在整个语言的网里面漫游。大多数语言教师都犯了“专家崇拜”的毛病,看到专家做事情的办法,然后就断定所有人都得这么做。当然也有人是天生的读书料,他们自己摆弄着就学会了语言。但是如果你这样来教每个人学语言的话,一半的孩子都学不会人口手。

    编程也一样,程序语言的设计者研究专家是如何编程的,然后就认为每个人都是这样学会编程的。这就好像期望一个冲浪新手能够对付40尺的巨浪一样。也许有人做到了,但是其他人都被冲走了。

    Perl 是用来帮助人们逐步学习编程,而不强迫他们学习自己还没做好准备的东西。当他们准备好的时候, Perl 又恰当的出现。我们只是没有反复的告诉初学者他们的高尔夫带子上面有个计速器。

    问: 有什么是不会加到 Perl 6 里面去的?* by TreyHarris


    什么功能是大家都需要而你又不会放到 Perl 6 里面去的,为什么?

    答:


    这要看你怎么定义功能,还有怎么定义需求。如果你看看 dev.perl.org 的所有 RFC 的话,你就会发现绝大多数请求的功能是一种创可贴一样的建议。然而我认为最好还是把他们当作求救。对于编程语言来说,75%的创可贴下面有弹孔。

    所以,基于多行注释的难度, 我公开拒绝了多行注释的 RFC 请求。无论如何,最好的方案不是增加更多的语法,而是修改 POD 的语法来达到人们的要求。

    但要记住这是 Perl ,所以总是要有更多的解决方案。另一个解决方案是让 Perl 的语法更加灵活嬗变,这样用户可以用 pragma 自己加入多行注释机制。对我来说这很好,只需要在词法一级解决这个问题,不用大动干戈的修改语法。“只要提前声明就没问题”。

    还有一个常被提起,但不会加入到 Perl 6 里面的功能是隐藏式词法定义。这种类型的功能对于一小段代码来说象是个好主意,但是当代码增多时就会出问题。按照缩进层次来区分语境也有相同的问题,不过因为某些奇怪的原因,还没有人严肃的要求这个功能。

    现在你肯定在想,大家要求最多的一定是除去 $、@ 和 % 符号,但是通常来说只有不理解 Perl 的人才会提出这样的要求,而且即使你满足了他们的要求,他们还是不会使用 Perl 的。理解 Perl 的人一般会倾向于喜欢这些符号。

    问: Perl 和其他语言的比较 by larry bagina

    每次 perl 的话题出现在 slashdot 上,就会有很多热衷语言的人宣布 perl 已经废弃了,应该用 php 或者 ruby 或 python 。

    你怎么看待其他的脚本语言呢?你喜欢什么,不喜欢什么?

    答:


    好的,总体来说我不喜欢其他编程语言的原因是他们都不是 Perl 。:-)

    严肃的说, Perl 最能匹配我思考的方式,因为我最需要的是一个很灵活的编程语言。我想要一个雅俗共赏的语言 。我想要一个老少皆宜的语言 。其他的编程语言都达不到这个要求。

    需要对比的话,我必须说 Ruby 的例子是主要的(导致我不支持在 Perl 6 中加入隐藏式词法范围)的原因。我们还是坚持使用 my 的声明方式。很多方面上我还是很喜欢 Ruby 的,这是因为那些部分是从 Perl 借过去的。:-)

    我还喜欢 Ruby 的 C<*> 一元星号操作符,所以我把它加到 Perl 6 里面。

    Ruby 的主要问题在于它的最少惊讶原则可能让人误入歧途,就好像隐藏式词法范围。问题在于减少谁的惊讶?专家和初学者对不同的事情惊讶。从一个小程序写成大程序的人和从开始就写大程序的人可能对不同的事情感到惊讶。

    例如,我认为对于初学者来说面向对象是个可以惊讶的事情。对他们来说,数值就是数值,字符串就是字符串。专家可能把他们作为对象来理解, 但对初学者来说才不管计算机是怎么想的呢。提前引入面向对象的概念对初学者来说是个坎。

    我得承认,我对 PHP 这样的向外扩展( inside-out) 的语言有种怜惜。我写过的第一个编译器就是一种文字处理的宏语言(命令嵌入在数据里面)。这是另外一种类型的编程语言,总是依赖于一种特殊的外部处理器。好像 awk 的模式/动作语法就总是意味着一个不可见的外部循环。

    Perl 也可以这么做,但并不是默认的模式。我认为 awk 和 PHP 一样总是需要小心的寄生在一种特殊的环境里面,尤其是当 Perl 可以更有效的做同样事情的时候。因此我从来没有受到诱惑去试着写 PHP 程序。所以如果我说 PHP 的名字空间和扩展机制有很大问题,那就是在引用别人的话。所以我在这里免谈 php 了。:-)

    Python 从细微上看很酷,不过我想他的整体语法不适合大块的代码。我在这点上赞同亚里士多德的三段论,故事总得有个开头,中间内容和结尾。代码块也一样。

    Python 迫使人们编写某种编排格式的代码,但是这不是 Perl 的方式。起码不是 Perl 的默认模式。但是如果你提前声明就什么样式都可以。你可以引入一个语法模块来限制大家用某种特定的编排格式。你的公司也可以限定你用某中 pragma 。当然,如果你想要用正真的编程规范,我建议你看看 Damian 的 Klingon 模块。

    问: Perl 和 .NET _by prostoalex_


    总体上你对 .NET 有什么看法?在其中 Perl 的角色如何?既然 .NET 支持 Perl 作为其中一种开发语言,你会建议用它来做所有的项目么?你觉得这种搭配有前途么?

    答:


    在我看来, .NET 只不过是我们需要把 Perl 移植上去运行的另一个架构而已。目前和 .NET 结合的努力还是一种技巧的尝试。部分的困难来自于 Perl 没有强大类型声明系统,但是同时也是 .NET 平台不能有效的支持动态语言的过错。我们可以期待 Parrot 接口那样的东西可以包在 .NET 或者 Java 虚拟机上面。在匹配过程中的阻力越小,这个包裹层就越薄。

    我建议你在适当环境下使用 Perl ,在不适当的时候不要用。我不能替你决定是否有必要在 .NET 平台上用 Perl ,主要是因为我的无知和愚钝所以不能替你决定。对不起。

    对于未来,我实在是不知道。很久很久以前(我们的银河还没产生前)我试着用一个流程模造 Perl 和 Java ,但是从来没有得到什么积极响应。实际上 Java 爱好者会对不是100% Java 的解决方案嗤之以鼻,Perl 爱好者也有差不多的反应。总体上来说 Perl 程序员对 Java 没什么好感。我想语言的设计师和实际用户不同,他们比一般人更加喜欢多语言的混合解决方案。

    这就是为什么我们在尝试做 Parrot ,自己想想吧。:-)

    问: 从项目经理角度看 by mustangdavis


    对于有些评价不知道你怎么看,他们说 Perl 不是为多程序员项目设计的。很多人一再声明超过一个人编写的 Perl 代码无法维护,你怎么考虑这个问题?你是怎么管理一个庞大的 Perl 项目的?你认为 Perl 适用于大项目么 ( 换句话说: 它只适合做快速不需要怎么维护的小项目?) 补充一下:我喜欢你的工作成果,总得有人说感谢的话。

    答:


    看上去有点不可思议,我自己不管理项目。我不是一个做管理的材料,我所有的管理技巧都外包了。问问其他代替我做管理的人就知道。

    但是那些说多人编写的 Perl 代码不能被管理的人确实没有什么依据。他们忽略了那些成功做到这点的人。你不能指望随便在大街上找人来一起写本小说。你得找那些真正懂得如何协同工作的小说家来干这个。如果没有那样的专家,你也可以设定一个规矩让每个人都能贡献点力量。好像 Liavek 的世界里面的写作规范是:每个故事都必须提到骆驼。

    通过 Perl 6 我们可以让项目经理和系统架构师在总体上设定这些编程规范,引入一个标准的元对象类型可能有帮助。没人会说 Perl 6 的面向对象功能是“包罗万象”( bolted on )。当然除了那些 Slashdot 上面不能区分理性讨论和摇旗呐喊的人。

    问: 宗教的角色? by Anonymous Cowdog


    我记得在哪里读到过你是一个基督徒,而且你的早期传教使命感(做好事,帮助别人的期望)也是你多年来投入到 Perl 里面的激情来源。

    从科学的角度来讲,我不相信宗教,也不想成为一个信徒。可能那里有个神,但是如果那里有的话,我想他/她并不动手干涉;换句话说,他没有能力来改变任何事情;事实仅仅依靠物理上的定律(不管哪种定律)来运转。

    请告诉我们为什么科学家或者起码有科学头脑的人会去相信神,还有宗教在你的工作中扮演了什么角色。

    答:


    这个话题要用一篇论文、一本书或者一生来说明。但是我会试着让它简短。

    当你说“世上怎么会”的时候我想你认为有科学头脑(或起码是技术头脑)的人会选择相信有神是不可思议的。我猜想问题的一大部分在于你忙着不相信一个不同于我正在相信的神。你可能没有注意到,神学上的问题比其他的问题更容易用正确的角度来探讨。

    所以让我来尽量清晰的表达我的意思,而且尽量浓缩到最小的程度。有些人很喜欢把这个弄得没有必要的难懂,但是实际上确实连孩子也可以明白的事。他不需要你有满口的信心才能理解,实际上耶稣说你只要有芥菜子大小的信心就好了。从信息角度来说那有多大?我想是两个。请让我引用圣经中希伯来书里面,有点段落感的:

    若没有信心你不能像以诺那样与神同行,因为来到神跟前的人必须(至少)相信: A) 有神,而且 B) 他赏赐那寻求他的人。

    就是这样,福音是如此简单以至于一个小孩子也可以懂得,同时也如此复杂连哲学家也不能理解。

    现在看来你已经愿意承认 A 了,你的那一个比特已经成为 1 了,这就只差一半了。如果那一比特也像 Shroedinger 家的猫一样在你心里摇摆不定,那你只差四分之一了。你应该观察,而不是我,除非你已经死了。:-)

    因为各种原因很多人在 B 那里停住了,有逻辑上的,也有道德上的,绝大多数人还是因为 Shroedinger 。人们总是害怕注意 B 这个量子是因为他们不希望这个 Shroedinger 函数收敛到 0 或者 1,因为那个选择都难以接受。很多人宣称不相信神不是因为他们不知道,而是因为他们不想知道,有时是无所谓。

    因为如果那个比特是 0 的话,我们就成为了自私基因的奴隶,道德也没有了根基(除了种族主义以外)。

    而且如果 B 比特也成为了 1 的话,你就得同时吞下附带的胡言乱语,你是这样想的么?

    让我来开导你,我是从另外一个方向思考的。我生长在一个宗教文化中,而且我得吐出其他很多的东西才把我的信仰压缩成刚才的两个比特。

    我还想进一步削减,但是不行了,因为神告诉我:“足够了。我早就把你的信仰的比特设成 1 了,我比你更擅长观察。这回你反过来成为 Shroedinger 家的猫了,你过去在灵魂上是死的,但是我早就检查过你的比特,而且我认为它们都是 1 。你是谁竟然能反对我呢?”

    所以,我是谁竟然能反对神呢?:-) 如果他真的是世界的创造者的话,他就該有权看我的比特/跳线,而且他还能偶尔的摆弄比特/跳线来让故事更加有趣。不管他是否有大拇指。

    一旦你能从这个角度看宇宙万物,很多的争吵就没有必要了。例如霍金所说:“宇宙是爆炸产生的所以并没有创造者”。这就好像魔戒是爆炸产生的,但并不意味它没有创造者。这意味着创造者的日程安排要早与被造者的。

    如果神像作者一样创造宇宙,那么最好的观看他的作品的地方就不是爆炸的边缘,而是故事的中心。我个人确信耶稣站在这个故事的中心。只要你想看,而且不被各种人为你制定的日程搅扰,也不会落到陷阱里面(认为神应该是个公式而不是人),证据就在那儿。所有人的组织都会化为乌有,也都会给你一个用来判定你是否属于他们的公式。通常这些公式叫做教义或者传统,他们里面都有些价值,这是为什么每个人类文化都有价值。但是他们都有些跑题。

    “系统神学”是一个悖论。神不是一个系统。基督徒喜欢问:“这个情况耶稣会怎么做?”不幸的是,他们很少会得到正确的答案,这就是:“没想到的事情!”如果创造者真的把他自己写到故事里面,那是我们希望看见的。创造性的解决方案。

    这个创造性是可传播的,我们应该是有创造性的,而且我们应该创造性的去帮助别人。

    而且这就终于回到你问题的最后部分,那就是这些和 Perl 有什么关系。

    很明显 Perl 是我为了帮助别人有创造性而产生的。我还有个小小的心愿就是帮助人们更多的认识神所喜欢的人。

    进一步说,我们都认为故事应该以情节为主,而不是开头结尾。这也和我的语言学家的见解相合:事情应该是用原型来定义而非公式。这也就是为什么我拒绝定义“好的” Perl 程序员是什么样子,或者谁是“ Perl 社区”的成员,谁不是。这些事情都是以他们的内心来判断,而非外表。

    TMTOWTDI (总有其他的办法来做)这个哲理是因为观察宇宙的创造者是个谦卑者,选择用隐密的方式来工作而非强力操纵。宇宙不是像机器一样被强加约束。创造性的人可以自己建立喜欢的样式。正是这样的人将要使天堂成为更美好的地方。

    最后,有个信念是这样,如果你真的从科学和宗教的核心来定义他们,就不会冲突。所以在所有的 Perl 文化的“宗教性”以外,你们还可以相信计算机科学带来的好处。我不是为了人们会跳起来唱哈利路亚才把词法变量和闭包加到 Perl 5 里面去的。(虽然有时也会发生这个,但不是我的目的。)

    好,现在我们来唱诗篇第42章。

    问: 谢谢你 Larry by wdr1


    和其他许多人一样,我喜欢 Perl 。我在工作和其他时候都使用 Perl。你不但帮我们找到了一个职业,还给我一个很愉快的回忆。我在想怎么才能表达我的感激呢?我能给你钱么?或者捐点什么给某人?

    新版的 Programming Perl (骆驼书)出版的时候,我已经不需要了( perldoc 万岁!),但是我想确保有办法给那些卓越的设计者一些资金上的援助。请问我在说感谢的话以外还能干什么?

    答:


    好及时的问题!你一定是那些教会里来的,他们总是在布道之后立刻开始传递奉献碟子。:-)

    其实哪怕只是说感谢的话也很好。但是如果你希望更多的帮助我们,有很多的地方去捐献金钱和时间。不幸的是,若你要奉献时间,你要额外再花点时间在各种兴趣小组里面,直到你发现其中最有趣的。重视对 Perl 文化的贡献也是 Perl 文化的一部分,所以不要因为你的奉献不怎么技术性就放弃了。我们不是那样来运行的。

    捐献金钱很容易(当然你要有钱的话)。给 Perl Foundation 的捐献可以抵税。我这些年的工作很多是因为 Perl Foundation 的赞助才能进行下去,尤其是我的全职编写 Apocalypses 的任务。如果你能说服你的公司来捐助,这个时间上(有时候是耐性上)的投资非常值得。这里请让我向所有曾经捐赠的人表示诚挚的感谢。这个节目就是因为有了你们这样的人才精彩。

    问: Perl 6 的生态圈 by maraist


    perl 1 到 5 都是非常好的 UNIX 配置/管理语言。这还包括了小规模的网站服务器。如此丝丝入扣的设计使替换它变得非常困难。它非常巧妙把运行速度,功能,简易性和哈夫曼编码结合到一起(特别是它还提供了和 UNIX 工具很好配合的感觉)。

    另一方面, Perl 6 可能会改变这个平衡,它更加注重提供一个通用的解决方案,因为更多抽象性的加入可能会削减性能,还在语法上明显的远离了 Unix 大家庭的传统,主要是 C 语言的传统(冒号,问号, select ,异常处理,等等),还有 awk/sed 的 reg-ex ,以及原始的 C 语言库包等等。要知道正是这些相似性使得一个懂得 CIS 和 UNIX 的人学习 perl 如此简单(以至于只需要花两天就能掌握)。

    我的问题是: perl 6 所要面对的领域是什么?还是他越来越专一的去和 Java/python/C# 竞争,以至于丢掉了自己的大本营呢?

    答:

    绝妙的问题。我喜欢那些进化论生物学家对生物群的讨论方法, 生物的进化是有目的的:“我想进化出一对翅膀变成一只鸟......”。尽管对 Perl 来说,我的心中总是有些期望的(其他人可能觉得还不够),更不要说其他 Perl 程序员了。把 Perl 想像成一个生物来讨论是很有趣的事情,或者想像成一个小说中逃离作家意愿的角色,就好像这句话一样。

    无论如何, Perl 从开始就没有满意于任何一个生态环境。从进化论的角度来讲那是很不健康的一种演变,特别是生存环境在消失的时候。直到目前为止 Perl 还是很幸运的选择了一个很好的生态圈来生存,但是如果某一天这个地方衰败了,这对我们来说不但是可以预计的,甚至是可以期待的。可能我们现在没有还是在枝头荡来荡去也得归罪于生态恶化。(当然也有的人还在枝头,但是他们通常不会出现在 Slashdot 上面,不过有时候也可能反过来)

    Perl 开始只是一个字处理语言(更好的 awk 和 sed ),但是它很快就扩展到系统管理的生态圈。在 Unix 来说,起码大多数的系统管理都是文本处理。到了第三版的时候,我们在 Perl 中加入了处理二进制数据而离开了文本处理的生态圈。 Perl 4 不经意的从系统管理生态圈扩展到 CGI/Web 的生态圈。 Perl 5 进一步成为可扩展的胶水语言从而加速了这个趋势,这就出人(我)意料的使网站可以把数据库的内容挂在各种基于文本的 Internet 协议里面。

    但是如果你担心 Perl 努力进入一种 “擅长做每件事”的生态圈的话,这确实是 Perl 5 出来以后才有的一种想法。不管怎么说,在你把一个语言弄得很完美前是没法给它加入面向对象的特性的。;-)

    认真的说,我觉得对很多现在在使用 Perl 的人来说,他们所在的生态圈早就被标明是“每件事”了,当然可能还差一点。对这些人来说,想要让 Perl 适合做每件事早就不是问题了,他们早就乐此不疲了。也正是这些人正在积极的把 Perl 带到一个个新的生态圈。我只是要让 Perl 成为一个胶水语言,其他人却把它用来点燃 Web 。 Perl 6 的一个隐含的设计目标是要让 Perl 成为最好的培育小程序成为大应用的语言。但是人们肯定会用它来搭建/甚至创造一个新的生态圈。我希望能够再一次被惊讶到合不拢嘴,好像 Web 的那次一样。但是我也可能完全错误。

    问: 怎么才能让人认真对待 Perl ? by kin_korn_karn


    我是一个每天使用 perl 的程序员。尽管我们这里很多人都熟练的使用它,我们的 C?O (CTO 或 CEO ?) 类型的人却下令舍弃 Perl 。新的标准是用 Java 来做 web service 和其他类似无用的东西。这让我难过,因为 a) 我个人喜欢 Perl b) 我明白 Java 只不过是一个痴狂的搭建各种笨重无用的服务器框架的语言。

    我们公司那些坐在高位子上的科技人员也不认真看待 Perl 。他们把它当成超级 awk 或者 web 时代初期的一种手艺。聪明的人知道的多,但是我们不在那个位子上来作出决定。

    你认为如何才能让人们重新认识到 Perl 是一个严肃的编程语言?你对 Perl 的推广有负担么?

    答:


    好了,如果 Java 真的是一个疯狂的玩具语言,我们就不需要做什么来击倒它了,我们做了么?:-)

    先不说 Java ,我的目标是要让 Perl 更加实用。当然如果人们都因为人为的原因不再用 Perl 的话,肯定没法让它更加实用。所以需要有人去宣传。可惜的是,相比于理性探讨,人性总是更容易被鼓动蒙蔽。

    无论如何,我的职务都不是拉拉队长,而是确保 Perl 的设计实用。我的所有直接目标中没有一个是要“被重视”。不论怎么说,我更注重动量而非重量。这多少也使 Perl 倍感愚钝。但是只要 Perl 真的实现了它所应有的东西,酒香就不怕巷子深。如果生态圈是自然的,自然也不容真空存在,那么生态圈里也不应该有真空。我盼望着听到未来十年到二十年里面真空被 Perl 的空气填满的声音。

    网友留言/评论

    我要留言/评论