Tłumaczenie Ruby Python comparison mojego autorstwa

Tips and tricks
1

http://faq.rubygarden.org/entry/show/14?controller_prefix=faq%2F
2.1: Jak Ruby przedstawia się w porównaniu do Pythona?

Obydwa Python i Ruby są obiektowo zorientowanymi językami, które udostępniają gładkie przejście z proceduralnych do OO stylów programowania. Smalltalk, odwrotnie, jest tylko obiektowy - nie możesz nic zrobić dopóki nie zrozumiesz obiektów, dziedziczenia i dużej hierarchi klas Smalltaka. Przez udostępnienie proceduralnych kół treningowych, Python i Ruby “naprawiają” jedną z cech, która mogła być blokadą do powszechnego użycia Smalltaka. Te dwa języki różnią się przez osiąganie tego celu z przeciwnych stron.

Python jest językiem hybrydowym. Posiada funkcje do programowania proceduralnego i obiekty do programowania OO. Python łączy te dwa światy przez umożliwienie funkcjom i metodom przekształcenia się używając jawnego parametru “self” przy każdej definicji metody. Kiedy funkcja jest wstawiona do obiektu, pierwszy argument automagicznie staje się referencją do odbiorcy.

Ruby jest czystym językiem OO, które może udawać proceduralny. Nie posiada funkcji, tylko wywołania metod. W Rubowej metodzie odbiorca, zwany również self, jest ukrytym argumentem jak “this” w C++. is a pure OO language that can masquerade as a procedural one. It has no functions, only method calls. In a Ruby method the receiver, also called self, is a hidden argument like ``this’’ in C++. Instrukcja “def” poza definicją klasy, która jest funkcją w Pythonie, jest właściwie wywołaniem metody w Rubim. Te namiastki funkcji stają się prywatnymi metodami obiektu klasy, wierzchołkiem hierarchi klas Rubiego. Programowanie proceduralne jest schludnie zrobione z innej strony - wszystko jest obiektem. Jeśli użytkownik nie pojmuje jeszcze obiektów, może udawać, że “def” jest definicją funkcji i mimo wszystko wykonać wymagane zadanie.

Czystość OO w Rubim dostarcza wiele użyteczności, których brak w Pythonie lub są dopiero opracowywane: ujednolicona hierarchia typów/klas, metaklasy, możliwość tworzenia podklas ze wszystkiego, ujednolicone wywołanie metod (brak śmieci w stylu len() jest funkcją ale items() są metodą). Ruby, jak Smalltalk, wspiera tylko pojedyncze dziedziczenie, ale ma bardzo potężny koncept miksowania: definicja klasy może zawierać moduł, który włącza z tego modułu do klasy metody, stałe, itp.

Ruby, znowu jak Smalltalk, udostępnia domknięcia i bloki kodu i używa ich w celu osiągnięcia tego samego dobrego efektu. klasy kolecje i iteratory w Rubim są wybitne, dużo bardziej potężne i eleganckie niż prowizoryczne rozwiązania które Python promuje (lambdy i złożenia list).

Składnia Rubiego i filozofia konstrukcji są pod dużym wpływem Perla. Posiada dużo różnorodności składniowej. Instrukcje kontrolne (if, unless, while, until, itp.) mogą pojawić się na końcu instrukcji. Niektóre słowa kluczowe są opcjonalne (na przykład “then” w instrukcji “if”). Nawiasy mogą być czasami pominięte w wywołaniach metod. Wiele, wiele rzeczy jest bezpośrednio przeniesionych z Perla. Wbudowane wyrażenia regularne, $_ i podobne, <do_przetlumaczenia>here_documents</do_przetlumaczenia>, różnica między napisami w apostrofach/cudzysłowach, przedrostki $ i @ dla odróżnienia różnych rodzai nazw i tak dalej.

