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

[Wiktor P.]

Witam.

Będąc na etapie programisty znającego php trochę lepiej niż średnio rozgarnięty szympans,
poszukuję frameworka, który nauczy mnie dobrych praktyk programistycznych i projektowych (projektowych tzn. odnośnie
całego projektu, włączając w to projekt w UML, coś jak rysunek techniczny dla architekta, tu projekt dla aplikacji).
W grę wchodzi Symfony i Zend - bo znam ludzi, którzy mnie pokierują, doradzą etc.
Wiem, że znajome mi osoby od ww FM zrobią wszystko w swoich narzędziach, bardzo je chwalą, nie chcieli by ich zmieniać.
I tu pojawia się na horyzoncie jeszcze jeden konkurent Symfony i Zend - mianowicie Ruby on Rails.

Przedstawię argumenty pehapowców i rorowców i prosiłbym o rozsądne rozstrzygnięcie, czy argumenty obydwu grup
są cokolwiek warte (pokrywają się z prawdą).
W nawiasach przedstawię własną opinię dot. danego punktu.
Chciałbym podkreślić, że argumenty za lub przeciw dot. wyboru któregoś z frameworków
mają na celu odpowiedzieć na pytania:
- czy nauka danego frameworka wniesie coś dla programisty odnośnie programowania ogólnie (nie zależnie od języka),
- czy nauka danego frameworka przyda się w praktyce (szybkie wdrożenie, hosting).

Proszę również o swoje argumenty odnośnie Symfony, Zend i Ruby on Rails.

1. Argumenty pehapowców za PHP:
- PHP jest prosty do wdrożenia na serwer produkcyjny.
- Miliony użytkowników, wielka społeczność.
- W PHP można zrobić wszytsko - od strony www dla cioci co ma stoisko na bazarze (proceduralnie)
do najbardziej zaawansowanych projektów jakie można znaleźć w sieci.
- Jest ogromna ilość podręczników do PHP po polsku.
- PHP jest kompatybilne wstecz (w rozsądnych granicach).
- Nowoczesne frameworki do PHP oferują wszystko to co konkurencja (Python Django, RoR, Merb i inne).
- Programista nie musi być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.

1a. Argumenty pehapowców przeciw Ruby on Rails.
- Brak polskich książek (te obydwie na rynku są do wersji przestarzałych).
- Hostowanie to dodatkowa praca, dodatkowy czas, dodatkowe problemy.
- Hostowanie to koszmar i drożyzna.
- Bez sensu używać do małych projektów (czyli przez conajmniej 50% programistów).
- Kłótnie w samym sercu założycieli frameworka (odszedł twórca serwera mongrel).
- Zdarza się przepiswyanie gotowych już projektów w RoR na PHP np.
a. http://www.wykop.pl
b. http://www.oreillynet.com/ruby/blog/2007/0...ack_to_p_1.html
- Jeśli coś już pójdzie nie tak, to będziesz szukał powodu conajmniej tygodniami w źródłach RoR.
- Brak kompatybilności jakiejkolwiek wstecz. Pojawienie się nowej wersji RoR grozi powrotem do korzeni (może nie trzeba uczyć się od nowa wyświetlania "Hello World", ale trzeba
douczyć się ogromnej ilości nowych rzeczy i zapomnieć o tych starych rozwiązaniach).
- Bardzo agresywny marketing, rodem z telezakupów "Mango", tu zacytuję dla przykładu:
książka "Rails Space" M. Hartl, A.Prochazka - Helion 2008,
str. 31
"Witryna Rails Space (wykonana w RoR) będzie miała wiele elementów kojarzonych z popularnymi sieciami społecznościowymi jak Facebook".
- ZARAZ ZARAZ - Facebook jest w PHP !
str. 26
" (...)stwierdził, że gdy porządnie przyjrzał się PHP, uznał, że jest do niczego(...)".
- brak argumentów.
- Programista RoR MUSI być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.


2. Argumenty zwolenników Ruby on Rails:
- PHP to nakładka na język C.
- RoR jest w Ruby, a ten jest całkowicie obiektowy (moja uwaga: rozumiem, że programista RoR na co dzień wykorzystuje tą obiektowość
i tworzy sobie nowe klasy na bazie znaków "+", "-", "=", ";" itp. ).
- Sam język Ruby daje o wiele większe możliwości niż sam PHP ( moja uwaga: a mimo to, nikt nie używa samego rubiego bez frameworka do webaplikacji ).
- PHP ma koszmarną składnię.
- RoR daje duże możliwości w zakresie ORM, testów jednostkowych, MVC (moja uwaga: podobną funkcjonalność oferował już pięc lat temu CodeIgniter napisany w PHP4).
- Kto raz spróbował RoR nigdy nie wróci do PHP (moja uwaga: to zdanie można znaleźć wszędzie co ma związek z RoR, ale brak argumentacji).
- PHP to bajzel, PHP to zło.
- PHP jest dla dzieci i wieśniaków.
- Rorowiec zarabia więcej niż pehapowiec ( moja uwaga: jeśli zna tak dobrze RoR, że może porównac się z kimś kto np. 5 lat programuje w Zend
i na dodatek w swoim województwie uda mu się znaleźć pracę przy RoR to może rzeczywiście ).

Dziekuję za opnie, wskazówki, swoje uwagi i wszelkie komentarze.

[jan3sobi3ski]

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 (IMG:style_emoticons/default/smile.gif)

[Zbłąkany]

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.

[jan3sobi3ski]

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 (IMG:style_emoticons/default/winksmiley.jpg) .

W każdym bądź razie temat zszedł na frameworki - no i wtedy dowiedziałem się takich rzeczy o Rubym i RoR (IMG:style_emoticons/default/smile.gif) Same superlatywy (IMG:style_emoticons/default/smile.gif) 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ć.

[Wiktor P.]

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

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.

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 (IMG:style_emoticons/default/smile.gif)



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

Ten post edytował Wiktor P. 10.06.2010, 18:43:45

[jan3sobi3ski]

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

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ł (IMG:style_emoticons/default/winksmiley.jpg) ), tworzonych od nowa etc. - pouczający artykuł http://www.webnodes.com/a-total-rewrite-co...ng-but-worth-it

[Zyx]

- Sam język Ruby daje o wiele większe możliwości niż sam PHP ( moja uwaga: a mimo to, nikt nie używa samego rubiego bez frameworka do webaplikacji ).
- PHP ma koszmarną składnię.

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

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

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

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

Będąc na etapie programisty znającego php trochę lepiej niż średnio rozgarnięty szympans, poszukuję frameworka, który nauczy mnie dobrych praktyk programistycznych i projektowych (projektowych tzn. odnośnie całego projektu, włączając w to projekt w UML, coś jak rysunek techniczny dla architekta, tu projekt dla aplikacji).

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

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

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

[Wiktor P.]

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 (IMG:style_emoticons/default/smile.gif)

[Cysiaczek]

@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

[Zbłąkany]

@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 (IMG:style_emoticons/default/smile.gif)

[marcio]

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

[Zyx]

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 (IMG:style_emoticons/default/smile.gif) . 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.

Ten post edytował Zyx 11.06.2010, 19:59:53

[destroyerr]

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

[Cysiaczek]

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

[Zyx]

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.

[dr_bonzo]

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.

[Dla PHP] Programista nie musi być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.
[ROR] Hostowanie to dodatkowa praca, dodatkowy czas, dodatkowe problemy.
[ROR] Hostowanie to koszmar i drożyzna.

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.

- Kłótnie w samym sercu założycieli frameworka (odszedł twórca serwera mongrel).

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

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

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.

[cojack]

- PHP jest dla dzieci i wieśniaków.

(IMG:style_emoticons/default/haha.gif)

[kwiateusz]

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 (IMG:style_emoticons/default/sad.gif)

[mike]

- PHP jest dla dzieci i wieśniaków.

Ale tępa opinia.
Przypomnijcie mi: Facebook jest w PHP? (IMG:style_emoticons/default/tongue.gif)

[Crozin]

Ale jedzie na HipHopie więc w sumie ciężko powiedzieć co to jest (IMG:style_emoticons/default/tongue.gif)

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

[hipertracker]

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.

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ć

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

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.

Ten post edytował hipertracker 3.09.2010, 10:00:14

[mike]

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

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

[hipertracker]

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

Widzę że kolega trzyma poziom będąc zwolennikiem antywzorca projektowego spaghetti code. (IMG:style_emoticons/default/laugh.gif) Aby wywołać zewnętrzny skrypt nie trzeba żadnej komendy GOTO.

[mike]

Widzę że kolega trzyma poziom będąc zwolennikiem antywzorca projektowego spaghetti code. (IMG:style_emoticons/default/laugh.gif) 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.

Ten post edytował mike 3.09.2010, 10:23:50

[SHiP]

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:

Kod

goto controller;
skrypt:
// tutaj mielenie przez skrypt
goto koniec;


controller:

//Controller zendowski z akcją a w niej

goto skrypt:
koniec:

Ten post edytował SHiP 3.09.2010, 10:32:22

[wookieb]

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?

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

Ten post edytował wookieb 3.09.2010, 10:30:52

[mike]

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?

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 (IMG:style_emoticons/default/tongue.gif)

[hipertracker]

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

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

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

class Pigeon extends Bird with Swimming with Flying {}

class Frigate extends Bird with Flying {}

Można to też zrobić dynamiczniej

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

W Ruby można uzyskać coś podobnego.

module Bird
end

module Flying
end

module Swimming
end

class Pigeon
include Bird
include Swinning
include Flying
end

class Frigate
include Bird
include Flying
end

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

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

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

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

[SHiP]

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.

Ten post edytował SHiP 3.09.2010, 10:45:56

[wookieb]

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

[hipertracker]

Oj koleżko czepiasz się wszystkiego więc i ja Ci powytykam.
1. Spaghetti code nie jest żadnym (anty)wzorcem programowania;

No, skoro Ty to mówisz... to pozostaje nam chyba tylko się zamknąć i przyjąć to jako święty dogmat. Weź napisz do autorów tych wszystkich książek o wzorcach projektowych i do wikipedystów że błądzą w ciemnościach, bo ty nie uważasz spaghetti code za błędny wzorzec projektowy. Także poinformuj autorów ponad 300 tysięcy stron webowych że nie wiedzą, iż spaghetti code to przecież wspaniały wzorzec projektowy. (IMG:style_emoticons/default/laugh.gif)

Ten post edytował hipertracker 3.09.2010, 10:45:28

[marcio]

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

Ja uwazam akurat ze wielodziedziczenie wprowadza tylko w blad poczatkujacych w php czesto spotkac:

[PHP] pobierz, plaintext 
class ksiegagosci extends mysqli { }
[PHP] pobierz, plaintext 

Pomijajac fakt jakby to wygladalo gdyby w php bylo wielodziedziczenie tak sa interfejsy i jesli ktos nie wie na czym to polega nie widzimy takich klockow.
Ucze sie python'a podoba mi sie ale zaluje ze nie ma tam interfejsow, klasy abstr. niby sa ale....ahhh ten duck typing

[hipertracker]

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?

Potrzebujesz zainstalowanej lokalnie Javy. Nic więcej. Ale już framework JRuby on Rails wymaga jakiegokolwiek kontenera serwletów, bo, Jetty, Tomcat, Glassfish3 czy JBoss. Tu masz kompleksowe rozwiązanie oparte na JBossie o którym wcześniej wspominałem: Torquebox. Z innych frameworków możesz spróbować Sinatry czy Padrino. Są prostsze od Rails. I też działają z JRuby.

Ten post edytował hipertracker 3.09.2010, 10:52:25

[SHiP]

@hipertracker: ale wzorzec spagetti(o ile można to wzorcem nazwać) sam w sobie nie jest czymś złym. Ja popieram zdanie mike. Po prostu jest niewygodny w użyciu. Były sytuacje, że się pisało za ich pomocą aplikacje(np. commodore64 i basic w nim wbudowany), bo sprzęt na wiele nie pozwalał. Do tej pory masz skoki w asemblerze i nikt z tego powodu nie płacze. Równie dobrze można napisać, że cały paradygmat obiektowy jest badziewny, bo bardzo komplikuje sytuację programisty. Funkcyjny już mniej. Ale wszystko zależy od zastosowań, przyzwyczajeń oraz maszyny na której odpalamy daną aplikację.

Nie lubię się przypominać, ale napisze mi ktoś w końcu to jedno, krótkie zdanie na temat tego co potrzebuję aby zacząć pisanie sklepu w Ruby? Co do frameworku podałem RoR bo tylko jego znam i w tym temacie był podawany. Po prostu jestem zielony w tym temacie.


EDIT: dzięki za info (IMG:style_emoticons/default/winksmiley.jpg)


Ten post edytował SHiP 3.09.2010, 10:52:32

[mike]

No, skoro Ty to mówisz... to pozostaje nam chyba tylko się zamknąć i przyjąć to jako święty dogmat. Weź napisz do autorów tych wszystkich książek o wzorcach projektowych i do wikipedystów że błądzą w ciemnościach, bo ty nie uważasz spaghetti code za błędny wzorzec projektowy. Także poinformuj autorów ponad 300 tysięcy stron webowych że nie wiedzą, iż spaghetti code to przecież wspaniały wzorzec projektowy. (IMG:style_emoticons/default/laugh.gif)

