为什么 Ruby 比 Python 更适合 Rails?

发布于 2024-07-26 00:08:39 字数 133 浏览 4 评论 0原文

Python 和 Ruby 通常被认为是近亲(尽管历史包袱截然不同),具有相似的表达能力和功能。 但有些人认为 Rails 框架的巨大成功确实与它所构建的语言有很大关系:Ruby 本身。 那么为什么 Ruby 比 Python 更适合这样的框架呢?

Python and Ruby are usually considered to be close cousins (though with quite different historical baggage) with similar expressiveness and power. But some have argued that the immense success of the Rails framework really has a great deal to do with the language it is built on: Ruby itself. So why would Ruby be more suitable for such a framework than Python?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(13

江南烟雨〆相思醉 2024-08-02 00:08:39

可能有两个主要区别:

Ruby 有优雅的匿名闭包。

Rails 使用它们取得了良好的效果。 下面是一个示例:

class WeblogController < ActionController::Base
  def index
    @posts = Post.find :all
    respond_to do |format|
      format.html
      format.xml { render :xml => @posts.to_xml }
      format.rss { render :action => "feed.rxml" }
    end
  end
end

匿名闭包/lambda 可以更轻松地模拟需要块的新语言功能。 Python 中存在闭包,但必须命名才能使用。 因此,您不能使用闭包来模拟新的语言功能,而是被迫明确说明您正在使用闭包的事实。

Ruby 具有更清晰、更易于使用的元编程。

这在 Rails 中被广泛使用,主要是因为它很容易使用。 具体来说,在 Ruby 中,您可以在类的上下文中执行任意代码。 以下代码片段是等效的:

class Foo
  def self.make_hello_method
    class_eval do
      def hello
        puts "HELLO"
      end
    end
  end
end

class Bar < Foo # snippet 1
  make_hello_method
end

class Bar < Foo; end # snippet 2
Bar.make_hello_method

在这两种情况下,您都可以执行以下操作:

Bar.new.hello  

这将打印“HELLO”。 class_eval 方法也接受一个字符串,因此可以在创建类时动态创建方法,这些方法根据传入的参数具有不同的语义。

事实上, ,可以在 Python(以及其他语言)中进行这种元编程,但 Ruby 有优势,因为元编程不是一种特殊的编程风格。 这是因为在 Ruby 中,一切都是对象,所有代码行都直接执行。 因此,Class本身就是对象,类体有一个self指向该类,并且您可以在创建类时调用该类的方法。

这在很大程度上决定了 Rails 中可能的声明性程度,以及我们能够轻松实现看起来像关键字或新的块语言功能的新声明性功能。

There are probably two major differences:

Ruby has elegant, anonymous closures.

Rails uses them to good effect. Here's an example:

class WeblogController < ActionController::Base
  def index
    @posts = Post.find :all
    respond_to do |format|
      format.html
      format.xml { render :xml => @posts.to_xml }
      format.rss { render :action => "feed.rxml" }
    end
  end
end

Anonymous closures/lambdas make it easier to emulate new language features that would take blocks. In Python, closures exist, but they must be named in order to be used. So instead of being able to use closures to emulate new language features, you're forced to be explicit about the fact that you're using a closure.

Ruby has cleaner, easier to use metaprogramming.

This is used extensively in Rails, primarily because of how easy it is to use. To be specific, in Ruby, you can execute arbitrary code in the context of the class. The following snippets are equivalent:

class Foo
  def self.make_hello_method
    class_eval do
      def hello
        puts "HELLO"
      end
    end
  end
end

class Bar < Foo # snippet 1
  make_hello_method
end

class Bar < Foo; end # snippet 2
Bar.make_hello_method

In both cases, you can then do:

Bar.new.hello  

which will print "HELLO". The class_eval method also takes a String, so it's possible to create methods on the fly, as a class is being created, that have differing semantics based on the parameters that are passed in.

It is, in fact, possible to do this sort of metaprogramming in Python (and other languages, too), but Ruby has a leg up because metaprogramming isn't a special style of programming. It flows from the fact that in Ruby, everything is an object and all lines of code are directly executed. As a result, Classes are themselves objects, class bodies have a self pointing at the Class, and you can call methods on the class as you are creating one.

This is to large degree responsible for the degree of declarativeness possible in Rails, and the ease by which we are able to implement new declarative features that look like keywords or new block language features.

愁以何悠 2024-08-02 00:08:39

那些争论过这一点的人

Rails 的巨大成功
框架确实有很多事情要做
与它所构建的语言有关

(IMO)是错误的。 这种成功可能更多地归功于聪明和持续的营销,而不是任何技术实力。 Django 可以说在许多领域(例如内置的强大管理)做得更好,而不需要Ruby 的任何功能。 我根本没有贬低 Ruby,只是支持 Python!

Those who have argued that

the immense success of the Rails
framework really has a great deal to
do with the language it is built on

are (IMO) mistaken. That success probably owes more to clever and sustained marketing than to any technical prowess. Django arguably does a better job in many areas (e.g. the built-in kick-ass admin) without the need for any features of Ruby. I'm not dissing Ruby at all, just standing up for Python!

等风来 2024-08-02 00:08:39

python 社区认为,以最简单、最直接的方式做事是优雅的最高形式。 Ruby 社区相信,以巧妙的方式做事并创造出酷炫的代码是优雅的最高形式。

Rails 的意义在于,如果您遵循某些约定,那么许多其他事情就会神奇地发生在您身上。 这与 Ruby 看待世界的方式非常吻合,但并不真正遵循 Python 的方式。

The python community believes that doing things the most simple and straight forward way possible is the highest form of elegance. The ruby community believes doing things in clever ways that allow for cool code is the highest form of elegance.

Rails is all about if you follow certain conventions, loads of other things magically happen for you. That jives really well with the ruby way of looking at the world, but doesn't really follow the python way.

§对你不离不弃 2024-08-02 00:08:39

这场争论是一场新的“vim 与 emacs”争论吗?

我是一名 Python/Django 程序员,到目前为止,我从未在该语言/框架中发现导致我切换到 Ruby/Rails 的问题。

我可以想象,如果我有 Ruby/Rails 的经验,情况也会是一样的。

两者都有相似的理念,并且以快速而优雅的方式完成工作。 更好的选择是您已经知道的。

Is this debate a new "vim versus emacs" debate?

I am a Python/Django programmer and thus far I've never found a problem in that language/framework that would lead me to switch to Ruby/Rails.

I can imagine that it would be the same if I were experienced with Ruby/Rails.

Both have similar philosophy and do the job in a fast and elegant way. The better choice is what you already know.

⒈起吃苦の倖褔 2024-08-02 00:08:39

就我个人而言,我发现 ruby​​ 在很多方面都优于 python,包括我所说的“一致的表达能力”。 例如,在 ruby​​ 中, join 是数组对象上的一个方法,它输出一个字符串,所以你会得到这样的结果:

numlist = [1,2,3,4]
#=> [1, 2, 3, 4]
numlist.join(',')
#=> "1,2,3,4"

在 python 中, join 是字符串对象上的一个方法,但如果你向它传递除字符串作为要连接的东西,因此相同的构造类似于:

numlist = [1,2,3,4]
numlist
#=> [1, 2, 3, 4]
",".join([str(i) for i in numlist])
#=> '1,2,3,4'

随着时间的推移,有很多这样的细微差异。

另外,我想不出比让空白变得重要更好的方法来引入不可见的逻辑错误。

Personally, I find ruby to be superior to python in many ways that comprise what I'd call 'consistent expressiveness'. For example, in ruby, join is a method on the array object which outputs a string, so you get something like this:

numlist = [1,2,3,4]
#=> [1, 2, 3, 4]
numlist.join(',')
#=> "1,2,3,4"

In python, join is a method on the string object but which throws an error if you pass it something other than a string as the thing to join, so the same construct is something like:

numlist = [1,2,3,4]
numlist
#=> [1, 2, 3, 4]
",".join([str(i) for i in numlist])
#=> '1,2,3,4'

There are a lot of these little kinds of differences that add up over time.

Also, I cannot think of a better way to introduce invisible logic errors than to make whitespace significant.

很酷又爱笑 2024-08-02 00:08:39

真正的答案是,Python 或 Ruby 都不是 Web 框架更好/更差的候选者。 如果您想要客观性,您需要在两者中编写一些代码,看看哪一个最适合您的个人偏好,包括社区。

大多数争论其中一种或另一种语言的人要么从未认真使用过另一种语言,要么只是根据自己的个人喜好“投票”。

我猜大多数人都会选择他们首先接触的东西,因为它教给他们一些新的东西(MVC、测试、生成器等)或者做一些更好的东西(插件、模板等)。 我以前是用PHP开发的,后来接触了RubyOnRails。 如果我在发现 Rails 之前就了解 MVC,我很可能永远不会抛弃 PHP。 但一旦我开始使用 Ruby,我就喜欢它的语法、功能等。

如果我首先找到了 Python 及其 MVC 框架之一,我很可能会赞扬该语言!

The real answer is neither Python or Ruby are better/worse candidates for a web framework. If you want objectivity you need to write some code in both and see which fits your personal preference best, including community.

Most people who argue for one or other have either never used the other language seriously or are 'voting' for their personal preference.

I would guess most people settle on which ever they come in to contact with first because it teaches them something new (MVC, testing, generators etc.) or does something better (plugins, templating etc). I used to develop with PHP and came in to contact with RubyOnRails. If I had have known about MVC before finding Rails I would more than likely never left PHP behind. But once I started using Ruby I enjoyed the syntax, features etc.

If I had have found Python and one of its MVC frameworks first I would more than likely be praising that language instead!

转身以后 2024-08-02 00:08:39

Python 拥有一整套类似 Rails 的框架。 框架数量如此之多,以至于有一个笑话说,在 PyCon 的典型演讲中,至少有一个 Web 框架会脱颖而出。

认为 Ruby 元编程会使其更适合的论点在我看来是不正确的。 您不需要对这样的框架进行元编程。

所以我认为我们可以得出这样的结论:Ruby 在这方面并不比 Python 更好(也可能也不差)。

Python has a whole host of Rails-like frameworks. There are so many that a joke goes that during the typical talk at PyCon at least one web framework will see the light.

The argument that Rubys meta programming would make it better suited is IMO incorrect. You don't need metaprogramming for frameworks like this.

So I think we can conclude that Ruby are not better (and likely neither worse) than Python in this respect.

蓝眼睛不忧郁 2024-08-02 00:08:39

因为 Rails 是为了利用 Ruby 的功能集而开发的。

一个类似的愚蠢问题是“为什么 Python 比 Ruby 更适合 Django?”。

Because Rails is developed to take advantage of Rubys feature set.

A similarly gormless question would be "Why is Python more suitable for Django than Ruby is?".

是你 2024-08-02 00:08:39

我想我们不应该讨论语言特性本身,而应该讨论各个社区对语言特性的强调。 例如,在Python中,重新打开一个类是完全可能的,但并不常见; 然而,在 Ruby 中,重新开设课程是日常实践。 这允许根据当前需求快速、直接地定制框架,并使 Ruby 比任何其他动态语言更适合类似于 Rails 的框架。
因此我的答案是:重新开课的常见做法。

I suppose we should not discuss the language features per se but rather the accents the respective communities make on the language features. For example, in Python, re-opening a class is perfectly possible but it is not common; in Ruby, however, re-opening a class is something of the daily practice. this allows for a quick and straightforward customization of the framework to the current requirement and renders Ruby more favorable for Rails-like frameworks than any other dynamic language.
Hence my answer: common use of re-opening classes.

天涯离梦残月幽梦 2024-08-02 00:08:39

有人说,使 ActiveRecord(rails 的关键组件)成为可能所需的元编程类型在 ruby​​ 中比在 python 中更容易、更自然 - 我还不了解 python;),所以我个人无法证实这一说法。

