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.

Większość z tych argumentów to jakieś totalne bzdury i tyle.

Jestem pewien, że można wymyślić dużo lepsze argumenty za i przeciw konkretnemu językowi czy frameworkowi. Poza tym argument w stylu "RoR daje duże możliwości w zakresie ORM, testów jednostkowych, MVC" świadczą o całkowitej niekompetencji - jeśli myli się framework z językiem programowania - w zasadzie to trudno to komentować.

Cały buzz wokół Ruby czy Pythona ma jednak bardzo pozytywny wpływ na wynagrodzenia - są zdecydowanie wyższe. Również jest takie podejście - programista Ruby czy Pythona na pewno jest lepszym programistą niż PHP. Tu oczywiście wszystko zależy od punktu siedzenia itd - jeśli ktoś porównuje kogoś dopiero po studiach inżynierskich (czy licencjacie) programującego w php z kimś kto od kilku lat siedzi w pythonie, to wiadomo kto będzie lepszym programistom

Argumenty odnośnie serwerów są całkowicie nietrafione. A co do innych punktów to moja opinia jest następująca: jest to jakiś psycho-pseudo-programistyczny bełkot dziecka, które jest kiepskim programistą i nie ma pojęcia o tym, jak rozstrzyga się takie spory.

Kiedyś rozmawiałem ze znajomym o tym co on robi dorywczo - serwisy na bazie drupala, instalacja tematów, pluginów takie tam - nic nie przerabia, bo ma problem z odróżnieniem zmiennej od funkcji .

W każdym bądź razie temat zszedł na frameworki - no i wtedy dowiedziałem się takich rzeczy o Rubym i RoR Same superlatywy Człowiek, który swoją znajomość programowania ograniczył do html i css był w stanie wymienić wiele zalet Ryby'ego i mówił o tym z dużą pasją - zupełniej jak zwolennicy Apple o produktach tej firmy.

Jaki z tego morał?

Ruby i RoR _mają_ _świetny_ marketing - tu goście od PHP i PHP'owych frameworków mogliby się naprawdę dużo nauczyć.

Jest naprawdę świetny.
99% odpowiedzi na pytanie "dlaczego przepisano wykop.pl z RoR na PHP" to - "Bo jest za mało programistów RoR i prace szły zbyt wolno".
Ale zaraz zaraz !
Przecież RoRowcy się chwalą, że ich społeczność dorównuje - i uwaga cytuję forum RoR "a nawet przewyższa ilością społeczność PHP"
(jak odnajdę ten cytat, to dodam linka).
Po za tym, "RoR jest tak doskonały, że podczas roboczogodziny programista RoR wykona kilka razy tyle backlogów (wg slangu SCRUM) co kilku programistów PHP".

