Почему Ruby больше подходит для Rails, чем Python? [закрыто]


90

Python и Ruby обычно считаются близкими родственниками (хотя и с совершенно другим историческим багажом) с аналогичной выразительностью и мощью. Но некоторые утверждают, что огромный успех фреймворка Rails действительно во многом связан с языком, на котором он построен: самим Ruby. Так почему же Ruby больше подходит для такого фреймворка, чем Python?


44
Аллитерация. _
Джимми

75
«Python on Pails» просто не вызывает того же ощущения ...
ephemient

105
@Ephemient: Думаю, это будет Python на самолетах.
Джимми

37
@ Джимми: Кому нужны самолеты? import antigravity
Виней Саджип

157
Есть ли в джейлах Java?
Носредна,

Ответы:


170

Вероятно, есть два основных отличия:

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

Анонимные замыкания / лямбда-выражения упрощают эмуляцию новых языковых функций, которые принимают блоки. В 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 все является объектом, и все строки кода выполняются напрямую. В результате Classes сами являются объектами, тела классов selfуказывают на класс, и вы можете вызывать методы класса по мере его создания.

Это в значительной степени отвечает за степень декларативности, возможную в Rails, и легкость, с которой мы можем реализовать новые декларативные функции, которые выглядят как ключевые слова или новые возможности блочного языка.


40
В Python все является объектами, и все строки кода также выполняются напрямую. ;) Но у вас нет «я», указывающего на класс в теле класса, которое не создается до тех пор, пока не будет определен класс, поэтому вы должны поместить этот код позже в Python, который, по общему признанию, менее элегантен. , но функционально эквивалентны.
Леннарт Регебро 08

31
@lennart в том-то и дело. Python позволяет вам делать те же вещи с именованными лямбдами, декораторами и помещением кода после создания классов, но потеря элегантности быстро накапливается и делает что-то вроде Rails либо заметно сложнее для реализации, либо заметно менее элегантным для конечных пользователей.
Иегуда Кац

9
Мне они не кажутся серьезными отличиями.
Дитрих Эпп

10
@lennart Я немного запуталась. Я сказал, что они вам не нужны в Python, но их отсутствие усложняет реализацию кода или делает его менее элегантным для конечных пользователей (того или другого). Языки завершены - вы можете написать Rails на C, если хотите.
Иегуда Кац

5
@lennart Теперь мы переходим на субъективную территорию, но две функции, о которых я говорил, весьма удобны при создании фреймворков с сочетанием декларативного и процедурного программирования. В частности, отсутствие анонимных лямбд является ограничением выразительности Python. Отсутствие согласованности (необходимость работать с созданными классами только ПОСЛЕ создания классов) также весьма ограничивает.
Иегуда Кац

58

Те, кто утверждал, что

огромный успех фреймворка Rails действительно во многом связан с языком, на котором он построен

ошибаются (ИМО). Этот успех, вероятно, в большей степени обязан умному и устойчивому маркетингу, чем техническому мастерству. Django, возможно, лучше справляется со многими задачами (например, с помощью встроенного админа) без необходимости использования каких-либо функций Ruby. Я ни в коем случае не осуждаю Ruby, просто защищаю Python!


10
Что ж, здесь мы попадаем на субъективную территорию. Если вы думаете, что администратор - «единственный», то, возможно, это потому, что вы не пользовались преимуществами экономии времени, которые он дает. Есть ли области, в которых, по вашему мнению, Django работает хуже, чем Rails, из-за функций, которые есть у Ruby, а у Python нет? Дело не в том, какой фреймворк лучше, а в том, есть ли (как указано в другом месте в этом вопросе) чего-либо, чего не хватает в Python, что делает его менее способным к разработке фреймворка. По свидетельствам, такого недостатка нет.
Vinay Sajip 08

18
@ Голосующим против: я не возражаю, но мне любопытно узнать, почему вы подумали, что мой ответ бесполезен . Я не понимал, что кто-то проголосовал против, потому что кто-то не согласился с чьей-то позицией - я обычно голосовал против только тогда, когда я чувствовал, что вопрос или ответ каким-то образом ухудшают ситуацию.
Vinay Sajip 08

5
Я могу написать свой собственный админ-раздел, мне это не нужно во фреймворке. Я предпочитаю другие способы облегчить написание моего приложения.
nitecoder 09

8
@railsninja: Молодец. Я предпочитаю не писать шаблонные страницы для административной работы, которая требуется большинству систем. Недавно я работал на общественных началах для местного благотворительного сайта, и это было бы вообще невозможно, если бы администратор Django не входил в уравнение. Как бы то ни было, я предоставил сайт с довольно настроенным Ajaxified UI для конечных пользователей, но серверные администраторы работали с администратором, и это было более чем адекватно их потребностям.
Vinay Sajip 09

