Frameworki PHP vs Ruby On Rails, Skąd ten agresywny marketing w community RoR ? Opcje

[marcio]

A jednak kazdy na tym forum robi/robil cos w php wiec jednak cos w tym jest ;]

[Crozin]

Czekaj, czekaj... ja pierwszą styczność miałem z PHP jako jakby na to nie patrzeć dziecko, mieszkam na wsi... (IMG:style_emoticons/default/blink.gif) gościu ma ewidentnie racje! PHP jest dla dzieci i wieśniaków...!

[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

[Pilsener]

W Ruby można pisać dowolne aplikacje

- a znacz powiedzenie, że jak coś jest do wszystkiego to jest do niczego? Cena, rodzaj i jakość narzędzia musi być adekwatna do czynności, którą chcemy wykonać. Po co mi RoR jak 90% stron to wizytówki, PHP powstał jako interpretowany język skryptowy, przecież można aplikację webową napisać i w Turbo Pascalu jak ktoś się uprze, bo jest super i elo, ale po co? Każdy sam sobie wybiera narzędzia adekwatne do jego wiedzy i aplikacji, którą tworzy, wiadomo, że ferrari jest lepsze ale jak rodzinę chcesz zabrać na wakacje to kupisz ferrari? Tak samo da się napisać w PHP/mysql rozbudowanego ERPa czy CRMa ale po co? Używa się narzędzi adekwatnych do zadania.

[hipertracker]

- a znacz powiedzenie, że jak coś jest do wszystkiego to jest do niczego?

Akurat to, że Ruby jest językiem ogólnego zastosowania nie jest przecież jego wadą, prawda?

Po co mi RoR jak 90% stron to wizytówki,

Zostawmy zatem pehapa dla pisarzy wizytówek. (IMG:style_emoticons/default/smile.gif) Akurat mnie wizytówki nie interesują. Tym bardziej że do tego nie trzeba żadnego PHP. Są gotowe aplikacje z szablonami. Nie trzeba w ogóle nic programować.

Co do prostych serwisów to Ruby ma fajne mikroframeworki (Sinatra, Padrino, Ramaze i inne). Taka Sinatra wcale nie jest trudniejsza od PHP. A jest szybsza i ma więcej możliwości (np. możliwość odpalenia JRuby i podpięcia się do potężnych bibliotek Javy, albo do potężnej obiektowej bazy Gemstone (Maglev) można także całą taką aplikację podmontować do większego projektu, np. do Rails).

BTW, wcale nie uważam, że Ruby jest jakimś nie-wiadomo-co językiem. Są już języki potężniejsze, nowocześniejsze - np. hybrydowa (pure OOP + FP) Scala czy lispowy, funkcyjny Clojure. Ogólnie warto im się przyjrzeć bo to troche poszerza horyzonty i daje lepszą optykę na obecnie używane narzędzia. W końcu tylko ten kto poznał najpotężniejszy z języków jest w stanie porównywać inne języki. Polecam klasyczny tekst Paula Grahama "Beat the Averages" (Pokonać przeciętniaków) http://www.paulgraham.com/avg.html)

[marcio]

Akurat to, że Ruby jest językiem ogólnego zastosowania nie jest przecież jego wadą, prawda?

Do zalet jak napisal @Pilsener nie nalezy kazdy jezyk ma swoje "wrodzone" zastosowanie inne zastosowania przewaznie to ciekawostki ;] w php tez mozna kodzic na winde i co z tego?

TY ciagle z tym ze mozna sie podpiac pod Jave, python tez ma taka mozliwosc i co z tego...?
ja juz uwazam ze scala jest bardziej "naturalna" jako jezyk niz Ruby (IMG:style_emoticons/default/snitch.gif)

[hipertracker]

TY ciagle z tym ze mozna sie podpiac pod Jave, python tez ma taka mozliwosc i co z tego...?

Akurat to, że pisałem o PHP który tego nie ma. Tzn. jest Xercus ale bardzo niedojrzały i niedopracowany i właściwie trudno powiedzieć czy ktoś to jeszcze rozwija. Poza tym JRuby jest dużo szybszy i dojrzalszy od Jythona.

