Na początek prośba do moderatorów by rozdzielić wątek na dwa.

Osobiście jestem w trakcie "przesiadki" na JEE i w żadnym wypadku nie można moich wypowiedzi traktować tutaj jako wypowiedzi kogoś kto ma z tą platformą spore obycie.
Prosiłeś o wypisanie wad i zalet tej platformy względem PHP tak więc i takie zestawienie znajdziesz poniżej, miej jednak na uwadze, że jak już wspomniałem JEE (a nawet i wiele elementów JSE) nie jest mi tak dobrze znaną technologią jak PHP, które znam od dobrych kilku lat. Na pewno z wielu wad/błędnych rozwiązań nie zdaję sobie nawet sprawy (brak wystarczającego doświadczenia), a jest ich na pewno cała masa - jak w każdym języku/platformie, szczególnie takiej która swoje początki miała w połowie lat 90 i dbała o wsteczną kompatybilność (to akurat zaleta) kosztem pewnych decyzji/rozwiązań (np. typy generyczne będące na dobrą sprawę jedynie lukrem składniowym).

Subiektywna lista:
Język:

1. Java jest statycznie i silnie typowanym językiem co znacznie ułatwia pracę poprzez: znaczne poprawienie czytelności kodu; ułatwienie dokumentacji kodu; uniemożliwia mieszanie typami (popatrz chociażby na genialny sposób informowania o nieznalezieniu podciągu przez strpos - zamiast zwrócić "-1" zwracają "false", które jest w większości przypadków traktowane jak "0") nie wspominając już o wszelkiego rodzaju narzędziach typu IDE, które po prostu mogą w ogóle działać.
2. Idiotoodporność PHP, która najbardziej krzywdzi właśnie początkujących, a bardziej doświadczonym sprawia jedynie problemy. Użyłeś nieistniejącej zmiennej/właśćwiości obiektu/elementu tablicy? Żaden problem, uznamy, że podano wartość null/false/0. Podałeś za dużo argumentów dla funkcji? Żaden problem, uznamy że tych nadmiarowych w ogóle nie ma. Podzieliłeś przez zero? Wszechświat się zapada, a zmienna przyjmuje boolean'owski fałsz i jedziemy dalej. Takich zachowań jest znacznie więcej i w najmniejszym stopniu nie są one pomocne.
3. Deweloperzy PHP nie myślą i nie testują nowych elementów języka:
   • Pojawiły się wyjątki, a nie istniały praktycznie żadne predefiniowane, żadnych reguł co do ich użycia, żadnych elementów składni informujących o tym, że dany wyjątek może się w ogóle pojawić itd.
   • Wprowadzili domknięcia, ale nie dali już możliwości zdefiniowania czy domknięcie przekazane w argumencie dla funkcji (np. jako callback) ma mieć jeden, dwa czy może cztery argumenty? O ich typach nie wspominając.
   • Wprowadzają kolejne klasy do SPL-a (bardzo dobrze), ale wymyślili sobie, że jedna z nich - bodajże MessageFormatter - będzie mogło zwrócić NULL-a w wyrażeniu new MessageFormatter(..); (tak dla jasności jest to sprzeczne z "specyfikacją" języka.
   • Wprowadzili przestrzenie nazw, ale nie narzucili żadnego sposobu ich nazywania (zrobił to dopiero PSR-0, który nie jest jednak zawsze przestrzegany)
4. Brak porządnego wsparcia dla Unikodu w PHP, ogromny burdel w bibliotece standardowej, [u]brak nowej, równoległej do istniejącej biblioteki standardowej[/i]
5. Spore braki w elementach/strukturach języka: w PHP nie stworzysz sobie nie-publicznej/lokalnej klasy gdy potrzebujesz jej jedynie w obrębie innej klasy/przestrzeni nazw przez co cały projekt musi być zawalony jakimiś nieistotnymi klasami; nie stworzysz sobie prywatnej stałej w klasie; nie stworzysz typu wyliczeniowego; nie masz dostępu do adnotacji, anonimowych instancji itp.

Platforma:

1. JEE jak sama nazwa wskazuje jest zdecydowanie bardziej "enterprise'owa". To dostęp do całej masy świetnych narzędzi, trzymanie się dobrych, utartych, a przede wszystkim sprawdzonych standardów co do których ma się pewność, że w ciągu najbliższych lat nawet jeżeli zostaną zamienione innymi nadal będą dobrze wspierane. Za JEE stoi cała masa korporacji co bardzo dobrze wpływa na jej stabilność. W tym zestawieniu PHP wygląda jak stojący na glinianych nogach, [brak mi weny ;] - kaleka?]. I bynajmniej nie jest to jak pojedynek Dawida i Goliata, tu ten ostatni jednak wygrywa.
2. W PHP na dobrą sprawę na start nie dostajesz kompletnie nic. Żadnych mechanizmów mogących realnie wspierać cokolwiek. Jak już napisałem na całe szczęście kilka lat temu pojawienie się FW dla PHP uratowało je przed kompletnym porzuceniem. A JEE? JSP/JSF, EJB, CDI, JPA, JTA, JMS i jeszcze wiele, wiele innych 3-4 literowych akronimów.
3. Oczywiście w/w to jedynie specyfikacje i zestawy interfejsów... bo w Javie masz możliwość realnego wyboru implementacji. Nie jesteś ograniczony do jednego producenta.
4. Serwer aplikacji nie działa na zasadzie od żądania do żądania - to znacznie ułatwia pokonywanie ograniczeń protokołu HTTP oraz platformy klient-serwer. Masz rzeczywistą możliwość robienie dowolnych rzeczy na serwerze (bo nie ogranicza Cię ani środowisko uruchomieniowe dla języka, ani sam język bo Java jest po prostu szybka).

