Jak validovat DTO v dynamicky typovaném jazyce?

[BoneFlute]

Trochu odbočím — koukals pak ještě někdy na záv. typy? Mám teď čerstvou zkušenost s jejich výukou, tak kdyby byl zájem

Nijak zvlášť. Aktuálně většinu svého volného času věnuju Rustu a realizaci konkrétního projektu. Takže k teorii se vrátím někdy později. Snad.

Ale od posledka a zvláště od vysvětlování forall se mi honí hlavou takové dojmy, že:
- zbytečně se zahodili výjimky, protože se autoři jazyků vykašlali na rozlišování checked/unchecked a nahradili se Option/Maybe.
- místo řešení rozhraní a tříd jako typových omezení, se používá forall, který je sice matematicky čistější, ale programátorsky neintuitivní
- navzdory mé antipatii k Pythonu (ano, typy), tak je mi na něm extrémně sympatická idea, že jazyk by měl programátorovi umožňovat jasně a srozumitelně vyjádřit co chce, a nekomplikovat mu to nějakou ideologií (OOP, FP, typy, etc)

Uvidím co si budu myslet, až se seznámím se Scalou a Idrisem.

PS: Zájem určitě bude, píšu si a předem díky za ochotu.

[Reklama]

[Idris]

Deklarace je nezajímavá. New je relikt. Prvek může vzniknout parsováním, přetypováním, deserializací, etc.

Deklarace je na tom to nejzajímavější, protože se na ní pozná chování (typového systému) jazyka. New je prostě vytvoření objektu, to má každý aspoň mírně OO jazyk. Parsování, přetypování apod. v sobě vždy zahrnuje toto “new” (může se samozřejmě jmenovat jinak, případně být implicitní jako např. v Dartu, ale pořád to je alokace někde na haldě nebo zásobníku).

[Idris]

Aktuálně většinu svého volného času věnuju Rustu a realizaci konkrétního projektu.

To zní dobře. Taky v Rustu poslední dobou dost píšu.

Ale od posledka a zvláště od vysvětlování forall se mi honí hlavou takové dojmy, že:
- navzdory mé antipatii k Pythonu (ano, typy), tak je mi na něm extrémně sympatická idea, že jazyk by měl programátorovi umožňovat jasně a srozumitelně vyjádřit co chce, a nekomplikovat mu to nějakou ideologií (OOP, FP, typy, etc)

Jo, takové jazyky jsou nejlepší. Podle tvůrců takový pragmatismus stojí za návrhem Go a Rustu. Ovšem třeba u Haskellu se asi nějaké teorii vyhnout nejde. Ale jakmile v nějaké diskusi dojde na ideologii, je to vošajslich

Uvidím co si budu myslet, až se seznámím se Scalou a Idrisem.

To jsem zvědav Poslední verze Scaly taky dostala silnější typový systém (path dependence).

[Wavelet]

Tedy zpět k otázce. Které jazyky jsou vlastně ty slabě typované, vůči kterým se ty silně typované vyhrazují?

Tak často se uvádí třeba, že neprovádí za zády žádná taková "zvěrstva".
 >>> True + 1
2
Otázka je, jestli to lze Pythonu vyčítat, když má ten typ implementovanou metodu, která toto přesně umožní. Pokud chci takové chování můžu ve spoustě jazycích použít extension methods. Skoro by se dalo říct, že to je moje "algebraická" neznalost, protože ten typ na to má prostě operaci. Být tebou mrknu se pro zajímavost na Scala 3 a Julia. Ty mají dle mého názoru zajímavý typový systém a mému srdci jsou bližší než např. Rust.

[Jiří Havel]

Tedy zpět k otázce. Které jazyky jsou vlastně ty slabě typované, vůči kterým se ty silně typované vyhrazují?

Tak často se uvádí třeba, že neprovádí za zády žádná taková "zvěrstva".
 >>> True + 1
2
Otázka je, jestli to lze Pythonu vyčítat, když má ten typ implementovanou metodu, která toto přesně umožní. Pokud chci takové chování můžu ve spoustě jazycích použít extension methods. Skoro by se dalo říct, že to je moje "algebraická" neznalost, protože ten typ na to má prostě operaci. Být tebou mrknu se pro zajímavost na Scala 3 a Julia. Ty mají dle mého názoru zajímavý typový systém a mému srdci jsou bližší než např. Rust.