ja juz uwazam ze scala jest bardziej "naturalna" jako jezyk niz Ruby (IMG:style_emoticons/default/snitch.gif)

Scala jest potęzniejsza, nowocześniejsza i ciekawsza, ale jest też trudniejsza, choćby ze wzg. na wyrafinowany system typów. Ruby jest OK. Zwłaszcza że wg tego co padło na ostatniej konferencji Ruby'ego w Japonii, to Ruby 2.0 ma mieć named parameters i traits! Wydany niedawno Rails3 jest tez lepszy od i tak nienajgorszego Rails2. Rails (także dzięki generatorom kodu) prowadzi początkujących za rękę. Jest darmowa książka online do Rails3, są bardzo fajne filmiki edukacyjne itp. http://weblog.rubyonrails.org/2010/8/28/ra...t-documentation. Scala ma co prawda potężniejszego Lifta (nie jest MVC, i dobrze, bo MVC jest cienkim paradygmatem do złożonych aplikacji) ale na pewno bariera wejścia jest wyższa. Z drugiej strony, dla tych co nie mogą uwolnić się od myślenia w kategoriach MVC, jest ciekawy framework Play, który od wersji 1.1 działa w Scali i jest bardzo podobny w swej filozofii i prostocie do Rails.

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

[dr_bonzo]

Przewrotnie PHP ma najszybszy GC ;-)
Po tym jak skończy request ma 100% skuteczności w GC.

To ma każdy język - po zakonczeniu dzialania programu zwraca cala pamiec. Tyle że w innych łatwiej napisac soft dzialajacy dluzej niz jeden request, gdzie porzadny GC jest potrzebny (no chyba ze inaczej sie zarzadza pamiecia).

[Wujashek]

To ma każdy język - po zakonczeniu dzialania programu zwraca cala pamiec. Tyle że w innych łatwiej napisac soft dzialajacy dluzej niz jeden request, gdzie porzadny GC jest potrzebny (no chyba ze inaczej sie zarzadza pamiecia).

Tak, tylko chciałem podkreślić że to że w jakimś języku w ogóle jest GC i na ile jest szybsze ma wpływ na jego wydajność w zależności od kontekstu

[yevaud]

troszke gorzej jesli ruby(konkretnie 1.8) jest tylko dodatkiem na Twoim developerskim serwerze vps (np. na ruby tylko redmine), wtedy okazuje sie ze pojedyncza aplikacja na redmine wpierdala tyle ramu(1 przeladowanie strony i 150mb ramu booyah!) ile 10 jednoczesnych requestow w aplikacji o podobnym poziomie skomplikowania(dotproject, bugzilla) dla php. Maly siege zeby sprawdzic wydajnosc rubego i serwer padl mi jak szmata (IMG:style_emoticons/default/smile.gif)

edit: chwila pracy w 2 osoby na redmine i ...
7649 xxx 20 0 200m 119m 3108 S 0 23.4 0:02.46 ruby1.8
7621 xxx 20 0 200m 119m 3112 S 0 23.3 0:02.30 ruby1.8
7554 xxx 20 0 164m 88m 3576 S 0 17.2 0:02.42 ruby1.8

trzecia kolumna od prawej to procent zjadanego ramu, przez ostatnie pare minut nikt nie korzystal z redmine, serwer ma 512 ramu. Wyglada na to ze nieuzywany w tym momencie ruby uniemozliwil korzystanie z serwera.

Ten post edytował yevaud 2.09.2010, 20:48:39

[Zyx]

hipertrackerze, odpowiem Ci w sposób następujący: a co Ty za pierdoły, za przeproszeniem, wypisujesz? Masz taki sam monopol na prawdę, jak każdy tutaj na tym forum, więc trochę wyluzuj człowieku.

Ad. obiektówki -> mylisz się już na samym początku, co średnio rzutuje na Twoją rzetelność i znajomość tematu. Obiektów można było już używać w PHP3, natomiast nikt tutaj nie podważa tego, że sensowny model obiektowy pojawił się dopiero w PHP5. Czy jest kiepski? To jest Twoje zdanie - mi osobiście niewiele w nim potrzeba do szczęścia, natomiast dla odmiany wkurzała mnie obiektówka w Rubym (mixiny to wg mnie wynalazek równie szatański, jak wielokrotne dziedziczenie).