Nie napisałem, że Spaghetti jest OK. Napisałem, ze nie jest to wzorzec.
Żeby coś było antywzorcem, powinno być najpierw wzorcem. A wzorce jak zapewne (nie?)wiesz są to sprawdzone sposoby na realizację typowych zadań.
Część z takich wzorców (na przykład Singleton) określa się mianem wzorców bo pomimo, że ich realizacje jest typowa to nie zawsze dobra.

A nie powiesz mi, że w jakiejkolwiek książce, którą czytałeś (też czytałem mnóstwo rzeczy z GoF, Wójkiem Bobem i Fowlerem na czele) Spaghetti jest określane wzorcem. Tylko tego się czepiłem.
Spaghetti code to określenie złego stylu pisania i śmietnika w kodzie. To określenie zbioru złych praktyk a nie wzorzec.


P.S.
I tak ? propos nie jestem programistą PHP, więc nie nawiązuj w ewentualnych odpowiedziach to PHP.

Edited:
P.S.2
~SHiP tak naprawdę to Ty mnie nie popierasz. Bo widzisz ja twierdzę jednoznacznie, że spaghetti code to coś czego należy unikać za wszelką cenę.

Ten post edytował mike 3.09.2010, 10:56:09

[hipertracker]

Nie lubię się przypominać, ale napisze mi ktoś w końcu to jedno, krótkie zdanie na temat tego co potrzebuję aby zacząć pisanie sklepu w Ruby? Co do frameworku podałem RoR bo tylko jego znam i w tym temacie był podawany. Po prostu jestem zielony w tym temacie.

Prościej, wskocz na kanał IRC #rubyonrails.pl. Nie wiem jaki system używasz (Windows czy Linux, Mac OS-X) Zainstaluj wpierw Ruby potem Rails, następnie zajrzyj do http://weblog.rubyonrails.org/2010/8/28/ra...t-documentation (tam jest kupa pożytecznych linków). Co do sklepów, nie używałem gotowych rozwiązań do sklepów, ale znalazłem coś takiego jak Spree (http://spreecommerce.com).

Fajne, interaktywne intro do Rubiego, w sam raz na 15 min, znajdziesz tu: http://tryruby.org/. Polska strona domowa http://www.ruby-lang.org/pl. Odnośnie Rails http://rubyonrails.pl i oczywiście kanał IRC #ruby.pl i #rubyonrails.pl

Spaghetti code to określenie złego stylu pisania i śmietnika w kodzie. To określenie zbioru złych praktyk a nie wzorzec.

No własnie owe złe praktyki są określane potocznie jako antipatterns (i tak to figuruje na wikipedii). Nie ma co się spierać o słowa, bo zgadzamy się, że to jest zła praktyka. I tylko o to mi chodziło.

Ucze sie python'a podoba mi sie ale zaluje ze nie ma tam interfejsow, klasy abstr. niby sa ale....ahhh ten duck typing

Języki dynamiczne nie potrzebują interfejsów. http://dirtsimple.org/2004/12/python-inter...e-not-java.html

Duck typing, to oddzielna bajka. To czasem użyteczna technika. Nawet statycznie typowana Scala posiada duck typing.

[Radarek]

Nie lubię się przypominać, ale napisze mi ktoś w końcu to jedno, krótkie zdanie na temat tego co potrzebuję aby zacząć pisanie sklepu w Ruby? Co do frameworku podałem RoR bo tylko jego znam i w tym temacie był podawany. Po prostu jestem zielony w tym temacie.

Potrzebujesz:
- ruby w wersji klasycznej (tzw. MRI, Matz Ruby Interpreter) bądź REE (Ruby Enterprise Edition - proszę się nie sugerować nazwą, to taki żart autorów) - REE jest forkiem MRI, który poprawia dosyć zużycie pamięci i co za tym idzie wydajność
- serwera aplikacyjnego, np. apache bądź nginx (polecam ten 2, ale jak ktoś ma już gotowy setup z apache to też jest ok)
- serwera aplikacyjnego, np. mongrel, thin, unicorn (oba serwery przy okazji są też serwerami www więc można je używać do developerki bez stawiania apache bądź nginx)
- frameworka, tutaj raczej RoR bądź Sinatra (ten pierwszy większy, z wieloma ficzerami, ten drugi bardziej lekki)
- baza jaką sobie życzysz (postgresql, mysql to najczęściej używane, ostatnio modne są też bazy nosql jak mongodb, couchdb, cassandra)
- memcache - bez problemu (o shmp nie słyszałem, a google nic mi nie zwracają chyba że chodzi Ci o shm to też podejrzewam nie ma problemu)

linki:
MRI http://www.ruby-lang.org/pl/downloads/ (najłatwiej jednak zainstalować z paczek, np. apt-get)
REE http://www.rubyenterpriseedition.com/


W przeciwieństwie do hipertrackera nie polecam od razu jrubiego. Dlaczego? Dlatego iż uważam, że takie rozwiązania jak jruby/maglev/ironruby (inne implementacje rubiego) są fajne, ale jak się ma konkretne potrzeby (np. chcę łatwej inteegracji z instniejącym systemem w javie to użyję prawd. jrubiego).

[SHiP]

~SHiP tak naprawdę to Ty mnie nie popierasz. Bo widzisz ja twierdzę jednoznacznie, że spaghetti code to coś czego należy unikać za wszelką cenę.

Ja też jestem za tym, aby unikać goto tego za wszelką cenę. W niektórych językach po prostu się nie da(jak np. w asemblerze). Jesli chodzi o moj przyklad w php, to tak pisałem użyłbym przestrzeni nazw, gdyby było na serwerze php 5.3. Gdybym mial jednak wybierać - przerabiać miesiąc skrypt lub w 10 sekund zastosować haczyk, który podałem wyżej to nie zastanawiałbym się.

EDIT: dzięki Radarek. Trochę tego jest ale w wolnej chwili spróbuję sobie odpalić wszystko

Chodziło mi o shmop(shared memory operations) więć w skrócie o shm czyli pamięć współdzieloną (IMG:style_emoticons/default/winksmiley.jpg)

Ten post edytował SHiP 3.09.2010, 12:22:22

[hipertracker]

Potrzebujesz:
- ruby w wersji klasycznej (tzw. MRI, Matz Ruby Interpreter) bądź REE (Ruby Enterprise Edition - proszę się nie sugerować nazwą, to taki żart autorów) - REE jest forkiem MRI, który poprawia dosyć zużycie pamięci i co za tym idzie wydajność
- serwera aplikacyjnego, np. apache bądź nginx (polecam ten 2, ale jak ktoś ma już gotowy setup z apache to też jest ok)
- serwera aplikacyjnego, np. mongrel, thin, unicorn (oba serwery przy okazji są też serwerami www więc można je używać do developerki bez stawiania apache bądź nginx)
- frameworka, tutaj raczej RoR bądź Sinatra (ten pierwszy większy, z wieloma ficzerami, ten drugi bardziej lekki)
- baza jaką sobie życzysz (postgresql, mysql to najczęściej używane, ostatnio modne są też bazy nosql jak mongodb, couchdb, cassandra)
- memcache - bez problemu (o shmp nie słyszałem, a google nic mi nie zwracają chyba że chodzi Ci o shm to też podejrzewam nie ma problemu)

linki:
MRI http://www.ruby-lang.org/pl/downloads/ (najłatwiej jednak zainstalować z paczek, np. apt-get)
REE http://www.rubyenterpriseedition.com/


W przeciwieństwie do hipertrackera nie polecam od razu jrubiego. Dlaczego? Dlatego iż uważam, że takie rozwiązania jak jruby/maglev/ironruby (inne implementacje rubiego) są fajne, ale jak się ma konkretne potrzeby (np. chcę łatwej inteegracji z instniejącym systemem w javie to użyję prawd. jrubiego).

Też myślę, że nie ma co od razu rzucać się na JRuby. Po JRuby sięgają ci co są świadomi potrzeb i potrzebują czegoś więcej niż to, co dostarcza (bogata) biblioteka standardowa Ruby'ego.

EDIT: Nie bawiłbym się w Ruby MRI, bo to jest Ruby 1.8. REE to też 1.8. Lepiej od razu zainstalować Ruby 1.9.2. Jest znacznie szybszy i ma większe możliwości (choćby porządny Unicode)

Jednak co do instalacji Ruby'ego to zdecydowanie zalecam używanie RVM. Jeśli nie Rails, to zamiast Sinatry lepiej użyć Padrino, jest oparty na Sinatrze czyli też lekki, ale ma więcej możliwości. Dzięki RVM możesz sobie zainstalować równocześnie izolowane środowiska REE, Ruby 1.9.2 czy JRuby. I w prosty sposób się między nimi przełączać. RVM rządzi.

Radarek nie wspomniał o najprostszej z opcji. Ja bym się nie bawił w żadnego mongrela ani thina, przynajmniej nie na produkcji. Najłatwiej zainstalować Passengera. Działać będzie podobnie prosto jak mod_php. Nie trzeba nic odpalać w tle, pilnować aby się podnosiło podczas startu serwera itp.

Ewentualnie na początek możesz skorzystać z darmowej chmury serwerów Heroku. Jest trywialna w obsłudze i mają tam darmową opcja do niewielkich aplikacji. Na początek może być. Wtedy w ogóle nie musisz stawiać żadnego serwera.

Oczywiście do pracy nad kodem, nie trzeba żadych serwerów, bo Rails ma wbudowany prosty serwer HTTP. Ewentualnie można sobie zainstalować Unicorn'a i odpalać pod nim, bo jest szybszy od tego wbudowanego. Nie trzeba jednak żadnych Apache'y ani Nginx'ów do tego aby pracować i testować sobie kod.

Ten post edytował hipertracker 4.09.2010, 02:14:28

[thek]

A czy ja wspomniałem, że chodzi o implementację obiektówki w Ruby'm? Chodzi mi o niekompatybilności pomiędzy kolejnymi wersjami. Zawsze będą występować. A czytając w necie o Rubym developerzy w części byli źli, że wprowadzane zmiany są robione tak, że o tę kompatybilność trudno. O ile w zasadzie kod napisany w PHP4 pozwalał się odpalić na wersjach php do 5.3 (wyłączając ją), choć z ostrzeżeniami, to rzekomo podobnie odległe czasowo i rozwojowo wersje Ruby'ego już tak przyjazne nie są dla starszego kodu.

Fakt, 5.3 wprowadził wiele zmian, ale gdyby nie zmiana pewnych dyrektyw to w zasadzie dla normalnego deva w PHP nie zaszło aż tak dużo poza częścią obiektową, którą bardziej dopieszczono. Gdyby przywrócić "stare ustawienia" dyrektyw poprzez ini_set, to kod z php4 nadal rusza i działa. To co nazwałem "obudzeniem się z ręką w nocniku" w php zaszło od bardzo długiego czasu własnie po raz pierwszy dla 5.3 a z opisów netowych devów Ruby'ego zachodzi to częściej. Dlatego moim zdaniem choć wymusza coś co uważam za pozytywne, czyli ciągła naukę, to sprawia jeden problem - niemal nieustanną kontrolę kodu i jego konserwację oraz aktualizację by dopasowywać do zmian w języku. Może tyczyło to nie samego Rudy'ego ale RoR, nie kojarzę. Jeśli tylko RoR to i tak byłoby to dziwne z racji "olewnictwa" częściowego i podchodzenia do zmian w sposób "robimy zmiany od razu a potem, zobaczymy co to da i kto się będzie burzył". Trochę całość rozwoju PHP przypomina Linuxa. Są pakiety stable, które dopiero po długim czasie wchodzą, gdy już są przetrzepane na wiele sposobów. Daleko im numeracją do aktualnych, ale są pewne, kompatybilne z większością rzeczy i nie burzą się ludzie na zmiany w nich. Poza tym co tak naprawdę w składni obiektówki było najpoważniejszą zmianą, która tak uwaliła kod? Zmiana nazewnictwa metody będącej konstruktorem? (IMG:style_emoticons/default/smile.gif) Bo poza tym reszta zmian aż tak dramatycznego wpływu na kod nie zauważyłem. Ten kto pisał w 5.X zgodnie ze standardami jedyne co odczuł bardzo poważnie po przejściu na 5.3 to faktyczny wzrost wydajności.

