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.

[Zyx]

hipertrackerze, odpowiem Ci w sposób następujący: a co Ty za pierdoły, za przeproszeniem, wypisujesz? Masz taki sam monopol na prawdę, jak każdy tutaj na tym forum, więc trochę wyluzuj człowieku.

Ad. obiektówki -> mylisz się już na samym początku, co średnio rzutuje na Twoją rzetelność i znajomość tematu. Obiektów można było już używać w PHP3, natomiast nikt tutaj nie podważa tego, że sensowny model obiektowy pojawił się dopiero w PHP5. Czy jest kiepski? To jest Twoje zdanie - mi osobiście niewiele w nim potrzeba do szczęścia, natomiast dla odmiany wkurzała mnie obiektówka w Rubym (mixiny to wg mnie wynalazek równie szatański, jak wielokrotne dziedziczenie).

Ad. wielowątkowości -> hehehe, bardzo podoba mi się, jak ktoś chwali się tym, że Ruby ma "wielowątkowość". Prawdziwa wielowątkowość w tym języku jest dopiero od niedawna, a wcześniej do dyspozycji była jedynie implementacja "zielonych wątków", czyli emulacja takowych na poziomie maszyny wirtualnej. Kumpel napisał jakiś czas temu w Rubym program do grania w szachy i niestety komputer wykonywał obliczenia dot. swojego ruchu jedynie wtedy, gdy się myszką ruszało po ekranie. Ponadto wielowątkowość wcale nie jest potrzebna, by pisać aplikacje współbieżne. Powołujesz się na wiele mądrych i uczonych języków, zatem pewnie słyszałeś o czymś takim, jak Erlang. Tam nie ma w ogóle żadnych wątków, muteksów, semaforów itd., a mimo to język ten nadaje się moim zdaniem dużo lepiej do tworzenia aplikacji współbieżnych niż np. Ruby, Python czy Java. Pomijam już fakt, że aby mieć cokolwiek ze współbieżności, trzeba najpierw nauczyć się pisać takie aplikacje.

Co do wad PHP to jest to temat powszechnie znany. To język bardzo źle, wręcz amatorsko zaprojektowany. Jest chaotyczny i niespójny (znana sprawa niespójnej konwencji nazw funkcji czy nieintuicyjnej kolejności przekazywania parametrów formalnych).

Każdy język ma błędy. Ja jestem świadomy wad PHP i nie robię z tego wielkiego halo. Czy Ty jesteś świadom wad Rubiego? Jeśli nie, odsyłam do mojego poprzedniego posta w tym temacie.

Dokumentacja? Jest cała masa książek, screencastów i innych materiałów http://weblog.rubyonrails.org/2010/8/28/ra...t-documentation

Fajnie, a ja w tej masie książek, screencastów i innych materiałów nie mogłem się doszukać potrzebnych mi informacji dot. np. działania Active Record i paru innych potrzebnych mi rzeczy...

Jak towarzystwo pewnie wie, PHP z definicji, pracuje w tak zwanym trybie CGI.

Jak każdy wie, kto trochę więcej siedzi w temacie PHP, piszesz wielkie głupoty. Poczytaj sobie, czym jest CGI, a później zajrzyj do dokumentacji PHP i poczytaj, jak PHP współpracować może z serwerami WWW. W ogóle w temacie wydajności ocknij się człowieku, Rasmus Lerdorf już od wielu lat pełni jedynie drugorzędną rolę przy pracach nad PHP. Ostatnią wersją, którą faktycznie tworzył, było PHP/FI 2.0...

Ogólne podsumowanie - tja, tylko było czekać na jakiś desant fanatyka Rubiego. Zarzuci kupą linków, poprzekręca mnóstwo rzeczy i pominie niewygodne fakty, o wadach Rubiego nie piśnie, bo i po co? Trochę o dziwo w Rubym programowałem i wiem, co tak naprawdę kryje się za tą całą propagandą i marketingową otoczką. Było trochę fajnych rzeczy, ale były też wady, niedoróbki i chybione rozwiązania i ogólnie nie znalazłem tam nic na tyle wyjątkowego, by przekreślać 9 lat doświadczenia z PHP. Co więcej, pisząc takim językiem odrzucasz mnie, drogi hipertrackerze, od środowiska programistów Rubiego jeszcze bardziej. W tym momencie nie jesteś dla mnie ani wiarygodny, ani autentyczny, bowiem dla mnie jedynym bytem doskonałym jest Bóg, a z tego, co mi wiadomo, imieniem Boga na pewno nie jest Ruby. Jeśli widzisz drzazgę w oku bliźniego, a nie potrafisz dostrzec belki w swoim, nie mamy o czym dyskutować.