Ktos napisał(a)
Krolik, ale moment, są dobrzy programiści PHP i są źli programiści PHP, są dobre zasady pisania w PHP i są złe. Ale cholernie mało jest ludzi, którzy umieją takie coś zrobić.
Takich ludzi jest zapewne więcej, ale zwykle nie programują w PHP, chyba że muszą.
Ruby On Rails jest owszem, fajne, a czy widziałeś jak sprawuje się w zastosowaniach pod obciążeniem? Średnio.
PHP też średnio. Wydajnosć obu interpreterów jest podobna. Kilkadziesiąt razy mniejsza niż rozpędzona Java/.NET. Ale nie jest to jakiś wielki problem bo zwykle całą robotę odwala baza danych - napisana w C/C++.
A czy widziałeś powstałe na RoRowej modzie na MVC frameworki dla PHP w rodzaju PHP on Trax, CodeIgnitera czy świetnego Cake?
Widziałem i doceniam, że sporo zmienia się na lepsze. Problem w tym, że bardzo daleko im do np. Spring + Tapestry + Hibernate, zarówno pod względem funkcjonalności jak i szybkości działania. Ciekawe jak realizują buforowanie obiektów w pamięci POMIĘDZY wywołaniami http, kiedy skrypt PHP żyje na czas jednego wywołania? Poza tym im więcej warstw aplikacji jest napisane w PHP (jako framework), tym wolniej to wszystko chodzi. Zaraz okaże się, że jest potrzebny JIT oraz dobry garbage collector, dorzucą jeszcze namespace'y i... wyjdzie z tego już prawie Java :|
(nie bierzemy pod uwagę zabezpieczeń!)
Czemu? [diabel]
Aczkolwiek chyba zeszliśmy na Off-Topic mały.
No tak, to dyskusja bardziej do działu inżynieria oprogramowania.
Chciałem tylko pokazać, że istnieją też inne drogi, a kwestia wyboru nie jest taka prosta, jak się autorowi posta wydaje.
Dlatego wracając do oryginalnego tematu, uważam, że napisanie dobrej wyszukiwarki połączeń dla kilkunastu linii autobusowych przecinających się pewnie w kilku punktach nie jest tak trywialne jak wyszukiwanie listy aukcji należących do usera Z, czy kończących się o zadanej godzinie albo wyszukanie produktu po słowach kluczowych. Nie da się tego zrobić jednym czy kilkoma zapytaniami SQL. Zagadnienie wymaga całkiem niezłego kawałka logiki biznesowej (Dijkstra, A*?) działającego na obiektach z bazy danych. Dodatkowym problemem jest to, że znalezienie tego jednego połączenia może pociągać konieczność odczytu sporej części informacji z bazy. Łatwej jest to napisać mając silny i szybki język (C#/Java) z dobrym frameworkiem O/R załatwiającym sprawy buforowania obiektów (cache) i optymalizującym zapytania przez np. outer-join-fetching, niż kodując to wszystko na ręcznych SQLach, jak to zwykle bywa w PHP. Nie mówiąc o tym, że w PHP buforowanie obiektów między zapytaniami bedzie dużym problemem (a buforowanie stron przwez np. squida nic nie da, bo raczej każdy będzie szukał czegos innego).