I wcale nie twierdzę, że PHP jest najlepsze, lepsze od Ruby'ego czy tego typu zdań. Ale w odróżnieniu od choćby Twoich postów pisze nie tylko o samych zaletach, gdyż mam świadomość wad tego języka i nie kryję ich przed nikim. Przyjrzyj się swoim postom i znajdź w nich jakąś krytyczną uwagę pod kątem Ruby'ego. Przykro mi, ale ja widzę same jechanie po PHP. Gdybym tak podchodził jak Ty, to bym tutaj pod niebiosa piał o C++, który moim zdaniem mimo bycia staruchem i małej wygody pozwala na tak wiele, że niewiele języków jest w stanie stanąć oko w oko z nim. Może nawet posunąłbym się do wychwalania assemblera, bo to dopiero zajebiście wydajny język (IMG:style_emoticons/default/winksmiley.jpg) Co z tego, że programowanie w nim to męczarnia. A jaką ma bogatą dokumentację. Rozumiesz do czego piję? Choćby o odrobinie przyzwoitości w tym, że żaden język nie ma możliwości nieograniczonych i ktoś kierując się opiniami fanboyów poświęci czas na naukę, by się po jakimś czasie dowiedzieć, że język posiada ograniczenia, o których nie dowiedział od nikogo wcześniej. Mógłbym porównać postawę devów Ruby'ego i PHP-owców tak:
Ruby: "W Ruby da się w sumie zrobić absolutnie wszystko." - po czasie okazuje, że jednak nie jest to do prawda.
PHP: "PHP jest głównie do łatwiejszego tworzenia stron. Aczkolwiek da się czasem z niego coś wycisnąć" - to czasem okazuje się być co jakiś czas rzeczą której chcieliśmy, ale nie wiedzieliśmy, że da się ją w PHP zrobić, choć najczęściej trzeba przy tym się trochę nagimnastykować (IMG:style_emoticons/default/winksmiley.jpg) Lub prościej: "Ruby'owcy zbyt często uważają, że mogą wszystko. PHPowcy zbyt często uważają, że są tylko od robienia stron. Obie grupy się mylą".

A co do środowiska miałem na myśli nie środowisko uruchomieniowe czy oprogramowanie a społeczność. Źle dobrałem słowo. Teraz chyba rozumiesz mój ciąg myślowy. Mniejsza społeczność to mniejsza liczba zaimplementowanych rozwiązań/projektów przydatnych społeczności. Nie miałem na myśli tego jak moje słowa odebrał wookieb, czyli udziwnianie projektów, byle zrobić coś innowacyjnego. Nie chodziło mi bynajmniej o wymyślanie koła na nowo, bo uważam to za głupotę.

Wookieb. To co pisałem o opieraniu się na innych to taka konkluzja wynikająca z postów hipertrackera samoczynnie się nasuwająca. Jakoby Rudy nie był na tyle dobry by normalna implementacja była dobra i trzeba się posiłkować innymi językami i innymi rozwiązaniami (JVM). Rozumiem co chciałeś mi powiedzieć o możliwości przeskoczenia między Ruby i JRuby by móc wykorzystywać coś z drugiego, czego nie ma pierwszy. To fajna rzecz, a zważywszy na możliwości bibliotek Java, to otwierają się po prostu ogromne wrota. Ale to jest właśnie to o czym wspomniałem jako opieraniu się na innych. Gdyby nie możliwości Java to i Ruby by ich nie posiadał. Taka łata zanim w bazowym języku tego nie wprowadzą.

Do spaghetti code nie będę się mieszał. Każdy pisze jak mu się podoba. Mi się to nie podoba, nie pisze tak i pisać nie mam zamiaru. Inna sprawa, że takowy choć trudny do ogarnięcia, jest wydajniejszy często.

[hipertracker]

@thek: pewnie ci chodzi o to zamieszanie między wersją 1.8.6 a 1.8.7 do której wrzucono pewne rzeczy z 1.9? Bo generalnie to nie jest jakiś wielki problem. Najwięcej narzekania zawsze było na zewnętrzne, nie będące oficjalnie częscią frameworka, pluginy. No, ale co się dziwić, nad tym nie masz kontroli. Rails3 wprowadza trochę porządku, bo jest bardziej modularny i każdy element frameworka jest sam w sobie pluginem, który można wymienić. Zdefiniowane jednak czytelniejsze zasady tego jak to robić, podzielono API na publiczne i prywatne (publiczne nie może się zmieniać) Dodano Bundlera który lepiej potrafi zarządzać różnymi zależnościami między bibliotekami Rubiego (tzw. gemami)

Co do zmian w kolejnych wersjach języka które zrywają z wsteczna kompatybilnością, to w PHP jest tego od groma. Nie liczac zmian od wersji 4.x do 5.0, także w ramach wersji 5 wprowadzono wiele, niekompatybilnych wstecznie zmian, ze zmianami w modelu obiektowym włącznie. To nie są żadne tajemnice, bo wszystko jest podane na stronie PHP.

I tak między PHP 5.0 a 5.1 wywalono z modelu obiektowego abstrakcyjne metody prywatne, zmieniono zasady dziedziczenia, dodano fata errora :lol:przy próbie redefinicji stałej w klasie itp. Między PHP 5.1 5.2 wprowadzono dalsze zmiany w modelu obiektowym łamiąc wsteczną kompatybilność z wersjami wcześniejszymi - tym razem wyleciały abstrakcyjne funkcje statyczne, zmieniono działanie magicznej metody __toString. Między PHP 5.2 a 5.3 dokonano dalszych zmian w metodzie __toString (tym razem nie może już przyjmować parametrów), zmieniono zakres metod magicznych __get, __set, __isset, __unset i __call na publiczny orz sposób działania metody __call. Wprowadzono przestrzenie nazw, którym zaraz po opublicznieniu... zmieniono składnię. Itp. itd.

Pominąłem to, że PHP5 (zresztą kopiuje to z Javy, której - jak wiadomo - model obiektowy jest daleki od doskonałości) posiada nieobiektowe konstrukcje w postaci statycznych metod i atrybutów klas. PHP powtarza także niepotrzebny podział na obiekty i typy prymitywne. Scala jest dowodem na to, że to wcale nie trzeba userowi wystawiać takiego miksu obiektów i prymitywów aby uzyskać optymalizację wydajnościową (bo to jest główny argument zwolenników tego podziału)

To, że w Ruby da się "absolutnie wszystko" zrobić to oczywiście przesada. Wiadomo, że współcześnie i tak operuje się wieloma językami. Swego czasu Microsoft się chwalił że wspiera wiele języków w ramach swojej platformy .NET. Java ma to samo, ale na większą skalę, bo jest ponad 240 języków zgodnych z platformą JVM. Na dodatek Java jest prawdziwie multiplatformowa, czego nie da się powiedzieć o .NET.

Popularność pehapa to bardziej efekt siły inercji. Dziś, mało kto rozumny, wybierze PHP jako podstawową technologię dla budowy jakiegoś bardziej złożonego projektu. Duże projekty takie jak np. Facebook to efekt wcześniejszego ugrzęźnięcia w PHP. Zbudowano duży kod i teraz trudno z tego prosto wyjść. Wątpię czy dziś by wybrali PHP gdyby zaczynali od podstaw. Widać też, że Facebooka ten cały pehap trochę ogranicza, skoro się rzucili aby napisać własną jego implementację, chata mają w Erlangu itp.

Szkoda, że tak małe wsparcie ma Quercus, javowa implementacja PHP. Mogłaby dużo zmienić. Otworzyłaby drzwi nie tylko do bibliotek Javy ale także ułatwiłaby ewentualną migrację na inny język. No, ale być może Zend się boi w to inwestować, bo ludzie by pouciekali od PHP mając taką furtkę. (IMG:style_emoticons/default/laugh.gif)

Samo korzystanie z bogatych bibliotek Javy, to nie żadna łata w oczekiwaniu na to, że coś zostanie do danego języka. Tu w ogóle nie chodzi o to aby coś dołączać do języka. Po co? I kto za to zapłaci? Przecież w platformę Javy wpompowano ciężkie miliony dolarów. To normalne że się korzysta z gotowych rozwiązań zamiast wymyślać na nowo koło. Znowu powołam się na Scalę, bo jest dobrym przykładem. W wielu miejscach "bezczelnie" korzysta z bibliotek Javy zmiast wymyślać jakieś swoje dziwne API do obsługi różnych rzeczy. I dobrze. Bo język ma służyć człowiekowi a nie być celem samym w sobie. Skoro już są pewne rozwiązania, są dobre, to po co je na nowo wymyślać?

Jeśli zaś chodzi o spaghetti code, upieranie się przy złych wzorcach programowania i robienie z kodu sieczki, bo niby jest tak "wydajniej", to jest wynik powszechnej niekompetencji i nieuctwa panującego w kręgach pehapowców. Załatać byle co, byle jak, a potem to choćby i potop. Dlatego, jakbym miał zatrudniać programistę, i znałby on tylko PHP, to bym się 10x zastanowił, czy z niego cokolwiek jeszcze będzie. Bo koszty kodu to nie tylko koszty związane z jego stworzeniem, ale także, a może - przede wszystkim, koszta związane z jego dalszym utrzymaniem i rozwojem. Wolę zapłacić za porządny kod i potem mieć niskie koszty jego utrzymania i rozwoju, niż zakopać się w walkę z błędami i utrzymaniem jakiegoś chlewu. Zaś programista który nie interesuje się, i nie wie nic ponad to w czym aktualnie programuje, to jakiś wyrobnik, który się nie rozwija w swej branży. Ta branża szybko się zmienia, kto się nie uczy, ten z niej wypada.

Jeszcze na koniec o kwestii wad Ruby'ego. Naprawdę nie umiecie tu wypunktować nic konkretnego, i ja mam wam w tym pomagać? Poza tym, temat wątku jest raczej o Rails, a prawie cała dyskusja zeszła na temat języków, nie frameworków...

Ten post edytował hipertracker 4.09.2010, 19:32:03

[wiewiorek]

W starciu z ASP.NET MVC - Ruby on Rails jest pod każdym względem do tyłu. I nie mylić ASP.NET WebForms z najnowszym ASP.NET MVC.

Ten post edytował wiewiorek 4.09.2010, 20:25:33

[Pr0100]

W starciu z ASP.NET MVC - Ruby on Rails jest pod każdym względem do tyłu

nie ma to jak dobrze uargumentowana opinia dotycząca tematu dyskusji (IMG:style_emoticons/default/dry.gif)

[thek]

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

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

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

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

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

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

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

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

[wiewiorek]

A jakie duże strony powstały w RoR ? Nie za bardzo słyszałem... natomiast w PHP i ASP.NET powstaje zdecydowanie najwięcej stron - jest to chyba najlepszy wskaźnik oceny danej technologii - z tymże ASP.NET jest kojarzony z technologiami dla dużych i bogatych stąd jego popularność jest mniejsza niż PHP. Google trends może nie jest najlepszym wskaźnikiem, ale pokazuje, że RoR to technologia marginalna: http://www.google.com/trends?q=ruby+on+rai...=all&sort=0

Ten post edytował wiewiorek 5.09.2010, 09:27:12

[SHiP]

Thek tutaj dobrze zauważył, że w php bardzo ogromnym plusem jest prostota. I nie chodzi tylko o język ale i o kod źródłowy parsera. Nie wiem czy ktoś z was kiedyś go przeglądał ale mi się zdarzyło i poprawienie dziurawej funkcji lub dopisanie własnej to nie jest zbyt wiele zachodu. Nie wiem jak z Ruby(tu czekam na opinię) ale w przypadku .neta to niestety jest ciężko. O ile możemy bawić się w mono to niestety jest ono ciągle kilka miesięcy wstecz w porównaniu z oryginalną platformą. Mogę się mylić ale od tego są dyskusje (IMG:style_emoticons/default/winksmiley.jpg) .

Jeśli chodzi o prędkość php to właśnie w ten sposób można sporo zaoszczedzic - przepisując fragmenty kodu do języka c. Nie jest to może całkiem wygodne rozwiązanie ale na pewno najbardziej optymalne.

EDIT:
google trends się tutaj w ogóle nie nadaje. Jesli natomiast miałbym wpisać jakieś frazy to http://www.google.com/trends?q=ruby+langua...=all&sort=0
Ruby on Rails(to framework) a php to język więc twój wykres był bez sensu

Ten post edytował SHiP 5.09.2010, 09:36:23

[dr_bonzo]

Thek tutaj dobrze zauważył, że w php bardzo ogromnym plusem jest prostota. I nie chodzi tylko o język ale i o kod źródłowy parsera. Nie wiem czy ktoś z was kiedyś go przeglądał ale mi się zdarzyło i poprawienie dziurawej funkcji lub dopisanie własnej to nie jest zbyt wiele zachodu. Nie wiem jak z Ruby(tu czekam na opinię) ale w przypadku .neta to niestety jest ciężko.

Wydaje mi się, że Ruby jest "lubiany bardziej" przez zaawansowanych programistów - którzy docenią jego możliwości jako język programowania, i nie wymagają od niego, żeby był tak prosty jak PHP.