Jeśli lubisz Perla, polubisz Rubiego i będziesz czuł się jak w domu z jego składnią. Jeśli lubisz Smalltalka, polubisz Rubiego i będziesz czuł się jak w domu z jego semantyką. Jeśli lubisz Pythona, możesz lub nie być odrzucony z powodu dużej różnicy wynikającej z filozofii konstrukcji Pythona i Rubiego/Perla.

Ruby jest dużo bardziej złożony niż Python, ale jego cechy, w większej części, dobrze ze sobą współpracują. Ruby jest dobrze zaprojektowany i pełen przyjemnych idei, które mogą mogą być <do_przetlumaczenia>mined for P3K</do_przetlumaczenia>. Nie jestem pewien jednak jak wielu programistów Pythona będzie zainteresowanych nim - u mnie nie wygrał (jeszcze). Ale jest wart przestudiowania i może być poważnym zagrożeniem dla Perla.

2

[quote=rofro]http://faq.rubygarden.org/entry/show/14?controller_prefix=faq
2.1: Jak Ruby przedstawia się w porównaniu do Pythona?[/quote]
To zabytkowy tekst z roku 2000. Python się bardzo zmienił od tego czasu. Nie umniejszając Twemu trudowi, ten tekst jest przestarzały i z błędami. Jako że trochę znam oba języki, pozwolę sobie na parę słów komentarza.

Wcale nie automagicznie. Automagicznie to implicite, ukrycie, domyślnie. To przekazywanie receivera w Pythonie jest jawne i jest spójne z cała jego filozofią (tj. explicite is better than implicite) Poza tym to nie musi być self. Tak konwencja dotyczy metod instancji. Dla metod klasowych używa się konwencji cls. A dla statycznych nie ma żadnego receivera, co jawnie pokazuje, że taka metoda nie jest związana z obiektem.

To jest już zupełnie nieaktualne. Python pozwala na tworzenie podklas ze wszystkiego i to obowiązuje już od dawna, od wersji 2.3.

To nie śmieci, ale efekt hybrydowości Pythona. Ale skoro już jesteśmy przy śmieciach, to jest to dobre określenie na kupę bezsensownych aliasów do metod w obiektach Rubiego. Nie dość, że podstawowych metod są tam setki, to na dodatek ich ilość jest sztucznie powiększona przez aliasy. To są te same metody ale pod innymi nazwami. Nie jestem przeciwko aliasom, ale nawrzucanie ich do bibliotek standardowych to jest istotnie śmietnik. Spróbujcie znaleźć odpowiednią metodę pośród 300 na liście. Dla odmiany, Python stosuje zasadę, że im mniej tym lepiej, tzn. powinna istnieć najlepiej tylko jedna metoda do osiągnięcia tego samego celu. Stąd Python posiada mniej metod, łatwiej cokolwiek znaleźć. Na dodatek posiada docstringi, dokumentację zintegrowaną z obiektami, co bardzo ułatwia znalezienie tego, co się szuka.

Domieszkowanie klas (mixins) jest innym rozwiązaniem na obejście braku dziedziczenia wielobazowego w Rubim. Python posiada dziedziczenie wielobazowe więc takie rozwiązanie jak wq Ruby nie jest mu potrzebne. Jeszcze inne języki (PHP5) stosują w tym wypadku inny mechanizm, interfejsów. Nie wiadomo czy mixins Rubiego przetrwają, bo Matz twierdzi że są zbyt skomplikowane i myśli nad jakimś ich zastąpieniem. Co do stałych Rubiego, to jest to żart. Nie ma tam stałych, skoro stałe można zmienić i Ruby nie wyrzuci wyjątku (tylko warning).

Lambdy posiada i Ruby. Nie “złożenia list”, ale “wyrażenia listowe”. Nie są one w żadnym stopniu prowizoryczne. (ciekawostka: pythonowe wyrażenia listowe mają być w JavaScript 1.7) Są potężne i czytelniejsze (choć to rzecz gustu) niż analogiczne struktury w Ruby. Szczególnie widać to na przypadku zamiany wyrażenia listowego na generator. Np.

