Forum PHP.pl

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ć (IMG:style_emoticons/default/winksmiley.jpg) ). Miałbym jednak problem by jednoznacznie się źle wypowiedzieć o JVM, które jest faktycznie bardzo dobrym środowiskiem na którym bazować mogą inne języki. Dlatego właśnie chciałbym oddzielić opisywanie zalet języka i jego frameworków od środowiska w jakim są uruchamiane. Równie dobrze moglibyśmy rzucać przykładowo choćby Matlabem. Resztę dokończę później.

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

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

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ć. (IMG:style_emoticons/default/winksmiley.jpg) Sądzę, że los PHP jest policzony i czas jego świetności już nigdy nie wróci. Każdy bardziej zaawansowany programista, z pewnością będzie wolał wybrać mniej ograniczającą (i wkurzającą) technologię. I nie musi to być Ruby, więc proszę mi nie pleść nonensów o jakimś zmasowanym marketingu Ruby'ego.

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

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.

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

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

Bardziej ciekawe jest zestawienie frustracji wokół obu technologii:


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


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

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 (IMG:style_emoticons/default/smile.gif) . Jaką moc mają Twoje argumenty w momencie gdy przychodzi do mnie klient i "rzuca" na stół specyfikację. Jakie realne korzyści przyniesie klientowi wybranie przeze mnie pracy z Rubym?

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

@wookieb: +1

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

Co do pytania:


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

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

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


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