Facebook otevře HipHop - čerstvě vyvinutý překladač z PHP do C++

Facebook otevře HipHop - čerstvě vyvinutý překladač z PHP do C++. HipHop snižuje nároky na systém při vykonávání skriptů. Byl vyvíjen dva roky a běží na něm 90 % webového provozu na Facebooku. Zatím není kompatibilní s web serverem Apache, ani s PHP 5.3. Více na ITBiz.cz.

4.2.2010 14:09 | Robert Krátký | Zajímavý software

Komentáře

[washeck]

Chápu, že chcete podpořit ITbiz, ale dělat to způsobem, kdy jejich zprávička obsahuje jinými slovy totéž a jediná přidaná hodnota je v odkazu na původní zdroj (který zde chybí) je hodně trapné.

Doufám, že se nehodláte vydat cestou Rootu a Lupy, kde tak dlouho vzájemně prolinkovávali bláboly pana Bednáře, až jsem smazal z RSS čtečky oba servery a prakticky tam nechodím.

[Robert Krátký]

Vynechaný původní zdroj je opomenutí, ne úmysl - napravil jsem. Je pravda, že chceme podpořit ITBiz, ale zároveň se snažím být konzistentní - když například píšu zprávičku o něčem, co najdu na Slashdotu, také uvedu i link na Slashdot - jako slušnost vůči zdroji.

[Radek Miček]

Docela se divím, proč je FB psaný z velké části zrovna v PHP.

[eax]

no asi preto ze to zacalo ako studentsky projekt na univerzite, a potom sa to postupne nabalovalo az tak ze sa to nikomu nechcelo prepisat :)

btw. v com by ste taky facebook riesili vy ? python ? java ?

[Radek Miček]

btw. v com by ste taky facebook riesili vy ? python ? java ?

Určitě ne v jazyce, který je slabě typovaný a nemá rozumný systém modulů/balíčků. Také bych si asi rozmyslel, jestli je úplně nejlepší vlastnost, že to, co je mimo <?php a ?>, se posílá na výstup.

[pasmen]

Také bych si asi rozmyslel, jestli je úplně nejlepší vlastnost, že to, co je mimo <?php a ?>, se posílá na výstup.

Proč je tohle problém?

[Radek Miček]

Může se stát, že se před otevírací <?php dostane třeba mezera, a to pak může být problém. Navíc, tam, kde používají šablonovací systémy, se tato featura nepoužije.

[pasmen]

Chápu, taková mezera, to je velká bezpečnostní díra Stejně tak se u printf("xxx") může dostat mezera za otevírací "

[AHAHA]

Problem je treba v hlavickach - jakmile poslete jeden byte vystupu, nemuzete nastavit hlavicky odpovedi (protoze hlavicky predchazeji obsahu).

[pasmen]

Jo to je fakt, to jsem si neuvědomil.

[R]

Nevsimol som si, ze by to bol nejaky problem. Vyrobi to warning, takze to lahko opravim. Sama o sebe sa tam ta medzera nedostane, slusny programator si dava pozor na to, co robi.

[Radek Miček]

slusny programator si dava pozor na to, co robi

IMO je lepší, když problematické situace nemohou nastat, než když programátor musí hlídat, aby nenastaly.

[Andrej Herceg]

A čo keď sa pred volanie funkcie header "dostane" nejaké echo (alebo iná funkcia, ktorá niečo vypíše)? Aj na to má dať pozor PHP?

[vlastikroot]

Dá se to dost pěkně vyřešit pomocí output bufferingu (který používám i např. na převod z XHTML na HTML4 pro prohlížeče nepodporující XHTML).

[Radek Miček]

Obecně hlídat, jestli se před voláním header zavolá echo, je nerozhodnutelný problém.

Já nechci tvrdit, co by PHP mělo nebo nemělo, nicméně si myslím, že by jazyk (nebo alespoň jeho implementace) měl podobné situace hlídat (nebo jim nějak zamezit), čím více chyb zachytí ještě před spuštěním programu, tím lépe.

[AHAHA]

Pokud ma program rozumnou architekturu (napr. MVC), tak je riziko neceho takoveho minimalni ...

[AHAHA]

S tim jsem se nesetkal, problemy ale mohou vzniknout: - na konci, tj. za ?> - nektere editory vkladaji na konec souboru prazdny radek. Lze snadno vyresit tim, ze se ?> neuvede, PHP pak povazuje cely zbytek souboru za kod - nektere editory (na Winech) vkladaji do souboru v UTF BOM. Tady nezbyva nez se takovym editorum vyhnout.

[AHAHA]

PHP samotne je sablonovaci jazyk

[Marek Bernát]

<?php ?> je len jeden z miliónov spôsobov, ako spraviť interfejs medzi webserverom a jazykom. Ak si napíšem modul haskellu pre apache, kde bude úplne rovnako fungovať <?haskell ?>, tak to spraví z haskellu zlý jazyk? A naopak, aj pre PHP existujú iné metódy ako ho spojiť s webserverom. Ničmenej, s prvou časťou komentára súhlasím, takže najjednoduchšie je PHP nepoužívať vôbec, ak človeka zrovna nenútia revolverom priloženým ku spánku

[error414]

nevyjadrovat se o necem o cem vim prd, dobre je drzet se toho pravidla.

[Radek Miček]

A něco konkrétního by nebylo?

[error414]

duvody proc je php nevhodne na vetsi projekty jsou jine.

[Radek Miček]

Můžete se podělit o svůj názor.

Ještě dodám, že to, co jsem jmenoval, považuji za špatné i pro malé projekty a bohužel, pokud vím, tak se v PHP 6 nic nezmění.

[Luboš Doležel (Doli)]

Určitě ne v jazyce, co defaultně escapuje uvozovky, aby si lamy neudělaly do systému díru...

[AHAHA]

Nevim, jak to je v PHP 5.2 a starsich, ale v PHP 5.3 jsou defaultne vypnute (a pri zapnuti vyhazuji E_DEPRECATED) a v PHP 6 nebudou uplne. Nicmene, stejne jako u linuxu:

- pokud si to uz nekdo kompiluje sam, asi vi co dela

- ten zbytek pouzivaji PHP od distributora nebo v ramci nejakeho balicku (XAMPP)

