Typový system versus unittesty

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Typový system versus unittesty
« Odpověď #675 kdy: 20. 08. 2018, 01:26:54 »
jak by tedy vypadaly ty funkce v Elmu?
To, že změním chování nějaké funkce, ale vnější signatura (vstup a výstup) zůstane stejná, to by zase mohli podchytit závislostní typy.
Ano, ty jsou mocné, docela rád bych tu viděl nějaké příklady problémů, které záv. typy řeší.

Tak třeba toto: https://forum.root.cz/index.php?topic=18370.0
nebo i toto substr("abc", 6, -2) by měli závislostní typy podchytit. Ale nemohu sloužit, zatím jsem ve fázi student :-)


Re:Typový system versus unittesty
« Odpověď #676 kdy: 20. 08. 2018, 07:36:20 »
A když se to spojí, tak máme ten hypotetický jazyk, který by dokázal nahradit testy v případech užití, které byly uváděny.
Uváděn byl příklad dvou funkcí pro sumaci. Nějak ho stále přehlížíte.

Obávám se, že to není nijak podstatné.

Byly časy, kdy API funkce (říkejme tomu spíše signatura) vypadala nějak takto:

function substr(String str, Int start, Int len) : String

A v praxi jsme pak museli ošetřit testem, co se stane, když zavoláme substr("abc", 6, -2). Někde uvnitř té funkce bylo definováno, že to má vyhodit výjimku, prázdný řetězec, nebo něco takového. Podstatné ale je, že signatura funkce o této nesmyslnosti nic nevěděla.

Dnes už máme typy na takové úrovni, že dokážeme zohlednit, že substr("abc", 6, -2) nepůjde vůbec přeložit. A myslím, že nikoho nijak zvlášť nezajímá, že kdysi dávno se tvrdilo, že ošetření těchto nesmyslných vstupů je otázka implementace, a nikoliv API/Signatury.

Takže pokud trváš na tom, že API/Signatura a implemnetace/chování jsou dva oddělené světy, tak já ti tvůj názor přeji, ale v takovém případě nám nejde o stejnou věc.
Ale já nepíšu o signatuře, píšu o API. A součástí API té funkce substr je, že někde v dokumentaci, např. v manuálové stránce, je napsáno, co ta funkce má dělat, a v lepším případě i jaké jsou možné parametry a co to bude dělat, pokud budou parametry mimo rozsah. V horším případě tam zejména ty chybové stavy moc dobře popsané nebudou , a pak nastává ten případ, o kterém jsem také psal, že se mohou lišit názory na to, jaké je vlastně přesné API té funkce.

Že API a implementace jsou dva oddělené světy jsem uváděl na tom příkladu se sumací, který raději ignorujete. Mimochodem, je to uváděné jako základní vlastnost API, že odstíní uživatele od konkrétní implementace, takže implementace se může měnit, aniž by se o tom uživatel dozvěděl. Znáte třeba POSIX?

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
Nechcete doufám tvrdit, že stejný kód poběží stejně rychle na 386 a na dnešních výkonných procesorech? Že poběží stejně rychle na Raspberry Pi, na chytrém telefonu i na pracovní stanici?

Ostatně, to, že rychlost funkce závisela na rychlosti procesoru je pradávná historie.
Říká vám něco pojem „výpočetní složitost“? Vážně si myslíte, že když budete mít v poli o milionu čísel najít největší hodnotu, nebo ho setřídit, nebude doba trvání té funkce záviset mimo jiné na rychlosti procesoru?

Jen si to představ. Vezmeš nějakou hru a dáš ji přeložit pod 486kou, a ono ti to odmítne, protože nejde zaručit potřebnou rychlost. Horní mez je sranda, to stačí jen oříznout.

Tak samozřejmě se můžeme bavit o tom, jak to zjistit, jak moc to jde zaručit, ale je třeba myslet na kontext tohoto vlákna. Porovnáváme to s testy. Pokud to nezvládneš ani testy, tak není nutné řešit jak to udělat typy.
Jak přeložit pod 486? Vy jí máte k dispozici? A máte k dispozici i budoucí procesory? Navíc rychlost té funkce by přece musela být zakódovaná v tom typu.

