Vlákno názorů ke zprávičce PHP slaví 25 let od Mlocik97 - https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ alebo stručnejšie a laickejšie https://whydoesitsuck.com/why-does-php-suck/ odporúčam prečítať všetkým.

A jak to pak funguje na lowendových sdílených hostinzích? To tam pro každý web (nebo nedejbože víc, když má ten web třeba blog + fórum) trvale běží proces, který obsluhuje ty požadavky?

Uplně stejně jako pro PHP nevidím tam vůbec žádný rozdíl mezi poskytováním Pythonu nebo PHP.

PHP umí běžet jako jeden modul (mod_php)/proces (fastcgi) a obsluhovat nezávislé „aplikace“. To jiné jazyky AFAIK typicky neumí, například Bottle.py aplikace buď vytváří vlastní server (pouze pro tu jednu aplikaci), nebo umí dělat CGI, ale to je nepoužitelně pomalé, protože při každém požadavku se natahuje úplně celý Python a importují všechny závislosti. Ale třeba to nějak jde (možná přes mod_wsgi, který ale je jenom pro Apache, ale co se dá dělat), rád se poučím (je v mém zájmu naučit se to nějak dělat, protože mě PHP štve).

PHP umí běžet jako jeden modul (mod_php)/proces (fastcgi) a obsluhovat nezávislé „aplikace“.

To je sice pravda, ale jako modul to umí obsluhovat jen Apache v MPM prefork. To je výkonnostní katastrofa a ten modul se de facto dokola inicializuje.

V případě fastcgi (FPM) toto sice odpadá, ale zase PHP má takové množství memory leaků, že to FPM stejně nastavíte tak, aby po pár requestech umřelo a spustilo se znovu. Ani jedno není dobré.

U FPM máte ještě možnost spustit vícero poolů, což je šikovné aspoň v tom, že se nemusí jednotlivé aplikace navzájem ovlivňovat, mohou mít jiné limity, bežet pod jiným userem, ... Ale kdo to ve skutečnosti dělá? Většinou to "admini" prdnou do jednoho poolu a žádnou z těch možností nevyužijí. A to nemluvím ani o takovém úletu, že Debian, jedna z nejpopulárnějších distribucí, neumí spustit několik instancí nginxu paralelně (např. kvůli limitům, worker uživateli atd.)

Technologie jsou, dokonce i to PHP umí hezké věci. Jenže za admina se dnes považuje ten, kdo umí zprovoznit podle internetové kuchařky AMPP - a software se této lidské ignoranci víc a víc poddává.

Samozřejmě je správně, aby aplikace měla svůj vlastní server, který nechcípá, sdílí veškerý kontext a neinicializuje se dokola.

PHP vyhrává jen ze setrvačnosti. Kde kdo ho umí (nebo si myslí, že umí), dobře se díky tomu shánějí "vývojáři" a dá se to provozovat na laciném hostingu. Uhozené.

> Samozřejmě je správně, aby aplikace měla svůj vlastní server, který nechcípá, sdílí veškerý kontext a neinicializuje se dokola.

Na jednu stranu se mi to designově líbí, a je rozumné že nemusíte pro každý request tahat všechno znova z databáze (jinak pro ostatní věci jsou různé cache), na druhou stranu si nedokážu představit, jak by fungovalo takové Webzdarma nebo různé hostingy za 10 Kč -- aby se jim to vyplatilo, musí mít na jednom stroji masivní množství webů, a pro každého klienta to znamená trvale obsadit tak 100 MB RAM (nebo kolik tak žerou pythoní appky?), nebo to nějak spouštět a vypínat on demand a doufat, že weby mají návštěvnost rozloženou tak, že to vyjde.

> V případě fastcgi (FPM) toto sice odpadá, ale zase PHP má takové množství memory leaků, že to FPM stejně nastavíte tak, aby po pár requestech umřelo a spustilo se znovu.

Já na tohle nastavení nikdy nesahal a default je nekonečně, a pokud můžu věřit datu startu threadů v ps, tak to teda běží velmi dlouho a z paměti to nevyteklo. Každopádně myslíte, že když někdo, kdo zbastlil stránku s PHP počítadlem a formulářem, bude psát trvale běžící aplikaci, tak v ní leaky nenaseká?

10. 6. 2020, 04:19 editováno autorem komentáře

U FPM máte ještě možnost spustit vícero poolů, což je šikovné aspoň v tom, že se nemusí jednotlivé aplikace navzájem ovlivňovat, mohou mít jiné limity, bežet pod jiným userem, ... Ale kdo to ve skutečnosti dělá? Většinou to "admini" prdnou do jednoho poolu a žádnou z těch možností nevyužijí.

A to je problém PHP ako jazyka?

Ako sám píšete, PHP všetky potrebné prostriedky na rozumné škálovanie výkonu aplikácií poskytuje. Ak na výkone vôbec nezáleží, lebo príde 5 requestov za minútu, tak môžete kľudne použiť aj klasické CGI či MOD_PHP alebo FPM s jedným poolom v defaultoch a je to potom jednoduché na nasadenie.