W Rubym naprawienie blednej funkcji wbudowanej to po prostu napisanie jej ponownie w Rubym (http://stackoverflow.com/questions/394144/what-does-monkey-patching-exactly-mean-in-ruby ) i załączenie do projektu. Nie muszisz nic w C grzebać, ani nazywać poprawionej funkcji inaczej. No i chyba programista *prostego* PHP niechętnie będzie się za kod w C zabierał (IMG:style_emoticons/default/winksmiley.jpg)

[SHiP]

@dr_bonzo: podoba mi się to rozwiązanie z Ruby. Mądrze to ktoś wymyślił (IMG:style_emoticons/default/winksmiley.jpg) .

Jesli chodzi o programistów do zmiany kodu parsera to jest to chyba oczywiste (IMG:style_emoticons/default/winksmiley.jpg) . Do tego to ja bym zatrudnił kogoś kto zna c. Moim zdaniem największym problemem Ruby jest mała ilość programistów. Tworzy się głupie błedne koło. Gdybym miał zakładać firmę to bym się nie zastanawiał, bo:

1. programistę php łatwiej znaleźć
2. programista ruby zazwyczaj jest na wyższym poziomie => trzeba mu więcej zapłacić

Ewentualnie kodować w php i powoli szkolić pracowników w stronę pythona/ruby lub javy ale to raczej kosztowne byłoby.

Poczekamy, zobaczymy jak się będzie rynek kształtował.

Ten post edytował SHiP 5.09.2010, 09:56:36

[hipertracker]

Przykładowo rzuciłeś że z Java pochodziły statyczne metody i atrybuty klas. Dziwne to nieco twierdzenie, bo ja z tymi spotykałem się w C, a to na nim, a nie Javie

W C nie ma żadnych klas bo C nie jest językiem obiektowym.

Z C++ więc bym wywodził źródło owych zmian.

Bo ja wiem? C++ posiada dziedziczenie wielobazowe, Java, i PHP5 - nie. Ale nie będę się upierał, bo to nic nie zmienia, gdyż zarówno C++ jak i Java są, w przeciwieństwie do PHP, językami ze statyczną typizacją. I to co ma sens tam, nie musi go mieć w języku dynamicznie typowanym. Ja to się dziwię, że nie wzorowano się na języku prawdziwie obiektowym i dynamicznym, choćby Smalltalku, Ruby czy Pythonie (Ruby powstał tym roku co Java, a Python o rok wcześniej). Zamiast próbować aplikować modelu obiektowy z statycznego do dynamicznego, o wiele sensowniej byłoby podejrzeć to, jak to zrobiono w innych językach dynamicznych.

Czy zakładając swój teraz w RoR przykładowo czy jRuby masz pewność, że za kilka miesięcy będzie on zdolny obsłużyć ruch idący w miliony użytkowników i konieczne będzie zmierzenie się z tym, czego nie przewidywałeś na początku?

No toż właśnie o to mi chodzi, że taka sytuacja mi raczej nie grozi. Na począterk, jeśli uznam, że jakieś fragmenty serwisu należy przyśpieszyć ponad to, co oferuje JRuby, mogę je wymienić na modułu napisane w Javie, lub Scali. Jeśli to za mało, mogę aplikację wpiąć Google App Engine lub inne systemy chmurowe. Ewentualnie mogę dorzucić serwerów i wpiąć się do Terracoty (która skaluje się bez limitów tworząc ciągłą przestrzeń pracy dla setek, lub tysięcy równolegle pracujących JVM). Poza tym mogę podpiąć się do bazy obiektowej (Neodatis, db4o),grafowej (Neo4J) itp., itd. Jak masz dostęp do platformy JVM to raczej żadne ograniczenia skalowalności ci nie grożą.

Co do kosztów, co jak co, ale znaleźć programistę Javy to żaden problem. Będzie droższy od pehapowca, ale też jeden starczy za takich pięciu. Poza tym student informatyki uczy się Javy, więc do jakiegoś prostego zadania nie muszę szukać nie wiadomo jakiego wymiatacza.

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

Ależ ja nie twierdzę, że język Java jest powerfull, lecz że Java jako platforma taka jest. Z tą przystępnością języka to trochę przesadzasz. Java to dosyć prymitywny język, może nie aż tak jak PHP, ale na pewno bardziej niż Ruby. Ma dosyć prostą składnię i zasady. Dla pehapowca może tylko trudność sprawiać rozwlekłość składni i to że na każdym kroku trzeba pamiętać o typach. Kiedyś też miałem błędne wyobrażenie o złożoności Javy jako języka. I też próbowałem czytać Thinking in Java (ta książka jest źle napisana). No, ale przecież Java jako platforma nie ogranicza mnie do tego języka, więc nie widzę powodu aby się go trzymać. Sama Java jako język niech sobie zostanie takim asemblerem do JVM. Nawet nie ma sensu walczyć o to aby ulepszać jej składnię (tak jak to robi Microsoft ze swoim C#). PO co, skoro można użyć świetnej Scali jako zamiennika?

Zauważ, że kiedyś w php nie było choćby czegoś takiego jak choćby klasy obsługujące katalogi, a ludzie sami to implementowali bo było potrzebne.

No wiem, pamiętam, że w PHP nie było kiedyś nawet obsługi sesji, i to też trzeba było sobie jakoś obsłużyć. Tylko, że ile ty możesz samemu sobie "doimplementować"? Dużo nie zaszalejesz. A mając dostęp do JVM, po prostu sięgasz i używasz to, co potrzebujesz.

Gdyby wszyscy podchodzili tak jak Ty chcesz, to aplikacje byłyby niemal bezbłędne (wciąż istniały by pewne możliwości wystąpienia problemów), ale ich tworzenie zajmowało by przynajmniej kilkakrotnie więcej czasu i pieniędzy.

Ależ nie. Uważam że należy podchodzić pragmatycznie i zastanowić się czy lepiej napisać daną funkcjonalność samemu, czy skorzystać z gotowca. Nie jestem przciwko pisaniu aplikacji heterogenicznej, czyli takiej która korzysta równocześnie z różnych technologii, nie wykluczając PHP.

PHP i Ruby to języki inne, a ich porównywanie choć może i ma dla kogoś sens, jest raczej średnio przydatne

Dla ciebie może nie, ale dla innych - tak. Nie widzisz porównania, bo nie znasz Ruby. Zakosztuj pracy w Rails to zobaczysz różnicę. Ja też wcześniej nie widziałem wielkiego powodu aby się uczyć Ruby. Nie wydawał mi się ąz tyle wnoszący w stosunku do, wtedy mojego ulubionego, Pythona. Ae o dziwo, Python jako język jest prostszy od Ruby, ale tego nie da się powiedzieć o jego frameworkach. Z ciekawości sprawdziłem czym się różni Rails i mi się spodobała ta jego prostota i elegancja kodu. To był rok 2005. Teraz wiele się zmieniło. Czy wg mnie Rails jest najlepszym framework do webu? Niekoniecznie. Wzorzec MVC ma wiele wad. Chyba bardziej mi odpowiada podejście View-First, jakie zastosowano w Lifcie. Ale to wyższa poprzeczka, bo pisanie kodu w enigmatycznej Scali pełnej pattern matching wymaga pewnego przestawienia. Ale dla większości starczy Rails3.

A jakie duże strony powstały w RoR ? Nie za bardzo słyszałem.

Ruby (lub JRuby) on Rails używany jest przez Twittera, Oracle/Sun, 37Signals, Scribd, Hulu, Github itp. Taki 37signals, (to tam stworzono Rails) ma ponad 5 mln klientów...

* http://storecrowd.com/blog/top-50-ruby-on-rails-websites
* http://www.rubyonrailsgallery.com
* http://rubyonrails.org/applications
* http://rails100.pbworks.com
* http://www.setfiremedia.com/blog/50-of-the...g-ruby-on-rails
* http://webdeveloper.econsultant.com/ruby-r...-projects-sites
* http://kenai.com/projects/jruby/pages/SuccessStories

Ten post edytował hipertracker 5.09.2010, 12:19:55

[vokiel]

Temat wątku to "Frameworki PHP vs Ruby On Rails", zatem IMHO pod ocenę powinny być poddane frameworki a nie sam język. To tak na marginesie.

Moim zdaniem ocenę dwóch narzędzi powinno się opierać na konkretnych, porównywalnych przypadkach zastosowania. Nie ma sensu sprzeczanie się, że Ruby ma to, można wykorzystać tamto, a PHP ma takie coś, czy coś innego. Poza tym, jeśli porównujecie to albo Ruby vs PHP, albo RoR vs Zend, czy RoR vs Symfony. Porównywanie JRuby on Rails do czystego PHP jest po prostu bez sensu.

Samo posiadanie jakiś funkcjonalności, możliwości nic nie znaczy. Ważne jest jak to się przekłada na konkretne zastosowania. Porównywać można np napisanie CMS'a w Kohanie vs RoR. Tutaj pojawia się możliwość sensownego przedstawienia za i przeciw danego zastosowania. Stawiamy się opcji wykonawcy aplikacji od zera. Przychodzi klient, daje dokładną specyfikację i zabieramy się do pracy. To miałoby jakiś wymierny sens. Można byłoby porównać czas niezbędny do przygotowania kompletnego środowiska, czas tworzenia rozwiązania, szybkość działania na takiej samej maszynie, ilość pożartego RAM, maksymalne ilość jednoczesnych użytkowników itd.

Z tym, że i takie porównanie nie będzie do końca obiektywne. Bo przede wszystkim wiele zależy od programisty, od subiektywnych ocen zwolenników danych rozwiązań (osoby, które wybrały daną technologię podświadomie nie będą zauważały niektórych niedociągnięć, za to inne aspekty będą przedstawiać w świetle pozytywnym, nawet jeśli w innym języku uznaliby to za wadę).

Tak czy inaczej, abstrahując od specyficznych cech programistów, ich znajomości tematu etc, porównać można np stworzenie dwóch takich samych systemów.

[thek]

Sam C jeszcze nie obsługiwał klas, ale miał już ich zaczątek w postaci typów złożonych pokroju struct. Z tego w C++ rozwinęło się coś co znamy jako klasy już w bardziej prawidłowym tego słowa znaczeniu. Zresztą wiem, że ani C, ani C++ nie są językami obiektowymi. C++ jest obiektowo orientowany. A to jest pewna różnica. Smalltalk już jest jak najbardziej obiektowy. Zresztą to był chyba jeden z pierwszych na świecie w pełni obiektowych jeśli mnie pamięć nie myli...

Co do redefinicji to od 5.3 w sumie można sobie przeciążać równie prosto funkcje wbudowane. Od tego właśnie są przestrzenie nazw.

Gdy mowa o różnicach między PHP i C++ to od zawsze uważałem ten pierwszy za baaaaaardzo uproszczony wariant drugiego, dodatkowo z dynamicznym typowaniem. Wiele bardziej złożonych mechanizmów tego drugiego więc zapewne nie wejdzie nigdy nawet do etapu TODO w PHP bez porządnej reorganizacji go (czyli przepisania na nowo).

Ze złożonością typów czy składni akurat nie było u mnie problemów. C++ jest od Javy "cięższy" do opanowania i w zasadzie Ci, którzy dobrze potrafią C++, nie powinni mieć problemów z "kuwusią". A jednak tak nie jest choćby w moim przypadku, a wiem, że nie jestem w tym odosobniony. Nie wiem co jest w Javie, że mimo iż od C++ prostsza, nie potrafię się do niej przekonać.

Co do JVM to wykraczamy tutaj poza ramy języka jakiegokolwiek. Gdyby porównać języki do aplikacji, to JVM stanowilo by coś na kształt systemu operacyjnego czy środowiska uruchomieniowego. Dlatego nie mogę się zgodzić że to JRuby, Java, Scala czy jakikolwiek jest jest świetny/boski/zajebisty (niepotrzebne skreślić (IMG:style_emoticons/default/winksmiley.jpg) ). Miałbym jednak problem by jednoznacznie się źle wypowiedzieć o JVM, które jest faktycznie bardzo dobrym środowiskiem na którym bazować mogą inne języki. Dlatego właśnie chciałbym oddzielić opisywanie zalet języka i jego frameworków od środowiska w jakim są uruchamiane. Równie dobrze moglibyśmy rzucać przykładowo choćby Matlabem. Resztę dokończę później.

Ok... Piszę dalej po kilku godzinach...

Zgadzam się ze zdaniem vokiela. Odskoczyliśmy nieco od głównego wątku i "rozmieniliśmy na drobne" wpadając na problem bezpośredniego porównywania języków, zamiast ich frameworków. Tutaj najlepszym byłoby rzucić zadanie określone osobom o identycznym stopniu znajomości badanego frameworka określonego języka i porównywać zarówno czas tworzenia, przygotowanie środowiska na serwerze, jakość kodu, jego wydajność, skalowalność, odporność na błędy i takie tam. Tylko to byłoby dopiero w miarę sensowne i oddawało stopień komplikacji. Ale nadal nie tłumaczyło podtytułu tematu, czyli tego skąd u miłośników RoR tak aktywne promowanie Ruby'ego na wielu płaszczyznach. Czasem hacząc o lekki fanatyzm. Stąd właśnie moje porównanie do miłośników produktów firmy Apple.

[hipertracker]

Poza tym, jeśli porównujecie to albo Ruby vs PHP, albo RoR vs Zend, czy RoR vs Symfony. Porównywanie JRuby on Rails do czystego PHP jest po prostu bez sensu

To tylko tak pozornie wygląda, bo na upartego można by powiedzieć, że sam PHP z definicji już jest takim mikroframeworkiem webowym. Toż to nie samodzielny język ogólnego zastosowania, ale już język z osadzony w HTML. Tak jak twórcy Savant doszli do wniosku, że drogą jaką poszło Smarty jest bez sensu, bo PHP sam w sobie jest już językiem szablonów. Poza tym, można by powiedzieć, że przez PHP jest tu rozumiane "dowolne rozwiązanie webowe (czy framework) napisane w PHP".

Samo posiadanie jakiś funkcjonalności, możliwości nic nie znaczy. Ważne jest jak to się przekłada na konkretne zastosowania.

Ale z drugiej strony, nie ma możliwości zastosowania czegoś, jeśli nie będzie w ogóle funkcjonalnie dostępne. Rails odpalony na JRuby jest w obszarze poza zasięgiem PHP. Ale nawet nie sięgając do JRuby, to i tak PHP, z powodu głębokich błędów w konstrukcji języka, nie nadaje się do pisania aplikacji, które powinny być maksymalnie odporne na błędy. PHP nie potrafi obsłużyć błędów fatal error. Frameworki pythonowe (Django i web2py) mają wbudowany mechanizm automatycznego przechwytywania wszelkich błędów i zgłaszania go administratorowi. Rails tego nie ma, ale można to łatwo dodać. Zaś w PHP czegoś takiego nie ma z powodu ograniczeń języka.

Tak czy inaczej, abstrahując od specyficznych cech programistów, ich znajomości tematu etc, porównać można np stworzenie dwóch takich samych systemów.

Tyko że tak stawiając sprawę, ograniczasz drugą stronę bo PHP nie jest w stanie nawiązać walki w wielu dziedzinach, które są bez problemu dostępne dla którejś z implementacji Ruby'ego. Choćby ten system automatycznej obsługi niewychwyconych błędów. Albo podpięcie się do chmury Goole App Engine. Albo zapisywanie danych bez żadnych śmiesznych, relacyjnych baz danych, ale transparentnie, w transakcyjnej bazie obiektowej sprawnie operującej na danych wielkości kilku petabajtów (vide MagLev).

Innymi słowy Ruby jest w stanie zaproponować taki system, który PHP nie będzie w stanie z nic obsłużyć. Zaś cokolwiek można stworzyć w PHP, da się stworzyć także i w Ruby. PHP jest po prostu dużo bardziej ograniczony. I w to chyba nikt nie wątpi.

To nie znaczy, że PHP do niczego się nie nadaje. Owszem, do stron-wizytówek może być. (IMG:style_emoticons/default/winksmiley.jpg) Sądzę, że los PHP jest policzony i czas jego świetności już nigdy nie wróci. Każdy bardziej zaawansowany programista, z pewnością będzie wolał wybrać mniej ograniczającą (i wkurzającą) technologię. I nie musi to być Ruby, więc proszę mi nie pleść nonensów o jakimś zmasowanym marketingu Ruby'ego.

Ten post edytował hipertracker 6.09.2010, 01:53:26

[uupah5]

Temat wątku to "Frameworki PHP vs Ruby On Rails", zatem IMHO pod ocenę powinny być poddane frameworki a nie sam język. To tak na marginesie.

http://www.google.com/trends?q=ruby+on+rai...=all&sort=0

[wiewiorek]

to ja też dam linka do google trends jak kolega wyżej tylko w nawiązaniu do asp.net mvc:
http://www.google.com/trends?q=ruby+on+rai...=all&sort=0

w każdym bądź razie google pokazuje, że następuje szybki spadek zainteresowania RoR na świecie.

Ten post edytował wiewiorek 6.09.2010, 05:45:47

[dr_bonzo]

Google trends? A co to zlicza? Ilosc newsow o danym temacie? To ja mam namacalny dowod ze wszystko inne tez traci na zainteresowaniu: http://www.google.com/trends?q=struts%2C+a...=all&sort=0

[hipertracker]

to ja też dam linka do google trends jak kolega wyżej tylko w nawiązaniu do asp.net mvc:
http://www.google.com/trends?q=ruby+on+rai...=all&sort=0

w każdym bądź razie google pokazuje, że następuje szybki spadek zainteresowania RoR na świecie.

Eee tam, zaraz powiesz, że disco-polo jest wyznacznikiem polskiej kultury muzycznej. (IMG:style_emoticons/default/smile.gif)

Bardziej ciekawe jest zestawienie frustracji wokół obu technologii:


Wyniki z Google dla
"PHP sucks" - about 7,810,000 results
"Ruby sucks" - about 1,030,000 results
"Ruby on Rails sucks" - about 57,500 results


Ten post edytował hipertracker 6.09.2010, 07:21:43

[wookieb]

Masakra. Dzieci dorwały statystyki i będą się kłócić a parę cyferek które powstają głównie dzięki bandom idiotów.
Nigdy ale to nigdy nie mierzy się jakości produktu to ilość jego wyszukiwań w googlu! To też może oznaczać, że przynosi TYLE PROBLEMÓW!
Błagam skończcie debilne statystyki.

[Daiquiri]

@hipertracker - prowadzisz iście akademickie wywody. Masz do tego oczywiście pełne prawo, aczkolwiek poproszę Cię o analizę pod kątem biznesowym (IMG:style_emoticons/default/smile.gif) . Jaką moc mają Twoje argumenty w momencie gdy przychodzi do mnie klient i "rzuca" na stół specyfikację. Jakie realne korzyści przyniesie klientowi wybranie przeze mnie pracy z Rubym?

Chciałam jeszcze zauważyć jedną rzecz. Temat nosi nazwę "Frameworki PHP vs Ruby On Rails, Skąd ten agresywny marketing w community RoR ?". Patrząc na Twoje wypowiedzi hipertracker rozumiem już dlaczego autor tematu użył słowa "agresywny" (IMG:style_emoticons/default/smile.gif) .

[Radarek]

@wookieb: +1

@Daiquiri: dlaczego oceniasz przez pryzmat jednego przypadku?(IMG:style_emoticons/default/smile.gif) Myślę iż hipertracker nie obrazi się gdy powiem iż jest on specyficznym człowiekiem (przynajmniej jeśli chodzi o programowanie), wystarczy poczytać jego bloga.

Co do pytania:

Jakie realne korzyści przyniesie klientowi wybranie przeze mnie pracy z Rubym?

Pytanie zasadnicze: dlaczego sądzisz iż to klient ma być tą stroną, która na tym coś zyskuje? Otóż w pierwszej kolejności zyskują programiści. Kiedy przebrnie się już przez tą pierwszą barierę nauki odkrywa się nowy świat, w którym po prostu lepiej się programuje. Dlaczego lepiej? Dlatego, że język Ruby jest lepiej przemyślanym językiem od PHP. I proszę Was, nie piszcie mi, że tak nie jest. Nie mam kompletnie problemu z tym iż ktoś programuje w PHP, na prawdę. Ale jeśli nie umie otwarcie przyznać, że język ma ogromne niedociągnięcia to szkoda dalej dyskutować.... Po prostu trzeba zdawać sobie sprawę z wad i ograniczeń stosowanych technologii. Ja też zdaję sobie z wad jakie posiada Ruby, ale dla mnie osobiście jest ich po prostu o wiele wiele mniej niż w PHP. Sam "wychowałem" się na PHP więc mam porównanie.
Zatem mnie jako programiście pracuje się lepiej z Ruby. A jak się programiście lepiej pracuje to i pośrednio korzysta z tego klient/pracodawca. Chęć do pracy jest większa, wydajność też.

Nijak ma się to oczywiście do budowanych aplikacji i ich możliwości. W każdej z wiodących technologii można zbudować dowolną aplikację (od formularza kontaktowego po facebooka), to tylko kwestia czasu i pieniędzy. Dlatego podawanie przykładu "facebook jest napisany w php więc php jest najlepsze" nie jest dobrym argumentem. Po prostu pewien zbieg zdarzeń sprawił, że z trójcy python/ruby/php to ten ostatni jest najpopularniejszy. Tylko czy najważniejsza jest popularność? Gdyby tak było to właśnie siedziałbym i słuchałbym Dody albo jakiejś innej shitowej muzyki. Natomiast każda z tych 3 technologii ma na tyle duże community by pakowanie się w nią nie oznaczało pakowanie się w nieznane (to zostało już zrobione przez innych (IMG:style_emoticons/default/smile.gif) ).

[Daiquiri]

@Daiquiri: dlaczego oceniasz przez pryzmat jednego przypadku?(IMG:style_emoticons/default/smile.gif) Myślę iż hipertracker nie obrazi się gdy powiem iż jest on specyficznym człowiekiem (przynajmniej jeśli chodzi o programowanie), wystarczy poczytać jego bloga.

A gdzie ja napisałam, że nie jest fajnym człowiekiem? Stwierdzam fakt: dyskutuje na wzór akademickiej maniery prowadzi "agresywny" marketing. Czy to źle? Nie mnie oceniać (IMG:style_emoticons/default/smile.gif) .

Pytanie zasadnicze: dlaczego sądzisz iż to klient ma być tą stroną, która na tym coś zyskuje?

Bo on za to płaci? Nie pytałam o to co zyskuje programista, bo te kilka stron dyskusji właśnie o tym traktuje (IMG:style_emoticons/default/smile.gif) . Mnie interesuje aspekt praktyczny - nie teoretyczny.

[Radarek]

A gdzie ja napisałam, że nie jest fajnym człowiekiem? Stwierdzam fakt: dyskutuje na wzór akademickiej maniery prowadzi "agresywny" marketing. Czy to źle? Nie mnie oceniać (IMG:style_emoticons/default/smile.gif) .

Nie chodzi mi o ocenę osoby hipertrackera, ale o ocenę marketingu RoR (czy np. community Rubiego) po tym co pisze hipertracker (IMG:style_emoticons/default/smile.gif) .

Bo on za to płaci? Nie pytałam o to co zyskuje programista, bo te kilka stron dyskusji właśnie o tym traktuje (IMG:style_emoticons/default/smile.gif) . Mnie interesuje aspekt praktyczny - nie teoretyczny.

Zadowolony programista to programista wydajny, dokładniejszy, popełniający mniej błędów. Na tym zyskuje właśnie klient. Oczywiście jeden programista jest bardziej wydajny w php (bo siedzi w nim od 5 lat i innej technologii nie ruszał), inny w rubym (np. ja). Bez dwóch zdań. Natomiast mnie (czy hipertrackera) możecie brać za przykład, że można przestawić się na inną technologię i czerpać z tego same korzyści. Pomijając akademickie wywody jestem pewien iż hipertracker potwierdzi prosty fakt: porównując php do ruby (czy też frameworkowo Zend/Symfony do RoR/Sinatra) w tej drugiej technologii jest bardziej wydajny, popełnia mniej błędów i ma większą ochotę po prostu programować. Na tym skorzystamy zarówno my jak i nasi klienci/pracodawcy.

[Daiquiri]

@Radarek
Prosiłam o realne korzyści dla klienta. Ty podałeś "miękkie" kryteria, które mogę podpiąć pod większość technologii ("zadowolony programista to programista wydajny, dokładniejszy, popełniający mniej błędów") - bo czy programista PHP jest z góry niezadowolony? Ty mówisz o przypadku hipertracker'a jako wydajniejszego w technologii, którą jak mniemam preferuje - ja nawet nie próbuję tego podważyć, bo niewątpliwie tak właśnie jest. Problem w tym, że ja szukam zupełnie innych informacji.

Pytam o to jakie realne korzyści przyniesie klientowi fakt, iż programista działa w Ruby. Czym dla klienta różni się fakt (i co na tym zyskuje), że dane zlecenie zostało wykonane przy użyciu Ruby zamiast "zwykłego" PHP.

Co do "agresywnego" marketingu RoR - zobacz jak szczęśliwie się złożyło. Autor pyta "Skąd ten agresywny marketing RoR" a pojawia się osoba, która takową "agresję marketingową" uprawia. Zbieg okoliczności? Nie twierdzę, że wszyscy korzystający z Ruby lubują się w takiej reklamie - dlatego odwołałam się do osoby hipertrackera a nie np. Twojej (IMG:style_emoticons/default/smile.gif) .

[dr_bonzo]

Pytam o to jakie realne korzyści przyniesie klientowi fakt, iż programista działa w Ruby. Czym dla klienta różni się fakt (i co na tym zyskuje), że dane zlecenie zostało wykonane przy użyciu Ruby zamiast "zwykłego" PHP.

A co go to interesuje w czym projekt jest zrobiony, jeśli projekt jest czymś co się nie zmieści na shared hostingu (PHP ma tu przewagę w małych projektach).
Duży projekt i tak będzie wspierany przez firmę która go robiła - bo jest z definicji za skomplikowany żeby oddać go komuś innemu - niezależnie od języka - więc argument o dostępności programistów odpada.

Autor pyta "Skąd ten agresywny marketing RoR" a pojawia się osoba, która takową "agresję marketingową" uprawia. Zbieg okoliczności? Nie twierdzę, że wszyscy korzystający z Ruby lubują się w takiej reklamie - dlatego odwołałam się do osoby hipertrackera a nie np. Twojej .

A nie miałbyś chęci podzielić się z innymi infem o nowej technologi która ci się i podoba i jest przyjemna i sprawdza w praktyce w czasie dyskusji o technologii?

Nawiązując do sprzętu appla (np. macbook): zachwycam się np budową, brakiem oczojebnych diód w obudowie, mag safem, mozliwoscia uchylania ekranu bez przytrzymywania "klawiatury" - bo uważam to za dobre/genialne rozwiązania. A czym mam się zachwycać w przypadku składaka - "patrz, jaki czarny kadłubek. Mam 10 diód i przelacznik WIFI. itp.". Jak dla mnie to wywodzi się z entuzjazmu i zadowolenia do technologii/produktów.

Czemu nikt tak nie marketinguje PHP? Nie potrzeba (bo jest mega popularny) czy nikt się nim nie zachwyca? (IMG:style_emoticons/default/winksmiley.jpg)

[SHiP]

Teoretycznie wyższe koszty utrzymania. Bo o ile firma, która nam wszystko złożyła dopisze pewne rzeczy w relatywnie niskiej cenie, to inna firma(np. gdyby pierwsza zbankrutowała, nie miała czasu etc) zrobi to już dużo drożej niż gdyby to był php. Myślę, że przy dużych projektach nie byłoby widać znaczącej różnicy jeśli chodzi o serwer. W przypadku małych - nie wiem jak cenowo stoją shared hostingi z rubym. Tu czekam na opinię specjalistów (IMG:style_emoticons/default/winksmiley.jpg) .

[Daiquiri]

A co go to interesuje w czym projekt jest zrobiony, jeśli projekt jest czymś co się nie zmieści na shared hostingu (PHP ma tu przewagę w małych projektach).
Duży projekt i tak będzie wspierany przez firmę która go robiła - bo jest z definicji za skomplikowany żeby oddać go komuś innemu - niezależnie od języka - więc argument o dostępności programistów odpada.

Przecież właśnie to napisałam, ze nie ma dla niego znaczenia fakt z jakiej technologi skorzystasz (jako argumentu samego w sobie). Jeżeli natomiast powiesz, że ten projekt w Rubym będzie kosztował 20% mniej niż ten sam projekt zrobiony w PHP - to np. klienta zainteresuje.

A nie miałbyś chęci podzielić się z innymi infem o nowej technologi która ci się i podoba i jest przyjemna i sprawdza w praktyce w czasie dyskusji o technologii?

Pewnie, że tak! Jednak w nieco inny sposób.... (IMG:style_emoticons/default/smile.gif) .

[thek]

W ogólnym zarysie z tym co pisze Radarek lub hipertracker się zgodzę, bo nie zamykam się na PHP i podobnie jak większość administracji ( także moderatorów ) oraz bardziej doświadczonych użytkowników, zdajemy sprawę z ułomności chyba niemal każdego języka z jakim mieliśmy do czynienia. Wookieb też słusznie podniósł problem statystyk. Jeśli w necie o czymś pisze to niekoniecznie są to opisy technologii, ale niejednokrotnie problemy z czymś. By podać bardzo jaskrawy przykład... "Headers already sent". Problem pojawiający się bardzo często na forum choć jego rozwiązanie jest banalne i wytłumaczone na niemal wszystkie możliwe języki świata oraz sposoby. Wolę nie wiedzieć ile ten problem razy był już zatrzymany na bardzo agresywnym filtrze tego forum. Problem na poziomie poniżej przedszkola a co pokazuje google?
Około 3,440,000 wyników (0,29 s)
To naprawdę nie jest śmieszne...

Nie wiem, może źle odczytałem słowa Daiquiri: "Mnie interesuje aspekt praktyczny - nie teoretyczny.", ale odnoszę wrażenie, że chodzi o dalszy los oprogramowania, gdy je już klientowi oddamy. Przypuśćmy znaleziono błąd i co teraz? Porównując wielkość społeczności, naprawdę dobrych programistów Ruby jest zapewne o wiele mniej niż o podobnym stopniu wiedzy w PHP. Trochę to ku konserwacji kodu idzie, a hipertracker sam wspomniał, że to często najbardziej koszto- oraz czasochłonna część. Kto wie gdzie nasze oprogramowanie trafi? Może klient odsprzeda je dalej? Co gdy to co zakupiliśmy okaże nie-upgrade'owalne, bo struktura jest tak hermetyczna, że nie da się do tego czegoś dorzucić bez poważnych ingerencji w szkielet? Ponownie zatrudnimy programistę by nam to poszerzył, zmodyfikował? W końcu klient nie musi znać się na programowaniu. Zlecił, dał projekt, teraz chce wzbogacić o nowe funkcjonalności, choć jest to niemal karkołomne. Ja także po programistach php poprawiałem taki kod, choć rzekomo był "w pełni profesjonalnym, komercyjnym rozwiązaniem", a mimo to miał poważne błędy na etapie projektowania, nie mówiąc o tych we wdrożeniu. Taki produkt dobry jak programista go tworzący.

Dlatego oddzielam język, i choć jego sprawę poruszyłem trochę w postach, to bardziej mnie ciekawi ów marketing, który porównywałem do Apple'owskiego. To jest według mnie ciekawe zjawisko. Skąd u developerów tego czy określonego języka takie nastawienie na bardzo silną promocję. Kiedyś było identycznie z flashem. Miał być on panaceum na wszystko, a mimo zachwytów nad nim, utrudniał on choćby porządne pozycjonowanie stron, by z tych jego poważniejszych grzechów wymienić przynajmniej jeden. Jest ASP, php, ruby, python oraz wiele innych języków dynamicznego generowania treści, ale mało który ma taką grupę aktywnie działających na polu marketingowym. Php stał się niejako standardem i niemal marketing zarzucono poza informowaniem o nowościach w nadchodzących wersjach. Wszystko jak na tacy na stronie projektu, ale poza nią niewiele tak naprawdę czegoś co nie jest przedrukiem. A jako że dr_bonzo odpowiedział w czasie pisania, to zapewne sam zauważył, że niestety, ale jakościowo Apple zaczyna dawać ciała coraz bardziej, podobnie jak reszta branży. Coraz gorsze materiały, wykonanie. Rozumiem, że wpadki się zdarzają każdemu, ale udawanie, że problemu nie ma choć jest ( jak było z nieszczęsną anteną ) jest już niepoważnym podejściem firmy do klientów. Gdy jeszcze do czasu gdy ogłoszono, że za darmo będą rozdawać pokrowce, ogłoszono, że powinni je klienci kupić sami to problem zniknie, było moim zdaniem kpiną i naciąganiem na dodatkowe koszty.

Gdy niedawno na kanale irc tego portalu rzucono klasę php, która ocenia skalę podobieństwa dwóch obrazków, a która dostała nominację do najlepszej miesiąca, to po samym opisie działania większość devów płakała ze śmiechu nad "zaawansowaniem". Na tym forum trafiały się pomysły, które biły nie tylko o kilka, ale wręcz kilkanaście długości to co tam zaproponowano. Inna sprawą jest to, że nawet tutaj moderatorzy wcale nie wyszukują na siłę rozwiązań w php i jeśli się da, to polecają korzystanie z zewnętrznych programów i bibliotek. Przykład? Ile razy na tym forum widziano polecanie odpalania przez exec imagemagicka na równi z GD? Ja widzę co rusz. Sam niedawno dałem temat jak rozwiązać aplikację przenośną i ostatecznie robić ją będę na kilka sposobów, także z użyciem php, ale jako jeden z wariantów, który potem oddam "klientowi" pod ocenę. Sam wybierze co dla niego lepsze/wygodniejsze.

Wracając jeszcze do wydajności, to klienta nie obchodzi czy programista jest zadowolony. On chce aplikację i już. A to czy w czasie pisania skakał on pod sufit z radością, czy klął na czym świat stoi, mało go obchodzi. Owszem, masz rację, że radosny jest wydajniejszy i ma większy zapał do pracy, ale ile razy można się cieszyć z tego samego wciąż? A nie ukrywajmy, większość aplikacji jest do siebie podobnych i podąża za pewną modą. Jeśli dostajesz zlecenie poważniejsze a innowacyjne, to jest duże prawdopodobieństwo, że niedługo się zetkniesz z innym, bazującym lub wzorującym na nim.

[Theqos]

Pomijając zadowolenie programisty i jego umiejętności to chyba oczywiste jest, że w lepszym języku/technologii napisze się aplikacje szybciej. To jest chyba zysk dla klienta?

PS. Ja tam bym poparł pana hipertracker bo mądre rzeczy prawi. Pomimo stylu "flame'owego", do którego chyba już każdy się przyzwyczaił w dyskusjach językowych. I tak każdy wie, że Scala > Ruby bo języki dynamicznie typowane to można co najwyżej do stron wizytówek używać (IMG:style_emoticons/default/winksmiley.jpg)

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

Chciałbym się z tym akademicko nie zgodzić. Pomijam już to czy kolega słyszał o metodzie JIT, ale JVM potrafi optymalizować już działajacy kod. Dzięki temu otwierają się całkiem nowe możliwości w przeciwieństwie do zwykłej starej "binarki".

[marcio]

Pomijając zadowolenie programisty i jego umiejętności to chyba oczywiste jest, że w lepszym języku/technologii napisze się aplikacje szybciej. To jest chyba zysk dla klienta?

Nie ma to jak profesjonalna opinia...jakie wedlug ciebie sa lepsze jezyki/technologie i na jakich kryteriach owe oceniasz...?

Niby dlaczego jezyki dynamicznie typowane, ogolnie "skryptowe" sa zle i nadaja sie tylko na strony wizytowek...?rotfl

JIT, JIT'em ale jvm chyba od wersji 1.6 ma wszystkie te optymalizacje....o ile sie nie myle...
.NET lubie ale i tak poki co wydajnosciowo w wielu rzeczach cpp nie dorowna to samo tyczy sie raczej javy.

[dr_bonzo]

.NET lubie ale i tak poki co wydajnosciowo w wielu rzeczach cpp nie dorowna to samo tyczy sie raczej javy.

To cię zmartwię, ASM jest jeszcze szybszy niż C/C++, ale co z tego?

[marcio]

CHodzi o to ze JIT na pewno dziala szybciej niz jezyki interpretowane co nie zmienia faktu ze poki co nie ma powodu zeby az tak sie nim zachwycac (IMG:style_emoticons/default/snitch.gif)

[thek]

Theqos. Musiałbyś naprawdę bardzo nieoptymalnie pisać w C/C++ i naprawdę bardzo dobrze w innych by się ich wydajność zbliżyła do siebie. Jednak aplikacja napisana przez programistów na tym samym dobrym poziomie nie ma szans być wolniejsza w języku kompilowanym. Zwróć choćby uwagę na fakt, że w przypadku oparcia aplikacji o JVM pierwsze uruchomienie musi być drastycznie wolne z racji załadowania tego wszystkiego do pamięci. Jeśli już w niej jest - OK - działa szybko, ale i tak z reguły trochę wolniej niż binarka. I tak jest lepiej niż kiedyś. Sam pamiętam jak aplikacje Javy po kilku dniach nieustannej pracy potrafiły zmienić responsywność systemu do kilkunastu sekund. Ja kiedyś tak zostawiłem jedną i pojechałem na kilka dni. Gdy wróciłem i włączyłem monitor, to kliknięcie w klawisz objawiło się reakcją po pół minucie. Dopiero po drobnej pracy spadł czas do około 5-10 sekund. To że JVM może optymalizować działający kod, nie znaczy, że dokona cudów. Do pewnej granicy wspomoże, ale nie licz na hiper przyspieszenie.

Lepszy język czy technologia nie musi mieć ukierunkowania na programistę. Owszem. C++ jest lepszy niż ASM, a PHP jest lepszy pod kątem programowania webowego niż C++. Ale popatrz też na ich wydajność. Każdy kolejny jest wolniejszy od poprzednika, choć przy każdym z nich można powiedzieć, że jest wygodniejszy (lepszy?) dla programisty.

Jak zauważył dr_bonzo... Spierać się o języki możemy, ale z assemblerem i tak nic nie wygra (IMG:style_emoticons/default/smile.gif) Tylko kto się teraz poza piszącymi drivery tym zajmuje na poważnie? Na studiach liźniesz nieco instrukcji 8080 i na tym koniec.

[hipertracker]

Pytam o to jakie realne korzyści przyniesie klientowi fakt, iż programista działa w Ruby. Czym dla klienta różni się fakt (i co na tym zyskuje), że dane zlecenie zostało wykonane przy użyciu Ruby zamiast "zwykłego" PHP.

1. większą elastyczność na zmienny humor klienta, który sam do końca nie jest pewien tego, jak ma wyglądać końcowy produkt. Wbrew pozorom to jest dosyć częsta sytuacja, że klient chce wprowadzać jakieś zmiany do poczatkowych założeń. A Rails jest stworzony do pracy agile.
2. mniejsze koszty utrzymania kodu, bo kod jest czytelniejszy, i jest go po prostu mniej
3. łatwiejsze nanoszenie zmian w działającej funkcjonalności lub dodawanie nowej (trochę wynika z pkt. 2 ale też z tego na ile modularnie pisana jest aplikacja)
4. większą odporność na awarie i błędy, możliwość automatycznego wyłapywania wszelkich nie obsłużonych wyjątków i wysyłanie ich natychmiast do osób, które się kodem opiekują. Dzięki temu błędy mogą być wyłapywane i naprawiane szybciej oszczędzając klientowi wstydu ("patrzcie jak im strona leży!, hahaha, hehehe"). W PHP można co najwyżej czekać aż jakiś wkurzony klient zgłosi błąd, którego nie wyłapali programiści. Ewentualnie pozostaje regularne przeczesywanie logów długo po tym jak błąd wystąpił. Mina klientów którzy, po kolejnym pehapowym fatal errorze, zobaczyli na ekranie biały ekran - bezcenna! (IMG:style_emoticons/default/laugh.gif)
5. trochę to samo co pkt. 4) większą odporność na błędy ze wzgędu na lepsze pokrycie kodu testami. Rails zawsze kładł nacisk na pokrycie kodu testami jednostkowymi i funkcjonalnymi. Ma doskonałe, eleganckie biblioteki do tego celu (RSpec, Cucumber i inne)
6. lepsze dogadanie się między klientem a wykonawcą odnośnie tego, co ma być zrobione. Zmiast pisać ciężkie wypracowania, albo przyjmować to co trzeba zrobić "na słowo", można w prosty, i czytelny dla osoby nietechnicznej, ubrać jej wymagania w formę specyfikacji BDD, zobacz Cucumber http://cukes.com
7. większa szybkość działania, aktualnie Rails jest szybszy od dowolnego frameworka PHP, a są szybsze i lżejsze rozwiązania od Rails, jak Padrino czy Sinatra.
8. brak ograniczeń rozwoju i skalowalności, klient nie musi się bać, że utknie w rozwoju bo ma zawsze możliwość podpięcia się do ciężkich systemów napisanych w technologii głównego nurtu (Java, .NET). Jeśli cokolwiek brakuje, to na pewno znajdzie się jakaś biblioteka w Javie, która dany problem rozwiązuje.
9. możliwość wpięcia się do chmur serwerów (Heruko, Google App Engine) co pozwala na elastyczniejsze kształtowanie kosztów hostingu (chmury pozwalają na czasowe zwiększanie/zmniejszanie potrzebnych zasobów w określonych godzinach dnia). Jeśli trzeba można błyskawicznie dodać 1000 serwerów na jakąś godzine szczególnie wysokiego ruchu, a zmniejszyć do paru w godzinach nocnych, czy wtedy kiedy statystyki pokazują mniejszy ruch na serwerze.

(IMG:http://zabiello.com/images/php.jpg)

Musiałbyś naprawdę bardzo nieoptymalnie pisać w C/C++ i naprawdę bardzo dobrze w innych by się ich wydajność zbliżyła do siebie.

Java ma o wiele wydajniejsze zarządzanie pamięcią od C++. Dynamiczna kompilacja może też więcej niż statyczna. Poza tym, nie sądzę aby taki Smalltalk czy Objective-C jakoś znacząco odstawał od C++. Nie słyszałem aby ktoś pokusił się o napisanie obiektowej bazy danych w C++ a w Smalltalku pod ponad 20 lat używane są takie bazy komercyjnie przez świat biznesu. O Javie nie wspomnę.

* Java vs. C benchmark
* Java vs. C benchmark #2: JET, harmony and GCJ

Ten post edytował hipertracker 6.09.2010, 20:32:54

[SHiP]

Ogólnie się zgadzam ale nie ze wszystkim

większą elastyczność na zmienny humor klienta, który sam do końca nie jest pewien tego, jak ma wyglądać końcowy produkt. Wbrew pozorom to jest dosyć częsta sytuacja, że klient chce wprowadzać jakieś zmiany do poczatkowych założeń. A Rails jest stworzony do pracy agile.

Co ma piernik do wiatraka? Agile to metodologia pracy zespołowej. Agile można również stosować w przypadku programistów php a nawet murarzy na budowie.

mniejsze koszty utrzymania kodu, bo kod jest czytelniejszy, i jest go po prostu mniej
łatwiejsze nanoszenie zmian w działającej funkcjonalności lub dodawanie nowej (trochę wynika z pkt. 2 ale też z tego na ile modularnie pisana jest aplikacja)

Kod php również jest czytelny i nanoszenie poprawek jest proste. Argument bez sensu

większą odporność na awarie i błędy, możliwość automatycznego wyłapywania wszelkich nie obsłużonych wyjątków i wysyłanie ich natychmiast do osób, które się kodem opiekują. Dzięki temu błędy mogą być wyłapywane i naprawiane szybciej oszczędzając klientowi wstydu ("patrzcie jak im strona leży!, hahaha, hehehe"). W PHP można co najwyżej czekać aż jakiś wkurzony klient zgłosi błąd, którego nie wyłapali programiści. Ewentualnie pozostaje regularne przeczesywanie logów długo po tym jak błąd wystąpił. Mina klientów którzy, po kolejnym pehapowym fatal errorze, zobaczyli na ekranie biały ekran - bezcenna! (IMG:style_emoticons/default/laugh.gif)

Tutaj widać, że nie programujesz w php (IMG:style_emoticons/default/winksmiley.jpg) . Jedynym błędem jakiego nie da się wychwycić jest "Parse Error" czyli błąd składni. Wszystko inne można wychwycić. Fakt, że php nie ma tak rozbudowanej i restrykcyjnej struktury wyjątków jak np. Java, lecz to nie znaczy, że nie da się dobrze napisać aplikacji.


Reszty nie używałem więc nie wiem.

[hipertracker]

Tutaj widać, że nie programujesz w php (IMG:style_emoticons/default/winksmiley.jpg) . Jedynym błędem jakiego nie da się wychwycić jest "Parse Error" czyli błąd składni. Wszystko inne można wychwycić. Fakt, że php nie ma tak rozbudowanej i restrykcyjnej struktury wyjątków jak np. Java, lecz to nie znaczy, że nie da się dobrze napisać aplikacji.

No to napisz mi "miszczu" kod PHP, który potrafi przechwycić i obsłużyć wywołanie metody na nullu http://gist.github.com/127274

[SHiP]

Czemu od razu miszczu?

[PHP] pobierz, plaintext 
<?php
 
function shutdown() {
 
	if(($error = error_get_last())) {
		ob_clean();
		echo('Blad: '.$error['message']);
	}
}
 
register_shutdown_function('shutdown');
 
function jakis_kod() { return null; }
 
    $obj = jakis_kod();
    $obj->not_existing();
 
?>
[PHP] pobierz, plaintext 

Muszę o 5 wstać więc tak pisane na szybkiego.

[Cysiaczek]

@hipertracker - to, co opisałeś jako zalety używania Ruby to prawda, która dotyczy także (i między innymi) PHP (co do chmur i spięcia z Javą się nie wypowiadam)
Czytam ten temat i nie mogę wyjść z podziwu nad tym, jak można doprowadzić do perfekcji stosowanie chwytów erystycznych (w tym negatywnym znaczeniu). Marketingowcy Ruby i Rails opanowali to naprawdę znakomicie. Przypominają mi się te filmiki, w których porównuje się język do frameworka. Może i są one zabawne, ale jednocześnie żałosne merytorycznie.
Cały problem jaki ma społeczność skupiona przy Ruby i Rails to pogardliwa ewangelizacja. Zdaję sobie sprawę, że to mocne słowa ale gdzie nie spojrzę, tam widzę analogiczne do Twoich argumentacje i tylko takie zdanie zdążyłem sobie wyrobić. Sprawiają (te argumentacje) wrażenie jakby Ruby i Rails były czymś nowym, niesamowitym, superwydajnym i dającym nieograniczone możliwości... i nikt i nic tego nigdy nie zapewni, tylko nasza technologia, bo jest najlepsza i/bo najnajsza. To wygląda trochę tak, jakbyście (Wy, jako społeczność) uważali programistów PHP za ludzi innej, gorszej kategorii - nieuświadomionych, bez wiedzy, bez doświadczenia i w ogóle głupich. Może trochę przesadzam, może nie wszyscy tak uważają, ale tutaj znów podeprę się moim subiektywnym wrażeniem, które do takich a nie innych wniosków prowadzi - spora część z Was, tak właśnie sądzi.

Prowadzi takie wrażenie do ciekawych zachowań - otóż spowodowało, że zarzuciłem chęć nauki Rubyego i Rails, bo atmosfera mi się nie spodobała. Podobnie jak uczynili fanboje Appla ( pozdrawiam irc.php.pl :* ) z moim podejściem do produktów tej firmy, tak właśnie podobne topiki do tego, skutecznie zniechęciły mnie do tego języka. Z tego co mi wiadomo, nie tylko mnie.

Reasumując Twoje posty - uważam, że czasem piszesz mądrze, czasem bzdury, ale sposób w jaki to robisz - zniechęca.

Pozdrawiam

[thek]

Hipertracker to mam zasadnicze pytanie dla przykładu z obiektowymi bazami danych: Widziałeś jak w standardzie wygląda dowiązanie dla obiektowych baz danych dla C++? Kijowo. Standard takich baz niby istnieje ale dlatego obiektowe bazy "wtopiły" bo przez grube lata nie były ustandaryzowane i przegrały wojnę z RDBMS. Standard jest chyba już od 2000 roku w wersji 3.0, ale wcześniej to była bieda z nędzą i tylko w sumie 3 języki mają jakieś dowiązania: C++, Smalltalk i Java. Spośród nich C++ ma najgorsze. Dodatkowo każdy z tych (i nie tylko tych) języków pozwala na samodzielne napisanie takiej bazy w zależności od wymagań projektu, więc to nieco dziwne by uznać ów przykład za wadę/wyższość jednego języka nad innym.

Teraz nieco na punkty odpowiem...
1) elastyczność, elastycznością, ale jeśli klient zmienia Ci nie coś z modułu ale wymaga zmian w szkielecie aplikacji to i tak jesteś z ręką w nocniku. I tutaj nawet najbardziej zajebisty język świata nie pomoże. A i takie zmiany nieraz bywają. Dobrze napisany i przemyślany projekt jest do wdrożenia w dowolnym języku. Czy będzie to php czy ruby - sprawa drugorzędna. Błędy na poziomie projektowania aplikacji zemszczą się, nieważne w jakim języku pracujesz.
2) nieco haczy o punkt pierwszy. Źle zaprojektowana aplikacja i trzymanie złych nawyków, złych wzorców rozłoży każdy projekt i sprawi, że będzie nieczytelny do granic możliwości. Ładnie uporządkowany, będzie czytelny i łatwy do konserwacji oraz modyfikacji niezależnie od użytego języka czy podejścia (strukturalny dobrze zrobiony nie jest wcale gorszy do konserwacji niż obiektowy). Może być, że jeden z nich zrobi jedną funkcją to co inny 3-4 bardziej elementarnymi, ale to jedyna poważniejsza różnica tak naprawdę.
3) sam zauważyłeś, że punkt 3 wynika z 2. Nadal Twoje prawdy są bardzo ogólne i pasują do dowolnego języka programowania. Nie tylko Ruby'ego.
4) tutaj plus dla języków, które mają pewne mechanizmy wbudowane. Nie wiem jak w Rubym to jest zrobione, ale zapewne nie jest to "out of box" i sam to musisz oprogramować by działało jak opisujesz. Jeśli tak jest jak piszę, to przynajmniej część języków także potrafi to sobie zaimplementować. Znając życie polecimy z użyciem debug_backtrace w php ;)
5) Biblioteki/aplikacje tego typu o jakich wspominasz (konkretnie do testów). Niewątpliwy plus.
6) Nie ma takiej aplikacji, która klienta nietechnicznego by "nauczyła posługiwać się" informatycznymi terminami lub przetworzyła język naturalny na specyfikację techniczną. Są tylko tego mniej lub bardziej udane próby. Z reguły mniej. Klient i tak może Ci przez 10 spotkań mówić, że chce tak i tak, by na 11 stwierdzić, że jednak miało być inaczej i inaczej to on tłumaczył, nazywał, a Ty go po prostu źle zrozumiałeś. Najczęściej są to zmiany dodawane na szybko, bo się klientowi coś "uwidziało", a przecież "klient ma zawsze rację" ;)
7) szybkość jest w dużej mierze wynikiem doboru testów i kryteriów oceny. Szybkość jest wynikiem walki z zasobożernością. Chcesz mieć system szybki? Pakuj do RAMu najczęściej używane rzeczy i masz już przyrost wydajności. Ale licz się z tym, że jeśli przesadzisz, efekt będzie odwrotny do zamierzonego, a i serwer może nie wytrzymać obciążenia. Tak więc prawdziwie miarodajne testy pokrywały by wiele aspektów działania strony/serwisu/portalu/aplikacji, począwszy od obsługi plików, poprzez bazy danych, generowanie grafiki, czy dokumentów, a całość pod kątem nie tylko szybkości, ale i zużywanych zasobów przy takiej samej maszynie testowej. Tylko to ma jakikolwiek sens by wyłapać "atrakcyjność" danej platformy. Niektóre nie nadają się na małe serwery, inne tylko na takich czują się dobrze i mają jedyny sens z racji zastosowanych rozwiązań. Przykład? Systemy/aplikacje embedded. Z założenia pracują w innych warunkach niż normalne i inaczej rozwiązuje się w nich pewne problemy. Tu nie zawsze liczy się czas, ale konieczność choćby pracy w ograniczonej i nierozszerzalnej pamięci. Tak lubisz jRuby ale masz zapewne świadomość, że im mniej pamięci tym to rozwiązanie zaczyna radzić sobie gorzej i GC tutaj zaczyna po prostu aplikację zajeżdżać, bo jest wywoływany bardzo często. Nieraz zbyt często. Tutaj już optymalizacje JVM niewiele pomogą. GC zaczyna stawać kością w gardle, choć i tak zachowa się ładniej niż PHP, który po prostu wywali się na braku pamięci ;)
8) znowu mam wrażenie, że odnosisz się głównie do możliwości jRuby zamiast samego Ruby'ego czy też RoR ;) Bardziej to przypomina w takiej sytuacji rozmowę o pisaniu GUI w C++. Są biblioteki pokroju Qt czy wxWidgets i opisywanie ich możliwości, nie wspominając że "goły" C++ bez bibliotek dodatkowych specjalnie do tworzenia i obsługi GUI napisanych kiepsko się nadaje. A przynajmniej ja takie wrażenie odnoszę czytając Twoje posty. Gdy pisaliśmy o języku nie wiedziałem bowiem nigdy gdzie kończy się opis możliwości samego Ruby'ego, a gdzie wkraczałeś na tereny zarezerwowane dla jRuby. Jedynie wstawki niektore zapalały mi lampkę "Kurka... To już chyba w Javie kiedyś widziałem".
9) to samo co punkt 8... Nie wiedzieć czemu mam wrażenie, że gdybyś miał punkt 10, znowu byś rzucił tekstem o Maglevie ;) Nie zrozum mnie źle, ale patrzę na to co piszesz i widzę, że masz duża wiedzę (najprawdopodobniej większą niż moja), ale jednocześnie zamknąłeś się w określonych plusach i poza nie raczej nie wychodzisz. Powiedziałbym, że są nieco jak mantra powtarzane w różnym natężeniu i z użyciem nieco innych słów. Jak widzisz, ja też potrafię pisać "elaboraty", więc na mnie ilość tekstu nie sprawia żadnego wrażenia ;) Już i tak część osób się śmieje, że z moich postów tu na forum bym mógł książkę napisać.

