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]

A czy ja wspomniałem, że chodzi o implementację obiektówki w Ruby'm? Chodzi mi o niekompatybilności pomiędzy kolejnymi wersjami. Zawsze będą występować. A czytając w necie o Rubym developerzy w części byli źli, że wprowadzane zmiany są robione tak, że o tę kompatybilność trudno. O ile w zasadzie kod napisany w PHP4 pozwalał się odpalić na wersjach php do 5.3 (wyłączając ją), choć z ostrzeżeniami, to rzekomo podobnie odległe czasowo i rozwojowo wersje Ruby'ego już tak przyjazne nie są dla starszego kodu.

Fakt, 5.3 wprowadził wiele zmian, ale gdyby nie zmiana pewnych dyrektyw to w zasadzie dla normalnego deva w PHP nie zaszło aż tak dużo poza częścią obiektową, którą bardziej dopieszczono. Gdyby przywrócić "stare ustawienia" dyrektyw poprzez ini_set, to kod z php4 nadal rusza i działa. To co nazwałem "obudzeniem się z ręką w nocniku" w php zaszło od bardzo długiego czasu własnie po raz pierwszy dla 5.3 a z opisów netowych devów Ruby'ego zachodzi to częściej. Dlatego moim zdaniem choć wymusza coś co uważam za pozytywne, czyli ciągła naukę, to sprawia jeden problem - niemal nieustanną kontrolę kodu i jego konserwację oraz aktualizację by dopasowywać do zmian w języku. Może tyczyło to nie samego Rudy'ego ale RoR, nie kojarzę. Jeśli tylko RoR to i tak byłoby to dziwne z racji "olewnictwa" częściowego i podchodzenia do zmian w sposób "robimy zmiany od razu a potem, zobaczymy co to da i kto się będzie burzył". Trochę całość rozwoju PHP przypomina Linuxa. Są pakiety stable, które dopiero po długim czasie wchodzą, gdy już są przetrzepane na wiele sposobów. Daleko im numeracją do aktualnych, ale są pewne, kompatybilne z większością rzeczy i nie burzą się ludzie na zmiany w nich. Poza tym co tak naprawdę w składni obiektówki było najpoważniejszą zmianą, która tak uwaliła kod? Zmiana nazewnictwa metody będącej konstruktorem? (IMG:style_emoticons/default/smile.gif) Bo poza tym reszta zmian aż tak dramatycznego wpływu na kod nie zauważyłem. Ten kto pisał w 5.X zgodnie ze standardami jedyne co odczuł bardzo poważnie po przejściu na 5.3 to faktyczny wzrost wydajności.

I wcale nie twierdzę, że PHP jest najlepsze, lepsze od Ruby'ego czy tego typu zdań. Ale w odróżnieniu od choćby Twoich postów pisze nie tylko o samych zaletach, gdyż mam świadomość wad tego języka i nie kryję ich przed nikim. Przyjrzyj się swoim postom i znajdź w nich jakąś krytyczną uwagę pod kątem Ruby'ego. Przykro mi, ale ja widzę same jechanie po PHP. Gdybym tak podchodził jak Ty, to bym tutaj pod niebiosa piał o C++, który moim zdaniem mimo bycia staruchem i małej wygody pozwala na tak wiele, że niewiele języków jest w stanie stanąć oko w oko z nim. Może nawet posunąłbym się do wychwalania assemblera, bo to dopiero zajebiście wydajny język (IMG:style_emoticons/default/winksmiley.jpg) Co z tego, że programowanie w nim to męczarnia. A jaką ma bogatą dokumentację. Rozumiesz do czego piję? Choćby o odrobinie przyzwoitości w tym, że żaden język nie ma możliwości nieograniczonych i ktoś kierując się opiniami fanboyów poświęci czas na naukę, by się po jakimś czasie dowiedzieć, że język posiada ograniczenia, o których nie dowiedział od nikogo wcześniej. Mógłbym porównać postawę devów Ruby'ego i PHP-owców tak:
Ruby: "W Ruby da się w sumie zrobić absolutnie wszystko." - po czasie okazuje, że jednak nie jest to do prawda.
PHP: "PHP jest głównie do łatwiejszego tworzenia stron. Aczkolwiek da się czasem z niego coś wycisnąć" - to czasem okazuje się być co jakiś czas rzeczą której chcieliśmy, ale nie wiedzieliśmy, że da się ją w PHP zrobić, choć najczęściej trzeba przy tym się trochę nagimnastykować (IMG:style_emoticons/default/winksmiley.jpg) Lub prościej: "Ruby'owcy zbyt często uważają, że mogą wszystko. PHPowcy zbyt często uważają, że są tylko od robienia stron. Obie grupy się mylą".

A co do środowiska miałem na myśli nie środowisko uruchomieniowe czy oprogramowanie a społeczność. Źle dobrałem słowo. Teraz chyba rozumiesz mój ciąg myślowy. Mniejsza społeczność to mniejsza liczba zaimplementowanych rozwiązań/projektów przydatnych społeczności. Nie miałem na myśli tego jak moje słowa odebrał wookieb, czyli udziwnianie projektów, byle zrobić coś innowacyjnego. Nie chodziło mi bynajmniej o wymyślanie koła na nowo, bo uważam to za głupotę.

Wookieb. To co pisałem o opieraniu się na innych to taka konkluzja wynikająca z postów hipertrackera samoczynnie się nasuwająca. Jakoby Rudy nie był na tyle dobry by normalna implementacja była dobra i trzeba się posiłkować innymi językami i innymi rozwiązaniami (JVM). Rozumiem co chciałeś mi powiedzieć o możliwości przeskoczenia między Ruby i JRuby by móc wykorzystywać coś z drugiego, czego nie ma pierwszy. To fajna rzecz, a zważywszy na możliwości bibliotek Java, to otwierają się po prostu ogromne wrota. Ale to jest właśnie to o czym wspomniałem jako opieraniu się na innych. Gdyby nie możliwości Java to i Ruby by ich nie posiadał. Taka łata zanim w bazowym języku tego nie wprowadzą.

Do spaghetti code nie będę się mieszał. Każdy pisze jak mu się podoba. Mi się to nie podoba, nie pisze tak i pisać nie mam zamiaru. Inna sprawa, że takowy choć trudny do ogarnięcia, jest wydajniejszy często.