Jinak ale miluju tu logiku - PHP pouziva hodne lam => PHP je jazyk pro lamy => Programatori v PHP jsou lamy.

[Luboš Doležel (Doli)]

PHP vzniklo jako nástroj pro lamy. Bordel bez ladu a skladu, na který se dolepují featury, aby se prodloužila životnost. Jediná výhoda je, že to nabízí prakticky každý webhosting a je v tom hodně napsáno.

Pro větší než drobné projekty zcela nevhodné, a přesto používané. I v případě Facebooku je PHP použito jen pro prezentační vrstvu.

[AHAHA]

PHP vzniklo jako nástroj pro lamy. Bordel bez ladu a skladu, na který se dolepují featury, aby se prodloužila životnost.

To ano. Presto to neznamena, ze v nem nejde napsat kvalitni kod.

Jediná výhoda je, že to nabízí prakticky každý webhosting a je v tom hodně napsáno.

Ta druha vyhoda je dost kriticka.

Pro větší než drobné projekty zcela nevhodné, a přesto používané.

Proc?

[pasmen]

Pro větší než drobné projekty zcela nevhodné

Nechápu proč. Pro PHP přece existuje spousta kvalitních frameworků (třeba Nette), s jejichž pomocí se dají větší věci bez problémů (a celkem kvalitně) psát. Možná máš na mysli jen staré funkcionální PHP?

[xm]

PHP a funkcionální? To je dobrý vtip Asi jste měl na mysli imperativní, ne? Nicméně s těmi MVC frameworky souhlasím, taková Kohana nebo CakePHP je také dost kvalitní. Nicméně od té doby co dělám v Pythonu je pro mě stejně jakákoliv práce v PHP utrpení

[Marek Bernát]

Máte asi na mysli neobjektové PHP v zmysle používania funkcií namiesto metód? Lebo funkcionálne PHP nebolo, nie je a asi ani nebude nikdy. Akurát v posledných verziách dolepili zopár funkcionálnych vlastností (lambda funkcie, uzávery).

[pasmen]

Eh, no samozřejmě máte oba pravdu. Měl jsme na mysli používání funkcí místo metod tříd. Doteď jsem slyšel slovo funkcionální programování jen párkrát. Takže sorry voe error

[Luboš Doležel (Doli)]

Mám na mysli celý koloběh, na kterém fungují PHP aplikace. Začít interpretovat kód -> připojit databázi -> načíst data -> vypsat data. Tohle prostě bude vždycky zoufale pomalé, třebaže existují řešení, jak to zoptimalizovat. Všechny ty Drupaly a obzvláště Joomly (pohroma!) jsou ve výsledku strašně HW náročné, jen to už lidem nepřipadá špatně...

Podívejte se na koloběh Java Servlet aplikace nebo podobných technologií, kde se jedná o skutečnou aplikaci, která se spouští a ukončuje podobně jako ty desktopové a pro kterou je web jen jiným typem uživatelského rozhraní.

[pasmen]

Já teda do Javy zatím moc nevidím (bohužel), takže nedokážu posoudit. Nicméně neříká se právě o Java aplikacích, že jsou enormně HW náročné? Což z praxe mohu potvrdit (místo Exchange máme PostPath server, který má části psané v Javě). Jinak co se týče té posloupnosti operací pro PHP - interpretace kódu budiž, přesto se dá použít něco jako memcached, připojení k db může být přece persistentní, db queries jdou také velice dobře cachovat (praxe), výpis dat bude pro jednotlivé jazyky porovnatelný.

[Luboš Doležel (Doli)]

Jsou náročné, ale ve srovnání s PHP je to prd. S tím mám zkušenosi z webhostingové firmy, kde kdejaká Joomla nebo Drupal dokážou dostat kdejaký horší server do kolen, kdykoliv tam přišlo víc návštěvníků najednou

"Joomla a Drupal" se považovalo za diagnózu problému, jakmile byla odhalena přítomnost jednoho s těchhle dvou, dál se nemuselo nic zkoumat.

[pasmen]

Dobrá, nechám se poučit. I když stejně... Laicky bych řekl, že už snad nemůže být nic méně náročného než interpret jazyka jako PHP. Naproti tomu Java musí mít obrovskou režii pro VM. Ale říkám, nevidím do toho, takže netuším kde je pravda.

[Radek Miček]

Ale běhové prostředí pro PHP musí dělat v podstatě totéž co běhové prostředí pro Javu. Rozdíl je třeba v tom, že v Javě máte (většinou) "lepší" typovou informaci, takže k proměnným není potřeba ukládat jejich typ, testovat typy za běhu atd.

[kralyk z abclinuxu]

A navíc java má Java Bytecode a další optimalizace, které PHP nemá, takže režie PHP interpreteru je o dost vyšší než JVM.

[bckp]

I PHP ma bytecompiler bcompiler se to jmenuje....

Jinak obecně, každý scriptovací jazyk nemůže být rychlejší než jazyk nativní... pokud má být ale rychlost argument, je třeba zahodit Javu, Python, Perl, JS, .NET, protože jediná správná cesta je C++, C, Goo a podobne jazyky.... ( trošku nesmysl ne? )

PHP není špatný jazyk, jenom není vhodný pro velké projekty, ale i ty se dají napsat, FB je krásným příkladem.

Ano, v PHP se dá prasit a psát lamovský kód, ale v čem ne? I v C# můžu napsat hnusně zprasený kód... Tak v čem je PHP jiné??

Mezery před které vkládají editory (což nepovažuju za chybu PHP) se dají ošetřit output bufferem, najednou PHP neřve, a vy můžete odesílat hlavičku uprostřed scriptu kde jste předtím napsali 10x echo... (ano, toto může působit prasácky)

[Marek Bernát]

Otázka je, jak moc sa dá v ktorom jazyku prasiť a jak je k tomu kompilátor/interpreter tolerantný. V PHP je to ďaleko za únosnou mierou.

[Filip Jirsák]

Jinak obecně, každý scriptovací jazyk nemůže být rychlejší než jazyk nativní...

Není zas tak těžké uvědomit si, že to není pravda.

[imploder]