Tych punktów mogłoby tutaj być więcej. Ale PHP nie jest wcale jakimś niewyobrażalnym badziewiem. Jak każdy język ma spore możliwości, a w dobrych rękach można w nim stworzyć na prawdę świetne projekty.

Na sam poczatek tez prosilbym o wydzielenie tematu jesli kogos on interesuje.


Tez uwazam ze php nie jest az taki bee jednak wiele rzeczy sprawia ze debugowanie kodu jak i jego skalowalnosc nie jest wcale taka latwa.

Mi w php przeszkadza:

• 
  Brak silnej kontroli typow skoro ma juz dynamiczne typowanie to w czasie interpretacji kodu interpreter moglby sprawdzac typy danych a nie jak w php ze potem mozna dodawac string do int albo cos co ma byc int tak naprawde jest traktowane jako string albo odwrotnie.
• Tak jak wspomniales wsparcie dla Unicode(utf-8)
• Burdel w bibliotece standartowej
• brakuje mi tego zeby wszystko bylo obiektem i method chaining
• Brak stosowania wyjatkow w bibliotece standartowej i glupie zwracane handlerow lub true/false w przypadku funkcji zamiast wyjatkow
• nie przemyslane parametryzowanie(istnieje takie slowo?) funkcji/metod
• Glupi trend fw php na uzywanie CamelCase gdy php nie jest case sensitive(po czesci jest a po czesci nie absurd)

Jeszcze cos by sie znalazlo na pewno.


Tzn jak dokladnie dziala?Runtime?

Co do idiotoodpornosci zgadzam sie co najwyzej rzuci nam E_NOTICE i wsio.
Wedlug mnie zamiast dodawac bajery powinni przepisac na nowo cala biblioteke standartowa i caly jezyk na model objektowy.

prywatna stałą mozna sobie stworzyc w klasie za pomocą konstrukcji private static $stała = "costam". jednak jest to swojego rodzaju hack. Co prawda nie jest to stała, ale daje to mozliwosc przechowywania stałej klasowej.

do plusow skladni php mozna zaliczyc late static binding - static::. bardzo fajna rzecz ktorej raczej nie ma w innych językach.
jednak jak sie pomysli ilu fajnych rzeczy PHP nie ma a inne jez. maja, to włos sie jezy na glowie.

wszystko juz chlopaki napisaliscie, i to jest wszystko prawda niestety. Ja od siebie bym dorzucil brak standardowego class Loadera.
metoda __autoload powoduje ze autoloader w kazdym fw/projekcie dziala inaczej.
A ja mam np swoj wlasny autoloader ktory dziala na moim autorskim pomysle i ma strukture katalogow nie korzystajac z namespace ale nie ma tez dlugich nazw jak zend i co sie okazuje? Biblioteka PHPUnit nie jest w stanie odnalezc zaleznosci miedzy klasami i klasy nie chcą się ładować, i tego co juz napisalem nie moge testowac jednostkowo. Musze robic sztuczki typu wydzielenie kodu logicznego do innej klasy poza projektem, tam stestowac , i opakowac w obiekt juz nalezacy do projektu.

Wraz z wprowadzeniem namespacow (ktore sa troche nieudane - brak mozliwosci zaimportowania calej namespace - porazka. Bez aliasowania trzeba uzywac nazw typu orzech\myproject\mymodule\myclass() - jeszcze wieksza porazka.) mogli by wprowadzic standardowy class loader tak jak jest w javie i juz.

Jest jeszcze jeden zarzut mój do PHP : brak wielowątkowości, i wsparcia dla lockow/sekcji krytycznych
W sytuacji gdy kazdy proces PHP dziala w oddzielnym wątku, i nie ma mozliwosci zablokowac jednemu mozliwosci grzebania w pliku gdy zapisuje do niego drugi, język wiąże ci ręce. Musisz wszystko ładowac do bazy danych.
To samo sie tyczy memcache - brak locków w PHP powoduje ze zle napisana aplikacja korzystajaca z memcache po prostu sie zawiesi (w momencie gdy wpis sie przedawnia, wchodzi na raz x uzytkownikow na strone, i z powodu braku locków wszyscy na raz zaczynaja aktualizowac ten memcachowy wpis, leci x zapytan do bazy danych... itd itp). Ostatnio chcialem skorzystac z memcache - jak zobaczylem jakie problemy to powoduje to dalem sobie z nim spokój.
Niby są mechanizmy locków bazujące na tworzeniu plików ~lock, ale jaki to ma sens przy cachowaniu danych w memcache?
zreszta pliki lock nie sa niezawodne bo jesli php przelaczy sie na drugi wątek w momencie tworzenia tego pliczku to tez nam cuda wyjdą.