Co do załączonych linków autor zrobił to, co ja już wypunktowałem: JVM dano czas na "rozgrzewkę" zanim przystąpiono do testów, a więc dynamiczny kompilator zoptymalizował się pod maszynę produkcyjną. Oczywiście patrząc na same wykresy nie dowiemy się o tym i potrafią one niektórych przekonać, że jednak Java jest bardzo szybka od razu. C++ nie potrzebuje takich przygotowań. Rusza z odpowiednio ustawionymi parametrami i jego wyniki są powtarzalne. JVM z każdym testem, do pewnego momentu, będzie coraz szybsza. Gdyby rozgrzewki zabrakło wyniki byłyby nieco inne. W dynamicznym środowisku webowym, gdzie mogą następować przełączania serwerów, częste zmiany osłabiają znaczenie dynamicznej kompilacji.

[hipertracker]

register_shutdown_function('shutdown');

No dobrze, zwracam honor. Jednak coś w końcu dodali. Dziwne jak mało ludzi jest tego świadomych. W dosyć dużej firmie pehapowej w jakiej miałem okazję pracować, oni wciąż bawili się w analizę logów przekonani, że nie ma możliwości napisania kodu ktory by jakoś wyłapywał takie cięższe błędy i wysyłał informację o tym w inne miejsce.