[code]lista = [item for item in items if item > 10]

ale już jest generator:

for x in (item for item in items if item > 10):
print x[/code]

Święta racja. Python jest klarowniejszy, jawniejszy - przez jego kod jest łatwiejszy w utrzymaniu. Ruby pozwala na pisanie bardzo eleganckiego kodu ale kosztem większych nakładów pracy i czasu.

[quote=rofro]Ruby jest dobrze zaprojektowany i pełen przyjemnych idei, które mogą mogą być
<do_przetlumaczenia>mined for P3K</do_przetlumaczenia>.[/quote]
Może chodzi o “które mogą stać się podwalinami dla P3K”?

Co do “dobrego zaprojektowania”, to można się zgodzić, ale nie w pełni. Ruby 2.0 wprowadzić ma całkiem sporo zmian. Np. Matz stawia pod znakiem zapytania otwarte klasy: (sic!). Jeśli je usuną to Railsy od razu padają, bo są silnie na tym oparte. Składnia słowników/haszy ma być zerżnięta z Pythona (czyli {‘key’:‘value’} zamiast {‘key’ => ‘value’}.

Mają być dodane także “named parameters” (nie wiem jak to oddać po polsku) . Ich brak to jedna z większych niedoróbek Rubiego. Dlatego Railsy tak intensywnie przekazują wszędzie hasze aby “symulować” tą cechę. Niestety, hasze to tylko prowizorka i na dodatek kulawa. Umożliwia przekazanie nie istniejących kluczy to metody i Ruby nawet się nie zająknie. Aby to kontrolować trzeba byłoby dodać dodatkowy kod, ale tego z kolei nikt nie chce robić, bo to byłoby bardzo nieeleganckie.

To porównanie nie wspomina nic o Unicode. Choć może pod koniec 2000 tego jeszcze nie było w Pythonie (nie pamiętam, dodano to chyba od Pythona 2.2, ale mogę się mylić) Brak pełnego Unicode jest też bolączką Rubiego. Ma to rozwiązać dopiero wersja 2.0. Na razie trzeba się liczyć z tym, że “napis”.length podaje… ilość bajtów (co nie ma żadnego już sensu w wypadku korzystania z UTF-8). Na dodatek “napis”[1] zamiast zwrócić znak “a” zwraca, nie wiedzieć dlaczego, jego bajt! To jest ewidentna niedoróbka i ma być też zmieniona w Ruby 2.0. Matz też chce skopiować ideę pythonowego rozwoju języka za pomocą PEP.

Dziwię się też, że autor tego tekstu nie wspomniał o modułach Pythona. Są znacznie doskonalsze niż owo, podobne do PHP “require plik”. Ta metoda nic nie mówi o tym co się dzieje. Nie wiadomo co zostało dodane do przestrzeni nazw. Trzeba zajrzeć do pliku. A co jak on ma też “require” do pliku, który z kolei ma swoje “require”? Robi się szukanie igły w stogu siana. W Pythonie nazwa pliku określa automatycznie przestrzeń nazw. O ile się nie mylę, Matz rozważa dodanie czegoś takiego do Ruby 2.0.

[code]import mymodule

wszystkie obiekty z tego pliku sa dostepne z prefiksem mymodule

from mymodule import to, tamto

ładuje do bieżącej przestrzeni nazw dwa obiekty.

from mymodule import cos as cos_innego

ładuj selektywnie obiekt z modułu do bieżącego namespace pod inną nazwą[/code]

Może ja czegoś nie rozumiem, ale w Ruby w ogóle nie ma żadnego odpowiednika dla ostatnich dwóch komend. “include modul” ładuje wszystko jak leci (odpowiada pythonowemu: “from modul import *”) Ładowanie wszystkiego “jak leci” jest niepotrzebnym zaśmiecaniem przestrzeni nazw. Tak samo to nawalenie, bez upamiętania, aliasów do obiektów.

Acha, zapomniałem też dodać o zwracaniu wielu wartości. Dziwne, że Ruby tego nie potrafi. To bardzo wygodna sprawa.

def fun(): return 1,2,3 x,y,z = fun()
Ruby 2.0 też ma dodać: coś podobnego do pythonowych dekoratorów…

W sumie jakoś nie widzę aby Python się uczył od Rubiego. Jest raczej odwrotnie. Reszta tekstu jest w zasadzie OK.

3

To nie śmieci, ale efekt hybrydowości Pythona. Ale skoro już jesteśmy przy śmieciach, to jest to dobre określenie na kupę bezsensownych aliasów do metod w obiektach Rubiego. Nie dość, że podstawowych metod są tam setki, to na dodatek ich ilość jest sztucznie powiększona przez aliasy. To są te same metody ale pod innymi nazwami. Nie jestem przeciwko aliasom, ale nawrzucanie ich do bibliotek standardowych to jest istotnie śmietnik. Spróbujcie znaleźć odpowiednią metodę pośród 300 na liście. Dla odmiany, Python stosuje zasadę, że im mniej tym lepiej, tzn. powinna istnieć najlepiej tylko jedna metoda do osiągnięcia tego samego celu. Stąd Python posiada mniej metod, łatwiej cokolwiek znaleźć. Na dodatek posiada docstringi, dokumentację zintegrowaną z obiektami, co bardzo ułatwia znalezienie tego, co się szuka.[/quote]
Hmm, mówiłem pół roku temu to samo to się nie chciałeś zgodzić :wink:

Lambdy posiada i Ruby. Nie “złożenia list”, ale “wyrażenia listowe”. Nie są one w żadnym stopniu prowizoryczne. (ciekawostka: pythonowe wyrażenia listowe mają być w JavaScript 1.7) Są potężne i czytelniejsze (choć to rzecz gustu) niż analogiczne struktury w Ruby. Szczególnie widać to na przypadku zamiany wyrażenia listowego na generator. Np.[/quote]
Nie wiem, co z wami jest. Nie moglibyście zamiast licytować się na przymiotniki typu “potężne”, “eleganckie”, “prowizoryczne”, “czytelne” pisać o konkretach?

Święta racja. Python jest klarowniejszy, jawniejszy - przez jego kod jest łatwiejszy w utrzymaniu. Ruby pozwala na pisanie bardzo eleganckiego kodu ale kosztem większych nakładów pracy i czasu.[/quote]
vide supra - “klarowniejszy”, “jawniejszy”, “łatwiejszy”. Czy wy Panowie robicie w PRze czy co? :wink:

Kompletna pierdoła. Co prawda kluczowa dla czytelności w językach funkcyjnych (pattern matching), ale bez wsparcia reszty infrastruktury funkcyjnej, w językach imperatywnych to jest na prawdę pierdoła. Czasami pozwala uniknąć jednej linii kodu - wielkie mecyje.

No proszę, szanowny kolega zmienia front coś ostatnio :wink:

4

Hmm, a czym konkretnie nie chciałem się zgodzić?

“Prowizoryczne”, to słowa z tego tekstu z 2000 r. kiedy Python wyglądał trochę inaczej niż dziś. Co do elegancji to i tak osoba chowana na C tego nie zrozumie. :slight_smile: Ruby pozwala na pisanie pięknego kodu. Każdy, kto więcej pracował z Ruby zauważa, że kod Rubiego potrafi wyglądać bardzo estetycznie. Ale aby dobrze pisać w Ruby trzeba znacznie więcej wiedzy niż poczytanie Agile2 czy pobawienie się w Railsach. Ruby przypomina mi pod tym względem Perla, którego można poznawać latami i ciągle coś ciekawego się odkryje. To może być nawet ekscytujące doświadczenie dla niektórych.

“klarowniejszy”, “jawniejszy”, “łatwiejszy”. Czy wy Panowie robicie w PRze czy co? ;)[/quote]
Nie chwytasz kontekstu? “Jawniejszy i klarowniejszy” bo “explicite is better than implicite”. Oglądając dowolny kod Pythona, wiadomo co, skąd się bierze. Wynika to ze sposobu obsługi modułów i przestrzeni nazw. Z tego wynika, że kod Pythona jest łatwiejszy w utrzymaniu, bo nie trzeba tracić tyle czasu na poszukiwanie co, skąd się wzięło. Z drugiej strony, Ruby ma więcej konstrukcji i metod i pozwala pisać zwarty, ale także czytelny kod, który naprawdę ładnie wygląda (czego bym nie powiedział o np. Perlu, który może jest i zwarty ale niekoniecznie czytelny).