Ad. wielowątkowości -> hehehe, bardzo podoba mi się, jak ktoś chwali się tym, że Ruby ma "wielowątkowość". Prawdziwa wielowątkowość w tym języku jest dopiero od niedawna, a wcześniej do dyspozycji była jedynie implementacja "zielonych wątków", czyli emulacja takowych na poziomie maszyny wirtualnej. Kumpel napisał jakiś czas temu w Rubym program do grania w szachy i niestety komputer wykonywał obliczenia dot. swojego ruchu jedynie wtedy, gdy się myszką ruszało po ekranie. Ponadto wielowątkowość wcale nie jest potrzebna, by pisać aplikacje współbieżne. Powołujesz się na wiele mądrych i uczonych języków, zatem pewnie słyszałeś o czymś takim, jak Erlang. Tam nie ma w ogóle żadnych wątków, muteksów, semaforów itd., a mimo to język ten nadaje się moim zdaniem dużo lepiej do tworzenia aplikacji współbieżnych niż np. Ruby, Python czy Java. Pomijam już fakt, że aby mieć cokolwiek ze współbieżności, trzeba najpierw nauczyć się pisać takie aplikacje.

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

Każdy język ma błędy. Ja jestem świadomy wad PHP i nie robię z tego wielkiego halo. Czy Ty jesteś świadom wad Rubiego? Jeśli nie, odsyłam do mojego poprzedniego posta w tym temacie.

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

Fajnie, a ja w tej masie książek, screencastów i innych materiałów nie mogłem się doszukać potrzebnych mi informacji dot. np. działania Active Record i paru innych potrzebnych mi rzeczy...

Jak towarzystwo pewnie wie, PHP z definicji, pracuje w tak zwanym trybie CGI.

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. W ogóle w temacie wydajności ocknij się człowieku, 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...

Ogólne podsumowanie - tja, tylko było czekać na jakiś desant fanatyka Rubiego. Zarzuci kupą linków, poprzekręca mnóstwo rzeczy i pominie niewygodne fakty, o wadach Rubiego nie piśnie, bo i po co? Trochę o dziwo w Rubym programowałem i wiem, co tak naprawdę kryje się za tą całą propagandą i marketingową otoczką. Było trochę fajnych rzeczy, ale były też wady, niedoróbki i chybione rozwiązania i ogólnie nie znalazłem tam nic na tyle wyjątkowego, by przekreślać 9 lat doświadczenia z PHP. Co więcej, pisząc takim językiem odrzucasz mnie, drogi hipertrackerze, od środowiska programistów Rubiego jeszcze bardziej. W tym momencie nie jesteś dla mnie ani wiarygodny, ani autentyczny, bowiem dla mnie jedynym bytem doskonałym jest Bóg, a z tego, co mi wiadomo, imieniem Boga na pewno nie jest Ruby. Jeśli widzisz drzazgę w oku bliźniego, a nie potrafisz dostrzec belki w swoim, nie mamy o czym dyskutować.

[cojack]

Wiecie co, chciałbym podziękować chłopakom od r'n'r za router. I to by było tyle w tym temacie ode mnie (IMG:style_emoticons/default/winksmiley.jpg)

[thek]

Nie znam Ruby'ego, nie uczyłem się go jeszcze, więc nie odniosę, który lepszy czy gorszy gdzie i jak bo zwyczajnie bym wypaczał prawdę. Odniosę za to do przytoczonych punktów, które moim zdaniem przeinaczasz. Patrząc chłodno na całość bardziej mi to przypomina wspomnianą przez Zyx'a ewangelizację czy coś w ten deseń (IMG:style_emoticons/default/winksmiley.jpg) Pominę większość tego co już napisał Zyx. Po co się powtarzać.

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.

Model obiektowy i jego "kiepskość" to głównie subiektywne wrażenie. Nie każdy wykorzystuje wszelkie możliwości, które obiektówka daje. Uproszczenie pewnych rzeczy w niej jest więc pewny wyjściem. Wspomniane wielodziedziczenie to dla wielu osób kompletna abstrakcja. Nie tylko dla piszących w PHP. Ja z tym w C++ miałem kontakt i wiele osób tego po prostu nie łapie. Inna sprawa, że jest to wykorzystywane rzadko niezmiernie.