Testy se tohle řeší snadno. Napíše se test, který bude měřit dobu běhu té funkce a zkontroluje, že je v daném rozmezí. Že ten test odhalí chybu, až když ho spustím na příslušném zařízení? Ano, to je vlastností testů, že nejsou prevencí chyb, ale umožňují chyby rychle nalézat po té, co k chybě došlo. Že testy nepokrývají všechny případy? Ano, i to je vlastností testů, a to umožňuje, aby se testy vůbec v reálném světě používaly. Protože programování je stále založené na tom, že se vybírají ty podstatné věci, které se vyjádří v programu, a všechny ostatní nepodstatné se ignorují. Takže se třeba v definici API ignorují záporné hodnoty indexu funkce substr, protože přece nikdo soudný nebude předávat záporný index.

Aby ten váš dokonalý typový systém opravdu předcházel všem chybám, jak si představujete, musel by do typu nakonec zakódovat celý vesmír. Vy považujete za nedokonalost testů, že nepokrývají vše. To ale není nedokonalost testů, to je „nedokonalost“, která je v samotných základech programování, a dokonce i v základech jakéhokoli modelování nebo abstraktního popisu světa, který dělá např. věda. A tahle „nedokonalost“ způsobuje, že vůbec něco jako programování nebo věda může existovat. Bez toho ořezávání nepodstatných informací by to totiž nebyl model ale reálný svět. A že občas ořízneme i informaci, která ve skutečnosti je podstatná? Ano, to se stává, jsme jen omylní lidé. Proto máme různé způsoby, jak na takové chyby přijít. Ale řešením není snažit se tam nacpat co nejvíc jakýchkoli informací, protože to byste nikdy neskončil.

Re:Typový system versus unittesty
« Odpověď #677 kdy: 20. 08. 2018, 08:31:46 »
A když se to spojí, tak máme ten hypotetický jazyk, který by dokázal nahradit testy v případech užití, které byly uváděny.
Uváděn byl příklad dvou funkcí pro sumaci. Nějak ho stále přehlížíte.

Obávám se, že to není nijak podstatné.

Byly časy, kdy API funkce (říkejme tomu spíše signatura) vypadala nějak takto:

function substr(String str, Int start, Int len) : String

A v praxi jsme pak museli ošetřit testem, co se stane, když zavoláme substr("abc", 6, -2). Někde uvnitř té funkce bylo definováno, že to má vyhodit výjimku, prázdný řetězec, nebo něco takového. Podstatné ale je, že signatura funkce o této nesmyslnosti nic nevěděla.

Dnes už máme typy na takové úrovni, že dokážeme zohlednit, že substr("abc", 6, -2) nepůjde vůbec přeložit. A myslím, že nikoho nijak zvlášť nezajímá, že kdysi dávno se tvrdilo, že ošetření těchto nesmyslných vstupů je otázka implementace, a nikoliv API/Signatury.

Takže pokud trváš na tom, že API/Signatura a implemnetace/chování jsou dva oddělené světy, tak já ti tvůj názor přeji, ale v takovém případě nám nejde o stejnou věc.
Ale já nepíšu o signatuře, píšu o API. A součástí API té funkce substr je, že někde v dokumentaci, např. v manuálové stránce, je napsáno, co ta funkce má dělat, a v lepším případě i jaké jsou možné parametry a co to bude dělat, pokud budou parametry mimo rozsah. V horším případě tam zejména ty chybové stavy moc dobře popsané nebudou , a pak nastává ten případ, o kterém jsem také psal, že se mohou lišit názory na to, jaké je vlastně přesné API té funkce.
To ze se nekdo rozhodl, ze nebude formalizovat veskere pozadavky na funkci, a ze neco jen popise v dokumentaci, neni proto, ze by to neslo, ale proto ze se mu nechtelo.
BoneFluteovi se chce.