Pokud je program ideálně optimalizovaný (nejvíc, jak to v daném jazyce jde), tak je to pravda. Z tohoto pohledu je ale úplně nejlepší assembler, takže je vidět, jak je absurdní. V praxi program dokonale optimalizovaný nebude a ve skriptovacím jazyce může vyjít rychlejší.

[Radek Miček]

Prostě čím více máte o programu informací, tím lépe jej můžete optimalizovat.

[Luboš Doležel (Doli)]

PHP má docela dost vysokou režii. Realita Javy je taková, že JVM si zabere hodně paměti, ale velkou část jí nevyužívá, prostě s tím pokrývá výkyvy. To je sice špatné, když je na serveru více věcí než jen webserver, ale realita viditelná v JConsole je taková, že javovské aplikace z alokované paměti reálně žerou docela málo.

Podívej se na hromadu PHP aplikací, kde musíš zvedat max. paměti třeba na 100 MB (per request!). U Javy může žrát těch 200 MB na všechny požadavky souběžně...

[Bedňa]

Stačí porovnať rýchlosť celosvetových webov o PHP v PHP a Abclinuxu naklepané v Jave kde si píše naraz 5 ludí a myslím že je to jasné, Javu som skúšal lebo je premakaná oproti C++, ale výkon katastrofa, je to tak už roky a iné to nebude.

[Luboš Doležel (Doli)]

Skutečnost je taková, že ty celosvětové weby běží na farmě serverů, kdežto Abc běží na jednom serveru. Výborný výkon javovského řešení ukázaly návaly ze Slashdotu, které aplikace zvládla naprosto bez problémů.

Pamětníci vědí, že to sice jednou padlo, ale to bylo vinou imbecilně nastaveného firewallu. Řešit obranu proti DoSu omezením počtu všech spojení na server, to je zcela nad mé chápání. Takové nastavení DoS spíš velmi usnadní...

[Bedňa]

Je jasné že keď príde k pádu serveru vlivom preťaženia, znamená to že je zle nastavený server a Java, alebo iný "Jazyk" s tým nemá nič spoločné, aj keby bol sebepomalší vždy podľa toho má byť nastavený aj server a chápem človeka ktorý ovláda zložitý jazyk ako Java že neuzná nejakému easy jazyku aj jeho výhody, vždy už to bude už s pohľadu "aha chlapci sa hrajú"

[Luboš Doležel (Doli)]

Ten jazyk přímo ne, ale jeho implementace a architektura aplikací, které se nad ním stavějí, ty za to mohou.

[Marek Bernát]

S tým výkonom si dosť mimo. Kedysi to bolo ďaleko horšie, dnes je rýchlosť Javy inde a ku C++ má rozhodne ďaleko ďaleko bližšie než nejaké PHP (o rády). A bude to ešte lepšie, lebo JIT kompilátory zďaleka nepovedali posledné slovo. Btw, porovnávať jazyky, na základe nejakých benchmarkov webových aplikácií, v ktorých ide obvykle predovšetkým o rýchlosť prístupu k databáze, je trochu nevhodné

[Bedňa]

Ja nepozerám na benchmarkové testy, skôr vlastné skúsenosti, teraz už nič čo začína na j ani neinštalujem, našťastie to "j" tam autory Java softu dosť často dávajú ako výstrahu Ale musím povedať že sa Jave chcem znova pozrieť pod kabát, kúpil som Androida a chcel by som zbúchať nejakú jednoduchú app.

[Marek Bernát]

Húm hóm, tak javovské aplikácie ani mne nepripadali nikdy 2x rýchle a vždy žrali strašne veľa pamäte (na čo zástancovia Javy obvykle odpovedajú, že si človek má kúpiť silnejšie CPU a viac RAM...), ale IMHO je to oveľa viac problém zlého programovania, než toho, že by ten jazyk bol inherentne pomalý (a ani nemá prečo. Je to síce VM, ale s poriadnym JIT kompilátorom, ktorý ľudia od Sunu stále vylepšujú, sa tá rýchlosť blíži predkompilovanému kódu).

[Luboš Doležel (Doli)]

Java je na desktopu fuj, tam se z X různých důvodů nehodí.

[Marek Bernát]

V princípe nevidím žiadny dôvod, prečo by Java mala byť pre desktop fuj a napr. C(++) nie. Všetky tie jazyky majú kopu výhod a kopu nevýhod. Javovské programy majú teda problém s GUI (aspoň z môjho pohľadu je to na hranici (ne)použiteľnosti), ale to nie je problém jazyka ako takého.

[Luboš Doležel (Doli)]

Jasně, je to problém implementace JVM.

[Heron]

To je dobré řešení, odstraňovat na webhostingu náročné weby

Tím ovšem nijak nechci hájit php, naopak souhlasím s tím že kolečko: zapnout, vstup, interpret, db, výstup, vypnout (pro každý http požadavek) je dost nevhodné.

[Luboš Doležel (Doli)]

Jinak co se týče té posloupnosti operací pro PHP - interpretace kódu budiž, přesto se dá použít něco jako memcached, připojení k db může být přece persistentní, db queries jdou také velice dobře cachovat (praxe), výpis dat bude pro jednotlivé jazyky porovnatelný.

Vem si, že v Javě můžeš zkombinovat Hibernate (který má cache na objekty z DB a na výsledky dotazů) a ještě mít často užívané věci (v redakčáku třeba položky z levého sloupce) jednoduše v globálních proměnných. Třeba když budeš mít v Lucene databází pro vyhledávání na webu, tak jí máš trvale načtenou v paměti... to nepřebiješ.

[Ladicek]

Vem si, že v Javě můžeš zkombinovat Hibernate (který má cache na objekty z DB a na výsledky dotazů)

A přesto je to bezkonkurenčně nejpomalejší a venkoncem nejproblematičtější způsob přístupu k datům, jaký si lze vůbec představit

Já se původně do téhle debaty nechtěl zapojovat, protože tady občas padají opravdové perly, ale tohle už prostě bylo moc. Jako bych nic neřekl

[JoHnY2]

Je to klasickej pripad preframeworkovani Javy. Lidi maj dneska dojem, ze je dobrej napad mit pod jednoduchou aplikaci o par tisich radku nekolik frameworku a vrstev. Pri programovani to chce pouzivat nastroje primereny zadani.

[Leoš Literák]