Powiem szczerze, że wykop.pl to ne jedyny przypadek.
Nie mogę podawać konkretnych webaplikacji, ponieważ znajomi od których mam takie informacje (przeważnie Symfoniarze lub Zend'iarze, że się tak miło wyrażę)
powiesiliby mnie i rozstrzelali za plotkartswo, jeśli trafiliby na ten wątek.
Panoć kiedyś na jakimś blogu ktoś wymyślił nowe polskie przysłowie:
"Napisz na swojej stronie, że programujesz w Rails i PHP, a zaraz znajdą się klienci, którzy będą prosić o przepisanie czegoś z RoR na PHP".




Czy chodzi o ten punkt:
"Programista RoR MUSI być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.".

A co do sporów to podobno na jakimś spotkaniu rozstrzygnięte było przez rękoczyny



Dzięĸi za wszystkie opinie.
Mam nadzieję, że temat szybko nie umrze.

No wiesz - marketing, to marketing - zachwalanie danego rozwiązania. Niekoniecznie musi być najlepsze.

Co do przepisywania serwisów, to nie jest to żadna nowość. Wiele serwisów jest przepisywanych na inną platformę (kiedyś w Stanach były modne migracje do ASP, .NET - bo dział marketingu wymyślił ), tworzonych od nowa etc. - pouczający artykuł http://www.webnodes.com/a-total-rewrite-co...ng-but-worth-it

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.



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

Dzięki Zyx za opinię.
Zawsze napiszesz coś konkretnego.
W całym temacie boli to, że trudno znaleźć konkretne za i przeciw, jeśli
jedna ze stron twierdzi, że PHP jest be, bo tak i koniec.
Tak jak to pisał Tom Negrino, autor podręczników do Ajaxa:

" (...) przykład jednej z najbardziej irytujących cech przemysłu komputerowego: tryumf marketingu nad treścią.".

Rozmawiałem z człowiekiem, co piąte przez dziesiąte pokumał się w Railsach.
Mówię mu - opowiedz jak to działa, jak to wrzucić na serwer itp.
Czy szablony muszą być w języku Ruby ?
Czy ORM "to zestaw obowiązkowy" ?
A on do mnie, że mam mózg wyprany przez PHP, że to są pytania nie na miejscu.

Mam wrażenie, że z 5 lat temu dyskutowało się o różnych rozwiązaniach, wyciągało wnioski, podkreślało zalety i wady jakichś rozwiązań.
Za 5 lat będą nas uważać za grupę, która jak dresiarze obrzuca się wyzwiskami, bo ten jeździ BMW, a ten VW.


PS Dzięki Zyx za wielokrotne i uargumentowane wypowiedzi na tym forum dot. Linuksa.
Właściwie to przez twoje argumenty i argumenty Thek'a od około roku jestem zadowolonym użytkownikiem pinginwa

@Zyx - Są trzy warstwy.
Model (uproszczony do mixu ORM i Row Data Gateway)
Widok - elastyczny system prezentacji danych w dowolnym formacie (wraz z możliwością kodowania za pomocą komponentów jeśli bierzemy pod uwagę użycie do stron www)
Kontroler - kontroluje wyniki operacji na modelach lub na Modelu Dziedziny (jeśli ktoś się na taki skusi) i wybiera widoki lub forwarduje żądanie do innego kontrolera.

Jedyna różnica pomiędzy MVC klasycznym, a tym webowym jest taka, że w klasycznej aplikacji możesz zaprezentować widok i jednocześnie wykonywać żądania, a w webowej masz pasywny widok, który nie ma fizycznej możliwości interakcji z systemem. Można to symulować AJAXEM lub wspomnianym wcześniej programowaniem komponentowym. Nadal nie jest to jednak to samo, co w przypadku podtrzymujących proces języków. Żądanie to inicjalizacja programu. To nadal jednak jest MVC chć schemat pracy wygląda najczęściej tak:


CMV CMV CV CMV.. wysłanie dokumentu

CMV - Akcja listPosts, model Post, widok show.php
CMV - Komponent (akcja) lastVisits, Model Visitors, widok lastVisits.php (wtłoczony do show.php)
CV - Komponent myFooter, widok myFooter.php (wtłoczony do show.php, pomijam oficjalnie Model, bo np jest to tekst wklepany na sztywn)

Na mój rozum, to tu jest używany trójwarstwowy system, który posiada wszystkie elementy MVC, wiec jest to MVC. W makro i mikro skali.

Pozdrawiam

@Wiktor P.: nie tylko, ogólnie wszystkie uwagi do serwera są nietrafione. Ustawienie PHP na serwerze nie jest takie trywialne, jak to wszyscy stwierdzają, a z kolei instalator Ruby (z tego, co zaobserwowałem) nie jest jakoś przesadnie skomplikowany

http://www.goldenline.pl/forum/891204/php-...ch-programistow poczytaj bedziesz mial argumenty za i przeciw sa tam niestety fanboy'e rubiego,python'a jak i php'a ale da sie wyciagnac konstruktywne odpowiedzi.

Nic wiecej pisac nie bede bo nie widze takiej potrzeby:]