Narzekając, mogę dodać, że znowu coś dodali, ale byle jak. Tą metodą nie da się wykonać przekierowania na stronę wyświetlającą ładnie sformatowaną informację dla usera. Musisz więc w ten handler upchnąć całą odpowiedź.

Czytam ten temat i nie mogę wyjść z podziwu nad tym, jak można doprowadzić do perfekcji stosowanie chwytów erystycznych (w tym negatywnym znaczeniu). Marketingowcy Ruby i Rails opanowali to naprawdę znakomicie.

Jaki marketing, jaka erystyka? Pleciesz coś bez sensu zamiast napisać coś merytorycznego.

tylko w sumie 3 języki mają jakieś dowiązania: C++, Smalltalk i Java. Spośród nich C++ ma najgorsze. Dodatkowo każdy z tych (i nie tylko tych) języków pozwala na samodzielne napisanie takiej bazy w zależności od wymagań projektu, więc to nieco dziwne by uznać ów przykład za wadę/wyższość jednego języka nad innym.

Wyższością języka zgodnego z JVM jest możliwość podpięcia się do tych wszystkich rzeczy. PHP tego nie potrafi, bo nie ma dobrej implementacji na JVM.

Źle zaprojektowana aplikacja i trzymanie złych nawyków, złych wzorców rozłoży każdy projekt i sprawi, że będzie nieczytelny do granic możliwości.