Já třeba vidím zásadní rozdíl v tom, jestli nějakému stringu můžu dát metodu append co bere int (nebo i nějakou generickou verzi) a v tom, že ten int na string zkouší konvertovat překladač.
V prvním případě dá programátor takové všežravé operace jen tam, kde dávají smysl. Ve druhém případě to překladač zkouší všude. Je zásadní rozdíl, pokud se taková konverze děje při konkatenaci stringů, nebo třeba při otevírání souboru.

Implicitní konverze mají nepříjemnou tendenci dít se tam, kde je nikdo nečeká. Respektive čeká je jen guru daného jazyka, kterého už X-krát nepříjemně překvapily.

[Reklama]

[Ink]

Tedy zpět k otázce. Které jazyky jsou vlastně ty slabě typované, vůči kterým se ty silně typované vyhrazují?

Tak často se uvádí třeba, že neprovádí za zády žádná taková "zvěrstva".
 >>> True + 1
2
Otázka je, jestli to lze Pythonu vyčítat, když má ten typ implementovanou metodu, která toto přesně umožní. Pokud chci takové chování můžu ve spoustě jazycích použít extension methods. Skoro by se dalo říct, že to je moje "algebraická" neznalost, protože ten typ na to má prostě operaci. Být tebou mrknu se pro zajímavost na Scala 3 a Julia. Ty mají dle mého názoru zajímavý typový systém a mému srdci jsou bližší než např. Rust.

Já třeba vidím zásadní rozdíl v tom, jestli nějakému stringu můžu dát metodu append co bere int (nebo i nějakou generickou verzi) a v tom, že ten int na string zkouší konvertovat překladač.
V prvním případě dá programátor takové všežravé operace jen tam, kde dávají smysl. Ve druhém případě to překladač zkouší všude. Je zásadní rozdíl, pokud se taková konverze děje při konkatenaci stringů, nebo třeba při otevírání souboru.

Implicitní konverze mají nepříjemnou tendenci dít se tam, kde je nikdo nečeká. Respektive čeká je jen guru daného jazyka, kterého už X-krát nepříjemně překvapily.

Zcela zásadní nectnost Pythonu (z mého hlediska) je, že neudělali boolovský typ v podmínkách exkluzivní. Že umožnili podmínky typu if (x), kde x může být číslo, řetězec, kontejner nebo jakýkoli jiný objekt (když nemá __bool__ nebo __len__(), bere se jako True), je podle mě chyba návrhu.

Na druhou stranu je bool legitimním a přiznaným celočíselným typem, takže to sčítání není problém, který bych řešil:

https://docs.python.org/3/reference/datamodel.html#index-10

[Jiří Havel]

Zcela zásadní nectnost Pythonu (z mého hlediska) je, že neudělali boolovský typ v podmínkách exkluzivní. Že umožnili podmínky typu if (x), kde x může být číslo, řetězec, kontejner nebo jakýkoli jiný objekt (když nemá __bool__ nebo __len__(), bere se jako True), je podle mě chyba návrhu.

Souhlas, hlavně to chybějící _bool_ je solidní past.

Na druhou stranu je bool legitimním a přiznaným celočíselným typem, takže to sčítání není problém, který bych řešil:

https://docs.python.org/3/reference/datamodel.html#index-10

Bool je teda dost pochybný celočíselný typ. Problém není v tom, že by to chování nebylo přiznané v dokumentaci, ale v tom že většina programátorů dokumentaci nemá našprtanou. Každá věc, kterou je třeba přiznat v dokumentaci, je potenciální past.
Ukažte mi programátora, který kompletně pročetl veškerou dokumentaci, než začal nějaký jazyk používat. Do dokumentace se leze až ve chvílí, kdy si člověk uvědomí, že něco neví.

[BoneFlute]

Tedy zpět k otázce. Které jazyky jsou vlastně ty slabě typované, vůči kterým se ty silně typované vyhrazují?

Tak často se uvádí třeba, že neprovádí za zády žádná taková "zvěrstva".
 >>> True + 1