Celowo nie pisalem o flock poniewaz dziala w pelni tylko pod linuchem, a poza tym jest problem bo raz zalozonej blokady nie mozna zdjac po uplywie np 30 sekund wiec jesli zawiesi sie skrypt zapisujacy do pliku ktory sobie zablokowal to nigdy nie zostanie odblokowany.

IDE ktory jest naprawde dopracowany i w zasadzie jak dla mnie jedyny na rynku to phpStorm, to program wart kazdych pieniedzy.
Ma wszystko co potrzebne i co najwazniejsze - dziala. PHPUnit dziala. IntelliSense - dziala pieknie, lepiej niz w ecl. i netbeans.
Refaktoryzacje typu wydziel metode/stałą/zmienną - +50% do predkosci kodowania. Do tej pory myslalem ze w jezyku dynamicznym sie nie da tego zrobic, ale jednak sie da. Predkosc IntelliSense (podpowiadania metod) - dziala jak eclipse pod javą czyli bez zastanowienia.
eclipse php/netbeans potrzebuje sekunde - piec przy duzym projekcie. wiec akurat edytor php od jakigos czasu nie ustepuje innym językom. Jak ktos chce wydajnie kodowac i szanuje swoj czas, taki edytor to raczej must have, notatnik/PDT to zamiana koparki na łopatę.
Nawet brak głupiego rename refactoring w edytorze, powoduje z czasem zaciemnianie sensu kodu - komu sie chce recznie zmieniac iles tam nazw zmiennych w kodzie? a to normalne ze zmienne z czasem zmieniaja swoje znaczenie..

no i idiotyczne operatory. operator obiektowosci -> . Operator namespace \ . Operator konkatenacji . (kropka). To jedyny jezyk ktory znam, ktory nie stosuje kropki jako obiektowosci\namespace oraz plusa jako konkatenacji. Brak overloadingu - przeciazania metod.
To spore utrudnienie przynajmniej dla mnie bo ja czesto uzywam tego w innych językach.

PHP jest wolny - poprawnie napisana aplikacja moze dzialac wolniej (i to sporo) od napisanej byle jak. Te wszystkie iteratory, gettery, settery powoduja swoj narzut. Takie symfony2 np 300 ms generuje pusta strone w trybie produkcyjnym.
Odswiezenie pustej strony w asp.net to czas jakichs 10 ms? moze mniej nawet. W javie zapewne jest podobnie. Skompilowany jezyk dziala znacznie szybciej i lepiej sobie radzi z kodem napisanym z wzorcami projektowymi ktore zazwyczaj daja pewien niewielki narzut wydajnosciowy, ktory jednak sie kumuluje.

styl pisania symfony2 na pewno nie jest archaiczny powiedzialbym nawet ze jak na php jest nowoczesny

Marcio: aplikacja webowa w javie uruchamia sie raz i dziala sobie w tle na serverze, jako servlet (cos jak usługa, tak mi sie wydaje). Po prostu sobie dziala. Korzysc juz tutaj masz bardzo duża: konfiguracja zostaje wczytana tylko raz.

w momencie requestu na strone ta dzialajaca aplikacja odpowiada na niego. Mozesz przechowywac sesje uzytkownika w pamieci aplikacji, kod jest skompilowany do kodu bajtowego wiec dziala szybko... Niektore czesto wykorzystywane obiekty mozesz trzymac w puli (np pule polaczen z baza danych) i nie tworzyc ich od nowa za kazdym razem.

natomiast PHP za kazdym razem includuje wszystkie pliki, odczytuje konfiguracje (define są dosc wolne jak na zwykla deklaracje stałej, ok 200 stałych to u mnie 10 ms), oblicza tysiac durnych rzeczy i dopiero wykonuje te kilka linijek kodu ktore mamy w naszym kontrolerze. Prawda ze to marnotrastwo? Choc trzeba przyznac ze php ma o polowe mniejsze zuzycie pamieci niz java.

w najnowszej wersji net. frameworka wprowadzono typ zmiennej [b]dynamic[/d], jest to typ zmiennej oparty na takim typowaniu jak ma php. Jednoczesnie sam net.framework jest statyczny. Daje to nam mozliwosc uzywania typow tam gdzie jest potrzebna bezblednosc oraz uzywania zmiennych bez typów tam gdzie nam wygodniej. I tak to rowniez powinno dzialac w php. co prawda są typy proste w php5.4 jednak nim on sie upowszechni to wieki miną.

PSR-0 istnieje, BA! Nawet bez PSR-0 istniała konwencja nazewnictwa klas. Będziesz ganić język za programistów, którzy w nim programują?
Poza tym "standardowy" autoloader jest: Symfony ClassLoader, niedługo SplClassLoader a także loader z Composera.


Przeczytaj co to jest "bootstrap" w testach jednostkowych i tam zaimplementuj swojego autoloadera.


Przepraszam - "standardowy class loader" w javie? Nie znam Javy na tyle, ale class loader? W języku kompilowanym? WTF?