Že API a implementace jsou dva oddělené světy jsem uváděl na tom příkladu se sumací, který raději ignorujete. Mimochodem, je to uváděné jako základní vlastnost API, že odstíní uživatele od konkrétní implementace, takže implementace se může měnit, aniž by se o tom uživatel dozvěděl. Znáte třeba POSIX?
Kdyz se zamyslim nad tim prikladem se sumaci tak mi prijde, ze to neni idealni. Tim rikam, ze bude ta funkce pracovat jen s nejakou linearni kolekci a dost se tim omezuji.
Kdyby byl na vstupu misto toho iterator tak dosahnu vetsi znovupouzitelnosti. A jen tak mimochoddem ziskam to, ze smer iterace bude dany tim iteratorem a ne zakodovany v implementaci te sumy.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
Nechcete doufám tvrdit, že stejný kód poběží stejně rychle na 386 a na dnešních výkonných procesorech? Že poběží stejně rychle na Raspberry Pi, na chytrém telefonu i na pracovní stanici?
By me zajimalo jestli v Turbo pascalu sli vubec napsat hodiny, nebo treba stopky...
http://computer-programming-forum.com/29-pascal/c1fd619ca94be881.htm

Jen si to představ. Vezmeš nějakou hru a dáš ji přeložit pod 486kou, a ono ti to odmítne, protože nejde zaručit potřebnou rychlost. Horní mez je sranda, to stačí jen oříznout.

Tak samozřejmě se můžeme bavit o tom, jak to zjistit, jak moc to jde zaručit, ale je třeba myslet na kontext tohoto vlákna. Porovnáváme to s testy. Pokud to nezvládneš ani testy, tak není nutné řešit jak to udělat typy.
Jak přeložit pod 486? Vy jí máte k dispozici? A máte k dispozici i budoucí procesory? Navíc rychlost té funkce by přece musela být zakódovaná v tom typu.

Testy se tohle řeší snadno. Napíše se test, který bude měřit dobu běhu té funkce a zkontroluje, že je v daném rozmezí. Že ten test odhalí chybu, až když ho spustím na příslušném zařízení? Ano, to je vlastností testů, že nejsou prevencí chyb, ale umožňují chyby rychle nalézat po té, co k chybě došlo.
Takze az napisu tu hru a budu ji prodavat skolakum tak je slusne poprosim, aby mi na svem stroji napred pustili testy z diskety 2?

Že testy nepokrývají všechny případy? Ano, i to je vlastností testů, a to umožňuje, aby se testy vůbec v reálném světě používaly. Protože programování je stále založené na tom, že se vybírají ty podstatné věci, které se vyjádří v programu, a všechny ostatní nepodstatné se ignorují. Takže se třeba v definici API ignorují záporné hodnoty indexu funkce substr, protože přece nikdo soudný nebude předávat záporný index.
Co kdyz se si zvykl na negativni indexovani v pythonu? Nejsem soudny?

v

Re:Typový system versus unittesty
« Odpověď #678 kdy: 20. 08. 2018, 09:06:07 »
jak by tedy vypadaly ty funkce v Elmu?
To, že změním chování nějaké funkce, ale vnější signatura (vstup a výstup) zůstane stejná, to by zase mohli podchytit závislostní typy.
Ano, ty jsou mocné, docela rád bych tu viděl nějaké příklady problémů, které záv. typy řeší.
měli jsme tu vektory s pevnou délkou tj. kontrola indexu při překladu

v

Re:Typový system versus unittesty
« Odpověď #679 kdy: 20. 08. 2018, 09:09:10 »
Protože programování je stále založené na tom, že se vybírají ty podstatné věci, které se vyjádří v programu, a všechny ostatní nepodstatné se ignorují. Takže se třeba v definici API ignorují záporné hodnoty indexu funkce substr, protože přece nikdo soudný nebude předávat záporný index.
buffer overflow? sql injection?