2
Otázka je, jestli to lze Pythonu vyčítat, když má ten typ implementovanou metodu, která toto přesně umožní. Pokud chci takové chování můžu ve spoustě jazycích použít extension methods. Skoro by se dalo říct, že to je moje "algebraická" neznalost, protože ten typ na to má prostě operaci. Být tebou mrknu se pro zajímavost na Scala 3 a Julia. Ty mají dle mého názoru zajímavý typový systém a mému srdci jsou bližší než např. Rust.

Já třeba vidím zásadní rozdíl v tom, jestli nějakému stringu můžu dát metodu append co bere int (nebo i nějakou generickou verzi) a v tom, že ten int na string zkouší konvertovat překladač.
V prvním případě dá programátor takové všežravé operace jen tam, kde dávají smysl. Ve druhém případě to překladač zkouší všude. Je zásadní rozdíl, pokud se taková konverze děje při konkatenaci stringů, nebo třeba při otevírání souboru.

Implicitní konverze mají nepříjemnou tendenci dít se tam, kde je nikdo nečeká. Respektive čeká je jen guru daného jazyka, kterého už X-krát nepříjemně překvapily.

OK, jenže v tom vidím určitý problém. Jak jsem psal zde: "Skutečnost, že se mi Javascript snaží automaticky konvertovat cokoliv podobného číslu na číslo má sice vliv na programátorský prožitek, ale že by z toho musela být extra kategorie si nemyslím."

Můžete oprávněně namítnout, že mám nízké požadavky a dám vám za pravdu. Ale Idris tady tvrdil, že než statické verzus dynamické, to je mnohem zásadnějším rozdílem silné verzus slabé. A to mi přijde moc divokej matroš.

Tak jak teda?

Je teda silné verzus slabé "jen" o vhodném/nevhodném samo konvertování, nebo je v tom víc?

[Idris]

Ale Idris tady tvrdil, že než statické verzus dynamické, to je mnohem zásadnějším rozdílem silné verzus slabé. […]
Tak jak teda?
Je teda silné verzus slabé "jen" o vhodném/nevhodném samo konvertování, nebo je v tom víc?

Evidentně jsem měl na mysli jinou definici silné vs. slabé (je jich několik a žádná “závazná”). Já mám zažitou tu o typovém runtimu. Ale je fakt, že ta definice založená na konvertibilitě je mnohem zajímavější, zvlášť když se někdo odmítá bavit o C/C++

[Jiří Havel]

Tedy zpět k otázce. Které jazyky jsou vlastně ty slabě typované, vůči kterým se ty silně typované vyhrazují?

Tak často se uvádí třeba, že neprovádí za zády žádná taková "zvěrstva".
 >>> True + 1
2
Otázka je, jestli to lze Pythonu vyčítat, když má ten typ implementovanou metodu, která toto přesně umožní. Pokud chci takové chování můžu ve spoustě jazycích použít extension methods. Skoro by se dalo říct, že to je moje "algebraická" neznalost, protože ten typ na to má prostě operaci. Být tebou mrknu se pro zajímavost na Scala 3 a Julia. Ty mají dle mého názoru zajímavý typový systém a mému srdci jsou bližší než např. Rust.

Já třeba vidím zásadní rozdíl v tom, jestli nějakému stringu můžu dát metodu append co bere int (nebo i nějakou generickou verzi) a v tom, že ten int na string zkouší konvertovat překladač.
V prvním případě dá programátor takové všežravé operace jen tam, kde dávají smysl. Ve druhém případě to překladač zkouší všude. Je zásadní rozdíl, pokud se taková konverze děje při konkatenaci stringů, nebo třeba při otevírání souboru.

Implicitní konverze mají nepříjemnou tendenci dít se tam, kde je nikdo nečeká. Respektive čeká je jen guru daného jazyka, kterého už X-krát nepříjemně překvapily.

OK, jenže v tom vidím určitý problém. Jak jsem psal zde: "Skutečnost, že se mi Javascript snaží automaticky konvertovat cokoliv podobného číslu na číslo má sice vliv na programátorský prožitek, ale že by z toho musela být extra kategorie si nemyslím."