Kompletna pierdoła.[/quote]
Jak dla kogo. W każdym razie Matz chce to dodać do Ruby 2.0.

No proszę, szanowny kolega zmienia front coś ostatnio ;)[/quote]
Nie tak do końca. Być może odkryję jakieś inne problemy w Pylonsach. Wszystko wychodzi w praniu. Dlatego prosiłem Jarka K. aby opisał jakieś wady Pylonsa (zalety generalnie są znane), bo ma w tym praktyczne doświadczenie. Ty też pracujesz z Pylonsami. Chętnie poczytam coś krytycznego, bo poza rozproszoną dokumentacją i większą trudnością w opanowaniu SQLAlchemy to wiele nie widzę. Wiem że jest SQLObject, ale wszyscy mówią, że SQLAlchemy jest lepsze. Trudno mi to dokładniej zweryfikować. Muszę potestować. Na razie najbardziej mi odpowiada składnia djangowego ORM’a. BTW, załóż jakiś blog, gdzie byś się trochę powyżywał. :slight_smile:

5

[quote=jzabiello]Acha, zapomniałem też dodać o zwracaniu wielu wartości. Dziwne, że Ruby tego nie potrafi. To bardzo wygodna sprawa.

def fun(): return 1,2,3 x,y,z = fun()
[/quote]
Myślę, iż jednak potrafi:

