Jakieś 6 lat temu zacząłem programować w PHP. Język ten uważałem wtedy za technologie przyszłości, (przynajmniej mojej przyszłości), gdyż:
- technologia PHP jest za darmo
- programiści PHP są tanią siłą roboczą
- programowanie w PHP jest szybkie i tanie
Dziś moja ocena środowiska PHP jest negatywna. Gdy zaczynałem programować nie uwzględniłem niestety kilku ważnych aspektów tworzenia aplikacji. Patrząc dalekowzrocznie (10 lat) PHP jest bardzo złą technologią, otóż:
- brak kompatybilności wstecz
- utrudnione łączenie aplikacji
- konkurencja jest z przodu
Za najważniejszy problem związany z PHP uważam
brak kompatybilności wstecz pomiędzy wersjami PHP4 i PHP5. Ten jeden czynnik dyskwalifikuje PHP w każdym projekcie, o którym myślimy dalekowzrocznie. Pisanie oprogramowanie w PHP5 wymusza ponowną analizę kodu stworzonego dla języka PHP4. W informatyce możemy łatwo policzyć czas potrzebny na napisanie nowej funkcji. Praktycznie nie możliwe jest określenie czasu potrzebnego na usunięcie błędu. Koszt portowania aplikacji do PHP5 jest bardzo trudny do wyceny. Obawiam się, że kolejne wersje tego języka także będą cierpieć na problemy wstecznej kompatybilności. Programowanie w PHP jest szybkie i tanie, ale tylko w krótkiej perspektywie. Dokładnie tak, jak w dowcipie o roztargnionym malarzu: Malarz dostał zadanie pomalowanie pasu na jezdni. Położył wiaderko na poboczu i pierwszego dnia pomalował 100 metrów, drugiego 50 a trzeciego 10. Gdy szef spytał co jest grane odpowiedział: wiaderko z farbą jest coraz dalej. Powtórzę to jeszcze raz. PHP jest tanie na krótką metę. Jestem pewny, że pisząc za 10 lat aplikacje w PHP7 nie będziemy mogli wykorzystać kodu napisanego 5 lat temu dla PHP4. Jeżeli ktoś może pozwolić sobie na takie marnotrawstwo, to proszę bardzo.
Kolejnym problemem w pisaniu aplikacji w PHP jest to, że nie da się zrobić naprawdę dużego zintegrowanego systemu.
Nie da się łączyć aplikacji. Powodem jest wiele: Najważniejsze to: brak jasno określonych standardów kodowania, brak specyfikacji dla bibliotek, brak przestrzeni nazw. Dla przykładu weźmy dwie aplikacje: czytnik poczty i forum. Chcemy je połączyć w jedną większą całość. Prawie na pewno napotkamy na następujące problemy: osobne i różnorakie bazy danych z kontami użytkowników, różne i niekompatybilne systemy szablonów (smarty,phplib), konflikty w nazwach obiektów i funkcji, a być może nawet to, że aplikacje będą oczekiwały sprzecznych ustawień dla zmiennych środowiskowych (magic_quotes_gpc). Po przeanalizowaniu tych problemów okaże się, że taniej będzie napisać aplikacje od nowa zamiast próbować łączy dwie już istniejące. Problem łączenia aplikacji jest dużo szerszy. Ciężko jest mi połączyć własne aplikacje napisane na przestrzeni kilku lat. Znacznie trudniej będzie połączy aplikacje napisane przez różne zespoły. Tworzenie dużych aplikacji w PHP jest po prostu nie możliwe.
Gdy zaczynałem programowanie w PHP konkurencja w zasadzie nie istniała. Nie było takich technologii jak: .net, rubby-on-rails, zope (lub ich nie znałem). Inne dopiero raczkowały: J2EE. Od tego czasu technologia J2EE zrobiła ogromny postęp zakończony specyfikacją EJB3. Kodowanie dla platformy J2EE 6 lat temu wymagało 5 razy więcej kodu niż teraz i 10 razy więcej pracy niż w PHP. Dziś różnice się zatarły. Nadkład kodu w Javie rekompensują znakomite IDE. Przez ostatnie lata PHP wprowadziło wersje PHP5. PHP5 jest znakomity leksykalnie językiem, o możliwościach przekraczających Javę i zbliżonych do Pythona. Aczkolwiek z powodu braku wstecznej kompatybilności mało kto chce tego języka używać. Java swoją słabość składniową nadrobiła specyfikacjami Bean, EJB, JSR-*. Narodziło się programowanie aspektowe.
PHP zrobiło duży krok w bok. Java olbrzymi krok do przodu.
Dziś zdecydowanie
odradzam pisania aplikacji w PHP. W ciągu 6 lat zmieniłem moją opinię na temat tego środowiska. PHP tak jak roztargniony malarz działa dobrze pierwszego dnia.
pisales jakies wieksze projekty w PHP5?
nie przypominam sobie
“Prawie na pewno napotkamy na następujące problemy: osobne i różnorakie bazy danych z kontami użytkowników, różne i niekompatybilne systemy szablonów (smarty,phplib), konflikty w nazwach obiektów i funkcji”
Ciekawe mnie jak byś połączył istniejącego klienta poczty z istniejącym Instant Messengerem. Oczywiście oba programy nie-Twojego autorstwa, a najlepiej zrobione przez różne zespoły ludzi.
Ja, być może jako jeden z nielicznych, nie znajduję tu wartości merytorycznej.
myślę, że Twoja frustracja jest spowodowana brakiem kobiety :(
Jak można tracić czas na takie elaboraty ?
Wejder
Jak dla mnie, to typowy przejaw fascynacji nową technologią. Tylko bardzo naiwny programista może powiedzieć, że Java jest antidotum na wszystko (a takie wrażenie odniosłem czytając ten wpis).
Jak ktoś nie umie poprawnie pisać w PHP to w Javie tym bardziej nie napisze dobrze.
Dalekowzroczność? Projekt, który jest pisany zgodnie z pewnymi zasadami (np. biblioteki PEAR) bez problemu podlączysz wszędzie bez konfliktów. Jak piszesz bałaganiarsko, to twój problem, a nie języka.
No, no – nie sądziłem, że takie
słowa padną z ust Antka!
Brawo – lepiej przejrzeć na oczy późno
niż wcale ;)
Nie jestem przekonany co do tego, że
Java jest antidotum na problemy z
PHP – proponuję poczytać o Ruby on Rails.
Marcin Gajda (aka zboczuch)
Ja tam mysle, ze jeszcze znajdziemy rozwiazanie/meritum problemu PHP. Odsylam do powstajacego http://meritum.pl ;-).
Oczywiscie, ze za JAVA stoja wieksze pieniadze :-). Bo po glebszym namysle dochodze do wniosku, ze o to w tym artykule chodzi. Poza oczywiscie zrzuceniem winy za balagan pozostawiony za soba w wielu klasach PHPowych tu i tam ;-).
Jednak nie technologia w jakiej pracujemy sie liczy a idea rozwiazan jakie implementujemy, a tych (duszy) jakos nie widzialem w tych klasach, o ktorych mowa akapit wyzej.
Poza tym nie wyobrazam sobie budowania duzych systemow informacyjnych na bazie kodu, w ktorym SQL zlewa sie z PHP, a OOP polega na serii definicji class{}.
PHP to jezyk programowania, JAVA to zestaw narzedzi programistycznych, Ruby to framework. Porownywanie powyzszych to jak porownywanie klockow lego i odmian plastiku. Chyba, ze ignorancja jest darem, a rzeczywistosc teatrem.
Nie zapominalbym jeszcze o tych kilkuset miliardach dolarow, ktore SUN wlal w JAVE i o tych kilkuset, ktorych ZEND nie wlal w PHP :D.
Nie po tym, jakiej farby uzywa, poznajemy artyste, a po tym co z ta farba zrobi.
ave 2 great architect
in gnosis we trust
Pozdrawiam serdecznie,
Tomek Grzechowski
miniman@k3o
meritum znajdziemy w http://merito.pl oczywiscie, sork za zlego linka :P
a jednak poplynalem piszac ten comment ;-)
“Prawie na pewno napotkamy na następujące problemy: osobne i różnorakie bazy danych z kontami użytkowników, różne i niekompatybilne systemy szablonów (smarty,phplib), konflikty w nazwach obiektów i funkcji”
Jak się robi bałagan a nie ładny kod to nawet Java nie pomoże…
Nie wyobrażam sobie pisania dużego projektu, który ma się składać z klocków które były zrobione w różnych standardach (chodzi mi o to, że dany producent robi wg pewnej zasady a inna wg nieco odmiennej)… i nie ma tu znaczenia czy będzie to Java czy PHP. Myślę, że nigdy nie pisałeś dużego projektu w zespole liczącym więcej niż 2 osoby… jakbyś robił kiedyś coś takiego to byś wiedział, że nawet dobrze wyspecyfikowane nazwy klas dokładnie opisane co konkretne metody mają robić… gdy robią to dwa niezależne zespoły mogą pojawić się kwiatki niezgodności… (i właśnie mówię tu o Javie)
PHP5 nie jest złe… jest po prostu inne niż PHP5… Myślę, iż przejścia z PHP5 na PHP6 też nie będą już takie drastyczne jak można by było się spodziewać po przeczytaniu tego co napisałeś…
Witam.
Cieszę się, że na mojego bloga zajrzało paru moich starych znajomych. Tymbardziej jest to miłe, że nie mówiłem im o tym.
Pisząc o PHP i JAVIe krytykuje przede wszystkim to, w jaki sposób PHP się rozwija. Java nie jest antidotum na moje problemy. Po prostu Java jest dla mnie lepsza.
6 lat temu dla webdevelopera PHP było najlepszą alternatywą. Dziś już tak nie jest. Te czasy nie wrócą wraz z PHP6 i
trzeba się z tym pogodzić.
PHP5 jest bardzo dobrym językiem programowania.
Odnośnie robienia bałaganu w kodzie.
Jeżeli ktoś nie spotkał się z takim problemem w aplikacjach PHP to pewnie nie widział żadnej dużej aplikacji rozwijanej przez zespół stale zmieniających się developerów przy stale zmienianej specyfikacji pod presją terminu “na wczoraj”. Niestety język PHP sprzyja bałaganiarzom. Brak mocnych narzędzi do refactoringu, utrudnia sprzątanie.
Tych, co myślą, że nie mam co robić i że brakuje mi dziewczyny, muszę rozczarować. Dzięki za propozycj, nie skorzystam, nie jestem gejem.
Jak połączyć nowoczesnego klienta poczty z nowoczesnym IM? Załóżmy, że to dwie nowoczesne aplikacje napisane jako portlety, zgodnie ze specyfikacja JSR-168. Dalej wszystko jest jasne.
Pozdrawiam.
“Jak połączyć nowoczesnego klienta poczty z nowoczesnym IM? Załóżmy, że to dwie nowoczesne aplikacje napisane jako portlety, zgodnie ze specyfikacja JSR-168. Dalej wszystko jest jasne.”
A jak założymy, że nie? (co jest bardziej prawdopodobne) – i znowu nastała ciemność…
PS.
Żeby nie było:
- nie jestem fanatykiem PHP, ale go lubię za prostotę
- nie jestem antyfanatykiem JAVY – to jest cholerna przyszłość
Raczej będą: JSP-168 jest standardem pisania aplikacji WWW. Na tym bazują najnowsze produkty IBM: Workplace, BEA: Portal (czy jakoś tam), Oracle, Liferay, inne. A jeżeli nawet nie, to będzie można to zrobić na pewno łatwiej niż w PHP. Nie sądzę, żebyś w aplikacji JAVA spotkał osadzane SQL lub HTML bezpośrednio w kodzie. A w aplikacji PHP na pewno na takie coś trafisz.
Jak spojrzysz na jakąś większą aplikację PHP to raczej żygniesz. Mało kto słyszał w PHP o MVC, lub o hermetyzacji. Przestrzenie nazw to feature dopiero z PHP5.
> Poza tym nie wyobrazam sobie
> budowania duzych systemow
> informacyjnych na bazie kodu, w
> ktorym SQL zlewa sie z PHP, a OOP
> polega na serii definicji class{}.
Bull shit ;) ABAP wykorzystywany w systemach SAP R/3 to jest wlasnie polaczenie SQLa i jezyka programowania… nie mozna powiedziec by byl to maly system…
SAP migruje w kierunku JEE.
“Jak połączyć nowoczesnego klienta poczty z nowoczesnym IM? Załóżmy, że to dwie nowoczesne aplikacje napisane jako portlety, zgodnie ze specyfikacja JSR-168. Dalej wszystko jest jasne.”
Załóżmy, że dwa programy w PHP5 zostały napisane używając wszelkich zasad programowania obiektowego, i potrafią komunikować się ze środowiskiem zew. za pomocą interfejsów ?
Myślę, że to czy istnieje jakiś oficjalny standard i tak zależy od tego czy programista o nim wie, tak samo jak czy wie, że można pisać aplikacje w PHP5 tak aby mogły być łączone z innymi systemami poprzez interfejsy.
Pozdrawiam.
Uzgodnienie samego API może być nie wystarczające w przypadku aplikacji WWW. Należy też uzgodnić style CSS dla odpowiednich elementów.
Odsyłam do specyfikacji JSR-168 na stronie 115.
Portlety, to nie bajka, ale to coś co będzie przyszłością aplikacji WWW.
no jak masz takie samo podejscie do programowania w innych jezykach to wybacz ale powinienes sie zastanowic nad jakimis innymi studiami. zostan moze historykiem albo cos kolo tego – tam w sumie nic sie nie zmienia i jest pelna kompatybilnosc wsteczna.
gdyby php mialo byc kompatybilne wstecz z wersja 4 to nadal udawaloby obiekty i ogolnie interesowaliby nim sie tylko tacy programisci jak Ty. poznaj obiektowke w 5 i pozniej podyskutujemy na temat godnienia za wiaderkiem z farba
Na programowanie w PHP nie patrzę jako student, ale jako osoba, która musiała spełnić oczekiwania klienta w trudnych projektach.
Programowanie w PHP sprawdza się, tak samo jak sprawdza się Lotus, czy Oracle Forms. Jednak jest coś nowego i tym się teraz zajmuję.
Pozdrawiam
egroupware, sugarcrm to nie są malutkie systemy a powstały w php.
Antek, tworzyles oprogramowanie w PHP pod presja terminow, “na wczoraj” wprowadzajac zmiany w specyfikacji. Nie sadzisz, ze Twoj wstret do PHP jest bardziej psychologiczny niz merytoryczny?
Poza tym sa duze szanse, ze za kilka lat napiszesz dokladnie takiego samego posta na temat javy…
Dyskutowanie o wyzszosci jednego jezyka nie ma sensu. Proponuje podejsc do tego tematu rekursywnie: PHP jest lepsze od Javy, Java jest lepsza od PHP. Zalezy tylko kto, kiedy i gdzie.
Nie sadze tez, aby PHP6 wywolalo jakas drastyczna zmiane w obszarze aplikacji internetowych. Wystarczy popatrzec sobie na statystyki serwerow i jakie obecnie wersje PHP obsluguja.