Re:Typový system versus unittesty
« Odpověď #680 kdy: 20. 08. 2018, 09:11:32 »
To ze se nekdo rozhodl, ze nebude formalizovat veskere pozadavky na funkci, a ze neco jen popise v dokumentaci, neni proto, ze by to neslo, ale proto ze se mu nechtelo.
Nikoli, je to proto, že to nejde. Abyste popsal opravdu vše, musel byste v důsledku popsat celý vesmír.

BoneFluteovi se chce.
Ne, jemu se chce jenom teoretizovat. Kdyby se mu chtělo to opravdu popisovat, nemusí čekat na žádný formální jazyk a může začít tím, že funkci přesně naspecifikuje v jazyce českém.

Kdyz se zamyslim nad tim prikladem se sumaci tak mi prijde, ze to neni idealni. Tim rikam, ze bude ta funkce pracovat jen s nejakou linearni kolekci a dost se tim omezuji.
Je to příklad, který můžete potkat v praxi. Byl by celkem k ničemu dokonalý typový systém, ve kterém by se daly psát jen ideální programy, ale reálné programy nikoli.

Kdyby byl na vstupu misto toho iterator tak dosahnu vetsi znovupouzitelnosti. A jen tak mimochoddem ziskam to, ze smer iterace bude dany tim iteratorem a ne zakodovany v implementaci te sumy.
A nebo taky ne. Iterátor definuje pořadí, sečíst můžete ale i prvky, které žádné pořadí nemají. A může být výhodnější prvky sčítat jinak, než v pořadí určeném iterátorem. Navíc to, že směr iterace bude daný iterátorem, je nevýhoda – ty dva příklady se lišily tím, že v některých případech mohl být jeden přístup efektivnější než druhý, o čemž by měl vědět autor implementace té sumační funkce, ale vůbec to nemá zajímat jejího uživatele. To je právě součást API – že schovává implementační detaily.

By me zajimalo jestli v Turbo pascalu sli vubec napsat hodiny, nebo treba stopky...
Šly.

Takze az napisu tu hru a budu ji prodavat skolakum tak je slusne poprosim, aby mi na svem stroji napred pustili testy z diskety 2?
Chápete rozdíl mezi „prevencí“ a „až po té, co k chybě došlo“?

agent

Re:Typový system versus unittesty
« Odpověď #681 kdy: 20. 08. 2018, 09:13:03 »
Takže se třeba v definici API ignorují záporné hodnoty indexu funkce substr, protože přece nikdo soudný nebude předávat záporný index.
Autoři PHP na to mají zjevně jiný názor - záporný parametr znamená že se bere x znaků od konce  :)

Re:Typový system versus unittesty
« Odpověď #682 kdy: 20. 08. 2018, 09:54:47 »
To ze se nekdo rozhodl, ze nebude formalizovat veskere pozadavky na funkci, a ze neco jen popise v dokumentaci, neni proto, ze by to neslo, ale proto ze se mu nechtelo.
Nikoli, je to proto, že to nejde. Abyste popsal opravdu vše, musel byste v důsledku popsat celý vesmír.
Jakoze abych mel kompletni API tak potrebuju osetrit pripad ze mi kozel sezere procesor?

BoneFluteovi se chce.
Ne, jemu se chce jenom teoretizovat. Kdyby se mu chtělo to opravdu popisovat, nemusí čekat na žádný formální jazyk a může začít tím, že funkci přesně naspecifikuje v jazyce českém.
Hmmm

Kdyz se zamyslim nad tim prikladem se sumaci tak mi prijde, ze to neni idealni. Tim rikam, ze bude ta funkce pracovat jen s nejakou linearni kolekci a dost se tim omezuji.
Je to příklad, který můžete potkat v praxi. Byl by celkem k ničemu dokonalý typový systém, ve kterém by se daly psát jen ideální programy, ale reálné programy nikoli.
Nechtel jsem primo rict, ze to smrdi tak jsem pouzil sugar coating "neni idealni"


