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]

Kwestia obiektowości

Obiekty w PHP3? Dodaj że równie dobrze można używać obiekty w assemblerze. W końcu OOP to tylko paradygmat... Co do PHP5, to pomijając niedoróbki w PHP 5.2, które poprawiono w wersji 5.3, model jest nadal kiepski. Po co w języku typowanym i dynamicznym interfejsy? Java pochodzi z innej, bo zarówno ścisłej jak i statycznie typowanej bajki. Interfejsy służą za sygnatury do kontraktu dla klas. W języku dynamicznie i słabo typowanym to ma niewielki sens.

Ogólnie model oparty na interfejsach i klasach abstrakcyjnych nie nadaje się do budowania modułów zgodnie z zasadą DRY (Don't Repeat Yourself). Interfejsy co prawda pozwalają na wielokrotne dziedziczenie, ale co z tego można złozyć, skoro interfejsy tylko sygnatury do metod, a nie jakiś użyteczny kod? Taki kod trzeba dopiero napisać. Np. można by jakieś wspólne części wstawić do klasy abstrakcyjnej, ale to jest też mało użyteczne, bo końcowa klasa nie może sobie dziedziczyć po wielu klasach abstrakcyjnych. Równie dobrze można kod implementować w normalnej klasie. Czy abstrakcyjna, czy nie, nie może być użyta w wielokrotnym dziedziczeniu. A te które mogą, czyli interfejsy, nie mogą mieć implementacji i klasa która jej nie dostarczy w ogóle nie może być używana. Słowem - kiepska sytuacja. Nie ma jak budować sobie modułów z których, niczym z cegiełek, można by poskładać sobie różne obiekty.

Ruby takich problemów nie ma, bo nie ma ograniczeń klas abstrakcyjnych (które nie moga być wielodziedziczone) ani interfejsów (które nie mogą posiadać żadnej implementacji), ani wielodziedziczenia (więc nie ma problemu diamentu). Ruby może dziedziczyć po jednej klasie, ale każda klasa może być domieszkowana dowolną ilością modułów (przy czym można wciągnąć metody z modułu jako metody klasowe lub instancji do jest wygodne) Same moduły nie mogą posiadać konstruktora ani nie można stworzyć instancji obiektu na ich bazie. Ale o to chodzi, o to aby można było składać większy kod z mniejszych, dobranych wedle uznania klocków.

Co do wielowątkowości, do te wcześniejsze green threads nie są aż takie złe, bo np. pozwalają na odpalenie napisanie wielowątkowego kodu nawet pod systemem, który w ogóle tego nie wspiera wielowątkowości. Co do zastosowań, to wątki może nie są zawsze potrzebne do pisania współbieżnego, ale na pewno przydają się do aplikacji korzystających z z rozbudowanego, graficznego GUI. Albo do pracy z systemami które nie potrafią forkować procesów (np. Windows).

Co do Erlanga, to raczej nie wyobrażam sobie napisania aplikacji desktopowej w Erlangu. (IMG:style_emoticons/default/biggrin.gif) To język stworzony do specyficznych zastosowań. Jest też językiem pure FP (czysto funkcyjnym). Nie ma nie tylko semaforów i wpółdzielenia zasobów ale też nie posiada w ogóle zmiennych (są tylko jednorazowe przypisania) ani pętli (pętle realizowane są za pomocą rekurencji). Nie mówię, że to źle czy dobrze, ale na pewno bardzo inaczej się tak pisze. Także pisanie jakiegoś niebanalnego kodu w pure FP wcale nie jest łatwe, bo najczęściej nie da się tak całkiem obyć bez I/O i innych elementów, które z definicji nie mogą być traktowane jako pure (a monady nie są wcale takie proste do zrozumienia dla każdego). Trochę bardziej pragmatycznym podejściem charakteryzuje się Clojure. Jes językiem funkcyjnym i posiada niemutowalne struktury, ale umożliwia dostęp do obszarów współdzielonych za pomocą ST (pamięci transakcyjnej). Właściwie Clojure wymusza (na poziomie składni) objęcia transakcją każdej operacji tego typu.

Ja jestem świadomy wad PHP i nie robię z tego wielkiego halo

No to też wiesz, że PHP nadaje się może do pisania wizytówek, ale do kodu bardziej złożonego, już tak sobie. Byle fatal error rozłoży ci każdą aplikacje PHP na łopatki. I to się nie zmieniło do dziś.

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.

A ty w ogóle potrafisz czytać ze zrozumieniem? Nie pisałem o tym, że za każdym requestem, kod źródłowy skryptu PHP jest ładowany do pamięci, ale o tym, że za każdym razem PHP musi tworzyć od nowa wszystkie obiekty. I tego nie zmieni żaden mod_php, fast_cgi czy akcelerator. A inaczej nikt nie pisze w PHP bo ma beznadziejny GC.

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

Chcesz powiedzieć, że twórca PHP sam nie wie czym jest jego dzieło i teraz bredzi na jego temat? (IMG:style_emoticons/default/laugh.gif)

Fakt, że przepisano część kodu obiektowego, ale tylko się cieszyć. Poza tym zmiany nie są ogromne, bo inaczej by się ludzie pochlastali na kompatybilności wstecz. Developerzy RoR podchodzą tutaj "na wariata trochę" z tego co wiem. Trzeba uważać na wersje bo można się obudzić z ręką w nocniku po update'cie.

Co ty za idiotyzmy wypisujesz? Ruby miał swój model obiektowy od samego początku. Nie odróżniasz języka (Ruby) od aplikacji (Rails)? Nie wiem o co ci chodzi. PHP przecież nie jest wcale w pełni kompatybilny nawet ww ramach tej samej wersji PHP5. Pamiętam jak sam pisałem maila do developerów MacPorts aby jakoś inaczej oznaczali pakiety do PHP 5.2 i 5.3 bo są znaczące rożnice w działaniu modelu obiektowego i przypadkowa aktualizacja do PHP 5.3 może uwalić niejeden kod.

Co do zarzutów o fanatyzm i przekręcanie "mnóstwa rzeczy". Jak widzę taki "kociokwik" to nie wiem czy to jest jeszcze śmieszne, czy tylko żałosne. Za trudno coś napisałem, czy co? Co wg ciebie zostało przekręcone??

Dlaczego też chcesz abym to ja się skupiał wadach Ruby'ego? Ja tylko skomentowałem parę idiotyzmów wypisywanych pod adresem tego języka. Np. te odnośnie hostingu. Nigdzie też nie twierdzę, że Ruby to najlepszy język pod niebiem. Choć jest całkiem niezły, owszem. Na pewno dużo lepszy od PHP. (IMG:style_emoticons/default/tongue.gif)

Wszędzie tylko JRuby to, tamto, JVM i GC JAVA super wypas. Tak jakby Ruby był jakimś ubogim kuzynem języka JAVA i wciąż się musi nią podpierać.

No niezupełnie. Przecież JRuby to ta sama semantyka języka co Ruby. Inna jest tylko implementacja. Ruby 1.8 MRI i Ruby 1.9.2 YARV napisano w C, ale już JRuby w Javie, IronRuby wńMacpo C#, MacRuby w Objective-C, MagLev w Smalltalku, Rubinius, hehe, w Ruby (i dziwiłbyś się jak potrafi być szybki, ma JIT i wirtualną maszynę, używa tylko loadera w C++). Ale to wszystko to nadal ta sama składnia Rubiego ale różne implementacje.

Ruby on Rails 3.0 pójdzie przecież zarówno pod Ruby jak i JRuby. Funkcjonalność masz tą samą. Inne tylko możliwości. W JRuby podoba mi się, że nie ma ryzyka, że czegoś zabraknie. Ale dopóki nie dojdziesz do tego momentu, nie potrzebujesz siegać po JRuby. Ja miałem raz taką sytuację w pracy, że klient zażyczył sobie używania Oracle. To były czasy przed Rails 2.0 i nie mogłem wtedy znaleźć dobrego sterownika. Przełączyliśmy się na JRuby i problem zniknął dzięki doskonałym sterownikom JDBC. Teraz rozumiesz? Chodzi o możliwości. W PHP jak nie znajdziesz jakiejś biblioteki, to jesteś zablokowany. W Rails, przełączam się na JRuby i znajdę wszystko. Tak nie masz w PHP.

programiści Ruby'ego mają znacznie mniejsze środowisko i znacznie mniej własnych rozwiązań, bazując częściowo na innych, wydajniejszych językach

Np. czego wg ciebie brakuje? Bo nie rozumiem o co ci chodzi co do tych rozwiązań. Skoro PHP ma ich więcej, to powiedz, czemu nawet pehapowcy stosują Capistrano? Podpowiem; bo nie ma nic tak dobrego dostępnego w PHP? (IMG:style_emoticons/default/smile.gif)
Poza tym (opcjonalne) bazowanie na takiej platformie JVM nie jest wcale niczym złym. Dobrym przykładem jest Scala, która w ogóle nie przedefiniowała wielu funkcji do operacji na stringach - po prostu korzysta z gotowych, javowych.

Ruby jest wolniejsze od JRuby, a więc o czym my tu mówimy.

Wolniejszy jest stary Ruby 1.8. Nowy Ruby 1.9.2 ma mniej więcej taką samą szybkość (w zależności od benchmarku, czasem jest szybszy, czasem wolniejszy, ale trzeba dodać że JRuby jeszcze nie jest w pełni optymalizowany wydajnościowo). No i trzeba dodać, że Ruby 1.9.2 jest tak szybszy zarówno od PHP jak i Pythona. BTW, najszybszym językiem dynamicznym jest, z tego co się orientuję Clojure - wielu benchmarkach ma wydajność taką jak Java. Klasy Javy są klasami Clojure i odwrotnie. JRuby ma mieć to samo już wkrótce.

Rubym samym w sobie czy jego portach na inne języki? Równie dobrze mozna by rzucać projektami około-php owymi jak spomniane PHP-GTK i masą innych.

PHP-GTK to biblioteka graficzna, a nie jakaś inna implementacja PHP. JRuby zaś to po prostu Ruby, tylko zaimplementowany w Javie. Inną implementacją PHP jest co najwyżej Xercus lub HipHop (choć ten ostatni to już jest raczej fork innego języka, bo nie jest już w pełni kompatybilny z PHP na poziomie składni).

Ten post edytował hipertracker 3.09.2010, 04:46:04

[mike]

Ogólnie model oparty na interfejsach i klasach abstrakcyjnych nie nadaje się do budowania modułów zgodnie z zasadą DRY (Don't Repeat Yourself). Interfejsy co prawda pozwalają na wielokrotne dziedziczenie, ale co z tego można złozyć, skoro interfejsy tylko sygnatury do metod, a nie jakiś użyteczny kod? Taki kod trzeba dopiero napisać. Np. można by jakieś wspólne części wstawić do klasy abstrakcyjnej, ale to jest też mało użyteczne, bo końcowa klasa nie może sobie dziedziczyć po wielu klasach abstrakcyjnych. Równie dobrze można kod implementować w normalnej klasie. Czy abstrakcyjna, czy nie, nie może być użyta w wielokrotnym dziedziczeniu. A te które mogą, czyli interfejsy, nie mogą mieć implementacji i klasa która jej nie dostarczy w ogóle nie może być używana. Słowem - kiepska sytuacja. Nie ma jak budować sobie modułów z których, niczym z cegiełek, można by poskładać sobie różne obiekty.

Bzdura. Oczywiście, że dziedziczenie pomaga w zachowaniu zasady DRY. Nie jest to oczywiście panaceum, ze wystarczy ładna hierarchia klas i mamy DRY za darmo.
Istotne jest to, żeby wiedzieć kiedy użyć dziedziczenia a kiedy agregacji. No ale to chyba oczywiste, że w programowaniu stosuje się zestawy wzorców, narzędzi i trików a nie jeden jedyny.
Jednym słowem: Czy dziedziczenie gwarantuje DRY? Nie. Czy pomaga w zachowaniu tej zasady? Oczywiście.

[hipertracker]

Bzdura. Oczywiście, że dziedziczenie pomaga w zachowaniu zasady DRY. Nie jest to oczywiście panaceum, ze wystarczy ładna hierarchia klas i mamy DRY za darmo.
Istotne jest to, żeby wiedzieć kiedy użyć dziedziczenia a kiedy agregacji. No ale to chyba oczywiste, że w programowaniu stosuje się zestawy wzorców, narzędzi i trików a nie jeden jedyny.
Jednym słowem: Czy dziedziczenie gwarantuje DRY? Nie. Czy pomaga w zachowaniu tej zasady? Oczywiście.

Widzę żeś w ogóle nie zrozumiał mojego poprzedniego postu. Przeczytaj parę razy, może w końcu dotrze. W PHP nie możesz sobie złożyć klasy z modułów bo ich po prostu nie ma. Możesz o najwyżeć dziedziczyć po jednej, i tylko jednej klasie i nie masz jej jak podzielić na funkcjonalne moduły.

Np w Scali możesz sobie stworzyć oddzielne traitsy odpowiedzialne za wybrane funkcjonalności. Np. masz traitsa Bird implementującego interfejsy i częściową funkcjonalność dla ptaka, masz traitsa Swimming, implementująca funkcjonalności zwiazane z pływaniem i masz klasę Flying, dla zwierząt, co latają. Masz podzielone funkcjonalności. Nie możesz stworzyć obiektu na bazie żadnego z tych traitsów, ale możesz stworzyć coś, co posiada ktoreś z tych cech.

class Pigeon extends Bird with Swimming with Flying {}

class Frigate extends Bird with Flying {}

Można to też zrobić dynamiczniej

val pigeon = new Pigeon with Swimming with Flying
pigeon.fly()

W Ruby można uzyskać coś podobnego.

module Bird
end

module Flying
end

module Swimming
end

class Pigeon
include Bird
include Swinning
include Flying
end

class Frigate
include Bird
include Flying
end

Teraz spróbuj to zrobić w PHP...

class Bird {};
class Flying {};
class Swimming {};

class Pigeon extends Bird {}; i dupa..., musisz uciec się do kompozycji i injection of control.

Ten post edytował hipertracker 4.09.2010, 02:22:35