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]

Jak wspomniałem nie znam Ruby'ego i mówię o nim to, co moi znajomi twierdzą. Stąd dla mnie w sumie "problem" z tematu jest niezbyt istotny. Nie znam? To nie staram się byś po żadnej ze stron, a całość w miarę neutralnie ubierać w słowa. Mam nadzieję, że jest to w moich postach tutaj będących, wyczuwalne.

Co do zmian to wiadomo, że one następują i muszą następować, bo takie są prawa ewolucji. Chodzi mi tu bardziej o tempo. W zasadzie zmiany następujące w PHP są dość rozstrzelone w czasie. Jest to dla mnie wada i zaleta jednocześnie. Wadą, bo rozwój jest powolny. Zaletą, bo więcej czasu na migrację i przygotowanie. Co do zmian to akurat wiele z nich jest efektem bezpośredniego przerzucania z C. Przykładowo rzuciłeś że z Java pochodziły statyczne metody i atrybuty klas. Dziwne to nieco twierdzenie, bo ja z tymi spotykałem się w C, a to na nim, a nie Javie php bazuje. Z C++ więc bym wywodził źródło owych zmian. Jako wpływ języka Java bym mechanizm interfejsów prędzej wymienił. Przestrzenie nazw to także wynalazek "od-C-owy" i chcąc, nie chcąc, wiele z przyszłych zmian będzie miało swoje źródło w tym języku. W zasadzie to zastanawiam się kiedy taki mechanizm jak klasy szablonowe wprowadzą. Zauważ że nie pytam "czy", ale "kiedy" (IMG:style_emoticons/default/smile.gif)

Z inercją w php jest do pewnego stopnia prawda. Bardziej trafne jest chyba nazwanie tego jednak efektem kuli śnieżnej. Dlaczego tak sądzę? Spójrz choćby na JavaScript... W chwili obecnej jest on bowiem używany niemal wszędzie, a jednak znających go choćby w stopniu średnim jest tak naprawdę niewielu. Ja już nawet nie mówię o czystym JS, ale nawet developerów znających porządniej jquery nie ma jakoś bardzo wielu. Tymczasem do php pcha się ludzi od groma. Nie będę jednak się wypowiadał jaki jest poziom wiedzy większości z nich, bo widać to dobrze po tematach na forum.

Co do grzęźnięcia w php większych serwisów to trudno się dziwić by ktoś na dzień dobry przewidywał, iż jego serwis zamieni się w odwiedzany przez tysiące czy miliony osób. Sam wspomniałeś o kosztach... Czy zakładając swój teraz w RoR przykładowo czy jRuby masz pewność, że za kilka miesięcy będzie on zdolny obsłużyć ruch idący w miliony użytkowników i konieczne będzie zmierzenie się z tym, czego nie przewidywałeś na początku? PHP ogranicza i developerzy dobrze o tym wiedzą, ale jednocześnie jest jednym z najtańszych jeśli chodzi o koszty rozwoju i konserwacji. W miarę szybko można znaleźć speców od niego, którzy za relatywnie niewielki koszt go poprawią i wzbogacą. W innych językach jest to o wiele mniej prawdopodobne. Im język egzotyczniejszy tym trudniej znaleźć dobrego w nim programistę, a tym samym koszta startowe, w porównaniu do php, o wiele wyższe. Ja przykładowo pracuję gdzie pracuję, bo w takim spaghetti code jakim administruję po poprzednikach, jako jedyny w firmie potrafię się połapać. Klnę nieraz przy szefie pokazując setki linii kodu zbędnego, do poprawki. Jednocześnie wiem, że właśnie "dzięki temu" mam zapewnioną pracę na całe lata. Bo tych serwisów nie da się uratować i prędzej czy później muszą zostać napisane od nowa. W jakim języku? A kto to wie (IMG:style_emoticons/default/smile.gif) Ale dopóki choć jeden staruszek stoi to mam pracę.

Co do php, javy i migracji pomiędzy nimi to skoro jest tak fajnie i różowo, to dlaczego znawców tego drugiego nie ma tylu, skoro to taki powerfull język? Odpowedź jest prosta: "Java nie jest tak przystępna jak php". Wiele osób, które miały kontakt z nią zapewne będzie twierdzić inaczej, ale sam miałem do Javy kilka podejść i po prostu nie podchodzi mi ona. A jakoś C++ nie sprawiał mi problemów szczególnych. W javie nie pomagało mi nawet czytanie ponoć tak przystępnych książek jak "Thinking in Java"

Gdy pisałem o "łatach" to miałem na myśli wprowadzanie pewnych funkcji, rozwiązań do samego języka, bez uciekania do kombinowania jak taki mechanizm zrobić mając dostępne tylko rzeczy standardowe. Coś na zasadzie: "A może da się użyć bibliotek jednego frameworka w innym?". Bo skoro nam coś udostępnia standard języka, to nie musimy już wtedy kombinować. Zauważ, że kiedyś w php nie było choćby czegoś takiego jak choćby klasy obsługujące katalogi, a ludzie sami to implementowali bo było potrzebne. Teraz mamy directoryiterator i spokój. Pomijam tutaj kwestię wydajności, bo STL w php ogólnie pod tym względem kuleje strasznie (IMG:style_emoticons/default/smile.gif)

Poza tym ciekawi mnie jedno... Jesteś zwolennikiem pięknego kodu, wolisz zapłacić za porządny. Ale pewnie chciałbyś go mieć w góra miesiąc jak każdy (pomijam, że jesteś programistą i sam piszesz, stawiam Cię w pozycji klienta) i gdy programista powie 2 lub 3 miesiące to zrezygnujesz i poszukasz kolejnego. Jako programista wiesz, że termin miesiąca jest do utrzymania tylko gdy odpuścisz pewne rzeczy, ale powiesz, że ok i polecisz po określonych częściach by kod jednak był gotowy choć jesteś świadom niedoskonałości. Firmy pokroju "Blizzarda", który mógł sobie pozwolić na pisanie Starcrafta 2 kilkanaście lat to wyjątki od reguły. Gdyby wszyscy podchodzili tak jak Ty chcesz, to aplikacje byłyby niemal bezbłędne (wciąż istniały by pewne możliwości wystąpienia problemów), ale ich tworzenie zajmowało by przynajmniej kilkakrotnie więcej czasu i pieniędzy. Koszty zjadły by niejednego zanim wydałby choć jedną aplikację. A w necie królowały by szablony do tych samych skryptów. Spójrz na "rynek" for internetowych bo tam dobrze to widać. Wszystko kręci się wokół pewnej niewielkiej skończonej liczby skryptów najpopularniejszych. To samo jest choćby w świecie blogów. Wordpress nie jest super, a patrz jak zdominował rynek.

I nie widzę problemu, że porusza się temat języka, a nie tylko jego frameworków. Bez znajomości języka i tak korzystanie z frameworka jest niemożliwe. Dlatego moim zdaniem istotniejszy niż tytuł tematu jest jego podtytuł. PHP i Ruby to języki inne, a ich porównywanie choć może i ma dla kogoś sens, jest raczej średnio przydatne.Bardziej mnie jako osobę ciekawi skąd taki marketing. Dla mnie trochę to porównywalne z iManią.