Kwestia znaków to kwestia umowna. Zobacz jak to wygląda w innych językach. To, że znasz troszkę jave, c++, javascript to wcale nie znaczy, że w innych językach jest tak samo.
Spójrz na Prologa. Spójrz na wszystkie inne języki, które umożliwiają przeciążanie operatorów (C++, Ruby, Scala itd) to widzisz, że może to wyglądać jeszcze gorzej.


APC Twoim przyjacielem.


To nie jest żadna nowość. Dynamiczne typowanie istnieje w wielu językach

ActionScript

Scala

js, php itd...
Fanboye JS jako jedną z wielu "zalet" javascriptu przedstawiają brak typowania. Co prawda są idiotami ale wbrew pozorom prawdziwy sens użycia dynamicznego typowania jest bardzo rzadki i często podyktowany błędem projektowym/upośledzeniem języka.


PHP nie miał być ani najszybszym, ani najładniejszym, ani najwydajniejszym językiem. Miał po prostu być łatwy dla początkujących programistów oraz ułatwiać wykonywanie prostych czynności z poziomu kodu i tak jest!
Ta dyskusja niestety nie przyniesie więcej niż stałe, niezmienne argumenty przewijające się od lat pomiędzy programistami klasy Enterprise a i parę głupich argumentów nie zabraknie choćby jak ten:

Błagam ludzie. Rozróżnijcie biblioteki od semantyki języka. To kompletnie 2 różne rzeczy.

IMHO moze tez to byc zaleta class loader powinien byc dostosowany pod projekt (wedlug mnie) a jakis standartowy loader by sie przydal do codziennego uzytku.


Jesli dobrze cie zrozumialem tez czesci aplikacji testuja poza nia by potem nie wyszly jakies krzaki ;]

Co do operatorow fakt to kwestia przyzwyczajenia jednak moze sprawic klopoty komos kto sie do nich przyzwyczai i wtedy skladnia inne jezyka moze wydawac sie imho dziwna(oczywiscie dziwna too jest ta od php)

Tak racja w php wszystko za kazdym zadaniem jest ladowane do pamieci i tu tez sie zgodze ze gdyby inaczej to bylo zaprojektowane php zyskal by na wydajnosci.


Tak spojrzalem na szybko i nie jest to taka strict konwencja, majac 3-4 sposoby na nazewnictwo klas i namespace'ow nie jest to juz takie uniwersalne.


Mysle ze chodzi mu o importowanie modulow/namespace'ow jak to sie ma w C# za pomoca using lub w python import...


Zgadzam sie tylko ta latwoscia i ich niedokladnoscia w php trzeba sie gimnastykowac


WTF?Gdzie wspomnialem o bibliotekach poprostu jakby wszystko bylo obiektem to by bylo i method chaining...

Nie. Tak jak jest teraz (czytaj porządne biblioteki używają standardu PSR-0 albo trzymają się starej konwencji gdzie _ w nazwie klasy to separator katalogu).
Inaczej nie ma standardu i jest syf. Co CI wtedy po projekcie gdzie chcesz użyć paru bibliotek a każda z nich ma inny autoloader. Poza tym pamiętaj, że wiele narzędzie "codziennego użytku" przepoczwarza się w biblioteki.



Ok... gdzie w schemacie

Widzisz "3-4 sposoby na nazewnictwo klas i namespace'ow" ?



Nie wspomniałeś bo nie rozróżniasz bibliotek od języka. Method chaining to pewien element zaprojektowania klasy/biblioteki. Nie jest to zależne od języka (tudzież jego składni).

Tak racja ale w php standartowa biblioteka tego nigdy nie zapewni bo jest napisana funkcyjnie oczywiscie mozna pisac wrapper'y i przepisywac wszystko na klasy o to mi chodzilo


OK, bazowalem sie na przykladach:

Nie wygladaja na jednoznaczne, chyba ze tak jak mowisz dostosowywuja sie do glownego "patternu"


EDIT:
Dobrze by bylo jesli ktos mogly zmienic nazwe tematu na inny tu nie moja o java vs php lecz o wszystkie platformy/jezyki ktore umozliwiaja tworzenia aplikacji web

Bawiąc się w kazuistyke... żadna z bibliotek phpowych nie jest napisana funkcyjnie.
Method chaining ma swoje wady i zalety. Raczej większość bibliotek nie będzie tego używała jeżeli nie ma ku temu jasnego przesłania co do użyteczności w wykorzystywaniu API.


To, że nazwa dostawcy może być przetłumaczona na ścieżke do katalogu nie czyni żadnej różnicy.
W standardzie jest jasno opisany jak ścieżki mają wyglądać. Nie ma tutaj żadnych wyjątków



As you wish...

Zly skrot myslowy mialem na mysle ze jest oparta o funkcje nie napisana funkcyjnie nmv przez co nic nie jest obiektem(zaden typ) i kod jest nieprzyjemny i dlugi.

Co do PSR-0 to teraz mnie oswieciles nie bylem zbyt uwazny jak czytalem znow dzieki !


Dziekuje !