6
@Matt: Его вопрос в том, почему Ruby БОЛЬШЕ подходит, чем Python ... И ответ, совершенно правильный, - это не так.
Lennart Regebro

54

Сообщество питонов считает, что делать что-то наиболее простым и понятным способом - это высшая форма элегантности. Сообщество ruby ​​считает, что умение делать вещи, позволяющие создавать крутой код, - это высшая форма элегантности.

Rails - это то, что если вы следуете определенным соглашениям, с вами волшебным образом происходит множество других вещей. Это очень хорошо сочетается с рубиновым взглядом на мир, но не совсем соответствует взгляду питона.


4
Конечно, но есть люди с Perl (ну, может быть, не много ), которые думают, что загадочные однострочные сообщения - это круто, и многие люди с Lisp, которые клянутся, что это единственный настоящий язык. Мы определенно находимся на территории того, что плавает ваша лодка.
Vinay Sajip 08

4
В Rails нет магии, она прямо в исходном коде. Если хочешь знать как, слезай с задницы и узнай.
nitecoder 09

21
"Любая достаточно развитая технология неотличима от магии." - Артур Кларк
Виней Саджип

1
«магия» означает, что фреймворк делает за вас чертовски много вещей, даже не спрашивая напрямую. Опять же, я не делаю оценочных суждений, это один из стилей ведения дел, у которого есть хорошие и плохие стороны. Лично я считаю, что в рельсах он прекрасно работает.
Мэтт Бриггс,

2
Элегантность и условности не означают магию.
BJ Clark

26

Является ли эта дискуссия новой дискуссией "vim vs. emacs"?

Я программист на Python / Django и до сих пор не обнаружил в этом языке / фреймворке проблемы, которая заставила бы меня перейти на Ruby / Rails.

Могу представить, что было бы то же самое, если бы я имел опыт работы с Ruby / Rails.

Оба имеют схожую философию и выполняют работу быстро и элегантно. Лучший выбор - это то, что вы уже знаете.


25

Лично я считаю, что 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'

Есть много таких небольших различий, которые со временем складываются.

Кроме того, я не могу придумать лучшего способа ввести невидимые логические ошибки, чем сделать пробелы значимыми.


29
Мой опыт показывает, что создание значительных пробелов помогает избавиться от логических ошибок. Гораздо сложнее иметь несогласованные интервалы и синтаксис.
Nosredna 09

5
В языках с началом и концом, а также в языках с фигурными скобками и в ассемблере я видел, как код вставлялся неправильно, что впоследствии приводило к проблемам. Это всегда проблема. У вас было много проблем с людьми, которые плохо вставляли Python?
Nosredna 09

5
Пробелы в Python не важны: secnetix.de/~olli/Python/block_indentation.hawk . Практически невозможно ввести «невидимые ошибки» из-за отступов в Python (вы должны подделать настройки редактора), хотя, конечно, вполне возможно ввести невидимые ошибки из-за отступов на любом другом языке, просто путем неправильного отступа. @fields: Тогда не копируйте код через скайп или HTML. Господи.
Леннарт Регебро, 09

7
Это правильно, что Python жалуется, если вы пытаетесь добавить не-строки к строкам, как в соединении. Это потому, что явное лучше, чем неявное. В Python очень мало автоматических преобразований, и причина этого в том, что они имеют тенденцию приводить к проблемам, особенно в динамических языках, поскольку в конечном итоге все оказывается не того типа, который вы ожидали. Конечно, метод "" .join () поначалу кажется обратным, но в этом причина. На самом деле это не имеет смысла в списке ...
Леннарт Регебро

8
Боже всемогущий ... Вы имеете в виду статически типизированный, а не строго типизированный. Python строго типизирован, как и Ruby: stackoverflow.com/questions/520228/ ... Вы также не можете добавить строку к целому числу в Ruby. Я устал исправлять вас, пожалуйста, проверьте свои факты, прежде чем отвечать в будущем.
Леннарт Регебро

15

Настоящий ответ таков: ни Python, ни Ruby не являются лучшими / худшими кандидатами для веб-фреймворка. Если вам нужна объективность, вам нужно написать код для обоих и посмотреть, что лучше всего соответствует вашим личным предпочтениям, включая сообщество.

Большинство людей, отстаивающих тот или иной язык, либо никогда серьезно не использовали другой язык, либо «голосуют» за свои личные предпочтения.

Я предполагаю, что большинство людей выбирают, с чем они сталкиваются в первую очередь, потому что это учит их чему-то новому (MVC, тестирование, генераторы и т. Д.) Или делает что-то лучше (плагины, шаблоны и т. Д.). Раньше я работал с PHP и познакомился с RubyOnRails. Если бы я знал о MVC до того, как нашел Rails, я бы, скорее всего, никогда не оставил бы PHP. Но как только я начал использовать Ruby, мне понравился синтаксис, функции и т. Д.

