Чому Ruby більше підходить для Rails, ніж Python? [зачинено]

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

Ймовірно, є дві основні відмінності:

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  

який надрукує "ПРИВІТАЙ". class_evalМетод також приймає рядок, так що можна створювати методи на льоту, як створюється клас, що мають різну семантику на основі параметрів, які передаються в.

Насправді це можливо зробити подібного роду метапрограмування на Python (та й інших мовах теж), але Ruby має ногу, оскільки метапрограмування не є особливим стилем програмування. Це випливає з того, що в Ruby все є об'єктом і всі рядки коду виконуються безпосередньо. Як результат, Classes - це самі об'єкти, тіла класу мають selfвказівку на Клас, і Ви можете викликати методи класу під час його створення.

Це значною мірою відповідає за ступінь декларативності, можливої ​​в Rails, і легкість, за допомогою якої ми можемо впроваджувати нові декларативні функції, схожі на ключові слова або нові функції блочної мови.

Ті, хто це аргументував

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

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

Спільнота пітонів вважає, що робити речі найпростішим і прямим можливим способом - це найвища форма елегантності. Спільнота рубінів вважає, що робити речі розумно, дозволяючи крутий код, є найвищою формою елегантності.

Rails - це все про те, що якщо ви дотримуєтеся певних домовленостей, для вас чарівно відбувається безліч інших речей. Це справді добре справляється з рубіновим поглядом на світ, але насправді не йде шляхом пітона.

Чи є ця дискусія новою дискусією "vim проти emacs"?

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

Я можу уявити, що це було б так само, якби я мав досвід роботи з Ruby / Rails.

Обидва мають схожу філософію і виконують роботу швидко і елегантно. Кращий вибір - це те, що ви вже знаєте.

Особисто я вважаю, що рубін перевершує 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'

Існує багато таких різновидів відмінностей, які з часом складаються.

Крім того, я не можу придумати кращого способу ввести невидимі логічні помилки, ніж зробити пробіли значними.

Реальна відповідь - ні Python, ні Ruby не є кращими / гіршими кандидатами на веб-фреймворк. Якщо ви хочете об’єктивність, вам потрібно написати якийсь код обом і подивитися, що найбільше відповідає вашим особистим уподобанням, включаючи спільноту.

Більшість людей, які сперечаються за те чи інше, або ніколи серйозно не використовували іншу мову, або "голосують" за свої особисті переваги.

Я гадаю, більшість людей вирішують питання, з якими вони коли-небудь контактують першими, оскільки це вчить їх чомусь новому (MVC, тестування, генератори тощо) або робить щось краще (плагіни, шаблони тощо). Раніше я розробляв PHP і контактував з RubyOnRails. Якби я знав про MVC до пошуку Rails, я б, швидше за все, ніколи не залишав PHP позаду. Але коли я почав користуватися Ruby, мені сподобався синтаксис, функції тощо.

Якби я спочатку знайшов Python та один з його фреймворків MVC, я б, швидше за все, хвалив цю мову!

Python має цілий ряд Rails-подібних фреймворків. Тут так багато жартів, що під час типової розмови в PyCon хоч один веб-фреймворк побачить світло.

Аргумент того, що метапрограмування Rubys зробило б його більш придатним, є неправильним IMO. Вам не потрібно метапрограмування для таких фреймворків.

Тому я думаю, що ми можемо зробити висновок, що Ruby в цьому відношенні не кращий (і, мабуть, не гірший) ніж Python.

Оскільки Rails розроблений, щоб скористатися набором функцій Rubys.

Подібним безпроблемним питанням було б "Чому Python більше підходить для Django, ніж Ruby?".

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

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

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

Я думаю, що синтаксис чистіший, і Ruby, принаймні для мене, просто набагато «приємніший» - настільки ж суб’єктивний!

Дві відповіді:

a. Тому що рейки були написані для рубіну.

b. З тієї ж причини C більше підходить для Linux, ніж Ruby

Все це ЗАГАЛЬНО "ІМХО"

У Ruby існує ОДИН фреймворк веб-додатків, тому це єдиний фреймворк, який рекламується для цієї мови.

З моменту створення Python мав декілька, назвемо лише декілька: Zope, Twisted, Django, TurboGears (він сам є поєднанням інших компонентів фреймворку), Pylons (своєрідний клон фреймворку Rails) тощо. Жоден з них не підтримується у всій спільноті пітонів як "ТИЙ, який слід використовувати", тому всі "паркові ділянки" розподілені на декілька проектів.

Rails має розмір спільноти виключно, або принаймні в переважній більшості, саме через Rails.

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