Ak potrebujete výkon (alebo bezpečnosť) riešiť, spravíte si osobitný FPM pool a v ňom môžete výkonové parametre, napr. počet workerov, ladiť podľa potrieb. Taktiež môžete pridať APCu a presunúť do neho cachovanie sessions z defauktného filesystému napríklad.

No a ak ani to nestačí, nasadíte FPM na viacero strojov a na cachovanie sessions sa použije zdieľaný Redis alebo Memcached.

Technologie jsou, dokonce i to PHP umí hezké věci. Jenže za admina se dnes považuje ten, kdo umí zprovoznit podle internetové kuchařky AMPP - a software se této lidské ignoranci víc a víc poddává.

Opäť, ako to súvisí s kvalitou jazyka?

PHP vyhrává jen ze setrvačnosti. Kde kdo ho umí (nebo si myslí, že umí), dobře se díky tomu shánějí "vývojáři" a dá se to provozovat na laciném hostingu. Uhozené.

Napísal ste príspevok plný výhrad ku kvalite práce adminov, či dokonca Debianu, že nevie spustiť viacero Nginxov naraz a z toho všetkého vyvodzujete, že PHP je špatný jazyk. Nerozumiem celkom tejto logike a príde mi to tak trochu ako posadnutosť, hateovať PHP za každú cenu je zjavne "cool" :-)

@matuscak

Ono to spolu souvisí. Můžete vyrobit skvělý supersport, ale když na něj v praxi budou lidé montovat kouli a tahat za ním přívěs, je to výrobek zacílený na prd.

Podobně dopadl i Apache. Ten server není vůbec špatný, ale implementoval takové zhůvěřilosti, že v praxi se začal používat naprosto pomýleně.

Na autorovi je, aby dal svému produktu (jazyku, serveru, ...) smysluplný koncept života a to se nestalo.

PHP vyhrálo hlavně díky tomu, že od dávných věků mělo implementované funkce z důležitých (šikovných) knihoven. Ještě ve verzi 4 neexistovala na "trhu"" smysluplná alternativa, dokumentace byla obstojně dobrá (co PHP podporovalo, bylo i dokumentováno). Teprve někdy kolem verze 5 začali blbnout, snažili se zároveň konkurovat novějším trendům a zároveň udržet kompatibilitu. Z toho vznikl kočkopes, který známe dnes.

Ja si naopak myslím, že to súvisí iba s tým, že PHP je veľmi rozšírené. A keď je niekde veľa kvantity, tak logicky sa tam bude vyskytovať aj veľa nekvality, ktorá ale nie je daná vlastnosťami jazyka, ale tým, že ho ako masovo rozšírený a ľahko dostupný používa naozaj "hocikto". A vôbec to neznamená, že v tej kvantite nie je aj kvalita alebo že sa kvôli tomu kvalita nedá tvoriť.

Väčšina konkrétnych výhrad, ktoré ľudia voči PHP píšu, sa pritom týka funkcií či vlastností, ktoré boli relevantné pred 20 rokmi v ére PHP4. PHP sa ale odvtedy masívne vyvinulo a neustále vyvíja a väčšina vtedy platných výhrad dnes už jednoducho neplatí. Je nezmysel porovnávať súčasný Python (napríklad) s PHP4, porovnávať ho treba s PHP7.4 resp. s PHP8 (už čoskoro).

PHP vyhrálo hlavně díky tomu, že od dávných věků mělo implementované funkce z důležitých (šikovných) knihoven.

Súhlas, ale to bolo ešte pred 20 rokmi a dnes to má ako argument nulovú relevanciu.

Keby bolo PHP také špatné, ako tu niektorí píšu a ostatné alternatívy také geniálne, tak by už túto dominantnú pozíciu dávno stratilo. To sa naozaj nedá pripísať iba "zotrvačnosti", ak by to tak v technike fungovalo, všetci máme ešte dnes mobily Nokia so Symbianom ;-)

Ještě ve verzi 4 neexistovala na "trhu"" smysluplná alternativa, dokumentace byla obstojně dobrá (co PHP podporovalo, bylo i dokumentováno). Teprve někdy kolem verze 5 začali blbnout, snažili se zároveň konkurovat novějším trendům a zároveň udržet kompatibilitu. Z toho vznikl kočkopes, který známe dnes.

A to sme presne pri pointe - vám vlastne vadí, že PHP neostalo vo verzií 4 so všetkými tými chybami, ktoré pred 20 rokmi malo? Vadí vám, že sa ďalej vyvíja a posúva dopredu? To je trochu divné, nie?

Lebo inak žiadnu konkrétnu technickú výhradu, platnú aj pre jeho súčasný stav, som vo vašich príspevkov zatiaľ nenašiel ...