我简单地使用过 Rails,它对包罗万象/拦截器和动态求值/代码注入的使用确实允许您在比其他一些框架(之前)更高的抽象级别上进行操作。 我对 Python 框架几乎没有经验,但我听说它同样有能力,并且 Python 社区在支持和促进 Python 化的努力方面做得很好。

Some have said that the type of metaprogramming required to make ActiveRecord (a key component of rails) possible is easier and more natural to do in ruby than in python - I do not know python yet;), so i cannot personally confirm this statement.

I have used rails briefly, and its use of catchalls/interceptors and dynamic evaluation/code injection does allow you to operate at a much higher level of abstraction than some of the other frameworks (before its time). I have little to no experience with Python's framework - but i've heard it's equally capable - and that the python community does a great job supporting and fostering pythonic endeavors.

青瓷清茶倾城歌 2024-08-02 00:08:39

我认为 Ruby 的语法更简洁,至少对我来说,只是更“令人愉快”——尽管这是主观的!

I think that the syntax is cleaner and Ruby, for me at least, is just a lot more "enjoyable"- as subjective as that is!

初懵 2024-08-02 00:08:39

两个答案

: 因为 Rails 是为 ruby​​ 编写的。

b. 出于同样的原因,C 比 Ruby 更适合 Linux

Two answers :

