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]

Hipertracker to mam zasadnicze pytanie dla przykładu z obiektowymi bazami danych: Widziałeś jak w standardzie wygląda dowiązanie dla obiektowych baz danych dla C++? Kijowo. Standard takich baz niby istnieje ale dlatego obiektowe bazy "wtopiły" bo przez grube lata nie były ustandaryzowane i przegrały wojnę z RDBMS. Standard jest chyba już od 2000 roku w wersji 3.0, ale wcześniej to była bieda z nędzą i tylko w sumie 3 języki mają jakieś dowiązania: C++, Smalltalk i Java. Spośród nich C++ ma najgorsze. Dodatkowo każdy z tych (i nie tylko tych) języków pozwala na samodzielne napisanie takiej bazy w zależności od wymagań projektu, więc to nieco dziwne by uznać ów przykład za wadę/wyższość jednego języka nad innym.

Teraz nieco na punkty odpowiem...
1) elastyczność, elastycznością, ale jeśli klient zmienia Ci nie coś z modułu ale wymaga zmian w szkielecie aplikacji to i tak jesteś z ręką w nocniku. I tutaj nawet najbardziej zajebisty język świata nie pomoże. A i takie zmiany nieraz bywają. Dobrze napisany i przemyślany projekt jest do wdrożenia w dowolnym języku. Czy będzie to php czy ruby - sprawa drugorzędna. Błędy na poziomie projektowania aplikacji zemszczą się, nieważne w jakim języku pracujesz.
2) nieco haczy o punkt pierwszy. Źle zaprojektowana aplikacja i trzymanie złych nawyków, złych wzorców rozłoży każdy projekt i sprawi, że będzie nieczytelny do granic możliwości. Ładnie uporządkowany, będzie czytelny i łatwy do konserwacji oraz modyfikacji niezależnie od użytego języka czy podejścia (strukturalny dobrze zrobiony nie jest wcale gorszy do konserwacji niż obiektowy). Może być, że jeden z nich zrobi jedną funkcją to co inny 3-4 bardziej elementarnymi, ale to jedyna poważniejsza różnica tak naprawdę.
3) sam zauważyłeś, że punkt 3 wynika z 2. Nadal Twoje prawdy są bardzo ogólne i pasują do dowolnego języka programowania. Nie tylko Ruby'ego.
4) tutaj plus dla języków, które mają pewne mechanizmy wbudowane. Nie wiem jak w Rubym to jest zrobione, ale zapewne nie jest to "out of box" i sam to musisz oprogramować by działało jak opisujesz. Jeśli tak jest jak piszę, to przynajmniej część języków także potrafi to sobie zaimplementować. Znając życie polecimy z użyciem debug_backtrace w php ;)
5) Biblioteki/aplikacje tego typu o jakich wspominasz (konkretnie do testów). Niewątpliwy plus.
6) Nie ma takiej aplikacji, która klienta nietechnicznego by "nauczyła posługiwać się" informatycznymi terminami lub przetworzyła język naturalny na specyfikację techniczną. Są tylko tego mniej lub bardziej udane próby. Z reguły mniej. Klient i tak może Ci przez 10 spotkań mówić, że chce tak i tak, by na 11 stwierdzić, że jednak miało być inaczej i inaczej to on tłumaczył, nazywał, a Ty go po prostu źle zrozumiałeś. Najczęściej są to zmiany dodawane na szybko, bo się klientowi coś "uwidziało", a przecież "klient ma zawsze rację" ;)
7) szybkość jest w dużej mierze wynikiem doboru testów i kryteriów oceny. Szybkość jest wynikiem walki z zasobożernością. Chcesz mieć system szybki? Pakuj do RAMu najczęściej używane rzeczy i masz już przyrost wydajności. Ale licz się z tym, że jeśli przesadzisz, efekt będzie odwrotny do zamierzonego, a i serwer może nie wytrzymać obciążenia. Tak więc prawdziwie miarodajne testy pokrywały by wiele aspektów działania strony/serwisu/portalu/aplikacji, począwszy od obsługi plików, poprzez bazy danych, generowanie grafiki, czy dokumentów, a całość pod kątem nie tylko szybkości, ale i zużywanych zasobów przy takiej samej maszynie testowej. Tylko to ma jakikolwiek sens by wyłapać "atrakcyjność" danej platformy. Niektóre nie nadają się na małe serwery, inne tylko na takich czują się dobrze i mają jedyny sens z racji zastosowanych rozwiązań. Przykład? Systemy/aplikacje embedded. Z założenia pracują w innych warunkach niż normalne i inaczej rozwiązuje się w nich pewne problemy. Tu nie zawsze liczy się czas, ale konieczność choćby pracy w ograniczonej i nierozszerzalnej pamięci. Tak lubisz jRuby ale masz zapewne świadomość, że im mniej pamięci tym to rozwiązanie zaczyna radzić sobie gorzej i GC tutaj zaczyna po prostu aplikację zajeżdżać, bo jest wywoływany bardzo często. Nieraz zbyt często. Tutaj już optymalizacje JVM niewiele pomogą. GC zaczyna stawać kością w gardle, choć i tak zachowa się ładniej niż PHP, który po prostu wywali się na braku pamięci ;)
8) znowu mam wrażenie, że odnosisz się głównie do możliwości jRuby zamiast samego Ruby'ego czy też RoR ;) Bardziej to przypomina w takiej sytuacji rozmowę o pisaniu GUI w C++. Są biblioteki pokroju Qt czy wxWidgets i opisywanie ich możliwości, nie wspominając że "goły" C++ bez bibliotek dodatkowych specjalnie do tworzenia i obsługi GUI napisanych kiepsko się nadaje. A przynajmniej ja takie wrażenie odnoszę czytając Twoje posty. Gdy pisaliśmy o języku nie wiedziałem bowiem nigdy gdzie kończy się opis możliwości samego Ruby'ego, a gdzie wkraczałeś na tereny zarezerwowane dla jRuby. Jedynie wstawki niektore zapalały mi lampkę "Kurka... To już chyba w Javie kiedyś widziałem".
9) to samo co punkt 8... Nie wiedzieć czemu mam wrażenie, że gdybyś miał punkt 10, znowu byś rzucił tekstem o Maglevie ;) Nie zrozum mnie źle, ale patrzę na to co piszesz i widzę, że masz duża wiedzę (najprawdopodobniej większą niż moja), ale jednocześnie zamknąłeś się w określonych plusach i poza nie raczej nie wychodzisz. Powiedziałbym, że są nieco jak mantra powtarzane w różnym natężeniu i z użyciem nieco innych słów. Jak widzisz, ja też potrafię pisać "elaboraty", więc na mnie ilość tekstu nie sprawia żadnego wrażenia ;) Już i tak część osób się śmieje, że z moich postów tu na forum bym mógł książkę napisać.

Co do załączonych linków autor zrobił to, co ja już wypunktowałem: JVM dano czas na "rozgrzewkę" zanim przystąpiono do testów, a więc dynamiczny kompilator zoptymalizował się pod maszynę produkcyjną. Oczywiście patrząc na same wykresy nie dowiemy się o tym i potrafią one niektórych przekonać, że jednak Java jest bardzo szybka od razu. C++ nie potrzebuje takich przygotowań. Rusza z odpowiednio ustawionymi parametrami i jego wyniki są powtarzalne. JVM z każdym testem, do pewnego momentu, będzie coraz szybsza. Gdyby rozgrzewki zabrakło wyniki byłyby nieco inne. W dynamicznym środowisku webowym, gdzie mogą następować przełączania serwerów, częste zmiany osłabiają znaczenie dynamicznej kompilacji.