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

90

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?

Victor Yan
źródło
44
Aliteracja. _
Jimmy,
75
„Python on Pails” po prostu nie ma takiego samego wrażenia ...
ephemient
105
@Ephemient: Uważam, że byłby to Python w samolotach.
Jimmy
37
@Jimmy: Kto potrzebuje samolotów? import antygrawitacji ;-) xkcd.com/353
Vinay Sajip
157
Czy w Jailsach jest Java?
Nosredna

Odpowiedzi:

170

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.

Yehuda Katz
źródło
40
W Pythonie wszystko jest obiektami, a wszystkie wiersze kodu są również bezpośrednio wykonywane. ;) Ale nie masz "self" wskazującego klasę w ciele klasy, które jest tworzone dopiero po definicji klasy, więc musisz później umieścić ten kod w Pythonie, który wprawdzie jest mniej elegancki , ale funkcjonalnie równoważne.
Lennart Regebro
31
@lennart w pewnym sensie. Python pozwala robić te same rzeczy z nazwanymi lambdami, dekoratorami i wprowadzaniem kodu po utworzeniu klas, ale utrata elegancji szybko się kumuluje i sprawia, że ​​coś takiego jak Rails jest albo zauważalnie trudniejsze do zaimplementowania, albo zauważalnie mniej eleganckie dla użytkowników końcowych.
Yehuda Katz
9
Dla mnie nie wyglądają na duże różnice.
Dietrich Epp
10
@lennart Jestem trochę zdezorientowany. Powiedziałem, że nie potrzebujesz ich w Pythonie - ale brak ich sprawił, że kod był trudniejszy do wdrożenia lub mniej elegancki dla użytkowników końcowych (jednego lub drugiego). Języki są kompletne - jeśli chcesz, możesz pisać w Railsach w C.
Yehuda Katz
5
@lennart Teraz wchodzimy w obszar subiektywny, ale dwie cechy, o których mówiłem, są całkiem wygodne podczas tworzenia frameworków z mieszanką programowania deklaratywnego i proceduralnego. W szczególności brak anonimowych lambd jest ograniczeniem ekspresji Pythona. Brak spójności (konieczność pracy z utworzonymi klasami dopiero PO utworzeniu klas) również jest dość ograniczony.
Yehuda Katz
58

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!

Vinay Sajip
źródło
10
Cóż, wchodzimy tutaj w obszar subiektywny. Jeśli myślisz, że administrator jest „jedyny”, być może dzieje się tak dlatego, że nie cieszysz się korzyściami, jakie zapewnia oszczędność czasu. Czy są jakieś obszary, o których myślisz, że Django radzi sobie gorzej niż Railsy z powodu funkcji, które ma Ruby, a Python nie? Tak naprawdę nie chodzi o to, który framework jest lepszy - chodzi o to, czy (jak wskazano w innym miejscu w tym pytaniu) czegoś brakuje w Pythonie, co czyni go mniej zdolnym do tworzenia niesamowitego frameworka. Na dowodach nie ma takiego braku.
Vinay Sajip
18
@Do negatywnych: Nie mam nic przeciwko, ale jestem ciekawy, dlaczego uważasz, że moja odpowiedź była nieprzydatna . Nie zdawałem sobie sprawy, że jeden z nich został odrzucony, ponieważ ktoś nie zgadzał się z czyimś stanowiskiem - generalnie przegłosowałem tylko wtedy, gdy czułem, że pytanie lub odpowiedź w jakiś sposób pogorszyły sytuację.
Vinay Sajip
5
Mogę napisać własną sekcję administratora, nie potrzebuję tego w ramach. Wolę inne sposoby ułatwienia pisania aplikacji.
nitecoder
8
@railsninja: Dobrze dla ciebie. Wolę nie pisać standardowych stron do prac administracyjnych, których potrzebuje większość systemów. Niedawno pracowałem pro-bono dla lokalnej strony charytatywnej i nie byłoby to w ogóle możliwe, gdyby administrator Django nie był częścią równania. W tej chwili dostarczyłem witrynę z dość dostosowanym Ajaxified UI dla użytkowników końcowych, ale administratorzy zaplecza pracowali z administratorem i było to więcej niż odpowiednie dla ich potrzeb.
Vinay Sajip
6
@Matt: Jego pytanie brzmi, dlaczego Ruby jest BARDZIEJ odpowiedni niż Python. I odpowiedź, całkiem poprawna, brzmi: tak nie jest.
Lennart Regebro
54

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.