Cysiaczek ->

1. Jeśli model upraszczasz do ORM-a, to wypaczasz jedną z podstawowych koncepcji MVC, która polega na tym, że od strony zewnętrznej mamy się nie zajmować w ogóle tym, skąd model te wszystkie dane bierze i gdzie je umieszcza. A spróbuj w pierwszym lepszym frameworku zrobić model korzystający z plików, zamiast z bazy danych i nie pochlastać się przy tym.

2. Pasywny widok nie jest jedyną zmianą w warstwie V. W MVC widok powinien samodzielnie pobierać dane z modelu, w domyśle poprzez jakiś "dobrze zdefiniowany interfejs". W prawie wszystkich frameworkach tymczasem masz zrównanie widok = szablon oraz jawne pośrednictwo kontrolera w przekazywaniu danych z modelu do widoku. Może się wydawać, że to banał, ale wystarczy choć raz zrobić to tak, jak sugeruje MVC, by przekonać się, że te dwie głupoty całkowicie zmieniają sposób programowania oraz właściwości wzorca. Paradoksy, które się pojawiają:
- Kontroler jest zależny od sposobu prezentacji, ponieważ jej logika z braku laku musi wylądować właśnie w kontrolerze (logika = np. system stronicowania, obsługa sortowalnych kolumn na liście wyników i ogólnie wszystko, co wymaga jakiegoś choćby banalnego menedżera sprawującego nad tym pieczę).
- Szablony są dostosowane najczęściej tylko do generowania HTML-a. PDF-a już sobie widokiem nie wygenerujesz, tymczasem zgodnie ze wzorcem MVC powinieneś być to w stanie prosto w tej warstwie zrobić.

Samo nazwanie trzech warstw modelem, widokiem i kontrolerem nie sprawia jeszcze, że uzyskujemy MVC. Ważne jest też, jak te elementy są połączone. Tak samo nazwanie czegoś obserwatorem i obserwowanym nie daje nam jeszcze wzorca Obserwator . A tak w ogóle jak wyrzucisz bezpośrednie pobieranie danych przez widok z modelu, to taki wzorzec ma swoją fachową nazwę: Model-View-Presenter.

Przy czym ponownie zaznaczam: każdy programuje, jak mu wygodnie. Jednak jeśli powołuje się na wzorce projektowe, to niech powołuje się zgodnie z zasadami przyświecającymi wzorcom.

@Zyx im dłużej o tym piszesz tym bardziej jestem skłonny dać się porwać. Brakuje mi tylko jednego: przykładu. Nie ukrywam, że byłoby miło gdybyś zaprezentował model, widok i kontroler. Mam kilka wątpliwości, a taki przykład mógłby pomóc.

Rozumiem to co piszesz, ale jeśli masz chwilę, pokaż jakiś kod w PHP, demonstrujący to co opisujesz w akcji, bo ja tego, póki co, nie widzę jako możliwego do zrealizowania, a przynajmniej nie jako funkcjonalnego szkieletu dla php.

Pozdrawiam

Na szybko taką realizację MVC można zobaczyć w Joomli - niestety jest to jedyna dobra rzecz, jaką można powiedzieć o jej kodzie. Eksperymentalnie wykorzystałem tę koncepcję w jednym projekcie, więc jest to jak najbardziej realizowalne (i co ważniejsze, przy dobrym zaprojektowaniu interfejsów efekt wychodzi naprawdę fajny) - niestety ponieważ był to projekt komercyjny, a sama implementacja też była robiona na szybko i na zasadzie "wchodzenia w nieznane", nie mogę jej ot tak udostępnić z przyczyn niezależnych.