irb(main):001:0> def foo; [1,2,3]; end => nil irb(main):002:0> a,b,c = foo => [1, 2, 3] irb(main):003:0> a => 1 irb(main):004:0> b => 2 irb(main):005:0> c => 3

6

[quote=daniel]Myślę, iż jednak potrafi:

irb(main):001:0> def foo; [1,2,3]; end => nil irb(main):002:0> a,b,c = foo => [1, 2, 3] irb(main):003:0> a => 1 irb(main):004:0> b => 2 irb(main):005:0> c => 3
[/quote]
To jest dosyć mętne. Można dać mniej zmiennych, np. a,b = foo() mimo że zwracana była lista trzech wartości i Ruby nie rzuci wyjątku. Trudno taki błąd potem odnaleźć. Matzowi się to nie podoba, uważa że to jest zbyt skomplikowane i nikt tego nie rozumie. W Ruby 2.0 chce to zmienić.

7

Proszę: http://blog.netstation.pl/ są i wady :slight_smile:

8

Przydałby się jakiś soczysty flame war Rails vs Pylons vs Django :slight_smile:

Ja jestem cały czas rozdarty - poznaję Rubiego i Railsy, widzę dużo zalet, trochę wad, zastanawiam się nad Pythonem. Niby wszystkie frameworki są opisane, niby są porównania, ale chyba nie widziałem żadnego dobrego tekstu, który opisałby to wszystko od strony praktycznej. Wszystko to trochę taka teoria: ror ma to, django ma tamto, ror nie ma tego, ale za to ma siamto. :slight_smile:

9

[quote=drogus]Przydałby się jakiś soczysty flame war Rails vs Pylons vs Django :slight_smile:

