分享 自己最近写的几篇 blog: Python vs Ruby

5long · 2013年05月25日 · 最后由 zw963 回复于 2013年06月16日 · 9092 次阅读

时常在社区会看到编程语言的对比,自己也未能免俗,写了这么一系列四篇 blog 专门来对比 Python 和 Ruby。第一篇的开头是

身在一个 python shop,无法不怀念 ruby 的种种优越。

写到这里,胜负已分......

欢迎反馈。

共收到 43 条回复

语言的争论没啥意义。 选择顺手的语言才是正确的选择。

就吐槽一点,可以不要中英混搭好么? 有的地方直接说中文来的更精确清楚。

#2楼 @ugoa 收到。很多时候我都是觉得用英文表达更准确才故意用英文的 - -。混搭确实容易造成不必要的思维跳跃,会多注意。

就吐槽一点,可以不要中英混搭好么? 技术文章纯英文更精确清楚。

哈哈开个玩笑,语言之间没必要分胜负啦。

看评论貌似要挑起 Chinese V.S. English 的味道...

没办法吧, 名词没有对应的翻译必须混搭, 放代码必须混搭...

#6楼 @luikore 所以说应该纯英

楼主博客的布局。。 难道是我打开方式不对。。

@5long 我就是太纠结,两者都不用了,去玩node.js,世界安静了~

#9楼 @xieren58 目测你要被围攻了

扯淡,php 才是最好的语言

12楼 已删除

@bhuztez 围攻我干嘛,既然两者难选,那不如都不选了,~

#11楼 @search #12楼 @lidashuang

我也在Ruby和Python之间挣扎过,最近又开始用PHP了……

内部DSL一个缺点是调用栈可能很深,需要调试时颇不容易

任何一门语言的精通都是困难的,还是用熟一种比较切合实际。 我在转ruby前perl和python都用过,不过都不算熟,python的设计目标显然是简单易用,不过同大多数设计目的是简单易用的东西一样,如果你需要解决的问题本身就不简单,用简单易用的语言做到一定程度,早晚会发现实际上是简单易用的语言使得你解决的问题更复杂或者冗长了,因为表达受限…… 不过,单说简单易用,还得选python……

我也说下我的状况吧,我工作用python,但是自己也玩ruby,我特别喜欢ruby社区氛围~但是去玩node.js了,不再纠结ruby,python~

#8楼 @Tony612 是故意的... 博客一共就这么点内容,还是觉得应该内容为重。

而且我猜测以博客主要读者群体(程序员)的习惯,当页面上没什么可看的东西的时候应该会开始往没逛过的地方乱逛(也可能直接就关了页面了...),一眼看上去除了滚动到页面底端已经没什么别的去处了。这时底部导航大概还是能起到作用的(吧)。

#18楼 @5long 不是 我是觉得页面太偏左了吧。。 左右很不协调

#19楼 @Tony612 哦这个... 当时考虑的是,如果用户有一些总是浮在桌面顶部的窗口(典型的如IM),这些窗口往往都是在右侧。那么我的页面内容就占据左侧好了。

#20楼 @5long 哈哈 这个想法很特别。。

觉得python比较好的一点就是import比ruby的require要直接明白 用到的东西一眼就能找到,只要不import *

从实例自身开始解析

>>> class A(object): pass
... 
>>> a = A()
>>> a.x = lambda: 1
>>> a.x()
1
>>> 

#22楼 @krazy 模块系统这方面在我看来有些争议。

Python 的 import 更显式,而且每个模块有自己的作用域,可以不受外界干扰(EDIT: 按照下文所述,还是可能会受干扰,只是不到万不得已不会这么做)。而 Ruby 的模块系统借鉴自 Perl,所有文件共享一个作用域,相当于大家一起堆砌全局变量(虽然有良好的命名空间支持)。这样看来 Python +1.

但是现实世界中,拿 Python 的模块标识符当作全局唯一标识,藉此访问/修改全局状态的用例也越发地多了起来。比如 [Mock] 模块的 patch 方法,就依赖这种访问方式,甚至随着调用方的 import 方式不同,patch 的使用还要多加小心。我还看到有生产环境的代码:模块本身提供了类似于 Rails 中的一组 model 对象,然后这个模块提供一个 init 函数来允许用户传入数据库和 memcache 的客户端,而这个配置逻辑也是依赖了模块标识符的全局性的。这样看来,Python 的模块系统反而是在制造不必要的复杂度。Ruby +1。

所以既然有这样的争议,我就没有去写。只写了 Ruby 比较有把握完胜的 :)

#23楼 @bhuztez Yes and no. Python 虽然可以用“callable 属性”来模拟按实例多态(per-instance polymorphism),但这个 callable 并不像常规的方法那样可以拿到 self 作为第一个参数。虽然我们还可以用实现了 __call__ 的类,或者闭包,以及动用 partial 模块等方式来让这个方法访问实例,但是有这样的实现门槛摆在面前,开发者往往习惯上就不会积极地去使用了。至少我很少见到。当然我个人阅历也实在有限。