Natomiast od jakiegoś czasu pracuję już nad stosowną samodzielną implementacją i jak tylko osiągnie ona sensowny poziom, mam zamiar udostępnić ją na Githubie. Niestety trochę to trwa, ponieważ wymaga to w zasadzie stworzenia frameworka całkowicie od zera, i to w dodatku bez żadnego punktu odniesienia, przez co trzeba się zastanowić nad każdą głupotą, by to miało ręce i nogi. W międzyczasie postaram się w najbliższych dniach opublikować jakiś wpis z praktycznymi przykładami u mnie na blogu, żeby można było na podstawie kawałków kodu zobaczyć, z czym to się je.

Co do marketingu RORa - powstał jako nowa technologia/FW - ludzie ktorzy go uzywali zobaczyli ze jest dobry i aby moc w nim robic projekty ROR (czyt znalezc klientow ktorzy zgodza sie na projekt w ROR) musial byc znany - rozpoznawaly, miec wystarczajaca ilosc ludzi ktorzy by mogli przejac po kims projekt w ROR (patrz Wykop). I od tego zaczela sie ewangelizacja, promowanie, wspieranie projektow około RORowych i Ruby'owych. To chyba normalne. Jak ADobe stworzył FLEXa to pewnie tez go promowal, reklamowal, wychwalal.



Co do administracji - PHP jest bardzo popularne, hosting jest trywialny - wpoldzielone konto, dostep przez FTP - jesli ci to wystarcza ok. Ale aktualizacja duzego projektu przez FTP to koszmar, brak SCM. Brak mozliwosci odpalania dodatkowych procesow (NoSQL bazy, cache, etc.) - jestes zdany na konfiguracje serwera od uslugodawcy. W PHP latwo postawic mala aplikacje szybko. Dlatego tez umiejetnosci administratorskie nie sa tu prawie wymagane.

ROR praktycznie wymaga osobnego serwera (jak nie wiecej), odpalania dodatkowych procesow, zarzadzania nimi == wymaga wiecej administracji. Ale, jesli bedziesz wdrazal appa w PHP na dedyku to tez musisz go skonfigurowac, nim zarzadzac, odpalac dodatkowe aplikacje etc, wiec IMO bez roznicy - wszystko zalezy od sposobu deploya i wielkosci aplikacji.



Straszne, slyszalem ze wyszla wersja ROR 3 (powstawala chyba ponad rok, jako merge ROR 2 + Merba) - jakos im ta klotnia niezbyt przeszkodzila.




Nikt nie kaze ci aktualizowac RORa do najnowszej wersji. I "jakiejkolwiek" to naduzycie.
Takie symfony tez sie zmienia i musisz poprawiac zmienione ficzery.
Jesli chcesz utrzymywac dluzej aplikacje to raczej chcesz uzywac aktualnych wersji FW'a - jest poprawiany, optymalizowany itp - jak masz testy dla systemu - jest do znacznie prostsze.

az sprawdziłem czy mi słoma z butów nie wystaje... kurcze i jedno źdźbło znalazłem, mam nadzieje że sąsiada

Ale tępa opinia.
Przypomnijcie mi: Facebook jest w PHP?

Ale jedzie na HipHopie więc w sumie ciężko powiedzieć co to jest

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

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

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

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

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


Zostawmy zatem pehapa dla pisarzy wizytówek. 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)

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

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.



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.

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.

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

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

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.

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.



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.



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

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

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ń 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 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 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" 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

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.

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 ?

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



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



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.



Chcesz powiedzieć, że twórca PHP sam nie wie czym jest jego dzieło i teraz bredzi na jego temat?



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.



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.


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



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.



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

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 .
[/irony]



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 ;]

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

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.


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.

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

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.

OK, masz konkretny problem, ale nie wiem czego konkretnie tam używasz, tzn. jak to wersja Ruby, Redmine i Rails? Być może to wina tej aplikacji readmine, nie używałem. Choć jeśli używasz starego Ruby 1.8.6, do tego starszej wersji Rails (sprzed 2.3.5) i na dodatek całość chodzi na paru procesach starych mongreli to może ci pożreć trochę więcej pamięci niż być chciał.

