Python培训之浅谈Python和Ruby的对比优势和劣势

2018-04-16 13:09:26 401浏览

一、异同对比选择

1、Python和ruby的相同点:

都强调语法简单,都具有更一般的表达方式。python是缩进,ruby是类basic的表达。都大量减少了符号。

都是动态数据类型。都是有丰富的数据结构。

都具有C语言扩展能力,都具有可移植性,比perl的可移植性更好。也都可以作为嵌入语言。

都是面向对象的语言,都可以作为大项目的开发工具。

都有丰富的库支持。

也有最宽松的版权许可,除了一些工具属于GNU世界。

都有lisp特色的eval函数,也都能把函数作为参数。

也有图形界面的ruby的专门编辑器。

都获得了广泛的c库的支持。如qt、gtk、tk、SDL、FOX等,ruby计划实现SWIG接口。

都有完善的文档。

2、和python相比ruby的优点:

具有正则表达式和嵌入html的功能。python也有正则表达式,但没有ruby的应用方便和广泛。python的嵌入html项目才刚起步。ruby还有apache的mod模块。ruby本身也实现和很多unix工具,如racc,doctools。比python更亲近Linux。

比python功能更完整的面向对象的语法。

ruby的整个库都是具有类继承的结构。

他的基本的数据类型和运算符都是可以重载的。

ruby主要的功能都是通过对象的方法调用来实现的,而不是函数。python也在向这方面发展,但没有ruby做的彻底。

ruby的类是更规范的单继承,还有接口等概念的实现。

python可以实现在列表内的条件语句、循环语句,而ruby用“块”的方式来实现这个功能,比python的更灵活,更具有通用性。

ruby具有类似lisp的彻底的函数方式的条件语句、循环语句等。语句的表达能力更强。

附带一些unix工具,如racc等。

3、和python相比ruby的不足:

最大的不足正是因为ruby的强大所引起的。它没有python的简单性好。比较复杂的面向对象语法、“块”语法的引入、正则表达式的引入、一些简写标记都增加了语言的复杂性。

python的缩进表达方式比ruby的basic的表达方式更让人悦目,ruby程序的满眼的end让人不舒服。当然,ruby认为end的方式比python更先进。

ruby还没有python的“自省”的能力,没有从程序文件中生成文档的能力。

ruby没有国际化的支持。国际化支持在ruby的计划中。这是因为ruby的历史比python要短造成的。

ruby没有类似jython的东西。

4、python和ruby的语言的选择:

从简单的就是好的来说,选python是没错的。python适合寻找简单语言的人,这很可能造成python更流行,因此也有更多的支持。但如果要追求更强大的语法功能,则ruby是好的选择。因为ruby和python的哲学有很多相似的地方,先从python入手,尽量用python,如果python的能力不足了,可以在找ruby。

ruby和python的比较,就像五笔和拼音输入法的比较。拼音作为入门的输入法和长久使用的输入法都没有问题。五笔适合更高要求的情况。如果追求性能的不妨学学ruby。对编程语言感兴趣,想了解各种编程概念的学ruby也会很兴奋。


二、两者各有特点:

1、Python从语法上来说更质朴一些,而Ruby更性感一些

Python的语法相对其他脚本语言来说,没有太多花巧的地方,显得比较死板一点,其实从Python强制代码缩进也可以看出来Guido设计语言的取向。语法死板的一面就是不容易玩出来更性感的东西,比方说Rails这样的框架,另外Python也无法做DSL这样的事情,但是语法死板的另一面就是比较规范,相对来说,更加适应软件开发的工程性要求,更容易组织大规模的团队进行开发。

Ruby的语法非常灵活,Matz设计ruby的出发点也是为了coding for fun,因此可以用ruby玩出来很多花样,运用足够的技巧,可以用Ruby写出来逼近自然语言的DSL,对于程序员来说,玩ruby确实充满了乐趣。Rails能在ruby社区诞生,而不是Python社区诞生绝对和编程语言有直接的关系。不过ruby语法灵活的另一面就是编程实现风格的多样性,这对于大规模团队的协作和管理是一个挑战。

2、Python的解析器实现更成熟,第三方库质量高

