Forum PHP.pl

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



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.

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

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.




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)

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

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.


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

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.

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)



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

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.

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

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)

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.

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)


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

Ogólnie się zgadzam ale nie ze wszystkim

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.



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


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.

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

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.

@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

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.

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



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




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.



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



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?



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


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 

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

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


Że co?

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


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.