Dlaczego Ruby jest bardziej odpowiedni dla Railsów niż Python? [Zamknięte]

Python i Ruby są zwykle uważani za bliskich kuzynów (choć z całkiem innym historycznym bagażem) o podobnej ekspresji i mocy. Ale niektórzy twierdzą, że ogromny sukces frameworka Rails naprawdę ma wiele wspólnego z językiem, na którym jest zbudowany: z samym Ruby. Dlaczego więc Ruby byłby bardziej odpowiedni dla takiego frameworka niż Python?

Prawdopodobnie istnieją dwie główne różnice:

Ruby ma eleganckie, anonimowe zamknięcia.

Railsy wykorzystują je z dobrym skutkiem. Oto przykład:

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

Anonimowe domknięcia / lambdy ułatwiają emulowanie nowych funkcji językowych, które wymagałyby blokowania. W Pythonie zamknięcia istnieją, ale muszą zostać nazwane, aby mogły być używane. Więc zamiast być w stanie używać domknięć do emulacji nowych funkcji języka, jesteś zmuszony do wyrażenia wprost faktu, że używasz domknięcia.

Ruby ma czystsze i łatwiejsze w użyciu metaprogramowanie.

Jest to często używane w Railsach, głównie ze względu na łatwość użycia. Mówiąc konkretnie, w Rubim możesz wykonać dowolny kod w kontekście klasy. Następujące fragmenty są równoważne:

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

W obu przypadkach możesz wtedy:

Bar.new.hello  

co spowoduje wydrukowanie „HELLO”. class_evalMetoda bierze również ciągiem znaków, więc jest to możliwe, aby utworzyć metody w locie, jak klasa jest tworzona, które mają różne semantykę w oparciu o parametry, które są przekazywane w.

W rzeczywistości jest możliwe wykonanie tego rodzaju metaprogramowania w Pythonie (i innych językach), ale Ruby ma przewagę, ponieważ metaprogramowanie nie jest specjalnym stylem programowania. Wynika to z faktu, że w Rubim wszystko jest obiektem i wszystkie linie kodu są bezpośrednio wykonywane. W rezultacie Classes są same w sobie obiektami, treści klas mają selfwskazanie na klasę i możesz wywoływać metody z klasy podczas jej tworzenia.

Jest to w dużej mierze odpowiedzialne za stopień deklaratywności możliwej w Railsach i łatwość, z jaką jesteśmy w stanie zaimplementować nowe deklaratywne funkcje, które wyglądają jak słowa kluczowe lub nowe funkcje języka blokowego.

Ci, którzy to argumentowali

Ogromny sukces frameworka Rails naprawdę ma wiele wspólnego z językiem, na którym jest zbudowany

są (IMO) w błędzie. Ten sukces prawdopodobnie zawdzięcza więcej sprytnemu i zrównoważonemu marketingowi niż umiejętnościom technicznym. Django prawdopodobnie radzi sobie lepiej w wielu obszarach (np. Wbudowany administrator-kick-ass) bez potrzeby posiadania jakichkolwiek funkcji Rubiego. W ogóle nie gardzę Rubim, po prostu opowiadam się za Pythonem!

Społeczność Pythona uważa, że ​​robienie rzeczy w najprostszy i najprostszy możliwy sposób to najwyższa forma elegancji. Społeczność rubinów uważa, że ​​robienie rzeczy w sprytny sposób, który pozwala na tworzenie fajnego kodu, jest najwyższą formą elegancji.

W Railsach chodzi o to, że jeśli przestrzegasz pewnych konwencji, dzieje się dla ciebie mnóstwo innych rzeczy. To bardzo dobrze współgra z rubinowym sposobem patrzenia na świat, ale tak naprawdę nie podąża za sposobem Pythona.

Czy ta debata to nowa debata „vim versus emacs”?

Jestem programistą Python / Django i jak dotąd nigdy nie znalazłem problemu w tym języku / frameworku, który prowadziłby mnie do przejścia na Ruby / Rails.

Mogę sobie wyobrazić, że byłoby tak samo, gdybym miał doświadczenie z Ruby / Rails.

Obaj mają podobną filozofię i wykonują swoją pracę w szybki i elegancki sposób. Lepszy wybór to to, co już wiesz.

Osobiście uważam, że ruby ​​jest lepszy od Pythona pod wieloma względami, które obejmują to, co nazwałbym „konsekwentną ekspresją”. Na przykład, w ruby, join jest metodą na obiekcie tablicy, która generuje ciąg, więc otrzymujesz coś takiego:

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

W Pythonie, join jest metodą obiektu typu string, ale która generuje błąd, jeśli przekażesz mu coś innego niż łańcuch jako element do przyłączenia, więc ta sama konstrukcja jest podobna do:

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

Jest wiele takich drobnych różnic, które sumują się w czasie.