a. Because rails was written for ruby.

b. For the same reason C more suitable for Linux than Ruby

叹沉浮 2024-08-02 00:08:39

所有这一切完全是“恕我直言”。

在 Ruby 中,有一个 Web 应用程序框架,因此它是该语言宣传的唯一框架。

Python 自诞生以来已有多个框架,仅举几例:Zope、Twisted、Django、TurboGears(它本身是其他框架组件的混合体)、Pylons(Rails 框架的一种克隆)等等。 它们都没有得到 Python 社区范围内的“可用”支持,因此所有“风潮”都分布在多个项目中。

Rails 的社区规模完全(或至少绝大多数)是因为 Rails。

Python 和 Ruby 都完全能够作为 Web 应用程序框架完成这项工作。 使用您(和您的潜在开发团队)喜欢并且可以配合的人。

All of this is TOTALLY "IMHO"

In Ruby there is ONE web-application framework, so it is the only framework that is advertised for that language.

Python has had several since inception, just to name a few: Zope, Twisted, Django, TurboGears (it itself a mix of other framework components), Pylons (a kinda-clone of the Rails framework), and so on. None of them are python-community-wide supported as "THE one to use" so all the "groundswell" is spread over several projects.

Rails has the community size solely, or at least in the vast majority, because of Rails.

Both Python and Ruby are perfectly capable of doing the job as a web applications framework. Use the one YOU (and your potential development team) like and can align on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文