Můžete oprávněně namítnout, že mám nízké požadavky a dám vám za pravdu. Ale Idris tady tvrdil, že než statické verzus dynamické, to je mnohem zásadnějším rozdílem silné verzus slabé. A to mi přijde moc divokej matroš.

Tak jak teda?

Je teda silné verzus slabé "jen" o vhodném/nevhodném samo konvertování, nebo je v tom víc?

Pokud je tohle jen "programátorský prožitek", tak se všechny výpočetně úplné jazyky liší jen v tom prožitku. Ty kategorie silný/slabý jsou samozřejmě neostré, ale to je jakákoliv klasifikace.

Jestli je důležitější rozdíl silný/slabý nebo statický/dynamický netuším. Obojí přináší dost znatelné důsledky. A ano, esence toho slabého typování jsou IMO ty automatické konverze.

[Ink]

Na druhou stranu je bool legitimním a přiznaným celočíselným typem, takže to sčítání není problém, který bych řešil:

https://docs.python.org/3/reference/datamodel.html#index-10

Bool je teda dost pochybný celočíselný typ. Problém není v tom, že by to chování nebylo přiznané v dokumentaci, ale v tom že většina programátorů dokumentaci nemá našprtanou. Každá věc, kterou je třeba přiznat v dokumentaci, je potenciální past.
Ukažte mi programátora, který kompletně pročetl veškerou dokumentaci, než začal nějaký jazyk používat. Do dokumentace se leze až ve chvílí, kdy si člověk uvědomí, že něco neví.

Mohl bych třeba namítnout, že tyhle věci by programátor nějak obsáhnout mohl a že ta taxonomie se nějak dělat musela. Co mi přijde ale zásadnější, je že bool by se do této situace v rozumně psaném kódu neměl nikdy dostat - už podle názvů proměnných by mělo být jasné, co je číslo (počet) a co je bool. Jasně, vzhledem k výše napsanému bych osobně bool fakt úplně vyloučil z kolektivu a nedovolil ani srovnávání ani sčítání s ostatními objekty. Ale to už se zas z opačné strany dostáváme k tomu, že Guido a spol. nikdy neměli nechat ostatní typy objektů, aby boolu lezly do zelí. Tam je ten zásadní problém a vždycky bude, pokud tohle nějak nepořeší třeba Python 4.

[Jiří Havel]

Na druhou stranu je bool legitimním a přiznaným celočíselným typem, takže to sčítání není problém, který bych řešil:

https://docs.python.org/3/reference/datamodel.html#index-10

Bool je teda dost pochybný celočíselný typ. Problém není v tom, že by to chování nebylo přiznané v dokumentaci, ale v tom že většina programátorů dokumentaci nemá našprtanou. Každá věc, kterou je třeba přiznat v dokumentaci, je potenciální past.
Ukažte mi programátora, který kompletně pročetl veškerou dokumentaci, než začal nějaký jazyk používat. Do dokumentace se leze až ve chvílí, kdy si člověk uvědomí, že něco neví.

Mohl bych třeba namítnout, že tyhle věci by programátor nějak obsáhnout mohl a že ta taxonomie se nějak dělat musela. Co mi přijde ale zásadnější, je že bool by se do této situace v rozumně psaném kódu neměl nikdy dostat - už podle názvů proměnných by mělo být jasné, co je číslo (počet) a co je bool.

Tahle situace nastane úplně hravě. Stačí třeba omylem přehodit parametry funkce o pár úrovní zanoření výš. V dynamicky typovaném jazyce z názvu parametru nezjistím, co je uvnitř, protože to přišlo zvenku. Slabé typování k tomu  pak přidá bonusové WTF, kdy taková situace neskončí chybou ani v runtime, ale tichou a nenápadnou konverzí na totální nesmysl.

[Google CTCCTCGGCGGGCACGTAG]

mypy ma prepinac --strict-boolean

[Idris]

Slabé typování k tomu  pak přidá bonusové WTF, kdy taková situace neskončí chybou ani v runtime, ale tichou a nenápadnou konverzí na totální nesmysl.

Z tohoto důvodu mám rád jazyky, které vyžadují explicitní přetypování i třeba u typových aliasů (Ada).

[Google CTCCTCGGCGGGCACGTAG]

ale tichou a nenápadnou konverzí na totální nesmysl.

neni konverze