Matt Briggs
źródło
4
Jasne, ale jest utrata ludzi Perla (no może nie wielu ), którzy uważają, że tajemnicze jednowierszowe są fajne, i wielu ludzi Lispów, którzy przysięgają, że to jedyny prawdziwy język. Zdecydowanie jesteśmy na terytorium, na którym twoja łódź pływa.
Vinay Sajip
4
Railsy mają zerową magię, jest ona w źródle. Jeśli chcesz wiedzieć jak, zejdź z tyłka i dowiedz się.
nitecoder
21
„Każda wystarczająco zaawansowana technologia jest nie do odróżnienia od magii”. - Arthur C. Clarke
Vinay Sajip
1
„magia”, co oznacza, że ​​framework robi za ciebie mnóstwo rzeczy bez bezpośredniego pytania. Ponownie, nie oceniam wartości, jest to styl robienia rzeczy, który ma dobre i złe strony. Osobiście uważam, że świetnie sprawdza się w szynach.
Matt Briggs
2
Elegancja i konwencje nie oznaczają magii.
BJ Clark,
26

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.

luc
źródło
25

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.

pola
źródło
29
Z mojego doświadczenia wynika, że ​​znaczenie białych znaków pomaga wyeliminować błędy logiczne. O wiele bardziej zagmatwane jest niezgodność odstępów i składni.
Nosredna
5
W językach z początkami i końcami oraz w językach z nawiasami klamrowymi oraz w asemblerze, widziałem, jak kod został źle wklejony i spowodował później problemy. To zawsze jest problem. Czy miałeś wiele problemów z ludźmi, którzy źle wklejali Pythona?
Nosredna
5
Białe znaki nie mają znaczenia w Pythonie: secnetix.de/~olli/Python/block_indentation.hawk . Wprowadzenie „niewidocznych błędów” z powodu wcięć w Pythonie (trzeba sfałszować ustawienia edytora) jest prawie niemożliwe, podczas gdy oczywiście jest całkowicie możliwe wprowadzenie niewidocznych błędów z powodu wcięć w jakimkolwiek innym języku, po prostu przez niepoprawne wcięcie. @fields: Więc nie kopiuj kodu przez skype lub HTML. Jezu.
Lennart Regebro
7
Prawdą jest, że Python narzeka, gdy próbujesz dodać elementy niebędące łańcuchami do łańcuchów, jak w przypadku łączenia. Dzieje się tak, ponieważ jawne jest lepsze niż niejawne. W Pythonie jest bardzo niewiele automatycznych konwersji, a powodem tego jest to, że zwykle prowadzą one do problemów, szczególnie w językach dynamicznych, ponieważ rzeczy nie są takie, jakich się spodziewałeś. Jasne, że metoda „” .join () na początku działa wstecz, ale to jest powód. To właściwie nie ma sensu na liście ...
Lennart Regebro
8
Boże wszechmogący ... Masz na myśli wpisane statycznie, a nie mocno. Python jest silnie wpisywany, podobnie jak Ruby: stackoverflow.com/questions/520228/… W Rubim również nie można dodać łańcucha do liczby całkowitej. Mam dość poprawiania cię, proszę, sprawdź fakty, zanim odpowiesz w przyszłości.
Lennart Regebro
15

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!

Kris
źródło
11

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.

Lennart Regebro
źródło
8

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?”.

Paddy3118
źródło
4

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.

Giorgi
źródło
1

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.

Faisal Vali
źródło
3
Rzeczywiście, ten rodzaj „magii” jest często źle widziany w Pythonie; na przykład code.djangoproject.com/wiki/RemovingTheMagic
ephemient.
2
Myślę, że „magia” (sztuczki metaprogramowania) ze względu na „magię” zawsze powinna być odrzucana - prostszy kod, ale równie potężny i wyrazisty, powinien zawsze wygrywać - ale są przypadki, w których jedynym sposobem na zapewnienie dokładnej funkcjonalności i składni chcesz wymaga "magii" - aw takich przypadkach "magia" jest nieodzowna;)
Faisal Vali
1

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

James Schorr
źródło
-1

Dwie odpowiedzi:

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

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

Dhananjay Nene
źródło
Biorąc pod uwagę kontekst pytania, odpowiedź nie ma absolutnie żadnego sensu.
lorefnon
-6

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ć.

Ch'marr
źródło
7
ruby ma wiele frameworków aplikacji internetowych: Nitro, Merb, Camping ... żeby wymienić tylko kilka
Corban Brook,
5
Dodaj: Sinatra, a nawet samą aplikację Rack dla bardzo szybkich, bardzo minimalnych aplikacji internetowych.
Kris,
2
-1 „W Rubim jest JEDEN framework do aplikacji internetowych” zbyt kategoryczny ... na fałszywe stwierdzenie. Nitro, Merb, Camping, Sinatra
Maximiliano Guzman
2
Niedoinformowane opinie z obu stron są dokładnie przyczyną zamieszania dla nowoprzybyłych, którzy próbują to wszystko uporządkować. Oznacza to również, że można przegapić coś, co naprawdę by docenili, gdyby wiedzieli lepiej.
Walt Jones,
3
Myślę, że chodziło mu o to, że Rails ma dużo
wspólnego umysłu