Kdyby byl na vstupu misto toho iterator tak dosahnu vetsi znovupouzitelnosti. A jen tak mimochoddem ziskam to, ze smer iterace bude dany tim iteratorem a ne zakodovany v implementaci te sumy.
A nebo taky ne. Iterátor definuje pořadí, sečíst můžete ale i prvky, které žádné pořadí nemají. A může být výhodnější prvky sčítat jinak, než v pořadí určeném iterátorem. Navíc to, že směr iterace bude daný iterátorem, je nevýhoda – ty dva příklady se lišily tím, že v některých případech mohl být jeden přístup efektivnější než druhý, o čemž by měl vědět autor implementace té sumační funkce, ale vůbec to nemá zajímat jejího uživatele. To je právě součást API – že schovává implementační detaily.
No prave ze ten Iterator schova jeste vic implementacnich detailu. A muzu ho snad snadno napsat i pro "veci" co sami od sebe poradi nemaji. Efektivita scitani snad bude stejna pri obou smerech iterace. A optimalni zpusob iterace by mel prave spis zaridit ten iterator nez funkce co ho bude pouzivat. Protoze kdyz budu mit 1000 funkci iterujicich stejnou kolekci tak optimalizace bude potreba na 1000 mistech. S iteratorem jen na jednom...

By me zajimalo jestli v Turbo pascalu sli vubec napsat hodiny, nebo treba stopky...
Šly.
Asi si prehlidl ten odkaz. Byla to ironicka poznamka...

Takze az napisu tu hru a budu ji prodavat skolakum tak je slusne poprosim, aby mi na svem stroji napred pustili testy z diskety 2?
Chápete rozdíl mezi „prevencí“ a „až po té, co k chybě došlo“?
Tak kdy se teda ty testy budou na te skolakove 486 poustet?

Re:Typový system versus unittesty
« Odpověď #683 kdy: 20. 08. 2018, 10:45:46 »
Jakoze abych mel kompletni API tak potrebuju osetrit pripad ze mi kozel sezere procesor?
Víceméně. V tomhle případě to asi bude zbytečné řešit, protože bez procesoru nebude na čem ten kód spouštět. Ale jinak je to přesně ono – co všechno se má ještě zahrnout do definice API. Je jasné, že substr bude všichni volat s nezáporným indexem, a nebo je potřeba nadefinovat i to, jak se má chovat, když někdo použije záporný index? A co když ho někdo zavolá s délkou větší, než je dostupná délka řetězce? A co když někdo závisí i na tom, jak dlouho ta funkce trvá? Jsou to všechno stále méně a méně pravděpodobné věci. Ale to je přesně to, na co si BoneFlute na začátku stěžoval, že testy se píší jenom na ty pravděpodobnější chyby a méně pravděpodobné chyby se ignorují – do té doby, než se ukáže, že je to pravděpodobnější, než si někdo myslel. BoneFlute řešil, jak podchytit všechny případy – tedy i ty málo pravděpodobné, jako že kozel sežere procesor.

Efektivita scitani snad bude stejna pri obou smerech iterace.
Efektivita sčítání ano. Ale stejná nemusí být efektivita procházení kolekce. Procházení jednosměrného spojového seznamu „proti srsti“ bude obvykle mnohem nákladnější, než procházení po směru.

A optimalni zpusob iterace by mel prave spis zaridit ten iterator nez funkce co ho bude pouzivat. Protoze kdyz budu mit 1000 funkci iterujicich stejnou kolekci tak optimalizace bude potreba na 1000 mistech. S iteratorem jen na jednom...
Jenže to, že budete pro sčítání prvků iterovat přes jednotlivé prvky, je implementační detail. Ta sumace může být implementovaná i jinak.

