O mně     Twitter

ARCHIV – tento článek je již staršího data. Doufám, že mnoho myšlenek v něm je stále platných, avšak některé informace již mohou být zastaralé.  

K čemu je PHP?

3.1.2006

PHP má nefunční objektový model, chybí mu zabudované komponenty a frameworky a má mnoho dalších nevýhod, které ho diskvalifikují z použití na větších projektech. Své ideální využití nalezne PHP pouze u menších webů.

Již dlouho s přestávkami přemýšlím, k čemu je vlastně dobrý jazyk PHP. Nejsem sice programátor, ale s programováním zkušenosti mám a díky škole mi momentálně nechybí ani přehled o vývoji v tomto oboru. Proti PHP mluví řada argumentů:

  • Nefunkční objektový model. Knihovna základních funkcí PHP je procedurální, téměř nevyužívá objekty. Co je ale ještě horší, základní funkce nevyhazují výjimky, což v podstatě znemožňuje opravdové objektové programování. Velmi podivná a neintuitivní (v porovnání třeba s Javou) je i syntaxe a chování mnoha objektových konstrukcí, a takto bychom mohli pokračovat.
  • Nesystematičnost v přidávání a pojmenovávání nových funkcí. PHP obsahuje funkce skoro na všechno, na co si vzpomenete, ale tyto funkce jsou přidávány bez ladu a skladu a pojmenovávány jednou s podtržítkem, podruhé bez, jednou celým jménem, jednou zkratkou...
  • Absence zabudovaných komponent a frameworků.
  • Podivná politika vývoje nových verzí. Často jsou slyšet problémy se vzájemnou kompatibilitou různých verzí PHP.
  • Absence sofistikovaných vývojářských nástrojů. Např. k jazyku Java jsou dostupné spolehlivé a fungující debuggery, programy na kontrolu kódu, nástroje pro generování dokumentace nebo testovací a sestavovací nástroje. K PHP mnoho těchto nástrojů také existuje, ale nejsou tolik spolehlivé ani tak dobře integrované jako u vyspělejších jazyků.
  • PHP je interpretovaný jazyk. To s sebou nese celou řadu problémů, počínaje netypovostí jazyka a konče značnou syntaktickou benevolencí interpretu. V PHP také chybí obecně přijímaná doporučení pro psaní čitelného kódu.

Kvůli těmto nedostatkům se nedá PHP využívat ve větších projektech, ani webových. Při jeho použití nutně musí narůstat náklady projektu a chybovost aplikace. Daleko vhodnějšími platformami pro vývoj webových aplikací jsou dnes Java, .NET nebo třeba Ruby on Rails.

Výhody PHP vidím dvě:

  • PHP se dá snadno naučit. Objektové programování je složitější než procedurální a jeho výhody se dostavují až u větších projektů. Snažšímu naučení PHP také pomáhá, že jeho základní funkce nemají objektovou strukturu a že mnoho dynamických prvků se dá vytvořit velmi přímočaře a rychle.
  • Vývojáři v PHP jsou levnější. Tímto bodem se nechci nikoho dotknout, pouze vycházím z ekonomické logiky – aby se někomu chtělo zabývat se těžším objektovým jazykem, musí být programování v něm lépe oceněno. Na druhou stranu, peníze ušetřené na vývojářích budou muset být investovány do projektu navíc, protože vývoj v PHP je chybovější a tím pádem nákladnější.

PHP se proto podle mě hodí pouze na menší projekty – v nich ještě převažují výhody tohoto jazyka (hlavně jeho snadné ovládnutí). Příkladem je koneckonců i tento web. Rád si ale také přečtu váš názor: především by mohla být zajímavá konkrétní čísla a zkušenosti z vašich projektů.

Reakce jinde na webu

48 komentářů od čtenářů

 

Přidat komentář

1. Jan Brašna | 3.1.2006, 8.20

"K čemu je PHP?" -- K použití jako šablonovací jazyk.

Pokud potřebuješ jen nějaký nástroj, kterým protlačíš data z úložiště k uživateli, nepotřebuješ sofistikovaný jazyk. A tím protlačením může nakonec být jak jednoduchý CMS, E-shop a podobně :)

Nutno říct, že s dostupnými OS balíky a PEARem je vývoj v PHP pro běžné webové použití relativně efektivní (a není to pochopitelně primárně zásluha jazyka, ale spíš "okolí" - existuje pro něj velká podpora ať už po stránce webhostingu či dostupných programátorů). A pokud ten, kdo aplikaci píše, je zodpovědný, nemusí být výstup nijak tristní.

V Kafi a .NET není vidět mnoho běžných webů nebo obchodů, zároveň si nedokážu představit třeba banku v Perlu :)

Jinak brát Ruby on Rails mezi jazyky není zcela košér, neboť to je vynikající framework nad IMHO hodně "basic" jazykem jako je Ruby. To bys s ním a s ostatními jmenovanými musel srovnávat třeba Symfony nebo CakePHP a nikoliv PHP samotné.

Do budoucna jsem zvědav na postup hlavně RoR a Pythonu.

2. Jan Brašna | 3.1.2006, 9.15

BTW stejně to máš s .NET, je to taktéž framework, ne jazyk - to srovnání je skutečně po stránce "platformy" jak píšeš, protože každé je úplně něco jiného. Pak srovnání multijazykového frameworku pro univerzální použití se skriptovacím jazykem pro web je takové, jaké je :)

3. Llaik | 3.1.2006, 9.43

Neexistujici vyjimky a divny objektovy system? Cetl jsi o PHP5?

Nesystematicnost v pojmenovavani novych fci? Koukl jsi nekdyna Ruby a jeho synonyma pro spoustu fci, kdy xy fci jsou pouze aliasy pro jinou? Rikaji tomu "vyhoda, muzete psat a nepremyslet nad nazvy"