Fakt by mě zajimalo, jak by si vedla PHP verze abíčka v porovnání se současnou psanou v Javě. Můj odhad je, že by bylo o dost pomalejší, už jen kvůli obrovskému množství cachí, které jsou persistentní mezi různými requesty. PHP nesleduji už asi osm let, třeba už má podobnou funkčnost ..

[Marek Bernát]

Chjo, tak znova... Toto nie je vlastnosť jazyka, ale čisto jeho spojenia s webserverom. Áno, ja viem, ľudí to mätie, keď 99.9% inštalácii PHP je cez libphp v apache a zamieňajú jazyk samotný s apachovským modulom, ale aj tak by nebolo od veci sa vyjadrovať trochu presnejšie

[Filip Jirsák]

Když se porovnávají rychlosti programů, logicky se porovnává implementace jazyka, ne jazyk jako takový. Ono totiž nezáleží na tom, jestli ty instrukce na procesoru původně vznikly z Javy nebo z PHP, procesor je provádí pořád stejně rychle. Takže porovnáváte rychlost běhových prostředí, knihoven, efektivnost výsledného kódu – a to vše je záležitostí implementace.

Takže lidé, kteří dokáží používat i běžný selský rozum, nepotřebují přesnou definici toho, co se myslí Javou (zda jazyk nebo nejrozšířenější implementace) a co PHP (zda jazyk nebo nejrozšířenější implementace).

[Marek Bernát]

Tu sa neporovnávajú rýchlosti. Leoš písal o nejakých nových vlastnostiach jazyka, ktoré by mali umožňovať perzistenciu stavu. Ja som len upozornil, že to s jazykom nijak nesúvisí, je to dané čisto majoritným apache modulom, ktorý toto nikdy neumožňoval a nikdy umožňovať nebude, proste kvôli tomu, jak je koncipovaný (ako skript interpreter).

Ak sa porozhliadnete po tejto diskusii, tak si všimnete, že to je v skutočnosti úplne inak a to tak, že väčšina ľudí (a to sme na abclinuxu ešte v ďaleko lepších podmienkach, čo sa kvality programátorov týka, než bežní PHP hurá programátori tam vonku) si ani neuvedomí, že existuje rozdiel medzi PHP ako jazykom a libphp ako apache modulom. Preto má podľa mňa zmysel na to poukazovať.

[Filip Jirsák]

Tu sa neporovnávajú rýchlosti.

Ano, věta „můj odhad je, že by bylo o dost pomalejší“ s rychlostí vůbec nijak nesouvisí…

Ja som len upozornil, že to s jazykom nijak nesúvisí

A já se vám marně snažím vysvětlit, že se zde neporovnávají jazyky (gramatika), ale majoritní implementace (kompilátor+běhové prostředí, runtime knihovny), kterým se říká stejně, jako těm jazykům.

Ak sa porozhliadnete po tejto diskusii, tak si všimnete, že to je v skutočnosti úplne inak a to tak, že väčšina ľudí (a to sme na abclinuxu ešte v ďaleko lepších podmienkach, čo sa kvality programátorov týka, než bežní PHP hurá programátori tam vonku) si ani neuvedomí, že existuje rozdiel medzi PHP ako jazykom a libphp ako apache modulom. Preto má podľa mňa zmysel na to poukazovať.

To je od vás hezké, že na to poukazujete, ale tady všichni vědí, že se diskutuje o konkrétní implementaci – jediný, kdo to nechápe, jste vy.

[Marek Bernát]

Zaujímavé. Leoš nižšie špecifikoval, že mal na mysli _ľubovoľnú implementáciu_. Takže minimálne ja a Leoš o tom, že sa bavíme o konkrétnej implementácii nevieme. A myslím si, že nás takých bude viac. Ale pán Jirsák je samozrejme schopný hovoriť za celé ľudstvo... Btw, keby ste sa trochu zamysleli, tak by Vám došlo, že sa nemohlo jednať o konkrétnu apache implementáciu, pretože tá niečo ako cache neumožňuje z princípu: interpreter sa spúšťa pre každý request znova. Jediná možnosť ako docieliť cachovania, je zmeniť ten modul, alebo napísať nový. V oboch prípadoch dostanete novú implementáciu

[Filip Jirsák]

Takže napíšete implementaci pro PHP překládané do bajtkódu pro JVM, pak ještě napíšete ten překladač, a dostanete implementaci srovnatelnou s implementací v Javě (protože v ideálním případě dostanete bajtkód identický s tím, který používá dnes Abíčko). K tomu asi ale nebude třeba to prakticky zkoušet, protože to víme všichni, že identický bajtkód poběží v JVM pořád stejně rychle, nezávisle na tom, jak vznikl.

Druhá věc je, jestli je rozumné takový překladač psát, zvlášť kdyby byl na jedno použití. Asi to moc rozumné není, takže se okruh našeho zájmu zužuje na existující implementace. Takže bych očekával, že napíšete, která existující implementace má ten potřebný výkon.

[Radim Kolář]

Prekladacu PHP do javy je nekolik. Neznamejsi a do produkce vhodne jsou:

1. project Zero
2. quercus

[Marek Bernát]

Podľa mňa to rozumné nie je; sám som ten posledný, kto by PHP používal Ja som chcel len trochu vyjasniť ten zmätok okolo otázky jazyk/implementácia, ktorá určite nie je tak jednoznačná, jak ste sa snažili tvrdiť. Len na okraj, ak ste ešte nezabudli, tak celá táto diskusia je pod správičkou o prekladači PHP do C++

Inak som samozrejme netušil, že pod mojou krátkou poznámkou sa rozbehne takýto flame, ktorý už začína byť pomaly ale isto OT. Asi si po vzore Ládička nabudúce rozmyslím, či má nejaký zmysel sa do týchto diskusií vôbec zapájať

[Luboš Doležel (Doli)]

Tak mi ukaž, jak snadno udělám PHP aplikaci ve stylu servletu. Tzn. trvale běžící aplikace přijímající požadavky od web serveru.

[Marek Bernát]

Neukážem ti ju. Možno taký apache modul existuje, možno nie (pre python aj pre ruby existujú, takže by som sa nečudoval, keby existoval aj pre PHP). Ničmenej moja pointa bola, že to, čo žiadal Leoš (perzistencia dát, cache, ...) nikdy v tom súčasnom module nebude, už z toho dôvodu, jak je postavený. Takže to nie je otázka nových vlastností jazyka, je to len otázka napísania nového apache modulu. Toť vsjo, nič viac som nechcel povedať.