Tak kdy se teda ty testy budou na te skolakove 486 poustet?
Když se s tím bude počítat předem jako s prostředím, kde je potřeba to testovat, bude se to tam spouštět třeba v rámci buildu. Když se takový požadavek objeví až dodatečně, spustí se ty testy tehdy, až se ten požadavek objeví – a díky testům bude snazší zjistit, jestli to na té 486 bude fungovat a co případně opravit. S dokonalým typovým systémem byste tu 486 musel řešit, i když by nikdo neočekával, že se ta aplikace na 486 někdy bude spouštět.

Re:Typový system versus unittesty
« Odpověď #684 kdy: 20. 08. 2018, 11:37:17 »
Jakoze abych mel kompletni API tak potrebuju osetrit pripad ze mi kozel sezere procesor?
Víceméně. V tomhle případě to asi bude zbytečné řešit, protože bez procesoru nebude na čem ten kód spouštět. Ale jinak je to přesně ono – co všechno se má ještě zahrnout do definice API. Je jasné, že substr bude všichni volat s nezáporným indexem, a nebo je potřeba nadefinovat i to, jak se má chovat, když někdo použije záporný index? A co když ho někdo zavolá s délkou větší, než je dostupná délka řetězce? A co když někdo závisí i na tom, jak dlouho ta funkce trvá? Jsou to všechno stále méně a méně pravděpodobné věci. Ale to je přesně to, na co si BoneFlute na začátku stěžoval, že testy se píší jenom na ty pravděpodobnější chyby a méně pravděpodobné chyby se ignorují – do té doby, než se ukáže, že je to pravděpodobnější, než si někdo myslel. BoneFlute řešil, jak podchytit všechny případy – tedy i ty málo pravděpodobné, jako že kozel sežere procesor.
Myslim, ze BoneFlute bude spokojeny uz kdyz ten typovy system dokaze pokryt to co unit testy. Dokud neuvidim unit test na kozla pozirajiciho procesor tak bych tyhle pripady nechal stranou.

A optimalni zpusob iterace by mel prave spis zaridit ten iterator nez funkce co ho bude pouzivat. Protoze kdyz budu mit 1000 funkci iterujicich stejnou kolekci tak optimalizace bude potreba na 1000 mistech. S iteratorem jen na jednom...
Jenže to, že budete pro sčítání prvků iterovat přes jednotlivé prvky, je implementační detail. Ta sumace může být implementovaná i jinak.
Kdyz bude mit funkce na vstupu iterator misto kolekce tak ten implementacni detail je tak trochu vynuceny v tom API, nemyslis?

Tak kdy se teda ty testy budou na te skolakove 486 poustet?
Když se s tím bude počítat předem jako s prostředím, kde je potřeba to testovat, bude se to tam spouštět třeba v rámci buildu. Když se takový požadavek objeví až dodatečně, spustí se ty testy tehdy, až se ten požadavek objeví – a díky testům bude snazší zjistit, jestli to na té 486 bude fungovat a co případně opravit. S dokonalým typovým systémem byste tu 486 musel řešit, i když by nikdo neočekával, že se ta aplikace na 486 někdy bude spouštět.
Mam pocit, ze tohle uz taky neni tak uplne o unit testech, teda pokud nemam takovy test napsany na (skoro) kazdou funkci v cele aplikaci. Neco podobneho resil kolega tusim pomoci AOP a myslim, ze slo spis o performance testy nez o unit testy.

Re:Typový system versus unittesty
« Odpověď #685 kdy: 20. 08. 2018, 11:51:42 »
Kdyz bude mit funkce na vstupu iterator misto kolekce tak ten implementacni detail je tak trochu vynuceny v tom API, nemyslis?
Jenže se implementace tím API zbytečně omezuje a nemusí být optimální.

Mam pocit, ze tohle uz taky neni tak uplne o unit testech, teda pokud nemam takovy test napsany na (skoro) kazdou funkci v cele aplikaci. Neco podobneho resil kolega tusim pomoci AOP a myslim, ze slo spis o performance testy nez o unit testy.
Je to pořád jednotkový test, nebo možná funkční test. Neřeší se výkon, ale to, že ta aplikace je za určité situace nepoužitelná nebo padá na chybu.

Bacsa