To co bym ci doradził, to po pierwsze pozbyć się tych 3 procesów. Użyj serwera asynchronicznego: Thin, Unicorn, Rainbows lub Zbatery. Najlepiej tego ostatniego (http://zbatery.bogomip.org/) bo jest jest co prawda oparty na asynchronicznych Rainbows i Unicorn ale używa pojedyńczego procesu z wątkami, co znacznie oszczędzi ci RAM. Wg tego co piszą na stronie Rainbows (http://rainbows.rubyforge.org/) "If you’re on a small system, or write extremely tight and reliable code and don’t want multiple worker processes, check out Zbatery, too. Zbatery can use all the crazy network concurrency options of Rainbows! in a single worker process."

Po drugie, jeśli potrzebujesz Ruby 1.8 to koniecznie użyj najnowszej wersji REE (Ruby Enterprise), który używa Ruby 1.8.7 i ma zdecydowanie ulepszone zarządzanie pamięcią. No chyba że masz możliwość odpalenia Ruby 1.9.2, ale musiałbyś sprawdzić czy ci ten Readmine z tym pójdzie.\
Warto wiedzieć, że dodatkowe optymalizacje REE są dostępne są po zarejestrowaniu klucza. o instalacji gemu możesz zobaczyć że jest skrypt passenger-make-enterprisey). Nie wiem jak teraz, ale wcześniej rozdawali kody za "co łaska". Wystarczyło dać dowolną dotację, choćby i 1 dolara i można było mieć ten kod. na pewno warto z tego skorzystać jeśli już używać REE.

Po trzecie, aktualizacja Railsów. Wersje starsze były znacznie bardziej zasobożerne.

Po czwarte, masz tu do czynienia z nadmiarowymi 2 procesami, starym Ruby, cholera wie jak starym Rails i Readmine. Czyli do pamięci ładujesz nie interpreter Ruby'ego ale cały framework + cała aplikacja. Można zrobić eksperyment i odpalić czystą aplikację rackową i porównać z tym co pożera Readmine. Bo być może, nadmierne zużycie pamięci też pochodzi z tego, w jaki sposób ktoś napisał Readmine.

Alternatywnie możesz też spróbować zobaczyć jak się zachow REE i Passengere (ale nie pod Apache lecz Nginxem). W końcu, skoro to VPS to nie powinno być problemem aby to postawić. Passengera można ustawić aby nie odpalał za dużo procesów. Zaletą Pasengera jest też to że nieużywane procesy są automatycznie usuwane po czasie z pamięci.

Jest jeszcze jedna alternartywa o której się dopiero co dowiedziałem. Pojawił się nowy Mongrel2. Najciekawsze jednak to, że jest może obsługiwać cała masę języków. Jak podają na http://mongrel2.org/home: Ruby, Python, C++, PHP, Haskell, Common Lisp, Perl, .NET, Clojure, i Lua. Nie sprawdzałem jeszcze jak to się zachowuje, ale myślę że warto się przyjrzeć




Nie, bo w JRuby pisze się szybciej, prościej, krócej, po prostu wygodniej. Nie, jeśli chcesz użyć Rails, Padrino czy Sinatry. Większość frameworków Javy jest ciężka i nadmiernie skomplikowana. Choć to się też zmienia, np. we frameworku Play. Poza tym, JRuby kontenera serwletów Javy, więc aż tak oszczędne pamięciowo to nie jest. Choć przy pewnym poziomie obciążenia, Rails odpalony w JRuby zajmuje już mniej pamięci niż stado mongreli, bo JRuby korzysta z wydajniejszej obsługi pamięci w JVM.

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 kolega trzyma poziom będąc zwolennikiem antywzorca projektowego spaghetti code. Aby wywołać zewnętrzny skrypt nie trzeba żadnej komendy GOTO.