Absence zabudovanych frameworku? Zatim jsem na tento problem nenarazil, nehodnotim :)

Nekompatibilita v novych verzich? Kde je casto slyset? Snad mensi trable mezi verzi 4 a 5, ale to jiste nemylis, viz tva prvni vytka tykajici se objektu - ta znaci, ze o verzi 5 nevis. O zasadnich nekompatibilitach v desetinkovych verzich ctyrky nevim. Muzes me nasmerovat?

Absence sofistikovanych vyvojarskych nastroju? Neco jako je Zend Studio, PHPEditor, Nusphere PHPedit, Eclipse? Aha.

Ze je php intepretovany jazyk a proto netypovy? No netypovy je, coz je povazovano za jeho vyhodu (stejne jako u Pythonu ci Ruby), intepretovany take, ale stejne jako treba Python je mozne ho kompilovat do bytekodu, takze beha svizne. Nemluve o tom, ze prave interpretovanost mu krome nekterych predevsim vykonovych nevyhod dava ohromnou vyhodu v rychlosti nasazeni, updatu, vyvoje, ladeni apod.

A nejaky coding standard ze neexistuje? PEAR je vzduch?

Programator PHP neni levnejsi, pouze hur nalezitelny, protoze krome nekolika PHP programatoru je na trhu prace i spousta lidi, kteri to o sobe tvrdi. Coz je bez diskuze ta opravdu nejvetsi nevyhoda tohoto jazyka.

Prosim, priste zkus vice zapatrat, vice diskutovat, nez zacnes kritizovat bez radneho zakladu.

Hezky den :)

4. Michal Táborský | 3.1.2006, 9.46

Martine, myslím vcelku rozumně si vyjmenoval nevýhody PHP a nedá se s tím než souhlasit. Já bych přidal jednu, která nás občas dovede potrápit a to je občasná nekvalita vydání (počet bugů zejména v prvních stádiích major verzí). Stejný seznam by se ale dal vyrobit asi pro každý jazyk, se kterým jsem se kdy setkal.

Nikde se netajíme, že naše (http://www.mall.cz) technologie používají PHP, takže k tomu asi nějaké důvody máme a tady jsou: obrovská flexibilita jazyka, rychlost vývoje, dostupnost nástrojů a široká nabídka knihoven a hotových řešení.

Aby bylo ovšem zvládnutelné dělat v tom větší věci, je potřeba dělat to trochu s rozmyslem:

- stanovit "coding standards", protože PHP umožňuje vícero syntaxí, jako nejméně náchylná na chyby se osvědčila Java syntaxe

- používat dokumentační systém (v současnosti asi jen PHPDocumentor)

- rozumně rozvrhnout repository projektu, necpat všechno do jednoho adresáře a nedej bože souboru

- dobré rozvržení jmenného prostoru

Pokud se toto dodrží spolu s obecnými zásadami pro vývoj, je možné v PHP vyrobit i středně velký projekt (okolo 100 tisíc řádků) s rozumnými náklady.

5. Jakub Vrána | 3.1.2006, 10.45

Interpretovanost jazyka přece nijak nesouvisí s netypovostí. Navíc ani jeden pojem není zcela přesný - PHP je před spuštěním zkompilováno do mezikódu podobně třeba jako Java, jen se tento mezikód nikam neukládá. A je to jazyk dynamicky typovaný (u každé proměnné v každý okamžik lze určit její typ), nikoliv netypový.

Překlad běžných chyb PHP na výjimky je zcela triviální, stačí se podívat na funkci set_error_handler().

Obecně přijímané doporučení pro psaní čitelného kódu je PEAR coding standards.

[3] Kromě dobře odůvodnitelné změny objektového modelu měl autor na mysli asi zbytečné zmatky kolem práce s referencemi.

Rozhodně bych nesouhlasil se závěrem, že PHP se na větší projekty nehodí. Pouze to chce vyšší kázeň.

6. Llaik | 3.1.2006, 10.49

[5] ach, tu jsem zahrnul do te zmeny objektoveho modelu, protoze tam to bylo "nejviditelnejsi" :)

jinak souhlasim se zaverem, je to predevsim o lidech, ne jazyku. Otazkou je, jak je definovan velky projekt, ale pokud se podivam po internetu, tak mam pocit, ze spoustu veci, ktere oznacuji sam za "velke projekty", je napsano v PHP.

7. Jozef Izso | 3.1.2006, 11.51

V ASP.NET robím 4 roky, v PHP občasne cca 1,5 roka.

PHP je rýchle na naučenie. Vďaka možnosti použiť C syntax sa netreba učiť nové podivné zápisy, ako napr. u Pythonu. Najviac s PHP robím v Textpatterne. A tu je vidieť veľké slabiny PHP: interpretácia kódu a nedostupné vývojové prostredie (= písanie kódu, dokumentácia!, integrácia s manažérom databázy, debugger - toto je kvalitné vývojové prostrie, ktoré úrychľuje vývoj. A prípadne integrácia so Source Control).

Keďže je kód interpretovaný a neexistuje k nemu kompilátor, tak sa 60% chýb u mňa tvoria preklepy v názvoch premenných. Existuje v PHP syntax checker, ale jeho kvalita končí s prvým exit; príkazom v kóde. Proste ďalej necheckuje (prípadne sa mi nepodarilo zistiť, ako sa to dá).

PHP má síce funkcie na všetko, ale má naozaj funkcie na všetko, čo je potrebné na webe? Videl som mnoho funkcií, ktoré vypočítajú rôzne podivné čísla, ale neexistujú napr. validátory vstupu. (Je ťažké porovnávať funkcie v PHP a serverové ovládacie prvky v ASP.NET a JSP, ale čo mi poskytuje viacej možností pre tvorbu stránky?)