Re:Typový system versus unittesty
« Odpověď #686 kdy: 20. 08. 2018, 12:07:12 »
Takže se třeba v definici API ignorují záporné hodnoty indexu funkce substr, protože přece nikdo soudný nebude předávat záporný index.
Autoři PHP na to mají zjevně jiný názor - záporný parametr znamená že se bere x znaků od konce  :)
Asi měli dobrej matroš :)

Re:Typový system versus unittesty
« Odpověď #687 kdy: 20. 08. 2018, 12:19:24 »
Kdyz bude mit funkce na vstupu iterator misto kolekce tak ten implementacni detail je tak trochu vynuceny v tom API, nemyslis?
Jenže se implementace tím API zbytečně omezuje a nemusí být optimální.
Podle me to prave pruznejsi. A optimalizaci prochazeni kolekce to nepotrebuje. Tu zajisti ten iterator.

Mam pocit, ze tohle uz taky neni tak uplne o unit testech, teda pokud nemam takovy test napsany na (skoro) kazdou funkci v cele aplikaci. Neco podobneho resil kolega tusim pomoci AOP a myslim, ze slo spis o performance testy nez o unit testy.
Je to pořád jednotkový test, nebo možná funkční test. Neřeší se výkon, ale to, že ta aplikace je za určité situace nepoužitelná nebo padá na chybu.
Unit test by podle me mel byt platfomne nezavisli.
Ale i tak:
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.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Typový system versus unittesty
« Odpověď #688 kdy: 20. 08. 2018, 13:22:32 »
A když se to spojí, tak máme ten hypotetický jazyk, který by dokázal nahradit testy v případech užití, které byly uváděny.
Uváděn byl příklad dvou funkcí pro sumaci. Nějak ho stále přehlížíte.

Obávám se, že to není nijak podstatné.

Byly časy, kdy API funkce (říkejme tomu spíše signatura) vypadala nějak takto:

function substr(String str, Int start, Int len) : String

A v praxi jsme pak museli ošetřit testem, co se stane, když zavoláme substr("abc", 6, -2). Někde uvnitř té funkce bylo definováno, že to má vyhodit výjimku, prázdný řetězec, nebo něco takového. Podstatné ale je, že signatura funkce o této nesmyslnosti nic nevěděla.

Dnes už máme typy na takové úrovni, že dokážeme zohlednit, že substr("abc", 6, -2) nepůjde vůbec přeložit. A myslím, že nikoho nijak zvlášť nezajímá, že kdysi dávno se tvrdilo, že ošetření těchto nesmyslných vstupů je otázka implementace, a nikoliv API/Signatury.

Takže pokud trváš na tom, že API/Signatura a implemnetace/chování jsou dva oddělené světy, tak já ti tvůj názor přeji, ale v takovém případě nám nejde o stejnou věc.
Ale já nepíšu o signatuře, píšu o API. A součástí API té funkce substr je, že někde v dokumentaci, např. v manuálové stránce, je napsáno, co ta funkce má dělat, a v lepším případě i jaké jsou možné parametry a co to bude dělat, pokud budou parametry mimo rozsah. V horším případě tam zejména ty chybové stavy moc dobře popsané nebudou , a pak nastává ten případ, o kterém jsem také psal, že se mohou lišit názory na to, jaké je vlastně přesné API té funkce.
To ze se nekdo rozhodl, ze nebude formalizovat veskere pozadavky na funkci, a ze neco jen popise v dokumentaci, neni proto, ze by to neslo, ale proto ze se mu nechtelo.
BoneFluteovi se chce.

Chci se posunout, a mět jazyky a stroj, který udělá maximum nudné práce.

Ž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ší. Když to jde, tak to použiju. Když to výhodnější nebude, tak to nepoužiju. Ale to neznamená že to nejde.

gll

  • ****
  • 429
    • Zobrazit profil
    • E-mail
Re:Typový system versus unittesty
« Odpověď #689 kdy: 20. 08. 2018, 13:37:00 »
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í.