Typový system versus unittesty

[BoneFlute]

Ale to neznamená že to nejde.

dosud jsi neukázal, že to jde ani u jednoduchých funkcí pro sčítání a odčítání.

To je pravda. To ukázali jiní, dvakrát.

[Reklama]

[A. F.]

Že limit nemá být záporný, a že start musí být menší jak str nebudu psát do dokumentace ani do testů. Napíšu to pomocí závislostních typů, protože je to výhodnější.

A jak by si tu funkci substr těmi závislostními typy napsal?

[Filip Jirsák]

A optimalizaci prochazeni kolekce to nepotrebuje. Tu zajisti ten iterator.

Nezajistí, protože iterátor neví, jak je výhodné procházet kolekci z pohledu sumační funkce. Vždycky je to něco za něco. Buď můžete mít obecné API, které můžete používat opakovaně, ale za cenu horší optimalizace. A nebo můžete mít kód, který jde až na dřeň toho, co jde z hardwaru vyždímat, pak ale musíte rezignovat na abstrakci a univerzální rozhraní.

Unit test by podle me mel byt platfomne nezavisli.

Proč? Jednotkový test má testovat jednu samostatnou část kódu. Klidně to může být implementace v assembleru něčeho, co je na jiných platformách dostupné jako instrukce procesoru. Ale i kód ve vyšších jazycích může být potřeba otestovat na různých platformách různě.

BoneFlute uz tu popisoval jak to zaridit pri kompilaci na te 486.
Namitka byla pokud vim, ze 486 neni v dobe prekladu k dispozici.
Takze kdyz zjistim, ze mam pozadavek aby to bezelo na 486 tak si nejakou sezenu a zkusim to na ni zkompilovat.
Stejne jako u toho testu, ktery zkusim na nejake pustit.

Ale BoneFlute přece chce, aby bylo vše kontrolované v době překladu, tedy ty informace v typech musí být už v době překladu. Bez ohledu na to, zda nějakou 486 máte nebo nemáte k dispozici, a dokonce bez ohledu na to, zda nějaká 486 už byla či nebyla vytvořena. Když to tam mít nebudete, musíte v typu povolit něco jako „neznámé“, a tím povolíte to, čemu se chtěl BoneFlute vyhnout.

[Filip Jirsák]

Když to výhodnější nebude, tak to nepoužiju. Ale to neznamená že to nejde.

Čímž jste právě popřel to, čím jste odstartoval celou diskusi. Pokud vím, nelíbilo se vám, že testy se píšou jenom tehdy, když je to výhodné – a chtěl jste je nahradit něčím, co bude provádět kontroly vždy, bez ohledu na to, jestli si programátor myslí, zda je nebo není ta kontrola výhodná.

A mimochodem, s tím dokazováním, že to vždy jde, jste na tom taky dost bledě. Zatím jste neodkázal, že to jde, ani u konkrétních příkladů, natož abyste to dokázal obecně.

[BoneFlute]

Že limit nemá být záporný, a že start musí být menší jak str nebudu psát do dokumentace ani do testů. Napíšu to pomocí závislostních typů, protože je to výhodnější.

A jak by si tu funkci substr těmi závislostními typy napsal?

Jak jsem uváděl, zatím je ještě neovládám, takže toto je jen takový pseudokód:

Kód: [Vybrat]

function substr(str: String, start: Int 0 (strlen str), len: Int 0 (strlen str)) : String 0 (strlen str)
Zápis asi nic moc, tak vařím to z hlavy, bez přípravy.

[Reklama]

[Bacsa]

Že limit nemá být záporný, a že start musí být menší jak str nebudu psát do dokumentace ani do testů. Napíšu to pomocí závislostních typů, protože je to výhodnější.

A jak by si tu funkci substr těmi závislostními typy napsal?

Jak jsem uváděl, zatím je ještě neovládám, takže toto je jen takový pseudokód:

Kód: [Vybrat]

function substr(str: String, start: Int 0 (strlen str), len: Int 0 (strlen str)) : String 0 (strlen str)
Zápis asi nic moc, tak vařím to z hlavy, bez přípravy.

Doporučil bych knihu "Seven more languages in seven weeks", tam stručně popisují Idris, který se přesně na tohle hodí.

[gll]

Doporučil bych knihu "Seven more languages in seven weeks", tam stručně popisují Idris, který se přesně na tohle hodí.

dokážeš v tom Idrisu napsat jednořádkovou funkci?

[BoneFlute]

Doporučil bych knihu "Seven more languages in seven weeks", tam stručně popisují Idris, který se přesně na tohle hodí.

Díky! Mrknu na to.

Můžeš mě trochu navnadit, o čem všem se tam píše?

[listoper]

A optimalizaci prochazeni kolekce to nepotrebuje. Tu zajisti ten iterator.