Vývoj v PHP na hodinu môže byť lacnejší, celkovo však v PHP treba dorobiť plno vecí, ktoré v ASP.NET alebo JSP sú už predpripravené. (napr.: prihlasovanie užívateľov - v PHP vždy iným a iným spôsobom realizované, človek strávy hodiny dumaním, ako to čo najviac zabezpečiť a i tak nakoniec credentials skončia v $_SESSION[]. ASP.NET: potrebujem viacej informcáií o užívateľovi? Spravím si vlastný ICredential. Netreba však písať celé pozadie prihlasovania. A rovnako validátory vstupu a pod.) To môže znamenať, že projekt v PHP bude nákladnejší.

Náklady na prevádzku PHP aplikácií bývajú podstatne nižšie, keďže prevádzkovateľ nemusí platiť licencie Microsoft-u ako u ASP.NET.

Na PHP mi teda najviac vadí veľmi pomalý vývoj a ťažké odlaďovanie kódu.

8. Martin Snížek | 3.1.2006, 11.57

Díky všem za komentáře. Odpovím jednotlivě:

[1] Na to tlačení dat z DB se PHP skvěle hodí, s tím souhlasím. Co se týče Pythonu, prý je zde slabá podpora komunity -- existuje málo již napsaných aplikací a knihoven.

[3] Výtkami k objektovému modelu samozřejmě myslím PHP 5. Podle mě se v něm o žádném objektovém programování vůbec mluvit nedá, a za tím si stojím.

[4] Zajímavá informace, díky.

[5] K těm typům -- je jedno, jak se tomu říká, ale mně vadí třeba tohle: <http://www.php.net/manual/en/types.comparisons.php>.

O set_error_handler() jsem nevěděl, ale asi není něco s OOP v PHP v pořádku, když se to musí takhle zapínat. Obecně se do PHP spousta věcí musí dodávat, obcházet, což nepřispěje přehlednosti kódu.

[6] Otázka je, jestli je dobře, že jsou takové projekty psané v PHP.

Jinak obecně myslím, že ze všech vašich komentářů vyplývá, že se dá PHP využívat i v něčem větším, pokud se obohatí o většinu vlastností, které mají vyspělé jazyky už automaticky.

9. Martin Snížek | 3.1.2006, 11.58

[7] Mluvíte mi z duše :-)

10. Michal Táborský | 3.1.2006, 12.42

[7] Pokročilé nástroje pro vývoj v PHP samozřejmě existují. Asi nejlepší je Zend Studio/Zend Platform. které ovšem stojí nějaký peníz (nijak závratný). Zdarma po trochu náročnější konfiguraci je Eclipse.

Co se týče předpřipravených věcí--je to skutečně tak, že v ASP.NET je to hotové. Ale leckdy pro uživatelský web nepoužitelné (často proto že to má špatnou použitelnost nebo přístupnost) a potom nějaká customizace zabere více času a je náročnější na prostředky, než vytoření lehkého custom řešení od začátku .

11. Llaik | 3.1.2006, 14.37

Ad IDE: debug, code checker, dokumentator, CVS rozhrani, pristup k databazi - minimalne Zend Studio toto umi. Nusphere nema tusim codechecker, zbytek ale zvlada take. PHPEditor od Waterproofu tusim to same.

Faktem je, ze kdyz jsem nedavno (cca pred 2 mesici) tvoril SWOTku pro PHP, Python a Ruby, tak PHP z toho nakonec vzeslo jako vitez. Melo jedine vetsi minus - vykon (bez zendich hracek).

Validator vstupu? Asi nevim, co to je :) kazdy vstup je trosku jiny, nekde [a-z0-9], jinde cokoliv, ale osetruji vstup pred vlozenim do sql dotazu apod.. toto mi nejak nechybelo, vzdy jsem si byl schopen osetrit co jsem potreboval tak, jak jsem potreboval.

No kazdopadne kdo chce hanit, at hani :) kdy vyjde clanek na tema: K cemu je Python? K cemu je Ruby? K cemu je Java? K cemu je C++?

Na kazdem se da najit nejaka ta chybicka.

Btw - ma treba Python ci Ruby takovy hezky graficky profiler, jako PHP? Ze to s jazykem primo nesouvisi? No ja s IDE nezacal... :)

Debata o nicem, clanek jiste zveda navstevnost, rozhodne ne vedomosti ctenaru. Az me to tu mrzi, protoze jak na PHP vzdy nadavam a snazim se vetsinu svych freetime aktivit psat v necem jinem (Python/C++), tak zde musim vypadat jako vasnivy milovnik PHPka. Spis se ale snazim jen delat obrance necemu, co je haneno bez konkretnich dukazu opravdovych nevyhod. To ze nekdo nezna IDE apod... boooze.

12. Martin Snížek | 3.1.2006, 14.48

[11] Neměl jsem v úmyslu se nikoho dotknout, jen jsem ukázal na nevýhody PHP a snažím se určit, kde se dají co nejlépe využít jeho výhody.

Nevím, proč se vám zdá, že je zde PHP "haneno bez konkretnich dukazu opravdovych nevyhod", protože tento příspěvěk a komentáře pod ním nejsou o ničem jiném, než o konkrétních nevýhodách a výhodách PHP. Návštěvnost mi to rozhodně nezvedá, tento příspěvek má stejnou čtenost jako většina ostatních.

13. Llaik | 3.1.2006, 15.11

"Obecně se do PHP spousta věcí musí dodávat, obcházet, což nepřispěje přehlednosti kódu." - velmi konkretni.

" Často jsou slyšet problémy se vzájemnou kompatibilitou různých verzí PHP." - jeste konkretnejsi :)