Ja jestem cały czas rozdarty - poznaję Rubiego i Railsy, widzę dużo zalet, trochę wad, zastanawiam się nad Pythonem. Niby wszystkie frameworki są opisane, niby są porównania, ale chyba nie widziałem żadnego dobrego tekstu, który opisałby to wszystko od strony praktycznej. Wszystko to trochę taka teoria: ror ma to, django ma tamto, ror nie ma tego, ale za to ma siamto. :)[/quote]
Można by dużo pisać. :slight_smile: Ograniczę się do kilku spraw. Dużą rolę odgrywa twoje wcześniejsze doświadczenie. Jak ktoś wcześniej programował w PHP, to Ruby i Rails jest jak powiew świeżego powietrza. Ale jak ktoś używał Pythona (tak jak ja), to już sam Ruby nie robi aż takiego wrażenia. Rails robił, owszem (i dlatego się nim zainteresowałem, a przez niego Rubim), ale z chwilą pojawienia się Django i Pylons, ta różnica już nie jest tak wielka, a nabierają wagi (przynajmniej dla mnie) różnice między językami (głównie odnośnie filozofii niż samej składni). To co, w moich oczach stawia Pythona, wyżej to przede wszystkim fundamenty na jakich go zbudowano. M.in. “Podejście jawne jest lepsze niż domyślne”, "Proste jest lepsze niż złożone, “Złożone jest lepsze niż skomplikowane”, “Błędy nie powinny nigdy przechodzić niezauważone”, “Powinna być jedna, i najlepiej tylko jedna, oczywista droga do osiągnięcia tego samego celu”. Z tego wynika mnóstwo konkretnych spraw.

Ruby i Rails ma swoje plusy. Trzeba może dużo więcej się uczyć aby osiągnąć porównywalną biegłość w posługiwaniu się językiem, ale końcowy kod jest bardzo piękny (od strony estetycznej). Może dla niektórych to nieważne, ale dla mnie się liczy. Na brzydki kod aż nie chce się patrzyć, nie mówiąc o pracy z nim. :wink:

Odnośnie złożoności, framework Rails to inna sprawa. Został tak zbudowany i ma tak dobre książki, że bardzo szybko można zacząć coś tworzyć. Wystartowanie i praca w Pylons czy Django (mimo że to drugie ma całkiem niezłą dokumentację) trwa znacznie dłużej. Rails to najprostszy framework jaki znam. Nawet nie trzeba znać dobrze Rubiego aby coś konkretnego w Railsach stworzyć. Może to też dlatego, że Ruby i Rails mają także znacznieeeeeee lepszą dokumentację niż wszystkie pozostałe pythonowe frameworki razem wzięte. Przez dokumentację mam na myśli głównie wysyp świetnych książek, z czego już część jest (i będzie więcej) po polsku. I wydaje się że społeczność skupiona wokół Ruby jest bardziej pomocna, bardziej zapalona, niż ta wokół Pythona.

Z innych spraw. Rails i Django wykazują znacznie większą integrację niż Pylons (nic dziwnego, Pylons to megaframework, składanka zewnętrznych modułów WSGI). Z językiem Ruby to trochę jak z Perlem. Ciągle możesz się go uczyć i nigdy się nie znudzi, bo ciągle coś nowego można odkryć (tylko że w ładniejszej, niż Perl, formie). Sam Python jest prostszy do nauki i szybciej można zacząć coś robić. (choć nie chcę powiedzieć że cały Python jest prosty, bo metaprogramowanie i niektóre zagadnienia są w nim całkiem skomplikowane, nawet bardziej niż w Ruby. Ale do większości zadań, jest prostszy)

Z praktycznych kwestii w RoR drażnią mnie 2 rzeczy: (1) co by nie mówić, słaba wydajność (szczególnie dokuczliwy wolny tryb developerski). Przeładowywania stron Django czy Pylons podczas prac nad kodem są znacznie szybsze. (2) RoR ma też za dużo magii i metod w globalnej przestrzeni nazw (często trudno coś znaleźć i trzeba szukać po książkach i w necie).

