|
Python和Ruby的对比，纠正一些误解 下面是我在看两篇关于Python和Ruby对比的文章时，所作的纠正，原文都是广泛流行的，比较好找。 ------------------------------------------------------ 《ruby和python的比较》更正一点事情 1、文档、开源项目、库支持，这些东西Ruby不要跟Python比，不是几个数量级的问题，何必貌似并列的排在一起。 2、Python确实没有把正则表达式模块内置到核心里面，但是却有re这个标准库的支持，当时的目的也是为了尽可能的把核心做到最小。我不太明白，使用标准库和内置有什么区别，甚至可以作为优点？且使用Python中的正则表达式也不过是多个import re和调用时的几个字母而已，省下的无数个end足以抵销这个问题了。 3、至于嵌入HTML功能，Python里有C/Python双实现的Cheetah模板可用，据说托Zope的福，美国海军和法国政府在用，不知Ruby这个功能的成熟度如何？ 4、mod_ruby模块的出现时间很短，如果作者没有听过mod_python那就实在孤陋寡闻了。我在一年前翻译mod_python3.2.8文档的时候，mod_python已经很成熟了，以至于几乎所有的Python WEB框架都支持构建在其上来提高效率。但是，似乎mod_ruby的更新，每年也只有几次。mod_python更有gnu.org这样的重量级应用，不知mod_ruby有没有？ 5、另外，提到unix工具。Red hat Linux的安装程序一直是用Python写的，如果你恰巧用ubuntu，那么，那个提示你更新系统的程序，也是用Python写的。 6、racc和doctools，请原谅我的孤陋寡闻，我google了一下居然除了你的这篇文章还没找到几篇关于racc的中文内容，辗转之后才查到是一种类似yacc的工具。从google的角度讲，racc的可用性我就不多说了。我不太明白一个yacc工具在日常编程当中有多大的实用性，但是既然作者提到了我就顺便找了个我只听说过名字，根本没用过的spark。google的结果是"racc ruby":"python spark"=159,000:659,000。至于doctools，我更是无话可说，在google上只有15,800条记录，我到现在都看不出这个东西是干什么用的。所以找了个估计是类似的东西对比了一下，docutils，google的记录是25,400条。 7、“比Python库更完整的面向对象语法”。试问面向对象的目的是什么？再者，ruby能否像Python一样，绝大多数标准库根本不需要查文档，只要猜测一下大体上的名字，然后dir()一下，再help()一下就可以直接上手，用到第二次的时候，因为模块内东西实在太少，记忆太方便，就可以直接写出来的地步？另外，面向对象既不是什么银弹，也不是最先进的软件工程思想。 8、"ruby的整个库都是类继承结构的"，个人认为是Java的糟粕，反倒是当成宝学过来了。或许这也是ruby来拯救Java程序员的一项优势吧。 9、"基本数据类型和运算符都是可以重载的"，这个不是太清楚，不知Python中重载__add__之类的算不算。 10、"ruby主要的功能都是通过对象的方法调用来实现的，而不是函数"，Python中所有的东西都是对象，但并不都是类，不知这句还有什么意义。另外，推荐你不要太追求什么彻底，还是实用这个词比较有吸引力。 11、Python没有严格要求单继承是给程序员以灵活性。另外，关于接口，Python中只要定义了同名的函数就算是具有了相同的接口，玄学上升到了这个高度，我也有些迷糊了。至于接口，不要那么自信，ruby的所谓接口也不过是个mix-in。这个东西Python的几个大项目中也有过实现，只是因为对Python意义不明显，所以才没有更多的使用。 12、关于lisp的函数式编程，Python中有很多内置支持，如map、zip、filter等等，当然还有lambda。不要说支持，我们谈实用。Pythoner中尚且有些人认为函数式编程影响了代码可读性而尽量避免呢。所以，你认为支持什么东西之前，先想好这样东西算不算是个好东西。 13、"最大的不足正是因为ruby的强大所引起的"。这句真恶心，不予评论。 14、呵呵，ruby居然没有国际化支持，真是个笑话，不知道当初那个小日本怎么想的？难道他英语过了四级？ 15、至于jython，现在也有了jruby，可能是作者的原文比较早的缘故吧。Python也有很多种实现，像是jython, ironpython, pypy, pyrex等等。Python的优秀其实并不一定要通过用其他语言来实现才能体现出来。当然更不要说寄希望于要Java来解救水深火热中的ruby了。 另外么，有些ruby的缺点不要回避： 16、ruby没有本地化线程，而是用的伪线程，根本无法利用多核CPU的优势。CPython使用了本地化线程，但是因为使用了GIL所以也是无法利用多核CPU优势的。但是Stackless的出现完全可以解决这个问题，并且stackless更是将Python提高到了并行计算的高度，这个高度的竞争对手可以是Erlang，ruby自然不必窥探。其中的超轻量线程技术可以确保一台很烂的机器上跑几十万的线程还很轻松。基于Twisted的异步编程方式也提供了一种选择。 17、刚刚开始学Python的时候，就听说过一句“Python是主流动态语言中最慢的”，后来才知道，说那句话的人根本没把ruby放在眼里。如果把ruby也算进主流动态语言里，那么就会出现一个比Python还慢了一个多数量级的语言了。 18、ruby流行么？是不是要走向PHP？PHP是个好东西，但是问题在于他只能作WEB编程，限制了PHP的应用范围，稍微需要系统一点的东西就要借助于C。而现在的ruby似乎也就是走着这条路。直到有一天，有人爆料"ruby是可以做客户端编程的"，赢得大家一片好奇。况且现在的ROR能否取代什么还是个未知数。从Java WEB开发中解救出来的人们也并不都是走向了ruby。 ------------------------------------------- 评《选Ruby还是选Python？》 这篇文章看来传播的算是比较多的，至少我看到的是转载。文中谬误颇多，在此纠正一下，当然还有少许经典语句这里也要提及。 Python和Ruby的设计哲学确实有很大的差异，这个问题，我就不评论哪个更好了，各有所爱吧。至于效率，Ruby永远不要考虑跟Python相比。Ruby是伪线程，而且根本没有利用多核CPU的可能，直接pass。而Python使用native thread，仅仅由于部分模块不是threadsafe的而加入了GIL来限制应用多核CPU，而在我最近的测试中，在使用Twisted的异步线程之后，已经可以很好的利用多核CPU的计算能力了。执行效率上也不是一个数量级，自己试试就知道。 拿Java对比Python，可见作者创造力之强悍，哈哈。开源项目是很符合达尔文的自然选择的，难道Ruby的开源项目少倒成了优点了？另外，在Python中我也没见除了WEB framework之外有什么项目有太多的重复。举个例子，pypcap就已经基本淘汰了pcapy了。 谈到资源，Ruby还有很长的路要走，所以提到双方都很强的时候，麻烦不要太并列化了。至于Java社区的人倾向于学Ruby，我个人认为只是被Java折磨惯了的开发人员目光太狭隘所致。语言是工具，面向对象也是工具，纯粹的面向对象并不见得高明到哪里去，Python也有函数式编程的支持，作者怎么没有提到。另外，Python的很多做法是以开发效率为第一目标的而不拘泥于各类形式，甚至为很多智力有限的人所广泛诟病的C++中的多继承，Python也可以支持。问题不在于支持了什么让你不喜欢的东西，而是让尽可能多的人用上他们喜欢的东西。另外，一直被Ruby开发者所认为的Python不够OO的一个例子就是取一个序列的长度，Python使用len(x)的方法。这个问题，如果Ruby开发者认为x.length就可以算是OO的话，那么Python也大可以直接使用x.__len__()来获取长度。从用方法来封装属性的Java角度讲，谁更OO一些呢，哈哈。 Ruby是一个日本人的作品，呵呵，这个就不多说了，不喜欢日本的国人有很多，在此我仅在技术层面就可以把Ruby贬低下去，无须用非技术的东西了。 关于Ruby on rails，Ruby社区确实把几乎所有的精力都集中于此。但是这只能表现出Ruby的幼稚，事实已经证明了，ROR的很多模仿者已经推出无数的高级功能，远远超过了ROR，没有取代ROR只是出于先入为主的观念。如果现在的Ruby，突然失去了ROR又会是什么样子。至于作者提到的zend，居然用来跟ROR相比，有如以卵击石，我学过Python的2种WEB框架，平时也比较关注Python和Ruby的各种东西，但是zend这个东西，我是没有听说过的，不知是不是作者的作品，哈哈。如果一定要在WEB框架上有个较量的话，你可以用django,Quixote,mod_python之类的来比较一下。django，一个典型的ROR模仿品，还在成长，但是已经有很多优于ROR的功能了，而性能上远优于ROR自不必说。应用Quixote的douban.com是所有使用Python和Ruby网站中流量最大的，而且在相同硬件配置的情况下比ROR实现速度快了一倍还多，要知道去除WEB服务器等等的各种平等损耗之后，这可是要快上一个数量级的东西。至于mod_python，据说www.gnu.org用的就是这个。如果Ruby还想开源的话，那么就永远活在Python的阴影里面吧。 至于上手的速度，各个人有不同的情况，不作评论。至于灵活性所带来的东西，仁者见仁，就不要评论了。作者谈到Python的入门不容易，真不知Ruby有个何等容易。我初学Python时，第11天就用Python写了一个词法解析器，至今仍然在我博客上可查。所以，入门难度这个东西，每个人还是自己去试试为好，不必听别人怎么说。 提到ROR生成的目录有很多东西，要很久才可以都了解，这确实是IDE的综合症。在Python下，比较典型的例子是TurboGears，如果你希望了解整个应用程序的运行方式，你可以从核心cherrypy开始学习，然后开始使用TurboGears就没有什么可不了解的东西了。在这个角度上，ROR没有选择。再者，现在ROR可用的一种连接WEB服务器的方式scgi，当年也是Python的作品，又是一个在Python的阴影下活着的小东西。 未来的发展么，孤注一掷的Ruby还很难说，但既然是孤注一掷，风险还是蛮大的。而Python么，我也以为真的会平稳的发展，但是后来Micro$oft的加入，让我们都难以预料Python的未来到底有多大了。我们再回头谈谈作者一直讨厌的Python的多样性，在我看来Ruby可以超越Python的东西屈指可数，而Python超过Ruby的东西，自然是Ruby难以逾越的鸿沟。所以从编程语言的多样性考虑，也就不建议大家学Ruby了吧，少了一种选择，聚集一些人气总是好的。 |
|
|