[Leoš Literák]

Tak jinak: jsem schopen napsat abicko pomoci PHP (libovolna implementace), aby rychlosti konkurovalo jave, ktera ma (mimo jine) vyhodu persistentnich cachi?

[Marek Bernát]

V princípe určite áno. Treba ale na to netriviálne znalosti (tzn. ďaleko väčšie, než má väčšina PHP programátorov) a v tom prípade už nevidím dôvod PHP vôbec používať, keď máme desiatky lepších jazykov, vrátane Javy.

[AHAHA]

Mám na mysli celý koloběh, na kterém fungují PHP aplikace. Začít interpretovat kód -> připojit databázi -> načíst data -> vypsat data.

Tento kolobeh znacne zjednodusuje tvorbu aplikaci, protoze se muzes spolehnout, ze aplikace je pred request vzdy ve stejnem stavu. Duvod, proc Drupal a Joomla jsou pomale lezi IMHO uplne nekde jinde ...

[Marek Bernát]

Aplikácia pred requestom nie je a nemôže byť v rovnakom stave, ak nie sú tie stránky úplne statické. Čo prístup na stránky od prihláseného/neprihláseného používateľa. Skutočne je to úplne rovnaké? Práve naopak, človek by ideálne chcel aplikáciu so skutočným stavom (tj. aplikačný server), ktorá by spracovávala požiadavky klienta (preposlané cez webserver). Až na tejto úrovni sa dá hovoriť o poriadnej aplikácií. V PHP sa toto rieši pomocou $_SESSION, ukladaní stavu do databáze, a pod., proste stav sa niekam odkladá, ale treba si uvedomiť, že sú to všetko len obezličky, ktoré majú nahradiť hlavný nedostatok a to je ten, že sa nedá napísať poriadna serverová aplikácia, ktorá by mala stav proste permanente uložený v pamäti. Pre malé weby to je výhoda, lebo tam si aplikácie veľa stavu pamätať nepotrebujú. IMHO toto mal Luboš na mysli, keď povedal, že PHP je pre väčšie projekty nevhodné.

[Marek Bernát]

Ešte doplním, že toto opäť nie je problém PHP ako jazyku, ale problém jeho najčastejšieho využitia pomocou libphp apache modulu. V princípe nie je problém použiť PHP na napísanie serverovej aplikácie, ktorá spracováva požiadavky (napr. pre python aj ruby existujú obe možnosti, jednak interpretácia skriptov ako bežne s PHP, jednak poriadne aplikácie), ale otázka je, či by v tomto prípade ešte malo nejaký zmysel PHP použiť a nebolo by lepšie siahnuť po lepšom jazyku; či už dynamickom (python, ruby), alebo statickom (java, c#), alebo pokojne po niečom exotickejšom (smalltalk seaside)

[AHAHA]

Mel jsem na mysli stav aplikace a jeji pameti, ne data (ulozena treba v databazi). Sessions je trochu vyjimka, protoze je to vlastne pamet mapovana na soubor, pricemz vlastne je soucasti requestu, protoze je urcena pomoci session id.

Práve naopak, človek by ideálne chcel aplikáciu so skutočným stavom (tj. aplikačný server), ktorá by spracovávala požiadavky klienta (preposlané cez webserver). Až na tejto úrovni sa dá hovoriť o poriadnej aplikácií.

Samozrejme, a jak jste nekde napsal tak to neni o tom, ze by to neslo, ale ze je to nepohodlne a pracne. Je to proste prace navic, kterou v mnoha pripadech proste neocenite ...

V PHP sa toto rieši pomocou $_SESSION, ukladaní stavu do databáze, a pod., proste stav sa niekam odkladá, ale treba si uvedomiť, že sú to všetko len obezličky, ktoré majú nahradiť hlavný nedostatok a to je ten, že sa nedá napísať poriadna serverová aplikácia, ktorá by mala stav proste permanente uložený v pamäti.

Skutecne chceme mit stav ulozeny v pameti? Co kdyz program spadne? Jak pak snadno obnovime predchozi stav? Co v pripade soubezne bezicich instanci?

[pasmen]

Aktuální stav je podle mě dobré držet v paměti. Ve chvíli, kdy teprve dojde ke korektnímu ukončení nějaké transakce se takto konzistentní stav uloží do databáze a stav v paměti se podle toho aktualizuje. Při pádu máš pak zaručeno, že databáze obsahuje jen konzistentní data i za cenu toho, že rozdělané transakce holt o své stavy přišli.

[Marek Bernát]

Tak. Databáza má IMHO slúžiť len na dve veci: 1) ako zbierka dát, nad ktorými sa dá efektívne vyhľadávať, 2) ako záloha stavu aplikácie. Pre ten účel číslo 2 sa dá rovnako dobre zálohovať na disk, alebo hocikam inam. Problém je, keď sa databáza začne zneužívať na udržiavanie stavu, kvôli tomu, že jazyk samotný to rozumne neumožňuje.

[Marek Bernát]

Ja tak isto. Ale do databáze sa dá uložiť aj ten stav. Session nie je žiadna výnimka, je to presne pamäť aplikácie. Bežná aplikácia v PHP nie je jeden .php súbor, ale ich kolekcia, ktorá interaguje cez $_SESSION, alebo cez databázu. Problém je, že toto nie je dobrá komunikácia v rámci jednej aplikácie pre väčšie projekty.

No, áno, ide to. Rovnako, ako sa dá presunúť tona piesku rukami namiesto použitia bágru

A čo ak ti spadne webserver? Čo ak vypnú elektrinu? Všetko sa to môže stať, ale v produkčnom prostredí existujú metódy, ako sa s tým vysporiadať. A medzi aplikačným serverom a webserverom nie je žiadny rozdiel. Oba sú to servere, na oba sa dajú použiť podobné metódy.

[AHAHA]

Session nie je žiadna výnimka, je to presne pamäť aplikácie.

Stejne jako $_GET a $_POST jsou taky jen pamet aplikace. Jde mi o to, ze vyber konkretni session je dan requestem (dle session id) a to i presto, ze obsah dane session je urcen aplikaci.