Owszem, jednak jakimś dziwnym zbiegiem okoliczności złe praktyki takie jak spaghetti code są najczęściej domeną pehapowców. Każdy javowcy uczy się wzorców projektowych, railsowcy są prowadzeni za rękę przez swój framework, więc omijają parę problemów trochę w sposób nieświadomy. Rails

tutaj plus dla języków, które mają pewne mechanizmy wbudowane. Nie wiem jak w Rubym to jest zrobione, ale zapewne nie jest to "out of box" i sam to musisz oprogramować by działało jak opisujesz.

W Django i web2py to jest dokładnie out of box. W Rails nie, ale łatwo to dodać. W najproszczej implementacji wystarczy założyć pułapkę na wszystkie wyjątki i już. W Ruby nie ma kategorii fatal errorów (no chyba że błąd składni, ale taki kod się po prostu w ogóle nie uruchomi). Wszelkie błędy są spójnie zgłaszane za pomocą systemu wyjątków. Zatem można je obsłużyć w jednolity, prosty sposób.

[RUBY] pobierz, plaintext 
begin
  # jakiś kod co się zwalił
rescue
  # mogę obsłużyć dowolny wyjątek
  # wysłać maila, przekierować na inną stronę, itp
ensure
  # tu zawsze przejmę sterowanie bez względy na to czy był wyjątek, czy nie
  # np. mogę upewnić się że zostanie zamknięty plik, albo połączenie z bazą