Nie mogę też wymyślić lepszego sposobu na wprowadzenie niewidocznych błędów logicznych niż nadanie znaczenia białych spacji.

Prawdziwą odpowiedzią jest to, że ani Python, ani Ruby nie są lepszymi / gorszymi kandydatami do frameworka internetowego. Jeśli chcesz obiektywności, musisz napisać kod w obu i sprawdzić, który najlepiej pasuje do twoich osobistych preferencji, w tym społeczności.

Większość ludzi, którzy argumentują za jednym lub drugim językiem, albo nigdy nie używała poważnie drugiego języka, albo „głosuje” na swoje osobiste preferencje.

Wydaje mi się, że większość ludzi decyduje się na to, z kim pierwszy raz się zetkną, ponieważ uczy ich czegoś nowego (MVC, testowanie, generatory itp.) Lub robi coś lepszego (wtyczki, szablony itp.). Kiedyś programowałem w PHP i skontaktowałem się z RubyOnRails. Gdybym wiedział o MVC przed znalezieniem Railsów, najprawdopodobniej nigdy nie zostawiłbym PHP w tyle. Ale kiedy zacząłem używać Rubiego, spodobała mi się składnia, funkcje itp.

Gdybym najpierw znalazł Pythona i jeden z jego frameworków MVC, prawdopodobnie pochwaliłbym ten język!

Python ma cały szereg frameworków podobnych do Railsów. Jest ich tak wiele, że żartuje się, że podczas typowej rozmowy na PyCon przynajmniej jeden framework sieciowy ujrzy światło dzienne.

Argument, że metaprogramowanie w Rubysie poprawiłoby jego dopasowanie, jest błędny IMO. Nie potrzebujesz metaprogramowania dla takich frameworków.

Myślę więc, że możemy wywnioskować, że Ruby nie są lepsze (i prawdopodobnie ani gorsze) niż Python pod tym względem.

Ponieważ Railsy zostały opracowane w celu wykorzystania zestawu funkcji Rubysa.

Podobnie niewyraźne pytanie brzmiałoby: „Dlaczego Python jest bardziej odpowiedni dla Django niż Ruby?”.

Przypuszczam, że nie powinniśmy dyskutować język wyposażony per se, lecz akcentuje poszczególne społeczności zrobić od funkcji językowych. Na przykład w Pythonie ponowne otwarcie klasy jest całkowicie możliwe, ale nie jest powszechne; w Rubim jednak ponowne otwieranie zajęć jest codzienną praktyką. pozwala to na szybkie i łatwe dostosowanie frameworka do aktualnych wymagań i sprawia, że ​​Ruby jest bardziej korzystny dla frameworków podobnych do Railsów niż jakikolwiek inny język dynamiczny. Stąd moja odpowiedź: powszechne stosowanie zajęć ponownie otwierających.

Niektórzy powiedzieli, że rodzaj metaprogramowania wymagany do umożliwienia ActiveRecord (kluczowego komponentu railsów) jest łatwiejszy i bardziej naturalny do zrobienia w Rubim niż w Pythonie - jeszcze nie znam Pythona;), więc nie mogę osobiście potwierdzić tego stwierdzenia.

Krótko korzystałem z railsów, a ich użycie catchalls / przechwytywaczy i dynamicznej oceny / wstrzykiwania kodu pozwala na działanie na znacznie wyższym poziomie abstrakcji niż niektóre inne frameworki (przed swoim czasem). Mam niewielkie doświadczenie z frameworkiem Pythona - ale słyszałem, że jest równie zdolny - i że społeczność Pythona wykonuje świetną robotę, wspierając i promując pythonowe przedsięwzięcia.

Myślę, że składnia jest czystsza, a Ruby, przynajmniej dla mnie, jest po prostu o wiele bardziej „przyjemny” - tak subiektywny, jak to jest!

Dwie odpowiedzi:

za. Ponieważ szyny zostały napisane dla rubinu.

b. Z tego samego powodu C bardziej pasuje do Linuksa niż Ruby

Wszystko to jest CAŁKOWICIE „IMHO”

W Rubim jest JEDEN framework aplikacji internetowych, więc jest to jedyny framework reklamowany dla tego języka.

Python miał kilka od samego początku, żeby wymienić tylko kilka: Zope, Twisted, Django, TurboGears (sam w sobie jest mieszanką innych komponentów frameworka), Pylony (rodzaj klonu frameworka Rails) i tak dalej. Żaden z nich nie jest obsługiwany przez całą społeczność Pythona jako „ten, którego należy używać”, więc cała „fala złości” jest rozłożona na kilka projektów.

Railsy mają rozmiar społeczności wyłącznie, a przynajmniej w zdecydowanej większości, ze względu na Railsy.

Zarówno Python, jak i Ruby doskonale radzą sobie jako framework aplikacji internetowych. Skorzystaj z tego, który TY (i Twój potencjalny zespół programistów) lubisz i na którym możesz się dopasować.