Bežná aplikácia v PHP nie je jeden .php súbor, ale ich kolekcia, ktorá interaguje cez $_SESSION, alebo cez databázu.

Proc by byla databaze na komunikaci mezi instancemi aplikace spatna? Databaze je perzistentni uloziste, pokud chcete uchovavat stavy mezi instancemi (nebo requesty), zda se mi to jako logicka volba.

A čo ak ti spadne webserver? Čo ak vypnú elektrinu? Všetko sa to môže stať, ale v produkčnom prostredí existujú metódy, ako sa s tým vysporiadať. A medzi aplikačným serverom a webserverom nie je žiadny rozdiel. Oba sú to servere, na oba sa dajú použiť podobné metódy.

Vtip je v tom, ze pokud vam spadne klidne cely system, jedine, co je potreba udelat je zapnout ho znovu. Diky perzistentnimu ulozeni stavu aplikace se jakoby nic nestalo. (toto se hodi i treba pri aktualizaci aplikace, neni potreba nic restartovat ...)

[pasmen]

Ta poslední část není úplně pravda. Stačí si představit, že na stejná data v databázi ti sahá ve stejný okamžik více lidí. Každý z těch uživatelů začne data zpracovávat a jednomu z nich to uprostřed spadne. Mezitím jiný uživatel dokončí operaci a data změní. První uživatel se opět přihlásí k již nekonzistentnímu stavu. A problém je na světě...

[error414]

tohle resi transakce, mysql ma "slusnou" podporu transakci pro innodb.

[pasmen]

Fakt? Nevěděl jsem, že MySQL má něco jako COMMIT a ROLLBACK.

[AHAHA]

Ma uz od verze 3 (je to spis zalezitost engine, tedy InnoDB a BDB, na novych se pracuje).

Krom toho samozrejme neni problem v PHP pouzit jinou DB.

[Marek Bernát]

Pletieš hrušky s jablkami. GET a POST sú HTTP metódy slúžiace na komunikáciu klienta so serverom pomocou HTTP protokolu. $_GET a $_POST sú potom už len access pointy k týmto dátam, ktoré apache dáva PHP skriptu. SESSION funguje úplne inak a nemá s HTTP nič spoločné

Áno, presne tak, je to perzistentné úložište, čiže má služiť maximálne ako backup stavu, nie ako miesto, kde sa aktuálny stav drží. Viete si predstaviť desktopovú aplikáciu, ktorá by celý svoj stav držala v databáze? Žiadna to nebude robiť (desktopové aplikácie používajú obvykle databázy na celkom iný účel a to, svete div sa, ako databázu, čiže kolekciu dát, nad ktorými sa vyhľadáva), lebo je to už z princípu pomalé a z rôznych dôvodov problematické (treba stav pri každom spustení aplikácie, čo je každý client request, všetko správne načítať z databázy a po skončení zasa uložiť. Pri oboch procesoch sa dá vyrobiť kopa zbytočných chýb). Keď má človek možnosť držať stav v pamäti, tak je to pochopiteľne oveľa lepšie. Používať databázu namiesto pamäte je len obezlička a perzistencia dát je len výhovorka, lebo sú možnosti ako si dáta ustrážiť.

Doporučujem Vám zistiť si, ako funguje softvér v telekomunikáciách, alebo v leteckých spoločnostiach. Skutočne si myslíte, že tieto aplikácie môžu vypovedať službu čo len na sekundu v priebehu celoročnej prevádzky? Pritom žiadne databázy nepotrebujú. Stači dostatočný paralelizmus a metódy samoopravy spadnutých procesov (viď Erlang).

[AHAHA]

Pletieš hrušky s jablkami. GET a POST sú HTTP metódy slúžiace na komunikáciu klienta so serverom pomocou HTTP protokolu. $_GET a $_POST sú potom už len access pointy k týmto dátam, ktoré apache dáva PHP skriptu. SESSION funguje úplne inak a nemá s HTTP nič spoločné

Vim, jak funguje session. Snazim se ale rict, ze session je dane bud pomoci session_id v GET nebo session_id v cookies, ktere prichazeji spolu s pozadavkem.

Áno, presne tak, je to perzistentné úložište, čiže má služiť maximálne ako backup stavu, nie ako miesto, kde sa aktuálny stav drží. Viete si predstaviť desktopovú aplikáciu, ktorá by celý svoj stav držala v databáze? Žiadna to nebude robiť (desktopové aplikácie používajú obvykle databázy na celkom iný účel a to, svete div sa, ako databázu, čiže kolekciu dát, nad ktorými sa vyhľadáva), lebo je to už z princípu pomalé a z rôznych dôvodov problematické (treba stav pri každom spustení aplikácie, čo je každý client request, všetko správne načítať z databázy a po skončení zasa uložiť. Pri oboch procesoch sa dá vyrobiť kopa zbytočných chýb). Keď má človek možnosť držať stav v pamäti, tak je to pochopiteľne oveľa lepšie. Používať databázu namiesto pamäte je len obezlička a perzistencia dát je len výhovorka, lebo sú možnosti ako si dáta ustrážiť.

Datove struktury musis mit v aplikaci tak jako tak a je jedno, jestli ti je poskytne databaze nebo si je naprogramujes sam. To, jestli bude databaze umistena v pameti nebo bude v souborech na disku je ciste vec tveho rozhodnuti.

Co ziskas, kdyz budes pouzivat DB (treba sqlite nebo firebird) ve sve (rekneme desktopove) aplikaci?

- jednotny pristup k datum at uz se rozhodnes ji mit v pameti nebo na disku

- nemusis znovu programovat kolo

- vysoky vykon, spolehlivost, skalovatelnost

- paralelni cteni i zapis (krom sqlite, kde paralelni zapis nejde)

atd.

[Luboš Doležel (Doli)]

Tento kolobeh znacne zjednodusuje tvorbu aplikaci, protoze se muzes spolehnout, ze aplikace je pred request vzdy ve stejnem stavu. Duvod, proc Drupal a Joomla jsou pomale lezi IMHO uplne nekde jinde ...

