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.

[hipertracker]

Przykładowo rzuciłeś że z Java pochodziły statyczne metody i atrybuty klas. Dziwne to nieco twierdzenie, bo ja z tymi spotykałem się w C, a to na nim, a nie Javie

W C nie ma żadnych klas bo C nie jest językiem obiektowym.

Z C++ więc bym wywodził źródło owych zmian.

Bo ja wiem? C++ posiada dziedziczenie wielobazowe, Java, i PHP5 - nie. Ale nie będę się upierał, bo to nic nie zmienia, gdyż zarówno C++ jak i Java są, w przeciwieństwie do PHP, językami ze statyczną typizacją. I to co ma sens tam, nie musi go mieć w języku dynamicznie typowanym. Ja to się dziwię, że nie wzorowano się na języku prawdziwie obiektowym i dynamicznym, choćby Smalltalku, Ruby czy Pythonie (Ruby powstał tym roku co Java, a Python o rok wcześniej). Zamiast próbować aplikować modelu obiektowy z statycznego do dynamicznego, o wiele sensowniej byłoby podejrzeć to, jak to zrobiono w innych językach dynamicznych.

Czy zakładając swój teraz w RoR przykładowo czy jRuby masz pewność, że za kilka miesięcy będzie on zdolny obsłużyć ruch idący w miliony użytkowników i konieczne będzie zmierzenie się z tym, czego nie przewidywałeś na początku?

No toż właśnie o to mi chodzi, że taka sytuacja mi raczej nie grozi. Na począterk, jeśli uznam, że jakieś fragmenty serwisu należy przyśpieszyć ponad to, co oferuje JRuby, mogę je wymienić na modułu napisane w Javie, lub Scali. Jeśli to za mało, mogę aplikację wpiąć Google App Engine lub inne systemy chmurowe. Ewentualnie mogę dorzucić serwerów i wpiąć się do Terracoty (która skaluje się bez limitów tworząc ciągłą przestrzeń pracy dla setek, lub tysięcy równolegle pracujących JVM). Poza tym mogę podpiąć się do bazy obiektowej (Neodatis, db4o),grafowej (Neo4J) itp., itd. Jak masz dostęp do platformy JVM to raczej żadne ograniczenia skalowalności ci nie grożą.

Co do kosztów, co jak co, ale znaleźć programistę Javy to żaden problem. Będzie droższy od pehapowca, ale też jeden starczy za takich pięciu. Poza tym student informatyki uczy się Javy, więc do jakiegoś prostego zadania nie muszę szukać nie wiadomo jakiego wymiatacza.

Co do php, javy i migracji pomiędzy nimi to skoro jest tak fajnie i różowo, to dlaczego znawców tego drugiego nie ma tylu, skoro to taki powerfull język? Odpowedź jest prosta: "Java nie jest tak przystępna jak php". Wiele osób, które miały kontakt z nią zapewne będzie twierdzić inaczej, ale sam miałem do Javy kilka podejść i po prostu nie podchodzi mi ona. A jakoś C++ nie sprawiał mi problemów szczególnych. W javie nie pomagało mi nawet czytanie ponoć tak przystępnych książek jak "Thinking in Java"

Ależ ja nie twierdzę, że język Java jest powerfull, lecz że Java jako platforma taka jest. Z tą przystępnością języka to trochę przesadzasz. Java to dosyć prymitywny język, może nie aż tak jak PHP, ale na pewno bardziej niż Ruby. Ma dosyć prostą składnię i zasady. Dla pehapowca może tylko trudność sprawiać rozwlekłość składni i to że na każdym kroku trzeba pamiętać o typach. Kiedyś też miałem błędne wyobrażenie o złożoności Javy jako języka. I też próbowałem czytać Thinking in Java (ta książka jest źle napisana). No, ale przecież Java jako platforma nie ogranicza mnie do tego języka, więc nie widzę powodu aby się go trzymać. Sama Java jako język niech sobie zostanie takim asemblerem do JVM. Nawet nie ma sensu walczyć o to aby ulepszać jej składnię (tak jak to robi Microsoft ze swoim C#). PO co, skoro można użyć świetnej Scali jako zamiennika?

Zauważ, że kiedyś w php nie było choćby czegoś takiego jak choćby klasy obsługujące katalogi, a ludzie sami to implementowali bo było potrzebne.

No wiem, pamiętam, że w PHP nie było kiedyś nawet obsługi sesji, i to też trzeba było sobie jakoś obsłużyć. Tylko, że ile ty możesz samemu sobie "doimplementować"? Dużo nie zaszalejesz. A mając dostęp do JVM, po prostu sięgasz i używasz to, co potrzebujesz.

Gdyby wszyscy podchodzili tak jak Ty chcesz, to aplikacje byłyby niemal bezbłędne (wciąż istniały by pewne możliwości wystąpienia problemów), ale ich tworzenie zajmowało by przynajmniej kilkakrotnie więcej czasu i pieniędzy.

Ależ nie. Uważam że należy podchodzić pragmatycznie i zastanowić się czy lepiej napisać daną funkcjonalność samemu, czy skorzystać z gotowca. Nie jestem przciwko pisaniu aplikacji heterogenicznej, czyli takiej która korzysta równocześnie z różnych technologii, nie wykluczając PHP.

PHP i Ruby to języki inne, a ich porównywanie choć może i ma dla kogoś sens, jest raczej średnio przydatne

Dla ciebie może nie, ale dla innych - tak. Nie widzisz porównania, bo nie znasz Ruby. Zakosztuj pracy w Rails to zobaczysz różnicę. Ja też wcześniej nie widziałem wielkiego powodu aby się uczyć Ruby. Nie wydawał mi się ąz tyle wnoszący w stosunku do, wtedy mojego ulubionego, Pythona. Ae o dziwo, Python jako język jest prostszy od Ruby, ale tego nie da się powiedzieć o jego frameworkach. Z ciekawości sprawdziłem czym się różni Rails i mi się spodobała ta jego prostota i elegancja kodu. To był rok 2005. Teraz wiele się zmieniło. Czy wg mnie Rails jest najlepszym framework do webu? Niekoniecznie. Wzorzec MVC ma wiele wad. Chyba bardziej mi odpowiada podejście View-First, jakie zastosowano w Lifcie. Ale to wyższa poprzeczka, bo pisanie kodu w enigmatycznej Scali pełnej pattern matching wymaga pewnego przestawienia. Ale dla większości starczy Rails3.

A jakie duże strony powstały w RoR ? Nie za bardzo słyszałem.

Ruby (lub JRuby) on Rails używany jest przez Twittera, Oracle/Sun, 37Signals, Scribd, Hulu, Github itp. Taki 37signals, (to tam stworzono Rails) ma ponad 5 mln klientów...

* http://storecrowd.com/blog/top-50-ruby-on-rails-websites
* http://www.rubyonrailsgallery.com
* http://rubyonrails.org/applications
* http://rails100.pbworks.com
* http://www.setfiremedia.com/blog/50-of-the...g-ruby-on-rails
* http://webdeveloper.econsultant.com/ruby-r...-projects-sites
* http://kenai.com/projects/jruby/pages/SuccessStories

Ten post edytował hipertracker 5.09.2010, 12:19:55