14. llook | 3.1.2006, 15.32

Bordel v tom je. Třeba to, že autoři rozšíření v C mají používat jiné jmenné konvence než autoři PEAR, je přinejmenším zvláštní.

> základní funkce nevyhazují výjimky

Tak třeba PDO už vyhazuje. Doufám, že časem budou výjimky méně výjimečné.

> Absence sofistikovaných vývojářských nástrojů

Kdyby jen sofistikovaných. Třeba teď jsem řešil rámec pro testy jednotek. Oblíbil jsem si SimpleTest, ale ten v PHP5 nejde, díky té srandě s referencema. Jediný funkční jsem našel PEAR:PHPUnit2, který je ale nechutně překombinovaný. Co si člověk neudělá sám...

> Objektové programování je složitější než procedurální a jeho výhody se dostavují až u větších projektů.

Tak to si nemyslím. Akorát lidé se i dnes většinou učí nejdřív procedurální a pak se těžce přeučují. Ještě si trochu pamatuju svůj přechod z Basicu na Pascal, ze začátku jsem měl všude goto. Přechod od procedur a funkcí k objektům byl podobně zábavný.

Zajímavé jsou také zkušenosti Rudolfa Pecinovského, kterého výuka OOP živí ( http://ceskaskola.cz/ICTveskol … asp?ARI=101878&CAI=2129 ):

> Na účastnících našich školicích a přeškolovacích kurzů je totiž vidět, že ti, kteří se do nich přišli naučit programovat a nemají žádné předběžné znalosti programování, mají s řadou věcí mnohem menší potíže než ti, kteří již programovat umějí a musejí nejprve pracně zapomenout nebo dokonce přebudovat značnou část toho, co se před tím pracně naučili.

15. johno | 3.1.2006, 15.59

[12] Môžem vedieť, s akými problémami v objektovom modeli ste sa v PHP stretli? Základné funkcie nevyhadzujú výnimky a potom trochu neskôr jedným dychom hovoríte o strašnej nekompatibilite medzi verziami? Divné, veľmi divné.

Nesystematickosť pridávania názvov funkcií možno na prvý pohľad niekoho naštve, ale osobne mi to vôbec nevadí. Neviem prečo, asi som si zvykol používať manuál a autocompletition v Scite.

Chystá sa Zend framework. Existuje PEAR. Žiadny flame prosím. Sú tam aj dobré aj zlé balíky.

No s tou kompatibilitou by som bol opatrnejší. Z mojich skúseností je to skôr spôsobené ignoranciou PHP užívateľov.

Vývojárske prostredie. Jediné čo mi chýba je IDE s dobrým refactoringom. Debugger je pri istých agilných metódach programovania zbytočný a profiler mi stačí cez príkazový riadok.

Ruby je tiež interpretované. Existujú predkompilátory pre PHP. Akcelerátory. Kto vie čo ešte. Ako nevýhodu by som to vôbec nespomínal. Typové verzus netypové jazyky. To je flamewar ako vyšitý. Každý nech používa to, čo mu sadne.

Povedzme si to na rovinu. PHP je bordelársky jazyk. Začne v ňom robiť hocikto veľmi rýchlo. Bez toho, aby niečo vedel o tom ako počítače vlastne fungujú. Ľudia, čo nemajú ani potuchy o zložitosti algoritmov a kritických súbehoch vo viacvláknových aplikáciach, by si mali programovať webstránky len pre seba. Opak je veľmi často pravdou.

Jednoduchosť PHP je silná aj slabá stránka zároveň. Ruby detto.

16. Jakub Vrána | 3.1.2006, 16.21

[7] Pokud nevíte o funkcích pro kontrolu vstupu, zkuste se podívat na rozšíření ctype.

Pokud děláte překlepy v názvech proměnných, tak to je buď špatnými návyky nebo špatným editorem. Já delší názvy proměnných píšu tak, že napíšu jejich začátek a pomocí Ctrl+Enter (ve SciTE) doplním konec. Možnost vynutit povinnou deklaraci proměnných (jako třeba v ASP) mi ale zpočátku také chyběla a kdyby byla, tak bych si ji zapnul asi i teď.

17. llook | 3.1.2006, 16.47

[14] SimpleTest beru zpět. CVS verze běhá v PHP 5 bez potíží. Díky Johnovi za upozornění.

18. dgx | 3.1.2006, 17.07

Srovnávat nebo hodnotit programovací jazyk by mělo příslušet skutečným odborníkům, kteří jej podrobně znají a používají. Oznámení "nejsem programátor" na začátku článku se bohužel ukázalo jako pravdivé.

PHP se dá vytknout celá řada nešvarů, v něčem se Martin trefil (například nekonzistence názvosloví funkcí, to se existencí editoru třetí strany s autocomplete omlouvat nedá), ale v mnohých míří naslepo (interpretovaný tudíž netypový, neexistující IDE) a vedle.

Drž se ševče svého kopyta.

19. Ivan | 3.1.2006, 17.19

Zdravim,
osobne sa tesim, ked nam poskytnete hosting s podporou ruby, java a .NET. Zaroven by som si rad pozrel nejaky "rozsahly projekt" na ktorom ste pracovali, ked dokazete tak odborne zhodnotit nevhodnost PHP. Z tohto celeho mam pocit, ze Vam pre Vas blog dochadzaju temy a tak kradnete a prekladate text z niektoreho anglicky hovoriaceho servera :)
Pekny vecer.

20. Ronnie | 3.1.2006, 17.55

Zajímalo by mne, jaký konkrétní typ projektu nešlo vytvořit pomocí PHP?

Jinak pro PHP existuje mnoho amatérských projektů, řekl bych, že existuje také více článků, které se PHP věnují, a tak je jeho studium mnohem jednodušší.

