Frameworki PHP vs Ruby On Rails, Skąd ten agresywny marketing w community RoR ? Opcje

[Wiktor P.]

Witam.

Będąc na etapie programisty znającego php trochę lepiej niż średnio rozgarnięty szympans,
poszukuję frameworka, który nauczy mnie dobrych praktyk programistycznych i projektowych (projektowych tzn. odnośnie
całego projektu, włączając w to projekt w UML, coś jak rysunek techniczny dla architekta, tu projekt dla aplikacji).
W grę wchodzi Symfony i Zend - bo znam ludzi, którzy mnie pokierują, doradzą etc.
Wiem, że znajome mi osoby od ww FM zrobią wszystko w swoich narzędziach, bardzo je chwalą, nie chcieli by ich zmieniać.
I tu pojawia się na horyzoncie jeszcze jeden konkurent Symfony i Zend - mianowicie Ruby on Rails.

Przedstawię argumenty pehapowców i rorowców i prosiłbym o rozsądne rozstrzygnięcie, czy argumenty obydwu grup
są cokolwiek warte (pokrywają się z prawdą).
W nawiasach przedstawię własną opinię dot. danego punktu.
Chciałbym podkreślić, że argumenty za lub przeciw dot. wyboru któregoś z frameworków
mają na celu odpowiedzieć na pytania:
- czy nauka danego frameworka wniesie coś dla programisty odnośnie programowania ogólnie (nie zależnie od języka),
- czy nauka danego frameworka przyda się w praktyce (szybkie wdrożenie, hosting).

Proszę również o swoje argumenty odnośnie Symfony, Zend i Ruby on Rails.

1. Argumenty pehapowców za PHP:
- PHP jest prosty do wdrożenia na serwer produkcyjny.
- Miliony użytkowników, wielka społeczność.
- W PHP można zrobić wszytsko - od strony www dla cioci co ma stoisko na bazarze (proceduralnie)
do najbardziej zaawansowanych projektów jakie można znaleźć w sieci.
- Jest ogromna ilość podręczników do PHP po polsku.
- PHP jest kompatybilne wstecz (w rozsądnych granicach).
- Nowoczesne frameworki do PHP oferują wszystko to co konkurencja (Python Django, RoR, Merb i inne).
- Programista nie musi być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.

1a. Argumenty pehapowców przeciw Ruby on Rails.
- Brak polskich książek (te obydwie na rynku są do wersji przestarzałych).
- Hostowanie to dodatkowa praca, dodatkowy czas, dodatkowe problemy.
- Hostowanie to koszmar i drożyzna.
- Bez sensu używać do małych projektów (czyli przez conajmniej 50% programistów).
- Kłótnie w samym sercu założycieli frameworka (odszedł twórca serwera mongrel).
- Zdarza się przepiswyanie gotowych już projektów w RoR na PHP np.
a. http://www.wykop.pl
b. http://www.oreillynet.com/ruby/blog/2007/0...ack_to_p_1.html
- Jeśli coś już pójdzie nie tak, to będziesz szukał powodu conajmniej tygodniami w źródłach RoR.
- Brak kompatybilności jakiejkolwiek wstecz. Pojawienie się nowej wersji RoR grozi powrotem do korzeni (może nie trzeba uczyć się od nowa wyświetlania "Hello World", ale trzeba
douczyć się ogromnej ilości nowych rzeczy i zapomnieć o tych starych rozwiązaniach).
- Bardzo agresywny marketing, rodem z telezakupów "Mango", tu zacytuję dla przykładu:
książka "Rails Space" M. Hartl, A.Prochazka - Helion 2008,
str. 31
"Witryna Rails Space (wykonana w RoR) będzie miała wiele elementów kojarzonych z popularnymi sieciami społecznościowymi jak Facebook".
- ZARAZ ZARAZ - Facebook jest w PHP !
str. 26
" (...)stwierdził, że gdy porządnie przyjrzał się PHP, uznał, że jest do niczego(...)".
- brak argumentów.
- Programista RoR MUSI być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.


2. Argumenty zwolenników Ruby on Rails:
- PHP to nakładka na język C.
- RoR jest w Ruby, a ten jest całkowicie obiektowy (moja uwaga: rozumiem, że programista RoR na co dzień wykorzystuje tą obiektowość
i tworzy sobie nowe klasy na bazie znaków "+", "-", "=", ";" itp. ).
- Sam język Ruby daje o wiele większe możliwości niż sam PHP ( moja uwaga: a mimo to, nikt nie używa samego rubiego bez frameworka do webaplikacji ).
- PHP ma koszmarną składnię.
- RoR daje duże możliwości w zakresie ORM, testów jednostkowych, MVC (moja uwaga: podobną funkcjonalność oferował już pięc lat temu CodeIgniter napisany w PHP4).
- Kto raz spróbował RoR nigdy nie wróci do PHP (moja uwaga: to zdanie można znaleźć wszędzie co ma związek z RoR, ale brak argumentacji).
- PHP to bajzel, PHP to zło.
- PHP jest dla dzieci i wieśniaków.
- Rorowiec zarabia więcej niż pehapowiec ( moja uwaga: jeśli zna tak dobrze RoR, że może porównac się z kimś kto np. 5 lat programuje w Zend
i na dodatek w swoim województwie uda mu się znaleźć pracę przy RoR to może rzeczywiście ).

Dziekuję za opnie, wskazówki, swoje uwagi i wszelkie komentarze.

[thek]