Pokud by nepřišla 5ka, tak by dnes PHP už neexistovalo. Během prvních 10 let se požadavky hodně změnily. Výhodou PHP byla jednoduchost použití, jednoduchost nasazení, nenáročnost na zdroje a samozřejmě i cena. Jinak v druhé polovině 90 let se neskutečně bastlilo, a PHP nebylo výjimkou. Z těch dob jediná technologie, která má kontinuální vývoj, je PHP. Změnit se na něco z gruntu jiného jde dost těžko - zvlášť v prostředí, kde se PHP používá, kde se musí brát v potaz bezpečnost a aktualizace.

Python málem nepřežil přechod z 2 na 3. Perl nepřežil přechod z 5 na 6ku. Navíc lidi, co dělají weby nejsou zrovna technologická esa (čest výjimkám), takže ta technologie musí respektovat i možnosti a schopnosti uživatelů (ať vývojářů nebo pak provozovatelů aplikací).

10. 6. 2020, 11:08 editováno autorem komentáře

@Pavel Stěhule

O tom žádná, plný souhlas. Jenže doba se posouvá a koncept PHP se od současných potřeb stále víc odklání. Mám tím na mysli např. škálovatelnost. Datové toky i souběžné přístupy rostou, datová nálož je násobně vyšší. Dlouhou dobu to šlo dotahovat hrubým výkonem. Pak přišly ohejbáky - různé cache, když se tak zamyslím, tak první udělá proxy / web server, druhou opcache, třetí preloading tříd, čtvrtou třeba nějaká magie v rámci aplikace / implementace ORM. A zatím nevidím, že by se ukazovala na obzoru nějaká cesta, jak to napravit - aspoň pro ty lidi, pro které neplatí "co dělají weby, ale nejsou zrovna technologická esa".

Za mě: PHP má na světě své místo a posloužilo světu jako jedna z nejužitečnějších technologií. Přesto k ní mohu mít i velké výhrady.

Ty ohejbáky, jak tvrdíš má každá technologie, která chce pokrýt tak ohromný prostor jako jsou webové (mobilní) aplikace. Tu variabilitu nemůžeš pokrýt jednou elegantní technologií. Maximálně je můžeš zamaskovat abstrakcí, schovat za nějaké vrstvy, ale ta komplexita tam bude. A co je hrozně důležité, je použitelnost pro kritickou masu vývojářů. Můžeš mít sebelepší technologii, ale když pro ní nenajdeš dostatek vývojářů, tak je na nic. Takže musíš mít něco, co se jednoduše používá a je funkční. A takové technologie vznikají párkrát za 100 let. To se nedá jednoduše zkonstruovat.

Každý pokročilý uživatel by měl mít k jakékoliv technologii výhrady (i velké výhrady). Každá technologie má svoje limity, svojí historii. 20 letý sw produkt bude mít saturaci trhu, bude mít infrastrukturu, uživatele, kulturu, ale zároveň je poplatný době svého vzniku, svému záběru.

Mám rád terminálové aplikace. Když se na ně, člověk podívá podrobně, tak mu vstávají vlasy hrůzou na hlavě. Softwarově se emulují hw technologie staré 50 let. Drtivou většinu věcí by šlo neskutečně zjednodušit. Ale těžko to někdo udělá, protože to znamená zahodit 50 let vývoje, a zrevidovat 50 let vývoje - a na to musí mít někdo dost velké **** a ego. Jednak ten produkt napsat, a jednak ho prosadit defacto proti vůli uživatelů. Takže můžu mít výhrady (a je hrozně důležité ve všem znát limity), ale to je asi tak všechno, co můžu dělat.

Mám rád terminálové aplikace. Když se na ně, člověk podívá podrobně, tak mu vstávají vlasy hrůzou na hlavě. Softwarově se emulují hw technologie staré 50 let. Drtivou většinu věcí by šlo neskutečně zjednodušit. Ale těžko to někdo udělá, protože to znamená zahodit 50 let vývoje, a zrevidovat 50 let vývoje

Co třeba MS PowerShell? To je podle mě přesně ten krok a povedl se. Je ale pravdou, že nezahazovali padesát let vývoje terminálu, terminál měl MS nulový.

To jsem zrovna neměl na mysli - spíš kompatibilitu s VT100, 220, ... + nejrůznější rozšíření pro xterm, nebo další. Napsat univerzální terminálovou aplikaci bez ncurses je neskutečný opruz - a ncurses - to je přesně ten ohýbák o kterém mluvíš. Vůbec historie curses, ncurses je hrozně poučná - jak (ne) funguje reálný svět - a jak má daleko k ideálům. Hromada technologií zatraceně má daleko k ideálům, ale fungují. Naopak ti, kteří se snažili o svoji ideální technologii skoro nikdy neuspěli.

Vzpomínám na přelom 90 a nultých let. Minimálně v Čechách se psalo několikrát o řádově lepší "proprietární" náhradě PHP (zrovna tak o náhradě SQL) Nic z toho dneska neexistuje. Technologie až na výjimky se vyvíjí evolučně.

žije jeste HURD? :-)