Názory k článku
PHP slaví 25 let
-
Ondra Satai NekolaZlatý podporovatelTak to nebylo.
Kanonicky zdroj (https://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html) pise naprosto jasne:
1995 - At a neighborhood Italian restaurant Rasmus Lerdorf realizes that his plate of spaghetti is an excellent model for understanding the World Wide Web and that web applications should mimic their medium. On the back of his napkin he designs Programmable Hyperlinked Pasta (PHP). PHP documentation remains on that napkin to this day.9. 6. 2020, 11:38 editováno autorem komentáře
-
Je to skriptovací jazyk na tvoření home page ...
Nevím jak sledujete web posledních 25 let, ale těch prvních 20 byl veliký problém sehnat webhosting který by uměl nabídnout něco jiného než PHP. Ostatní řešení programování na straně serveru neuměla (z pohledu správce webhostingu) tak snadné oddělení jednotlivých stránek/zákazníků.
Je to jako videopřehrávače VHS vs. Beta - nejde o to nabídnout nejlepší technologii, ale tu "nejpoužitečnější".
No a PHP byla přesně to. Rychlá a snadná na nasazení na webhostingu, rychlá na naučení a nasazení pro uživatele.
Že v PHP vznikají molochy jako Wordpress, Drupal ... kde se musí hledat rovnák na vohejbák, aby ta "cloud enterprise application" držela pohromadě. Tak to není problém PHP ...
Zajímalo by mne jak se v tomhle světle díváte na JavaScript ...
-
Na JavaScript se dívám s absolutní hrůzou :)
V tom, proč se PHP ujalo, máte samozřejmě pravdu. To nic nemění na tom, že to není dobrá technologie - je to jenom technologie, kterou bylo a stále ještě je velice snadné nasadit. Proti Wordpressu, Dupalu apod celkem nic nemám, kdyby nic jiného, mají aspoň tu výhodu, že s nimi se člověk může prakticky vyhnout kontaktu se samotným PHP. Hlavní problém PHP je jazyk samotný, ani ne tolik nástroje, které kolem něj vznikly.
Ad Betamax vs VHS: to je otřelé klišé ale z velké části mýtus. Z několika hledisek bylo VHS lepší technologie, než Betamax.
-
„Proti [...] Dupalu [...] celkem nic nemám, kdyby nic jiného, mají aspoň tu výhodu, že s nimi se člověk může prakticky vyhnout kontaktu se samotným PHP.“
V případě Drupalu 8 si dovoluji silně nesouhlasit. Možná to platí v případě jednoduchých webů (blogů), ale oproti D6 jsem si spousty věcí musel doprogramovávat. Jistě, záleží na tom, co od toho člověk očekává a můžete namítnout, že autoři D8 nemají pod kontrolou rozsah pluginů třetích stran - - - ale vzhledem k tomu, že jako jedna z hlavních featur Drupalu se prezentují pluginy, tak pro běžného uživatele je to dost podstatný faktor...
-
Drupal 8 je uplne neco jinyho nez predchozi verze. Je to postavene na Symfony komponentach. By me zajimalo co sis musel tak moc doprogramovat oproti D6. BTW hlavni vyhoda je to, ze k tomu z velke casti je to jiz OOP dle Symfony style zatimco k D6 kdyz prisel programator se znalosti jakehokoliv frameworku tak netusil ktera bije.
-
„By me zajimalo co sis musel tak moc doprogramovat oproti D6.“
Popravdě, už jsem většinu z toho vytlačil z paměti, nicméně namátkou;- Nodereference URL - některé typy uzlů jsou odkazovány jinými (např. „zadání výzvy“ - „řešení“). Pro pohodlí uživatelů přidávám k odkazům pod uzlem odkaz, který vede na vytvoření nového uzlu s před-vyplněnou referencí. V D8 jsem sice našel alternativu, ale neúplnou, takže jsem si to implementoval celé sám.
- Alt login & display names - na webu máme „přihlašovací jméno“ bez háčků a čárek a „zobrazované jméno“. V D6 jsem použil základní user name pro zobrazení a alternativní field pro přihlášení. Tento plugin v D8 prohazuje tyto role, což funguje... dokud nevytvoříte user reference autocomplete field; ten totiž vyhledává podle user name. Je mi celkem jasné, že problém je už v základním designu, takže jsem to ani nereportoval a implementoval si vlastní variantu, která se drží původního konceptu.
- CKEditor je v základu velmi omezený. Vzhledem k cílové skupině uživatelů, nastavování barviček apod. je pro ně velmi důležité (jakkoliv nám to může přijít zbytečné). Přidání pluginů vyžaduje nejen jejich stažení do složky libraries (nebo tak nějak), ale i registrování skrz PHP. Některé CKE pluginy řeší moduly, některé si musím takto řešit sám.
- Osobní zprávy - jistě, existuje hned několik modulů pro D8. Jenže všechny jsou buď opuštěné, nebo v raných fázích vývoje. Jedinou výjimkou, kterou jsem našel, je private_message, jenže kromě toho, že má pár zásadních bugů (aktuálně si už nepamatuji, co to bylo, ale nějaká featura prostě nefungovala), tak buď jsem blbý, nebo jeho použití je strašně neintuitivní - abych pochopil, jak to funguje, musel jsem se podívat do zdrojáku a v ten moment mi došlo, že tohle po svých uživatelích nemůžu chtít.
- Je potřeba dělat i vlastní bug-fixy, například:
- (K tomuto jsem se ještě nedostal.) Při použití obráceného řazení komentářů jsou odkazy na komentáře chybné. A z reakce to nevypadá, že by autoři měli nějak zájem to řešit, ale poskytli nápovědu, kde je problém, takže si prostě budu muset hacknout jádro, jakkoliv se mi to příčí.
- (K tomuto jsem se též ještě nedostal.) Widget pro práci s obrázky v CKEditoru je zabugovaný. Bug report je ignorovaný, takže si budu muset najít čas a nějak to vyřešit. (Uznávám, toto nejspíš budu muset řešit v JavaScriptu, ne PHP.)
- Je toho víc, ale z hlavy si už další nevzpomínám. Nicméně myslím, že tam mám řádově tak 5 patchů v PHP composeru, které něco opravují.
- A další...
A kromě doprogramování jsem se musel v PHP hrabat kvůli migracím. Dokumentace je tak omezená a chybové hlášky většinou chybí, nebo jsou totálně nevypovídající, že jsem nakonec debugoval samotný migrační kód, což mi dalo chybějící informace.
Ono vlastně ve chvíli, kdy chci po D8 (jak v případě jádra, tak modulů) cokoliv víc, než je popsáno v dokumentaci, která většinou pokrývá jen „první kroky“, se ukázalo debugování jako nejspolehlivější zdroj informací (tím druhým je samozřejmě Google).
-
-
Především kapacita záznamu. První trh mimo Japonsko, kde se videorekordéry začaly prodávat, byly USA a je známé, že americké publikum vzrušovala hlavně možnost si nahrávat zápasy NFL, kde jedno utkání může v pohodě trvat dvě nebo i tři hodiny. První generace Betamaxu dokázala na jednu kazetu nahrát maximálně 60 minut, což bylo v tomto případě nepoužitelné, kdežto VHS hned zpočátku nabízelo 120 nebo 180 minut, postupně i 240 minut.
Druhá věc byly seriály - Star Trek, Twilight Zone apod. Jedna epizoda trvala cca 45-50 minut, což by Betamax v principu umožňoval, jenže kazety byly zpočátku drahé, takže spotřebitelé byli radši, když si na jedu kazetu mohli během týdne nahrát tři a pak se na ně v klidu dívat o víkendě
Navíc videorekordéry VHS prakticky hned zpočátku uměly zvýšit rychlost pásku a nahrávat ve vyšší kvalitě (a připravit tak Betamax o svoji výhodu, nebo ji aspoň značně zmenšit), nebo naopak nahrávat ve snížené kvalitě, kde se na jednu kazetu vešly hodiny a hodiny záznamu. Sony potom uvedlo rekordér Betamax, který tohle měl taky, ale už bylo pozdě.
A kromě toho všeho VHS byla otevřená technologie, JVC poskytovalo licence každému, kdo měl zájem ho vyrábět, kdežto Betamax byl striktně proprietární. Krátce řečeno, VHS plnilo funkce, o které měli spotřebitelé zájem, Betamax je neplnil. VHS kromě toho nabízelo větší flexibiitu a navíc se velmi rychle stalo podstatně levnější.
-
Podle mě motáte jazyk a punkový patlaly a zároveň jste asi viděl naposled PHP před více než 10 lety. Třeba v Javě jsem viděl podstatně horší kód, než v PHP. Současné PHP už je dost striktní, umí typy skoro všude a kde ne, tam si to člověk (věřim, že) prozatim musí validovat sám, případně šáhnout po nějakym externim toolu, jako například Assertion.
Souhlasím s tim, že pro vývoj webových aplikací, kde se očekává větší nápor requestů, neni PHP ideologisticky ideální, vzhledem k tomu, že s každym requestem se načítá aplikace komplet celá, nicméně se v tom jazyce vyvíjí velmi rychle a dnešní trend je neřešit tolik optimalizace a nahánět to výpočetnim výkonem, protože je to cenově výhodnější.
-
... vzhledem k tomu, že s každym requestem se načítá aplikace komplet celá ...
Ani to už nemusí byť pravda, viď. PHP 7.4 opcache preloading.
https://wiki.php.net/rfc/preload -
To mi připadá přehnané. Python, Ruby, Rust, Ada a další jsou celkem "ohrabané", každý svým způsobem. Mají svá omezení a žádný z nich není univerzální všelék, ale totéž platí o Haskellu. V určitých ohledech je Haskell nádhera, ale některé věci má taky strašně neohrabané nebo neelegantní.
11. 6. 2020, 05:02 editováno autorem komentáře
-
Mě třeba schází (v těch co jsem vyjmenoval) pattern matching, destructuring assignment, mocnější statické typy (v případě Pythonu ideová záležitost). Tím bych já oddělil jazyky sice dobré, ale přeci jen ne dost dobré (Java, C#, Python, PHP) od jazyků, které jsou mnohem lepší (Haskell, Scala, Elm, Rust).
-
Pattern matching a statické typy např. v Pythonu celkem nedávají smysl. Python je plně dynamický jazyk se všemi výhodami a nevýhodami, co to obnáší. Na OOP, modelování, metaprogramování, implementaci DSL, ale taky jako moderní nástupce BASICu (ve smyslu snadno použitelného jazyka, kde se dá všechno udělat narychlo a bez boilerplatu) je ideální, mnohem lepší, než kdy bude Haskell nebo Rust. Tam, kde požaduju statickou prokazatelnost nebo mocný typový systém, destrukturaci atd. pochopitelně použiju Haskell Rust, Scala apod.
-
Ten nejjednodušší pattern maching, tj. v podstatě jenom "switch" dejme tomu rozšířený i na řetězce, stylu
match blah:
'debil': ...
'blbecek': ...
_: ...to mi skutečně v Pythonu často chybělo a upřímně řečeno nevím, proč to nemá. Destrukturační pattern matching nedává moc velký smysl, protože v Pythonu i objekty téže třídy můžou mít různé atributy a vlastně se chovat jinak. V Pythonu je taky velmi častý kachní polymorfismus, který si taky s destrukturací rozhodně moc nerozumí. Jistě, dá se to částečně ošetřit typovými anotacemi atd, jenže to mi připadá, že se tím už ztrácí to, v čem je síla Pythonu, a staticky typovaným jažykům jako je Rust a Haskell se to přitom nikdy nevyrovná,
-
"V době sdílených hostingů"
- - - - - - - - - -
Jakože dnes hostingy sdílené nejsou? Asi už jsi dlouho mimo obor, že?
btw. původní zprávička včera na lupě, stále je web z 80% na php a ještě hodně dlouho se nic v neprospěch php odehrávat nebude ;)
https://www.lupa.cz/aktuality/php-dnes-slavi-25-let-stale-je-nejpopularnejsim-jazykem-pro-tvorbu-webu/tzn. když zohledním banky a korporáty, kde se kdysi zavrtali do javy a teď to musí udržovat senioři (myslím důchodce, ne nutně vždy zkušenosti..), tak to prostě v reálném světě webových aplikací nemá konkurenci..
9. 6. 2020, 15:56 editováno autorem komentáře
-
zrovna v teto dobe delam projekt na php. Lepe receno neni to jenom php, je to propletena kombinace html, css, javascript, php a sql. html mi nedela problemy, css trosku, sql absolutne ne. Jenom ta kombinace javascript-php. Javascript je pekny, dobre se pouziva, ovsem clovek si musi davat pozor, aby to fungovalo na vsech browserech. To uz dnes vetsinou funguje. Ovsem php je proste hruza. Naprosto nekonzistentni knihovny, objektove programovani sice do php dorazilo, ale stringy a array nejsou objekty. Tim padem jsou tady desitky funkci s pomerne nejednotnymi jmeny a dost blbe se to pouziva. Hlavne z duvodu ze v jednom file je kousek php, kousej javascript, nekdy uz ani nevim, ktery kousek je ktery a v kazdem se na stringy pouzivaji jine funkce. Proc se i na serverove strane nepouziva javascript? Vyvijet takovouhle aplikaci by bylo 100 krat jednodussi. Na php se mi ovsem libi, ze se dobre integruje do html stranek. Tohle se jim celkem povedlo.
-
Pokud děláte PHP doporučil bych určitě jít do nějakého frameworku, ať se dostanete do MVC (např. Nette je velmi dobrá volba). Ušetří to mnoho práce a zajistí to udržitelnost projektu (přehlednost, snadná modifikace atd.). Vyřeší to za Vás i mnoho problémů včetně jednotnosti knihoven atd.
Co se týče js na serveru... poslední dobou je poměrně populární Node.js, ale s tím jsem nepracoval, ale možná vám k tomu řekne někdo jiný.
-
Frameworky jsou kapitola sama pro sebe. Udržitelnost je s nimi samozřejmě větší, ale musíte opravdu respektovat daná pravidla. Jinak si ho zašprcnete na verzi, ze které se nehnete. Zrovna Nette moc nevyniká ani přechodovými cestami, ani soudržností verzí frameworku a modulů. V tomto ohledu je zajímavější spíš Symfony. Oba zmiňované jsou ale za cenu obrovské ztráty výkonu, jen "Hello World" trvá nesmyslný čas. Symfony to umí aspoň částečně kompenzovat preloadem v PHP 7.4. Ale to všechno jsou obezličky, které kompenzují to, že se PHP používá na úplně něco jiného, než na co by se ve skutečnosti hodilo (psal už někdo výše). Nejpopulárnější a taky nejhorší, co se může potkat je pak kombinace Apache s podporou htaccess, framework (nette, symfony) a ORM. Skvěle se to naprogramuje a běží to do prvního výkonnostního problému. Pak je utrum a nejde to pořadně vyladit.
-
1) tohle neni zase tak uplne pravda.
2) na hello world si fakt nebudu brat framework
3) kolik programatoru se potka s appkou kde performance opravdu musi resit?
4) i s tim PHP dokazeme na Symfony vykon ktery bohate staci pro bezne zpravodajske servery.
5) ORM je dobry sluha, ale zly pan. tam souhlasim, ze to muze byt bolest. Ale zase proste pocitac vs programator je v nakladech neporovnatelne takze v pripade vyssiho loadu pridame aplikacni server a balancer to poresi :-)
6) jasne, na velín jaderne elektrarny nebo rizeni rakety pouziju neco jinyho -
@bez přezdívky
Tyto argumenty slýchávám často a každý jednotlivě platí. Programátoři pak naprogramují appku, která POSTEM posílá megabajty dat a díky ORM je zpracovávají v paměti. Na PHP Vám nezbude než nastavit vysoké limity RAM i POST.
...a v jeden okamžik se Vám server dostane do stavu, kdy "něco" přestane fungovat a nemáte ani jak najít chybu. Server, na kterém by běžela jen jedna apka a FPM pool nebyl sdílený aby člověk pohledal (je to pak drahé na prostředky = vysoká cena). Takže z malých projektů, které nepotřebují výkon, se Vám poskládá velký průser. Zákazník pak ječí, proč to nefunguje a vysvětlujte mu, že místo sdíleného hostingu si má pronajmout managed VPS nebo bare metal, pokud nechce ani čas od času zažívat problémy.
Ale to už jsme na hony daleko od tématu. To bylo, že PHP se dnes používá úplně jinak, než na co by se opravdu hodilo. Vynalejzají se ohejbáky a na ně narovnáváky (viz "přidáme aplikační server a balancer").
-
Souhlas. Nette (nebo Symfony) jsou dobrá volba. Patří mezi technologickou špičku v PHP ať už co se kvality týče, dokumentace, nebo v tom, že DG je fakt fanatik co se zpětné kompatability a BC týče.
Symfony víc vyniká určitou šíří záběru. Ale IMHO je trochu víc akademickej a prekombinovanej.
JS na serveru v dnešní době není problém - respektive je to už problém jen hostingů. Ekosystím kolem Node.js je obrovskej.
-
1. miešanie rôznych jazykov v stejných súboroch bol vždy humus.
2. niekedy si nemôžeš dovoliť tým na osobitné riešenie backendu a frontendu a niekedy to ani nie je moc možné.Ostatne v JavaScripte viem jednoducho spraviť jak front-end tak back-end, s frameworkom Svelte/Sapper je to úplne zábava v tom robiť.
-
To neni zas tak problem v jednom souboru nebo ve dvou souborech, ale v tom, ze musis paralelne myslet ve dvou jazycich a pak v javascriptu pisu promenne s dolarem na zacatku a v php pristupuju do pole pres tecku.
Nejvic me na php stve prave to, ze se do pole nedostanes pres tecku, jako treba v lua nebo v js. Psat vsechny pristupy jako pole['xxx'] misto pole.xxx je na zblazneni. K tomu ti zadny framework nepomuze.
Navic jsem tady z historickych duvodu nucen to psat tak, aby to bezelo jak na php 4, tak na php 7 nebo ktera je posledni, takze skutecne opruz.
Ze by jeden clovek delal backend a druhy frontend je sice mozna dobra idea v pripade, ze pracujes na velkem projektu ve firme kde je 100 lidi. Ovsem pro tento maly projekt a malou firmu by to nebylo. Mimo jine i kvuli tomu, ze se frontend i backend meni soucasne a dost propletene. -
"a v php pristupuju do pole pres tecku.
Nejvic me na php stve prave to, ze se do pole nedostanes pres tecku, jako treba v lua nebo v js. Psat vsechny pristupy jako pole['xxx'] misto pole.xxx je na zblazneni. K tomu ti zadny framework nepomuze."??? ak viem, nie je tečka prístup do objektu? zrovna nikde som nevidel používať pole.2 ako aby som načítal hodnotu z pola na indexe 2... to ešte častejšie vidím obj["property"]...
-
Není. Pro přístup k property používá šipku.
A naopak, PHP to má vymyšlené chytře, protože v objektu jsou dva kontexty: jeden pro property, druhý pro klíče pole, takže v něm můžeš používat oboje. Někdo by se mohl pozastavit nad tím, proč to mít - potud ok, ale IMHO Javascript to má s možností přistupovat přes tečku i přes index špatně.
-
> Navic jsem tady z historickych duvodu nucen to psat tak, aby to bezelo jak na php 4, tak na php 7 nebo ktera je posledni, takze skutecne opruz.
Pokud Vás za tohle neplatí naprosto královsky, tak bych doporučoval se poohlédnout po jiném zaměstnání, kde Vás nikdo nebude nutit prasit místo programovat.
-
Vis, ono to neni tak jednoduche. On se hrozne jednoduse programuje nejaky web system, ktery pojede nekde na hostingu, kde si muzes nainstalovat co chces. Tohle co delam musi bezet na systemech, ktere jsou u klientu a nektere z techto systemu bezi na strojich, ktere maji 10+ let. S operacnim systemem, ktery ma 15 let. Zkus na tom rozjet neco novejsiho. A zkus presvedcit nekolik stovek klientu, ze si maji koupit lepsi hardware a dostat na to lepsi software. Ja budu jenom rad, kdyz se ti to povede, nebudu muset delat eskamontaze s kompatibilitou.
Takze mi nezbyva, nez se smirit s tim, ze musim psat tak, aby to bezelo i na php4 a mysql 3.23 -
L.Stříbrný podporovatel
Ty jo, pokud ty stroje nejsou na nějakém velmi dobře zabezpečeném segmentu sítě, tak je to slušný bezpečnostní hazard.
-
> Takze mi nezbyva, nez se smirit s tim, ze musim psat tak, aby to bezelo i na php4 a mysql 3.23
Tak to je to, co jsem se snažil naznačit - těch možností máte rozhodně více než se s tím smířit. Prostě se taky můžete rozhodnout to už dále nedělat. Nebo to dělat, ale stanovit si podmínky takové, aby to nebyla jen rezignace, ale aktivní rozhodnutí - "fajn, chcete to mít na 10+ let starém stroji, tak to bude stát 5x tolik", protože Vás to nakonec 5x tolik (možná i více) stojí na vývoji.
-
"fajn, chcete to mít na 10+ let starém stroji, tak to bude stát 5x tolik", protože Vás to nakonec 5x tolik (možná i více) stojí na vývoji.
To je jediná aspoň trochu fungující cesta. Plus zákazníkům posílat informace o životních cyklech technologií a další podklady, aby rozuměli tomu, proč se to projeví na ceně (jinak mají pocit, že je jen "trestáte" bez důvodu).
V praxi se ale vždycky najde aktivní blbec, který neví, že to je problém, přijde a udělá to. Sice si možná po pár měsících, letech nabije ústa, ale to v té době jste už bez zákazníka a zakázky.
-
Naprosty souhlas. Presne tohle mame v umyslu. Sice to nebude stat 5x tolik, ale rozhodne ti, co maji system postaveny na OS z roku 2004 bud upgradnou na novejsi os, ve vetsine pripadu i zelezo, na tom starem zeleze nic noveho nejede a kdyz jo, tak silene pomalu. Nebo budou platit o kus vic za upgrady. A kazdy rok o vetsi kus vic, ono je to prestane bavit. Protoze ja si tady musim psat jak blbec i funkce jako json_encode - podle manualu php4 by tam sice mela byt, ale neni nebo xml parser. Taky neexistuje. Proste silenost. Nehlede na potencialni bezpecnostni problemy celeho systemu, jak uz tady taky nekdo zminil.
-
Jan HrachStříbrný podporovatel> Navic jsem tady z historickych duvodu nucen to psat tak, aby to bezelo jak na php 4, tak na php 7
A nepramení tedy váš hejt z toho, že porovnáváte verzi z roku 2004 (!) se současnými jazyky?
> Psat vsechny pristupy jako pole['xxx'] misto pole.xxx je na zblazneni.
Lua neznám, ale teda pole.i ani slovník."klíč" jsem neviděl nikde jinde, ani v tom JS.
-
L.Stříbrný podporovatel
Tak se podívejte znova. Schválně si zkuste zadat třeba do konzole Chrome:
const a = {xxx: 'yyy'}
console.log(a.xxx) -
-
Přesně kuli takovejm punkovejm vývojářum, jako jste vy, si lidi o php myslí, že je to kentus jazyk. Nic ve zlym, punkoví vývojáři jsou potřeba ve startupech (ať se jedná o php, python, java), aby se ušetřily peníze a rychle se to rozjelo, ale jak se projekt začne sám platit, mělo by se zainvestovat do refaktoringu a napsat to pořádně, klidně i v jinym jazyce, kterej podle vás "neni příšernej". Samozřejmě to nemusí být tak jednoduchý, ale zažil jsem, když startup prorazil na nějakym wtf kódu a po pár letech to začali přepisovat. Pak třeba Rohlík, jestli se nepletu, přechází/přešel z php na javu.
Jsem víceméně backendový vývojář, ale svého času jsem dělal fullstack a nějak jsem neměl problém mít separé js, php i html. Ono to "separé php a html" neni tak uplně pravda, ať už jsem dělal na custom frameworku, kterej templaty řešil vyloženě phpkem, nebo jsem používal třeba nette s latte, který je víceméně zase zpracovávaný phpkem. Ale tak to funguje všude, i v javě. A zrovna v javě jsem narazil fakt na mixování html a JAVY. Nebo úžasná konstrukce - instance vytvořená anonymní funkcí a přiřazená ihned při inicializaci proměnné. To byl poslední hřebíček do rakve a s javou jsem definitivně rozloučil :)
Prasit a dělat ostudu ste dá v jakymkoli jazyce. Že někdo narazí na hnusnej kód v php, za to sice php částečně může svou jednoduchostí, ale zároveň ta jeho jednoduchost je důvod, proč je tak rozšířenej i přes jeho neduhy.
-
Laravel mi teda prijde spis jak inspirovany Ruby on Rails, coz kolem a kolem nemam PHPkarum za zle, ze konecne vnesli nejake koncepty a struktury do PHP aplikaci. To je podle mne ten duvod, proc spousta lidi povazuje PHPko za "hnusny", protoze kdyz otevrete Wordpress, Drupal a Joomlu tak v tom, aby se prasatko vyznalo.
Samozrejme prasit se da v kazdym jazyku a spousta lidi zacalo programovat diky "dostupnosti" PHP, coz prineslo i to, ze kazdej si to delal po svem.
Setkal jsem se relativne castokrat s problemem, kde PHP programatori duplikovali z nejakeho duvodu napr. funkcinolitu OS viz pristup k souboru nebo network stack kvuli CDN. Cili naucili se pouzivat kladivo a kazdy problem byl najednou hrebik.
Dalsi vec jsou PHP balicky, composer, jak si pustit neco ala RVM/virtualenv v php bohuzel nenasel jsem nic moc podobneho. To, ze vynechali jednu major verzi, mluvi samo za sebe (kazdej problem byl hrebik).
-
Jan HrachStříbrný podporovatel
Mezitím u konkurence:
>>> (True == False) is False True >>> True == (False is False) True >>> True == False is False [no schválně si tipněte co to vypíše]
-
PHP v tom zďaleka nie je samo, viď. napríklad
https://www.destroyallsoftware.com/talks/watNavyše ide o neaktuálnu výhradu, keďže tento problém je už v PHP vyriešený, viď.
https://www.php.net/manual/en/migration74.deprecated.php -
Náhradou je (a vždy bolo) použiť zátvorky, nespoliehať na to, či je to defaultne asociatívne sprava alebo zľava, ale vyjadriť očakávané vyhodnocovanie explicitnými zátvorkami.
PHP 7.4 spravilo bezzátvorkový zápis deprecated, od PHP 8.0 to bude error.
Teoreticky o X verzií neskôr by sa mohol znova povoliť bezzátvorkový zápis s obrátenou asociatívnosťou, ale to je už fakt len mikro detail, pretože písať to so zátvorkami naozaj žiaden veľký problém nie je, zvlášť keď si vezmeme, že reťazenie ternary operátorov naozaj nie je konštrukcia ktorá by sa často používala (ani si nepamätám, kedy som to naposledy použil).
Problémom bolo, že takýto zápis v minulosti mohol byť zle chápaný pri prechádzaní medzi rôznymi jazykmi a toto už dnes nehrozí.
-
Obligatorní odkaz: PHP: a fractal of bad design (myslím, že nikde jinde to není tak hezky shrnuté).
Ano, arrays jsou velmi vypečená. Hádanka: co vypíše nálsedující program?
$a = []; $a[2] = "treti"; $a[1] = "druhy"; $a[0] = "prvni"; foreach ($a as $x) { echo "$x\n"; }Ještě by možná s přivřenýma očima mohlo dávat smysl používat jeden datový typ pro seznamy a slovníky. Ale používat stejný datový typ pro seznamy a uspořádané slovníky, to prostě v principu nemůže fungovat.
9. 6. 2020, 17:14 editováno autorem komentáře
-
Áno majú to veľmi krásne popísané, preto som ten odkaz sem tiež dal... Ohľadom arrayov by som povedal že toto je ešte ich "menší" problém. Ono celkovo je to na hlavu a myslím že nemá zmysel to ani popisovať, v tom linku je väčšina toho zhrnutá. To ešte PHP funkcie na prácu s arraymi a pod je to väčšie peklo. No, inak by ma zaujímalo či funguje v PHP aspoň niečo ako
`$a = nejakamojafunkcia() || "defaultna hodnota";` lebo čo si pamätám ani toto nebolo/není možné.9. 6. 2020, 17:57 editováno autorem komentáře
-
Ten odkaz je už takmer 10 rokov starý a veľká časť z tam uvedených výhrad dnes už neplatí, keďže PHP sa stále vyvíja.
Čo sa týka array, tak jeho flexibilita je daná dobou vzniku a pre rýchle prototypovanie je skôr prínosom ako brzdou.
Každopádne ale, viac ako 10 rokov existuje ArrayAccess interface pomocou ktorého si každý môže spraviť vlastnú implementáciu triedy/typu s presnou biznis logikou akú potrebuje a používať ju miesto array.
Alebo použiť niečo takéto napríklad:
https://www.php.net/manual/en/book.ds.php -
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.
-
Jan HrachStříbrný podporovatel
Ano, taky znám v PHP věci, co jsou blbě, naštěstí webové věci zas tak moc nedělám. Jenže jaká je alternativa? A tím nemyslím pro ECA jak se píše výše, ale pro malé věci, kde chceš prostě do existující stránky dopsat
<? kousek_kódu ?>a podobné triviality. -
@Jan Hrach bežne nikdy nepotrebuješ dopísať len jeden či 2 riadky server-sidu. Ak áno tak potom server-side nepotrebuješ vôbec, inak bežne napíšeš tých riadkov viac, a v takom prípade nevidím zmysel pre to čo popisuješ. Radšej využijem JavaScript, alebo sú tu aj možnosti ako Golang, Python, C/C++,... Ešte aj v blbej Jave so Springom je to výrazne lepšie.
-
Jan HrachStříbrný podporovatel
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?
-
Jan HrachStříbrný podporovatel
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é.
-
Jan HrachStříbrný podporovatel
> 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ě.
ČLÁNKY DO MAILU