Brak wielowątkowości = bezsens tworzenia aplikacji desktopowych w języku? No weź mnie nie rozśmieszaj (IMG:style_emoticons/default/biggrin.gif) Do wszystkich aplikacji pchasz współbieżność? Nie wszystko da się zresztą na wersję taką przetworzyć. Część programu, czemu nie, ale są sytuacje nader często, gdy program jest zwyczajnie zbyt jednolity by można to było zrobić. A uwierz, że dla mnie pisanie programów równoległych (nie współbieżnych jedynie) to nie jest puszcza, bo w przeciwieństwie do wielu uczelni współbieżne i wieloprocesorowe aplikacje mieliśmy całkiem ładnie rozwalone także od strony praktycznej (MPICH).

Ruby w jakiejkolwiek wersji miałby zagrozić językowi C czy C++, no weź sobie jaj nie rób (IMG:style_emoticons/default/biggrin.gif) Rozumiem, że komuś może się jakiś język bardzo podobać, ale nie bądźmy ślepcami. Żaden język interpretowany nie dorówna wydajnością językom kompilowanym. Każdy poziom pomiędzy kodem a maszyną to spadek tejże. Binarka w kodzie maszynowym zawsze będzie szybsza niż kod, który musi przejść przez interpreter by mógł być zrozumiany przez maszynę. A puszczenie tego jeszcze dodatkowo przez coś bonusem - tym bardziej. Szalejesz przykładami korzystającymi z Javy. Proszę bardzo, oto ścieżka. Kod źródłowy, konwerter do formy akceptowalnej w JVM, ona dopiero na maszynę rzuca. Można by się czepiać takich pierdół. GC? Nie znam języka który mógłby powiedzieć, że ma bezbłędnie działający. Są tylko te, które mają go już na tyle przejechanego we wszystkie strony, że trudno znaleźć nań haka. Ale i one walą babole, bo człowiek nie przewidzi wszystkiego.

Multiplatformowość w Ruby nawet z tego co piszesz tutaj to tylko "zrobienie niewolnika z Javy". Jakoś patrzę w to co piszesz i widzę praktycznie zdanie o sensie: "Zabrać Ruby'emu obsługę JVM to traci na oko 80% funkcjonalności" (IMG:style_emoticons/default/winksmiley.jpg) 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 sorry, ale tak to wygląda patrząc obiektywnie na Twoje posty (IMG:style_emoticons/default/winksmiley.jpg)

Wspominasz, że to i tamto ma być w R2.0, ale przecież w PHP6.0 też mają być zmiany, więc to trochę dziwne podpierać się, czymś co ma być w przyszłej wersji. Wiesz czy będzie to działać i w jakiej formie? Ja jasnowidzem nie jestem i nie wiem czy zmiany nie przyniosą więcej szkody niż pożytku. To tak jak teraz z chwaleniem IE9.0, który rzekomo ma wszystkie przeglądarki odstawić na tor boczny i zaimplementować obsługę niemal wszystkich standardów od HTML5 poprzez CSS3 i masę innych rozwiązań. O IE 7 i 8 też pisali wiele i widać dobrze co z tego wyszło.

Krótko mówiąc, Twoje posty, zważywszy na częstotliwość słów pokroju "kiepski", "niedojrzały", "nędzny" mówią wyraźnie, że do tematu podszedłeś od razu z pozycji "nawracajcie się na Ruby'ego". Problemem jest jednak mały szczegół... Sypanie linkami nie ukryje tego, że tak naprawdę programiści Ruby'ego mają znacznie mniejsze środowisko i znacznie mniej własnych rozwiązań, bazując częściowo na innych, wydajniejszych językach. Sam nawet niechcący wspomniałeś, że Ruby jest wolniejsze od JRuby, a więc o czym my tu mówimy? Rubym samym w sobie czy jego portach na inne języki? Równie dobrze mozna by rzucać projektami około-php owymi jak wspomniane PHP-GTK i masą innych.

[yevaud]

Ruby w jakiejkolwiek wersji miałby zagrozić językowi C czy C++