21. Martin Snížek | 3.1.2006, 18.13

[15] Problémy PHP v objektovém modelu:

* Podivné prolínání referencí & s objekty.
* Mechanismus __autoload -- třeba v Javě to funguje automaticky a systematicky.
* Přetěžování metod pomocí __call -- bordelářské, nesystematické, nepřehledné.
* Možnost uvádění typů v parametrech funkcí -- jedná se o možnost, ne povinnost, nedá se použít u primitivních typů. Opět další nepřehlednost.
* Už zmiňovaný fakt, že standardní funkce nejsou napsané objektově a že nevyhazují výjimky -- ani set_error_handler() nestačí, protože už se o to musíte sám starat, sám si připravit třídu pro výjimku. Správně byste si měl akorát přečíst jméno výjimek, které metoda vyhazuje, a napsat si pro ně try..catch.

[18] Dobře, uznávám, že moje programátorské vzdělání není bez děr, ale k hodnocení vhodnosti PHP nepotřebuju být výborným programátorem.

I když jste vyvrátil jeden můj argument, tak minimálně první tři argumenty z původního příspěvku stále zůstávají -- a tyto argumenty jsou nejpádnější. Dokonce byly tyto argumenty potvrzeny i některými programátory tady v komentářích. Takže si myslím, že nestačí říct, že "když není programátor, nemá pravdu, jedeme dál".

[19] Podívejte se, tohle osočování si nechte. Pokud si neumíte vedle políčka pro komentář přečíst, že máte psát slušně a k věci, tak sem radši nepište.

22. David Majda | 3.1.2006, 19.12

Mám několik upřesnění/dotazů:

1. Nepoužívání ani neexistence vyjímek nesouvisí s "opravdovým objektovým programováním" jinak, než že vyjímky jsou ve většině jazyků uspořádány do hierarchie tříd (ne ve všech, třeba v JavaScriptu zrovna nejsou). Oba koncepty jsou ortogonální - můžu mít OO jazyk bez vyjímek, nebo naopak dodělat vyjímky třebas do neobjektového céčka.

2. Co se myslí výrazem "absence zabudovaných komponent a frameworků"? Přesněji, co v PHP po téhle stránce chybí a nedá se snadno doplnit?

3. Jak už bylo zmíněno, to, že je PHP interpretovaný jazyk, nijak neimplikuje beztypovost a syntaktickou benevolenci. Jsou to tři úplně ortogonální koncepty. To, že většina interpretovaných jazyků je zároveň dynamicky a slabě typovaných a nemá tolik rigidní syntaxi, je dáno typickým způsobem použití těchto jazyků, který je trochu jiný, než u "statických" jazyků typu C++, Java nebo C#.

4. Z hlediska jazyka je Ruby na tom až na elegenaci, konzistenci a jistý příklon k funkcionálnímu programování vícemně stejně jako PHP (interpretovaný, rlativně rozvolněný jazyk). Dávat ho do jednoho pytle s Javou a .NETem je dost odvážné. Framework typu Ruby on Rails by šel v PHP v principu nejspíš napsat taky (neznám Ruby moc do hloubky, proto jen "nejspíš", ne "určitě").

Jinak s ostatními body kritiky v zásadě souhlasím.

23. Martin Snížek | 3.1.2006, 19.21

[22] On by ten framework určitě v PHP napsat šel. Problém je, že v těch ostatních jazycích sáhnu do dokumentace a můžu ho začít používat, píše se o něm v knížkách atd., to v PHP není.

Co se týče těch výjimek, tak já si bez nich nedokážu objektové programování představit :-) (Objektovým programováním nemyslím jen používání objektů k uchovávání dat.) Jak jinak se dá izolovaně bez kontextu v jednotlivých metodách efektivně ošetřit chybový stav, který přesahuje kompetence této metody?

24. johno | 3.1.2006, 19.47

[21] Podivné prolínání referencí & s objekty.
Neviem čo ste tým mysleli, ale v PHP5 sú objekty predávané vždy referenciou. Presne tak ako v Jave.

Mechanismus __autoload.
Ak sa to snažíte porovnať s import v Jave, tak tam to funguje trochu inak už len preto, lebo Java je kompilovaná. Import sa pokiaľ viem spracováva pri kompilácii a __autoload počas behu programu. Lazy loading. Neviem však prečo toto považujete za problém. Osobne som to ešte ani nepoužil.

Přetěžování metod pomocí __call. __get, __set
Veľmi veľmi dobrá vec. Ak človek vie, na čo to použiť. A inak viac menej ekvivalent existuje aj v Jave. Prečo asi? Nájdite si Reflection API a metódu invoke(). __call v PHP je to isté len cez efektnú skratku. Z PHP sa takto dá napríklad spraviť aj deklaratívny jazyk. Veľmi sympatické.
http://www.sitepoint.com/forums/showthread.php?t=322409

Možnost uvádění typů v parametrech funkcí.
PHP je stále netypový jazyk! Nazdávam sa, že toto vzniklo najskôr kvôli lepšej podpore parametrových hintov vo vývojových prostriedkoch. Potom sa to zahrnulo do Reflection API a teraz môžeme vychutnávať krásne Dependency Injection.

...standardní funkce nejsou napsané objektově...
PHP nie je pôvodne objektový jazyk, ale procedurálny. V tomto má Ruby obrovskú výhodu. Ak by chceli vývojári PHP zmeniť razom všetko v PHP5 na objekty, tak by mal tento článok asi titulok "PHP je mrtvé".

25. David Majda | 3.1.2006, 20.08

[23] K vyjímkám: Asi myslíme objektovým programováním každý něco jiného (já tím myslím klasické "zapouzdření, dědičnost, polymorfismus").