Czy ktos z was ma stycznosc z innymi platformami: ruby(ror), python(django,pylons,pyramid,zope,plone), asp.net/mvc lub jakies rozwiazanie web scala/groovy?

Nie pogardzilbym tez zestawem za i przeciw php'owskich fw jesli ktos z was mial mozliwosc zapoznania sie z wiecej niz jednym rozwiazaniem.

Dokładnie. Jak komuś method chaining aż tak bardzo potrzebny, większego problemu nie widzę, pakuj wszystko w obiekty i niech każdy obiekt, zawiera metody które zwracają obiekt. Przykład: http://simplehtmldom.sourceforge.net/ jest biblioteka, jest i method chaining.



Bo niestety póki co nie istnieje jakaś sensowna maszyna wirtualna która by działała jak kompilator jit. Jak coś takiego wejdzie, to szybkość php znacznie się zwiększy, a pamięciożerność zmaleje. Coś tam podobno facebook kombinuje, no ale nie zagłębiałem się specjalnie w temat. Jak hostingi tylko wychwycą że taka maszyna wirtualna istnieje, i działa sprawnie, to zaczną instalować po to aby odciążyć swoje serwery i jeszcze więcej ludzi dowalić na jeden serwer.

Pisałem i pisze w ServerSide JavaScript - Jest ok, ale jeżeli ktoś nie lubi javascriptu samego w sobie plus obsługi wielu callbacków (nawet za pomocą przeróżnych bibliotek) to jego nie polubi.

Scala nie jest rozwiązaniem stricte Web. To po prostu nakładka językowa na Jave. I muszę przyznać - to najpiękniejszy i najbardziej uporządkowany język jaki kiedykolwiek widziałem. Wydajny , pojawia się na niego mnóstwo świetnych narzędzi. Niestety moja opinia bazuje na tym co czytam, troszkę poprogramowałem. Musiałbym totalnie przeskoczyć do świata Javy a następnie Scali aby moja opinia stała się bardziej obiektywna.

@by_ikar chodzi ci o HipHop?Tez mi sie cos o uczy obilo.