Oj koleżko czepiasz się wszystkiego więc i ja Ci powytykam.
1. Spaghetti code nie jest żadnym (anty)wzorcem programowania;
2. ~SHiP nie napisał, że musiał użyć GOTO żeby wywołać zewnętrzny skrypt. Czytaj chłopie ze zrozumieniem. Stał przed problemem i problem można była rozwiązać na trzy sposoby. To napisał. No ale jedno trzeba oddać. Chcąc użyć GOTO wybrał najgorsze rozwiązanie.

Ok, powiedzmy, że mnie przekonałeś ale ja jestem totalnie zielony z Rubego. Podałeś z 20 różnych nazw i się w tym pogubiłem. Co ja potrzebuje żeby napisać dużą aplikację w Ruby(np. ogromny sklep internetowy).
W php mam: PostgreSQL, php, memcache lub shmp do tego apache. Całość na moim frameworku lub zendzie

W ruby?: Postrgre pewnie jest, memcache pewnie też, framework to zapewne RoR, ale jak z resztą? Jaki muszę mieć serwer i jak to jest z tym JRuby? Co jeszcze trzeba doinstalowac?

EDIT: goto to zapewne najgorsze rozwiązanie ale i jednocześnie najszybsze(10 sekund roboty). Ostatecznie nie użyłem goto bo nie mieliśmy php 5.3 na serwerze. Tu można się zastanawiać. Czy użycie goto to straszna rzecz w przypadku gdy mamy do czynienia z kodem wyglądającym jakby był pisany za czasów php3(ogrom zmiennych globalnych i latanie z funkcji do funkcji bez sensu). Była jeszcze czwarta opcja: przestrzenie nazw ale wiedzieliśmy, że to dopiero w 5.3 jest. Goto myśleliśmy, że siedzi w php od początku, a tu taka niespodzianka.

Tak wyglądał przykład:

OFFTOP
Zabrzmiało to strasznie ignorancko. I jeżeli kolega odpowie sposobem w pełni zadowalającym mam nadzieję, że to Cię zamknie.
Nie zdziw się, że przy dużych sklepach internetowych nie wykorzysta się Postgres-a, bowiem są inne WYDAJNIEJSZE rozwiązania od niego.
Memcache - zdziwisz się jaka jest masa też INNYCH "cache-ów" operujących na pamięci nie tylko pod RUBY-ego. BTW google -> memcache ruby
Framework - a znasz cała listę? http://accidentaltechnologist.com/ruby/10-...web-frameworks/ a to tylko 10
Serwer - kyrie eleison

A ja nie znam Ruby'ego wcale ale Twoje pytanie wygląda na kompletnie dziwne. Jakbyś miał pretensje mówiąc, że Lamborghini Murcielago to słabe auto bo trzeba się nauczyć jeździć i uważać z gazem.

To, że czegoś nie ma w Out of the Box to żaden minus. Z takim jak Twoje podejście nie napisał byś kompletnie niczego w Javie, bo tam liczy się integracja. Pytasz, co trzeba doinstalować? W przypadku dużych projektów pewnie setki rzeczy. Tyle tylko, że to nic złego.
Jeśli liczysz w życiu na odpalenie gotowca i wesołe programowanie to proszę bardzo, tkwij w PHP na swoim poziomie

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.

Ale po co takie nerwy? Ciekawy jestem. Kolega postawił jasne argumenty i chciałbym wiedzieć jak wyglądają kwestie budowania serwera. Czy jest prosto czy nie. A nóż widelec zostanę "rubownikiem".


OFFTOP:
Postgre to przykład. Wszystko zależy od sytuacji. Równie dobrze można napisać, że sqllite działa szybciej od postgre. Domyślam sie ze jest i Oracle do ruby bo to raczej norma teraz.

To, że nie ma wielokrotnego dziedziczenia w PHP da się przeboleć.
Rozumiem jego zalety ale też rozumiem jakie konsekwencje może wywołać.
Poza tym "kompozycja" nie jest wcale jakimś "złą", brzydką metodą.