Souhlasím, že vyjímky jsou lepší než jiné mechanismy ošetření chyb (speciální návratová hodnota, errno apod.), ale to, že vyjímky jsou objekty, je až sekundární. Souvisí to s tím, že se ukázalo, že vyjímky je žádoucí hierarchicky rozlišovat a protože ve většině jazyků, kde jsou vyjímky, je už mechanismus hierarchické struktury implementován u tříd, je hierarchie vyjímek definována v pojmech hierarchie tříd.

Mimochdem, názor, že vyjímky jsou dobré, není rozhodně univarzální: kdysi jsem na svém zápisníku odkazoval na docela zajímavou debatu o tom - <http://www.majda.cz/zapisnik/permalink.php?idart=156>.

Teď mě ještě napadá: u vyjímek je taky jeden ůležitý problém, a to posoudit situaci, kdy je třeba vyjímku vyhodit a kdy ne. Příklad: kloekce v Javě. Když se zeptám na prvek, který v kolekci není, vrátí se null - místo vyhození vyjímky. V 90% případů si je totiž programátor jistý, co v kolekci má, a psaní prázdného catch-bloku v této situaci by jen znepřehledňovalo kód.

S vyjímkami to zkrátka není lehké :-)

26. Jan Brašna | 3.1.2006, 20.12

Marine, ale u těch frameworků, validátorů a kredenciál (hodně blbé slovo) srovnáváš frameworky s jazykem. Můžeš srovnat "out-of-the-box" Ruby, C# a PHP. A nebo pak RoR, .NET a třeba CakePHP. Pak máš buď srovnání jazyků nebo srovnání frameworků. Nemůžeš ale obojí míchat dohromady. Tato funkcionalita nepatří do jazyka, ale frameworku. A věř tomu, že všechny větší věci v PHP na nějakém frameworku stojí, pokud se dělají "na zelené louce".

27. llook | 3.1.2006, 21.16

[21] Tak s dovolením okomentuju jednotlivé body.

* Podivné prolínání referencí & s objekty.

Uznávám, že předávání objektů v PHP5 je trochu zvláštní - ani referencí, ani hodnotou. Ale pracovat se s tím dá.

* Mechanismus __autoload

Že mě k tomu PHP nenutí neznamená že to nelze. Můžu si vytvořit vlastní konvence pro ukládání tříd a funkci __autoload naučit podle těchto konvencí třídy načítat.

* Přetěžování metod pomocí __call

Věc názoru, mě připadá tento způsob pro PHP vhodnější.

* Možnost uvádění typů v parametrech funkcí

U validace argumentů funkcí se to má podobně jako u validace třeba formulářů. Někdy je potřeba se ujistit, že jde o číslo od 1 do 10, jindy stačí vědět že jde o integer a jindy není potřeba ani to.

Jak dalece má validaci vstupu usnadňovat jazyk, jen na úroveň datových typů?

Co se mě týče, klidně si to ošetřím sám a u chybného vstupu hodím InvalidArgumentException (narozdíl od type hintingu, který používá obyčejný fatal error).

* K poslednímu bodu: Jo, standardní instalace PHP coby aplikační rámec za moc nestojí. Což je zároveň reakce na [26].

28. Ondřej Hadač | 3.1.2006, 21.38

Pane Snizku,

nechci Vas nikterak urazit, ale hodnotit PHP, pokud nejste programator je nesmysl.
Pisete, ze diky skole mate rozhled. I v te me skolce dostavam od ostrilenych programatoru aviza, jaky onen konkretni scriptovaci jazyk je a v cem predci nektery jiny. Avsak ja radeji, nez budu (z meho pohledu) tyto informace filtrovat na svem blogu, pomlcim a pokusim se (paklize me to skutecne zajima) nastudovat co mozna nejvice materialu (a pokud me to opravdu zajima) a neco zkusit naprogramovat (a nasledne srovnat s jinym jazykem).

Timto clankem jste zbytecne pichl do vosiho hnizdecka, ale prosim, je to Vas blog :)

Na zaver bych rad rekl, ze Vase clanky se mi (az na nektere vyjimky) velice libi a dekuji Vam za ne.

29. Martin Snížek | 3.1.2006, 21.56

[28] Já tady nefiltruju cizí názory. Na škole se učíme hlavně obecné zásady objektového návrhu a objektového programování na příkladu Javy. V PHP jsem zase napsal už pár webů, neříkám že velkých, ale dost na to, abych se probral dokumentací a část PHP se naučil. Navíc nemluvím o žádných detailech jazyka, ale o základním konceptu -- vadí mi na něm konkrétní věci, které jsou třeba v Javě lepší. Kromě toho jsem se o PHP bavil i s lidmi, kteří v něm projekty realizují (či řídí) a těm vadí podobné věci jako mně.

Souhlasím, že jsem píchl do vosího hnízda, i když jsem to tak trochu čekal. Na druhou stranu, myslím, že ne zbytečně, v diskusi se nejlépe dojde ke správným závěrům :-)

30. johno | 4.1.2006, 0.39

[21] No to s tými referenciami som to prestrelil. Objekty sa však priraďujú presne tak ako v Jave. Nechápem, čo Martinovi na tom vadí, keď Javu tak ospevuje.

[29] Jediné na čom sme sa tu doteraz zhodli je to, že PHP má zlú konvenciu pomenovania funkcií. Tie ostatné konkrétne veci sú nejaké zvláštne dohady, ktoré tu už boli zopár krát vyvrátené.

31. Roman Dagi Pichlik | 4.1.2006, 8.46

[5]PHP je před spuštěním zkompilováno do mezikódu podobně třeba jako Java, jen se tento mezikód nikam neukládá.