Nie znam Ruby'ego, nie uczyłem się go jeszcze, więc nie odniosę, który lepszy czy gorszy gdzie i jak bo zwyczajnie bym wypaczał prawdę. Odniosę za to do przytoczonych punktów, które moim zdaniem przeinaczasz. Patrząc chłodno na całość bardziej mi to przypomina wspomnianą przez Zyx'a ewangelizację czy coś w ten deseń (IMG:style_emoticons/default/winksmiley.jpg) Pominę większość tego co już napisał Zyx. Po co się powtarzać.

Fakt, że przepisano część kodu obiektowego, ale tylko się cieszyć. Poza tym zmiany nie są ogromne, bo inaczej by się ludzie pochlastali na kompatybilności wstecz. Developerzy RoR podchodzą tutaj "na wariata trochę" z tego co wiem. Trzeba uważać na wersje bo można się obudzić z ręką w nocniku po update'cie.

Model obiektowy i jego "kiepskość" to głównie subiektywne wrażenie. Nie każdy wykorzystuje wszelkie możliwości, które obiektówka daje. Uproszczenie pewnych rzeczy w niej jest więc pewny wyjściem. Wspomniane wielodziedziczenie to dla wielu osób kompletna abstrakcja. Nie tylko dla piszących w PHP. Ja z tym w C++ miałem kontakt i wiele osób tego po prostu nie łapie. Inna sprawa, że jest to wykorzystywane rzadko niezmiernie.

Brak wielowątkowości = bezsens tworzenia aplikacji desktopowych w języku? No weź mnie nie rozśmieszaj (IMG:style_emoticons/default/biggrin.gif) Do wszystkich aplikacji pchasz współbieżność? Nie wszystko da się zresztą na wersję taką przetworzyć. Część programu, czemu nie, ale są sytuacje nader często, gdy program jest zwyczajnie zbyt jednolity by można to było zrobić. A uwierz, że dla mnie pisanie programów równoległych (nie współbieżnych jedynie) to nie jest puszcza, bo w przeciwieństwie do wielu uczelni współbieżne i wieloprocesorowe aplikacje mieliśmy całkiem ładnie rozwalone także od strony praktycznej (MPICH).

Ruby w jakiejkolwiek wersji miałby zagrozić językowi C czy C++, no weź sobie jaj nie rób (IMG:style_emoticons/default/biggrin.gif) Rozumiem, że komuś może się jakiś język bardzo podobać, ale nie bądźmy ślepcami. Żaden język interpretowany nie dorówna wydajnością językom kompilowanym. Każdy poziom pomiędzy kodem a maszyną to spadek tejże. Binarka w kodzie maszynowym zawsze będzie szybsza niż kod, który musi przejść przez interpreter by mógł być zrozumiany przez maszynę. A puszczenie tego jeszcze dodatkowo przez coś bonusem - tym bardziej. Szalejesz przykładami korzystającymi z Javy. Proszę bardzo, oto ścieżka. Kod źródłowy, konwerter do formy akceptowalnej w JVM, ona dopiero na maszynę rzuca. Można by się czepiać takich pierdół. GC? Nie znam języka który mógłby powiedzieć, że ma bezbłędnie działający. Są tylko te, które mają go już na tyle przejechanego we wszystkie strony, że trudno znaleźć nań haka. Ale i one walą babole, bo człowiek nie przewidzi wszystkiego.

Multiplatformowość w Ruby nawet z tego co piszesz tutaj to tylko "zrobienie niewolnika z Javy". Jakoś patrzę w to co piszesz i widzę praktycznie zdanie o sensie: "Zabrać Ruby'emu obsługę JVM to traci na oko 80% funkcjonalności" (IMG:style_emoticons/default/winksmiley.jpg) Wszędzie tylko JRuby to, tamto, JVM i GC JAVA super wypas. Tak jakby Ruby był jakimś ubogim kuzynem języka JAVA i wciąż się musi nią podpierać. No sorry, ale tak to wygląda patrząc obiektywnie na Twoje posty (IMG:style_emoticons/default/winksmiley.jpg)

Wspominasz, że to i tamto ma być w R2.0, ale przecież w PHP6.0 też mają być zmiany, więc to trochę dziwne podpierać się, czymś co ma być w przyszłej wersji. Wiesz czy będzie to działać i w jakiej formie? Ja jasnowidzem nie jestem i nie wiem czy zmiany nie przyniosą więcej szkody niż pożytku. To tak jak teraz z chwaleniem IE9.0, który rzekomo ma wszystkie przeglądarki odstawić na tor boczny i zaimplementować obsługę niemal wszystkich standardów od HTML5 poprzez CSS3 i masę innych rozwiązań. O IE 7 i 8 też pisali wiele i widać dobrze co z tego wyszło.

Krótko mówiąc, Twoje posty, zważywszy na częstotliwość słów pokroju "kiepski", "niedojrzały", "nędzny" mówią wyraźnie, że do tematu podszedłeś od razu z pozycji "nawracajcie się na Ruby'ego". Problemem jest jednak mały szczegół... Sypanie linkami nie ukryje tego, że tak naprawdę programiści Ruby'ego mają znacznie mniejsze środowisko i znacznie mniej własnych rozwiązań, bazując częściowo na innych, wydajniejszych językach. Sam nawet niechcący wspomniałeś, że Ruby jest wolniejsze od JRuby, a więc o czym my tu mówimy? Rubym samym w sobie czy jego portach na inne języki? Równie dobrze mozna by rzucać projektami około-php owymi jak wspomniane PHP-GTK i masą innych.