Nezajistí, protože iterátor neví, jak je výhodné procházet kolekci z pohledu sumační funkce. Vždycky je to něco za něco. Buď můžete mít obecné API, které můžete používat opakovaně, ale za cenu horší optimalizace. A nebo můžete mít kód, který jde až na dřeň toho, co jde z hardwaru vyždímat, pak ale musíte rezignovat na abstrakci a univerzální rozhraní.

Iterator zajisti optimalni prochazeni kolekce. Myslel jsem, ze na tom scitani uz jsme se dohodli ze performance rozdil nebude.
Mozna neco prehlizim. Priklad?

BoneFlute uz tu popisoval jak to zaridit pri kompilaci na te 486.
Namitka byla pokud vim, ze 486 neni v dobe prekladu k dispozici.
Takze kdyz zjistim, ze mam pozadavek aby to bezelo na 486 tak si nejakou sezenu a zkusim to na ni zkompilovat.
Stejne jako u toho testu, ktery zkusim na nejake pustit.

Ale BoneFlute přece chce, aby bylo vše kontrolované v době překladu, tedy ty informace v typech musí být už v době překladu. Bez ohledu na to, zda nějakou 486 máte nebo nemáte k dispozici, a dokonce bez ohledu na to, zda nějaká 486 už byla či nebyla vytvořena. Když to tam mít nebudete, musíte v typu povolit něco jako „neznámé“, a tím povolíte to, čemu se chtěl BoneFlute vyhnout.

To aby to selhalo pri prekladu na 486 a fungovalo jinde prece nezalezi na tom jestli 486 existuje nebo ne.

[Bacsa]

Doporučil bych knihu "Seven more languages in seven weeks", tam stručně popisují Idris, který se přesně na tohle hodí.

Díky! Mrknu na to.

Můžeš mě trochu navnadit, o čem všem se tam píše?

O závislostních typech Je to úvod do toho jazyka se zaměřením na právě závislostní typy, protože znalost toho, na čem staví (FP à la Haskell), se předpokládá.

[BoneFlute]

Doporučil bych knihu "Seven more languages in seven weeks", tam stručně popisují Idris, který se přesně na tohle hodí.

Díky! Mrknu na to.

Můžeš mě trochu navnadit, o čem všem se tam píše?

O závislostních typech Je to úvod do toho jazyka se zaměřením na právě závislostní typy, protože znalost toho, na čem staví (FP à la Haskell), se předpokládá.

OK, díky.
Tak já jsem si původně představoval, že to třeba bere více teoreticky a i jiné techniky než závislostní typy. Ale taky dobrý. Díky!

[Bacsa]

Doporučil bych knihu "Seven more languages in seven weeks", tam stručně popisují Idris, který se přesně na tohle hodí.

Díky! Mrknu na to.

Můžeš mě trochu navnadit, o čem všem se tam píše?

O závislostních typech Je to úvod do toho jazyka se zaměřením na právě závislostní typy, protože znalost toho, na čem staví (FP à la Haskell), se předpokládá.

OK, díky.
Tak já jsem si původně představoval, že to třeba bere více teoreticky a i jiné techniky než závislostní typy. Ale taky dobrý. Díky!

Ne, je to poměrně stručné, ale jako úvod užitečné, s rozumnými příklady. Teoretičtěji a do hloubky to bere Bradyho kniha o Idrisu, tam jde od úplných začátků až po komplexní konstrukce, ale kdo zná Haskell, tak stejně dvě třetiny přeskočí.

[Filip Jirsák]

Iterator zajisti optimalni prochazeni kolekce.

Ano. Akorát že já nechci kolekci procházet, já chci získat součet jejích prvků.

Myslel jsem, ze na tom scitani uz jsme se dohodli ze performance rozdil nebude.

Nikoli, to byla pouze vaše chybná domněnka, kterou jsem vyvrátil.

Mozna neco prehlizim. Priklad?

Procesor nemůže pracovat s daty přímo, pracuje s tím, co má v registrech nebo nejbližší cache. Ta cache není moc velká, data do ní se tahají z pomalejší vzdálenější cache, z ještě pomalejší RAM nebo z ještě pomalejšího swapu. Aby procesor na data zbytečně nečekal, pokouší se odhadnout, jaká data budou potřeba, a ty načítá dopředu. Pokud tedy bude způsob procházení kolekce pro procesor předvídatelný, dokáže data včas přednačítat a jejich zpracování bude mnohem rychlejší, než když bude procesor každou chvíli na data čekat.

Navíc dnešní procesory jsou vícevláknové, a zrovna sumace se dá dobře paralelizovat – každé vlákno sečte část kolekce a na závěr se sečtou dílčí součty. Akorát z výše uvedeného důvodu je potřeba, aby každé vlákno zpracovávalo ucelený blok kolekce – tj. první vlákno třeba prvních 16 prvků, druhé vlákno dalších 16 prvků atd. To iterátor neumožňuje, ten by cpal jednotlivé prvky vláknům napřeskáčku (a ještě by se musel mezi vlákny zamykat).