chyba chodzilo o Objective-C - na platforme MacOS i IOS

swoja droga, skoro juz idziemy w takie zachwyty jesli chodzi o przenosnosc JRuby, to nie lepiej po prostu to w Javie napisac i spokoj ?

Ten post edytował yevaud 3.09.2010, 02:27:01

[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

[SHiP]

1. A ja piszę serwer gry w php i uruchamiam go jako oddzielny proces, który dziala na petli nieskończonej i po prostu nasłuchuje gniazda. I działa to całkiem przyzwoicie.

2. Na tym polegają języki funkcyjne, że nie ma w nich zmiennych. To by było kretyńskie(choć to też zależy od tego co chce się zrobić) domontować do nich zmienne(chociaż się stosuje i powstają jakieś dziwne twory pół-funkcyjne)

3. Wyobraź sobie, że piszesz aplikację. Ktoś ją bierze, przepisuje od zera, dodaje masę rzeczy, przerabia etc. A ty po 10 latach mówisz, że ten projekt nie ma racji bytu no bo w końcu Ty jesteś twórcą i wiesz na pewno.
[irony]
4. Nie znam Ruby ale czy jest w nim instrukcja goto? Bardzo, ale to bardzo mi jej brakowało i na szczęście jest juz w php 5.3 (IMG:style_emoticons/default/winksmiley.jpg) .
[/irony]

(IMG:style_emoticons/default/smile.gif)

PS: a tak w ogóle miałem ostatnio przypadek gdzie miałem do wyboru użyć goto, wywołać zewnetrzny skrypt przez curl lub przepisac ten zewnetrzny skrypt. Goto wydało się najłatwiejsze, lecz projekt był na php 5.2 ;]

[wookieb]

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.

Podaj przykład czego nie ma w php i czego nie da się "dość" łatwo uzyskać.

Skoro PHP ma ich więcej, to powiedz, czemu nawet pehapowcy stosują Capistrano?

A co to ma do rzeczy? Sugerujesz, że RUBY ma taką masę funkcjonalności, że jest mi w stanie nawet podetrzeć tyłek? To po prostu pewien program z którego możesz korzystać z poziomu PHP nie widzę związku.

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

Dno argumentacji. Spoko, bądź innowacyjny i chodź na samych paznokciach rąk, bo dlaczego masz bazować "częściowo na innych" ludziach.

HipHop raczej nie jest inną implementacją języką. To raczej pewien "dodatek" usprawniający jego działanie, ale nie będę się spierać.

Przyznam PHP potrafi wkurzyć niemiłosiernie, gdzie ostatnio doświadczyłem tego jak dowiedziałem się, że funkcja od której wymaga się działania w trybie TIP TOP jest do dupy! Chodzi oczywiście o fread i wycieki pamięci. Nie możesz przez to przeanalizować dowolnego pliku, przez co jesteś skazany na wszystkie inne rozwiązania byle nie to.
Był już tutaj poważny temat o PHP i dużych serwisach i debiliźmie w PHP. W większości przypadków da się przeżyć i znaleźć sensowne ładne rozwiązanie. Niestety Python (Ruby wcale nie uważam za konkurencję) depcze mu po piętach i sądzę, że stanie się bardziej przyszłościowym językiem.

Ten post edytował wookieb 3.09.2010, 09:07:05

[Cysiaczek]

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.

To ja mam pytanie. Czy Ty pracujesz, czy się uczysz i prowadzisz dyskusję akademicką? Pytam poważnie, bo to nie jest żaden argument przeciwko php w rozwiązaniach biznesowych (innymi słowy - klientowi to wisi).
Moduły projektuje się zazwyczaj pod kątem funkcjonalności którą realizują, nie pod kątem budowy ich kodu. Powinny posiadać interfejs, to wszystko.

Pozdrawiam

[cojack]

Cysiaczek ja się z Tobą zgadzam i nie.

Dlaczego tak? Ponieważ wiem jak to funkcjonuje, jest czas i masz to zrobić na czas.

Dlaczego nie? Ponieważ mam swoje ideały, i chce by mój kod był najlepszy.

Ale i tak czasami to pierwsze wygrywa.