哎！大家说实话，Perl的发展前景究竟如何？

[anticlockwise]

学不会pl的 fanhe, 我围观。

口水战没关系了。热闹下嘛。

ls这，，，居然带5个e。 nnnnnnnd

弯弯，回家我给你补pl的课。 省得去那边，被人看低。 你问下哈皮就知道为什么会被人看低了，他有经验。

pcre 是事实标准。pl 是unix的根基。打不死的小强。


大家继续掐架。

切～～～我的三个面试都是用的Python写程序，用Perl人家还不愿意类～～

我还是会Perl滴，HOHO，现在这个公司用的Perl，木有办法啊～～

[leeaman]

NNNNNNND,踩一脚,死ee占上风了,开玩笑,我踩我踩我踩踩踩

[qy117121]

NNNNNNND,踩一脚,死ee占上风了,开玩笑,我踩我踩我踩踩踩

[remeber]

这贴歪了。药味出现。

[cheeselee]

习惯用法太多，用perl好好写的话，也可以写出很好的代码，可惜这种是靠个人修养的，语言本身没有这种保障

use strict;
use warnings;

甚至语言本身有鼓励你去写难维护代码的倾向，

从哪里看出来的呢？

python呢，模块一开始不多，python是搞一个核心团队，专门整了个标准库。。。。。有个标准库我个人觉得还是很有意义，不要打开个文件就有各种方法。。。。

Python 有一个巨型的标准库，多数 Python 模块只会依赖标准库，而不会再需要别的非标准库模块，最著名的例子就是 Django。这点设计理念接近于 Windows。当然现在有了pypi之后要处理依赖关系也很方便。
而 Perl 的标准库很小，常用的CPAN模块很少会依赖只标准库，而通常都会有一堆依赖关系。这点设计理念接近于 Unix，Perl 程序员通常对重复发明轮子(reinvent the wheels)很反感。

而且perl的oop是很难看的

这是因为 perl 的 oop 系统比较自由。而现在有 Moose 可以写出漂亮严谨的 oop。

（模块撰写本身就很恶心，比如末尾非要留个1

这是语言一致性的体现。

，名字空间的管理也很难看）

Perl的是显式的、绝对的 namespace，而 Python是隐含的、相对的 namespace。可能各有所爱吧。

perl内联c也比较麻烦，没有标准的FFI，xs那时候我也比较柴，没好好读过文档。。。

嗯，Perl 的 FFI 不成熟是事实，但是Python也没有像XS那样便利的扩展手段。当然，Python和Perl都可以用SWIG。

专业领域的话，比如生物信息这块的话，倒还是perl绝对优势，其他方面对python大有优势的倒不觉得。

Python语法简明，但也造成 Python 从语言本身来看缺乏特别的长处，所以 Python 好像什么事情都可以做，但目前并没有在任何一个领域占有绝对优势
Perl 虽然也是全能，但在文本处理上特别便利，所以才能在生物信息领域占据绝对优势。

从9.04到10.10，我个人感觉ubuntu里应用越来越倚重python了。。。

嗯，现在 Python 写的 GUI 程序明显比用 Perl 写的多。

[cheeselee]

这贴歪了。药味出现。

如 ee 所说：

口水战没关系了。热闹下嘛。

[tangboyun]

use strict;
use warnings;

够吗？远远不够呀!!这个标准只是合格而已，把perltidy（Perl::Tidy）和criticism（Perl::Critic）开高（level3以上），出来代码没warning才说明写的规范。要觉得自己写的代码不错的，可以try下看有多少warning哦～～

从哪里看出来的呢？

perl为啥要有use English？还有就是没事就省略缺省arg，关键是用法还和脚本非常相似（但又有很多小细节不一样），好了，似是而非的东西是最讨厌的了。

这是语言一致性的体现。

这是模块系统本身的缺陷，必须要保证最后个表达式是eval true的。

嗯，现在 Python 写的 GUI 程序明显比用 Perl 写的多。

为啥捏，根源是python的oop系统和c/c++很接近，就比如PyQt，和c++的Qt之间很相似。

[cheeselee]

use strict;
use warnings;

代码： 全选

够吗？远远不够呀!!这个标准只是合格而已，把perltidy（Perl::Tidy）和criticism（Perl::Critic）开高（level3以上），出来代码没warning才说明写的规范。要觉得自己写的代码不错的，可以try下看有多少warning哦～～

Python 有 Perl::Critic 类似的东西吗？