To aby to selhalo pri prekladu na 486 a fungovalo jinde prece nezalezi na tom jestli 486 existuje nebo ne.

Ale ono to nemá selhat při překladu na 486. Má to selhat při překladu kdekoli, pokud by to např. na 486 selhalo při běhu. BoneFlute přece chtěl, aby se jakákoli chyba odhalila už při překladu, ne až při běhu testů.

[listoper]

Myslel jsem, ze na tom scitani uz jsme se dohodli ze performance rozdil nebude.

Nikoli, to byla pouze vaše chybná domněnka, kterou jsem vyvrátil.

Kde? Asi jsem prehledl...

Mozna neco prehlizim. Priklad?

Procesor nemůže pracovat s daty přímo, pracuje s tím, co má v registrech nebo nejbližší cache. Ta cache není moc velká, data do ní se tahají z pomalejší vzdálenější cache, z ještě pomalejší RAM nebo z ještě pomalejšího swapu. Aby procesor na data zbytečně nečekal, pokouší se odhadnout, jaká data budou potřeba, a ty načítá dopředu. Pokud tedy bude způsob procházení kolekce pro procesor předvídatelný, dokáže data včas přednačítat a jejich zpracování bude mnohem rychlejší, než když bude procesor každou chvíli na data čekat.

Navíc dnešní procesory jsou vícevláknové, a zrovna sumace se dá dobře paralelizovat – každé vlákno sečte část kolekce a na závěr se sečtou dílčí součty. Akorát z výše uvedeného důvodu je potřeba, aby každé vlákno zpracovávalo ucelený blok kolekce – tj. první vlákno třeba prvních 16 prvků, druhé vlákno dalších 16 prvků atd. To iterátor neumožňuje, ten by cpal jednotlivé prvky vláknům napřeskáčku (a ještě by se musel mezi vlákny zamykat).

To je ale dost nizkourovnova zalezitost. Myslim, ze v jazycich vyssi urovne s tim stejne moc neudelame, protoze jsme tak daleko abstrahovali od HW, ze nemuzeme optimalizovat na urovni l1 a l2 cache.
To je dan kterou platime za expresivnost jazyku.

To aby to selhalo pri prekladu na 486 a fungovalo jinde prece nezalezi na tom jestli 486 existuje nebo ne.

Ale ono to nemá selhat při překladu na 486. Má to selhat při překladu kdekoli, pokud by to např. na 486 selhalo při běhu. BoneFlute přece chtěl, aby se jakákoli chyba odhalila už při překladu, ne až při běhu testů.

Jmeno toho vlakna naznacuje, ze jde o srovnani toho co jde a nejde udelat typy vs unit testy.
Takze nevim jak BoneFlute, ale za me:
Az uvidim unit test ktery pri behu na Xeonu zahlasi ze dana funkce selze na 486 zacnu resit jak je mozne, ze tohle nedokaze typovy system.

[BoneFlute]

To je ale dost nizkourovnova zalezitost. Myslim, ze v jazycich vyssi urovne s tim stejne moc neudelame, protoze jsme tak daleko abstrahovali od HW, ze nemuzeme optimalizovat na urovni l1 a l2 cache.
To je dan kterou platime za expresivnost jazyku.

Zde bych si dovolil nesouhlasit.

Právě expresivnost jazyka nám, minimálně teoreticky, dovoluje agresivně optimalizovat. Tudíž se docela dobře na tu úroveň cache můžeme dostat.

Příklad: mám kolekci objektů, u které si kompilátor z typové signatury odvodí, že jsou imutable, tak mohu nejenom neřešit zámky, ale klidně můžu tu kolekci umístit na stacku, nebo ji inlinovat/rozkopírovat. Mě, jako uživatele to nezajímá, a kompilátor má volné ruce.

V praxi se to i dost ukazuje: http://funkcionalne.cz/2015/04/bez-typu-se-obejdeme-ale/

V kontextu tohoto vlákna: kompilátor píšou parta lidí, kteří se soustředí na různé tyto optimalizace. Obvykle můžeme očekávat špičky ve svém oboru. V případě, kdy to samé dělám testy, tak to píšeš zas a znova, a optimalizovat musíš opět zas a znova ty sám. Snad je z toho vidět ta motivace po typech.

Jmeno toho vlakna naznacuje, ze jde o srovnani toho co jde a nejde udelat typy vs unit testy.
Takze nevim jak BoneFlute, ale za me:
Az uvidim unit test ktery pri behu na Xeonu zahlasi ze dana funkce selze na 486 zacnu resit jak je mozne, ze tohle nedokaze typovy system.

:-D Tak nějak.