Java se sice kompiluje do platformove nezavisleho bytecode, ale to uz je na urovni kompilatoru. Behem zavadeni JVM a behu se provadi kompilace do nativniho kodu dane platformy a rika se tomu JIT kompilace. Tim padem odpada pomala interpretace.

[clanek]
Ojektové programování je složitější než procedurální a jeho výhody se dostavují až u větších projektů.

Martine to je nesmysl. Precti si nejaka knihu, kterou napsali lide, ktery rozumi objektove orientovanemu programovani treba Fowler, Beck, Gamma, Jones nebo z ceskych treba vzpominany Ruda Pecinovsky.

Tedka nekolik otazek pro slovutne obhajce PHP, vzdycky me jako Javistu zajima (vsechno se to tyka weboveho vyvoje):

1.) Hadam, ze nejake implementace MVC uz v PHP jsou?
2.) Existuje podpora Continuation, docela uzitecne pro vyvoj webovych aplikaci viz http://www.sweb.cz/pichlik/arc … ive.html#112807671779965454
3.) Existuje uz nejaky komponetne udalostni framework ala Java Server Faces nebo WinForms?
4.) Existuje podpora metaprogrammingu ala anotace?
5.) Existuje moznost AOP?
6.) Existuje nejaky ORM framework jak je v Jave Hibernate nebo standardizovany JDO?
7.) Existuje nejaky RAD nastroj pro tvorbu webovych aplikaci v PHP tka jako tomu je v pripade Java Studio Creatoru 2 (je zdarma)?
8.) Ma PHP primou podporu pro remoting ala Web Services?
9.) Existuji nejaky standard pro deployment web aplikaci?
10.) Existuje standard a podpora pro Autorizaci a Autentizaci, obdoba JAAS?

Diky za odpovedi.

32. Pin007 | 4.1.2006, 10.22

Souhlasim s tim, ze PHP neni dospeli programovaci jazyk. Ale zaroven rikam, ze PHP je vyborny skriptovaci jazyk.

Pokud budu potrebovat, aby muj projekt byl napsan obektove tak rozhodne nesahnu po PHP. Myslim si, ze drive nez budovat nejaky pokrocili obektovy model by PHP melo napr. ujednotit nazvoslovi a zbavit se dalsich neduhu minulosti.

PHP je vyborny skriptovaci jazyk. Pro webove projekty je zcela postacujici a pokud mi to dovoli platforma, troufnu si jej pouzit i na velke webove projekty.

Rozhodne v nem nema smysl programovat napr. komunikacni interface, ktery zpracovava rekneme stovky XML zprav za vterinu.

Kazdy programator by se mel zamyslet nad problemem a nad prostredky, ktere pouzije k vyreseni. Na vrabce nepujdu s kanonem a na lov lvu si, alespon ja osobne, nebudu brat polevkovou lzici :)

33. llook | 4.1.2006, 11.38

[31]
1.) Existuje jich víc ( http://www.phpwact.org/php/mvc_frameworks ). Nejvíc diskutované jsou pokud vím Mojavi (alá Struts) a CakePHP (alá Rails). Žádný se ještě ale neprosadil tak masově jako jejich vzory. Dgx už pěkně dlouho slibuje úplně nový - Nette. Na ten jsem docela zvědavý.
2.) Nevím a taky by mě zajímalo.
3.) PRADO http://www.xisc.com/
4., 5.) O tom nic nevím.
6.) Také jich existuje víc, ale většinou nic moc (viz http://wiki.cc/php/Object_Relational_Mapping ). Ze samostatných projektů je asi nejznámější Propel.
7., 8., 9., 10.) Ne.

Dlužno podotknout, že "slovutným obhájcem" péhápka nejsem.

34. Roman Dagi Pichlik | 4.1.2006, 12.18

[33] Propel vypada pekne, ale asi by mi vadilo, ze je to tak invazivni a taky jsem tam nikde nevsimnul transakcniho zpracovani a par dalsich drobnosti jako secondary cache a QL. Celkove vzato me to celkem prekvapilo, ze neco takoveho pro PHP existuje.

35. Pachollini | 4.1.2006, 12.24

Mimochodem: předvíčerem jsem viděl v metru velký inzerát v angličtině. Firma Sun hledá programátory v PHP. Asi na něm něco bude.
Ne, fakt nekecám ;-)

36. Pachollini | 4.1.2006, 12.24

Mimochodem: předvíčerem jsem viděl v metru velký inzerát v angličtině. Firma Sun hledá programátory v PHP. Asi na něm něco bude.
Ne, fakt nekecám ;-)

37. markon | 4.1.2006, 12.31

O tom, ze PHP se nehodi na vetsi projekty bych silne polemizoval. Pro predstavu Wikipedia, jez bezi na solidni serverove farme a je clusterovana je napsana v PHP a jak ten projekt dobre funguje.

A takovyhle velkych projektu je obrovske mnozstvi. Zkuste ale ukazat jeden opravdu veliky projekt na Jave? Neni! Java mozna zvladne pristup do banky nebo do CRM systemu, ale nezvlada absolutne naport milionu UIP, neznam velky projekt, jez by fungoval na Jave.

Pokud uz ma nekdo velky projekt, pouzije Python, vsimnete si aktualniho vyvoje. Hlavni jadro aplikace se dela PHP a zatezove veci se delaji v Pythonu.

Navic po zprovozneni studentskeho systemu na VSE, jez je komplexne napsan v Jave a je pomalejsi nez Skoda 105 a deravejsi nez cednik ztracim absolutne pochybnosti nad tim, ze pri psani projektu zavisi na jazyku. Jazyk je prostredek jak se vyjadrit a tak berte PHP. Java neni o nic lepsi, muzete v ni napsat prasacky projekt stejne dobre jako v PHP a vykonnejsi rozhodne neni.

38. Roman Dagi Pichlik | 4.1.2006, 13.05

