指责Rails的“魔法”是否公平？

Question

当我第一次开始研究Rails和Django时，我被Djang开发人员从Rails转向了，他们觉得Rails是一个使用过多“魔法”（漏洞抽象）的黑盒子。在进一步探索Rails时，我想知道这是否是一个不知情的假设，基于不知道如何在不使用脚手架的情况下在Rails中实现自定义。脚手架本身似乎隐藏了很多但是一旦你理解了如何创建没有它的项目，Rails似乎与Django一样高度可定制。这是我对Rails“神奇”批评者的误解吗？

Answer 1

Rails广泛使用Ruby的元编程工具为你做了很多繁重的工作，但没有什么魔力 - 最后它只是代码，只要有足够的时间和精力就可以理解。

脚手架一直用于快速启动和运行模型上的CRUD操作。我们的意图始终是用实际生产代码替换脚手架。

Answer 2

我不会接受Pythonista关于Rails的建议，而不是Rubyist对Django的看法，除非他们能够证明对这两个平台的合理理解水平，至少，并且很少有人可以。< / p>

这些框架（我对Django方面的理解有限）具有类似的架构，但却有所不同，并充分利用了不同语言的优势。

我同意Rails有相当多的“魔力”，convention-over-configuration这个东西是框架的很大一部分。我可以看到这对Python专家来说可能是多么令人讨厌，而且这可能是公平的 - Ruby的一个相对优势是使编程能力发挥作用的元编程功能。也许正因为如此，一般来说，Python中的monkey-patching被认为是可疑的，而在Ruby中它是常见的。不是更糟糕的事情，只是不同。

老实说，我认为你可以在任何一个平台上进行开发。我建议花两三天时间在每个上面构建一个简单的应用程序，然后选择你最喜欢的应用程序。我有兴趣看到你选择的反馈和原因。

Answer 3

您认为Merb是什么？这是Rails开发者在Rails中反抗太多魔法的旗帜。

Rails 3试图减少魔法，拉动Merb的许多部分并清理干净。

现在真的有太多魔力吗？也许，但请记住这一点。 Rails基本上是一组DSL（领域特定语言），它们作为Web开发的框架结合在一起。这就是为什么它如此干净，它是路由，模板或ORM等的语言。要制作干净的DSL，你必须扩展Ruby，这需要很好，一些魔术或元编程。

Django没有这样做，它不会是Python的方式。它不是更好或更坏，只是截然不同。

现在你问，Rails中有太多魔法吗？

记住Arthur C Clark's Third law of prediction：任何足够先进的技术都与魔术无法区分。

所以也许你的开发者朋友只是说Rails是太先进的技术让他们觉得使用起来很舒服。

对我来说，我可以阅读Rails的来源并弄清楚发生了什么。当然它在某些地方很复杂，但我总是能够浏览源代码，阅读非常广泛的单元测试，并了解它是如何工作的。内核也很复杂，但我们不会因为这些原因而拒绝使用它，是吗？

Answer 4

您可能会觉得花一些时间阅读这个问题的变体的答案是有用的（例如，我已经解释了我对它的看法here）。

Answer 5

我不知道如何将导轨视为黑盒子。你有来源。有些红宝石有点棘手，元编程可能会让事情难以追踪，但有一切你可以看到。除非他们在谈论旧的脚手架而不是生成的脚手架，只是创建非常基本的代码模板，而脚手架的批评是没有意义的。

我猜这个djangoist并不是不知情但是他们真的意味着其他东西就像rails使用太多棘手的红宝石并且踩到一些东西它不应该通过monkeypatching ruby​​类。这是一个可以做的案例。

当然他们真的不应该因为我非常肯定Djangos会在澳大利亚吃婴儿。

Answer 6

我认为“公平”的概念在这里是错误的。这都是品味问题。我很害怕rails monkey补丁内置的ruby类型（导致像“5.days”这样的东西）。我认为这很神奇。一些rubyist可能认为它是坚实的工程。

我认为rails的目的是为语言运行时做很多非显而易见的事情。如果你认为这个好坏取决于你。