唔现在看来觉得确实应该把这一段加入到文章里去。并且也指出这种做法在 Python 社区并不多见。反观 Ruby 因为 eigenclass 的存在,统一地解决了类方法和按实例多态的问题,还提供了 extend 方法来简化使用。

#25楼 @5long self.next = self.do_something ...

只有用Ruby才能搞出如此优雅的OpenStruct,Python就不行了

http://www.ruby-doc.org/stdlib-2.0/libdoc/ostruct/rdoc/OpenStruct.html

#27楼 @bhuztez 啊没错,直接用已绑定的方法(bound method)也是一个制造 callable 属性的办法。但这又要求方法定义在当前对象的方法解析顺序中能找得到。如果方法定义在别处,恐怕又会受限。

依然,虽然理论上可以做到,但因为种种实现门槛/细微的不舒适的存在,在现实世界的代码里就难得一见。比如我在生产环境还见过 Python 中实现 Ruby 的“重新打开一个类去添加 mixin”。具体的实现是:用 mixin 与旧类创建新的类,然后去修改旧类所在模块的作用域,把新类塞进去。结果代码稍显肮脏,更糟糕的是会因为旧类在 mixin 之前被别处 import 拿到引用(虽然利用了 Python 的 package 中 __init__.py 优先执行的逻辑但还是出了问题,诡异得很,至今原因不明),而导致新旧两个类并存使用。导致我现在的想法就是“有时间一定把那玩意重构掉”。当然实际上也一直没那个时间......

#29楼 @5long 不需要这么搞啊,直接改__bases__就好了,毫无压力

#30楼 @bhuztez 发现 object 的直接子类的 __bases__ 不让改 - - 搜了一手发现有这么个问题:http://bugs.python.org/issue672115 如果自己额外定义个用来替代 object 的基类似乎可以做到,但这么搞又麻烦了 oTL

#TIL

#28楼 @bhuztez 说到 OpenStruct,Python 也是可以自己山寨一个的:

class OS(object):
    # __eq__, __setitem__ 什么的也都可以实现得了。
    def __init__(self, **attrs):
        self.__dict__.update(attrs)

恼人的是这么好用的东西竟然在 Python 标准库里就是没有。如果写二者的标准库的话我还可以至少再写一篇,FileUtils, OpenStruct, rake, Minitest, URI, Forwardable, Pathname, YAML 等等,以及 Core 里面的 Time 和 Struct,在 Python 那边要么干脆没有对应物,要么有但易用性完败。但想想绝大多数情况下开发者可以装第三方的包,只对比标准库的意义不那么大了。而且库的演进要容易得多,语言设计留下缺陷就是长期硬伤。

@5long 有试做过scipy么?ruby就不行了。

#33楼 @zhenning Ruby可以调用Python的...

#33楼 @zhenning 这个无法否认。Python 在这方面的积累明显胜过 Ruby。反过来,Ruby 在 Web 开发方面的积累也胜过 Python。这样比下去就等于在比社区的兴趣倾向与自己日常工作的契合程度。不过这种高度专业领域的编程问题反而容易做出决策,没有太多好纠结的。

于是我写的这一系列 blog 只专注对比语言设计,如 #32楼 所述:连标准库都懒得去写。

最近公司做一个Grails 的项目,越来越喜欢这种动态语言的开发框架了,Grails借助强大的Spring和Hibernate,很喜欢

目前还没有开始Rails的项目

#22楼 @krazy 用了段时间 nodejs ,确实发现 ruby 有这个问题,require 不那么容易理解

#10楼 @bhuztez 我是来围观 b 大的

懒得看这种语言之争的文章,无聊的感觉。

#39楼 @vincenttone 多看看不同的语言。对比一下可以学习的更多。。怎么会无聊。文章又不是空洞的再说某好某不好。

^£^. Raise a fight

我想吐槽的是, 选择一门好的语言真的很重要, 作为一个程序员, 这也许是第一重要的事情!! 而且无论是你初学编程, 又或者作为一个主力编程工具, 都应该自己仔细斟酌.

当然, 这不意味着我反对 语言无所谓 这种说法, 这话是有道理的, 但说这话的, 可能只有两种人:

一种是类似于 Matz 这种人, 对一个语言可以随意改进, 随便整个 DSL 语言出来或干脆整个 Ruby 出来, 但这样的人凤毛麟角呀. 全世界也没几个.

还有一种, 人云亦云, 纯粹 装 13 的... (对事不对人, 如有雷同, 请勿对号入座).

离题了... 看了半天楼主的博文, 因为 Python 没仔细研究过, 基本上看不懂, 现在我终于了解为什么别人理解 Ruby 中一些基础的概念, 像读天书了. 个人觉得, 这俩语言, 没有高下之分, 只有风格差异, 都算得上好语言. 不过, 显然 Ruby 更优雅些.

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册