Trendy v PHP

Re:Trendy v PHP
« Odpověď #45 kdy: 06. 09. 2022, 17:58:11 »
https://www.php.net/manual/en/class.datetime.php

Musím se podívat, proč to kolegové reimplementují, ale počítám, že nějaký vážný důvod to má. Každopádně počítám, že porovnávat to nejde, takže třeba triviální max($datetime1, $datetime2, $datetime3) neuděláš.


Tak já třeba Tester ignoruju, vesele používám PHPUnit, a nijak mě neuráží, že Nette má svoje vlastní řešení. Kdo jsem abych jim kecal do jejich štěstí.

Akorát, když otevřeš dokumentaci Nette, tak tam najdeš jen Tester. A když chceš testovat presentery, musíš si to napsat sám, ani dokumentace ti nepomůže. Když potřebuješ v testech DB, jsi nahraný a píšeš si sám celé řešení pro bootstrap databáze a pro pouštění testů v transakcích.

PHP jako celek mi moc nepřirostlo k srdci, ale když už, tak třeba Laravel má komplet řešení (https://laravel.com/docs/5.7/database-testing), Symfony má řešení (https://symfony.com/doc/current/testing/database.html), ale v Nette si každý prošlapává svojí cestu sám a objevuje stokrát vymyšlené kolo.

Možná jsem měl jen smůlu, ale ve dvou různých firmách jsem potkal dva (a ne triviálně malé) Nette projekty a v obou to byla zoufalost, věci fungující v jiných frameworcích out-of-the box (autentizace, lokalizace, testy) řešené nějakými vlastními polofunkčními konstrukcemi.

A nejhorší je, že mimo náš píseček, to vlastně nikdo nepoužívá. Integrace Sentry - jen Laravel a Symfony, Loggly - opět Laravel a Sentry, atd. Nic nevygooglíš, nic ti nikdo nepřipravil, pořád řešíš nějaké technikálie místo práce na byznys zadání.


Re:Trendy v PHP
« Odpověď #46 kdy: 06. 09. 2022, 22:37:30 »
Ty jiné jazyky si hlavně nenesou tak šílenou zátěž špatného návrhu a mizerné základní knihovny jako php, kde stále ještě spousta knihovních funkcí vrací nulu nebo false při chybě místo, aby vyhodily výjimku. Existuje externí knihovna, která to zkouší řešit, ale při mém zkoušení nefungovala: https://thecodingmachine.io/introducing-safe-php

Také mě překvapilo, že v php není ani tak základní věc jako datový typ pro datetime, takže na projektu, kde jsem dělal, se používaly rovnou tři in-house knihovny pro práci s časem, každá nedomrlá svým způsobem. Navíc v php nejdou přetížit operátory, takže třeba pythonovské datetime(year=2010,month=1,day=1) + timedelta(minutes=60) si ani sám nemůžeš implementovat a u nás se to řešilo podivnými funkcemi jako TimeStamp->addSeconds().

Co mi ale přijde nejhorší, je komunita kolem Nette, které má potřebu ignorovat okolní svět a všechno si dělat samo. Takže máme sice phpUnit, ale Nette si vyvíjí vlastní Tester, který má možná nějaké drobné fíčurky navíc, ale chybí podpora v IDE (polofunkční plugin do PhpStormu nepočitám) a testy v debuggeru si prostě jednoduše nepustíš. Podpora pro NEON v IDE - jde, ale zaplať si propietární plugin. Atd.

Přijde mi, že PHP jde celkem dobrým směrem (třeba typová kontrola a phpstan jsou fajn), ale staví na tak špatných základech, že mě osobně dává větší smysl věnovat se jiným jazykům.

Tohle je hodně výstižný komentář. Mě každý den na PHP nejvíce sere:
- Chybějící generika, hlavně jak se pak všechno zapisuje do komentáře. Navíc používáme 5.3 a 7.0, kde nejsou nativní anotace a neumí ani null typehint..
- Často potřebuju zřetězit volání .filter(..).map(..), jenže pole ani string není objekt, místo toho musím udělat více cyků za sebou nebo použít pomocnou třídu Collection::from(..)->filter(..)->map(..)->toArray()..
- array jako jeden typ pro hashmapu a list je zdrojem bugů

Prostě v PHP ještě není z historických důvodů vyřešeno to, co je jinde od začátku. I kombinace JS+TS je daleko mocnější. Osobně bych šel radší do C# a nebo Kotlinu, i když ten mi přijde trochu divočejší.

Dělám fulltime v Nette a líbí se mi, jak je lightweight oproti Symfony, ale vše je udělej si sám. Třeba aktuálně by se mi hodilo něco na tvorbu API, sice je tam Apitte, ale v něm nejde ani popsat pokročitejší otypovaná struktura.. Zatímco Symfony má API platform a vlastně vše je naservírováno a můžeš hned začít řešit byznys problém.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Trendy v PHP
« Odpověď #47 kdy: 06. 09. 2022, 22:41:30 »
Tak já třeba Tester ignoruju, vesele používám PHPUnit, a nijak mě neuráží, že Nette má svoje vlastní řešení. Kdo jsem abych jim kecal do jejich štěstí.

Akorát, když otevřeš dokumentaci Nette, tak tam najdeš jen Tester. A když chceš testovat presentery, musíš si to napsat sám, ani dokumentace ti nepomůže. Když potřebuješ v testech DB, jsi nahraný a píšeš si sám celé řešení pro bootstrap databáze a pro pouštění testů v transakcích.
Nemohu potvrdit. Ale máš právo na svůj závěr.


PHP jako celek mi moc nepřirostlo k srdci, ale když už, tak třeba Laravel má komplet řešení (https://laravel.com/docs/5.7/database-testing), Symfony má řešení (https://symfony.com/doc/current/testing/database.html), ale v Nette si každý prošlapává svojí cestu sám a objevuje stokrát vymyšlené kolo.
Tak zrovna Laravel je ukázka toho jak to nedělat. To bych jako příklad moc nevytahoval. Dělá PHP ostudu. IMHO.


A nejhorší je, že mimo náš píseček, to vlastně nikdo nepoužívá. Integrace Sentry - jen Laravel a Symfony, Loggly - opět Laravel a Sentry, atd. Nic nevygooglíš, nic ti nikdo nepřipravil, pořád řešíš nějaké technikálie místo práce na byznys zadání.
V posledním PHP projektu, ke kterému mě přizvaly tak Sentry už bylo nasazené. Jako out-of-the-box rozšíření do Nette.
Pokud dám vyhledat v balíčcích, tak mi to přijde jako fajn: https://packagist.org/?query=nette&tags=sentry



Možná jsem měl jen smůlu, ale ve dvou různých firmách jsem potkal dva (a ne triviálně malé) Nette projekty a v obou to byla zoufalost, věci fungující v jiných frameworcích out-of-the box (autentizace, lokalizace, testy) řešené nějakými vlastními polofunkčními konstrukcemi.
Když jsem před časem nastoupil k projektům napsaných v C#, tak jsem měl taky poněkud větší očekávání. Tři projekty, který jsem dostal na starost, a prostě, asi jsem měl smůlu no.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Trendy v PHP
« Odpověď #48 kdy: 06. 09. 2022, 22:47:33 »
- Chybějící generika, hlavně jak se pak všechno zapisuje do komentáře. Navíc používáme 5.3 a 7.0, kde nejsou nativní anotace a neumí ani null typehint..
- array jako jeden typ pro hashmapu a list je zdrojem bugů
Mohu doporučit https://phpstan.org/ řeší jak generika, tak notnull type hint, tak list versus array. To, že je to externí nástroj jde vlastně brát i jako pozitivum.


neumí ani null typehint..
Rád bych upozornil na to, že C# taky nemá notnull typehint. Což zase velmi vadí mě.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Trendy v PHP
« Odpověď #49 kdy: 07. 09. 2022, 00:04:55 »
https://www.php.net/manual/en/class.datetime.php

Musím se podívat, proč to kolegové reimplementují, ale počítám, že nějaký vážný důvod to má. Každopádně počítám, že porovnávat to nejde, takže třeba triviální max($datetime1, $datetime2, $datetime3) neuděláš.

Uděláš.

Hele, nebylo by prostě tak nějak férovější prohlásit "já prostě PHP nemám rád, nemám pro to žádný racionální důvod, jenom je mi nesympatický"? Jen takový návrh.


Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Trendy v PHP
« Odpověď #50 kdy: 07. 09. 2022, 01:35:53 »
V jazyku přišli nové featury, konkrétně typy, enum, traity, anotace (co zrovna mě hodně potěšilo).
Anotace pro reflexi ok, ale často se to dost přehání a je víc kódu nad metodou než v ní.
Anotace mají zajímavou vlastnost v tom, že jsou deklarativní. Tedy jiný přístup k "programování". Někdo (třeba já) by mohl říct, že čím víc deklarativního kódu tím lépe  :)

Deklarativní kód mám také rád. Proto vypouštím anotace a většinu kódu mám XSLT, hlavně vstupy a výstupy. PHP se tak stane jen lepidlem. Výsledkem je přehledný a velmi rychlý kód.

oss

  • ***
  • 229
    • Zobrazit profil
    • E-mail
Re:Trendy v PHP
« Odpověď #51 kdy: 07. 09. 2022, 07:58:30 »
Co sa taky Rustu, ten ma tiez svoje problemy, na ktore ale clovek pride ked s nim zacne robit
Co například?
Nechcem rozbiehat vlakno o Ruste. Ale v kratkosti - viem, ze mnoho veci je kvoli borrow checkingu a vlastnictvu, ale obcas to stve. No take objektivne: UT8 stringy - na prvy pohlad super, v realite ciste zlo, milion dalsich typov stringov, slaba standardna kniznica - balicky si implementuju uplne trivialne veci sami a potom ma clovek na to iste milion nekompatibilnych typov (ale stale je to lepsie ako v JS), language server mi pri monhych veciach neokaze dat hint, hlavne pri zlozitych generikach a vtedy mi nepomaha ani dokumentacia (kvoli tomu som uz vzdal jeden projekt).

Ako Rust je super, robil som s nim vela, ale proste nie je az taky pohodlny.

oss

  • ***
  • 229
    • Zobrazit profil
    • E-mail
Re:Trendy v PHP
« Odpověď #52 kdy: 07. 09. 2022, 08:00:29 »
Rád bych upozornil na to, že C# taky nemá notnull typehint. Což zase velmi vadí mě.

C# sice nema notnull typehint, ale ma null typehint - takze ide na to spravne - null moze byt len to co  oznacis. Je to tam od verzie C# 7.x , s dotnet 6 ma uz null anotacie cela standardna kniznica a aj milion dalsich.

Coati

Re:Trendy v PHP
« Odpověď #53 kdy: 07. 09. 2022, 09:17:53 »
No take objektivne: UT8 stringy - na prvy pohlad super, v realite ciste zlo, milion dalsich typov stringov
UTF8 má po řetězce spousta jazyků, proč je to zlo?
Že má několik typů pro řetězce je fakt, ale dává to smysl, ne? Převod na řetězce à la C nebo na seznam run se řeší všude možně, Go to má, i Fortran, dokonce i v rámci C existuje několik typů třeba na Windows.
« Poslední změna: 07. 09. 2022, 09:23:25 od Coati »

Re:Trendy v PHP
« Odpověď #54 kdy: 07. 09. 2022, 09:53:01 »
https://www.php.net/manual/en/class.datetime.php

Musím se podívat, proč to kolegové reimplementují, ale počítám, že nějaký vážný důvod to má. Každopádně počítám, že porovnávat to nejde, takže třeba triviální max($datetime1, $datetime2, $datetime3) neuděláš.

Uděláš.

Hele, nebylo by prostě tak nějak férovější prohlásit "já prostě PHP nemám rád, nemám pro to žádný racionální důvod, jenom je mi nesympatický"? Jen takový návrh.

Tak jsem na to koukal a hlavním důvodem bude nedomrlá podpora mikrosekund. PHP se zákeřně tváří, že mikrosekundy podporuje, ale ve skutečnosti

Citace
microtime(true) loses precision in conversion to float. I think you only end up getting precision to 1/10th of a millisecond.

Plus tyhle rady jsou taky skvělé

Citace
You can specify that your input contains microseconds when constructing a DateTime object, and use microtime(true) directly as the input.

Unfortunately, this will fail if you hit an exact second, because there will be no . in the microtime output; so use sprintf to force it to contain a .0 in that case: date_create_from_format(     'U.u', sprintf('%.f', microtime(true)) )->format('Y-m-d\TH:i:s.uO');

Opravdu ti připadá, že tohle není racioální argument - ten jazyk je plný podobných záludných chování, kdy kód většinou funguje, ale pak někam přijde nula a ono to spadne. Případně se ti magicky ztratí přesnost.

fos4

Re:Trendy v PHP
« Odpověď #55 kdy: 07. 09. 2022, 10:33:47 »
to je zase flame..

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Trendy v PHP
« Odpověď #56 kdy: 07. 09. 2022, 11:44:15 »
Opravdu ti připadá, že tohle není racioální argument - ten jazyk je plný podobných záludných chování, kdy kód většinou funguje, ale pak někam přijde nula a ono to spadne. Případně se ti magicky ztratí přesnost.
Opravdu mi přijde, že to není racionální argument. Matně si vzpomínám na nějaký seznam, kde byl popis takovýchto špeků pro všelijaké jazyky. Já třeba aktuálně trpím u C#, protože ho ještě tak dobře neznám, ještě si toho všímám.

Vtip byl hlavně v tom, s jakou samozřejmostí jsi napsal:
https://www.php.net/manual/en/class.datetime.php
Každopádně počítám, že porovnávat to nejde, takže třeba triviální max($datetime1, $datetime2, $datetime3) neuděláš.

jen na základě pocitu, aniž by sis to alespoň vyzkoušel.

Můj závěr, založený jen na základě zkušeností s používáním je v tom, že mi nedělá problém se přepínat mezi PHP - C# - Java - Python. Protože jsou to víceméně podobné jazyky. Jistě, C# je o trošičku vymazlenějí jak Java nebo PHP, Java má knihovny na všechno a je čistější, ... Ale všechno je to prostě podobné. Když bych si měl vybírat mezi nimi tak rozhodování na základě komfortu jazyka nebude ani v první dvacítce důvodů, protože tak moc se zase neliší.
« Poslední změna: 07. 09. 2022, 11:45:50 od BoneFlute »

Re:Trendy v PHP
« Odpověď #57 kdy: 07. 09. 2022, 13:07:18 »
Ano, napsal jsem to bez vyzkoušení. Ale už vím, že php neumožňuje přetížit operátory a naši php vývojáři na takový styl práce nejsou zvyklí. Proto až na základě mého podnětu v rámci code review přibyla do naší vlastní implementace datetime pomocná funkce max(), která to řeší (do té doby to všichni převáděli na int a porovnávali ve for cyklu). Čili jsem to automaticky u datetime neočekával.

Nicméně na základě naší debaty jsem procházel dokumentaci PHP a nevidím tam, jak poznat, které třídy porovnávání podporují. Našel jsem debatu na StackOverflow, kde dokonce porovnávali date() a spoléhali na to, že proběhne implicitní konverze na string a ty stringy pak budou ve správném formátu. To je přístup, který mě doslova děsí a to že to v PHP prochází mi přijde jako nejhorší, těžko opravitelná vlastnost jazyka.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Trendy v PHP
« Odpověď #58 kdy: 07. 09. 2022, 15:39:08 »
Ano, napsal jsem to bez vyzkoušení. Ale už vím, že php neumožňuje přetížit operátory a naši php vývojáři na takový styl práce nejsou zvyklí. Proto až na základě mého podnětu v rámci code review přibyla do naší vlastní implementace datetime pomocná funkce max(), která to řeší (do té doby to všichni převáděli na int a porovnávali ve for cyklu). Čili jsem to automaticky u datetime neočekával.

Nicméně na základě naší debaty jsem procházel dokumentaci PHP a nevidím tam, jak poznat, které třídy porovnávání podporují. Našel jsem debatu na StackOverflow, kde dokonce porovnávali date() a spoléhali na to, že proběhne implicitní konverze na string a ty stringy pak budou ve správném formátu. To je přístup, který mě doslova děsí a to že to v PHP prochází mi přijde jako nejhorší, těžko opravitelná vlastnost jazyka.

Rozumím.

oss

  • ***
  • 229
    • Zobrazit profil
    • E-mail
Re:Trendy v PHP
« Odpověď #59 kdy: 08. 09. 2022, 08:55:18 »
No take objektivne: UT8 stringy - na prvy pohlad super, v realite ciste zlo, milion dalsich typov stringov
UTF8 má po řetězce spousta jazyků, proč je to zlo?
Že má několik typů pro řetězce je fakt, ale dává to smysl, ne? Převod na řetězce à la C nebo na seznam run se řeší všude možně, Go to má, i Fortran, dokonce i v rámci C existuje několik typů třeba na Windows.

Je to vykonova pasca. A mizerne sa s tym pracuje, neustale konverzie zru vykon. Ja viem, ze sa to zda pohodlne, ked sa stringy len spajaju, ale parsovanie cohokolvek je fakt cista bolest. To, ze to ma tak aj Go ma moc nezaujima, je to priserny jazyk.

No rad by som vratil temu k aktualnym trendom v PHP.