[37] To by me zajimalo podle ceho poznate, ze system bezi na Jave? Podle toho, ze v URL vidite jsp, nenechte se vysmat. Z tech ktere znate, treba eBay. Nechtel bych kecat, ale tusim ze i Yahoo.

Samozrejme, ze programy postavene na Jave zvladnou miliony UIP, podivejte se na nejake WS stacky kolik zvladaji zpracovat volani.

System VSE znam jenom velice zbezne a jedine co onem dokazu rict, ze je postaveny na Struts. To jak je to udelane vevnitr, na jakem serveru to bezi, to nedokazu rici. Ale dam vam za pravdu, ze i v Jave muzete zbastlit rychlou aplikaci stejne jako vyumelkovanou snekoidni aplikaci.

39. Roman Dagi Pichlik | 4.1.2006, 13.07

[36] ono se o integraci skriptovacich jazyku jako PHP pro tvorbu view uvazuje, dokonce je v tomhle smeru otevreny JCP, ale ze by to doslo uz tak daleko? :-)

40. Jan Brašna | 4.1.2006, 13.16

1.) K výše zmíněným bych ještě doplnil Symfony, jinak skutečně Mojavi a Cake jsou asi nezjznámější, každý používaný dle své charakteristiky. Na seznam všech už bylo také linkováno a Nette si taktéž zmínku zasloužil.

8.) Nevím, jak komplexní škála je potřeba, ale http://php.net/soap je k dispozici. Existují i další implementace, tužím jako PEAR/PECL popř. OS třídy.

41. Roman Dagi Pichlik | 4.1.2006, 13.29

[40] SOAP je pouze protokol, kterym se WS volaji. Ma PHP nejaky stnadard pro exportovani business logiky a nastroje k tomu urcene?

42. llook | 4.1.2006, 13.33

[37] No, je otázka, jestli by zvolili stejné prostředky, kdyby jim už na začátku někdo ukázal tenhle graf: http://en.wikipedia.org/wiki/I … edia_size_all_languages.png

[39] Specifikace JSP snad dovoluje pro skriptlety použít jakýkoli jazyk, ne? Schází akorát implementace... Ale možná jsem teď řekl kravinu, o Javu se zajímám zatím jen okrajově.

43. Martin Snížek | 4.1.2006, 13.49

[31] Když srovnám, co se člověk musí naučit, aby si napsal web v PHP, a co se musí naučit, aby ho napsal v Javě, tak je Java složitější. Malý web se dá ale v pohodě napsat přehledně a tak, aby se dal později upravovat a rozvíjet, i v PHP. Java v takovém případě nemá výhody a má jen nevýhodu v podobě těžšího naučení.

44. Roman Dagi Pichlik | 4.1.2006, 13.54

[42] add scriptlety.) ano teoreticky lze viz psecifikace

JSP.1.12.2 Scriptlets
Scriptlets can contain any code fragments that are valid for the scripting language specified in the language attribute of the page directive.

Ale ten JSP proces je mnohem komplexnejsi, treba jak zpristupnit javovske objekty daneho page contextu pro PHP

45. Roman Dagi Pichlik | 4.1.2006, 13.56

[43] S takovym RAD nastrojem jako Java Studio Creator 2 o tom nejsem presvedcen. Zkus si ho Martine stahnout a vyzkouset ze stranek Sunu. Kdyz jsem ho zkousel na testech pouzitelnosti, tak mi malem vypadli oci z dulku. Kolega na tom byl podobne.

46. Roman Dagi Pichlik | 4.1.2006, 14.04

[45]vypadly oci jsme chtel napsat

47. Jakub Vrána | 4.1.2006, 14.32

[38] Myslíte to stejné Yahoo, které zaměstnává Rasmuse Lerdorfa, původního tvůrce PHP?

Nevím, jestli na něco používají Javu, každopádně vím, že několik svých služeb provozují na PHP.

48. Martin Snížek | 4.1.2006, 14.36

Komentáře už se tady začínají trochu točit v kruhu, takže bych si dovolil diskusi uzavřít. Pokud shrnu, co z ní vyšlo:

* PHP se dá použít i pro větší projekt, ale je potřeba nastolit jasná pravidla pro syntaxi, pojmenovávání a umísťování souborů a využívat nástroje a frameworky, které nejsou součástí jádra PHP. Musí na něm také pracovat lidé s většími znalostmi a přehledem než jen PHP, aby nedělali začátečnické chyby, které se v PHP dělat dají.

* V PHP nejsou tak snadno dostupné některé pokročilejší knihovny -- viz komentáře [7], [31] a [33].

* Ohledně nemožnosti používání výjimek pro standardní funkce a nesystematičnosti v pojmenovávání funkcí PHP jsem měl pravdu, ohledně vývojařských nástrojů již tolik ne. Netypovost jazyka je pro někoho výhodou, pro někoho (třeba mě) nevýhodou.

* Výhodou PHP je také široká komunita vývojařů a široká nabídka již hotových knihoven.

* Největší devizou PHP je snadnost na první naučení, kvůli tomu ale dělá PHP mnoho málo znalých lidí a vznikají špatné aplikace.

Gró této diskuse je asi v tom, že některým lidem, mezi které patřím, připadá PHP "prasácké" a nesystematické (díky tomu jednoduché na první naučení a tím pádem populární). Některým jiným ale ne. Obě strany mají své argumenty a nemá cenu je neustále přetřásat -- ať si každý používá, co mu vyhovuje.

Přidat komentář

Lituji, ale komentáře k tomuto článku již byly uzavřeny. Další není možné přidávat. Pokud mi i přesto chcete sdělit svůj názor na článek, kontaktujte mě.

© Martin Snížek 2005-2016.   ISSN 1802-2103.