Z kolei bardzo podoba mi się integracja z Ajaksem i te wszystkie helpery, np. formularze bazujące na closures. Tu Rails naprawde błyszczy. Rozmawiałem z developerami Pylonsów, ale oni jakoś nie wykazują entuzjazmu aby dodać helpery do Ajaksa. Zresztą mówili, że nie da się napisać odpowiednika RJS (odnośnie tych wszystkich jego pętli) dla Pythona z powodu jego odmiennej składni. I to jest nie do przeskoczenia. Z kolei Django w ogóle nie ma żadnych helperów ani do JavaScript ani czegoś co by ułatwiło pracę Ajaksem. Trzeba sobie pisać w czystym JavaScript (najlepiej: Prototype) Jeśli więc ktoś chce napisać aplikację z duża ilością interaktywnego kodu w Ajaksie to Rails chyba będzie najlepszym wyborem.

W Pylonsach brakuje mi odpowiednika panelu Django czy choćby scaffoldingu w RoR. Nie podoba mi się także składnia ani SQLObject ani SQLAlchemy (ten drugi, to w ogóle nawet nie wiadomo jak zacząć używać, jest może potężny, ale przesadnie (jak na Pythona) skomplikowany i daje za dużo możliwości różnego użycia (to też jest wbrew filozofii “jednej drogi”). Jeśli chodzi o ORM, to gdyby tak podszlifować Active Record (generatory, możliwość opcjonalnego definiowania pól) to byłby the best. Na razie najbardziej mi się spodobała składnia ORM w Django. Jest szybki, prosty i bardziej obiektowy (AR dla warunków wymaga w praktyce klepania SQL’a; jest plugin który to poprawia, ale to powinno być zintegrowane z głównym kodem)

Hehe, nie wiem czy to poprawi sytuację osoby niezdecydowanej na wybór frameworka. :slight_smile:

10

Cytując Steve Yegge: “Dodając odpowiednio dużo chilli, zrobisz z kupy dobre jedzenie” - czyli “dając odpowiednio dużo wysiłku i starań napiszesz świetną aplikację webową w PHP4”.

IMO oba języki są na tyle dynamiczne, że można w nich oddać dosyć dobrze większość abstrakcji potrzebnych w programowaniu aplikacji webowych. Przy wyborze nie powinno się porównywać Python vs. Ruby tylko raczej “Jakie nasi programiści mają doświadczenie w danym języku, które biblioteki znają lepiej itd.”.

Być może Ruby ułatwia niektóre aspekty metaprogramowania, jest bardziej “lispowy”, tworzenie Domain Specific Languages jest bardziej naturalne - ale to z pewnością nie przeszkodzi doświadczonemu programiście Pythona czy nawet Javy obejść ograniczeń ich języka i zrobić tą samą funkcjonalność - no, może trochę większym nakładem pracy.

Być może też Ruby jest ogólnie rzecz biorąc wolniejszy niż Python, ale to nie przeszkadza w zrobieniu bardzo szybkiego serwisu www opartego na Railsach - pod warunkiem, że mamy do dyspozycji dobrego admina, który wszystko ładnie skonfiguruje i włożymy odpowiednio duży nacisk na myślenie o “skalowaniu” aplikacji, optymalizacji zapytań itd.

Spójrzmy prawdzie w oczy - pisanie aplikacji webowych to w 90% pobranie danych z bazy i wyświetlenie ich na ekranie - szybkość języka przy korzystaniu z frameworka ma tu drugorzędne znaczenie - zakładając że nie obliczamy w międzyczasie toru statku kosmicznego i ewentualnych kolizji z asteroidami :wink:

Ech, możnaby ten wątek ciągnąc w nieskończoność :wink:

11

Właśnie, właśnie proponowałbym ubić te gadki - wbrew pozorom wiele nie one nie wnoszą.
Ileż to razy każdy z nas zaczynając poznawać nowy framework, język czy bibliotekę szukał porównań, zestawień, opinii, komentarzy. I co? i nic praktyka, praktyka i jeszcze raz praktyka. Postaw pierwszy krok, popróbuj zobacz, zepsuj - wtedy masz baze aby samemu oceniać co jest ok a co zdecydowanie nie.
Odwracając cytat dot. chilli gdyby istniał framework wyposażony w telepatyczne polączenie z umysłem developera z dodatkiem AI - zbudowany tak, że developer myśli o problemie, a komputer generuje rozwiązanie - to czy to uratowałoby nas przed nędznymi, źle przemyślanymi rozwiązaniami? Nie sądzę.

Więc zamiast trawić czas na czytanie porównań lepiej w zrobić dla wprawy kolejną Todo List, Wykop czy… webankiete :wink:

12

Wiesz, ja tak czy tak się nauczę Pythona i popróbuję coś napisać, ale teraz brakuje mi trochę czasu (sesja…), a żeby dobrze się zapoznać przydałoby się chociaż kilka dni nad tym posiedzieć :slight_smile: Ale lubię jednak usłyszeć więcej niż mniej opinii :wink:

13

To mnie zaintrygowało. Biorąc pod uwagę, że silnik bazodanowy napisany jest raczej w szybkim języku kompilowanym, to chyba większość czasu poświęconego na zapytanie idzie na te wszystkie zabawy z inicjowaniem controllera, potem zbudowaniem obiektów z odpowiedzi bazodanowej, a potem parsowaniem template’u HTML.

Ciekawe na ile przyspieszyłoby pracę Rails, gdyby baza danych zwracała od razu zserializowane obiekty Rubiego zamiast litanii ASCII, którą trzeba sparsować, skonwertować do odpowiednich typów, itd. :slight_smile:

14

Ruby też jest napisany w szybkim języku kompilowanym :smiley:

15

:smiley: Ta… Ale do sparsowania pozostałoby tylko zapytanie w SQL, a potem odpowiedź jako obiekty Rubiego. Miodzio. Nienawidzę całej tej koncepcji human-readable języka zapytań i odpowiedzi z całą tą ASCII-niewydajnością. Data i czas przesyłana jako kilkanaście bajtów, tragedia :slight_smile: Dlatego jak dotąd wolałem rozwiązania bazodanowe takie jak 4D. Ale dla Railsów zdradziłem 4D :slight_smile:

16

A ja się tak zastanawiam co w razie tych zmian, o których piszesz. Przepisanie railsów?

No i jeszcze myślałem chwilę nad tymi otwartymi klasami. Nie dość, że Railsy często gęsto to wykorzystują, to jeszcze większość pluginów. Tylko coś mi się wydaje, że community railsów mogłoby nie dać żyć biednemu Matzowi gdyby jednak chciał coś takiego uczynić :wink:

I jak tak patrzę na te zmiany, to niedługo Ruby się będzie niewiele różnił od Pythona :wink:

17

Fakt, że Matz przygotował taką prezentację nie oznacza, że w Ruby 2 znajdziemy to wszystko o czym pisał. Wersja 1.9 ma być testowana przez rok, z największych zmian jakie zauważyłem to dodanie YARV, nie widać póki co żadnej rewolucji więc byłbym ostrożny w zbyt wczesnym martwieniu się o przepisywanie Railsów na 2.0 :slight_smile:

Swoją drogą, badał ktoś dokładniej 1.9 i może powiedzieć co się zmieniło ? Klasy chyba wciąż są otwarte ?

18

[quote=drogus]A ja się tak zastanawiam co w razie tych zmian, o których piszesz. Przepisanie railsów?

No i jeszcze myślałem chwilę nad tymi otwartymi klasami. Nie dość, że Railsy często gęsto to wykorzystują, to jeszcze większość pluginów. Tylko coś mi się wydaje, że community railsów mogłoby nie dać żyć biednemu Matzowi gdyby jednak chciał coś takiego uczynić ;-)[/quote]
Myślę, że Matz jednak nie pozamyka klas. To byłaby zbyt wielka zmiana. W wersji 1.9 nic nie pozamykano rzecz jasna.