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]

Co wy tu za pierdoły wypisujecie? Hosting RoR może być tak samo banalny jak PHP. Dzięki Passengerowi (http://www.modrails.com/) wystarczy jedynie dostęp do FTP aby wrzucić pliki. Przeładowanie aplikacji polega na odświeżeniu pliku tmp/restart.txt. Dostępne jest też rozwiązanie oparte na chmurze serwerów (np. Heroku http://heroku.com/). Odpalenie aplikacji RoR jest banalne. Jedna komenda z konsoli klienta i gotowe. Znacie może jakieś dostępne chmury serwerów dla PHP? Albo możliwość odpalania aplikacji webowych w Google App Engine?

Porównywanie samego języka PHP do Ruby'ego to trochę kopanie leżącego. Ruby od początku był językiem obiektowym ogólnego zastosowania, podczas zaś PHP powstawał jako język szablonów i w ogóle nie był obiektowy (dopiero w PHP4 to zmienionio, ale tak nieudanie, że w PHP5 przepisano obiektowość od zera (choć trochę to próżny trud, bo model obiektowy w PHP 5.x jest po prostu kiepski, ale o tym innym razem jeśli jest taka potrzeba).

PHP nie posiada wielowątkowości, więc się zupełnie nie nadaje poza zastosowaniami webowymi (gdzie paralelizmem zajmuje się serwer HTTP) W Ruby można pisać dowolne aplikacje, bez ograniczeń, od skryptów, aplikacji webowych, po aplikacje desktopowe. Np. na Mac OS-X za pomocą MacRuby można tworzyć normalne aplikacje okienkowe. MacRuby (http://www.macruby.org/) to jedna z wielu implementacji Ruby'ego. Jest b. szybka, docelowo ma być alternatywą wobec Objective C.

PHP jedyne co ma to swoją implementację i trochę rozszerzeń w języku C. Nędzne to. Zaś Ruby ma dostęp do wszystkich bibliotek klasy enterprise dla Javy dzięki temu że istnieje javowa implementacja Ruby'ego - JRuby (http://jruby.org). Dzięki temu znika kompletnie problem brakujących rozwiązań. Dzięki JRuby można po prostu wziąć gotową bibliotekę Javy i zintegrować z resztą kodu, np. Railsów. Np. ciekawym rozwiązaniem jest JRuby on Rails pracujący z Neo4j i Lucene. Neo4j to nowoczesna baza grafowa (tu są slajdy z tej prezentacji) a Lucene to dojrzały, dedykowany silnik bazy danych do wyszukiwania pełnotekstowego (tak jak Sphinx ale potężniejszy, bo Lucene potrafi indeksować nawet pliki PDF). Nie tylko integracja z Javą, ale także z .NET (IronRuby) albo w ogóle przezroczysta, skalowalna, smalltalkowa obiektowa baza danych taka jak Gemstone (używa go m.in. giełda NY) dzięki Maglev. O takich zastosowaniach pehapowiec może sobie co najwyżej pomarzyć.

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).
W PHP5 dodano obsługę wyjątków, ale co z tego, skoro nie nie objęto nią wszystkich funkcji standardowych? Przez to nie można ich błędów wyłapywać spójnie za pomocą wyjątków. Najgorsze jednak jest to, że pewne błędy w ogóle nie są do obsłużenia w PHP. Żaden handler wyjątków nie wyłapie fatal error'a wywołanego na próbie wykonania metody na nullu (vide: http://gist.github.com/127274). Taki błąd rozkraczy każdą aplikację PHP i nawet o tym nie będzie się wiedzieć! User dostanie najwyżej biały ekran a błąd zapisze się do logów. Nie ma możliwości napisania kodu samoleczącego się lub choćby automatycznie zgłaszającego mailem takie awarie w kodzie. To, moim zdaniem dyskwalifikuje PHP jako język do poważnych zastosowań.

Chcesz zobaczyć jak się pisze testy do kodu w Ruby? Zobacz np. Cucumber, i RSpec, standardowe biblioteki do takich celów. Spróbuj uzyskać tak elegancki kod dla testów w PHP i śmiesznym PHPUnit. Potrzebujesz zautomatyzować prace na zdalnych serwerach? Zobacz napisany w Rubym - Capistrano (http://en.wikipedia.org/wiki/Capistrano) BTW, można tego używać do dowolnej technologii, także PHP. Warto też wspomnieć o RVM (http://rvm.beginrescueend.com/) do tworzenia i przełaczania się między różnymi izolowanymi środowiskami Ruby'go czy Rake, standardowa biblioteka do tworzenie tasków (coś jak ant do Javy ale dużo prostsze). A może potrzeba dobrego IDE do Ruby on Rails? Jest ich sporo, RubyMine, Netbeans, RadRails itp.

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

Teraz troszkę o wydajności.

Jak towarzystwo pewnie wie, PHP z definicji, pracuje w tak zwanym trybie CGI. Tzn. chodzi o to e każdy request tworzy od nowa i niszczy za każdym razem wszystkie obiekty i zmienne. Nie pomogą tu żadne akceleratory. Taka jest zasdnicza idea pracy interpretera PHP. Musi zniszczyć i stworzyć na nowo każdy obiekt. Stąd im aplikacja większa, tym bardziej... zwalnia (bo ma więcej obiektów do tworzenia i kasowania) W przeciwieństwie do tego, wszystkie frameworki napisane w Ruby działają (podobnie zresztą jak to jest Javie) w tzw. trybie serwletowym. Tzn. większość obiektów jest tworzona jeden, jedyny raz, i nie są nigdy usuwane z pamięci, ale tylko nasłuchują i obsługują przychodzące wywołania. Tryb serwletowy, czy też tryb serwera aplikacyjnego, polega w uproszczeniu na zastosowaniu pętli do obsługi przychodzących requestów. Teoretycznie dałoby się PHP też tak używać, ale w praktyce nik tego nie czyni z jednej prostej przyczyny - PHP ma kompletnie niedopracowany garbage collector (odśmiecacz pamięci), jest po prostu koszmarnie wolny. Ruby ma duuuuużo wydajniejszy GC. Zaś JRuby to w ogóle korzysta z cholernie wydajnego GC w JVM. Dodatkowo wykorzystuje możliwości dynamicznej kompilacji HotSpota. Tzn. wirtualna maszyna Javy jest b. inteligentna i dokonuje nieustannej analizy i optymalizacji kodu dawno po tym jak został skompilowany i uruchomiony. Np. jeśli wykryje że jakaś pętla nic nie wnosi, to ją po prostu.. usunie (m.in. dlatego Java tak bardzo nadaje się na serwer). JRuby korzysta także z wszystkich rdzeni procesora dzięki wielowątkowości systemowej.

Rails odpalony na JRuby ma jeszcze jedną zaletę - kompletna multiplatformować kodu. Można całą aplikację zapakować do jednego pliku WAR i po prostu wrzucić go do Jetty, Tomcata czy innego kontenera serwletów. Plik WAR zawiera w sobie kompletnie wszystko, z interpreterem JRuby włącznie, co pozwala na kompletnie odizolowanie od bibliotek i innych rzeczy na serwerze klienta. Nie ma też znaczenia czy system to Windows, czy Linux. Jedyne wymaganie to zainstalowane środowisko uruchomieniowe Javy. Niezłe, co? Da tych co chcieliby użyć JRuby z Rails dobrym rozwiązaniem może być też Torquebox, używa JBoss'a http://torquebox.org/

Mity o tym, że Ruby jest wolny już dawno nie są aktualne. Ruby 1.9 bez problemu bije wydajnościowo nie tylko PHP ale także dowolną wersję Pythona. A JRuby jest jeszcze szybszy! Zresztą sam Rasmus Lerdorf (twórca języka PHP) przyznał, że nie da się tego języka uczynić szybkim:

"How to make PHP fast? "Well, you can’t" was his (Rasmus Lerdorf) quick answer." http://www.sitepoint.com/blogs/2008/08/29/...ks-think-again/.

Na koniec pozwolę sobie przytoczyć za http://www.reddit.com/r/programming/commen.../php_vs_python/

PHP cannot be fixed. I've said it before and I'll say it again:
its developers don't have a clue about language design,
have no interest in whatever happened in the last 40 years
of language design, and have no concept of security.
It's a kitchen-sink-and-your-mom sort of language like VB6,
with no architecture, no philosophy, and no concept of what
constitutes good programming practices.

If I may refer to some examples, look at what PHP's creator,
Rasmus Lerdof, considers to be good code:
http://toys.lerdorf.com/archives/38-The-no...C-framework.html

The syntax is brain-dead and unfixable. It looks ugly to the eye
and unorganized. Functions don't follow any convention on order
parameters or naming. Classes are a hack that try to take from Java,
possibly the worst option available. There is no metaprogramming
to speak of.

You can't fix PHP. The only hope is to nuke it from orbit.

Zobacz też

"PHP Sucks, But It Doesn't Matter" http://www.codinghorror.com/blog/archives/001119.html

Ten post edytował hipertracker 2.09.2010, 16:55:00

[Wujashek]

Przewrotnie PHP ma najszybszy GC ;-)
Po tym jak skończy request ma 100% skuteczności w GC.
Czy tworzenie i kasowanie obiektów jest lepsze/szybsze/wydajniejsze od GC + memory leaks ? Na to pytanie nie ma już tak prostej odpowiedzi.
Zarządzanie wyciekami pamięci też do najprostszych nie należy.