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.

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

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.

@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

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

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


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.


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.

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

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ą

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.

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

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

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

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.

nie ma to jak dobrze uargumentowana opinia dotycząca tematu dyskusji

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"

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

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

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

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 .

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

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ł

@dr_bonzo: podoba mi się to rozwiązanie z Ruby. Mądrze to ktoś wymyślił .

Jesli chodzi o programistów do zmiany kodu parsera to jest to chyba oczywiste . 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ł.

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



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.



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.



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?



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.




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.



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.



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

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.

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

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


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.


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

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

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.

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

Eee tam, zaraz powiesz, że disco-polo jest wyznacznikiem polskiej kultury muzycznej.

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

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.

@hipertracker - prowadzisz iście akademickie wywody. Masz do tego oczywiście pełne prawo, aczkolwiek poproszę Cię o analizę pod kątem biznesowym . 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" .

@wookieb: +1

@Daiquiri: dlaczego oceniasz przez pryzmat jednego przypadku? 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:


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

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


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 . Mnie interesuje aspekt praktyczny - nie teoretyczny.

Nie chodzi mi o ocenę osoby hipertrackera, ale o ocenę marketingu RoR (czy np. community Rubiego) po tym co pisze hipertracker .



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 .

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?

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 .

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

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ć



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

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

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

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

Dyskusja typu: moje jest fajne bo a),,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 . 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.