Ten důvod leží právě hlavně v tom, že pokaždé musí všechno tahat nanovo. Je to jako jet autem a na každé křižovatce nanovo startovat a rozjíždět auto.

[Bedňa]

Zaujímavé že najlepšie CMS sú napísané v PHP, Drupal a Joomla sú určite malé projekty ... a pozor nebyl to hloupý chlapec, byl s Prahy ...

[Luboš Doležel (Doli)]

To nevypovídá naprosto o ničem. To je jako prohlašovat, že Windows je nej OS, protože pro něj byly napsané nejlepší hry.

[Bedňa]

Nieje to tak dávno čo tu bol v zprávičkach odkaz na vyhodnotenie CMS a vo väčšine kritérií vyhral Drupal, takže keď je to PHP také zhovadilo lámerské ako je to možné? Poďalšie ja som nenapísal najrozšírenejšie (M$), ale najlepšie.

[Luboš Doležel (Doli)]

Ehm, takže když vyhraje CMS napsaný v Brainfucku, bude tenhle jazyk tím pádem dobrý? Kvalitu jazyka nelze moc dobře hodnotit na základě toho, že v tom někdo napsal dobrý software.

Poďalšie ja som nenapísal najrozšírenejšie (M$), ale najlepšie.

Však já jsem taky psal nejlepší.

[pasmen]

Ty jsi pouze uvedl, že PHP je jazyk pro projekty větší než drobné naprosto nevhodný. Zdá se, že výjimka potvrzuje pravidlo...

[Bedňa]

Vždy sa mi páčila matematika pretože má pevné pravidlá a podla toho čo tvrdíš vychádza že len v zlom programovacom jazyku sa dá naprogromovať dobrý program.

[Luboš Doležel (Doli)]

A BTW v Praze studuju, jinak jsem Jihočech.

[imploder]

To se dá vypnout (.htaccess: php_flag magic_quotes_gpc off) a v další verzi už to nebude (byla chyba to zavádět). Kdo není lama, vypne si to.

[JohnnyDoe]

Docela se divím, proč je FB psaný z velké části zrovna v PHP.

"PHP's roots are those of a scripting language, like Perl, Python, and Ruby, all of which have major benefits in terms of programmer productivity and the ability to iterate quickly on products. This is compared to more traditional compiled languages like C++ and interpreted languages like Java." -- viz odkaz ve zprávičce

[Senior Database Programmer]

As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug. Pozor, jednoduchost/primitivnost je jeho vyhoda, nie nevyhoda (samozrejme to zavisi pripad od pripadu).

[Josef Kufner]

Jo, taky nechápu, co proti němu všichni mají. Píše se v něm skvěle, běhá to rychle a že to má nějaké ty mušky? Který jazyk nemá...

Btw, ty kecy o nevhodnosti na veliké projekty jsou jen známkou neschopnosti slušně navrhnout program.

[Marek Bernát]

"Který jazyk nemá..."

Čo jazyky, o ktorých sa dá dokázať, že nemajú žiadne chyby? A na nich vybudované nástroje na dokazovanie programov. Pravda, bežní programátori sú skeptickí a tvrdia, že vyrobiť dôkaz zaberie oveľa viac času ako napísať samotný program

Btw, PHP nemá len tak nejaké mušky, ale poriadne muchy, ktorých je v každej novej verzii opravených na desiatky. O tom, že aj v zlom jazyku je dobrý programátor písať slušne, netreba polemizovať, ale to nič nemení na tom, že PHP je jeden obrovský bordel a je to čím ďalej tým horšie (funkcionálne programovanie a menné priestory sú chválitebné, ale ten spôsob, akým to zapracovali má k dokonalosti veľmi ďaleko...). Tak isto to ich "objektové programovanie" s miliónmi menných prepínačov, ktoré pribúdajú v každej druhej verzii (napr. kvôli nedostatočnej introspekcii tried) a jasne ukazujú, jak nevhodne to bolo celé navrhnuté. A čo napr. používateľska správa chýb? Majú veľmi zvláštnu ad hoc hranicu medzi vnútornými Zend chybami, na ktorých vyhorí samotný parser a človek už nič nenarobí a chybami, ktoré v súčasných verziách môže ešte programátor spracovať (vhodné na testovanie a debugovanie). Je toho proste moc. PHP nie je jazyk. PHP je trochu lepší shell...

[AHAHA]

Jake nedostatky vidite v PHP implementaci jmennych prostoru a lambda funkci a v cem je nedostatecna introspekce trid?

[Marek Bernát]

Nedostatky vidím v tom, že tak ako celé PHP, sú tam len dolepené a nie integrálnou súčasťou. Stačí porovnať s jazykom so slušnou správou modulov, napr. Haskell, Lisp, ale postačí aj Java. Lambda funkcie to isté. Holt je ich ťažko zapracovať do jazyka, ktorý má milión prepínačov typu global (ktoré sú pozostatkom ranného detstva PHP a v normálnom jazyku nemajú čo hľadať), a tým pádom nie je moc jasné, aký presne majú mať tie bindingy scope. Toto je ale problém aj lepšich jazykov, napr. Lispu, kde odchytiť do uzáveru lexikálnu premennú je niečo úplne iného ako odchytiť dynamickú (a to druhé je dokonca občas závislé od implementácie). Najjednoduchšie sa to rieši Schemeovský prístupom: všetky bindingy majú lexikálny scope. Toto by ale len tak nejaký imperatívny programátor asi moc neprežul

Introspekcia, zadať do googlu late static binding, ktoré pribudlo fakt len nedávno a zistíte, čo všetko bolo ešte nedávno prakticky nemožné (keď som chcel nájsť pravý objekt, ktorý volal oddedenú statickú metódu, musel som to riešiť pomocou debug backtrace a zopár hackov. Lepší spôsob som nenašiel ani osobne, ani na internete). Takýchto prepínačov bindingov má PHP opäť kopu a v prípade objektov je ten bordel s globálnymi, statickými, oddedenými priestormi samozrejme ešte ďaleko väčší než obvykle...

Aby som to zhrnul, tak celkovo za najväčší zdroj problémov PHP považujem to, že si dopredu neujasnili, aké presne bindingy od toho jazyka čakajú, takže použili všetky možné a teraz tú oceľovú guľu budú so sebou vliecť už navždy.

[AHAHA]

