Vlákno názorů k článku
PHP slaví 25 let od anonym - Byla to dobrá technologie v době sdílených hostingů.

„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).

> Betamax vs VHS: to je otřelé klišé ale z velké části mýtus.

Prosím o víc informací, nebo zdroj ... Děkuji

Cena a hlavně max hodina záznamu na betamaxu.

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ě jazyk samotný zas tak špatný není. Spíš způsob nasazení má své výhody i omezení.

Naopak jazyk má od začátku featury, které při tvorbě webů nejvíc oceníte, třeba formátovací řetězce, které byly do pythonu přidány až ve verzi 3.6.

10. 6. 2020, 09:51 editováno autorem komentáře

Jsem Haskellista. V porovnání s takovým jazykem je všechno ostatní stejná břečka.

Haskellista jsem byl dlouhou dobu taky, ale přece jenom těch nevýhod má Haskell taky hodně, nemluvě o nedešifrovatelných chybových hláškách...

Jo, má, a?

A nic, jenom to taky není "definitivní" jazyk jak se někteří nadšenci snaží tvrdit. Paradoxně má podobný problém, jako C++ a Perl: příliš svádí k tomu, aby člověk řadu problémů řešil "chytře".

V kontextu mé odpovědi, jen jsem vysvětlil, že díky Haskellu si uvědomuji, jak jsou ostatní jazyky strašně neohrabané, a vlastně toho zase tolik neumí.

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).

Destructuring assignment maji dnes skoro vsechny jazyky. Pattern matching ma treba Ruby, z tech ktere jmenoval klokan.

11. 6. 2020, 20:51 editováno autorem komentáře

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.

Že statické typy v Pythonu nejsou protože je to Pythoní idea, to jsem uvedl. A dál bych to nerad rozváděl.

Proč pattern matching v Pythonu nedává smysl? Řekl bych, že naopak. Python přeci typy má. Úplně nevidím důvod, proč je tedy nepoužít?

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á,