end
[RUBY] pobierz, plaintext 

W PHP natomiast, mimo wprowadzenia obsługi wyjątków, funkcje wbudowane w ogóle nie są tym objęte. To bardzo komplikuje wyłapywanie tych błędów. Skoro dodali wyjątki to powinni nimi objąć także wszystkie funkcje wbudowane. A dla wstecznej kompartybilności dodali by jakaś flagę dla ini_set'a i już. Proste?

Nie ma takiej aplikacji, która klienta nietechnicznego by "nauczyła posługiwać się" informatycznymi terminami lub przetworzyła język naturalny na specyfikację techniczną. Są tylko tego mniej lub bardziej udane próby.

Akurat Cucumber to dosyć udana próba i aktualnie główny sposób pisania specs dla Ruby. Na dodatek obsługuje nie tylko jęz. angielski, ale także inne języki narodowe. Wyobraź sobie że ten poniższy kod to jest nie jakaś beletrystyka, ale dokładnie kod testu, tak się pisze testy behawioralne w Ruby. I jeśli ktoś sobie życzy, mogą być po polsku, bo nie każdy klient musi znać angielski. Przykład za http://github.com/aslakhellesoy/cucumber/t...18n/pl/features

Kod

# language: pl
Właściwość: Dodawanie
  W celu uniknięcia głupich błędów
  Jako matematyczny idiota
  Chcę sprawdzić wartość sumy dwóch liczb

  Szablon scenariusza: Dodaj dwie liczby
    Zakładając wprowadzenie do kalkulatora liczby <liczba_1>
    Oraz wprowadzenie do kalkulatora liczby <liczba_2>
    Jeżeli nacisnę <przycisk>
    Wtedy rezultat <wynik> wyświetli się na ekranie

  Przykłady:
    | liczba_1 | liczba_2 | przycisk | wynik  |
    | 20       | 30       | dodaj    | 50     |
    | 2        | 5        | dodaj    | 7      |
    | 0        | 40       | dodaj    | 40     |

Właściwość: Dzielenie
  W celu uniknięcia głupich błędów
  Kasjer musi znać się na ułamkach

  Scenariusz: Zwykłe liczby
    Zakładając wprowadzenie do kalkulatora liczby 3
    Oraz wprowadzenie do kalkulatora liczby 2
    Jeżeli nacisnę podziel
    Wtedy rezultat 1.5 wyświetli się na ekranie

A tu jest kod Ruby'ego który powyższy DSL przetwarza:

[RUBY] pobierz, plaintext 
# encoding: utf-8
begin require 'rspec/expectations'; rescue LoadError; require 'spec/expectations'; end
require 'cucumber/formatter/unicode'
$:.unshift(File.dirname(__FILE__) + '/../../lib') 
require 'calculator'
 
Before do
  @calc = Calculator.new
end
 
After do
end
 
Zakładając /wprowadzenie do kalkulatora liczby (\d+)/ do |n|
  @calc.push n.to_i
end
 
Jeżeli /nacisnę (\w+)/ do |op|
  @result = @calc.send op
end
 
Wtedy /rezultat (.*) wyświetli się na ekranie/ do |result|
  @result.should == result.to_f
end
[RUBY] pobierz, plaintext 

W dynamicznym środowisku webowym, gdzie mogą następować przełączania serwerów, częste zmiany osłabiają znaczenie dynamicznej kompilacji.

Jakie przełączanie? Chyba masz na myśli wyłączanie. To jakiś nonsens. Serwer jest po to aby uruchomiony wykonywał obsługę wielu requestów a nie restartował się przy każdym. Stąd JVM idealnie nadaje się do zastosowań serwerowych, do desktopowych trochę gorzej.

Ten post edytował hipertracker 7.09.2010, 02:08:49

[everth]

Dyskusja typu: moje jest fajne bo a),(IMG:style_emoticons/default/cool.gif) ,c) - wcale nie, moje jeszcze lepsze bo e), f), g) itd. To ja wrzucę swoje trzy grosze.

Pisze się po prostu w czymś co się zna - nie mam na czasu na poznawanie tajemnic i trików RoR czy jakiegokolwiek innego frameworku/języka gdy jestem w pracy. Po pracy po prostu mi się nie chce. Ale z ekonomicznego punktu widzenia sprawa jest trochę mniej skomplikowana.

Np. prowadząc firmę lepiej nastawiać się na popularny język. Dlaczego? Ponieważ łatwiej o pracowników za grosze (vide 'biały murzyn'). Wbrew pozorom łatwiej takiego pracownika wyszkolić by pisał w miarę sensowny kod, niż bulić 2xtyle za gościa znającego bardziej egzotyczny język. Tutaj jakość przechodzi w ilość, a i tak się kalkuluje (o ile firma jest dobrze zarządzana).

Inaczej wygląda sprawa gdy pracujemy na siebie. Tutaj wolałbym napisać projekt w czymś innym niż PeHaP choćby dlatego że to wiąże silniej klienta ze mną. Dając mu ten projekt w PHP, klient może później znaleźć tysiące ofert które rozbudują mu go nawet za darmo (IMG:style_emoticons/default/winksmiley.jpg) . Jeśli stworzę coś choćby w Django to automatycznie ograniczam mu możliwości - łatwiej wróci do mnie.

Pewnie dlatego większe strony ciągle żyłują PHPa (poza historycznymi zaszłościami) - po prostu programiści są tańsi

Tą metodą nie da się wykonać przekierowania na stronę wyświetlającą ładnie sformatowaną informację dla usera. Musisz więc w ten handler upchnąć całą odpowiedź.

Że co?

[Cysiaczek]

Jaki marketing, jaka erystyka? Pleciesz coś bez sensu zamiast napisać coś merytorycznego.

Znów chwyt - ad hominem, choć obliczony na ad audience, wiec nie będę się spierał.

Piję do tego, że ewangelizujesz oczerniając php, odmawiając mu zalet i jednocześnie przypisujesz zalety promowanej technologii, zalety które można przypisać również językowi PHP i technologiom współpracującym - punkty 1-8

Przypomnę Ci fragment wcześniejszego Twojego posta

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

Skoro SHiP udowodnił Ci, że jest inaczej, zwróciłeś honor, to czy nadal uważasz, że php nie nadaje się do poważnych zastosowań? Jeśli bowiem się nadaje, to rozmawiamy o wyższości Świąt Wielkiej Nocy nad Świętami Bożego Narodzenia, a cała reszta to marketing.

Powód edycji: [Cysiaczek]: poprawiłem bbcode