Ruby1.9解析器尽管已经有了很大的性能提升和很多新的功能,但是从源代码实现的角度来说,基本上是通过在Ruby1.8源代码上打patch来增加功能的。从源代码的结构来说,Ruby的实现太古老了,Ruby扩展起来比较困难,只能不断打patch。这也是为什么现在Ruby社区涌现出来那么多新的Ruby解析器实现的原因。从很大程度上来说,这制约了Ruby的发展速度。相对而言,Python解析器更成熟,也比较稳定。

在第三方类库的数量上来说,Ruby并不比Python少,但是高性能高质量久经考验的第三方类库Python要明显比Ruby多,事实上很多Ruby的第三方类库都不太成熟,因此这也很大程度上制约了Ruby的发展。

3、Python的应用领域非常广泛,而Ruby目前主要局限在在Web领域

Python应用的领域非常广泛,除了web开发以外,还被广泛用在服务器后端的高性能服务器实现,服务器后端的各种密集运算,全文检索,各种文本处理,系统管理等等,另外桌面应用领域wxPython也是一个很成熟的跨平台GUI框架。对于某些特殊的应用,比方说调用操作系统内核API,Python也可以完成的很好,比方说大量小文件的实时同步方案,就是用Python直接调用linuxKernel的inotify特性来实现的。所以可以说Python是软件开发领域的瑞士军刀,什么事情都可以做。

正是由于Ruby解析器和Ruby类库的制约,Ruby的应用主要局限在Web开发领域,目前Ruby的应用还无法延伸到web开发领域以外的很多地方。据说豆瓣早期就考虑过Ruby on Rails,但是因为Ruby不能做其他事情,而Python可以大包大揽,最后放弃Ruby选择了Python。

4、在Web领域Ruby是王者

随着互联网应用更进一步渗透到软件开发的各个领域,其实web开发占整个软件行业开发的比重也是越来越大。尽管Ruby在其他领域很受制约,但是在Web开发领域就是绝对的王者了。Rails框架的领先程度已经远远甩开了任何一个潜在的竞争对手十万八千里。因此尽管Ruby可能有这样那样的问题,但是说到Web开发,Rails几乎就是无可争议的唯一选择。

而Python尽管十分全面,却偏偏在web开发领域不彰,web框架虽然众多,却没有一个真正可以挑大梁,Django虽然在Python社区比较流行,但很多方面也有缺陷。现在的互联网应用往往都是多种语言混合编程,Ruby在Web以外的缺陷也可以用其他语言来弥补。

5、Python的包管理不如Ruby

尽管Python的第三方类库更高质量更成熟,但是Python社区缺乏Ruby Gem这样一个良好的包管理软件和包发布的网站。因此应用的构建显得不如Ruby那么方便,那么人性化。特别是在类库的版本升级上,就会遇到很多麻烦,不如Ruby Gem那么简单。

不过总的来说,Python和Ruby还是相似度极高的两种编程语言,即使两种编程语言都学习一下也不会浪费太多时间。如果我个人选择的话,会首选用Rails来构建web应用,再根据情况选择Python或者Java处理一些服务器后端的运算。总之,未来还是一个混合编程的时代,我们需要多了解一些编程工具,然后根据需要看菜吃饭才行。

三、《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,据说用的就是这个。如果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了吧,少了一种选择,聚集一些人气总是好的。


以上就是关于Python培训之浅谈Python和Ruby对比优势和劣势的详细介绍,最后想要了解更多关于Python发展前景趋势,请关注扣丁学堂Python培训官网、微信等平台,扣丁学堂IT职业在线学习教育平台为您提供最新的Python视频教程系统,通过千锋扣丁学堂金牌讲师在线录制的Python视频教程课程,让你快速掌握Python从入门到精通开发实战技能。扣丁学堂Python开发工程师技术交流群:279521237


扣丁学堂微信公众号



关注微信公众号获取更多学习资料



查看更多关于"Python开发资讯"的相关文章>

标签: Python视频教程 Python基础教程 Python爬虫 Python培训 Python开发工程师
扣丁微信
扣丁小程序
15311698296

全国免费咨询热线

邮箱:codingke@1000phone.com

官方群:148715490

北京千锋互联科技有限公司版权所有   北京市海淀区宝盛北里西区28号天丰利商场4层
京ICP备12003911号-6   Copyright © 2013 - 2018
返回顶部 返回顶部