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?
python
ruby-on-rails
ruby
web-frameworks
Victor Yan
źródło
źródło
Odpowiedzi:
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_eval
Metoda 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
Class
es są same w sobie obiektami, treści klas mająself
wskazanie 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.
źródło
Ci, którzy to argumentowali
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!
źródło
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.
źródło
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.
źródło
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.
źródło
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!
źródło
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.
źródło
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?”.
źródło
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.
źródło
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.
źródło
Myślę, że składnia jest czystsza, a Ruby, przynajmniej dla mnie, jest po prostu o wiele bardziej „przyjemny” - tak subiektywny, jak to jest!
źródło
Dwie odpowiedzi:
za. Ponieważ szyny zostały napisane dla rubinu.
b. Z tego samego powodu C bardziej pasuje do Linuksa niż Ruby
źródło
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ć.
źródło