perl为啥要有use English？还有就是没事就省略缺省arg，关键是用法还和脚本非常相似（但又有很多小细节不一样），好了，似是而非的东西是最讨厌的了。

Perl是既可以像写 shell 一样简练，又能使用严格并显式的函数定义。
而且 Perl 的最根本设计理念就是对 context 敏感和支持默认参数（$_)，如果否定了这一点就相当于否定了 Perl 的全部。

这是语言一致性的体现。

这是模块系统本身的缺陷，必须要保证最后个表达式是eval true的。

因为 Perl 本来就没有一个特别的“模块系统”，模块（首次）载入其实只是运行一次外部脚本，所以当然希望这个外部脚本最后返回值 eval true ，说明脚本正常运行。

嗯，现在 Python 写的 GUI 程序明显比用 Perl 写的多。

为啥捏，根源是python的oop系统和c/c++很接近，就比如PyQt，和c++的Qt之间很相似。

我觉得原因主要还是因为 Python 的语法简明。
其实 binding 和原生库一般都很相似的啦，不管是哪种语言的 binding，要不然怎样叫 "binding"。比如写 wxWidgets 的话，不管用 Python 还是 Perl binding 来写，只要看原生C++的API就够了，因为原生API在 Python 和 Perl binding 中的对应关系很清楚。

[ykk23]

还是python有前途

[tangboyun]

Python 有 Perl::Critic 类似的东西吗？

这倒真不清楚了，我对Python了解不深。类似功能的工具里，印象最好的是Haskell的hlint，连修改建议给的都很全。

Perl是既可以像写 shell 一样简练，又能使用严格并显式的函数定义。
而且 Perl 的最根本设计理念就是对 context 敏感和支持默认参数（$_)，如果否定了这一点就相当于否定了 Perl 的全部。

Context敏感要看是基于什么的，Perl本身是个弱类型动态语言，所以它的上下文推断是error-prone的，这也是为啥当初搞perl6的时候，唐宗汉（现在叫唐鳳）觉得Haskell（强类型带类型推断）有许多Perl6理想中的特性（我也是因为这个才会对haskell产生兴趣，现在是最喜欢的语言），然后鼓动一大批perl hacker包括Larry Wall本人去研究Haskell。Perl的设计风格，受到教主（Larry Wall）影响太大，它自己是搞语言学的，结果搞的Perl的风格很奇怪，Perl的习惯用法就像一直在说些外行（指其他语言程序员）听不懂的“行话”“黑话”，拿来装b是不错，要拿出来推广和维护就不行了。

因为 Perl 本来就没有一个特别的“模块系统”，模块（首次）载入其实只是运行一次外部脚本，所以当然希望这个外部脚本最后返回值 eval true ，说明脚本正常运行。

这只说明了一件事：在Perl中，Exception handle是很薄弱的。。。

[tangboyun]

还是python有前途

没什么前途不前途的，其实学起来都很快的，python属于那种抓起手册就可以写的那种，因为没有门槛。。。。事实上就个人而言，我觉得学一门没门槛的技术，比较没有保障。。。。

[lilydjwg]

那你也不太适合写 C/C++/C#/JAVA/PHP 了，就做 Python 的小白吧

Python 和 C/C++ 适应的任务不同。想快速地完成某件事，当然不希望有分号来烦人了。想写个精致/高效/宏大的程序，别说个分号，调试和测试的时间比写代码的时间多得去了。至于 C#/Java，我承认我不适合。PHP 嘛，都有那么多 $ 了，也够烦人的，所以我一直还没学。

这未免说得太轻松了。
当玩具的话那当然升级一下很轻松，但你的库呢？

不好意思，我的库都是 Python 3 的

[lilydjwg]

其实 binding 和原生库一般都很相似的啦，不管是哪种语言的 binding，要不然怎样叫 "binding"。比如写 wxWidgets 的话，不管用 Python 还是 Perl binding 来写，只要看原生C++的API就够了，因为原生API在 Python 和 Perl binding 中的对应关系很清楚。

你这是在否认 lxml 么？

[jtshs256]

支持掐架

尤其支持ee参与…

[cheeselee]

其实 binding 和原生库一般都很相似的啦，不管是哪种语言的 binding，要不然怎样叫 "binding"。比如写 wxWidgets 的话，不管用 Python 还是 Perl binding 来写，只要看原生C++的API就够了，因为原生API在 Python 和 Perl binding 中的对应关系很清楚。

你这是在否认 lxml 么？

那 binding 的作者还是有自己的自由的啦，特别是对一些非OOP的库加上OOP的 binding，这是很常见的事情。