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]

- 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ę.

Według jakich kryteriów? Ruby i PHP to tylko narzędzia. Każdy ma własne odczucia na ten temat i jeśli ktoś przytacza taki argument w dyskusji bez żadnego uzasadnienia, to tak naprawdę jest głupi i nie wie, o czym w ogóle pisze. Jak zmierzyć "koszmarność składni"? Znam ludzi, którzy lubią składnię w stylu Rubiego, ale mnie ona nie przekonała ani trochę. Czy to znaczy, że PHP ma lepszą składnię, a Ruby gorszą? Nie! To znaczy, że mi się wygodniej pisze w językach ze składnią w stylu C, a komuś innemu w językach ze składnią w stylu Rubiego.

A tak nawiasem mówiąc... ludzie się wkurzają na separator przestrzeni nazw w PHP 5.3, a jednocześnie nie przeszkadza im to tworzyć/polecać/używać języków, które z konwencjami wypracowanymi w mimo wszystko wciąż dominujących językach C-podobnych mają niewiele wspólnego. Zacząłem używać przestrzeni nazw w PHP i co? Backslash - znak, jak każdy inny.

Wracając do tematu frameworków, moje zdanie jest następujące:

- w PHP podoba mi się, że jest konkurencja na rynku frameworków. Niektórzy uznają to za wadę, ja twierdzę, że to jest zaleta. Po pierwsze daje to możliwość do przetestowania w praktyce wielu różnych koncepcji, a tym samym ciągłego ulepszania narzędzi w konkretnym kierunku - dobre pomysły propagują się na społeczność, złe upadają. Jako programista można dobrać framework do swoich umiejętności i zapatrywań na proces tworzenia aplikacji WWW. Co więcej, w przypadku specyficznych wymagań, jeśli się wie jak taki framework działa, da się stosunkowo łatwo opracować własne rozwiązanie, bo nie czarujmy się - większość frameworków jest zaprojektowana i zoptymalizowana pod kątem jednego typu aplikacji. A w przypadku Rubiego jaki mamy wybór? Albo nam się RoR podoba, albo mamy problem. Wbrew temu, co twierdzą fanatycy RoR, może on się nie podobać tak samo, jak może nie podobać się Zend Framework, Symfony i każdy inny framework.

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).

Niektórzy szybko znajdują, inni nie. Ja np. cztery lata szukałem i do dzisiaj nie znalazłem nic, a używałem najczęściej ZF z braku laku. Powód był prosty: wszyscy piali, jakie to MVC jest wspaniałe, opisywali ten wzorzec na wszystkie możliwe sposoby, chwaląc się, jak bardzo zwiększył ich produktywność w stosunku do "ręcznego", "nieusystematyzowanego" pisania aplikacji. Potem siadałem do kodu, robiłem projekt, patrzyłem do niego i zadawałem sobie pytanie: "OK, i gdzie tu jest jakaś jakościowa różnica w porównaniu z tym, jak pisałem wcześniej, poza tym, że szablony nazwane są widokami, komunikacja z bazą - modelem, a cała reszta - kontrolerem"? Niby była kupa helperów, gotowych komponentów, generatorów kodu, ale to, że nie muszę ich pisać od zera nie ma nic wspólnego z MVC jako takim. I tak było aż do czasu, gdy w ubiegłym roku zorientowałem się, że frameworki pod nazwą "MVC" sprzedają zupełnie inny wzorzec projektowy, który wprawdzie z MVC się wywodzi, ale ma zupełnie inne właściwości niż oryginał.

Czy ten wzorzec jest gorszy czy lepszy, zależy już od zapatrywań konkretnego programisty. Są ludzie, którym pasuje taka organizacja aplikacji, mi nie pasuje. W sumie jedyne, o co mam tak naprawdę pretensje to właśnie nazywanie tego nie-MVC MVC, podczas gdy wzorce powstały po to, by konkretna praktyka programistyczna o konkretnych właściwościach miała konkretną, jednoznaczną nazwę. To tak, jakby zabrać z obserwatora możliwość obserwowania i dalej twierdzić, że to jest obserwator. A kto wypromował takie zrównywanie modeli z ORM-em oraz widoków z szablonem? Ruby on Rails i jego słynny marketing... (IMG:style_emoticons/default/smile.gif)

Ten post edytował Zyx 11.06.2010, 09:33:57