Te prvni casti se priznam moc nerozumim, ale diky za odpoved. Mne se tyto nove featury libi (hlavne lambda funkce, namespace moc nepouzivam) a problemy jsem s nimi nemel ...

K introspekci: tak to ano, tam PHP dost pokulhavalo, v PHP 5.3 je to ale znacne lepsi. Puvodne jsem tvuj komentar chapal ve smyslu reflection api, tzn. neco jako "vrat seznam metod daneho objektu/tridy".

[error414]

php by se melos rovnavat pythonem nebo ruby, to jsou podobne jazyky zhruba pro stejny ucel.

[Marek Bernát]

Veľmi by neuspelo. Ako python, tak ruby, majú celkom slušný základný návrh (nehovorím, že dokonalý, to ani omylom, ale aspoň niečo, na rozdiel od PHP). Ruby je ako potomok smalltalku čisto objektový a prakticky celý jazyk je v tomto zmysle konzistentný a kým sa človek nezačne hrabať v metaprogramovaní, tak na nejaké zákernosti nenarazí. Niekomu môžu vadiť perlovské syntaktické bonbóniky, ale to je už len detail. Python je na tom vcelku podobne, hoci je to trochu väčší bordel. Ale celkovo sa ani jeden z jazykov nedá s PHP porovnávať. Oba majú dobre spracované bindingy a správu premenných, objektové aj funkcionálne programovanie na veľmi slušnej úrovni (hoci python trochu pokrivkáva), sú silne typované, veľmi dobrý koncept modulov, dalo by sa pokračovať. PHP oproti týmto jazykom nemá prakticky žiadnu výhodu.

[Jakub Lucký]

má... hosting s PHP sežente kdekoliv... Hosting s Ruby/Pythonem obvykle něco stojí (a obvykle dost...)

[Marek Bernát]

To je síce pravda, ale zas tak hrozné to nie je. Navyše pre produkčnú aplikáciu už nemá človek problém trochu zainvestovať do komplexného serverového riešenia. Každopádne, ja som porovnával len jazyky samotné.

[Jakub Lucký]

Pro obyčejného student-webdesigner je to trochu problém... ale uznávám, že řešitelný...

[kralyk z abclinuxu]

No, oni tas ty free php hostingy nejsou žádná výhra. Jsou sice free, ale tomu odpovídá kvalita.

[error414]

python je podle me slabe typovany, dyt je skoro stejny jak php. ja python pokladam za vylepsene php.

BTW: nevim co mate porad stou typovosti jazyku. to ze je php slabe typovane je jenom dobre

[Radek Miček]

Ne, Python je silně a dynamicky typovaný, ale PHP je slabě a dynamicky, Java je silně a (víceméně) staticky, Agda je silně a staticky.

(Hranice mezi slabě a silně typovanými jazyky není přesně definována).

[Marek Bernát]

Ak pokladáš python za vylepšené PHP, tak buď neovládaš python, alebo PHP, alebo ani jedno

[Marek Bernát]

A btw, python je o 5 rokov starší, takže ak nemal Guido vešteckú guľu, ťažko sa mohol riadiť modelom PHP pri návrhu pythonu (aj keby PHP nejaký model malo...)

[Jakub Lucký]

No, mušky to má... A jako admin ty mušky moc rád nemám, protože tuhle jsem se podíval do debian changelogu PHP5 a od té doby nemám klidné spaní (někteří lidi mi to i kdysi říkali, ale to jsem radši ignoroval)

pro vaše porovnání: PHP Perl Python Ruby

Můžeme dát soutěž, kdo kde najde víc, security, urgency=high, denial of service a tak... A to by člověk řekl, že od 5.2 z roku 2006 se s tím nějak pokročilo...

[Radek Miček]

Podle čeho soudíte, že to běhá rychle?

Btw, ty kecy o nevhodnosti na veliké projekty jsou jen známkou neschopnosti slušně navrhnout program.

Myslím si, že je PHP v některých věcech příliš tolerantní.

[Jan Drábek]

Jestli to bude mít podobnou kvalitu jako oficiální PHP knihovny, tak potěš pánbůh!

[Jakub Lucký]

jakože víc bugů než řádků kódu a názvy funkcí generované z /dev/urandom? Jo, to bude pravé FBH-HPHPC++ peklo...

[Grunt]

Ježiš, Facebook, HipHop, PHP → C++. To je teda vražedná kombinace.

[cheaf]

+1 :D

[kralyk z abclinuxu]

Tak to bych nenasadil už jen kvůli tomu názvu

[kap]

+1 Ten název mě taky děsí :D

[Jakub Lucký]

Ale zase tahle super cool technologie pro ganxtaz a fellaz otevře zcela novou dimenzi špatných webů o 50Cent, TuPac atd...

[Grunt]

[kap]

:D Tak tohle mě dostalo :)

[kralyk z abclinuxu]

Tenhle článek je naprosto legendární...

[Yontalcar]

Taky doporučuji přečíst tohle: http://necyklopedie.wikia.com/wiki/Hip-hop

[xm]

Zasmál jsem se taky hezky Ale pak jsem si otevřel diskuzi pod tím článkem a smích mě rychle přešel :-/

Hip hop obecně nemám rád a ten pozérský styl okolo mě vytáčí, ale pořád bych se stokrát radši bavil s nějakým takovým "kchůl gangsta nigga" než s takovými arogantními, nesnášenlivými, rasistickými a fašistickými idioty, jakých je ta diskuze plná. Znovu jsem se přesvědčil o tom, že D-FENS je páchnoucí stoka (byť klasické staré články o zmrdech jsem miloval).

Jen kdybyste vy mladi chlapci vedeli, co se vse skryva za HipHopem...

http://www.youtube.com/watch?v=4AvP1atLBuo http://www.youtube.com/watch?v=4ugPmsMNEOI http://www.youtube.com/watch?v=bPP9NvUXJhU

[Jakub Lucký]

Zrovna některé věci, které jsou "tak trochu k hiphopu" mám docela rád... třeba některé věci od Wiche, např. Inside of my soul... Ale současná hoperská mládež je fakt trošku moc...

[the.max]

HipHop

Halda

Imbecilnich

Pitomcu

Hopsajicich

Okolo

Podia

[poky74]

ámen