@wookieb mnie javascript wydaje sie taki dziwny zeby nie powiedziec "dziki"(egzotyczny?') i ma troche inny paradygmat niz ten do ktorego dotychczas jestem przyzwyczajony.

O Scali tez jak czytam gdzie jakis wpis obojetnie o czym by nie byl to wszyscy zachwycaja sie nia, coz ona ma w sobie ;p

@by_ikar nie jestem znawca ale czy istnieje mozliwosc napisania php dla javy cos takiego jak jython/jruby?

Jest tworzona m.in przez profesorów. Połączenie języków funkcyjnych, silnego typowania, prawdziwych traitsów i wiele innych przepotężnych mechanizmów (m.in pattern matching) umożliwiających tworzyć kod szybciej.
Sama książka http://www.amazon.com/Programming-Scala-Co...95&sr=8-1ma 852 z czego jej 50% to pisanie o ficzerach niespotykanych nigdzie indziej.

@wookieb: Tak, w Javie jest ClassLoader i jest jednym ze słabiej znanych i rozumianych elementów języka. Na prawdę można się mocno zdziwić czytając o całym mechanizmie ładowania klas. Gdybyś był zainteresowany: http://www.javaworld.com/javaworld/jw-10-1...10-indepth.html

@marcio: Serwer aplikacji (SA) traktuje każde żądanie jako nowy wątek, który (w przeciwieństwie do środowiska PHP) nie jest kompletnie odizolowany od innych. SA jest również odpowiedzialny za przygotowanie całego środowiska do pracy, co nie ogranicza się jedynie do nadania odpowiednich wartościom zmiennych $_SERVER/$_POST/$_GET. Patrząc z punktu PHP SA to już mocno rozbudowany FW.

hiphop od facebooka, jest czymś podobnym, właściwie to jest przerobiony hiphop. Bo w obecnej postaci niestety to jest masakra, więcej ograniczeń niż możliwości Ten hiphop od fb, "tłumaczy" kod php, na c/c++ i następnie kompiluje do kodu maszynowego. I trzeba to wszystko robić ręcznie i jest ogólnie z tym sporo babraniny. Maszyna wirtualna z kolei śledzi z miany w plikach i kompiluje taki kod php do kodu maszynowego i w przypadku zmiany w jakimś pliku dopiero wtedy na nowo jest kompilowany plik. Dzięki czemu, serwer serwuje skompilowany kod, którego nie musi w żaden sposób interpretować. Gdzieś tam pisali że zyski w oszczędności pamięci mogą sięgnąć nawet 90%, a czas wykonywania takiego skompilowanego kodu, może się zmniejszyć o około 60%. I najlepsze będzie to że nie będzie trzeba wówczas się niczego nowego uczyć, bo tak ma działać maszyna wirtualna. Z kolei hiphop obecnej postaci w jakiej jest udostępniony, niesie dość sporo ograniczeń. Pomijam evala, którego i tak nie powinno się używać, są inne elementy które poprostu przeszkadzają.

Maszynę wirtualną ma chociażby java, gdyby nie to, strasznie mulastym językiem by była.. No póki co niestety nie ma niczego sensownego, są tam jakieś jeszcze projekty maszyn wirtualnych, ale cały problem w nich rozbija się właśnie o kastracje php, tak jak to ma hiphop od facebooka..


Jest, tyle że to w przypadku php, bo nie wiem jak jest w przypadku innych języków (python, ruby) niestety kastruje php i takiego ZF już byś mógł pomarzyć że postawisz.

Taka maszyna wirtualna musiała by działać transparentnie, tzn wrzucasz pliki na serwer i to poprostu działa. Podobnie jest z APC, tyle że ten akcelerator, działa nieco inaczej, nie mniej i tak zyskuje się sporą wydajność, zwłaszcza w szybkości ładowania. Jakby powstała taka maszyna, to bolączki odnośnie wydajności php raczej byłby najmniejszym problemem..

Mi osobiście w php brakuje czegoś takiego, żebym jakimś mechanizmem mógł sobie wyłączyć wsteczną kompatybilność, która jest mi zbędna. Chodzi tutaj głównie o typowanie, czy rzucanie wyjątkami. Wszech obecna idioto odporność kiedyś była fajna, teraz niestety męczy. I raczej to się nie zmieni i trzeba zwyczajnie przywyknąć..

Marudzicie
Jedyny problem PHP, który obecnie jest nie do obejścia, to wspomniany brak importu całych NS, co de facto jest powrotem do include(), tylko pod inną nazwą i odrobinę ulepszone.
Dobry opis problemu: http://propel.posterous.com/the-end-of-autoloading

I znacznie utrudnia skalowalność. Jak masz niezależne rządania to o wiele łatwiej obsłużyć pierwsze żadanie na serwerze A, a drugie na serwerze B.

Najgorszy to jest językowy fanboizm i językowi haterzy. Ściany tesktu, a 80% to półprawdy, nieścisłości i sporo bzdur. Wybór platformy i języka programowania zależy od wielu czynników, nie tylko technicznych. Dopiera się je w zależności od projektu i nierzadko używa więcej niż jednego. Ogólnie nie ma się co tak ekscytowść, programowanie to tylko przetwarzanie danych


PS. Scala jest pro, ale IMHO zbyt skomplikowana dla przeciętnego kodera przez co będzie miała popularność porównywalną z Haskellem.

Ja bym postawił na C#,JEE, F#(niejako odmiana JEE).W c# niekiedy można korzystać z niektórych namespaców pochodzących z JEE ,czyli łatwiej integrować oba języki.
http://www.codeproject.com/Articles/32313/...ASP-net-using-C

Od tego jest load balancer a nie aplikacja.

Co ma load balancer do tego, że aplikacja trzyma unikalny stan w pamięci jednego z serwerów? Chodzi ci o to, że kolejne żądania danego użytkownika kieruje na ten sam serwer?

No jeżeli zmuszasz appke do tego aby przechowywał personalne dane użytkownika u siebie w pamięci i w żaden sposób ich nie synchronizowała to masz zła appke. Nie ma to nic wspólnego ze skalowalnością.

Odnosiłem sie do serwera aplikacji, jaki to jest zajebiaszczy wynalazek lepszy od "PHPowkiego" bezstanowego stylu rządania i odpowiedzi. Dzięki niemu można robić takie rzeczy jak Stateful Beans, o to chyba chodziło OP.

To nie sprawia żadnego problemu w obsłudze żądań. Uruchamiasz aplikację na dwóch serverach za loadbalancerem i już. Wystarczy tylko pamiętać aby np. zresetować oba servery gdy zmieniliśmy konfigurację, aby zmiany się rozniosły. Można też sprawić aby A kazało B aktualizować konfigurację.


Mi "stanowośc" servletów bardzo się podoba. Obsługa bazy danych/cache, konfiguracja aplikacji, ACL'e, grupy, mailer, języki i prezentacja w aplikacji forum. Nie trzeba tego ładować przy każdym żądaniu, bo to już jest w pamięci i czeka. Minimalizuję narzut frameworka dzięki czemu obsługuję klientów szybciej. Mogę więc obsłużyć większy ruch (tak zrobił Blizzard przenosząc swoje strony w 2010 na Javę).

Albo mi coś umknęło, albo Internet nadal opiera się jednak na protokole HTTP, tak? Czyli każde żądanie wysyłane do serwera jest nadal niezależne od innych, niezależnie od tego jaka platforma obsługuje serwer.
I nie, obsłużenie sesji utworzonej na serwerze A w serwerze B nie jest specjalnie trudne. Google: JEE HttpSession failover

dorobilem sobie bootstrap do testow jednostkowych, jednak aby zadzialac wymagał przeróbki - phpunit uruchamia testy w konsoli, a konsola nie udostepnia $_SERVER['document_root']. Ot, taki mały niesmaczek.

W javie z tego co wiem jest class loader, z uwagi że java, po skompilowaniu kompiluje sie do tylu plikow .class ile bylo plikow kodu zrodlowego. Te pliki class sa nastepnie wczytywane przez class loader jesli beda potrzebne. Otworz sobie jakies archiwum jar i zobacz jak ono od srodka wyglada. Owszem, java sie kompiluje, jednak zazwyczaj kazda klasa jest w oddzielnym pliku.

Z tego rowniez powodu ze java ma class loader, nie mozesz utworzyc w pliku publicznej klasy o nazwie innej niz nazwa pliku, oraz nie mozesz utworzyc dwoch publicznych klas (dostepnych spoza tego pliku zrodlowego). To jest prawie taka sama sytuacja jak w PHP, gdy masz autoloader po namespace, lub taki jak w zendzie - jezeli umiescisz w pliku 2 klasy na raz, to za pomoca autoloadera mozesz sie dostac tylko do tej klasy ktora ma taka nazwe jak plik. druga klasa bedzie dostepna dopiero po uzyciu pierwszej. w odwrotnej kolejnosci sie wysypie.

w C#, w ktorym cały namespace jest kompilowany do postaci .dll ki, mozesz sobie nazywac pliki jak chcesz i mozesz w nich umieszczac dowolna ilosc publicznych klas widzianych w innych plikach kodu zrodlowego.

PSR-0 widzialem w symfony, aczkolwiek nie sadzilem ze to ma nazwę. A skoro ja nie wiedzialem ze to standard, to rowniez cala masa ludzi o tym nie wie I oni beda pisac po staremu i mieszać.

Swoja droga skoro to jest standard to PHPUnit raczej go nie trzyma - tam to w ogole jest kilkanascie autoloaderow, kazdy do czego innego, jak na szybko lustrowalem kod.

poza tym nikt nie wypowiedzial sie odnosnie mojego zarzutu co do braku sekcji krytycznych, semaforow i ogolnie przyjetych locków w programowaniu wspolbieznym ktorego w php czasem nie idzie uniknąć

Czepiasz się PHPUnit-a a sam masz badziewny kod bo używasz $_SERVER['document_root']. Toż to hipokryzja.


Przeczytaj o standardzie PSR-0 bo wykazujesz się totalnym... lamerstwem.


Możesz to zrobić, ale po co? Od tego nie jest PHP. W dużych systemach PHP jest tylko do frontu, resztę robią inne oprogramowania stworzone na innych platformach.
To jak ze śrubokrętem. Nie rozwiercisz nim betonu bo nie ma do tego słuzyć.

Sry ze zadam glupie pytanie ale jak mozna stworzyc aplikacji by miala front end na danej platformie a back end na innej
?
Sry za lamerskie pytanie ale nie mialem nigdy okazji tego widziec

Tak samo jak łączysz się z bazą danych. Za pomocą protokołu binarnego.
Są takie narzędzia jak Thrift, Protocol Buffers.
Dodatkowo możesz wystawić api w jakiejkolwiek formie np REST-owej.
Najciekawszym rozwiązaniem jakie ostatno widziałem w tej dziedzinie to https://github.com/twitter/finagle

Czyli jezeli chce skorzystac z memcache, ale nie moge go użyć z powodu braku locków, to mam przepisac funkcjonalnosc na C++, uzyc thrilla a na koncu i tak z tego memcache nie skorzystac?

A po co Ci "locki" w PHP gdy chcesz skorzystać z memcache?

masz jakis wpis w memcache. Ma on waznosc na 10 minut.
nastepnie x uzytkownikow (dajmy na to 100) akurat wchodzi w tym samym momencie na twoja strone, i potrzebuje tego wpisu w memcache.
Poniewaz sie przedawnil, probuja go utworzyc od nowa. poniewaz kazdy request dziala w oddzielnym wątku, i robia to mniej wiecej w tym samym momencie, nie wiedzą o sobie nawzajem, ze rownolegle requesty rowniez probuja utworzyc ten wpis na nowo.
leci 1000 zapytan do bazy danych, a nastepnie 1000 requestów zapisuje te dane w danej komórce pamieci.

Jezeli zapytanie do bazy danych trwa 500ms, to przez 500ms pomimo ze zapytanie juz jest wykonywane, kolejne requesty ktore wchodza na strone i żądają tej komorki pamieci memcache, robią swoje requesty od nowa, bo mysla ze komorka pamieci jest pusta - pierwszy request ktory wykonal zapytanie majace na celu odswiezyc cache, jeszcze nie zakonczyl swojego dzialania. I tak w kolko beda sie odpalac kolejne zapytania dopoki pierwszy request nie zakonczy zapytania i nie zapisze go w memcache.
Zazwyczaj cachuje sie duze partie danych wiec calkiem prawdopodobne ze to zapytanie bedzie trwalo dosc długo.

Z tego co widzialem i co jest w miare logiczne, aby uniknac tej sytuacji proponują aby swoje zapytania do memcache przekonstruowac tak ze każdy request zanim zacznie to zapytanie do bazy danych czy cokolwiek innego co ma zdobyc dane dla odswiezenia memcache, sprawdza czy zostala ustawiona flaga ze juz ktos to odswieza - zazwyczaj jest to np dodatkowa zmienna w memcache o jakiejs tam nazwie. To nawet dzialajaca solucja ale i tak nie do konca rozwiazuje problem, jesli ten pierwszy skrypt ktory zalozyl lock sie zawiesi, blokada nie zostanie zdjęta. Po za tym wątki moga zostac przelaczone w dowolnym momencie - np pierwszy proces ustawia flage lock, nastepnie system zatrzymuje ten watek i uruchamia drugi - drugi tez chce odswiezyc cache ale widzi ze flaga jest ustawiona więc czeka sleepem lub pętlą, zajmuje procesor, nastepnie przeskakuje do trzeciego.. tysiecznego i na koncu wraca do pierwszego ktory dopiero wtedy moze zaaktualizowac cache i dokonczyc prace i odblokowac reszte wątkow. gdyby byla sekcja krytyczna to nie byloby takiego problemu bo caly kod wykonalby sie za jednym razem bez przeskakiwania do innego wątku.

po za tym jest to smierdzące obejscie niedorobki w jezyku ktore powinno byc rozwiazane przez developerow php, ewentualnie memcache, a nie przez programistow korzystajacych z tych modułów. skoro php nie ma mechanizmow programowania wspolbieznego, to powinien byc zrobiony tak by programisci nie musieli sie wspolbieznoscia przejmowac.

@Orzeszekk: Ten problem można rozwiązać w bardzo prosty sposób: skrypt odczytujący dane z cache nie jest odpowiedzialny za ich aktualizację w razie przedawnienia. Nie musi być nawet zainteresowany tym czy pobierane dane są nadal świeże. Co jest wtedy odpowiedzialne za aktualizację danych? Zupełnie inny skrypt (działający w tle), który cyklicznie aktualizuje dane.

PS. Wątek (tak jak się spodziewałem) w nic konstruktywnego się nie przerodził.

Akurat w przypadku danych do których dostęp musi być zawsze, a pobierane są z cache, nie powinno się nawet czegoś takiego jak locki stosować. Powód jest prosty, za każdym razem ktoś musi wejść żeby te dane zostały wygenerowane. Co w przypadku kiedy tych danych jest dużo? Wtedy taki użytkownik czeka długo, jak długo on czeka, tak długo czekają pozostali, bo jest założony lock. W przypadku danych które muszą być zawsze dostępne, stosuje się cache pasywne, czyli cache które jest generowane przez backend podpięty pod crona czy coś podobnego. I wtedy dostęp do takich danych masz zawsze, nie martwisz się o jakieś lock i inne duperele, jak i na użytkownika nie spada ciężkie brzemię wygenerowania takiego cache.

To nie jest żadna bolączka php, jest to kwestia podejścia do tematu IMO.

Racja, racja

Niemniej wczoraj przez pol wieczoru przygladalem sie tez asp.net mvc i musze powiedziec e jest ciekawe wyglada na bardziej skomplikowane niz django ale chyba warto sprobowac cos w tym zrobic ma duzo ciekawych mechanizmow a wiekszosc aplikacji jest generowana(szkielet,modele) a nawet widoki.

A czego dokładniej oczekiwałes?

@wookieb: W sumie to dokładnie tego co się tutaj pojawiło. Ale @marcio poprosił o wypowiedź więc ją dostał.

To dlaczego mówisz, że wątek nie przerodził się w nim konstruktywnego?

Może ja odpowiem-bo każdy ma swoje preferencje programistyczne.Jakiekolwiek przekomarzanie się co jest lepsze chyba nie ma sensu.Jeden będzie stosował lock w memcache, bo mu tak wygodniej ,drugi użyje do tego crona.

PS.Ja uważam ,że dokonałem prawidłowego wyboru szkoląc się w C#.NET ,język coraz bardziej staje się powszechnym zważywszy ,że w tym języku w większości programuje się teraz na urządzenia mobilne.C#.NET można łatwiej zintegrować z innymi językami programistycznymi.Jedyna wada to darmowe hostingi,których praktycznie nie ma,albo można na palcach policzyć, ale może się to kiedyś zmieni.Lubię ten język ,ale to są tylko moje preferencje i nie będę się kłócił ,czy jest lepszy.

Jeżeli ktoś chce się nauczyć czegoś sensownego ablo chociażby tego jak wyglądają inne języki to gorąco polecam
http://www.amazon.com/Seven-Languages-Week...4386483-7530148

Autoloader moze byc wydajnie zaimplementowany tylko w dwoch przypadkach:

- jak kod jest rozpowrzechniany w postaci spakowanych komponentow (czyli jezyki kompilowane).
- jak kod ma wyrazne zasady korelacji pomierzy nazwa a sciezka.

W przeciwnym wypadku jest to mozliwe do zaimplementowania ale nie wydajne. Dlatego np. w jezykach kompilowanych jak kompilator kompiluje kod to sa zawsze tak zawane "pass 0" i "pass 1". Gdzie w pass 0, tworzy sie tablice definicji symboli (gdzie jest funkcja o danej sygnaturze, gdzie jest struktura o danej nazwie, itd..) a pass 1 dopiero przetrwarza ciala kodu. Bez pass0 kompilacja wskoczylaby conajmniej o kilka poziomow zlozonosci obliczeniowej. Ta tablica jest wlasnie tym autoloaderem w tych jezykach.

PHP nie ma ani pierwszego ani drugiego warunku (narzuconego przez jezyk) dlatego autoloader zawsze bedzie zbiorem hackow