Re: [PerlChina] 关于PERL和PHP的融合的思考

truncatei Wed, 30 Dec 2009 06:31:01 -0800

这两天没怎么看信，错过了各位的讨论。

我觉得我们在讨论的问题集中在怎么把Perl用来作为一个简单易用的web的基础，能够像php那样拿起来就用。感觉这样看不外乎POST/GET，加CRUD的逻辑。


我一直固执地认为语言是否适当是和怎么“用”密切相关的，用不好的话再好的语言也白搭。
当一个团队选择一种语言来实现WEB端的时候，如果选择的理由不是出于对这门的语言的掌握和把控能力，那么这种理由显然有些站不住脚。
比如说PHP简单，团队的成员能很快上手，但是缺少全局的控制，最后的结果可能会是非常混乱和难以维护的代码。

Facebook的web是php的，就一套程序，一次升级部署n台服务器(n是3位数或者更多)。
LJ/MIXI和其它一些的web是Perl的。国内很多都是Java的(我现在工作中维护的也是)。

Nginx我也在用，它用到epoll这样的新内核特性，流水线处理方式，并发能力相对Apache的提高是成倍的。

应该很多人看过《Perl最佳实践》，推荐没读过朋友也看看 :)


在 2009-12-29，上午11:22， [email protected] 写道：

> 反�g：我�]有�X得�e人搞的�|西都不可靠啊。我�f的��http服�掌骱涂蚣芙y一用perl��的目的：����只是想毒害下一代程序�t而已。（��人�x得那�拥脑���起web服�掌鞫顺绦��砗芎��危�比如serialize到�r就不需要了，因�橹灰�web服�掌鬟�在�\行，你就可以保存一���ο蠼o所有的http��求使用。��然，...@�右灿胁缓玫牡胤健１热纾喝绾����b�d入一��模�k，多��站�c同�r�\行�r如何�_保多站�c�g不�_突...）
> CPAN�_��是好，支��Perl到�F在的��大�恿��o疑就是它。
> web�_�l到�f在服�掌鞫说募夹g含量已��很低了，php能�俪鼍驼f明了...@一�c。用perl�碜瞿切┰��h查改，�f有perl提供的方案��是太�碗s了。太�^于追求模�k化的同�r���适У艉���性的。
> 就...@�印�
> 
> 2009/12/29 flw <[email protected]>
> 性能我没有测试过，即使有性能的差别，这也是实现时造成的问题，
> 并不是模块化的坏处。（当然 CPAN 上的模块良莠不齐，在所难免）
> 至于警告么，我觉得需要就事论事，有些警告是程序员的问题，有些警告是模块自身的问题。
> （Perl 序列化可以用 http://search.cpan.org/~ams/Storable-2.21/Storable.pm）
> 
> 我不懂 web 开发，可以请擅长的朋友们详细阐述一下 PHP 和 Perl 在 web 开发时的性能问题，
> 以及这种性能差距假如存在的话，是否有可能在 Perl 内部解决掉。
> 
> 我的想法是，Perl 应该不会比 PHP 慢，如果真的慢，那么应该是 mod_perl 的实现问题，
> 只是单纯地搞一套 Perl 库出来应该无济于事。
> 
> PHP 从语言的角度讲，实在算不得上是一种设计优美的语言（平坦的名字空间，含糊的冗余的内置函数）。
> 没有 CPAN 是它的劣势，不是它的优势，PHP 社群这两年也在搞类似于 CPAN 的东西，足以说明这一点。
> 
> 事实上就我接触过的语言来说，大多都缺乏一个像 CPAN 这样运作良好的模块中心。
> 近年来 PHP Erlang Haskell 等也都在搭建类似于自己的 CPAN 这样的东西。
> 
> 小林和 alex 提到的感想，是许多老一辈程序员（尤其是另一些 C 程序员）经常会有的想法，
> 他们往往觉得别人搞的东西都不可靠，只有自己从零开始搞出来的东西才可靠，
> （于是 PHP 诞生了，nginx 诞生了）但是对于大多数新入门的朋友们来说，
> 能够有更多的模块来复用，在这些基础上快速地构建自己的应用，实在是一件乐事。
> 只是，过了新入门这个阶段之后，还是应该深入了解一些东西，这样就可以在使用第三方模块的时候，
> 又不为它们所制约，逢山开路遇水搭桥，有 BUG 就改 BUG 有不足就重写之。
> 我在使用 Net::SSH::Perl 的过程中尤其感受到这一点。
> 2009/12/29 Lin <[email protected]>
> 
> 除了写法不同，性能也会有不少差异。
> 我们经常能看到很多 PHP 脚本拿 serialize 和 unserialize 来做数据库缓存以减少 SQL 查询，
> 而在 Perl 里面要达到这个效果，你就不得不搬出一堆模组，并且可能有这样或那样的警告，非常不方便。
> 
> 2009/12/28 flw <[email protected]>
> 
> 我觉得这个只是写法上的不同吧。
> Data::Dumper 本身也是 Perl 标准发行版的一部分，
> 基本上不需要你另行安装的。
> 
> 更何况 Module 本身也是软件工程发展的方向，
> 如果什么都要集成，那就会像 PHP 一样，有很多重复的功能。
> Perl 就已经够不正交的了。
> 
> 2009/12/25 Lin <[email protected]>
> 比如 Perl 大家经常会用：
>  
> use Data::Dumper;
> print Dumper( ... );
>  
> 而在 PHP 里面，可以有：
>  
> var_dumnp( ... );
> print_r( ... );
> serialize( ... );
>  
> 等等，这是很明显的区别。
> 
> 
> 

--

您收到此邮件是因为您订阅了 Google 网上论坛的“PerlChina Mongers 讨论组”论坛。
要向此网上论坛发帖，请发送电子邮件至 [email protected]。
要取消订阅此网上论坛，请发送电子邮件至 [email protected]。
若有更多问题，请通过 http://groups.google.com/group/perlchina?hl=zh-CN 访问此网上论坛。

Re: [PerlChina] 关于PERL和PHP的融合的思考

回复