Если бы я сначала нашел Python и одну из его сред MVC, я бы, скорее всего, хвалил бы этот язык!


11

Python имеет целый ряд фреймворков, подобных Rails. Их так много, что шутят, что во время типичного выступления на PyCon хотя бы один веб-фреймворк увидит свет.

Аргумент, что метапрограммирование Rubys сделало бы его более подходящим, неверен ИМО. Для подобных фреймворков метапрограммирование не требуется.

Итак, я думаю, мы можем сделать вывод, что Ruby не лучше (и, вероятно, не хуже), чем Python в этом отношении.


8

Потому что Rails разработан для использования набора функций Rubys.

Не менее бессмысленный вопрос: «Почему Python более подходит для Django, чем Ruby?».


4

Я полагаю, нам следует обсуждать не языковые особенности как таковые, а скорее акценты, которые соответствующие сообщества делают на языковых функциях. Например, в Python повторное открытие класса вполне возможно, но редко; в Ruby, однако, повторное открытие класса является чем-то вроде повседневной практики. это позволяет быстро и просто настроить фреймворк в соответствии с текущими требованиями и делает Ruby более подходящим для Rails-подобных фреймворков, чем любой другой динамический язык. Отсюда мой ответ: обычное использование повторно открывающихся классов.


1

Некоторые говорят, что тип метапрограммирования, необходимый для реализации ActiveRecord (ключевого компонента рельсов), проще и естественнее выполнять в ruby, чем в python - я еще не знаю python;), поэтому я не могу лично подтвердить это утверждение.

Я кратко использовал рельсы, и его использование улавливателей / перехватчиков и динамической оценки / внедрения кода позволяет вам работать на гораздо более высоком уровне абстракции, чем некоторые другие фреймворки (до своего времени). У меня мало или совсем нет опыта работы с фреймворком Python, но я слышал, что он одинаково эффективен, и что сообщество Python делает отличную работу, поддерживая и поощряя усилия Python.


3
В самом деле, этот вид «магии» часто осуждается в Python; например, code.djangoproject.com/wiki/RemovingTheMagic
ephemient

2
Я думаю, что «магия» (уловки метапрограммирования) ради «магии» всегда должна вызывать неодобрение - более простой код, но столь же мощный и выразительный, всегда должен побеждать - но бывают случаи, когда единственный способ обеспечить точную функциональность и синтаксис вы хотите, требует "магии" - и в тех случаях "магия" незаменима;)
Фейсал Вали

1

Я думаю, что синтаксис чище, а Ruby, по крайней мере, для меня, намного более «приятен» - как бы субъективно это ни было!


-1

Два ответа:

а. Потому что rails был написан для рубина.

б. По той же причине C больше подходит для Linux, чем Ruby


Учитывая контекст вопроса, ответ не имеет абсолютно никакого смысла.
lorefnon

-6

Все это ПОЛНОСТЬЮ "ИМХО"

В Ruby есть ОДИН фреймворк для веб-приложений, так что это единственный фреймворк, рекламируемый для этого языка.

У Python с момента создания было несколько, это лишь некоторые из них: Zope, Twisted, Django, TurboGears (он сам представляет собой смесь других компонентов фреймворка), Pylons (своего рода клон фреймворка Rails) и так далее. Ни один из них не поддерживается сообществом Python как «тот, который нужно использовать», поэтому вся «земля» распространяется на несколько проектов.

Rails имеет размер сообщества исключительно, или, по крайней мере, в подавляющем большинстве, благодаря Rails.

И Python, и Ruby отлично подходят для работы в качестве фреймворка для веб-приложений. Используйте то, что нравится ВАМ (и вашей потенциальной команде разработчиков) и с которым можете согласиться.


7
ruby имеет несколько фреймворков для веб-приложений: Nitro, Merb, Camping ... и многие другие
Корбан Брук,

5
Добавьте: Sinatra и даже простое приложение Rack для очень быстрых и минимальных веб-приложений.
Крис

2
-1 «В Ruby есть ОДИН фреймворк для веб-приложений» слишком категорично ... для ложного утверждения. Nitro, Merb, Camping, Sinatra
Максимилиано Гусман

2
Неосведомленные мнения с обеих сторон и являются причиной замешательства новичков, которые пытаются во всем этом разобраться. Это также означает, что можно упустить то, что они действительно оценили бы, если бы знали лучше.
Уолт Джонс,

3
Я думаю, что его точка зрения заключалась в том, что Rails больше думает о сообществе Ruby, чем Django - о сообществе Python, и это действительно так
pjb3
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.