Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: BoneFlute 17. 06. 2018, 23:39:32

Název: Typový system versus unittesty
Přispěvatel: BoneFlute 17. 06. 2018, 23:39:32
Zdravím.

Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém.

(Teď samozřejmě neřeším který jazyk a zda něco takového má.)

Zajímalo by mě, můžete zkusit uvést nějaký příklad konstrukce, na kterou je nutné napsat test, protože typem to podchytit nejde?

Díky.
Název: Re:Typový system versus unittesty
Přispěvatel: Honza 18. 06. 2018, 00:16:53
Kéž by toto vlákno skončilo konstatováním, že typový systém nemůže nahradit unit testy...
Název: Re:Typový system versus unittesty
Přispěvatel: Franta <xkucf03/> 18. 06. 2018, 00:32:01
To je hodně nezdravé přesvědčení :-D Je pravda, že jednotkové testy se často přeceňují, ale tak daleko bych nešel. Spíš bych to formuloval:

jednotkové testy nejsou tolik potřeba máte-li kvalitní typový systém

Metody/funkce ale nemají jen rozhraní (vstup-výstup, definiční obor, obor hodnot), ale (a to hlavně) nějakou logiku uvnitř, nějaký algoritmus. A ten potřebuješ otestovat. Neznám typový systém, který by dokázal deklarativně popsat i tu logiku uvnitř a nahradit testy.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 18. 06. 2018, 01:25:19
Ono záleží na tom, jak jsou ty typy definované. Jeden ze způsobů (v Haskellu hodně využívaný) JSON serializace (aeson) jsou instance FromJSON a ToJSON. Mělo by platit
Kód: [Vybrat]
fromJSON . toJSON = Just
Což jinak než jednotkovými testy zkontrolovat nejde (kontroluje se to typicky přes QuickCheck property). Na druhou stranu je pravda, že lze ten typ serializace vyrobit tak, že se popíše způsob té serializace a ta možnost, že by bylo možné vyrobit vzájemně nekompatibilní FromJSON/ToJSON prostě nebude. I tak je ale typicky potřeba nějak otestovat, že alespoň ta knihovna je korektní.

Jednotkové testy prostě typicky píšu pro parsery. Ono se dost blbě typově popisuje, co má ten parser dělat. Pak třeba pro různé výpočty - jestli to počítá fakt správně. Pak třeba pro nějaké multi-threadované problémy (messagebus), jestli to dělá to, co to má dělat.

Metody/funkce ale nemají jen rozhraní (vstup-výstup, definiční obor, obor hodnot), ale (a to hlavně) nějakou logiku uvnitř, nějaký algoritmus. A ten potřebuješ otestovat. Neznám typový systém, který by dokázal deklarativně popsat i tu logiku uvnitř a nahradit testy.
No... dependent types dokážou hodně. https://www.youtube.com/watch?v=n-b1PYbRUOY (https://www.youtube.com/watch?v=n-b1PYbRUOY) - ukázka implementace red-black tree. Ono je to v podstatě takový model checker.... Ono se v typových systémech dá popsat docela hodně, ale je to někdy takové práce, že je rychlejší napsat si ty unit testy (nebo ještě líp quickcheck property testy)
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 01:30:39
Ono záleží na tom, jak jsou ty typy definované. Jeden ze způsobů (v Haskellu hodně využívaný) JSON serializace (aeson) jsou instance FromJSON a ToJSON. Mělo by platit
Kód: [Vybrat]
fromJSON . toJSON = Just
Což jinak než jednotkovými testy zkontrolovat nejde (kontroluje se to typicky přes QuickCheck property). Na druhou stranu je pravda, že lze ten typ serializace vyrobit tak, že se popíše způsob té serializace a ta možnost, že by bylo možné vyrobit vzájemně nekompatibilní FromJSON/ToJSON prostě nebude. I tak je ale typicky potřeba nějak otestovat, že alespoň ta knihovna je korektní.

Jednotkové testy prostě typicky píšu pro parsery. Ono se dost blbě typově popisuje, co má ten parser dělat. Pak třeba pro různé výpočty - jestli to počítá fakt správně. Pak třeba pro nějaké multi-threadované problémy (messagebus), jestli to dělá to, co to má dělat.
Tento příklad mi zrovna přijde celkem na pohodu. Nadefinuju si jednotlivé elementy jsonu, serialize to string. Že to dává smysl zkouknu okem, a pak zafixuju ala Elm.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 01:37:12
jednotkové testy nejsou tolik potřeba máte-li kvalitní typový systém

Prosím, toto není námětem mé otázky.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 18. 06. 2018, 01:40:27
jednotkové testy nejsou potřeba máte-li kvalitní typový systém.
Jednotkové testy a typový systém řeší ortogonální problémy. Je ale pravda, že závislostní typy jsou nesmírně mocný nástroj a odchytí neuvěřitelné množství chyb. I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 01:51:37
I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).
Proč?
Název: Re:Typový system versus unittesty
Přispěvatel: tdvorak 18. 06. 2018, 06:38:21
I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).
Proč?
Jak typy zajistis, ze tvoje metoda sum(a,b) vraci pro int a a int b spravny int soucet? Jako alternativu k primitivnimu assertEquals(3, sum(1,2)) ?
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 18. 06. 2018, 07:18:00
Kéž by toto vlákno skončilo konstatováním, že typový systém nemůže nahradit unit testy...
...a naopak.
Název: Re:Typový system versus unittesty
Přispěvatel: uuuuuuuu 18. 06. 2018, 07:22:03
Kéž by toto vlákno skončilo konstatováním, že typový systém nemůže nahradit unit testy...
...a naopak.


A naopak:  kez by to vlakno zacalo konstatovanim.....
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 18. 06. 2018, 09:12:49
Kéž by toto vlákno skončilo konstatováním, že typový systém nemůže nahradit unit testy...
...a naopak.

Prosil bych ukázku použití typového systému, ve které není možné provést náhradu jednotkovými testy.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 09:38:55
Prosil bych ukázku použití typového systému, ve které není možné provést náhradu jednotkovými testy.
Jedna věc je, zda je to teoreticky možné, druhá věc je, zda opravdu ručně psanými jednotkovými testy pokryjete všechny možnosti.

A snad ještě podstatnější je to, že typový systém používá programátor přímo při psaní (jako dokumentaci) – což je úplně něco jiného, než když bude zkoušet náhodně psát kód a zkoušet, jestli to projde jednotkovými testy.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 18. 06. 2018, 10:16:31
Zdravím.

Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém.

(Teď samozřejmě neřeším který jazyk a zda něco takového má.)

Zajímalo by mě, můžete zkusit uvést nějaký příklad konstrukce, na kterou je nutné napsat test, protože typem to podchytit nejde?

Díky.

Je to kacir. Upalte ho!

A ted vazne. Budeme povazovat napriklad clojure.spec za soucast typoveho systemu, nebo nastroj pro testovani?
A co generativni property based testing (napr. QuickCheck)? Je definice vlastnosti funkce typova zalezitost nebo testovaci?

Btw. diky za to otazku. Samotneho by me ani nenapadlo o tom premyslet a ted mam pocit ze jsem dosahl dilciho osviceni.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 18. 06. 2018, 10:23:01
Citace
Tento příklad mi zrovna přijde celkem na pohodu. Nadefinuju si jednotlivé elementy jsonu, serialize to string. Že to dává smysl zkouknu okem, a pak zafixuju ala Elm.
Tomu asi nerozumím - je poměrně jednoduché vytvořit ToJSON a FromJSON tak, aby to navzájem kompatibilní nebylo. Tak, jak jsou ty typeclassy oddělené, nejde typově zajistit, že to kompatibilní je. Je možné vyrobit ty typy jinak. Nicméně parsing obecně typově kontrolovat nejde - ten soulad se specifikací prostě do typu té funkce
Kód: [Vybrat]
Text -> ParsedValue nenakóduju.

Jak typy zajistis, ze tvoje metoda sum(a,b) vraci pro int a a int b spravny int soucet? Jako alternativu k primitivnimu assertEquals(3, sum(1,2)) ?
No já bych řekl, že to pude ;) (nejsem teda vůbec expert na dependent types), ale Nat (natural number) jako typ existuje, udělat součet v peanově algebře (fakt nevim o čem mluvim) jde taky a dopsat k tomu ty důkazy do těl funkcí je poměrně primitivní záležitost. Ale pravda, je to trošku cvičení o ničem...

Citace
A co generativni property based testing (napr. QuickCheck)? Je definice vlastnosti funkce typova zalezitost nebo testovaci?
IMO testovací.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 18. 06. 2018, 11:14:19
Prosil bych ukázku použití typového systému, ve které není možné provést náhradu jednotkovými testy.
Jedna věc je, zda je to teoreticky možné, druhá věc je, zda opravdu ručně psanými jednotkovými testy pokryjete všechny možnosti.

A snad ještě podstatnější je to, že typový systém používá programátor přímo při psaní (jako dokumentaci) – což je úplně něco jiného, než když bude zkoušet náhodně psát kód a zkoušet, jestli to projde jednotkovými testy.

Ručně psanými testy (resp. generovanými) podchytím nejen typovost, což obslouží jeden test, ale i spoustu dalších možností, například reakce na nevalidní vstupy.

Jednotkové testy jsou součástí dokumentace. Jsou zárukou, že jednotka funguje jak má. Tohle typy nedokáží.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 11:28:45
Jednotkové testy jsou součástí dokumentace. Jsou zárukou, že jednotka funguje jak má. Tohle typy nedokáží.

Naopak: http://elm-lang.org - elm-package diff elm-lang/core 3.0.0 4.0.0
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 11:30:44
Prosil bych ukázku použití typového systému, ve které není možné provést náhradu jednotkovými testy.

Jak to souvisí s mojí otázkou?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 11:38:20
Ručně psanými testy (resp. generovanými) podchytím nejen typovost, což obslouží jeden test, ale i spoustu dalších možností, například reakce na nevalidní vstupy.

Jednotkové testy jsou součástí dokumentace. Jsou zárukou, že jednotka funguje jak má. Tohle typy nedokáží.
S tím, že jsou testy součástí dokumentace, nesouhlasím. Ano, typy nedokáží to, co dokáží testy – to navrhoval jen BoneFlute a myslím, že už to bylo vyvráceno.

Já bych pod klasickou testovací pyramidu přidal další vrstvu – typový systém. Platí pro to pak stále to, co pro samotnou pyramidu – to, co je vespod, je nejjednodušší, je toho tudíž nejvíc a nejrychleji to odhalí chybu. Takže co jde, pokryje se typovým systémem, když to nejde pokrýt typy, napíšou se na to jednotkové testy, když to nejde řešit jednotkovými testy, napíšou se funkční testy atd.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 11:51:27
Ano, typy nedokáží to, co dokáží testy – to navrhoval jen BoneFlute a myslím, že už to bylo vyvráceno.

Kde?

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 18. 06. 2018, 12:03:41
Ano, typy nedokáží to, co dokáží testy – to navrhoval jen BoneFlute a myslím, že už to bylo vyvráceno.

Kde?

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.

Tak ono jaksi uz v principu typy resi (ne nutne dost zevrubnou) kontrolu pro vsechny mozne hodnoty, zatimco testy jenom pro nejake konkretni (at uz zadane nebo v pripade property based testu generovane) hodnoty.

Tohle samozrejme neni realny produkcni kod, ale jenom vydestilovany jeden z moznych problemu (misto toho random si predstav trebas neco, co zavisi na stavu konkretniho stroje, na kterem to bezi, neco, co zavisi na case atp.):

Kód: [Vybrat]
foo(i):
   if (Random.double(0, 1) > 0.0000001:
      return i + 1
   else
      return "Life suckz!"

print(1 + foo(1))

V testovani na to nejspis neprijdes, typova kontrola to da na prvni dobrou...
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 12:14:51
Kde?

Hned v komentáři #6 (https://forum.root.cz/index.php?topic=18804.msg270115#msg270115).

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.
Nesmetl jsem to ze stolu, jenom mi připadá zbytečné opakovat, co už bylo řečeno a je triviální.

Název: Re:Typový system versus unittesty
Přispěvatel: Kit 18. 06. 2018, 12:17:20
Kód: [Vybrat]
foo(i):
   if (Random.double(0, 1) > 0.0000001:
      return i + 1
   else
      return "Life suckz!"

print(1 + foo(1))

V testovani na to nejspis neprijdes, typova kontrola to da na prvni dobrou...

Když tam místo "Life suckz!" dáš třeba 0, což bývá častý případ, tak to typová kontrola také nedá.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 12:18:31
Ano, typy nedokáží to, co dokáží testy – to navrhoval jen BoneFlute a myslím, že už to bylo vyvráceno.

Kde?

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.

Tak ono jaksi uz v principu typy resi (ne nutne dost zevrubnou) kontrolu pro vsechny mozne hodnoty, zatimco testy jenom pro nejake konkretni (at uz zadane nebo v pripade property based testu generovane) hodnoty.

Tohle samozrejme neni realny produkcni kod, ale jenom vydestilovany jeden z moznych problemu (misto toho random si predstav trebas neco, co zavisi na stavu konkretniho stroje, na kterem to bezi, neco, co zavisi na case atp.):

Kód: [Vybrat]
foo(i):
   if (Random.double(0, 1) > 0.0000001:
      return i + 1
   else
      return "Life suckz!"

print(1 + foo(1))

V testovani na to nejspis neprijdes, typova kontrola to da na prvni dobrou...

Ah, tak teď jsem si naběhl. Jsem tu větu pochopil přesně naopak, že Filip Jirsák tvrdí, že bylo vyvráceno, že by typová kontrola nedokázala plně nahradit testy.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 12:20:16
Kód: [Vybrat]
foo(i):
   if (Random.double(0, 1) > 0.0000001:
      return i + 1
   else
      return "Life suckz!"

print(1 + foo(1))

V testovani na to nejspis neprijdes, typova kontrola to da na prvni dobrou...

Když tam místo "Life suckz!" dáš třeba 0, což bývá častý případ, tak to typová kontrola také nedá.
To by nebyl problém. Typy by vyžadovali nějakou monádu, nebo effect, a podle toho pokračovali s tím, zda se to počítá dobře.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 12:24:44
Kde?

Hned v komentáři #6 (https://forum.root.cz/index.php?topic=18804.msg270115#msg270115).
To těžko. Je tam tvrzení, ne vysvětlení. Viz následující komentáře.

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.
Nesmetl jsem to ze stolu, jenom mi připadá zbytečné opakovat, co už bylo řečeno a je triviální.
Ano, neboli žádné argumenty, jen tvrzení, a smetení ze stolu.

Když by to bylo triviální, tak předvedeš nějaký pěkný kód. Chci snad tak moc?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 12:25:54
Ah, tak teď jsem si naběhl. Jsem tu větu pochopil přesně naopak, že Filip Jirsák tvrdí, že bylo vyvráceno, že by typová kontrola nedokázala plně nahradit testy.
Pro pořádek, tvrdím, že typová kontrola nedokáže plně nahradit jednotkové testy (např. nedokáže zkontrolovat algoritmy). Dále jsem reagoval na Kita, že jednotkové testy sice teoreticky mohou nahradit typovou kontrolu (a dělá se to tak u jazyků bez typů), ale prakticky to nikdy nebude úplná kontrola, protože psát jednotkové testy je podstatně náročnější, než používat typy.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 12:31:05
Citace
Tento příklad mi zrovna přijde celkem na pohodu. Nadefinuju si jednotlivé elementy jsonu, serialize to string. Že to dává smysl zkouknu okem, a pak zafixuju ala Elm.
Tomu asi nerozumím - je poměrně jednoduché vytvořit ToJSON a FromJSON tak, aby to navzájem kompatibilní nebylo. Tak, jak jsou ty typeclassy oddělené, nejde typově zajistit, že to kompatibilní je. Je možné vyrobit ty typy jinak. Nicméně parsing obecně typově kontrolovat nejde - ten soulad se specifikací prostě do typu té funkce
Kód: [Vybrat]
Text -> ParsedValue nenakóduju.

Rozumím.

Kód: [Vybrat]
(toJSON json) -> str == (fromJSON str) -> json by nešlo? Kompiler by musel ověřit, zda všechny varianty stromu, když se vygenerují do stringu a pak následně naparsují jsou shodné.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 12:32:09
To těžko. Je tam tvrzení, ne vysvětlení. Viz následující komentáře.
Následující komentář je váš dotaz na vysvětlení a hned následující komentář je vysvětlení.

Když by to bylo triviální, tak předvedeš nějaký pěkný kód. Chci snad tak moc?
Vždyť ten kód byl v komentáři odpovídajícím na vaše „Proč?“ Já bych tu funkci akorát jinak nazval, jinak je kód stejný, protože to je první, co každého napadne:

Kód: [Vybrat]
//sečte dvě čísla
int add(int x, int y) {
  return x - y;
}
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 12:42:21
To těžko. Je tam tvrzení, ne vysvětlení. Viz následující komentáře.
Následující komentář je váš dotaz na vysvětlení a hned následující komentář je vysvětlení.

Když by to bylo triviální, tak předvedeš nějaký pěkný kód. Chci snad tak moc?
Vždyť ten kód byl v komentáři odpovídajícím na vaše „Proč?“ Já bych tu funkci akorát jinak nazval, jinak je kód stejný, protože to je první, co každého napadne:

Kód: [Vybrat]
//sečte dvě čísla
int add(int x, int y) {
  return x - y;
}

A následně bylo poukázáno, že toto by šlo: https://forum.root.cz/index.php?topic=18804.msg270160#msg270160

Prosím něco lepšího :-)
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 18. 06. 2018, 12:43:20
I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).
Proč?
Protože třeba funkce vracející k n n-té prvočíslo. Prostě logika se typovým systémem v obecnosti otestovat nedá. Se závislostním typovým systémem jde ale podchytit mnoho věcí již během překladu, což je jeho největší výhoda. Čistě teoreticky kontrolu za běhu nelze zcela vyloučit, protože halting problem. Nicméně některé jazyky zaručují i totalitu funkcí.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 12:46:02
I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).
Proč?
Protože třeba funkce vracející k n n-té prvočíslo. Prostě logika se typovým systémem v obecnosti otestovat nedá. Se závislostním typovým systémem jde ale podchytit mnoho věcí již během překladu, což je jeho největší výhoda. Čistě teoreticky kontrolu za běhu nelze zcela vyloučit, protože halting problem. Nicméně některé jazyky zaručují i totalitu funkcí.

Rozumím. Prvočísla sou svině.

Ale pokud to chápu dobře, tak zde je problém v tom, že prvočísla se nedají ani otestovat. U typů zase narazím na to, že typ se snaží být ultimátní. Takže bych se přimlouval za plichtu :-) V tomto případě.
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 18. 06. 2018, 12:58:27
Kód: [Vybrat]
foo(i):
   if (Random.double(0, 1) > 0.0000001:
      return i + 1
   else
      return "Life suckz!"

print(1 + foo(1))

V testovani na to nejspis neprijdes, typova kontrola to da na prvni dobrou...

Když tam místo "Life suckz!" dáš třeba 0, což bývá častý případ, tak to typová kontrola také nedá.

On taky nikdo nerika, ze typova kontrola da vsechno....
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 18. 06. 2018, 12:59:15
Statický typový systém nemá s testováním nic společného. Historicky vznikl kvůli tomu, aby kompilátor mohl generovat rychlý kompaktní kód. Na návrh programu má poněkud komplikační dopad - návrh musí být podřízen statickému typování, ale bez něj by byl jednodušší.

Unit testy píšu kvůli testování funkčnosti, ne kvůli ověřování typů. Pokud budu mít kupř. za úkol napsat nějaký grafový algoritmus, tak unit testem zkouším, zda funguje tak jak má, a ne jestli tam jdou "správné" typy. Statická typová kontrola, jak se zdá, v někom vzbuzuje falešný pocit, že je to nějaký test navíc. Ale to není! Statická typová kontrola mi hází při kompilaci chyby, které tam jsou, jen protože se vyžaduje statická typovost. Je to tak trochu začarovaný kruh. Na jednu stranu mě sice zarazí, pokud omylem použiju nějakou proměnnou na něco jiného (samozřejmě tedy jen pokud to má náhodou i jiný typ), ale na druhou stranu mi zase komplikuje práci, když by ta jedna proměnná klidně mohla obsahovat různorodá data.

Nechci hodnotit, co je lepší nebo horší, obojí má podle mě své místo a opodstatnění. Ale statické typování rozhodně žádné unit testování nenahrazuje.
(osobně mi statické typování překáží tím více, na čím vyšší úrovni abstrakce se pohybuji; na low-level záležitosti mi připadá jako naprosto perfektní)
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 18. 06. 2018, 13:00:16
I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).
Proč?
Protože třeba funkce vracející k n n-té prvočíslo. Prostě logika se typovým systémem v obecnosti otestovat nedá. Se závislostním typovým systémem jde ale podchytit mnoho věcí již během překladu, což je jeho největší výhoda. Čistě teoreticky kontrolu za běhu nelze zcela vyloučit, protože halting problem. Nicméně některé jazyky zaručují i totalitu funkcí.
Rozumím. Prvočísla sou svině.

Ale pokud to chápu dobře, tak zde je problém v tom, že prvočísla se nedají ani otestovat. U typů zase narazím na to, že typ se snaží být ultimátní. Takže bych se přimlouval za plichtu :-) V tomto případě.
Obecně platí, že typová kontrola zajistí korektnost vstupu a správný typ výstupu a že všechny funkce na sebe bezchybně navazují. Zároveň zajistí přesměrování chyb za běhu. Nemůže ovšem garantovat správnost výsledků (v některých případech ano, ale obecně ne).
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 18. 06. 2018, 13:02:32
Ale pokud to chápu dobře, tak zde je problém v tom, že prvočísla se nedají ani otestovat. U typů zase narazím na to, že typ se snaží být ultimátní. Takže bych se přimlouval za plichtu :-) V tomto případě.

Prvočíslo se dá otestovat velmi snadno.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 13:03:15
Nemůže ovšem garantovat správnost výsledků (v některých případech ano, ale obecně ne).
Dobře. Ale já se táži proč.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 13:04:39
Statický typový systém nemá s testováním nic společného. Historicky vznikl kvůli tomu, aby kompilátor mohl generovat rychlý kompaktní kód. Na návrh programu má poněkud komplikační dopad - návrh musí být podřízen statickému typování, ale bez něj by byl jednodušší.

Unit testy píšu kvůli testování funkčnosti, ne kvůli ověřování typů. Pokud budu mít kupř. za úkol napsat nějaký grafový algoritmus, tak unit testem zkouším, zda funguje tak jak má, a ne jestli tam jdou "správné" typy. Statická typová kontrola, jak se zdá, v někom vzbuzuje falešný pocit, že je to nějaký test navíc. Ale to není! Statická typová kontrola mi hází při kompilaci chyby, které tam jsou, jen protože se vyžaduje statická typovost. Je to tak trochu začarovaný kruh. Na jednu stranu mě sice zarazí, pokud omylem použiju nějakou proměnnou na něco jiného (samozřejmě tedy jen pokud to má náhodou i jiný typ), ale na druhou stranu mi zase komplikuje práci, když by ta jedna proměnná klidně mohla obsahovat různorodá data.

Nechci hodnotit, co je lepší nebo horší, obojí má podle mě své místo a opodstatnění. Ale statické typování rozhodně žádné unit testování nenahrazuje.
(osobně mi statické typování překáží tím více, na čím vyšší úrovni abstrakce se pohybáváuji; na low-level záležitosti mi připadá jako naprosto perfektní)

Obávám se, že žijem každý úplně v jiném světě.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 13:13:26
Stalo se mi, že:

Psal jsem kód, kde se řadil strom (uzel, mající n potomků). Každý prvek v seznamu potomků měl být seřazen. Psal jsem na to testy asi tejden. Vždycky všechno prošlo, dal jsem na review, a poslali mi to zpět, že za těchto a těchto okolností to padá.
Pak jsem se dožral a napsal jsem si generátor všech možností - tedy dle mého chápání něco jako statický typ. Pak to půl hodiny chroupalo, vyhodilo pět chybujících scénářů, ty jsem zohlednil a byl klid.

Psal jsem parser. Unittesty jsou samozřejmě na to jak stvořené. Všechno krásně přímočaré, supr. Pochvaloval jsem si, jak umím krásně psát testy. A pak jsem si uvědomil, že jsem idiot. Kdyžbych napsal jen specifikaci toho formátu, a napsal na to generátor, tak se s tím nemusím tak patlat.

Tak jasně, u typů se musí víc přemýšlet. Ale nerad bych odbočoval do těchto bažin.

Rád bych v tomto vláknu ještě pár ukázek nějakého kódu, kde si typy nabijou hubu. Zatím uvedl Gödel uvedl ty prvočísla. To máme jeden. Napadá vás něco dalšího?
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 18. 06. 2018, 13:15:57

Pak jsem se dožral a napsal jsem si generátor všech možností - tedy dle mého chápání něco jako statický typ.

Tak to je nejake divne chapani...
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 18. 06. 2018, 13:18:22
Celé mi to připadá jako souboj mezi funkcionálním a objektovým programováním. Zatímco funkcionální jazyky se opírají zejména o typy a dokazování správnosti, objektové jazyky se opírají zejména o testy. V tomto kontextu se nedá rozhodnout, co z nich je lepší.

Otázku bych tedy rozdělil na dvě:
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 18. 06. 2018, 13:21:49
Zatímco funkcionální jazyky se opírají zejména o typy a dokazování správnosti

Napriklad lisp nebo lambda calculus, co?

  • Myslíte si, že ve funkcionálním jazyce, ve kterém máte kvalitní typový systém, jsou potřebné jednotkové testy?
  • Myslíte si, že v objektovém jazyce, ve kterém máte jednotkové testy, je potřebný typový systém?

Ano a ano. Protoze jedno umi snadno resit problemy, ktere to druhe nezvladne nebo zvladne bolestive.
Název: Re:Typový system versus unittesty
Přispěvatel: gll 18. 06. 2018, 13:25:37
Tak ono jaksi uz v principu typy resi (ne nutne dost zevrubnou) kontrolu pro vsechny mozne hodnoty, zatimco testy jenom pro nejake konkretni (at uz zadane nebo v pripade property based testu generovane) hodnoty.

ta kontrola může být dost komplikovaná. Samotnou definici typu potom musíte testovat na nějakých konkrétních hodnotách. Napadá mě třeba typ reprezentující číslo kreditní karty. Je docela jedno, jestli je validace součástí typu nebo v samostatné funkci.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 13:27:16

Pak jsem se dožral a napsal jsem si generátor všech možností - tedy dle mého chápání něco jako statický typ.

Tak to je nejake divne chapani...
Tak samozřejmě :-) Ber to prosím s rezervou.

Já si z typů beru to, že
- jsou deklarativní (a ideálně expresivní) - deklarativní s důrazem na "popisné"
- jsou ultimátní, tedy pokrývají všechny scénáře
- počítá to stroj
- a samozřejmě nesmíme zapomenout na záruky

Dále jsem se poučil studiem nějakých věcí, že typy jsou mnohem víc, než to, co nám ukazuje Java. A snažím se zchladit své nadšení hledáním, kde to má hranice. Protože zatím všechny případy nějaké logiky, které mě napadali tak se při troše fantazie dali typy popsat.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 13:30:04
Tak ono jaksi uz v principu typy resi (ne nutne dost zevrubnou) kontrolu pro vsechny mozne hodnoty, zatimco testy jenom pro nejake konkretni (at uz zadane nebo v pripade property based testu generovane) hodnoty.

ta kontrola může být dost komplikovaná. Samotnou definici typu potom musíte testovat na nějakých konkrétních hodnotách. Napadá mě třeba typ reprezentující číslo kreditní karty. Je docela jedno, jestli je validace součástí typu nebo v samostatné funkci.

Co na té kartě chceš testovat?
Název: Re:Typový system versus unittesty
Přispěvatel: gll 18. 06. 2018, 13:31:20
Tak ono jaksi uz v principu typy resi (ne nutne dost zevrubnou) kontrolu pro vsechny mozne hodnoty, zatimco testy jenom pro nejake konkretni (at uz zadane nebo v pripade property based testu generovane) hodnoty.

ta kontrola může být dost komplikovaná. Samotnou definici typu potom musíte testovat na nějakých konkrétních hodnotách. Napadá mě třeba typ reprezentující číslo kreditní karty. Je docela jedno, jestli je validace součástí typu nebo v samostatné funkci.

Co na té kartě chceš testovat?

https://en.wikipedia.org/wiki/Luhn_algorithm
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 13:36:00
Tak ono jaksi uz v principu typy resi (ne nutne dost zevrubnou) kontrolu pro vsechny mozne hodnoty, zatimco testy jenom pro nejake konkretni (at uz zadane nebo v pripade property based testu generovane) hodnoty.

ta kontrola může být dost komplikovaná. Samotnou definici typu potom musíte testovat na nějakých konkrétních hodnotách. Napadá mě třeba typ reprezentující číslo kreditní karty. Je docela jedno, jestli je validace součástí typu nebo v samostatné funkci.

Co na té kartě chceš testovat?

https://en.wikipedia.org/wiki/Luhn_algorithm

Díky. V tomto případě mi stále ještě fantazie neselhává. Ale díky.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 13:48:39
A následně bylo poukázáno, že toto by šlo: https://forum.root.cz/index.php?topic=18804.msg270160#msg270160
Nikoli, bylo poukázáno, že by šlo něco jiného. Sčítání i odčítání dvou čísel jsou legitimní operace a záleží na použití, kdy použiju tu a kdy onu.

Ale pokud si myslíte, že je to řešitelné typovým systémem, ukažte váš kód. Ukažte, jak byste navrhl typový systém, který by u následujícího kódu odhalil chybu.

Kód: [Vybrat]
int add(int x, int y) {
  return x - y;
}

int sub(int x, int y) {
  return x - y;
}

Mně připadá, že je triviálně vidět, že ta funkce add() je špatně pojmenovaná (a případně má špatnou dokumentaci), což nevyřeší žádný typový systém. Ale budu rád, když mne vyvedete z omylu.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 13:59:19
Mně připadá, že je triviálně vidět, že ta funkce add() je špatně pojmenovaná (a případně má špatnou dokumentaci), což nevyřeší žádný typový systém. Ale budu rád, když mne vyvedete z omylu.

Ukaž mi unittest s témže.

Bavíme se (doufám) o tvrzení, že typy plně nahradí unittesty. Nic víc neřeším.
Název: Re:Typový system versus unittesty
Přispěvatel: gll 18. 06. 2018, 14:05:43
Mně připadá, že je triviálně vidět, že ta funkce add() je špatně pojmenovaná (a případně má špatnou dokumentaci), což nevyřeší žádný typový systém. Ale budu rád, když mne vyvedete z omylu.

Ukaž mi unittest s témže.

Bavíme se (doufám) o tvrzení, že typy plně nahradí unittesty. Nic víc neřeším.

Kód: [Vybrat]
def add(x: int, y: int) -> int:
    """
    >>> add(1, 1)
    2
    """
    return x - y
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 14:07:10
Bavíme se (doufám) o tvrzení, že typy plně nahradí unittesty. Nic víc neřeším.
Bavíme se o vašem tvrzení, že by unittesty byly plně nahrazeny typy.

Ukaž mi unittest s témže.
To opravdu takovou trivialitu neodkážete napsat sám? Tu chybu odhalí už takhle primitivní test, který nezkoumá žádné mezní stavy, ale prostě jen otestuje jeden jednoduchý nezajímavý případ.

Kód: [Vybrat]
int add(int x, int y) {
  return x - y
}

int sub(int x, int y) {
  return x - y
}

assert add(3, 2) == 5
assert sub(3, 2) == 1
Název: Re:Typový system versus unittesty
Přispěvatel: anonym 18. 06. 2018, 14:16:01
Jsem nečetl celé vlákno, ale jednotkové testy jsem viděl na projektu v bance a je nutné si ujasnit, o co jde. Jednotkový test je myšleno otestování metod třídy izolovaně od ostatních tříd, tedy zahrnuje intenzivní mockování.

Když píšu nějakou metodu, tak si zároveň k ní udělám jednotkový test. Pokud dělám velký projekt, který bude v budoucnu velice složitý, udělám ten jendotkový test zpravidla vždy, i pro jednoduchou metodu. Zároveň to udělat muséím, protože se na takovém projektu měří test coverage. Zároveň si jednotkový test napíšu i v menším projektu ze svobodné vůle, protože mi šetří čas pro teď a i pro budoucnost: otestuju si tam, že metoda, kterou jsem právě napsal, nebo nějaká posloupnost metod, dělá to, co chci, aby dělala - tzn. místo abych otrocky pouštěl aplikaci, přihlašoval se do ní a zkoušel nově napsanou ufnkcionalitu, testuju si to tím unit testem a zároveń vyvíjím - je to značně rychlejší. Konrétní příklad: používám v metodě nějakou knihovnu a nejsem si jistý, jak funguje - např. knihovna pro parsování vstupních parametrů z konzole - udělám si proto k tomu unit test, ve kterém si ověřím, jak se vlastně ta knihovna chová.

Když někdo tvrdí, že Unit testy nejsou potřeba, když je silný typový systém, tak si myslím, že dotyčný dělá zřejmě v nějakém Pythonu nebo Javascriptu. Já dělám v javě, která silný typový systém má, a přesto se unit testy dělají, protože jejich primární goal je zafixovat chování kódu proti překlepům (někdo prostě napíš nechtěně něco do kódu, nevšimne si toho a pak to commitne, no a produkní incient e na světě), proti nevhodným změnám (někdo v kódu neotestuje na null něco, co null být může, a unit test to může podchytit), ba či přímo proti zásadním změnám funkce kódu. Unit testem taky můžu upozornit kolegy na to, že metoda, nebo její část, se opravdu musí chovat tak, jak je to v kódu - z různých důvodů.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:17:43
Bavíme se (doufám) o tvrzení, že typy plně nahradí unittesty. Nic víc neřeším.
Bavíme se o vašem tvrzení, že by unittesty byly plně nahrazeny typy.

Ukaž mi unittest s témže.
To opravdu takovou trivialitu neodkážete napsat sám? Tu chybu odhalí už takhle primitivní test, který nezkoumá žádné mezní stavy, ale prostě jen otestuje jeden jednoduchý nezajímavý případ.

Kód: [Vybrat]
int add(int x, int y) {
  return x - y
}

int sub(int x, int y) {
  return x - y
}

assert add(3, 2) == 5
assert sub(3, 2) == 1

To není to co tvrdíš.

Sorry, tvé příspěvky nejsou vůbec inspirativní. Nebudu se tedy tebou již zabejvat.
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 18. 06. 2018, 14:22:03
Bavíme se (doufám) o tvrzení, že typy plně nahradí unittesty. Nic víc neřeším.
Bavíme se o vašem tvrzení, že by unittesty byly plně nahrazeny typy.

Ukaž mi unittest s témže.
To opravdu takovou trivialitu neodkážete napsat sám? Tu chybu odhalí už takhle primitivní test, který nezkoumá žádné mezní stavy, ale prostě jen otestuje jeden jednoduchý nezajímavý případ.

Kód: [Vybrat]
int add(int x, int y) {
  return x - y
}

int sub(int x, int y) {
  return x - y
}

assert add(3, 2) == 5
assert sub(3, 2) == 1

To není to co tvrdíš.

Sorry, tvé příspěvky nejsou vůbec inspirativní. Nebudu se tedy tebou již zabejvat.

Chces inspiraci nebo jednoduchou a celkem rozumnou odpoved?
Název: Re:Typový system versus unittesty
Přispěvatel: gll 18. 06. 2018, 14:23:55
To není to co tvrdíš.

vyvrací to co tvrdíš ty.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:26:07
Já dělám v javě, která silný typový systém má,

Tak ano, Java silný typový systém má, ale co si budem povídat, stojí za starou belu. V porovnáním s takovou Scalou, a to přitom ani ta nevyužívá všeho, co se dá typy udělat.

Jinak k příkladům, které jsi uvedl: null, změna signatury, změna chování, překlep, dokumentace chování - to všechno typy zvládnou (zvládli by).
Název: Re:Typový system versus unittesty
Přispěvatel: gll 18. 06. 2018, 14:26:49
Jirsák by musel udělat tu stejnou chybu na dvou místech nezávisle, aby ji neodhalil. Tobě stačí překlep na jednom místě ve znaménku.
Název: Re:Typový system versus unittesty
Přispěvatel: Ondrej Nemecek 18. 06. 2018, 14:27:54
Já dělám v javě, která silný typový systém má, a přesto se unit testy dělají, protože jejich primární goal je zafixovat chování kódu (...)

Akorát nevím jestli je v původním dotazu míněn typový systém javy - hádám že jsou míněny mnohem silnější typové systémy, které toho garantují mnohem víc. Možná by mohl BoneFlute upřesnit?

Jinak taky záleží, jak kdo unit testy používá, někdo testuje skutečně izolovanou funkčnost, někdo to spíš používá jako integrační testy (testuje spolupráci více jednotek a třeba ani tolik nemockuje).
Název: Re:Typový system versus unittesty
Přispěvatel: andy 18. 06. 2018, 14:30:58
Kód: [Vybrat]
(toJSON json) -> str == (fromJSON str) -> json by nešlo? Kompiler by musel ověřit, zda všechny varianty stromu, když se vygenerují do stringu a pak následně naparsují jsou shodné.
No, obvávám se, že to je ale obecně vzato nerozhodnutelný problém... (i.e. halting problem). tímpádem to řešit typy  nejde. Těch "všech variant stromu" může být nekonečno, takže to nejde ani po jednom projít.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 18. 06. 2018, 14:32:24
Celé mi to připadá jako souboj mezi funkcionálním a objektovým programováním. Zatímco funkcionální jazyky se opírají zejména o typy a dokazování správnosti, objektové jazyky se opírají zejména o testy. V tomto kontextu se nedá rozhodnout, co z nich je lepší.

Otázku bych tedy rozdělil na dvě:
  • Myslíte si, že ve funkcionálním jazyce, ve kterém máte kvalitní typový systém, jsou potřebné jednotkové testy?
  • Myslíte si, že v objektovém jazyce, ve kterém máte jednotkové testy, je potřebný typový systém?
Je to ortogonální, i v λ-kalkulu se striktní typovou kontrolou (takovému formalismu se ostatně říká “jednoduchá teorie typů”) se hodí testy.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:32:58
Mně připadá, že je triviálně vidět, že ta funkce add() je špatně pojmenovaná (a případně má špatnou dokumentaci), což nevyřeší žádný typový systém. Ale budu rád, když mne vyvedete z omylu.

Ukaž mi unittest s témže.

Bavíme se (doufám) o tvrzení, že typy plně nahradí unittesty. Nic víc neřeším.

Kód: [Vybrat]
def add(x: int, y: int) -> int:
    """
    >>> add(1, 1)
    2
    """
    return x - y
Stejně tak může být:
Kód: [Vybrat]
def add(x: int, y: int) -> int:
    """
    >>> add(1, 1)
    3
    """
    return x + y

Každopádně toto by měli řešit závislostní typy. Já jsem si to přeložil jako:
Kód: [Vybrat]
add x y == y * succ x
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 18. 06. 2018, 14:33:46
Kód: [Vybrat]
(toJSON json) -> str == (fromJSON str) -> json by nešlo? Kompiler by musel ověřit, zda všechny varianty stromu, když se vygenerují do stringu a pak následně naparsují jsou shodné.
No, obvávám se, že to je ale obecně vzato nerozhodnutelný problém... (i.e. halting problem). tímpádem to řešit typy  nejde. Těch "všech variant stromu" může být nekonečno, takže to nejde ani po jednom projít.

S timhle opatrne...
Halting problem je, kdyz ti nekdo (nepritel...) prinese program a ty mas rozhodovat o nem. Ty jsi v situaci, kdy sam pises program a typovy system ti na nej klade nejake omezeni. Takze ten zkoumany program neni libovolny, ale vznikly nejakym zpusobem (trebas tak, ze spolu s nim vznika "dukaz" jeho korektnosti).
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:34:42
Chces inspiraci nebo jednoduchou a celkem rozumnou odpoved?
Tak ideálně to druhé. Ale spokojím se i s tím prvním.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:36:42
Jirsák by musel udělat tu stejnou chybu na dvou místech nezávisle, aby ji neodhalil. Tobě stačí překlep na jednom místě ve znaménku.

Křížová kontrola, tomu rozumím. Mám výhrady, ale beru :-) Takže to máme dva.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 18. 06. 2018, 14:38:28
Kód: [Vybrat]
(toJSON json) -> str == (fromJSON str) -> json by nešlo? Kompiler by musel ověřit, zda všechny varianty stromu, když se vygenerují do stringu a pak následně naparsují jsou shodné.
No, obvávám se, že to je ale obecně vzato nerozhodnutelný problém... (i.e. halting problem). tímpádem to řešit typy  nejde. Těch "všech variant stromu" může být nekonečno, takže to nejde ani po jednom projít.
S timhle opatrne...
Halting problem je, kdyz ti nekdo (nepritel...) prinese program a ty mas rozhodovat o nem. Ty jsi v situaci, kdy sam pises program a typovy system ti na nej klade nejake omezeni. Takze ten zkoumany program neni libovolny, ale vznikly nejakym zpusobem (trebas tak, ze spolu s nim vznika "dukaz" jeho korektnosti).
Já to tak myslel - ty typeclassy jsou interface, nepřítel přinese program a kompilere rozhodni, zda to platí. No a protože možných vstupů je nekonečno, tak to nejde projít, tak by připadalo v úvahu nějaké rozhodnutí na jiné úrovni - ale to je halting problém. Takže s takto definovanými typy (FromJSON, ToJSON) nejde typově ošetřit, že ty instance jsou navzájem kompatibilní. (s jinak definovanými instancemi by to samozřejmě jít mohlo)
Název: Re:Typový system versus unittesty
Přispěvatel: gll 18. 06. 2018, 14:38:45
Stejně tak může být:
Kód: [Vybrat]
def add(x: int, y: int) -> int:
    """
    >>> add(1, 1)
    3
    """
    return x + y

Každopádně toto by měli řešit závislostní typy. Já jsem si to přeložil jako:
Kód: [Vybrat]
add x y == y * succ x

když udělám chybu v testu, tak test neprojde a chybu odhalím. Je nepravděpodobné, že bude stejná chyba v testu i v kódu.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 14:38:53
To není to co tvrdíš.
Jak to, že ne? Je to chyba v kódu, jednotkový test tu chybu odhalí, žádný použitelný typový systém jí nezabrání ani neodhalí. Je to tedy vyvrácení vašeho tvrzení, že by bylo možné všechny jednotkové testy nahradit typovým systémem.

Sorry, tvé příspěvky nejsou vůbec inspirativní. Nebudu se tedy tebou již zabejvat.
Ona vůbec inspirativní není vaše otázka, protože je triviální přijít na to, že existují algoritmy, které jsou platné a legitimní, a které je možné zaměnit za jiné platné a legitimní algoritmy. To typový systém nemůže zachytit, protože musí povolit oba dva algoritmy, ale nedokáže rozlišit, že jste chtěl použít jiný algoritmus. Sčítání a odčítání jsou ty nejjednodušší případy (někdy potřebujete sčítat, někdy odčítat, a žádný typový systém nezajistí, abyste nemohl použít odčítání tam, kde správně má být sčítání).

Spíš to vypadá, že jste z toho zmatený a není vám moc jasné, co zajišťuje typový systém a k čemu slouží jednotkové testy.

Tak snad pro vás bude inspirativní alespoň to, že největší slabinou jednotkových testů je to, že testují jenom případy, u kterých autor testů předpokládá, že by u nich mohl nastat problém. A dále to, že jedna z nejpodstatnějších dovedností programátora je právě schopnost odhalit ty problematické situace.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 18. 06. 2018, 14:39:19
Dále jsem se poučil studiem nějakých věcí, že typy jsou mnohem víc, než to, co nám ukazuje Java.
To rozhodně, v Javě je typový systém dost primitivní. Na druhou stranu čím mocnější typový systém, tím delší doba překladu, na jedné přednášce o Coqu si pochvalovali, jak jim překladač dokazuje korektnost, ale překlad trval hodiny kvůli závislostním typům.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:40:08
Akorát nevím jestli je v původním dotazu míněn typový systém javy - hádám že jsou míněny mnohem silnější typové systémy, které toho garantují mnohem víc. Možná by mohl BoneFlute upřesnit?

Úplně ten nejlepší (Agda, Idris, Eff) a ještě o kousek dál. Bavím se čistě na poli teorie. Takže to, že to bude nepraktické nevadí. Nerozhodnutelnost už samozřejmě ano. Přičemž zase ne zas tak teorie, abych třeba nemohl prohlásit, že "typový systém má omezení, že dokáže rozhodnout jen pro prvních milión prvočísel", třeba.
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 18. 06. 2018, 14:42:49
Kód: [Vybrat]
(toJSON json) -> str == (fromJSON str) -> json by nešlo? Kompiler by musel ověřit, zda všechny varianty stromu, když se vygenerují do stringu a pak následně naparsují jsou shodné.
No, obvávám se, že to je ale obecně vzato nerozhodnutelný problém... (i.e. halting problem). tímpádem to řešit typy  nejde. Těch "všech variant stromu" může být nekonečno, takže to nejde ani po jednom projít.
S timhle opatrne...
Halting problem je, kdyz ti nekdo (nepritel...) prinese program a ty mas rozhodovat o nem. Ty jsi v situaci, kdy sam pises program a typovy system ti na nej klade nejake omezeni. Takze ten zkoumany program neni libovolny, ale vznikly nejakym zpusobem (trebas tak, ze spolu s nim vznika "dukaz" jeho korektnosti).
Já to tak myslel - ty typeclassy jsou interface, nepřítel přinese program a kompilere rozhodni, zda to platí. No a protože možných vstupů je nekonečno, tak to nejde projít, tak by připadalo v úvahu nějaké rozhodnutí na jiné úrovni - ale to je halting problém. Takže s takto definovanými typy (FromJSON, ToJSON) nejde typově ošetřit, že ty instance jsou navzájem kompatibilní. (s jinak definovanými instancemi by to samozřejmě jít mohlo)

Ale u typoveho systemu nutis nepritele, aby prinesl program s dalsimi (strojove overitelnymi) castmi...
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:45:06
To není to co tvrdíš.
Jak to, že ne? Je to chyba v kódu, jednotkový test tu chybu odhalí, žádný použitelný typový systém jí nezabrání ani neodhalí. Je to tedy vyvrácení vašeho tvrzení, že by bylo možné všechny jednotkové testy nahradit typovým systémem.
elm-package odhalí

Tak snad pro vás bude inspirativní alespoň to, že největší slabinou jednotkových testů je to, že testují jenom případy, u kterých autor testů předpokládá, že by u nich mohl nastat problém. A dále to, že jedna z nejpodstatnějších dovedností programátora je právě schopnost odhalit ty problematické situace.
Je mi líto, to moc dobře vím. Je to jeden z důvodů proč typy mám rád.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:47:27
Dále jsem se poučil studiem nějakých věcí, že typy jsou mnohem víc, než to, co nám ukazuje Java.
To rozhodně, v Javě je typový systém dost primitivní. Na druhou stranu čím mocnější typový systém, tím delší doba překladu, na jedné přednášce o Coqu si pochvalovali, jak jim překladač dokazuje korektnost, ale překlad trval hodiny kvůli závislostním typům.
Jsem si toho vědom. Na druhou stranu se to dá (snad) obejít. Třeba tím (naivně), že při dev procesu ty typy mám vypnuté, a teprve při releasu tomu dám nažrat.
Název: Re:Typový system versus unittesty
Přispěvatel: PetrM 18. 06. 2018, 14:48:03
Chjo, tak jinak.

Předpokládejme, že Pepa píše program a nechce v něm mít chyby. A chce využít všechny možnosti, ale co nejjednodušším způsobem. A co nejrychlej. Takže:
- Je lepší při chybě program nepřeložit a dostat rovnou hlášku "type mismatch @ line 256", než týden procházet logy
- Je lepší, pokud má funkci
Kód: [Vybrat]
speed_t avgSpeed( distance_t distance, time_t time) { ... }
a vyběhne na něj při překladu rovnou varování, že prohodil argumenty, než když na to přijde tesťák náhodou
- A chce mít podchyceno, že se opravdu implementuje správný vzorec, takže dá i unit test, který ho upoyorní, že ten výpočet je blbě.
- A protože chce vědět, jestli větší celek programu běhá správně, hodít am i integrační testy.

Takže s čím se to dělá efektivně ohlídá datový typ (bez práce a před commitem), co se dělá ohlídá unit test.

Pokud se i "s čím to dělám" musí (v základu) hlídat unit testem, tak je něco blbě (= jazyk stojí za starou bačkoru)
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 14:49:57
Chjo, tak jinak.

Předpokládejme, že Pepa píše program a nechce v něm mít chyby. A chce využít všechny možnosti, ale co nejjednodušším způsobem. A co nejrychlej. Takže:
- Je lepší při chybě program nepřeložit a dostat rovnou hlášku "type mismatch @ line 256", než týden procházet logy
- Je lepší, pokud má funkci
Kód: [Vybrat]
speed_t avgSpeed( distance_t distance, time_t time) { ... }
a vyběhne na něj při překladu rovnou varování, že prohodil argumenty, než když na to přijde tesťák náhodou
- A chce mít podchyceno, že se opravdu implementuje správný vzorec, takže dá i unit test, který ho upoyorní, že ten výpočet je blbě.
- A protože chce vědět, jestli větší celek programu běhá správně, hodít am i integrační testy.

Takže s čím se to dělá efektivně ohlídá datový typ (bez práce a před commitem), co se dělá ohlídá unit test.

Pokud se i "s čím to dělám" musí (v základu) hlídat unit testem, tak je něco blbě (= jazyk stojí za starou bačkoru)

Integrační testy sem prosím netahat.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 18. 06. 2018, 14:50:13
Citace
Ale pokud si myslíte, že je to řešitelné typovým systémem, ukažte váš kód. Ukažte, jak byste navrhl typový systém, který by u následujícího kódu odhalil chybu.
Kód: [Vybrat]
int add(int x, int y) {
  return x - y;
}

int sub(int x, int y) {
  return x - y;
}

Psal jsem, že v tom nejsem expert...ale ta idea je něco ve stylu
Kód: [Vybrat]
(ty typy musí být nějak jinak, ale nedám to dohromady)
add :: (HNat a, HNat b, HAdd a b c) => a -> b -> c
add ... následuje přičítání jedničky, pokud první argument není 0...
Je to dost zbytečné cvičení, a tak trošku to přesměrovává problém od "spletl jsem se v pojmenování" na "spletl jsem se v typu". Ale svým způsobem to je třeba odpověď na autorovu otázku - ano, typový systém odhalí chyby v kódu, ale jak odhalí chyby v typech?

Citace
Ale u typoveho systemu nutis nepritele, aby prinesl program s dalsimi (strojove overitelnymi) castmi...
Teď nerozumím - typový systém třeba Javy umí rozhodnout Null/NonNull (někdy...) bez ohledu na to, že to vlastně v tom typovém systému "není". Ty typeclassy FromJSON/ToJSON jsou udělány tak, že kompiler kompatibilitu prostě rozhodnout nemůže. Halting problém byl v tom smyslu, že i kdyby na to kompiler šel analýzou kódu jako Java, tak tu property "fromJSON . toJson = Just" stejně nemůže (obecně) rozhodnout.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 15:00:15
Psal jsem, že v tom nejsem expert...ale ta idea je něco ve stylu
Kód: [Vybrat]
(ty typy musí být nějak jinak, ale nedám to dohromady)
add :: (HNat a, HNat b, HAdd a b c) => a -> b -> c
add ... následuje přičítání jedničky, pokud první argument není 0...
Je to dost zbytečné cvičení, a tak trošku to přesměrovává problém od "spletl jsem se v pojmenování" na "spletl jsem se v typu". Ale svým způsobem to je třeba odpověď na autorovu otázku - ano, typový systém odhalí chyby v kódu, ale jak odhalí chyby v typech?
Ano, křížová kontrola. Přiznávám unittestům bod :-)
Stejně jako se můžeš splést v typu, můžeš se splést v testu. Jenže jako v testu kontroluješ, zda to testuje co má pohledem, stejně tak můžeš u typu. Jako v testu kontroluješ změnu oproti předchozímu, stejně tak to umí elm u typů.

Takže zůstává jen ta křížová kontrola, kdy u testů to píšu dvakrát. Jenže, stejně tak může kompilátor generovat usecase, a ty ukazovat... No ale to už jsme zase trochu jinde.

Citace
Ale u typoveho systemu nutis nepritele, aby prinesl program s dalsimi (strojove overitelnymi) castmi...
Teď nerozumím - typový systém třeba Javy umí rozhodnout Null/NonNull (někdy...) bez ohledu na to, že to vlastně v tom typovém systému "není". Ty typeclassy FromJSON/ToJSON jsou udělány tak, že kompiler kompatibilitu prostě rozhodnout nemůže. Halting problém byl v tom smyslu, že i kdyby na to kompiler šel analýzou kódu jako Java, tak tu property "fromJSON . toJson = Just" stejně nemůže (obecně) rozhodnout.

Předpokládám, že kompiler:
Mám json element číslo, převést na string a zpět. Element string, detto. Element Struct obsahující číslo, na string a zpět. Dále je to rekursivní, takže to už nemusím.

Asi by se našlo něco, kde by to začalo být hodně divoké. Jenže pak je otázka, zda v takovém případě by si nevylámal zuby i unittest. Nevím.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 15:04:49
elm-package odhalí
Cože? elm-package odhalí, že jste se překlepl v operátoru? Řekl bych, že nastal čas pro to, abyste také vy ukázal svůj kód.

Je to dost zbytečné cvičení, a tak trošku to přesměrovává problém od "spletl jsem se v pojmenování" na "spletl jsem se v typu". Ale svým způsobem to je třeba odpověď na autorovu otázku - ano, typový systém odhalí chyby v kódu, ale jak odhalí chyby v typech?
Ono by to vůbec bylo schování všech možných algoritmů do typů. Typy jsou ale součástí kódu, takže tím si nijak nepomůžeme.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 15:12:51
Jenže pak je otázka, zda v takovém případě by si nevylámal zuby i unittest. Nevím.
Jednotkový test testuje jenom to, co do testu napíše programátor. A spousta jednotkových testů se píše jednoduše tak, že kontrolují, zda pro zadané vstupní hodnoty dává jednotka očekávaný výstup. Není to nic světoborného, ale praxe ukazuje, že i hloupé třídění není snadné napsat na první pokus správně, takže i testy, které z miliard možných vstupů otestují těch pět správných dokážou odhalit většinu chyb, které v praxi nastávají.
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 18. 06. 2018, 15:53:17
Chjo, tak jinak.

Předpokládejme, že Pepa píše program a nechce v něm mít chyby. A chce využít všechny možnosti, ale co nejjednodušším způsobem. A co nejrychlej. Takže:
- Je lepší při chybě program nepřeložit a dostat rovnou hlášku "type mismatch @ line 256", než týden procházet logy
- Je lepší, pokud má funkci
Kód: [Vybrat]
speed_t avgSpeed( distance_t distance, time_t time) { ... }
a vyběhne na něj při překladu rovnou varování, že prohodil argumenty, než když na to přijde tesťák náhodou
- A chce mít podchyceno, že se opravdu implementuje správný vzorec, takže dá i unit test, který ho upoyorní, že ten výpočet je blbě.
- A protože chce vědět, jestli větší celek programu běhá správně, hodít am i integrační testy.

Takže s čím se to dělá efektivně ohlídá datový typ (bez práce a před commitem), co se dělá ohlídá unit test.

Pokud se i "s čím to dělám" musí (v základu) hlídat unit testem, tak je něco blbě (= jazyk stojí za starou bačkoru)
Jestli to má být v C a jestli to jsou všechno ve skutečnosti jen doubly, tak na něj nevyběhne nic, protože všechny tři typy jsou kompatibilní. Pokud by kompilátor hlásil varování v každé takové situaci, tak by v programech rozsahem i jen málo nad rámec učebnicových příkladů vyhazoval tolik varování, že by se v nich ta relevantní ztratila, protože většina by byla planými poplachy. Další možností by bylo všude přetypovávat, což by zase vedlo k nepřehlednosti programu.
Název: Re:Typový system versus unittesty
Přispěvatel: . 18. 06. 2018, 15:53:33
A zatímco úzká skupinka akademiků si posilovala své ego a pocit nadřazenosti teoretizováním o abstraktních problémech, někdo reálný napsal reálný program, který pomohl vyřešit konkrétní problém.

Nic proti akademikům, ale pokud chybí alespoň elementární porce pokory, zbude jen prázdnota a nadutost.

/* Možná je hodnocení moc příkré, ale po přečtení vlákna si nemohu pomoct. */
Název: Re:Typový system versus unittesty
Přispěvatel: . 18. 06. 2018, 16:01:01
Jestli to má být v C a jestli to jsou všechno ve skutečnosti jen doubly, tak na něj nevyběhne nic, protože všechny tři typy jsou kompatibilní. Pokud by kompilátor hlásil varování v každé takové situaci, tak by v programech rozsahem i jen málo nad rámec učebnicových příkladů vyhazoval tolik varování, že by se v nich ta relevantní ztratila, protože většina by byla planými poplachy. Další možností by bylo všude přetypovávat, což by zase vedlo k nepřehlednosti programu.
C nepatří mezi silně typové jazyky a pokud si na to člověk zvykne, má pocit, že to přece nemůže být jinak. Ale velké množství chyb a zkušenosti z takovýchto jazyků ukazují, že při správném návrhu to s tím přetypováváním není tak žhavé a vývoj to naopak značně zrychlí.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 16:05:12
A zatímco úzká skupinka akademiků si posilovala své ego a pocit nadřazenosti teoretizováním o abstraktních problémech, někdo reálný napsal reálný program, který pomohl vyřešit konkrétní problém.

Nic proti akademikům, ale pokud chybí alespoň elementární porce pokory, zbude jen prázdnota a nadutost.

/* Možná je hodnocení moc příkré, ale po přečtení vlákna si nemohu pomoct. */
Tak já mám k papírovým akademikům dost daleko. Ale to, že jsem přičichl k statickým typům, dokonce i nedobrovolně nakouklu do teorie typů (grupy axiomy a tyhlencty vymyšlenosti) mi dost otevřelo oči. A začal jsem se i u pitomejch jazyků jako je php, java, javascript, nebo python uvažovat jinak. Snad ku prospěchu věci.

Třeba u mě se opakuje scénář: píšu v Javě, načichnu tím stylem. Po nějaké době mě to začne rozčilovat. Pak zkouším nějaký projekt a tak si řeknu, že to tentokrát zkusím v Pythonu. Nejdřív nadšení, jak jde všechno snadno a krásně, a pak když navzdory incrementálnímu vývoji už třetí den nedělám nic jiného než že spouštím aplikaci a opravuju chyby mě to začne štvát z druhé strany. Tak se vrátím zpět k Javě. Tam mě začne štvát, že žádné typy neumí, tak zkusím Scalu, Haskell...

U Haskellu to byla zatím největší spokojenost. Poněkud náročné na hlavu, ale jinak se dá. Nejvíc mě zatím vadilo, když mi totálně vyhnil cabal. Tak ale za to jazyk nemůže.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 16:29:09
elm-package odhalí
Cože? elm-package odhalí, že jste se překlepl v operátoru?
Ne. Překlep pozná už kompilátor. Že se změnila signatura oproti minule (tedy, to co dělají testy) odhalí elm-package.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 18. 06. 2018, 16:35:28
A zatímco úzká skupinka akademiků si posilovala své ego a pocit nadřazenosti teoretizováním o abstraktních problémech, někdo reálný napsal reálný program
Ti akademici jsou taky reální ;) A museli tomu tvůrci "reálného programu" vymyslet a implementovat překladač nebo interpretr, aby to svoje veledílo mohl napsat a pustit ;)
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 18. 06. 2018, 16:38:05
Tak já mám k papírovým akademikům dost daleko. Ale to, že jsem přičichl k statickým typům, dokonce i nedobrovolně nakouklu do teorie typů (grupy axiomy a tyhlencty vymyšlenosti) mi dost otevřelo oči. A začal jsem se i u pitomejch jazyků jako je php, java, javascript, nebo python uvažovat jinak.
Gratuluju. To je normální vývoj u člověka, co se chce zdokonalovat a je schopen pochopit mírně abstraktní poznatky. V IT bohužel převažují zakrnělí pologramoti...
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 18. 06. 2018, 16:39:01
U Haskellu to byla zatím největší spokojenost. Poněkud náročné na hlavu
Co tam je tak náročného?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 16:39:23
Ne. Překlep pozná už kompilátor.
Jak? Můžete to konkrétně ukázat na těch funkcích add() a sub().

Že se změnila signatura oproti minule (tedy, to co dělají testy) odhalí elm-package.
Ne, testy dělají něco jiného, svým způsobem přesný opak. Kdybyste si chtěl kód jenom vyzkoušet, nepotřebujete celou infrastrukturu kolem testů – prostě byste si to jednou zkusil, a kdyby to fungovalo, testovací kód byste smazal. Celá ta infrastruktura kolem testů a jejich pravidelné spouštění ale slouží právě k tomu, abyste odhalil chyby při změnách kódu. Takže test nemůže záviset na signatuře implementace, protože celý smysl testu je v tom, že implementace dává pro zadaný vstup očekávaný výstup bez ohledu na to, jaká je zrovna použitá implementace.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 17:05:40
U Haskellu to byla zatím největší spokojenost. Poněkud náročné na hlavu
Co tam je tak náročného?
Aktuálně se peru s existencionálními typy aka forall. Už mi to nějaký chlápek vysvětloval, ale nedostatečně jsem si to zažil, a zase zapoměl.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 17:09:46
Takže test nemůže záviset na signatuře implementace, protože celý smysl testu je v tom, že implementace dává pro zadaný vstup očekávaný výstup bez ohledu na to, jaká je zrovna použitá implementace.
Právě jsi popsal, co dělají typy. Je-li typem definováno, že výsledek funkce má být ysucc x, tak to vždycky pozná, že je implementace správně (budeme-li o odvozování kompilátorem mluvit jako o jeho implementaci).
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 17:15:41
Hrál jsem si typem Date, jen pro ukázku:
Naivní implementace, naprosto nedostatečná (a v reálu nejpoužívanější):
Kód: [Vybrat]
type Data = {year: Int, month: Int, day: Int}

O něco málo lepší:
Kód: [Vybrat]
type Data = {year: Int, month: Int 1 12, day: Int 1 31}

elm-package* zařve, protože se změnila logika

Už použitelná:
Kód: [Vybrat]
type Data = {year: Int, month: 1|3|5|7|8|10|12, day: Int 1 31}
                | {year: Int, month: 4|6|9|11, day: Int 1 30}
                | {year: Int, month: 2, day: Int 1 28}
elm-package zařve, protože se změnila logika

A mohl bych pokračovat dál a dál, zohlednit rok nula, zohledňovat přestupné roky, ...

Každopádně ta elegance se s ukecanýmy a nedostatečnými testy nedá srovnat.

Nevěřím, že by ty typy skutečně dokázali popsat všechno. Ale těch hranic se nedokážu dopátrat :-)


* elm-package ve skutečnosti samozřejmě nezařve, protože Elm neumí závislostní typy, ale jde o princip, kdy nějaký nástroj typů dokáže vykrást doménu testů.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 17:27:07
Takže test nemůže záviset na signatuře implementace, protože celý smysl testu je v tom, že implementace dává pro zadaný vstup očekávaný výstup bez ohledu na to, jaká je zrovna použitá implementace.
Právě jsi popsal, co dělají typy. Je-li typem definováno, že výsledek funkce má být ysucc x, tak to vždycky pozná, že je implementace správně (budeme-li o odvozování kompilátorem mluvit jako o jeho implementaci).
Máte v tom pěkný hokej.

Zkuste si představit, že ta funkce v liché týdny přičítá a v sudé týdny odčítá. Budete definovat typ  y-tý_následník_x_v_liché_ týdny_union_y-tý_předchůdce_v_sudé_týdny? Celou bankovní aplikaci pak navrhnete jako funkci main vracející ten správný datový typ™ a kompilátor už to nějak vyřeší?

Ano, mezi typy a algoritmy není úplně pevná hranice, do určité míry mezi nimi lze přecházet, ale ta pružnost není nekonečná. Nezapomínejte na to, že nakonec to stejně někdo musí převést do strojových instrukcí procesoru. A že většinu věcí lidé snáze vyjádří algoritmem, než aby definovali složitou hierarchii typů.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 17:31:58
Ale těch hranic se nedokážu dopátrat :-)
Tak si zkuste nadefinovat typ pro datum používané v Evropě a Severní Americe v období uplynulých pěti set let. Ne nějakou abstrakci, ale typ, který bude odpovídat tomu, co se v různých dobách a na různých územích skutečně používalo.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 18. 06. 2018, 17:51:25
Právě jsi popsal, co dělají typy. Je-li typem definováno, že výsledek funkce má být ysucc x, tak to vždycky pozná, že je implementace správně (budeme-li o odvozování kompilátorem mluvit jako o jeho implementaci).
Úžasné. Takže abych se vyhnul unittestům, tak si musím tu funkčnost naimplementovat ještě jednou, akorát bez pokročilé matematiky typu součet dvou čísel. ::)
Implementoval už jsi někdy nějakou netriviální logiku? Fakt bych chtěl vidět podobný typ pro funkci co počítá třeba daň z úroku.

Sice jsem bývalý akademik se závislostí na silném typování, ale co je moc, to je moc.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 18:19:59
Právě jsi popsal, co dělají typy. Je-li typem definováno, že výsledek funkce má být ysucc x, tak to vždycky pozná, že je implementace správně (budeme-li o odvozování kompilátorem mluvit jako o jeho implementaci).
Úžasné. Takže abych se vyhnul unittestům, tak si musím tu funkčnost naimplementovat ještě jednou, akorát bez pokročilé matematiky typu součet dvou čísel. ::)
Tak za prvé, pomocí unittestů to taky implementuju ještě jednou.
A za druhé, nikde jsem nepsal, že se to tak má dělat, nebo tak něco. Je to jen úvaha. Praktičnost toho není obsahem mé otázky.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 18:21:16
Máte v tom pěkný hokej.

Zkuste si představit, že ta funkce v liché týdny přičítá a v sudé týdny odčítá. Budete definovat typ  y-tý_následník_x_v_liché_ týdny_union_y-tý_předchůdce_v_sudé_týdny? Celou bankovní aplikaci pak navrhnete jako funkci main vracející ten správný datový typ™ a kompilátor už to nějak vyřeší?

Ano, přesně tak. Žádný problém pane hokejisto.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 18:27:11
akorát bez pokročilé matematiky typu součet dvou čísel.
To mě připomíná, ono třeba v žádném mě známém typovaném jazyku není typ Int implemenován jako ...|1|2|3|4|5|6|7|8|9|10|... ale je na to nějaká zkratka na buildin typ, a stejně tomu ten kompilátor rozumí. Takže si představuji, že stejně tak se dá udělat i ta pokročilá matematika. Netřeba se utápět v detailech.
Název: Re:Typový system versus unittesty
Přispěvatel: v 18. 06. 2018, 18:32:10
tak já bych si tipnul, že to jde (computational trinitiarism) a že bych u toho fakt nechtěl být (ale paper bych si přečet)
k tomu s algoritmama - když si představíte, že by ty funkce byly asi čisté, tj. rekurzivní (tj. bez cyklů), tak s o tom hned uvažuje jinak
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 18:41:56
computational trinitiarism
Můžeš prosím rozvést vo co de?

Jinak díky, píšu si do seznamu k nastudování :-)
Název: Re:Typový system versus unittesty
Přispěvatel: v 18. 06. 2018, 18:47:46
computational trinitiarism
Můžeš prosím rozvést vo co de?
moc ne :D
https://existentialtype.wordpress.com/2011/03/27/the-holy-trinity/
https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
https://ncatlab.org/nlab/show/computational+trinitarianism

dívám se na to tak, že chování programu se (s dostatečně schopným typovým systémem) zcela odráží v typu programu (který by byl a->b)
disclaimer: tady jsem už dost daleko od věcí o kterých bych si troufnul říct, že jim rozumím
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 18:53:22
computational trinitiarism
Můžeš prosím rozvést vo co de?
moc ne :D
https://existentialtype.wordpress.com/2011/03/27/the-holy-trinity/
https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
https://ncatlab.org/nlab/show/computational+trinitarianism
Díky moc!

dívám se na to tak, že chování programu se (s dostatečně schopným typovým systémem) zcela odráží v typu programu (který by byl a->b)
Ano, taková je moje idea :-)
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 19:00:28
Jak typy zajistis, ze tvoje metoda sum(a,b) vraci pro int a a int b spravny int soucet? Jako alternativu k primitivnimu assertEquals(3, sum(1,2)) ?
Teorie typů praví, že sum a b je pohled na množinu všech možných kombinací <a, b>. Takže stejně tak, jako víme, že po 1čce přijde dvojka (pomocí těch axiomů), tak víme že (sum 1 2) == 3. Je třeba to nějak definovat, nemusí to být triviální, ale co už.

Pamatuji si učitele, který nám pro zajímavost ukazoval, jak se vypočítá odmocnina. Byl to vzorec na několik řádek (jak moc to byla hloupost netuším, od té doby jsem se k tomu nikdy nevrátil). A v reálu se proto stejně používají tabulky. (Jak to počítají procesory, zda na to mají vzorec, nebo používají taky tabulku, to netuším.)
Název: Re:Typový system versus unittesty
Přispěvatel: uuuuuuuu 18. 06. 2018, 19:16:29
Odmocni jde skoro z hlavy.

Mam cislo (50), vydelim dvema (25), sectu s 2 a udelam prumer(13,5).
Pokracuju 50:13=asi 3, zas sectu 13+3 a udelam prumer(8).
Pokracuju 50:8=asi 6, zas prumer 6+8 a tak dal.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 19:23:17
Odmocni jde skoro z hlavy.

Mam cislo (50), vydelim dvema (25), sectu s 2 a udelam prumer(13,5).
Pokracuju 50:13=asi 3, zas sectu 13+3 a udelam prumer(8).
Pokracuju 50:8=asi 6, zas prumer 6+8 a tak dal.
Sice to nebylo pointou mého příspěvku - ale hezký :-)
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 18. 06. 2018, 19:24:03
Jestli to má být v C a jestli to jsou všechno ve skutečnosti jen doubly, tak na něj nevyběhne nic, protože všechny tři typy jsou kompatibilní. Pokud by kompilátor hlásil varování v každé takové situaci, tak by v programech rozsahem i jen málo nad rámec učebnicových příkladů vyhazoval tolik varování, že by se v nich ta relevantní ztratila, protože většina by byla planými poplachy. Další možností by bylo všude přetypovávat, což by zase vedlo k nepřehlednosti programu.
C nepatří mezi silně typové jazyky a pokud si na to člověk zvykne, má pocit, že to přece nemůže být jinak. Ale velké množství chyb a zkušenosti z takovýchto jazyků ukazují, že při správném návrhu to s tím přetypováváním není tak žhavé a vývoj to naopak značně zrychlí.
To si právě spousta lidí myslí, ale v praxi to tak optimistické zdaleka není. Na akademických příkládcích se dá každá vlastnost předvést jako naprosto elegantní, ale v praxi na reálném projektu to pak vypadá poněkud odlišně. (např. Pascal je typově silnější než C a byl to jeden z důvodů, proč lidi tolik iritoval a pro praktickou práci se sahalo raději po C, přestože na školách snad každý ve své době absolvoval pascalskou průpravu)

Třeba u mě se opakuje scénář: píšu v Javě, načichnu tím stylem. Po nějaké době mě to začne rozčilovat. Pak zkouším nějaký projekt a tak si řeknu, že to tentokrát zkusím v Pythonu. Nejdřív nadšení, jak jde všechno snadno a krásně, a pak když navzdory incrementálnímu vývoji už třetí den nedělám nic jiného než že spouštím aplikaci a opravuju chyby mě to začne štvát z druhé strany. Tak se vrátím zpět k Javě. Tam mě začne štvát, že žádné typy neumí, tak zkusím Scalu, Haskell...

U Haskellu to byla zatím největší spokojenost. Poněkud náročné na hlavu, ale jinak se dá. Nejvíc mě zatím vadilo, když mi totálně vyhnil cabal. Tak ale za to jazyk nemůže.
A o jak rozsáhlé věci asi tak šlo?

Jak typy zajistis, ze tvoje metoda sum(a,b) vraci pro int a a int b spravny int soucet? Jako alternativu k primitivnimu assertEquals(3, sum(1,2)) ?
Teorie typů praví, že sum a b je pohled na množinu všech možných kombinací <a, b>. Takže stejně tak, jako víme, že po 1čce přijde dvojka (pomocí těch axiomů), tak víme že (sum 1 2) == 3. Je třeba to nějak definovat, nemusí to být triviální, ale co už.
To mi teda smysl nedává.

Pamatuji si učitele, který nám pro zajímavost ukazoval, jak se vypočítá odmocnina. Byl to vzorec na několik řádek (jak moc to byla hloupost netuším, od té doby jsem se k tomu nikdy nevrátil). A v reálu se proto stejně používají tabulky. (Jak to počítají procesory, zda na to mají vzorec, nebo používají taky tabulku, to netuším.)
Je docela možné, že algoritmus výpočtu odmocniny by šlo nějak vměstnat do vzorce, ale ten procedurální přístup (1. rozděl číslo na skupinky po dvou, 2. najdi největší číslo, které po umocnění na druhou bude menší nebo rovno než skupinka vlevo, 3...) je poměrně názorný. Ale ta pointa mi stejně uniká.
Název: Re:Typový system versus unittesty
Přispěvatel: uuuuuuuu 18. 06. 2018, 19:28:34
Uz jsem si vpomel na nazev, to rucni odmocnovani je newtonuv vzorec.

Fi = F0 - f(x)/f'(x)
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 18. 06. 2018, 19:31:15
Uz jsem si vpomel na nazev, to rucni odmocnovani je newtonuv vzorec.

Fi = F0 - f(x)/f'(x)
Konkrétně tzv. babylonská metoda. Newtonův vzorec je iterativní metoda obecně na řešení transcendentních rovnic.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 18. 06. 2018, 20:21:06
Tak za prvé, pomocí unittestů to taky implementuju ještě jednou.
Tak to ani náhodou. Unittesty obvykle testují jenom významné případy. Automaticky porovnat dvě implementace mezi sebou není vůbec jednoduché.
Ty vybrané případy můžou být významné na základě modelovaného problému, autorova odhadu, nebo prostě proto, že to na tomhle už někdy vybouchlo. Implementovat to ještě jednou je naopak kontraproduktivní. Pokud tu referenční implementaci nedělá někdo nezávislý, tak je velká šance, že tam autor naseká dost podobné chyby.
Citace
A za druhé, nikde jsem nepsal, že se to tak má dělat, nebo tak něco. Je to jen úvaha. Praktičnost toho není obsahem mé otázky.
V našem oboru neexistuje nic, co by se nedalo hrnout přímo v hexa. Všechno od assembleru výš je o té praktičnosti. ;)

Jde mi o to, že typy a unittesty chytají s přiměřenou námahou různé druhy chyb. Třeba přehozené pořadí násobení matic nejde přes typy skoro odhalit. Leda že by sémantika výsledku byla celá zakódovaná v typech. Ale to pak přesune problém jenom o úroveň výš, protože je třeba nějak ověřit ty komplikované typy.
Název: Re:Typový system versus unittesty
Přispěvatel: v 18. 06. 2018, 20:40:37
tohle vlákno mě přimělo juknout se znovu na kousek kódu se kterým jsem si nedávno hrál, a světe div se, našel jsem tam chybu v type family, která měla zajišťovat korektnost (jeden z aspektů) programu vygenerovaného překladačem (takovým překladačem na hraní), takže taky hlasuju za nezavrhování testů :)
najdi jeden rozdíl (a uvaž, který případ je vlastně "správně"):
Kód: [Vybrat]
type family Drop (a :: [*]) (b :: [*]) :: [*] where
Drop '[] b = b
Drop (a ': a') (b ': b') = Drop a' b'
Kód: [Vybrat]
type family Drop (a :: [*]) (b :: [*]) :: [*] where
Drop '[] b = b
Drop (a ': a') (a ': b') = Drop a' b'
Název: Re:Typový system versus unittesty
Přispěvatel: stejně jsme to tušili 18. 06. 2018, 20:47:41
Kéž by toto vlákno skončilo konstatováním, že typový systém nemůže nahradit unit testy...

+1  ;D
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 21:13:11
Tak za prvé, pomocí unittestů to taky implementuju ještě jednou.
Tak to ani náhodou. Unittesty obvykle testují jenom významné případy. Automaticky porovnat dvě implementace mezi sebou není vůbec jednoduché.
Ty vybrané případy můžou být významné na základě modelovaného problému, autorova odhadu, nebo prostě proto, že to na tomhle už někdy vybouchlo. Implementovat to ještě jednou je naopak kontraproduktivní. Pokud tu referenční implementaci nedělá někdo nezávislý, tak je velká šance, že tam autor naseká dost podobné chyby.
Citace
A za druhé, nikde jsem nepsal, že se to tak má dělat, nebo tak něco. Je to jen úvaha. Praktičnost toho není obsahem mé otázky.
V našem oboru neexistuje nic, co by se nedalo hrnout přímo v hexa. Všechno od assembleru výš je o té praktičnosti. ;)

Jde mi o to, že typy a unittesty chytají s přiměřenou námahou různé druhy chyb. Třeba přehozené pořadí násobení matic nejde přes typy skoro odhalit. Leda že by sémantika výsledku byla celá zakódovaná v typech. Ale to pak přesune problém jenom o úroveň výš, protože je třeba nějak ověřit ty komplikované typy.

Nejsme ve sporu.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 06. 2018, 21:17:47
tohle vlákno mě přimělo juknout se znovu na kousek kódu se kterým jsem si nedávno hrál, a světe div se, našel jsem tam chybu v type family, která měla zajišťovat korektnost (jeden z aspektů) programu vygenerovaného překladačem (takovým překladačem na hraní), takže taky hlasuju za nezavrhování testů :)
najdi jeden rozdíl (a uvaž, který případ je vlastně "správně"):
Kód: [Vybrat]
type family Drop (a :: [*]) (b :: [*]) :: [*] where
Drop '[] b = b
Drop (a ': a') (b ': b') = Drop a' b'
Kód: [Vybrat]
type family Drop (a :: [*]) (b :: [*]) :: [*] where
Drop '[] b = b
Drop (a ': a') (a ': b') = Drop a' b'

Mám vyhrabat nějaký unittesty? :)

To je jako ten oblíbenej hejt na Lisp, že je to plné závorek. To ano, protože každá závorka v Lispu reprezentuje jednu třídu v Javě.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 06. 2018, 22:10:50
Nejsme ve sporu.
Jste. Vy jste napsal nesmysl, že v jednotkových testech něco implementujete znovu, JSH vám to správně vyvracel, že implementovat něco v jednotkovém testu znova je obvykle velmi špatně.

Mám vyhrabat nějaký unittesty? :)
Ano, myslím, že už je na čase.
Název: Re:Typový system versus unittesty
Přispěvatel: Gœdel 18. 06. 2018, 23:07:58
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 18. 06. 2018, 23:54:05
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
Šlo by to tvrzení trochu rozvést? Generika, nebo i implicitní typy bych bral, ale silné typování samo o sobě tyhle věci neimplikuje.
Název: Re:Typový system versus unittesty
Přispěvatel: Gœdel 19. 06. 2018, 00:03:29
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
Šlo by to tvrzení trochu rozvést? Generika, nebo i implicitní typy bych bral, ale silné typování samo o sobě tyhle věci neimplikuje.
“Silné” ve smyslu aspoň s HKT, prostě něco víc než Java. Generika jsou prvním stupněm. HKT umožní ještě více sdílení a závislostní typy ještě o stupeň více.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 19. 06. 2018, 09:24:59
Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém.

Jak jste k tomu dospěl?

Zajímalo by mě, můžete zkusit uvést nějaký příklad konstrukce, na kterou je nutné napsat test, protože typem to podchytit nejde?

class Sčítačka {
    Int součet(Int a, Int b) {
        <cokoliv>
    }
}

Int je třídou pro celá čísla (třeba vlastní implementace). Výsledek je nutně typu (správně instancí) Int, to je ale jediná věc, kterou vám typový systém garantuje. To ale nestačí - jak tento typ (třída) garantuje, že 1+1 rovná se opravdu 2???

Diskusi jsem nečetl - má to po výše uvedeném ještě smysl číst?
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 09:39:26
Zajímalo by mě, můžete zkusit uvést nějaký příklad konstrukce, na kterou je nutné napsat test, protože typem to podchytit nejde?

class Sčítačka {
    Int součet(Int a, Int b) {
        <cokoliv>
    }
}

Int je třídou pro celá čísla (třeba vlastní implementace). Výsledek je nutně typu (správně instancí) Int, to je ale jediná věc, kterou vám typový systém garantuje. To ale nestačí - jak tento typ (třída) garantuje, že 1+1 rovná se opravdu 2???

Diskusi jsem nečetl - má to po výše uvedeném ještě smysl číst?
třeba peanova čísla na typové úrovni, v haskellu docela banální
Kód: [Vybrat]
type family Append a b where ...
součet :: I a -> I b -> I (Append a b)
součet = ...
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 10:25:40
třeba peanova čísla na typové úrovni, v haskellu docela banální
Kód: [Vybrat]
type family Append a b where ...
součet :: I a -> I b -> I (Append a b)
součet = ...
Jak by to mělo pomoct?
Součet dvou čísel je jenom příklad nějakého (netriviálního) výpočtu. Pokud ho popíšu v typu, tak jenom přesunu potenciálně vadný kód někam jinam. Pořád nevím, jestli je dobře. Akorát jsem se přesunul z deště pod okap, protože ten typ se čte hůř než původní kód.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 10:28:58
Diskusi jsem nečetl - má to po výše uvedeném ještě smysl číst?
Záleží na tom. Ten váš příklad je v diskusi uveden několikrát, ale nepomohlo to…
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 10:35:09
třeba peanova čísla na typové úrovni, v haskellu docela banální
Kód: [Vybrat]
type family Append a b where ...
součet :: I a -> I b -> I (Append a b)
součet = ...
Jak by to mělo pomoct?
Součet dvou čísel je jenom příklad nějakého (netriviálního) výpočtu. Pokud ho popíšu v typu, tak jenom přesunu potenciálně vadný kód někam jinam. Pořád nevím, jestli je dobře. Akorát jsem se přesunul z deště pod okap, protože ten typ se čte hůř než původní kód.
ptal jste se na typ, který garantuje, že kód provádí součet a ten jsem naznačil
nic se nepřesouvá, pořád máte zvlášť program a jeho typ, že se v tom dá udělat chyba? no jistě, to jde všude
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 10:50:32
že se v tom dá udělat chyba? no jistě, to jde všude
Jenže celá diskuse začala tvrzením, že s propracovaným typovým systémem nejsou potřeba jednotkové testy – kde je skrytý předpoklad, že se při použití propracovaného typového systému chyba udělat nedá.

Nebo-li v této diskusi se vyskytují dvě skupiny diskutujících – jedním připadá samozřejmé, že je možné chybu udělat všude, zatímco druzí tomu, že je možné udělat chybu všude, nevěří.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 10:56:30
ptal jste se na typ, který garantuje, že kód provádí součet a ten jsem naznačil
nic se nepřesouvá, pořád máte zvlášť program a jeho typ, že se v tom dá udělat chyba? no jistě, to jde všude
Já se ptal v kontextu tohohle vlákna. Diskutujeme o tom, jestli se unittesty dají nahradit typovým systémem. Zeptám se jinak :

Píšu funkci, která skládá transformace. To je dost netriviální. A je tam pár věcí, které se dají jednoduše zvrtat. Třeba přehodit pořadí násobení matic. Jak dokážu typovým systémem ověřit, jestli to mám dobře? V unittestech otestuju pár jednoduchých případů a mám celkem jistotu.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 10:57:33
že se v tom dá udělat chyba? no jistě, to jde všude
Jenže celá diskuse začala tvrzením, že s propracovaným typovým systémem nejsou potřeba jednotkové testy – kde je skrytý předpoklad, že se při použití propracovaného typového systému chyba udělat nedá.
myslím, že žádný takový předpoklad tam není
má to být náhrada, dá se předpokládat, že i s některými vlastnostmi původního řešení
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 11:09:14
nejdřív bych zdůraznil svůj postoj: neargumentuju proti testům, testy jsou dobrá věc
původní dotaz se zabývá tím (moje interpretace), jestli se testy dají teoreticky nahradit typovým systémem a já si vzhledem k tomu co jsem o tématu četl, myslím, že ano, dále mě zajímají praktické limity tohoto přístupu, protože z vlastní praxe ho považuju za extrémně užitečný

ptal jste se na typ, který garantuje, že kód provádí součet a ten jsem naznačil
nic se nepřesouvá, pořád máte zvlášť program a jeho typ, že se v tom dá udělat chyba? no jistě, to jde všude
Já se ptal v kontextu tohohle vlákna. Diskutujeme o tom, jestli se unittesty dají nahradit typovým systémem.
asi nechápu
Píšu funkci, která skládá transformace. To je dost netriviální. A je tam pár věcí, které se dají jednoduše zvrtat. Třeba přehodit pořadí násobení matic. Jak dokážu typovým systémem ověřit, jestli to mám dobře? V unittestech otestuju pár jednoduchých případů a mám celkem jistotu.
napadají mě dvě možnosti, něco jako units of measure z F sharpu a pak prosté přejmenování typů, např místo (syntaxe haskellu) Float -> Float -> Float
 napsat Distance -> Time -> Speed (kde newtype Distance = Distance Float etc)
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 11:31:17
nejdřív bych zdůraznil svůj postoj: neargumentuju proti testům, testy jsou dobrá věc
Tak o čem tu diskutujeme? Vlákno začalo tvrzením
Citace
Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém.
A všechny tyhle příklady, které sem házíme, jsou věci, které se dají ozkoušet triviálním unittestem, ale v typech je to přinejlepším strašně komplikované.

Citace
asi nechápu
Argumentujeme tu proti BoneFluteově extrémním postoji. Proti rozumnému využívání typů naše argumenty samozřejmě nedávají nejmenší smysl.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 11:36:09
jeho extrémní postoj je zajímavý, rozumné použití typů je nuda (a co je dneska akademický blábol, může být zítra industry best practice)
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 11:42:18
myslím, že žádný takový předpoklad tam není
má to být náhrada, dá se předpokládat, že i s některými vlastnostmi původního řešení
Jednotkové testy se používají pro odhalení určitého typu chyb. Náhrada by musela alespoň odhalit stejný typ chyb, jinak to není náhrada.

původní dotaz se zabývá tím (moje interpretace), jestli se testy dají teoreticky nahradit typovým systémem a já si vzhledem k tomu co jsem o tématu četl, myslím, že ano, dále mě zajímají praktické limity tohoto přístupu, protože z vlastní praxe ho považuju za extrémně užitečný
A mohl byste tedy uvést konkrétní příklad? Zatím tady máme opakovaně příklad, kdy programátor omylem místo sčítání použije odčítání. Triviální jednotkový test takovou chybu odhalí. A zatím tady nebyl uveden žádný příklad typového systému, který by takové chybě zabránil. Viděli jsme jen příklady, že je možné operátor sčítání nahradit typem „výsledek součtu“, což ale neřeší ten problém, protože stejně, jako může programátor použít špatný operátor, může použít špatný typ.

Aby bylo jasno, já souhlasím s tím, že silnější typový systém znamená, že není potřeba psát některé jednotkové testy. Ale v žádném případě to neznamená, že dostatečně silný typový systém by znamenal, že nebudou potřeba žádné jednotkové testy (jak tvrdil BoneFlute), protože by vše, co se kontroluje jednotkovými testy, kontroloval typový systém.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 12:01:29
myslím, že žádný takový předpoklad tam není
má to být náhrada, dá se předpokládat, že i s některými vlastnostmi původního řešení
Jednotkové testy se používají pro odhalení určitého typu chyb. Náhrada by musela alespoň odhalit stejný typ chyb, jinak to není náhrada.
přesně tak

původní dotaz se zabývá tím (moje interpretace), jestli se testy dají teoreticky nahradit typovým systémem a já si vzhledem k tomu co jsem o tématu četl, myslím, že ano, dále mě zajímají praktické limity tohoto přístupu, protože z vlastní praxe ho považuju za extrémně užitečný
A mohl byste tedy uvést konkrétní příklad?
uvedl
Zatím tady máme opakovaně příklad, kdy programátor omylem místo sčítání použije odčítání. Triviální jednotkový test takovou chybu odhalí. A zatím tady nebyl uveden žádný příklad typového systému, který by takové chybě zabránil.
byl
Viděli jsme jen příklady, že je možné operátor sčítání nahradit typem „výsledek součtu“
myslím, že ne

Ale v žádném případě to neznamená, že dostatečně silný typový systém by znamenal, že nebudou potřeba žádné jednotkové testy (jak tvrdil BoneFlute), protože by vše, co se kontroluje jednotkovými testy, kontroloval typový systém.
no a já si myslím, že to teoreticky možné je (výše jsem k tomu dal nějaké odkazy), což neznamená, že to někdy bude i praktické
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 12:25:02
V tom případě by to asi chtělo ten příklad rozvést a ukázat, jak je zabráněné tomu, abych místo typu „n-tý následník„ použil typ „n-tý předchůdce“, nebo „n-tý následník“ s -n místo n.

Konkrétně už tu byl uveden tento slabě typový pseudokód:
Kód: [Vybrat]
int add(int a, int b) {
  return a + b;
}

int sub(int a, int b) {
  return a - b;
}

Jak by vypadal tentýž kód, který by pomocí silnějších typů zabránil tomu, aby někdo místo sčítání použil odčítání?

Podle mne je tedy nesmyslné vůbec se pokoušet nějaké takové typy vytvořit, protože to, jestli se má použít sčítání nebo odčítání, je vlastností řešené domény – tudíž musí programátor pochopit řešený problém, uvědomit si, zda použije sčítání nebo odčítání (případně něco úplně jiného), a pak použije vhodné prostředky programovacího jazyka. Tohle za programátora nevyřeší žádný typový systém, protože kompilátor neví nic o tom, zda se má např. částka přičíst nebo odečíst, když firma zaplatí fakturu.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 12:33:46
V tom případě by to asi chtělo ten příklad rozvést a ukázat, jak je zabráněné tomu, abych místo typu „n-tý následník„ použil typ „n-tý předchůdce“, nebo „n-tý následník“ s -n místo n.

Konkrétně už tu byl uveden tento slabě typový pseudokód:
Kód: [Vybrat]
int add(int a, int b) {
  return a + b;
}

int sub(int a, int b) {
  return a - b;
}

Jak by vypadal tentýž kód, který by pomocí silnějších typů zabránil tomu, aby někdo místo sčítání použil odčítání?

Podle mne je tedy nesmyslné vůbec se pokoušet nějaké takové typy vytvořit, protože to, jestli se má použít sčítání nebo odčítání, je vlastností řešené domény – tudíž musí programátor pochopit řešený problém, uvědomit si, zda použije sčítání nebo odčítání (případně něco úplně jiného), a pak použije vhodné prostředky programovacího jazyka. Tohle za programátora nevyřeší žádný typový systém, protože kompilátor neví nic o tom, zda se má např. částka přičíst nebo odečíst, když firma zaplatí fakturu.
tady je to hezky rozepsané https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/dependent-types-in-haskell
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 12:48:37
V tom případě by to asi chtělo ten příklad rozvést a ukázat, jak je zabráněné tomu, abych místo typu „n-tý následník„ použil typ „n-tý předchůdce“, nebo „n-tý následník“ s -n místo n.

Konkrétně už tu byl uveden tento slabě typový pseudokód:
Kód: [Vybrat]
int add(int a, int b) {
  return a + b;
}

int sub(int a, int b) {
  return a - b;
}

Jak by vypadal tentýž kód, který by pomocí silnějších typů zabránil tomu, aby někdo místo sčítání použil odčítání?

Podle mne je tedy nesmyslné vůbec se pokoušet nějaké takové typy vytvořit, protože to, jestli se má použít sčítání nebo odčítání, je vlastností řešené domény – tudíž musí programátor pochopit řešený problém, uvědomit si, zda použije sčítání nebo odčítání (případně něco úplně jiného), a pak použije vhodné prostředky programovacího jazyka. Tohle za programátora nevyřeší žádný typový systém, protože kompilátor neví nic o tom, zda se má např. částka přičíst nebo odečíst, když firma zaplatí fakturu.
tady je to hezky rozepsané https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/dependent-types-in-haskell
Vždyť ten odkazovaný článek je o něčem úplně jiném. "Avoiding boundary errors" a to, jestli kód odpovídá modelovanému problému jsou někde úplně jinde.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 19. 06. 2018, 12:51:54
tady je to hezky rozepsané https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/dependent-types-in-haskell

Když tu délku článku srovnám s délkou jednotkového testu, tak test jednoznačně vítězí.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 12:54:45
tady je to hezky rozepsané https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/dependent-types-in-haskell
Vždyť ten odkazovaný článek je o něčem úplně jiném. "Avoiding boundary errors" a to, jestli kód odpovídá modelovanému problému jsou někde úplně jinde.
používá to peanovu aritmetiku na typové úrovni pro vynucení vlastností operací s vektorama (ve smyslu datové struktury), např. tahle funkce je vlastně to stejné jako sčítání:
append :: Vector a n -> Vector a m -> Vector a (n :+ m)
délka výsledného vektoru je součet délek vstupních vektorů (a typový systém to opravdu na implementaci vynutí)
Název: Re:Typový system versus unittesty
Přispěvatel: SB 19. 06. 2018, 13:06:27
Zajímalo by mě, můžete zkusit uvést nějaký příklad konstrukce, na kterou je nutné napsat test, protože typem to podchytit nejde?

class Sčítačka {
    Int součet(Int a, Int b) {
        <cokoliv>
    }
}

Int je třídou pro celá čísla (třeba vlastní implementace). Výsledek je nutně typu (správně instancí) Int, to je ale jediná věc, kterou vám typový systém garantuje. To ale nestačí - jak tento typ (třída) garantuje, že 1+1 rovná se opravdu 2???

Diskusi jsem nečetl - má to po výše uvedeném ještě smysl číst?
třeba peanova čísla na typové úrovni, v haskellu docela banální
Kód: [Vybrat]
type family Append a b where ...
součet :: I a -> I b -> I (Append a b)
součet = ...

Tak jinak: Doplňuju svůj původní příspěvek:

místo <cokoliv> je "return 10"

Typově je vše správně, ale nějak nám to pro většinu vstupů nevychází, přičemž by to mělo vyjít alespoň pro ty, které budu používat.

Přeloženo: Typová kontrola by zafungovala pouze v případě, že pro každé dva sčítance a součet budete mít extra typy, což je ale v rozporu s jednoduchými, obecnými kategoriemi (zde celá čísla) a prakticky to neřeší problém.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 13:08:30
používá to peanovu aritmetiku na typové úrovni pro vynucení vlastností operací s vektorama (ve smyslu datové struktury), např. tahle funkce je vlastně to stejné jako sčítání:
append :: Vector a n -> Vector a m -> Vector a (n :+ m)
délka výsledného vektoru je součet délek vstupních vektorů (a typový systém to opravdu na implementaci vynutí)
1) Ten typ ale vůbec nezaručuje, že ten append dělá to, co chceme. Ten typ je kompatibilní se spoustou věcí od appendu v libovolném pořadí až po nějaké pseudonáhodné promíchání.
2) V reálných programech se obvykle počet prvků dovídám až v runtimu.
3) A jak to vůbec souvisí s tím, jestli kód odpovídá řešenému problému?
Název: Re:Typový system versus unittesty
Přispěvatel: SB 19. 06. 2018, 13:19:39
...V unittestech otestuju pár jednoduchých případů a mám celkem jistotu.

Jistotu nemáte, ale i jednoduchým(!) testem můžete zachytit ty největší průsery či totální nefunkčnosti (pravděpodobnost, že chybějící implementace či metoda vám vrátí správný výsledek, je nula hovno), v případě pouhých několika specifických testů dokážete dosáhnout řádově větší protestovanosti než POUHOU typovou kontrolou (kterou můžete úplně klidně též do testu u netypového jazyku doplnit!).

Mimochodem v TDD je pravidlem, že se píší vybrakované metody, které se teprve na stížnost hotových testů vyplňují, případně (a teď pozor, soudruzi javaři nečtěte dále, aby vám z toho nehráblo) se tyto metody teprve vytvářejí! :O :O :O (No nekecej!)

Tohle není odpověď pro JSH, ale autora dotazu Boneflute.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 13:22:15
Tak jinak: Doplňuju svůj původní příspěvek:

místo <cokoliv> je "return 10"

Typově je vše správně, ale nějak nám to pro většinu vstupů nevychází, přičemž by to mělo vyjít alespoň pro ty, které budu používat.

Přeloženo: Typová kontrola by zafungovala pouze v případě, že pro každé dva sčítance a součet budete mít extra typy, což je ale v rozporu s jednoduchými, obecnými kategoriemi (zde celá čísla) a prakticky to neřeší problém.
s použitím techniky o které jsem mluvil by se takový kód nepřeložil, že má třeba 1 a 2 jiný datový typ není nic až tak zvláštního
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 13:25:01
používá to peanovu aritmetiku na typové úrovni pro vynucení vlastností operací s vektorama (ve smyslu datové struktury), např. tahle funkce je vlastně to stejné jako sčítání:
append :: Vector a n -> Vector a m -> Vector a (n :+ m)
délka výsledného vektoru je součet délek vstupních vektorů (a typový systém to opravdu na implementaci vynutí)
Stále se míjíte s podstatou problému. V mém příkladu bylo záměrně sčítání a odčítání. Abyste si uvědomil, že v běžném programu budu potřebovat obojí, a žádný typový systém neohlídá to, že nepoužiju odčítání tam, kde z logiky věci má být sčítání.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 13:25:20
používá to peanovu aritmetiku na typové úrovni pro vynucení vlastností operací s vektorama (ve smyslu datové struktury), např. tahle funkce je vlastně to stejné jako sčítání:
append :: Vector a n -> Vector a m -> Vector a (n :+ m)
délka výsledného vektoru je součet délek vstupních vektorů (a typový systém to opravdu na implementaci vynutí)
1) Ten typ ale vůbec nezaručuje, že ten append dělá to, co chceme. Ten typ je kompatibilní se spoustou věcí od appendu v libovolném pořadí až po nějaké pseudonáhodné promíchání.
2) V reálných programech se obvykle počet prvků dovídám až v runtimu.
3) A jak to vůbec souvisí s tím, jestli kód odpovídá řešenému problému?
1) to je pravda a nevím jak to řešit, pro sčítání to ovšem nehraje roli
2) to se dá řešit
3) typ specifikuje co je řešený problém, funkce tomu musí odpovídat
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 13:27:29
používá to peanovu aritmetiku na typové úrovni pro vynucení vlastností operací s vektorama (ve smyslu datové struktury), např. tahle funkce je vlastně to stejné jako sčítání:
append :: Vector a n -> Vector a m -> Vector a (n :+ m)
délka výsledného vektoru je součet délek vstupních vektorů (a typový systém to opravdu na implementaci vynutí)
Stále se míjíte s podstatou problému. V mém příkladu bylo záměrně sčítání a odčítání. Abyste si uvědomil, že v běžném programu budu potřebovat obojí, a žádný typový systém neohlídá to, že nepoužiju odčítání tam, kde z logiky věci má být sčítání.
tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 13:27:46
s použitím techniky o které jsem mluvil by se takový kód nepřeložil, že má třeba 1 a 2 jiný datový typ není nic až tak zvláštního
Jak zabráníte tomu, aby programátor nepoužil špatný typ? Místo typu pro „sčítání“ použije typ pro „odčítání“.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 13:28:29
s použitím techniky o které jsem mluvil by se takový kód nepřeložil, že má třeba 1 a 2 jiný datový typ není nic až tak zvláštního
A k čemu to je, když většina numerických hodnot, se kterýma se pracuje, je k dispozici až v runtime? Na zkontrolování čísel, která znám při kompilaci, obvykle stačí blbý static_assert či něco podobného.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 13:32:45
tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test
To je ale nepochopení testů. Testy nemají opakovat implementaci, testy mají kontrolovat, zda pro zadaný vstup dostanu očekávaný výstup.

Nikdo netvrdil, že testy jsou dokonalé a že nemůže být chyba i v testu. Pouze vyvracíme tvrzení, že jednotkové testy lze plně nahradit silným typovým systémem. Vyvráceno to bylo triviálním příkladem, kdy programátor použije odčítání místo sčítání, a tomu žádný typový systém z logiky věci nemůže zabránit.
Název: Re:Typový system versus unittesty
Přispěvatel: Harik 19. 06. 2018, 13:32:50
Sorry, tvé příspěvky nejsou vůbec inspirativní. Nebudu se tedy tebou již zabejvat.

Jirsák a nobody  ;D ;D
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 13:34:33
s použitím techniky o které jsem mluvil by se takový kód nepřeložil, že má třeba 1 a 2 jiný datový typ není nic až tak zvláštního
A k čemu to je, když většina numerických hodnot, se kterýma se pracuje, je k dispozici až v runtime? Na zkontrolování čísel, která znám při kompilaci, obvykle stačí blbý static_assert či něco podobného.
nekontrolují se konkrétní čísla (typicky), ale funkce, které s nimi pracují, např. ten příklad se sčítáním tvrdí, že předpoklad z typu je splněn pro všechna čísla (Nat)
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 13:38:29
tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test
To je ale nepochopení testů. Testy nemají opakovat implementaci, testy mají kontrolovat, zda pro zadaný vstup dostanu očekávaný výstup.

Nikdo netvrdil, že testy jsou dokonalé a že nemůže být chyba i v testu. Pouze vyvracíme tvrzení, že jednotkové testy lze plně nahradit silným typovým systémem. Vyvráceno to bylo triviálním příkladem, kdy programátor použije odčítání místo sčítání, a tomu žádný typový systém z logiky věci nemůže zabránit.
já jsem ale o opakování implementace nic nepsal, pokud špatně pochopíte problém, můžete napsat test, který od funkce chce pro zadané vstupy jiné výstupy, než ty správné (z hlediska řešeného problému)
a prosím přestaňte si domýšlet obsah příspěvků, pokud máte pochybnosti tak se prostě zeptejte
Název: Re:Typový system versus unittesty
Přispěvatel: SB 19. 06. 2018, 13:49:17
tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

To už ale nemá co dělat s problematikou testování, ale chápání řešené úlohy, zde nevznikne rozdíl při použití typového systému, nebo testů.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 13:52:24
tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

To už ale nemá co dělat s problematikou testování, ale chápání řešené úlohy, zde nevznikne rozdíl při použití typového systému, nebo testů.
souhlasím
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 19. 06. 2018, 14:04:37
...V unittestech otestuju pár jednoduchých případů a mám celkem jistotu.

Jistotu nemáte, ale i jednoduchým(!) testem můžete zachytit ty největší průsery či totální nefunkčnosti (pravděpodobnost, že chybějící implementace či metoda vám vrátí správný výsledek, je nula hovno), v případě pouhých několika specifických testů dokážete dosáhnout řádově větší protestovanosti než POUHOU typovou kontrolou (kterou můžete úplně klidně též do testu u netypového jazyku doplnit!).

Ty testy se nepíší náhodně, ale testují se hlavně okrajové podmínky, kdy testovaná jednotka může selhat nebo musí selhat.

Mimochodem v TDD je pravidlem, že se píší vybrakované metody, které se teprve na stížnost hotových testů vyplňují, případně (a teď pozor, soudruzi javaři nečtěte dále, aby vám z toho nehráblo) se tyto metody teprve vytvářejí! :O :O :O (No nekecej!)

Má to svůj důvod. Pokud vytvořím test, který neselže, je to problém, který se musí vyřešit dříve, než napíši první znak testované jednotky. Může to být způsobeno například kolizí názvů, takže ten test testuje jinou jednotku téhož jména, která náhodou také projde.

Pak teprve napíši ty prázdné metody, které musí splnit definované rozhraní. Až testy projdou, teprve je čas na rozšíření testů o požadované funkcionality a následně i rozšíření metod.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 19. 06. 2018, 14:08:27
Stále se míjíte s podstatou problému. V mém příkladu bylo záměrně sčítání a odčítání. Abyste si uvědomil, že v běžném programu budu potřebovat obojí, a žádný typový systém neohlídá to, že nepoužiju odčítání tam, kde z logiky věci má být sčítání.
tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

Jistě, ale vcelku brzy zjistí, že ten test je chybný. Testy na testy se však nepíší, od toho tu jsou testované jednotky.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 14:18:41
já jsem ale o opakování implementace nic nepsal, pokud špatně pochopíte problém, můžete napsat test, který od funkce chce pro zadané vstupy jiné výstupy, než ty správné (z hlediska řešeného problému)
To je možné, ale je to spíše výjimečné. Daleko častější je případ, kdy ví správně, jaký výstup má být pro daný vstup, ale špatně to implementuje. Jednotkové testy řeší tenhle případ, a to silným typovým systémem nejde nahradit.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 14:19:07
nejdřív bych zdůraznil svůj postoj: neargumentuju proti testům, testy jsou dobrá věc
původní dotaz se zabývá tím (moje interpretace), jestli se testy dají teoreticky nahradit typovým systémem a já si vzhledem k tomu co jsem o tématu četl, myslím, že ano, dále mě zajímají praktické limity tohoto přístupu, protože z vlastní praxe ho považuju za extrémně užitečný

Chápeš to zcela přesně jak jsem to myslel.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 14:25:00
Mimochodem v TDD je pravidlem, že se píší vybrakované metody, které se teprve na stížnost hotových testů vyplňují, případně (a teď pozor, soudruzi javaři nečtěte dále, aby vám z toho nehráblo) se tyto metody teprve vytvářejí! :O :O :O (No nekecej!)

Tohle není odpověď pro JSH, ale autora dotazu Boneflute.

Obnošená vesta.

Proč @v dokázal pochopit, že se táži na limity toho typového systému vůči unittestům, zatímco jiní se mě pokouší přesvědčit že jsem idiot a ani nejsou schopni uvést zajímavé argumenty?
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 14:30:09
tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

To už ale nemá co dělat s problematikou testování, ale chápání řešené úlohy, zde nevznikne rozdíl při použití typového systému, nebo testů.

Samozřejmě.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 14:44:54
já jsem ale o opakování implementace nic nepsal, pokud špatně pochopíte problém, můžete napsat test, který od funkce chce pro zadané vstupy jiné výstupy, než ty správné (z hlediska řešeného problému)
To je možné, ale je to spíše výjimečné. Daleko častější je případ, kdy ví správně, jaký výstup má být pro daný vstup, ale špatně to implementuje. Jednotkové testy řeší tenhle případ, a to silným typovým systémem nejde nahradit.
co si vlastně představujete pod pojmem "silný typový systém"? já přinejmenším ten implementovaný v GHC
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 14:50:43
Proč @v dokázal pochopit, že se táži na limity toho typového systému vůči unittestům, zatímco jiní se mě pokouší přesvědčit že jsem idiot a ani nejsou schopni uvést zajímavé argumenty?
Vy jste se na nic netázal, vy jste konstatoval, že jednotkové testy nejsou při použití kvalitního typového systému potřeba (protože typový systém zajistí to, co jinak zajišťují jednotkové testy). Což není pravda, jak už zde bylo opakovaně dokázáno. Akorát to někteří nechápou a neustále navrhují různé typové systémy, které ovšem neodhalí chybu, která zde byla několikrát uvedena jako příklad, a kterou jednotkový test odhalí.

Pokud se příště budete chtít na něco dotázat, doporučuji zeptat se na to a ne tvrdit zjevný nesmysl.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 19. 06. 2018, 15:05:49
co si vlastně představujete pod pojmem "silný typový systém"?
Rozhodně něco s HKT (tím se vyloučí Java apod.), to by byl středně silný, nicméně jak tu už někdo zmiňoval, adjektivum "silný" by mělo implikovat alespoň běžné závislostní typy à la Agda/Coq/Idris.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 15:08:31
co si vlastně představujete pod pojmem "silný typový systém"? já přinejmenším ten implementovaný v GHC
Pro účely této diskuse si pod tím představuji ten nejsilnější teoreticky možný typový systém. Podstatou této diskuse je totiž to, že velká část problémů, které jsou podchycené jednotkovými testy, není řešitelná žádnými formálními mechanismy – protože formálně jsou přípustní všechny možnosti, ale pro řešení daného problému je přípustná jen jedna možnost.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 15:09:43
co si vlastně představujete pod pojmem "silný typový systém"?
Rozhodně něco s HKT (tím se vyloučí Java apod.), to by byl středně silný, nicméně jak tu už někdo zmiňoval, adjektivum "silný" by mělo implikovat alespoň běžné závislostní typy à la Agda/Coq/Idris.
co tohle https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/dependent-types-in-haskell ?
asi neumím říct, kde závislostní typy začínají
a "silný" je asi dost blbé označení
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 15:12:47
co si vlastně představujete pod pojmem "silný typový systém"? já přinejmenším ten implementovaný v GHC
Pro účely této diskuse si pod tím představuji ten nejsilnější teoreticky možný typový systém.
nevím, který to je, postněte odkaz
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 15:15:47
co si vlastně představujete pod pojmem "silný typový systém"?
Rozhodně něco s HKT (tím se vyloučí Java apod.), to by byl středně silný, nicméně jak tu už někdo zmiňoval, adjektivum "silný" by mělo implikovat alespoň běžné závislostní typy à la Agda/Coq/Idris.
Rád bych, když bychom se nedrželi jen toho, co se zatím někomou podařilo implementovat. Zajímá mě klidně i to, co by teoreticky šlo.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 19. 06. 2018, 15:16:49
nejdřív bych zdůraznil svůj postoj: neargumentuju proti testům, testy jsou dobrá věc
původní dotaz se zabývá tím (moje interpretace), jestli se testy dají teoreticky nahradit typovým systémem a já si vzhledem k tomu co jsem o tématu četl, myslím, že ano, dále mě zajímají praktické limity tohoto přístupu, protože z vlastní praxe ho považuju za extrémně užitečný
Chápeš to zcela přesně jak jsem to myslel.
Tohle téma je super (po dlouhé řadě trollotémat na Rootu), protože je zajímavé, aktuální a vybízí k hlubšímu zamyšlení. Obecně asi platí, že když se program převede do churchovského λ-kalkulu (kde se nerozlišuje mezi dobou překladu a běhu), tak jakákoliv totální funkce, jejíž doména je konečná, se dá verifikovat typově (čili v době překladu v nějaké implementaci s dostatečně silným typovým systémem). Odhalování a charakteristika chyb tímto způsobem souvisí (na úrovni pusté teorie) s ι-operátorem.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 15:18:34
co si vlastně představujete pod pojmem "silný typový systém"?
Rozhodně něco s HKT (tím se vyloučí Java apod.), to by byl středně silný, nicméně jak tu už někdo zmiňoval, adjektivum "silný" by mělo implikovat alespoň běžné závislostní typy à la Agda/Coq/Idris.
co tohle https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/dependent-types-in-haskell ?
asi neumím říct, kde závislostní typy začínají
a "silný" je asi dost blbé označení
Tý vozo, jsem ani nedoufal, že to v Haskellu jde. To bude zase propálených hodin.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 15:18:49
co si vlastně představujete pod pojmem "silný typový systém"? já přinejmenším ten implementovaný v GHC
Pro účely této diskuse si pod tím představuji ten nejsilnější teoreticky možný typový systém.
nevím, který to je, postněte odkaz
Klidně zrovna ten v Haskellu. Problémy, které tu zazněly, totiž neřeší. Jeden každý váš odkaz řešil jiný a podstatně jednodušší problém.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 15:23:35
Klidně zrovna ten v Haskellu. Problémy, které tu zazněly, totiž neřeší. Jeden každý váš odkaz řešil jiný a podstatně jednodušší problém.
tak zrovna to sčítání řeší
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 15:23:54
Obecně asi platí, že když se program převede do churchovského λ-kalkulu (kde se nerozlišuje mezi dobou překladu a běhu), tak jakákoliv totální funkce, jejíž doména je konečná, se dá verifikovat typově (čili v době překladu v nějaké implementaci s dostatečně silným typovým systémem). Odhalování a charakteristika chyb tímto způsobem souvisí (na úrovni pusté teorie) s ι-operátorem.
Limit typů jsou časová náročnost. Limit testů zase neúplnost. Dokážete si někdo představit, že by se dal uělat nějaký kompromis, omezit ultimátnost typů, aby to otestování proběhlo v kontrolovaném čase. Nebo optimalizovat compiler, aby si dokázal domyslet některé věci a nepočítal to hrubou silou?
Samozřejmě si představuju spíš otázku konfigurace, kdy při vývoji budu mět méně striktní režim, a pak při buildu dám kompilovat třeba tejden.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 15:27:42
tak zrovna to sčítání řeší
„To sčítání“ možná řeší. Ale to je nějaký váš problém, který tu neřešíme. My tu řešíme problém, že programátor měl použít sčítání a použil odčítání. Tohle neřeší žádný typový systém (tedy kromě takového, který odčítání vůbec nedovolí, což ale bude pro většinu programů nepoužitelné).
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 15:29:30
... (kde se nerozlišuje mezi dobou překladu a běhu) ...
Akorát že doba překladu a běhu jsou oddělené jak v čase, tak v prostoru. Spoustu informací typový systém prostě nemá a ani nemůže mít k dispozici.

Už jsem to tu jednou zmiňoval a v se zmohl akorát na "to se dá řešit". ::)
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 19. 06. 2018, 15:30:35
co si vlastně představujete pod pojmem "silný typový systém"?
Rozhodně něco s HKT (tím se vyloučí Java apod.), to by byl středně silný, nicméně jak tu už někdo zmiňoval, adjektivum "silný" by mělo implikovat alespoň běžné závislostní typy à la Agda/Coq/Idris.
Rád bych, když bychom se nedrželi jen toho, co se zatím někomou podařilo implementovat. Zajímá mě klidně i to, co by teoreticky šlo.
Co by šlo teoreticky se ví. Stačí vzít churchovský λ-kalkul a zamyslet se, jaké výpočty lze přenést na úroveň typů. Pokud požadujeme, aby překlad syntakticky správně utvořeného programu trval vždy jen konečnou dobu (to je poměrně rozumný předpoklad), lze přenést na tu vyšší ("typovou") úroveň funkce, které jsou totální (předpokladem je samozřejně dostatečně silný typový systém). Vše, co zbyde, se musí ponechat v tělech formulí. V implementaci by to pak zbylo na jednotkové testy. V podstatě stačí přečíst si původní článek o zmiňovaném λ-kalkulu a v příslušných kontextech si u typů představovat závislostní typy (jež korespondují s formální logikou s kvantifikátory). Tolik k tomu "co by teoreticky šlo", protože v praxi by byl přínos sporný až nesmyslný.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 15:35:36
... (kde se nerozlišuje mezi dobou překladu a běhu) ...
Akorát že doba překladu a běhu jsou oddělené jak v čase, tak v prostoru. Spoustu informací typový systém prostě nemá a ani nemůže mít k dispozici.

Už jsem to tu jednou zmiňoval a v se zmohl akorát na "to se dá řešit". ::)
taky jste se mohl zeptat na detaily, nechce se mi rozepisovat všechno, když píšu sem, tak nepíšu kód :D
http://augustss.blogspot.com/2009/06/more-llvm-recently-someone-asked-me-on.html
tohle je můj oblíbený příklad, ukazuje jak se od netypového syntaktického stromu dostat k silně typovanému, stejně to jde i s číslama
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 15:36:36
Limit typů jsou časová náročnost. Limit testů zase neúplnost. Dokážete si někdo představit, že by se dal uělat nějaký kompromis, omezit ultimátnost typů, aby to otestování proběhlo v kontrolovaném čase. Nebo optimalizovat compiler, aby si dokázal domyslet některé věci a nepočítal to hrubou silou?
Samozřejmě si představuju spíš otázku konfigurace, kdy při vývoji budu mět méně striktní režim, a pak při buildu dám kompilovat třeba tejden.
Problém je, že hodně zjednodušujete, a pak vyvozujete něco z nepřesností toho zjednodušení. Protože problém neúplnosti testů znamená, že mohou existovat vstupy, pro které dává testovaná jednotka chybný výsledek – přičemž taková kombinace není pokrytá testem. To je ale úplně jiná neúplnost, než „úplnost“ typů.

Formální dokazatelnost má smysl řešit u jednoduchých a kritických úloh typu zabezpečovací zařízení na železnici. U komplexních systémů typu ERP, bankovní systémy, webové prohlížeče apod. nemá vůbec smysl řešit rychlost případného kompilátoru, protože to je ten nejmenší problém – skutečný problém je v tom, že nikdo tak komplexní systém nedokáže správně formálně vyjádřit.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 19. 06. 2018, 15:36:54
... (kde se nerozlišuje mezi dobou překladu a běhu) ...
Akorát že doba překladu a běhu jsou oddělené jak v čase, tak v prostoru. Spoustu informací typový systém prostě nemá a ani nemůže mít k dispozici.

Už jsem to tu jednou zmiňoval a v se zmohl akorát na "to se dá řešit". ::)
Jistě, ale když už se tu volá po teorii, je poměrně snadné namapovat si prakticky používaný jazyk na zmíněný λ-kalkul a uvědomit si, že těla formulí jsou "běh" a typové výrazy "překlad". Typový systém taky může počítat, jen o úroveň výš (v praxi něco na způsob TMP v C++, v teorii na úrovni typů složených z *). Jde jen o to, jaké operátory jsou na té které úrovni povoleny.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 15:43:59
... (kde se nerozlišuje mezi dobou překladu a běhu) ...
Akorát že doba překladu a běhu jsou oddělené jak v čase, tak v prostoru. Spoustu informací typový systém prostě nemá a ani nemůže mít k dispozici.

Už jsem to tu jednou zmiňoval a v se zmohl akorát na "to se dá řešit". ::)
taky jste se mohl zeptat na detaily, nechce se mi rozepisovat všechno, když píšu sem, tak nepíšu kód :D
http://augustss.blogspot.com/2009/06/more-llvm-recently-someone-asked-me-on.html
tohle je můj oblíbený příklad, ukazuje jak se od netypového syntaktického stromu dostat k silně typovanému, stejně to jde i s číslama
Cože??? To jako že až se na uživatelově stroji načtou vstupy, tak si pro ty vstupy teprve zkompiluju něco spustitelného???

Já doufám, že jsem to vůbec nepochopil. Opravdu v to upřímně doufám.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 19. 06. 2018, 15:47:37
Klidně zrovna ten v Haskellu. Problémy, které tu zazněly, totiž neřeší. Jeden každý váš odkaz řešil jiný a podstatně jednodušší problém.
tak zrovna to sčítání řeší

Jaké je tedy správné řešení s použitím typů, které odhalí, že ve sčítací funkci programátor chybně napsal znaménko "-"? Zatím jsem se dozvěděl jen to, že to jde, s odkazem na článek. Jak by tedy vypadal zápis této triviality, např. v Haskellu?
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 15:47:57
... (kde se nerozlišuje mezi dobou překladu a běhu) ...
Akorát že doba překladu a běhu jsou oddělené jak v čase, tak v prostoru. Spoustu informací typový systém prostě nemá a ani nemůže mít k dispozici.

Už jsem to tu jednou zmiňoval a v se zmohl akorát na "to se dá řešit". ::)
taky jste se mohl zeptat na detaily, nechce se mi rozepisovat všechno, když píšu sem, tak nepíšu kód :D
http://augustss.blogspot.com/2009/06/more-llvm-recently-someone-asked-me-on.html
tohle je můj oblíbený příklad, ukazuje jak se od netypového syntaktického stromu dostat k silně typovanému, stejně to jde i s číslama
Cože??? To jako že až se na uživatelově stroji načtou vstupy, tak si pro ty vstupy teprve zkompiluju něco spustitelného???

Já doufám, že jsem to vůbec nepochopil. Opravdu v to upřímně doufám.
nepochopil a jestli máte podobný background jako já (v mém případě C, C++, C#, python), tak se ani nedivím, docela mi trvalo než jsem to vstřebal (s pauzama možná rok), vlastně to není nic tak komplikovaného, ale je to hodně odlišné od programátorského mainstreamu
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 15:50:21
Klidně zrovna ten v Haskellu. Problémy, které tu zazněly, totiž neřeší. Jeden každý váš odkaz řešil jiný a podstatně jednodušší problém.
tak zrovna to sčítání řeší

Jaké je tedy správné řešení s použitím typů, které odhalí, že ve sčítací funkci programátor chybně napsal znaménko "-"? Zatím jsem se dozvěděl jen to, že to jde, s odkazem na článek. Jak by tedy vypadal zápis této triviality, např. v Haskellu?
viz článek hned pod větou "For example, singleton function for natural addition :+ can be implemented as follows:"
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 15:52:01
že těla formulí jsou "běh" a typové výrazy "překlad".
Možná ti jen nerozumím, ale:
mám množiny
Bool = True | False
RGB = Red | Green | Blue
pak mám funkci
isRed :: RGB -> Bool
která se dá zapsat takto:
isRed :: RGB -> Bool = (Red -> True) | (Green -> False) | (Blue -> False)
Té množině isRed ale obvykle říkáme funkce, a něco počítá, ale je to stejně jen množina, respektive pohled na průnik dvou množin. (Nebudu se pokoušet trefit se do přesného pojmosloví.)

Bavíme se cca o tom samém?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 19. 06. 2018, 15:56:34
Jaké je tedy správné řešení s použitím typů, které odhalí, že ve sčítací funkci programátor chybně napsal znaménko "-"? Zatím jsem se dozvěděl jen to, že to jde, s odkazem na článek. Jak by tedy vypadal zápis této triviality, např. v Haskellu?
viz článek hned pod větou "For example, singleton function for natural addition :+ can be implemented as follows:"

Celý článek? V testech je to na několika řádcích a definice typu je na celý článek?
Název: Re:Typový system versus unittesty
Přispěvatel: SB 19. 06. 2018, 16:01:54
Proč @v dokázal pochopit, že se táži na limity toho typového systému vůči unittestům, zatímco jiní se mě pokouší přesvědčit že jsem idiot a ani nejsou schopni uvést zajímavé argumenty?

Omezené možnosti kontroly správnosti programu typovým systémem jsem vám přímočaře a bleskově (a vypadá to, že nejen já, nečetl jsem vše) předvedl na příkladu, víceméně důkazu sporem. Takže odpověď na váš původní dotaz už máte. Je třeba ještě něco řešit?
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 16:04:06
Jaké je tedy správné řešení s použitím typů, které odhalí, že ve sčítací funkci programátor chybně napsal znaménko "-"? Zatím jsem se dozvěděl jen to, že to jde, s odkazem na článek. Jak by tedy vypadal zápis této triviality, např. v Haskellu?
viz článek hned pod větou "For example, singleton function for natural addition :+ can be implemented as follows:"

Celý článek? V testech je to na několika řádcích a definice typu je na celý článek?
typy můžou být definovány v knihovnách a mezi testem a tím v článku je přece jenom trochu rozdíl, ty záruky (pro všechny dvojice přirozených čísel) prostě testama nelze nahradit
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 16:05:41
nepochopil a jestli máte podobný background jako já (v mém případě C, C++, C#, python), tak se ani nedivím, docela mi trvalo než jsem to vstřebal (s pauzama možná rok), vlastně to není nic tak komplikovaného, ale je to hodně odlišné od programátorského mainstreamu
Tak mi to prosím osvětlete. Můj background je primárně C++ a hned po tom právě Haskell. Jestli jsem ten článek pochopil dobře, tak je to o JIT kompilaci Haskellu. Kdy a kde ta JIT kompilace běží?
Jestli u mně, tak neznám všechny vstupy a nemůžu si dovolit třeba velikosti polí nacpat do typu.
Jestli to běží u uživatele, tak jsou důkladné unit testy jediná možnost, jak si užít klidnou dovolenou.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 16:05:56
Proč @v dokázal pochopit, že se táži na limity toho typového systému vůči unittestům, zatímco jiní se mě pokouší přesvědčit že jsem idiot a ani nejsou schopni uvést zajímavé argumenty?

Omezené možnosti kontroly správnosti programu typovým systémem jsem vám přímočaře a bleskově (a vypadá to, že nejen já, nečetl jsem vše) předvedl na příkladu, víceméně důkazu sporem. Takže odpověď na váš původní dotaz už máte. Je třeba ještě něco řešit?
Pro pořádek, hodíte sem link na ten příspěvek, prosím? Protože je možné, že jsem to mezi spoustou toho smetí přehlédl.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 19. 06. 2018, 16:06:26
viz článek hned pod větou "For example, singleton function for natural addition :+ can be implemented as follows:"

Nebudu líny jako ty a pošlu sem ten kus kódu, který má nahradit test na sčítání typem:
Kód: [Vybrat]
infixl 6 :+

(%:+) :: SNat n -> SNat m -> SNat (n :+ m)
SZ   %:+ m = m
SS n %:+ m = SS (n %:+ m)

Vypadá to skoro jako test.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 19. 06. 2018, 16:06:35
že těla formulí jsou "běh" a typové výrazy "překlad".
Možná ti jen nerozumím, ale:
mám množiny
Bool = True | False
RGB = Red | Green | Blue
pak mám funkci
isRed :: RGB -> Bool
která se dá zapsat takto:
isRed :: RGB -> Bool = (Red -> True) | (Green -> False) | (Blue -> False)
Té množině isRed ale obvykle říkáme funkce, a něco počítá, ale je to stejně jen množina, respektive pohled na průnik dvou množin. (Nebudu se pokoušet trefit se do přesného pojmosloví.)

Bavíme se cca o tom samém?
Ano, bavíme. Jen jsem psal (možná to trochu zapadlo), že operace (výpočty) na všech úrovních jsou dány formulemi a základními hodnotami. Co jde vypočítat na té které úrovni je dáno těmito hodnotami stanovenými úmluvou. Na té nejnižší úrovni se utvořeným výrazům říká funkce, protože odpovídají funkcím v teorii množin (nebo prostě aritmetice apod.). Stejně tvořeným výrazům na vyšší úrovni už se říká jinak (podle kontextu metavýrazy, metahodnoty apod.), ale v podstatě to je to samé, jen o úroveň výše. V případě isRed můžu jednoduše napsat funkci a stejně jednoduše můžu vytvořit součtový typ nad RGB implementující isRed o úroveň výše (něco jako "metaIsRed"), jenž by šel použít v typovém systému pro kontrolu v době překladu. Ale jak už jsem psal nejméně dvakrát, moc praktické takové počínání není, už jen proto, že takové typy by se nikdy nepoužily za běhu (ne že by se to nedělalo, ale jde jen o velmi speciální případy v avionice nebo kódu pro jaderné elektrárny apod.).
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 16:12:59
nepochopil a jestli máte podobný background jako já (v mém případě C, C++, C#, python), tak se ani nedivím, docela mi trvalo než jsem to vstřebal (s pauzama možná rok), vlastně to není nic tak komplikovaného, ale je to hodně odlišné od programátorského mainstreamu
Tak mi to prosím osvětlete. Můj background je primárně C++ a hned po tom právě Haskell. Jestli jsem ten článek pochopil dobře, tak je to o JIT kompilaci Haskellu. Kdy a kde ta JIT kompilace běží?
Jestli u mně, tak neznám všechny vstupy a nemůžu si dovolit třeba velikosti polí nacpat do typu.
Jestli to běží u uživatele, tak jsou důkladné unit testy jediná možnost, jak si užít klidnou dovolenou.
tak možná jsem zvolil trochu matoucí příklad, JIT je tam to co se implementuje, ne technika, která se využívá k implementaci něčeho jiného (uff)
kouzelný typ tam je "data TExp a" a pointa je, že nejde vytvořit hodnota tohoto typu, která by reprezentoval chybně typovaný syntaktický strom
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 16:13:09
že těla formulí jsou "běh" a typové výrazy "překlad".
Možná ti jen nerozumím, ale:
mám množiny
Bool = True | False
RGB = Red | Green | Blue
pak mám funkci
isRed :: RGB -> Bool
která se dá zapsat takto:
isRed :: RGB -> Bool = (Red -> True) | (Green -> False) | (Blue -> False)
Té množině isRed ale obvykle říkáme funkce, a něco počítá, ale je to stejně jen množina, respektive pohled na průnik dvou množin. (Nebudu se pokoušet trefit se do přesného pojmosloví.)

Bavíme se cca o tom samém?
Ano, bavíme. Jen jsem psal (možná to trochu zapadlo), že operace (výpočty) na všech úrovních jsou dány formulemi a základními hodnotami. Co jde vypočítat na té které úrovni je dáno těmito hodnotami stanovenými úmluvou. Na té nejnižší úrovni se utvořeným výrazům říká funkce, protože odpovídají funkcím v teorii množin (nebo prostě aritmetice apod.). Stejně tvořeným výrazům na vyšší úrovni už se říká jinak (podle kontextu metavýrazy, metahodnoty apod.), ale v podstatě to je to samé, jen o úroveň výše. V případě isRed můžu jednoduše napsat funkci a stejně jednoduše můžu vytvořit součtový typ nad RGB implementující isRed o úroveň výše (něco jako "metaIsRed"), jenž by šel použít v typovém systému pro kontrolu v době překladu.
Neměl by si prosím nějakou pěknu demonstraci principu toho metaIsRed. Nebo link na nějaké zdroje. Přeci jenom to hned z fleku nedávám (už jen ty množiny mi chvilku trvaly, než jsem dosáhl aha efektu).

A hlavně díky :-)

Ale jak už jsem psal nejméně dvakrát, moc praktické takové počínání není, už jen proto, že takové typy by se nikdy nepoužily za běhu.
Jak už jsem psal taky nejméně dvakrát, na praktičnost vám prdim :-)

Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 16:14:33
tak možná jsem zvolil trochu matoucí příklad, JIT je tam to co se implementuje, ne technika, která se využívá k implementaci něčeho jiného (uff)
kouzelný typ tam je "data TExp a" a pointa je, že nejde vytvořit hodnota tohoto typu, která by reprezentoval chybně typovaný syntaktický strom
Wow!
+1
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 16:18:32
Ano, bavíme. Jen jsem psal (možná to trochu zapadlo), že operace (výpočty) na všech úrovních jsou dány formulemi a základními hodnotami. Co jde vypočítat na té které úrovni je dáno těmito hodnotami stanovenými úmluvou.
Nejsou ty formule náhodou takové ty "grupové axiomy"? Abych si to nějak srovnal.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 19. 06. 2018, 16:23:15
typy můžou být definovány v knihovnách a mezi testem a tím v článku je přece jenom trochu rozdíl, ty záruky (pro všechny dvojice přirozených čísel) prostě testama nelze nahradit

Měl jem na mysli hlavně typy, které v knihovnách definovány nejsou a které je třeba definovat ke každé uživatelské funkci. Kdybych to aplikoval například na určitý integrál s mezemi a, b a funkcí f(x), tak ta definice typu bude buď nehorázně složitá, anebo bude duplicitou té funkce. Úplně se tím vytratí kouzlo jednoduchosti funkcionálního jazyka.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 19. 06. 2018, 16:25:09
Ano, bavíme. Jen jsem psal (možná to trochu zapadlo), že operace (výpočty) na všech úrovních jsou dány formulemi a základními hodnotami. Co jde vypočítat na té které úrovni je dáno těmito hodnotami stanovenými úmluvou.
Nejsou ty formule náhodou takové ty "grupové axiomy"? Abych si to nějak srovnal.
Vypadají tak. Formule se prostě poskládá z elementárních hodnot (ty závisí na úrovni, o kterou se jedná) a operací (grupy mají např. jen jednu). Hlavní rozdíl je, že u grup nejsou typy. Jakmile je přidáme, dostaneme kategorie, ale o těch se tu nemluví, jinak přijde Voldemort a sežere nám všechny monády...
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 16:34:39
Nejsou ty formule náhodou takové ty "grupové axiomy"? Abych si to nějak srovnal.
Vypadají tak. Formule se prostě poskládá z elementárních hodnot (ty závisí na úrovni, o kterou se jedná) a operací (grupy mají např. jen jednu). Hlavní rozdíl je, že u grup nejsou typy. Jakmile je přidáme, dostaneme kategorie, ale o těch se tu nemluví, jinak přijde Voldemort a sežere nám všechny monády...

Díky!
Název: Re:Typový system versus unittesty
Přispěvatel: SB 19. 06. 2018, 16:49:12
Pro pořádek, hodíte sem link na ten příspěvek, prosím? Protože je možné, že jsem to mezi spoustou toho smetí přehlédl.

Zde: https://forum.root.cz/index.php?topic=18804.msg270520#msg270520 (https://forum.root.cz/index.php?topic=18804.msg270520#msg270520)

Když tu tak čtu tu diskusi (a některým věcem nerozumím), tak mě napadá, že by asi šlo testy nahradit nějakým typovým systémem, ale jeho složitost by byla extrémní. Z praktického hlediska testy vyměňují obecnost (kategorie) či případnou složitost typového systému za svoji neúplnost (testování diskrétních hodnot) - diskrétní hodnoty by musely být nahrazeny mnoha specifickými třídami vedoucími na výraznou složitost typového systému. Uvažuju správně?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 19. 06. 2018, 16:50:26
Nejsou ty formule náhodou takové ty "grupové axiomy"? Abych si to nějak srovnal.
Vypadají tak. Formule se prostě poskládá z elementárních hodnot (ty závisí na úrovni, o kterou se jedná) a operací (grupy mají např. jen jednu). Hlavní rozdíl je, že u grup nejsou typy. Jakmile je přidáme, dostaneme kategorie, ale o těch se tu nemluví, jinak přijde Voldemort a sežere nám všechny monády...
Díky!
Abych to ještě uvedl přesněji: jsou dány základní typy (Church měl například ι a ο pro individua a pravdivostní hodnoty) a typované operace nad těmito typy. Funkčním výrazům odpovídají výhradně uzavřené formule, kupříkladu +≡(λx:ω)(λy:ω)x+y. Tělo je "x+y" a je vidět, že formule je uzavřená a výsledek je typu ω, takže typ formule je ωωω (asociativita je doleva). Tady je názorně vidět, že jediná operace u typů je v případě Churchova systému kompozice (v Haskellu se říká typový konstruktor). Když připustíme silnější typy, například se závislostmi (λ-kalkulu to je jedno, funguje s jakýmkoliv typovým systémem), můžeme počítat s typy a hodnoty na té nižší úrovní budou triviální (pro účely kontroly "překladu"), třeba u toho metaIsRed bychom měli jednotkové typy True a False. Největší sranda je, že jakmile začneme takto šaškovat s typy, neskončíme u dvou úrovní, ale nekonečně mnoha :) V praxi (jakmile to chceme implementovat) nás pak omezuje jen ta podmínka na konečnou dobu překladu (i když nekonečno vs. 100 let už zase takový rozdíl v praxi není...).
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 19. 06. 2018, 16:52:09
Pro pořádek, hodíte sem link na ten příspěvek, prosím? Protože je možné, že jsem to mezi spoustou toho smetí přehlédl.
Když tu tak čtu tu diskusi (a některým věcem nerozumím), tak mě napadá, že by asi šlo testy nahradit nějakým typovým systémem, ale jeho složitost by byla extrémní.
Přesně, výhody by rozhodně nepřevažovaly. Ale výslovně byla žádána teorie bez ohledu na praxi.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 17:14:26
Když tu tak čtu tu diskusi (a některým věcem nerozumím), tak mě napadá, že by asi šlo testy nahradit nějakým typovým systémem, ale jeho složitost by byla extrémní. Z praktického hlediska testy vyměňují obecnost (kategorie) či případnou složitost typového systému za svoji neúplnost (testování diskrétních hodnot) - diskrétní hodnoty by musely být nahrazeny mnoha specifickými třídami vedoucími na výraznou složitost typového systému. Uvažuju správně?
Nešlo by takto nahradit ani zdaleka všechny testy. Vycházíte z toho, že test pokryje jenom některé možné vstupy, a nějakým typovým systémem byste omezil typy tak, aby byly možné jenom ty vstupy, které dávají správné výstupy. Jenomže tím se dostáváte do cyklu, protože to, zda jsou výstupy správné, není vlastností toho typového systému, ale je to arbitrární vlastnost – něco, co tomu přisuzujeme z venku. A k tomu právě slouží ty testy, abychom ověřili, že implementace (libovolná, klidně jako „typový systém“) odpovídá těm námi stanoveným pravidlům.

Jinak řečeno – o nějakém algoritmu ani typu nelze říci, zda je nebo není správně (sám o sobě). Jestli je nebo není správně závisí na tom, k čemu ho chceme použít. A to právě dělají testy – dají dohromady implementaci (algoritmus) a způsob použití a testují, zda daný algoritmus je správný pro daný způsob použití.

Typový systém nás může omezit, abychom něco nemohli použít způsobem, který pravděpodobně nikdy nebude správně. Ale už nás nemůže omezovat ve způsobu použití, který někdy správně je ale jindy správně není.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 17:15:59
typy můžou být definovány v knihovnách a mezi testem a tím v článku je přece jenom trochu rozdíl, ty záruky (pro všechny dvojice přirozených čísel) prostě testama nelze nahradit

Měl jem na mysli hlavně typy, které v knihovnách definovány nejsou a které je třeba definovat ke každé uživatelské funkci. Kdybych to aplikoval například na určitý integrál s mezemi a, b a funkcí f(x), tak ta definice typu bude buď nehorázně složitá, anebo bude duplicitou té funkce. Úplně se tím vytratí kouzlo jednoduchosti funkcionálního jazyka.
pokud se bavíme o tom co teoreticky jde, tak je jedno jestli je to komplikované, pokud se bavíme o tom co je praktické, tak na integrál apod. to nikdo (???) aplikovat nebude, použití v http://augustss.blogspot.com/2009/06/more-llvm-recently-someone-asked-me-on.html je aspoň pro mě takový sweet spot (viz též https://hackage.haskell.org/package/TTTAS-0.6.0)
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 17:20:44
Pro pořádek, hodíte sem link na ten příspěvek, prosím? Protože je možné, že jsem to mezi spoustou toho smetí přehlédl.

Zde: https://forum.root.cz/index.php?topic=18804.msg270520#msg270520 (https://forum.root.cz/index.php?topic=18804.msg270520#msg270520)
myslím, že jsem vám psal (?), že tohle by se nepřeložilo

Když tu tak čtu tu diskusi (a některým věcem nerozumím), tak mě napadá, že by asi šlo testy nahradit nějakým typovým systémem, ale jeho složitost by byla extrémní. Z praktického hlediska testy vyměňují obecnost (kategorie) či případnou složitost typového systému za svoji neúplnost (testování diskrétních hodnot) - diskrétní hodnoty by musely být nahrazeny mnoha specifickými třídami vedoucími na výraznou složitost typového systému. Uvažuju správně?
kurz und gut, že něco jde ještě neznamená, že to je dobrý nápad
Název: Re:Typový system versus unittesty
Přispěvatel: ava 19. 06. 2018, 18:14:49
Mě by zajímalo: Pokud tvrdíte, že typy dokáží nahradit unit testy, jak by se (jen teoreticky, ať se to překládá třeba sto let) naimplementovala funkce incrementString převádějící čísla uloženého ve stringu (třeba "42") na string obsahující číslo o jedna vyšší ("43") tak, aby typová kontrola dokázala nahradit alespoň (ne všechny případy pokrývající, situaci by mohl výrazně zlepšit např. nějaký property check test, ale to není pointou příspěvku) unit test

assertEqual("43", incrementString("42"))

? (nevalidní čísla není třeba pro potřeby příkladu uvažovat, můžeme pro ně např. chtít vrátit prázdný string)
Název: Re:Typový system versus unittesty
Přispěvatel: Radek Micek 19. 06. 2018, 18:27:01
Mě by zajímalo: Pokud tvrdíte, že typy dokáží nahradit unit testy, jak by se (jen teoreticky, ať se to překládá třeba sto let) naimplementovala funkce incrementString převádějící čísla uloženého ve stringu (třeba "42") na string obsahující číslo o jedna vyšší ("43") tak, aby typová kontrola dokázala nahradit alespoň (ne všechny případy pokrývající, situaci by mohl výrazně zlepšit např. nějaký property check test, ale to není pointou příspěvku) unit test

assertEqual("43", incrementString("42"))

? (nevalidní čísla není třeba pro potřeby příkladu uvažovat, můžeme pro ně např. chtít vrátit prázdný string)

Treba v jazyce Idris existuje za timto ucelem datovy typ So : Bool -> Type (https://github.com/idris-lang/Idris-dev/blob/master/libs/base/Data/So.idr), jehoz jedina hodnota je Oh a ta ma typ So True.

Pak staci psat

Kód: [Vybrat]
nazevTestu : So ("43" == incrementString("42"))
nazevTestu = Oh

Pokud tedy pozadovano rovnost neplati, ma nazevTestu typ So False jenze Oh ma typ So True, takze se program neprelozi.
Název: Re:Typový system versus unittesty
Přispěvatel: ava 19. 06. 2018, 18:50:12
Mě by zajímalo: Pokud tvrdíte, že typy dokáží nahradit unit testy, jak by se (jen teoreticky, ať se to překládá třeba sto let) naimplementovala funkce incrementString převádějící čísla uloženého ve stringu (třeba "42") na string obsahující číslo o jedna vyšší ("43") tak, aby typová kontrola dokázala nahradit alespoň (ne všechny případy pokrývající, situaci by mohl výrazně zlepšit např. nějaký property check test, ale to není pointou příspěvku) unit test

assertEqual("43", incrementString("42"))

? (nevalidní čísla není třeba pro potřeby příkladu uvažovat, můžeme pro ně např. chtít vrátit prázdný string)

Treba v jazyce Idris existuje za timto ucelem datovy typ So : Bool -> Type (https://github.com/idris-lang/Idris-dev/blob/master/libs/base/Data/So.idr), jehoz jedina hodnota je Oh a ta ma typ So True.

Pak staci psat

Kód: [Vybrat]
nazevTestu : So ("43" == incrementString("42"))
nazevTestu = Oh

Pokud tedy pozadovano rovnost neplati, ma nazevTestu typ So False jenze Oh ma typ So True, takze se program neprelozi.

Hmm, jestli chápu správně, tak pro tento příklad jedna (zřejmě dost pozdní) z fází překladu v jazyce Idris je vlastně spuštění kódu "43" == incrementString("42")?

Taková "typová kontrola" mi nakonec zní dost podobně jako unit test (což je také spuštění kódu), s tím rozdílem, že u unit testu si sám rozhodnu, že když dopadne červeně, mám kód považovat za nevalidní, kdežto v příkladu s Idris to za mě rozhodne překladač (kód je vždy nevalidní). Nebo je tam nějaký další rozdíl, který nevidím?

Každopádně je to zajímavé, ale jestli jsem to pochopil správně, paradoxně mi to vychází spíš jako argument pro unit testy :)
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 21:04:47
Pro pořádek, hodíte sem link na ten příspěvek, prosím? Protože je možné, že jsem to mezi spoustou toho smetí přehlédl.

Zde: https://forum.root.cz/index.php?topic=18804.msg270520#msg270520 (https://forum.root.cz/index.php?topic=18804.msg270520#msg270520)
Obávám se, že toto je ta samá věc, kterou uváděl Filip Jirsák. A tuším, že tu bylo minimálně dvakrát poukazováno, že to by problém být neměl - viz závislostní typy.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 06. 2018, 21:14:01
V tomto vláknu https://forum.root.cz/index.php?topic=18370.0 , díky pěkné odpovědi od @andi-ho, jsem si uvědomil jednu věc:

Mám zápis, čitelný pro stroj:
Kód: [Vybrat]
    case s `hasMinimumLen` 4 of
        Just sn -> Str.sub sn 20
        Nothing -> "default"

Ale pro člověka je mnohem lepší zápis:
Kód: [Vybrat]
    if (Str.len s) < 4 then
        "default"
    else
        Str.sub s 20

Jenže není vůbec žádný problém naučit stroj, aby ten druhý, lidský zápis chápal a převedl si ho na ten svůj.

Tudíž já mohu napsat:
Kód: [Vybrat]
add x y = x + y

stroj si to převede na svou reprezentaci (něco jako x * succ y), ale podstatné je, že když změním implementaci:

Kód: [Vybrat]
add x y = y + x
add x y = if x == 0 then y else x + y

tak stroj pozná, že je to stejného typu, a nebude mět výhrady, zatímco

Kód: [Vybrat]
add x y = if x < 1 then y else x + y

odmítne.

Pointa je tedy taková, že možná není tak úplně nutné, aby psaní těch komplexních typů bylo nějak zvláště o tolik složitější než na to napsat test. Záleží, jak dobře se to navrhne.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 21:23:19
Obávám se, že toto je ta samá věc, kterou uváděl Filip Jirsák. A tuším, že tu bylo minimálně dvakrát poukazováno, že to by problém být neměl - viz závislostní typy.
Nazval bych to teologickým programováním: „Když něčemu nerozumím, musí to být všemocné“. (Po této fázi následuje fáze zklamání, že to příslušný jazyk nebo koncepce „neumí“, zařazení jazyka či koncepce na seznam špatných jazyků/koncepcí a vyhlédnutí dalšího kandidáta, který už určitě bude dokonalý.)

Vy se stále touláte někde ve výšinách, ale unikají vám základní věci. Testy se píšou proto, aby odhalily případné chyby v programu. Na tom se shodneme? Tedy pokud program může obsahovat chyby, má smysl psát testy. Na tom se také shodneme? Pak tedy platí, že testy nemá smysl psát jenom u programu, u kterého bezpečně víme, že neobsahuje žádnou chybu. I na tom se shodneme? Takže vy tu vlastně hledáte způsob, jak docílit toho, aby platilo „pokud to šlo  zkompilovat, není v tom žádná chyba“, je to tak?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 06. 2018, 21:31:09
Pointa je tedy taková, že možná není tak úplně nutné, aby psaní těch komplexních typů bylo nějak zvláště o tolik složitější než na to napsat test. Záleží, jak dobře se to navrhne.
Test pokrývá jen malou množinu vstupů z (často teoreticky nekonečné) množiny všech možných vstupů. Jak by asi „kompilátor“ doplnil definici toho komplexního typu pro vstupy, které by tím testem nebyly pokryté?

Napsat test může být takhle jednoduché:
Kód: [Vybrat]
assert 5 == fun(2, 3)
assert 3 == fun(1, 2)

Co k tomu přidáte, aby to popisovalo komplexní typ?
Název: Re:Typový system versus unittesty
Přispěvatel: wamba 19. 06. 2018, 22:41:20
Citace
Napsat test může být takhle jednoduché:
Kód: [Vybrat]
assert 5 == fun(2, 3)
assert 3 == fun(1, 2)

V Perlu 6 by šel napsat typ (resp. podtyp), který jen kontroluje tyto případy
Kód: [Vybrat]
subset Add where { $++ || add(1,1) == 2 && add(2,3) == 5 };
sub add ( $a, $b --> Add ) { $a + $b };

say add 1,2 ;
ale samozřejmě chápu, že k tomuto původní dotaz nesměřoval :)
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 19. 06. 2018, 22:41:55
tak možná jsem zvolil trochu matoucí příklad, JIT je tam to co se implementuje, ne technika, která se využívá k implementaci něčeho jiného (uff)
kouzelný typ tam je "data TExp a" a pointa je, že nejde vytvořit hodnota tohoto typu, která by reprezentoval chybně typovaný syntaktický strom
Tak já zopakuju svůj blbý dotaz. Ty instance toho typu TExp se vytvářejí v runtime? Jestli ne, tak proč to neprohnat přímo skrz ghc (se všemi omezeními, které už jsem zmiňoval)?
Pokud se vytvářejí v runtime, tak je to argument pro unit (a ostatní) testy. Udělat z Haskellu dynamicky typovaný jazyk je sice cool, ale jako u každého jiného dynamicky typovaného jazyka ztrácím typovou kontrolu v době překladu a jsem odkázáný čistě na ty testy.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 06. 2018, 23:13:25
tak možná jsem zvolil trochu matoucí příklad, JIT je tam to co se implementuje, ne technika, která se využívá k implementaci něčeho jiného (uff)
kouzelný typ tam je "data TExp a" a pointa je, že nejde vytvořit hodnota tohoto typu, která by reprezentoval chybně typovaný syntaktický strom
Tak já zopakuju svůj blbý dotaz. Ty instance toho typu TExp se vytvářejí v runtime? Jestli ne, tak proč to neprohnat přímo skrz ghc (se všemi omezeními, které už jsem zmiňoval)?
Pokud se vytvářejí v runtime, tak je to argument pro unit (a ostatní) testy. Udělat z Haskellu dynamicky typovaný jazyk je sice cool, ale jako u každého jiného dynamicky typovaného jazyka ztrácím typovou kontrolu v době překladu a jsem odkázáný čistě na ty testy.
ano, v runtime, je to miniaturní překladač, překladače mají  dispozici překládaný kód až v runtime (TExp je syntaktický strom překládaného "jazyka")
Název: Re:Typový system versus unittesty
Přispěvatel: SB 20. 06. 2018, 08:44:27
Zde: https://forum.root.cz/index.php?topic=18804.msg270520#msg270520 (https://forum.root.cz/index.php?topic=18804.msg270520#msg270520)
myslím, že jsem vám psal (?), že tohle by se nepřeložilo

Právěže přeložilo, syntakticky ani typově to nemá chybu, ale významově už ano.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 20. 06. 2018, 09:03:06
ano, v runtime, je to miniaturní překladač, překladače mají  dispozici překládaný kód až v runtime (TExp je syntaktický strom překládaného "jazyka")
Konečně. Takže tady má BoneFlute příklad, kdy unittesty (nebo testy obecně) nejde nahradit typovým systémem. A to ani hypoteticky za jakýchkoliv předpokladů. Prostě proto, že se typový systém dostane ke slovu až v runtimu.
Název: Re:Typový system versus unittesty
Přispěvatel: v 20. 06. 2018, 09:19:03
Zde: https://forum.root.cz/index.php?topic=18804.msg270520#msg270520 (https://forum.root.cz/index.php?topic=18804.msg270520#msg270520)
myslím, že jsem vám psal (?), že tohle by se nepřeložilo

Právěže přeložilo, syntakticky ani typově to nemá chybu, ale významově už ano.
nepřeložilo, reprezentace celých čísel, kterou to používá má pro každé konkrétní číslo jiný datový typ (to jsou ty "dependent types"), ale neznamená to, že musíte pro každé číslo implementovat funkcionalitu zvlášť, ten typový systém je docela chytrý
Název: Re:Typový system versus unittesty
Přispěvatel: v 20. 06. 2018, 09:20:54
ano, v runtime, je to miniaturní překladač, překladače mají  dispozici překládaný kód až v runtime (TExp je syntaktický strom překládaného "jazyka")
Konečně. Takže tady má BoneFlute příklad, kdy unittesty (nebo testy obecně) nejde nahradit typovým systémem. A to ani hypoteticky za jakýchkoliv předpokladů. Prostě proto, že se typový systém dostane ke slovu až v runtimu.
tak to není a pro původní dotaz to moc neznamená, protože ten se týkal teoretických mezí
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 20. 06. 2018, 09:47:21
tak to není a pro původní dotaz to moc neznamená, protože ten se týkal teoretických mezí
Ani sebelepší typový systém nezajistí, že program bude bez chyby. Teoretické meze neleží v typovém systému nebo kompilátoru, ale ve schopnosti formálně popsat specifikaci. Pak může nastoupit automatické dokazování nebo verifikace, např. Isabelle.
Název: Re:Typový system versus unittesty
Přispěvatel: v 20. 06. 2018, 11:37:58

ad "Ani sebelepší typový systém nezajistí, že program bude bez chyby."
ano, stejně jako ten nejlepší testovací framework, musíte ho taky použít, v obou případech musíte napsat správný typ resp. testy

ad "Teoretické meze neleží v typovém systému nebo kompilátoru, ale ve schopnosti formálně popsat specifikaci."
to nejsou teoretické meze ale praktické - "lidský faktor"

ad "Pak může nastoupit automatické dokazování nebo verifikace, např. Isabelle."
tak kontrola souladu datového typu s programem je formální verfikace a přijde mi pozoruhodné, že jste zmínil Isabelle a ne IMHO mnohem známější Coq
Název: Re:Typový system versus unittesty
Přispěvatel: andy 20. 06. 2018, 11:39:20
tak to není a pro původní dotaz to moc neznamená, protože ten se týkal teoretických mezí
Ani sebelepší typový systém nezajistí, že program bude bez chyby. Teoretické meze neleží v typovém systému nebo kompilátoru, ale ve schopnosti formálně popsat specifikaci. Pak může nastoupit automatické dokazování nebo verifikace, např. Isabelle.
V čem se liší dostatečně silný typový systém od automatického dokazování?
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 20. 06. 2018, 12:32:19
V čem se liší dostatečně silný typový systém od automatického dokazování?
Že typová kontrola může proběhnout až dynamicky za běhu. Automatické dokazování se pokud vím obvykle za běhu neprovádí.
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 20. 06. 2018, 12:41:09
Mám zápis, čitelný pro stroj:
Kód: [Vybrat]
    case s `hasMinimumLen` 4 of
        Just sn -> Str.sub sn 20
        Nothing -> "default"

Ale pro člověka je mnohem lepší zápis:
Kód: [Vybrat]
    if (Str.len s) < 4 then
        "default"
    else
        Str.sub s 20
Co to má být "zápis čitelný pro stroj"? Program v jakémkoli jazyce, který lze zpracovat překladačem? Nebo strojový kód?
Název: Re:Typový system versus unittesty
Přispěvatel: andy 20. 06. 2018, 13:23:36
V čem se liší dostatečně silný typový systém od automatického dokazování?
Že typová kontrola může proběhnout až dynamicky za běhu. Automatické dokazování se pokud vím obvykle za běhu neprovádí.
No.... ne.

Citace
Pierce, TPL: A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.
...
The word “static” is sometimes added explicitly—we speak of a “statically typed programming language,” for example—to distinguish the sorts of compile-time analyses we are considering here from the dynamic or latent typing found in languages such as Scheme, where run-time type tags are used to distinguish different kinds of structures in the heap. Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,” but the usage is standard.
Myslím, že v tomhle bych se o autoritu opřel :)
Název: Re:Typový system versus unittesty
Přispěvatel: andy 20. 06. 2018, 13:26:27
Co to má být "zápis čitelný pro stroj"? Program v jakémkoli jazyce, který lze zpracovat překladačem? Nebo strojový kód?
BoneFlute má na mysli, že v tom prvním případě programátor překladači poskytnul důkaz správnosti typů, v tom druhém případě si ten důkaz počítač našel sám (což je obecně nerozhodnutelný problém).
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 20. 06. 2018, 13:43:46
Co to má být "zápis čitelný pro stroj"? Program v jakémkoli jazyce, který lze zpracovat překladačem? Nebo strojový kód?
BoneFlute má na mysli, že v tom prvním případě programátor překladači poskytnul důkaz správnosti typů, v tom druhém případě si ten důkaz počítač našel sám
Ne tak docela "našel", jako že prostě si řekne, že "if podmínka" aha, to si musím přeložit na  tyhle Maybe typy...

(což je obecně nerozhodnutelný problém)
V jakém smyslu? Buď té konstrukci rozumí, nebo jí odmítne. IMHO nic složitého.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 20. 06. 2018, 13:46:50
Co to má být "zápis čitelný pro stroj"? Program v jakémkoli jazyce, který lze zpracovat překladačem? Nebo strojový kód?
Bavíme se o typech, a v tomto kontextu strojem nazývám kompilátor.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 20. 06. 2018, 14:07:48
V čem se liší dostatečně silný typový systém od automatického dokazování?
Že typová kontrola může proběhnout až dynamicky za běhu. Automatické dokazování se pokud vím obvykle za běhu neprovádí.
No.... ne.

Citace
Pierce, TPL: A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.
...
The word “static” is sometimes added explicitly—we speak of a “statically typed programming language,” for example—to distinguish the sorts of compile-time analyses we are considering here from the dynamic or latent typing found in languages such as Scheme, where run-time type tags are used to distinguish different kinds of structures in the heap. Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,” but the usage is standard.
Myslím, že v tomhle bych se o autoritu opřel :)
OK. Pak ale zase padá spousta argumentů, které tu tahali v a BoneFlute. Padá např. ten odkaz od v o přesunu překladu Haskellu do runtime. Protože to pak říká jenom to, že pomocí LLVM mašinerie se dá z Haskellu udělat “dynamically checked” jazyk.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 20. 06. 2018, 14:12:36
ano, stejně jako ten nejlepší testovací framework, musíte ho taky použít, v obou případech musíte napsat správný typ resp. testy
Máte testy zařazené na špatnou úroveň. Na jedné úrovni jsou typy nebo algoritmy – ty musí být správně, aby program fungoval správně. Pak je volitelná druhá úroveň – můžete napsat testy, které otestují nějaké zajímavé případy. Žádný systém algoritmizace, typů nebo psaní testů nezajistí bezchybnost programu – testy slouží jen ke zvýšení pravděpodobnosti, že chybu odhalíte.

to nejsou teoretické meze ale praktické - "lidský faktor"
Myslel jsem, že se bavíme o tom, co je reálně dosažitelné. Ne že prohlásíme, že program předhodíme nějakému orákulu nebo CML, který nám řekne, zda je správně nebo špatně. No a že takový CML neumíme vytvořit? To je „lidský faktor“…
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 20. 06. 2018, 14:37:09
Myslel jsem, že se bavíme o tom, co je reálně dosažitelné. Ne že prohlásíme, že program předhodíme nějakému orákulu nebo CML, který nám řekne, zda je správně nebo špatně. No a že takový CML neumíme vytvořit? To je „lidský faktor“…
A navrch se těma typama a dokazováním zabýváme právě kvůli tomu lidskému faktoru.
Název: Re:Typový system versus unittesty
Přispěvatel: v 20. 06. 2018, 14:39:09
OK. Pak ale zase padá spousta argumentů, které tu tahali v a BoneFlute. Padá např. ten odkaz od v o přesunu překladu Haskellu do runtime. Protože to pak říká jenom to, že pomocí LLVM mašinerie se dá z Haskellu udělat “dynamically checked” jazyk.
ne, ten článek říká, že jde v haskellu udělat překladač (AOT/JIT nezáleží), který bude pracovat s dočasnou reprezentací (TExp), která má stejné typové garance, jako by to byl kód v haskellu, tj. TExp garantuje, že žádná funkce nad ním (funkce, která je součástí kompilátoru, staticky ověřená při překladu překladače) neudělá blbost typu string + int (nejprovařenější příklad, jde to rozšířit na další vlastnosti) a dále ukazuje, že k takové reprezentaci lze přejít za běhu (proto jsem ten link postnul), což je docela normální, protože překladač dostane zdroják až za běhu, ne při překladu překladače
Název: Re:Typový system versus unittesty
Přispěvatel: andy 20. 06. 2018, 14:56:25
OK. Pak ale zase padá spousta argumentů, které tu tahali v a BoneFlute. Padá např. ten odkaz od v o přesunu překladu Haskellu do runtime. Protože to pak říká jenom to, že pomocí LLVM mašinerie se dá z Haskellu udělat “dynamically checked” jazyk.
Zrovna tu mám projektík, kde se podobnou mašinérii budu snažit vyrobit... ne, ten článek říká něco jiného.

Autor píše "interpret" jazyka. Za tímto účelem si vyrobil Abstrat syntax tree, který je postavený na GADT... což se hezky dá využít k tomu, že v tom stromě nelze sestavit špatně typovaný program (uzel má typ "TExp Bool" - tak ho nejde dát jako potomka "+", který očekává jako parametry "TExp Double"). Při parsingu si vyrobí AST bez typů (takže tam tyhle chybné operace vyjádřit jde) - a ten článek je o tom, jak té netypované reprezentace přejde k té typované.

Je to v podstatě ta otázka o tom sčítání - když bych měl tu funkci
Kód: [Vybrat]
add :: SNat n -> SNat m -> SNat (n + m)
tak je to hezké, ale jak vyrobit tu funkci
Kód: [Vybrat]
toNat :: Int -> SNat n
Kdy ten typ závisí na vstupu od uživatele. No a..ono to nějak jde (někdy)...doufám, že až si to implementuju, tak i pochopím jak...
Název: Re:Typový system versus unittesty
Přispěvatel: andy 20. 06. 2018, 14:59:10
Myslel jsem, že se bavíme o tom, co je reálně dosažitelné. Ne že prohlásíme, že program předhodíme nějakému orákulu nebo CML, který nám řekne, zda je správně nebo špatně. No a že takový CML neumíme vytvořit? To je „lidský faktor“…
To není lidský faktor, to je halting problem....
Název: Re:Typový system versus unittesty
Přispěvatel: v 20. 06. 2018, 15:10:11
Kód: [Vybrat]
toNat :: Int -> SNat n
Kdy ten typ závisí na vstupu od uživatele. No a..ono to nějak jde (někdy)...doufám, že až si to implementuju, tak i pochopím jak...
hint: jestli na to ghc nemá nějaký nový trik, tak budete potřebovat něco jako je v článku "data ATExp = forall a . TExp a ::: TTyp a", já jsem to teda potřeboval (a kdybyste to zvládl bez ATExp tak to sem určitě napište :D )
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 20. 06. 2018, 15:28:20
(ne že by se to nedělalo, ale jde jen o velmi speciální případy v avionice nebo kódu pro jaderné elektrárny apod.).
O tom bych měl něco vědět. Pro které elektrárny konkrétně? A o jaký typ kódu?
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 20. 06. 2018, 15:30:24
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
No tak to bych řekl, že ani náhodou! Nějaké podklady/porovnání by nebyly?
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 20. 06. 2018, 15:39:20
Myslel jsem, že se bavíme o tom, co je reálně dosažitelné. Ne že prohlásíme, že program předhodíme nějakému orákulu nebo CML, který nám řekne, zda je správně nebo špatně. No a že takový CML neumíme vytvořit? To je „lidský faktor“…
To není lidský faktor, to je halting problem....

To neni halting problem.

Uvedom si, ze tomu orakulu nepredhazujes libovolny program, ale program v urcenem formatu s urcenymi omezenimi (v extremnim pripade si muzes predstavit, ze povinnou soucasti programu v danem jazyce je i jeho dukaz).

Samozrejme zdaleka nejsme tam, kde by tohle bylo prakticke. Ale je potreba si uvedomit, ze se to obecnemu halting problemu podoba, ale ta uloha je (resp. muze byt) lehci.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 20. 06. 2018, 22:23:03
Myslel jsem, že se bavíme o tom, co je reálně dosažitelné. Ne že prohlásíme, že program předhodíme nějakému orákulu nebo CML, který nám řekne, zda je správně nebo špatně. No a že takový CML neumíme vytvořit? To je „lidský faktor“…
To není lidský faktor, to je halting problem....

To neni halting problem.

Uvedom si, ze tomu orakulu nepredhazujes libovolny program, ale program v urcenem formatu s urcenymi omezenimi (v extremnim pripade si muzes predstavit, ze povinnou soucasti programu v danem jazyce je i jeho dukaz).
No já reagoval na:
Citace
Myslel jsem, že se bavíme o tom, co je reálně dosažitelné. Ne že prohlásíme, že program předhodíme nějakému orákulu nebo CML, který nám řekne, zda je správně nebo špatně.
Což bych řekl, že o omezení nemluví...
Název: Re:Typový system versus unittesty
Přispěvatel: andy 20. 06. 2018, 22:25:05
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
No tak to bych řekl, že ani náhodou! Nějaké podklady/porovnání by nebyly?
No, neodvažoval bych se něco takového tvrdit, ale faktem je, že programy v Haskellu jsou typicky docela hodně úsporné, takže "ani náhodou" bych se teda neodvažoval tvrdit taky.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 20. 06. 2018, 22:59:02
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
No tak to bych řekl, že ani náhodou! Nějaké podklady/porovnání by nebyly?
Je směšně triviální nahlédnout, že čím silnější typový systém, tím lepší znovupoužitelnost (ve smyslu DRY). V Javě a spol. nejde např. napsat obecná monáda kvůli absenci HKT (v C++ jde). S HKT bez závislostních typů se ale taky brzy narazí a musí se duplikovat. V několika iteracích to je názorně vidět na Swiftu, na začátku bylo v stdlib hodně duplicitního kódu kvůli slabému typovému systému. V poslední verzi (4.2) se kvanta kódu mohla smazat díky podmíněné konformanci a dalším vymoženostem. Až přidají HKT (je to v plánu), stdlib opět zeštíhlí. Tím to asi skončí, protože v 5. verzi už má být (konečně) stabilní ABI, ale i tak je docílená minimalizace kódu úctyhodná (nemluvě o vyšší bezpečnosti).
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 20. 06. 2018, 23:39:14
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
No tak to bych řekl, že ani náhodou! Nějaké podklady/porovnání by nebyly?
Je směšně triviální nahlédnout, že čím silnější typový systém, tím lepší znovupoužitelnost (ve smyslu DRY). V Javě a spol. nejde např. napsat obecná monáda kvůli absenci HKT (v C++ jde). S HKT bez závislostních typů se ale taky brzy narazí a musí se duplikovat. V několika iteracích to je názorně vidět na Swiftu, na začátku bylo v stdlib hodně duplicitního kódu kvůli slabému typovému systému. V poslední verzi (4.2) se kvanta kódu mohla smazat díky podmíněné konformanci a dalším vymoženostem. Až přidají HKT (je to v plánu), stdlib opět zeštíhlí. Tím to asi skončí, protože v 5. verzi už má být (konečně) stabilní ABI, ale i tak je docílená minimalizace kódu úctyhodná (nemluvě o vyšší bezpečnosti).
Ale já myslel nějaké konkrétní příklady v porovnání s dynamickými jazyky, ne s Javou. Že vymakaný typový systém zjednoduší program oproti neohrabanému jako je třeba v Javě, o tom bych se asi nepřel. Ale ten samý efekt vidím i u dynamických jazyků. Jenže zatímco takový Lisp nebo Smalltalk jsou směšně jednoduché, tak třeba ten Haskell mi vždycky připadal jako poměrně složitý.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 21. 06. 2018, 00:07:09
Ale já myslel nějaké konkrétní příklady v porovnání s dynamickými jazyky, ne s Javou.
Tohle možná půjde díky širokým knihovnám v některých dynamických jazycích, ale typicky to bývá dost problém... setřiď lidi sestupně podle věku, vzestupně podle příjmení - využívá typeclass Monoid a "rekurzivní" instance.
Kód: [Vybrat]
sortBy (flip (comparing age) <> comparing surname)

Monady - callback hell - JS vs. PureScript (nový JS na to má "await", takže tam už ten rozdíl není tak velký).

Polymorfní v návratové hodnotě - parsing JSONu. Tenhle kód provede kontrolu - nahlásí chybu, pokud vstupní data neobsahují položky s korektním typem. Dekóduje čas ve stringu na odpovídající typ, se kterým se dá normálně pracovat (UTCTime je něco jako "new Date()").

Vysvětlení: operátor ".:" je polymorfní v návratové hodnotě, takže hledá v objektu ten typ, který je požadován. Celé to běží v Parser monadu, takže v případě chyby se to celkem rozumně reportuje. Operátor <|> je "nebo" a funguje podobně jako "try...catch", dá se hezky řetězit.

Kód: [Vybrat]
data Person = Person Text Double UTCTime
instance FromJSON Person where
  parseJSON = withObject "person" $ \o -> do
    jmeno <- o .: "name" <|> o .: "jmeno"
    vyska <- o .: "height" <|> o .: "vyska"
    narozeni <- o .: "birthdate" <|> o .: "narozeni"
    return (Person jmeno vyska narozeni)

IMO kód v dynamických jazycích může být kratší, protože třeba v případě toho parsingu by se člověk prostě vybodnul na kontrolu korektního vstupu... v některých jaycích a knihovnách to ještě nějak relativně dobře funguje přes generic parsing, ale jak do toho člověk potřebuje trochu víc hrábnout (zpětná kompatibilita apod.), tak už ten kód hodně roste a je dost nepřehledný.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 00:35:33
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
No tak to bych řekl, že ani náhodou! Nějaké podklady/porovnání by nebyly?
Je směšně triviální nahlédnout, že čím silnější typový systém, tím lepší znovupoužitelnost (ve smyslu DRY). V Javě a spol. nejde např. napsat obecná monáda kvůli absenci HKT (v C++ jde). S HKT bez závislostních typů se ale taky brzy narazí a musí se duplikovat. V několika iteracích to je názorně vidět na Swiftu, na začátku bylo v stdlib hodně duplicitního kódu kvůli slabému typovému systému. V poslední verzi (4.2) se kvanta kódu mohla smazat díky podmíněné konformanci a dalším vymoženostem. Až přidají HKT (je to v plánu), stdlib opět zeštíhlí. Tím to asi skončí, protože v 5. verzi už má být (konečně) stabilní ABI, ale i tak je docílená minimalizace kódu úctyhodná (nemluvě o vyšší bezpečnosti).
Ale já myslel nějaké konkrétní příklady v porovnání s dynamickými jazyky, ne s Javou. Že vymakaný typový systém zjednoduší program oproti neohrabanému jako je třeba v Javě, o tom bych se asi nepřel. Ale ten samý efekt vidím i u dynamických jazyků. Jenže zatímco takový Lisp nebo Smalltalk jsou směšně jednoduché, tak třeba ten Haskell mi vždycky připadal jako poměrně složitý.
U dynamických jazyků to vyjde nastejno, akorát člověk nemá tu typovou kontrolu. Přínos mocných typových systémů je právě v tom, že při plné typové kontrole umožňuje značnou flexibilitu (“dynamičnost”). Jinak Haskell složitý není, jen jiný - matoucí je možná syntax.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 21. 06. 2018, 07:27:26
IMO kód v dynamických jazycích může být kratší, protože třeba v případě toho parsingu by se člověk prostě vybodnul na kontrolu korektního vstupu...
Byl bych velmi opatrný s tvrzením, že kratší kód se automaticky rovná lepší kód. Vy jste napsal konkrétní případ, kdy je kód kratší ale jiný, ale ani kratší kód, který dělá přesně to samé, jako delší kód, nemusí být lepší.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 08:25:30
Že vymakaný typový systém zjednoduší program oproti neohrabanému jako je třeba v Javě, o tom bych se asi nepřel. Ale ten samý efekt vidím i u dynamických jazyků.
někdo tvrdí, že pokud máte dostatečné pokrytí testy, tak nepotřebujete statický typový systém - myslíte, že by ten efekt nezmizel kdybychom započítali i testy? přece jenom typy umožňují množinu možných testcasů dost zmenšit
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 11:20:46
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.

Nechci spekulovat, ale jednoduchá úvaha, že když netypový systém otypuju, tj. omezím jej, dosáhnu tak větší znovupoužitelnosti, neboli obecnosti, mi nedává smysl.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 11:24:51
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
Nechci spekulovat, ale jednoduchá úvaha, že když netypový systém otypuju, tj. omezím jej, dosáhnu tak větší znovupoužitelnosti, neboli obecnosti, mi nedává smysl.
Co je “netypový systém”? Dynamické typování je netypové nebo ne? Jinak znovupoužitelnost nesouvisí s obecností.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 11:32:14
někdo tvrdí, že pokud máte dostatečné pokrytí testy, tak nepotřebujete statický typový systém - myslíte, že by ten efekt nezmizel kdybychom započítali i testy? přece jenom typy umožňují množinu možných testcasů dost zmenšit

Pozor, další myšlenka:

Opačně: Neobsahuje v sobě každý test z podstaty "typovou" kontrolu? Neboli vkládám-li na vstup diskrétní hodnoty a testuju-li výstupní diskrétní hodnoty (přísnější podmínka), netestuju zároveň i kategorii těch hodnot (volnější podmínka)?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 11:38:11
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
Nechci spekulovat, ale jednoduchá úvaha, že když netypový systém otypuju, tj. omezím jej, dosáhnu tak větší znovupoužitelnosti, neboli obecnosti, mi nedává smysl.
Co je “netypový systém”? Dynamické typování je netypové nebo ne? Jinak znovupoužitelnost nesouvisí s obecností.

Navíc je nutné rozlišit slabé typování od dynamického.

Dynamické typování je také typové. Rozdíl je jen v tom, že typ si nese jako atribut.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 11:44:33
Nechci spekulovat, ale jednoduchá úvaha, že když netypový systém otypuju, tj. omezím jej, dosáhnu tak větší znovupoužitelnosti, neboli obecnosti, mi nedává smysl.
Co je “netypový systém”? Dynamické typování je netypové nebo ne?

Netypový systém je systém bez typů (odvolávám se na Smalltalk, když už se tu šermuje Haskellem), dynamicky typovaný systém (https://en.wikipedia.org/wiki/Type_system#Dynamic_type_checking_and_runtime_type_information) typy obsahuje a testuje.

Jinak znovupoužitelnost nesouvisí s obecností.

Opravdu? Třeba se pletu. Nadhoďte příklad (ale prosím v nějaké profláklejší notaci než Haskellu).
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 11:51:11
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.

Naopak silný typový systém zvyšuje délku kódu a snižuje znovupoužitelnost. Pokud mi typový systém nedovolí vložit int místo float nebo float místo double, musím to v kódu nějak obejít, což jej prodlouží.

Bavíme se o silně nabo staticky typovaném systému?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:03:04
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
Naopak silný typový systém zvyšuje délku kódu a snižuje znovupoužitelnost. Pokud mi typový systém nedovolí vložit int místo float nebo float místo double, musím to v kódu nějak obejít, což jej prodlouží.
To rozhodně ne, jak implicitní type cast prodlouží kód? Je třeba mít na paměti, že v jazycích s kontrolou typů v době překladu je tendence redukovat explicitní deklaraci typů. Logicky nikdo se nechce párat s psaním zbytečného kódu, ale chce vyzobat rozinky přísné a včasné typové kontroly. V běžných jazycích (OO i funkcionálních) se většina typů odvozuje (dedukuje). V kombinaci s rozhraními se použití dobře navržené knihovny obejde bez explicitních deklarací typů. V takovém C++ můžu mít téměř všude auto, včetně deklarací funkcí.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:04:26
Nechci spekulovat, ale jednoduchá úvaha, že když netypový systém otypuju, tj. omezím jej, dosáhnu tak větší znovupoužitelnosti, neboli obecnosti, mi nedává smysl.
Co je “netypový systém”? Dynamické typování je netypové nebo ne?
Netypový systém je systém bez typů (odvolávám se na Smalltalk, když už se tu šermuje Haskellem)
Smalltalk ale typy má.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 12:05:32
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.

Naopak silný typový systém zvyšuje délku kódu a snižuje znovupoužitelnost. Pokud mi typový systém nedovolí vložit int místo float nebo float místo double, musím to v kódu nějak obejít, což jej prodlouží.

Bavíme se o silně nabo staticky typovaném systému?
nechá http://hackage.haskell.org/package/base-4.11.1.0/docs/Prelude.html#t:Num
IMHO silně a staticky
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:09:10
Jinak znovupoužitelnost nesouvisí s obecností.
Opravdu? Třeba se pletu.
Možná jde jen o slovíčkaření. Už tu byl uveden příklad Swiftu. Ve verzi 4.2 se silnějším typovým systémem se z stdlib smazalo hodně duplicitního kódu (specializací generik), který byl nahrazen jednou implementací pro mnoho typů (se společným protokolem). Obecnějšími se ty typy ovšem nestaly.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 12:17:59
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
Naopak silný typový systém zvyšuje délku kódu a snižuje znovupoužitelnost. Pokud mi typový systém nedovolí vložit int místo float nebo float místo double, musím to v kódu nějak obejít, což jej prodlouží.
To rozhodně ne, jak implicitní type cast prodlouží kód? Je třeba mít na paměti, že v jazycích s kontrolou typů v době překladu je tendence redukovat explicitní deklaraci typů. Logicky nikdo se nechce párat s psaním zbytečného kódu, ale chce vyzobat rozinky přísné a včasné typové kontroly. V běžných jazycích (OO i funkcionálních) se většina typů odvozuje (dedukuje). V kombinaci s rozhraními se použití dobře navržené knihovny obejde bez explicitních deklarací typů. V takovém C++ můžu mít téměř všude auto, včetně deklarací funkcí.

Tím, že jsem nucen používat explicitní typování tam, kde bych přetypovávat nemusel. Nemohu jednou funkcí sčítat int, float a spojovat stringy. Musím mít tři funkce.

Také si potřebné typy musím nadefinovat, jinak deklarace funkcí vypadají takhle:
Kód: [Vybrat]
circumference :: Float -> Float 
circumference r = 2 * pi * r
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 12:20:34
někdo tvrdí, že pokud máte dostatečné pokrytí testy, tak nepotřebujete statický typový systém - myslíte, že by ten efekt nezmizel kdybychom započítali i testy? přece jenom typy umožňují množinu možných testcasů dost zmenšit

Pozor, další myšlenka:

Opačně: Neobsahuje v sobě každý test z podstaty "typovou" kontrolu? Neboli vkládám-li na vstup diskrétní hodnoty a testuju-li výstupní diskrétní hodnoty (přísnější podmínka), netestuju zároveň i kategorii těch hodnot (volnější podmínka)?
furt je ten test jenom pro jednu volbu typů argumentů, u dynamického jazyka je možných voleb spousta
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:21:26
Ještě tu nezaznělo, že kromě vyšší bezpečnosti přináší silný typový systém také úsporu kódu díky větší znovupoužitelnosti. To jen tak pro úplnost.
Naopak silný typový systém zvyšuje délku kódu a snižuje znovupoužitelnost. Pokud mi typový systém nedovolí vložit int místo float nebo float místo double, musím to v kódu nějak obejít, což jej prodlouží.
To rozhodně ne, jak implicitní type cast prodlouží kód? Je třeba mít na paměti, že v jazycích s kontrolou typů v době překladu je tendence redukovat explicitní deklaraci typů. Logicky nikdo se nechce párat s psaním zbytečného kódu, ale chce vyzobat rozinky přísné a včasné typové kontroly. V běžných jazycích (OO i funkcionálních) se většina typů odvozuje (dedukuje). V kombinaci s rozhraními se použití dobře navržené knihovny obejde bez explicitních deklarací typů. V takovém C++ můžu mít téměř všude auto, včetně deklarací funkcí.

Tím, že jsem nucen používat explicitní typování tam, kde bych přetypovávat nemusel. Nemohu jednou funkcí sčítat int, float a spojovat stringy. Musím mít tři funkce.

Také si potřebné typy musím nadefinovat, jinak deklarace funkcí vypadají takhle:
Kód: [Vybrat]
circumference :: Float -> Float 
circumference r = 2 * pi * r
Doporučuju přečíst si to ještě jednou a zamyslet se. Implicitní type cast obchází explicitní typování. Neboli prodloužení kódu se nekoná.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:24:57
Jenže zatímco takový Lisp nebo Smalltalk jsou směšně jednoduché
Možná proto ono tvrzení, že každý reálně použitelný jazyk konverguje k Lispu :)
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:29:20
Je poučné podívat se, jak zachází C++ nebo Swift s callbacky. Můžu mít třeba

Kód: [Vybrat]
let request = ...
request.perform { response, error in ... }

Tedy vše bez explicitního uvádění typů a zároveň s plnou kontrolou v době překladu. V podstatě to vypadá jako v dynamicky typovaném jazyce. V C++ to dotáhli ještě dál. Prostě vzhled/zápis kódu ani v nejmenším nevypovídá nic o charakteru jazyka vzhledem k jeho typovému systému.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 12:38:47
Tím, že jsem nucen používat explicitní typování tam, kde bych přetypovávat nemusel. Nemohu jednou funkcí sčítat int, float a spojovat stringy. Musím mít tři funkce.
Doporučuju přečíst si to ještě jednou a zamyslet se. Implicitní type cast obchází explicitní typování. Neboli prodloužení kódu se nekoná.

Jenže s implicitním typováním si vystačím jen u primitivních funkcí. Jakmile budu vytvářet cokoli složitějšího, musím si nadefinovat vlastní typy.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 12:47:24
Jenže zatímco takový Lisp nebo Smalltalk jsou směšně jednoduché
Možná proto ono tvrzení, že každý reálně použitelný jazyk konverguje k Lispu :)

Otázkou tedy je, proč místo Lispu používáme náhražky :)
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 12:50:33
To rozhodně ne, jak implicitní type cast prodlouží kód?

Tohle zrovna není dobrý příklad silného typového systému, spíš ojebávky (nehledě na to, že je to obecně problematický mechanismus). Zkuste jiný příklad zvýšení znovupoužitelnosti posílením typového systému, ať se tu nemusíme hádat.

Je třeba mít na paměti, že v jazycích s kontrolou typů v době překladu je tendence redukovat explicitní deklaraci typů. Logicky nikdo se nechce párat s psaním zbytečného kódu, ale chce vyzobat rozinky přísné a včasné typové kontroly. V běžných jazycích (OO i funkcionálních) se většina typů odvozuje (dedukuje). V kombinaci s rozhraními se použití dobře navržené knihovny obejde bez explicitních deklarací typů. V takovém C++ můžu mít téměř všude auto, včetně deklarací funkcí.

Jestli máte na mysli psaní "var" např. v Jávce, tak to je triviální dovození typu, kdy není pochyby. V jazycích OO (skutečných, ne imperativních hybridech) je komunikace místo voláním funkcí řešeno posíláním zpráv obsahujících selektor metody, takže typový systém by tu k ničemu nebyl, není co odvozovat!
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 12:52:50
Smalltalk ale typy má.

Nemá. Jestli s tím máte problém, zkuste si představit javascriptové objekty ad-hoc.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:56:08
Jenže zatímco takový Lisp nebo Smalltalk jsou směšně jednoduché
Možná proto ono tvrzení, že každý reálně použitelný jazyk konverguje k Lispu :)
Otázkou tedy je, proč místo Lispu používáme náhražky :)
Alergie na závorky? ;)
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:57:13
Tím, že jsem nucen používat explicitní typování tam, kde bych přetypovávat nemusel. Nemohu jednou funkcí sčítat int, float a spojovat stringy. Musím mít tři funkce.
Doporučuju přečíst si to ještě jednou a zamyslet se. Implicitní type cast obchází explicitní typování. Neboli prodloužení kódu se nekoná.
Jenže s implicitním typováním si vystačím jen u primitivních funkcí. Jakmile budu vytvářet cokoli složitějšího, musím si nadefinovat vlastní typy.
To je právě omyl. Z nějakého nepochopitelného důvodu evidentně rozšířený.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 12:58:23
Možná jde jen o slovíčkaření. Už tu byl uveden příklad Swiftu. Ve verzi 4.2 se silnějším typovým systémem se z stdlib smazalo hodně duplicitního kódu (specializací generik), který byl nahrazen jednou implementací pro mnoho typů (se společným protokolem). Obecnějšími se ty typy ovšem nestaly.

Supr. Tak teď ještě vykopejte ty "generika" (tj. zobecněný typovací systém) a ponechejte to netypové, a bude to (logicky) maximálně stejně velké, možná taky poloviční.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 12:59:17
Zkuste jiný příklad zvýšení znovupoužitelnosti posílením typového systému, ať se tu nemusíme hádat.
Už nejméně dvakrát jsem ho uváděl: podmíněná konformance. Vlastně třikrát. Stačí letmo mrknout na Swift.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 12:59:24
Jenže zatímco takový Lisp nebo Smalltalk jsou směšně jednoduché
Možná proto ono tvrzení, že každý reálně použitelný jazyk konverguje k Lispu :)

Otázkou tedy je, proč místo Lispu používáme náhražky :)
časy se mění, lisp vznikl ve stejné době jako projekt použití jaderných zbraní na stavební práce
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 13:05:18
Pozor, další myšlenka:

Opačně: Neobsahuje v sobě každý test z podstaty "typovou" kontrolu? Neboli vkládám-li na vstup diskrétní hodnoty a testuju-li výstupní diskrétní hodnoty (přísnější podmínka), netestuju zároveň i kategorii těch hodnot (volnější podmínka)?
furt je ten test jenom pro jednu volbu typů argumentů, u dynamického jazyka je možných voleb spousta

To je právě ten problém - testování kategorií hodnot ještě neznamená správnost kombinací jejich hodnot.
Takže se shodneme, že oba systémy jsou (to se ale dalo čekat) neúplné.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 13:06:27
Možná proto ono tvrzení, že každý reálně použitelný jazyk konverguje k Lispu :)

Opět nepodložené tvrzení. Doložte to.
Název: Re:Typový system versus unittesty
Přispěvatel: jdusizasvym 21. 06. 2018, 13:08:36
Unit testy jsem nikdy neřešil, vždy si vše testuji sám vlastním systémem, že si vytvořím testovací třídu, která testuje veškeré elementární objekty (třídy, funkce), kdy ověřuji, zda na zadaný vstup leze zadaný výstup. Systém téměř debuggovat nemusím a pokud systém vykazuje chybu, vím hned, kde konkrétně je.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 13:10:24
Pozor, další myšlenka:

Opačně: Neobsahuje v sobě každý test z podstaty "typovou" kontrolu? Neboli vkládám-li na vstup diskrétní hodnoty a testuju-li výstupní diskrétní hodnoty (přísnější podmínka), netestuju zároveň i kategorii těch hodnot (volnější podmínka)?
furt je ten test jenom pro jednu volbu typů argumentů, u dynamického jazyka je možných voleb spousta

To je právě ten problém - testování kategorií hodnot ještě neznamená správnost kombinací jejich hodnot.
Takže se shodneme, že oba systémy jsou (to se ale dalo čekat) neúplné.
asi nevím co je "kategorie hodnot"
se statickým typovým systémem můžete u některých funkcí dosáhnout vyčerpávajícího testování, u dynamického asi nikdy
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 13:15:23
testování kategorií hodnot
asi nevím co je "kategorie hodnot"
[/quote]
chytil jsem se do pasti?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 13:18:03
Diskuse se poněkud odklonila od původního tématu. Jako obvykle "type haters" nekriticky prosazují "čisté OOP". Přitom flexibilní (smalltalkovské) posílání zpráv a mocný typový systém s kontrolou v době překladu se ani v nejmenším nevylučují. Malý kvíz: který "čistě OO" jazyk má generika, varianci typů (to nemá ani C++ nebo Swift) a typovou kontrolu při překladu?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 13:19:20
Pozor, další myšlenka:

Opačně: Neobsahuje v sobě každý test z podstaty "typovou" kontrolu? Neboli vkládám-li na vstup diskrétní hodnoty a testuju-li výstupní diskrétní hodnoty (přísnější podmínka), netestuju zároveň i kategorii těch hodnot (volnější podmínka)?
furt je ten test jenom pro jednu volbu typů argumentů, u dynamického jazyka je možných voleb spousta

To je právě ten problém - testování kategorií hodnot ještě neznamená správnost kombinací jejich hodnot.
Takže se shodneme, že oba systémy jsou (to se ale dalo čekat) neúplné.
asi nevím co je "kategorie hodnot"
Kategorie je taková ta blbost s morfismama a funktorama a dalšíma fuj věcma :)
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 13:27:31
Už nejméně dvakrát jsem ho uváděl: podmíněná konformance. Vlastně třikrát. Stačí letmo mrknout na Swift.

Tohle https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md) je ono? Dopracováváme se zpět k myšlence, že dokonalý typový systém možná existuje, ale určitě je složitý jak prase? Tak to soráč květináč, ale to si radši nechám ten netypovaný systém s jednotkovými testy.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 13:29:40
Diskuse se poněkud odklonila od původního tématu. Jako obvykle "type haters" nekriticky prosazují "čisté OOP". Přitom flexibilní (smalltalkovské) posílání zpráv a mocný typový systém s kontrolou v době překladu se ani v nejmenším nevylučují. Malý kvíz: který "čistě OO" jazyk má generika, varianci typů (to nemá ani C++ nebo Swift) a typovou kontrolu při překladu?

Který "čistě OO" jazyk potřebuje generika, varianci typů a typovou kontrolu při překladu?
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 13:30:54
Unit testy jsem nikdy neřešil, vždy si vše testuji sám vlastním systémem, že si vytvořím testovací třídu, která testuje veškeré elementární objekty (třídy, funkce), kdy ověřuji, zda na zadaný vstup leze zadaný výstup. Systém téměř debuggovat nemusím a pokud systém vykazuje chybu, vím hned, kde konkrétně je.

Supr! A teď si zkuste tipnout, jak se tomu, co jste vytvořil, říká.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 13:32:53
asi nevím co je "kategorie hodnot"
se statickým typovým systémem můžete u některých funkcí dosáhnout vyčerpávajícího testování, u dynamického asi nikdy

To je jiný název pro typy.

To se tu právě řeší.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 13:44:24
Už nejméně dvakrát jsem ho uváděl: podmíněná konformance. Vlastně třikrát. Stačí letmo mrknout na Swift.

Tohle https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md) je ono? Dopracováváme se zpět k myšlence, že dokonalý typový systém možná existuje, ale určitě je složitý jak prase?
Co je na tom složitého? Naopak když budu psát nějakou generickou kolekci, tak si ušetřím psaní kódu. DRY se tomu říká. Jestli pro někoho psaní méně kódu znamená vyšší složitost, tak asi nemá cenu dál diskutovat, jedem das seine.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 13:45:02
Už nejméně dvakrát jsem ho uváděl: podmíněná konformance. Vlastně třikrát. Stačí letmo mrknout na Swift.

Tohle https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md) je ono? Dopracováváme se zpět k myšlence, že dokonalý typový systém možná existuje, ale určitě je složitý jak prase? Tak to soráč květináč, ale to si radši nechám ten netypovaný systém s jednotkovými testy.
co je na tom tak složitého?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 13:46:55
Už nejméně dvakrát jsem ho uváděl: podmíněná konformance. Vlastně třikrát. Stačí letmo mrknout na Swift.
Tohle https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md) je ono? Dopracováváme se zpět k myšlence, že dokonalý typový systém možná existuje, ale určitě je složitý jak prase? Tak to soráč květináč, ale to si radši nechám ten netypovaný systém s jednotkovými testy.
co je na tom tak složitého?
Asi je pro někoho obtížné to pochopit. Což nechápu proč, ale i mimo IT někteří preferují dělat věci složitě, i když to jde jednoduše a s menší námahou. Holt svět není dokonalý.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 13:49:01
Asi je pro někoho obtížné to pochopit. Což nechápu proč, ale i mimo IT někteří preferují dělat věci složitě, i když to jde jednoduše a s menší námahou. Holt svět není dokonalý.

Přesně! Přesně to samé si myslím o vás.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 13:49:50
Malý kvíz: který "čistě OO" jazyk má generika, varianci typů (to nemá ani C++ nebo Swift) a typovou kontrolu při překladu?

Nenapínejte nás.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 13:51:09
Asi je pro někoho obtížné to pochopit. Což nechápu proč, ale i mimo IT někteří preferují dělat věci složitě, i když to jde jednoduše a s menší námahou. Holt svět není dokonalý.

Přesně! Přesně to samé si myslím o vás.
tohle je zajímavý moment
Název: Re:Typový system versus unittesty
Přispěvatel: jdusizasvym 21. 06. 2018, 13:53:03
Unit testy jsem nikdy neřešil, vždy si vše testuji sám vlastním systémem, že si vytvořím testovací třídu, která testuje veškeré elementární objekty (třídy, funkce), kdy ověřuji, zda na zadaný vstup leze zadaný výstup. Systém téměř debuggovat nemusím a pokud systém vykazuje chybu, vím hned, kde konkrétně je.

Supr! A teď si zkuste tipnout, jak se tomu, co jste vytvořil, říká.

Komparační test elementárních funkcí. Nebo také elementární test.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 13:53:55
Asi je pro někoho obtížné to pochopit. Což nechápu proč, ale i mimo IT někteří preferují dělat věci složitě, i když to jde jednoduše a s menší námahou. Holt svět není dokonalý.
Přesně! Přesně to samé si myslím o vás.
tohle je zajímavý moment
Ano, konečně i v tomto vlákně došlo na ad hominem :)
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 14:01:52
Asi je pro někoho obtížné to pochopit. Což nechápu proč, ale i mimo IT někteří preferují dělat věci složitě, i když to jde jednoduše a s menší námahou. Holt svět není dokonalý.
Přesně! Přesně to samé si myslím o vás.
tohle je zajímavý moment
Ano, konečně i v tomto vlákně došlo na ad hominem :)
je dobře, že si svůj prohřešek uvědomujete, teď zpět k věcné debatě :)
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:08:41
Asi je pro někoho obtížné to pochopit. Což nechápu proč, ale i mimo IT někteří preferují dělat věci složitě, i když to jde jednoduše a s menší námahou. Holt svět není dokonalý.
Přesně! Přesně to samé si myslím o vás.
tohle je zajímavý moment
Ano, konečně i v tomto vlákně došlo na ad hominem :)
teď zpět k věcné debatě :)
Ano, teď se čeká, až SB a Kit dodají důkazy svých tvrzení. Trochu to začíná připomínat debatu Čada vs. Virius, kde prvně jmenovaný přestal se snahou dokládat svá uhozená tvrzení.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 14:13:23
Ano, teď se čeká, až SB a Kit dodají důkazy svých tvrzení. Trochu to začíná připomínat debatu Čada vs. Virius, kde prvně jmenovaný přestal se snahou dokládat svá uhozená tvrzení.

Které z mých tvrzení potřebuješ doložit?
Název: Re:Typový system versus unittesty
Přispěvatel: andy 21. 06. 2018, 14:15:21
Nechci spekulovat, ale jednoduchá úvaha, že když netypový systém otypuju, tj. omezím jej, dosáhnu tak větší znovupoužitelnosti, neboli obecnosti, mi nedává smysl.
Pokud otypuju netypový jazyk (třeba ve stylu TypeScript), tak ne. Zajímavé to začne být, jakmile je schopen překladač na základě těch typů něco rozhodovat. Zářným případem je právě polymorfismus na základě návratové hodnoty. To prostě nejde s "vtable"-like jazyky rozumně udělat, přitom pokud má překladač k dispozici informace o typech, tak je pro něj celkem jednoduché vybrat tu "správnou" funkci (nebo i konstantu).

Ona teda i ta typová kontrola vede k vyšší jednoduchosti kódu, protože prostě nemusím spoustu věcí kontrolovat - a vím, že je nemusím kontrolovat a nic se nestane (překladač to garantuje). Ono stačí se podívat na to jak fungují Promisy v JS a zkusit si představit, že by podobný protokol měl být naprosto běžný pro spoustu jiných situací.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:16:46
Ano, teď se čeká, až SB a Kit dodají důkazy svých tvrzení. Trochu to začíná připomínat debatu Čada vs. Virius, kde prvně jmenovaný přestal se snahou dokládat svá uhozená tvrzení.
Které z mých tvrzení potřebuješ doložit?
Třeba toto: "Jenže s implicitním typováním si vystačím jen u primitivních funkcí. Jakmile budu vytvářet cokoli složitějšího, musím si nadefinovat vlastní typy." Ani ne doložit, spíš objasnit. Implicitní typování nevylučuje vlastní typy, takže můžeme zůstat u první věty.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 14:24:37
Implicitní typování
co to vlastně je? implicitní přetypování? jako "implicit type cast"/"implicit type conversion"?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 14:26:22
Které z mých tvrzení potřebuješ doložit?
Třeba toto: "Jenže s implicitním typováním si vystačím jen u primitivních funkcí. Jakmile budu vytvářet cokoli složitějšího, musím si nadefinovat vlastní typy." Ani ne doložit, spíš objasnit. Implicitní typování nevylučuje vlastní typy, takže můžeme zůstat u první věty.

Měl jsem za to, že signatury funkcí jsou například v Haskellu povinné nebo přinejmenším doporučené.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:27:32
Jinak čistě pragmaticky - v případě Swiftu proběhla diskuse, jestli podporovat HKT, protože "jsou moc složité a málokdo jim rozumí" (což je určitě pravda). Úplně stejnou věc debatovali tvůrci Rustu ("skoro nikdo to není schopen pochopit, takže se to nebude používat"). Haskellisti si tuto otázku nějak moc nekladli, pročež má teď Haskell nálepku esoterického a akademického jazyka, protože naučit se jej nad rámec povrchního seznámení se syntaxí zvládne jen zlomek lidí, co se považují za programátory (i když určitě by to dalo 100% teoretických fyziků například). V tomto vlákně se opět manifestuje staré známé "nejsem-li něco schopen pochopit, je to k ničemu". Aneb na co používat bagr, když mám lopatu...
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:28:36
Které z mých tvrzení potřebuješ doložit?
Třeba toto: "Jenže s implicitním typováním si vystačím jen u primitivních funkcí. Jakmile budu vytvářet cokoli složitějšího, musím si nadefinovat vlastní typy." Ani ne doložit, spíš objasnit. Implicitní typování nevylučuje vlastní typy, takže můžeme zůstat u první věty.

Měl jsem za to, že signatury funkcí jsou například v Haskellu povinné nebo přinejmenším doporučené.
nejsou povinné
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:30:33
Implicitní typování
co to vlastně je? implicitní přetypování? jako "implicit type cast"/"implicit type conversion"?
Ne, jde o deklarace. Nezná-li někdo definici, Google napoví ("implicit typing").
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 14:37:17
Ano, teď se čeká, až SB a Kit dodají důkazy svých tvrzení...

Které tvrzení potřebujete dokázat ode mě?
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 14:41:15
Měl jsem za to, že signatury funkcí jsou například v Haskellu povinné nebo přinejmenším doporučené.
povinné nejsou, jsou nutné u některých zvláštních případů (co vím tak teba pattern matching na některých GADTs) a silně se doporučují u funkcí exportovaných z modulu
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 14:41:49
Implicitní typování
co to vlastně je? implicitní přetypování? jako "implicit type cast"/"implicit type conversion"?
Ne, jde o deklarace. Nezná-li někdo definici, Google napoví ("implicit typing").
děkuji
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:48:51
Implicitní typování
co to vlastně je? implicitní přetypování? jako "implicit type cast"/"implicit type conversion"?
Ne, jde o deklarace. Nezná-li někdo definici, Google napoví ("implicit typing").
děkuji
Není samozřejmě zač. Jinak implicitní přetypování (nebo jen typová aserce) se toho také výslovně týká. Nicméně pořád zůstává, že dynamické typování a kontrola typů při překladu se nijak nevylučují. Na druhou stranu je-li k dispozici ta aserce, nepotřebuju "čistý" OO runtime, protože obecně čím pozdnější vazba, tím hůře (krom oprávněných případů pochopitelně, těch je ale jak šafránu). Někdy mám pocit, že lidi zkazilo C++ a dorazila to Java.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:50:32
Měl jsem za to, že signatury funkcí jsou například v Haskellu povinné nebo přinejmenším doporučené.
silně se doporučují u funkcí exportovaných z modulu
To mi přijde jako samozřejmé, protože jsou součástí dokumentace. Ale možná jsem jen v tomto ohledu naivní a programátoři nad sebou potřebují bič 24/7...
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:50:58
Ano, teď se čeká, až SB a Kit dodají důkazy svých tvrzení...
Které tvrzení potřebujete dokázat ode mě?
Radši nic.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 21. 06. 2018, 14:51:41
Jinak čistě pragmaticky - v případě Swiftu proběhla diskuse, jestli podporovat HKT, protože "jsou moc složité a málokdo jim rozumí" (což je určitě pravda). Úplně stejnou věc debatovali tvůrci Rustu ("skoro nikdo to není schopen pochopit, takže se to nebude používat"). Haskellisti si tuto otázku nějak moc nekladli, pročež má teď Haskell nálepku esoterického a akademického jazyka, protože naučit se jej nad rámec povrchního seznámení se syntaxí zvládne jen zlomek lidí, co se považují za programátory (i když určitě by to dalo 100% teoretických fyziků například). V tomto vlákně se opět manifestuje staré známé "nejsem-li něco schopen pochopit, je to k ničemu". Aneb na co používat bagr, když mám lopatu...
No tak nemusím být ani nijak zvlášť inteligentní. Tak tomu prostě dám pár hodin navíc no.

Pamatuju si, jak jsem kolegovi vysvětloval, proč je jako docela fajn v konstruktoru testovat vstupní hodnoty; že jinak to balit do třídy nemá smysl. Strašně se kroutil. Je docela chytrý, ale celou svou inteligenci vyčerpal na to, aby mi dokázalmě uhádal, že to tak není.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:53:56
Jinak čistě pragmaticky - v případě Swiftu proběhla diskuse, jestli podporovat HKT, protože "jsou moc složité a málokdo jim rozumí" (což je určitě pravda). Úplně stejnou věc debatovali tvůrci Rustu ("skoro nikdo to není schopen pochopit, takže se to nebude používat"). Haskellisti si tuto otázku nějak moc nekladli, pročež má teď Haskell nálepku esoterického a akademického jazyka, protože naučit se jej nad rámec povrchního seznámení se syntaxí zvládne jen zlomek lidí, co se považují za programátory (i když určitě by to dalo 100% teoretických fyziků například). V tomto vlákně se opět manifestuje staré známé "nejsem-li něco schopen pochopit, je to k ničemu". Aneb na co používat bagr, když mám lopatu...
No tak nemusím být ani nijak zvlášť inteligentní. Tak tomu prostě dám pár hodin navíc no.
Jen jsem volně citoval, nicméně asi skutečně existují lidé, co nechápou třeba jen funkce vyššího řádu. A i ti píšou komerční kód.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 14:58:03
[...]
P.S. Jinak to není jen v IT, divil byste se, jak málo lidí je schopno pochopit například podvojné účetnictví.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 21. 06. 2018, 14:58:26
Jen jsem volně citoval, nicméně asi skutečně existují lidé, co nechápou třeba jen funkce vyššího řádu. A i ti píšou komerční kód.
Tak to nechápou no. Tak přijde senior, řekne jim - to je tak a tak, voni na to - hmm, pomaleji... Zkusí to na malém příkladu, vyzkouší na části projektu, po pěti aplikacích (toho konceptu) budou tvrdit, že to znali vždycky.

Chci říct, samozřejmě souhlasím. Největší problém je ignorace. Ignorace na straně neznalých, že to je blbost, a ignorace na straně znalých, že není třeba to polopatě vysvětlit.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 21. 06. 2018, 15:05:11
V tomto vlákně se opět manifestuje staré známé "nejsem-li něco schopen pochopit, je to k ničemu". Aneb na co používat bagr, když mám lopatu...
Přitom to celé začalo starým známým „nejsem schopen to pochopit, ale zrovna bych potřeboval bagrovat, tak to určitě je bagr“. Jen nevím, co je horší…
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 21. 06. 2018, 15:09:40
Tak to nechápou no. Tak přijde senior, řekne jim - to je tak a tak, voni na to - hmm, pomaleji... Zkusí to na malém příkladu, vyzkouší na části projektu, po pěti aplikacích (toho konceptu) budou tvrdit, že to znali vždycky.

Chci říct, samozřejmě souhlasím. Největší problém je ignorace. Ignorace na straně neznalých, že to je blbost, a ignorace na straně znalých, že není třeba to polopatě vysvětlit.
Obávám se, že ještě horší je, když někdo jenom zahlédne nějaký kousíček, a už má pocit, že to chápe. To je pak ten neznalý, který si ale navíc nenechá vysvětlit, že je neznalý.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 15:11:39
Největší problém je ignorace. Ignorace na straně neznalých, že to je blbost, a ignorace na straně znalých, že není třeba to polopatě vysvětlit.
+1
empatie by mohla pomoct, třeba tady SB, banda rádobychytrých pseudomatematiků se mu snaží nacpat, že nějaké conditional conformance burrito je lepší než to prostě napsat v pythonu
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 21. 06. 2018, 15:14:50
Obávám se, že ještě horší je, když někdo jenom zahlédne nějaký kousíček, a už má pocit, že to chápe. To je pak ten neznalý, který si ale navíc nenechá vysvětlit, že je neznalý.
Tak ona je taková dobrá zásada, když člověk něco zjišťuje, tak vyfiltrovat zdroje/lidi, které evidentně nejsou k užitku.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 21. 06. 2018, 15:21:30
empatie by mohla pomoct, třeba tady SB, banda rádobychytrých pseudomatematiků se mu snaží nacpat, že nějaké conditional conformance burrito je lepší než to prostě napsat v pythonu

Mou jedinou otázkou (odpovídající původnímu dotazu), na kterou mě zajímala odpověď, bylo, zda se mi vyplatí budovat typové systémy, nebo mě vyjde jednodušeji a pružněji celý tento aparát odbourat a nechat to na oněch testech (kterým se možná stejně nevyhnu). Nechci se kvůli tomu hádat, každý si stejně vybere to svoje.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 21. 06. 2018, 15:24:54
empatie by mohla pomoct, třeba tady SB, banda rádobychytrých pseudomatematiků se mu snaží nacpat, že nějaké conditional conformance burrito je lepší než to prostě napsat v pythonu

Mou jedinou otázkou (odpovídající původnímu dotazu), na kterou mě zajímala odpověď, bylo, zda se mi vyplatí budovat typové systémy, nebo mě vyjde jednodušeji a pružněji celý tento aparát odbourat a nechat to na oněch testech (kterým se možná stejně nevyhnu). Nechci se kvůli tomu hádat, každý si stejně vybere to svoje.
Šel jsem oběma cestama. A musím říct, že napsat aplikaci, kde spolehlivost bude stát jen na testech je peklo.
Psát aplikaci v Haskellu, kde mi vše drží typy mi přišla pohodlnější. Ale zase to jde ztuha, a ty IO monády - no člověk si musí hodně zvykat.

Za mě je ideální kompromis: co nejvíc typů, a teprve když to nejde tak pomoct testy.

A úplně největší peklo je Java.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 15:32:34
Jen jsem volně citoval, nicméně asi skutečně existují lidé, co nechápou třeba jen funkce vyššího řádu. A i ti píšou komerční kód.
Tak to nechápou no. Tak přijde senior, řekne jim - to je tak a tak, voni na to - hmm, pomaleji... Zkusí to na malém příkladu, vyzkouší na části projektu, po pěti aplikacích (toho konceptu) budou tvrdit, že to znali vždycky.

Chci říct, samozřejmě souhlasím. Největší problém je ignorace. Ignorace na straně neznalých, že to je blbost, a ignorace na straně znalých, že není třeba to polopatě vysvětlit.
Ano, ale každý má limit chápání někde jinde. Polopatě se nedá vysvětlit vše, taková kvantová chromodynamika nebo obecná teorie relativity mají hodně vysoké předpoklady.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 15:37:53
empatie by mohla pomoct, třeba tady SB, banda rádobychytrých pseudomatematiků se mu snaží nacpat, že nějaké conditional conformance burrito je lepší než to prostě napsat v pythonu
Mou jedinou otázkou (odpovídající původnímu dotazu), na kterou mě zajímala odpověď, bylo, zda se mi vyplatí budovat typové systémy, nebo mě vyjde jednodušeji a pružněji celý tento aparát odbourat a nechat to na oněch testech (kterým se možná stejně nevyhnu). Nechci se kvůli tomu hádat, každý si stejně vybere to svoje.
Za mě je ideální kompromis: co nejvíc typů, a teprve když to nejde tak pomoct testy.
K tomuto poznatku jednou dospěje každý. Pokud teda dříve neumře...
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 15:39:29
A úplně největší peklo je Java.
Někomu třeba peklo vyhovuje.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 15:42:38
Pamatuju si, jak jsem kolegovi vysvětloval, proč je jako docela fajn v konstruktoru testovat vstupní hodnoty; že jinak to balit do třídy nemá smysl. Strašně se kroutil. Je docela chytrý, ale celou svou inteligenci vyčerpal na to, aby mi dokázalmě uhádal, že to tak není.

Jak kdy. Pokud potřebuji pozdní vazbu, tak nevím, co bych v tom konstruktoru testoval.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 15:44:08
Mou jedinou otázkou (odpovídající původnímu dotazu), na kterou mě zajímala odpověď, bylo, zda se mi vyplatí budovat typové systémy, nebo mě vyjde jednodušeji a pružněji celý tento aparát odbourat a nechat to na oněch testech (kterým se možná stejně nevyhnu). Nechci se kvůli tomu hádat, každý si stejně vybere to svoje.
za sebe tvrdím, že se to vyplatí a určitě je jednodušší to odbourat a nechat to na testech, přínos se IMHO liší
na typy se dá dívat jako na další testovací nástroj (s každým nástrojem se musí člověk naučit), překladač něco ověří, typy výrazně omezí množinu vstupů (a tím testů) a pak jsou tu QuickCheck-y...
a tak dále
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 15:46:08
Největší problém je ignorace.
Někdy i absence ignorace, diskuse by byla přínosnější, kdyby ji ignoroval místní Gang of IQ 4. Ale zrovna toto vlákno bylo místy hodně zajímavé.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 15:49:31
Pamatuju si, jak jsem kolegovi vysvětloval, proč je jako docela fajn v konstruktoru testovat vstupní hodnoty; že jinak to balit do třídy nemá smysl. Strašně se kroutil. Je docela chytrý, ale celou svou inteligenci vyčerpal na to, aby mi dokázalmě uhádal, že to tak není.
Jak kdy. Pokud potřebuji pozdní vazbu, tak nevím, co bych v tom konstruktoru testoval.
Nějak to pleteš. Míchat konstruktory a pozdní vazbu chce hodně divokou představivost.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 16:01:13
Pamatuju si, jak jsem kolegovi vysvětloval, proč je jako docela fajn v konstruktoru testovat vstupní hodnoty; že jinak to balit do třídy nemá smysl. Strašně se kroutil. Je docela chytrý, ale celou svou inteligenci vyčerpal na to, aby mi dokázalmě uhádal, že to tak není.
Jak kdy. Pokud potřebuji pozdní vazbu, tak nevím, co bych v tom konstruktoru testoval.
Nějak to pleteš. Míchat konstruktory a pozdní vazbu chce hodně divokou představivost.

Ve chvíli, kdy vytvořím objekt, ještě nevím, které metody budu volat a které atributy mám validovat. Validuje se až při zavolání konkrétní metody.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 16:07:12
Pamatuju si, jak jsem kolegovi vysvětloval, proč je jako docela fajn v konstruktoru testovat vstupní hodnoty; že jinak to balit do třídy nemá smysl. Strašně se kroutil. Je docela chytrý, ale celou svou inteligenci vyčerpal na to, aby mi dokázalmě uhádal, že to tak není.
Jak kdy. Pokud potřebuji pozdní vazbu, tak nevím, co bych v tom konstruktoru testoval.
Nějak to pleteš. Míchat konstruktory a pozdní vazbu chce hodně divokou představivost.
Ve chvíli, kdy vytvořím objekt, ještě nevím, které metody budu volat a které atributy mám validovat. Validuje se až při zavolání konkrétní metody.
Aha. Takže když vytvořím instanci třídy Person s věkem -50, tak ti to je jedno, protože na zavolání metody “chcípni” (pure OO ekšperti by řekli poslání zprávy “chcípni”) to nemá vliv? Co zásada “fail early”? To “early” taky může znamenat před pádem letadla nebo výbuchem elektrárny.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 16:09:49
takové fajne vlákno to bylo :(
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 16:17:14
Ve chvíli, kdy vytvořím objekt, ještě nevím, které metody budu volat a které atributy mám validovat. Validuje se až při zavolání konkrétní metody.
Aha. Takže když vytvořím instanci třídy Person s věkem -50, tak ti to je jedno, protože na zavolání metody “chcípni” (pure OO ekšperti by řekli poslání zprávy “chcípni”) to nemá vliv? Co zásada “fail early”? To “early” taky může znamenat před pádem letadla nebo výbuchem elektrárny.

Co když ten věk vůbec nebudu potřebovat a v konstruktoru není uveden? Proč bych ho měl validovat?

"fail early" je cestou do pekel, protože narušuje atomicitu operací. Co když mezi validací a použitím hodnoty mi ji nějaké jiné vlákno změní? Výjimky pro tento účel poslouží mnohem lépe.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 21. 06. 2018, 16:33:17
Jak kdy. Pokud potřebuji pozdní vazbu, tak nevím, co bych v tom konstruktoru testoval.
Hele, založ si vlastní vlákno!
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 21. 06. 2018, 16:44:11
Šel jsem oběma cestama. A musím říct, že napsat aplikaci, kde spolehlivost bude stát jen na testech je peklo.
Nějak mne nenapadá, v čem by se měla lišit dovednost psát testy od dovednosti programovat.

Častým projevem toho nechápání bývá paušální odsuzování – a je jedno, zda PHP, JavaScriptu, Javy nebo C.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 21. 06. 2018, 17:03:42
Aha. Takže když vytvořím instanci třídy Person s věkem -50, tak ti to je jedno, protože...

Ono hodně dělají zvyky z těch statických typu. Pro nás už jen představa existence nevalidního objektu je neprijatelná.

V případě netypovych jazyku kde to může kdykoliv kdekoliv chcipnout - to tolik neprozivaji.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 17:12:42
Aha. Takže když vytvořím instanci třídy Person s věkem -50, tak ti to je jedno, protože...
Ono hodně dělají zvyky z těch statických typu. Pro nás už jen představa existence nevalidního objektu je neprijatelná.

V případě netypovych jazyku kde to může kdykoliv kdekoliv chcipnout - to tolik neprozivaji.
To už je o zvyku a disciplíně bez ohledu na jazyk. Prasit jde i v Haskellu.
Název: Re:Typový system versus unittesty
Přispěvatel: v 21. 06. 2018, 17:13:44
Častým projevem toho nechápání bývá paušální odsuzování – a je jedno, zda PHP, JavaScriptu, Javy nebo C.
vyloučil jste možnost, že ten nechápající jste vy?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 21. 06. 2018, 17:27:06
Častým projevem toho nechápání bývá paušální odsuzování – a je jedno, zda PHP, JavaScriptu, Javy nebo C.
vyloučil jste možnost, že ten nechápající jste vy?

Jistě, Haskell tady přece nikdo neodsuzuje. Není lepší ani horší než ostatní jazyky, je prostě jiný.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 21. 06. 2018, 21:10:59
Aha. Takže když vytvořím instanci třídy Person s věkem -50, tak ti to je jedno, protože...
Ono hodně dělají zvyky z těch statických typu. Pro nás už jen představa existence nevalidního objektu je neprijatelná.

V případě netypovych jazyku kde to může kdykoliv kdekoliv chcipnout - to tolik neprozivaji.
To už je o zvyku a disciplíně bez ohledu na jazyk.
Před seznámením se z Haskellem jsem to psal proto, protože je to tak správně. Po seznámení s Haskellem jsem začal chápat proč.

Prasit jde i v Haskellu.
To mě zajímá. Ne, to, zda to jde, ale nějakou pěknou ukázku prasení v Haskellu.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 21. 06. 2018, 23:50:34
Aha. Takže když vytvořím instanci třídy Person s věkem -50, tak ti to je jedno, protože...
Ono hodně dělají zvyky z těch statických typu. Pro nás už jen představa existence nevalidního objektu je neprijatelná.

V případě netypovych jazyku kde to může kdykoliv kdekoliv chcipnout - to tolik neprozivaji.
To už je o zvyku a disciplíně bez ohledu na jazyk.
Před seznámením se z Haskellem jsem to psal proto, protože je to tak správně. Po seznámení s Haskellem jsem začal chápat proč.
Je fakt škoda, že se Haskell neučí do hloubky na našich VŠ.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 22. 06. 2018, 00:14:04
To mě zajímá. Ne, to, zda to jde, ale nějakou pěknou ukázku prasení v Haskellu.
Nic konkrétního po ruce nemám, prasečiny si neschovávám, ale většinou jde o stupidní použití do notace. Ono vůbec nejhorší jsou lidi, co si myslí, že umí Haskell, a pak v něm něco píšou nebo ho nedejbože vysvětlují jiným. Operátor <- je pro ně přiřazení (haha) a kód píší v podstatě procedurálně.
Název: Re:Typový system versus unittesty
Přispěvatel: Link 22. 06. 2018, 01:14:55
Pro inspiraci: https://medium.com/@pereroigcat/functional-algorithmics-2-type-operators-and-higher-kinds-a594cd9cb01
Název: Re:Typový system versus unittesty
Přispěvatel: sdf 23. 06. 2018, 01:10:47
Častým projevem toho nechápání bývá paušální odsuzování – a je jedno, zda PHP, JavaScriptu, Javy nebo C.
vyloučil jste možnost, že ten nechápající jste vy?

Je to Jirsák. Co bys čekal.
Název: Re:Typový system versus unittesty
Přispěvatel: sdf 23. 06. 2018, 01:11:21
Častým projevem toho nechápání bývá paušální odsuzování – a je jedno, zda PHP, JavaScriptu, Javy nebo C.
vyloučil jste možnost, že ten nechápající jste vy?

Jistě, Haskell tady přece nikdo neodsuzuje. Není lepší ani horší než ostatní jazyky, je prostě jiný.

Totéž se dá říct o whitespacu....
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 23. 06. 2018, 10:13:44
Častým projevem toho nechápání bývá paušální odsuzování – a je jedno, zda PHP, JavaScriptu, Javy nebo C.
vyloučil jste možnost, že ten nechápající jste vy?

Jistě, Haskell tady přece nikdo neodsuzuje. Není lepší ani horší než ostatní jazyky, je prostě jiný.

Totéž se dá říct o whitespacu....
No říct se to sice dá, ale dost pochybuju že by to Kit opravdu řekl. Je to totiž úplná kravina. Dokonce bych řekl, že pojmem "jazyky" myslel automaticky "neezoterické jazyky".
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 23. 06. 2018, 12:34:38
Jistě, Haskell tady přece nikdo neodsuzuje. Není lepší ani horší než ostatní jazyky, je prostě jiný.

Totéž se dá říct o whitespacu....
No říct se to sice dá, ale dost pochybuju že by to Kit opravdu řekl. Je to totiž úplná kravina. Dokonce bych řekl, že pojmem "jazyky" myslel automaticky "neezoterické jazyky".

Přesně. Kdysi jsem si napsal vlastní jazyk, který jsem používal komerčně. Byl sice Turing complete, ale přesto bych ho s běžně používanými jazyky nesrovnával.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 23. 06. 2018, 12:45:58
Jistě, Haskell tady přece nikdo neodsuzuje. Není lepší ani horší než ostatní jazyky, je prostě jiný.

Totéž se dá říct o whitespacu....
No říct se to sice dá, ale dost pochybuju že by to Kit opravdu řekl. Je to totiž úplná kravina. Dokonce bych řekl, že pojmem "jazyky" myslel automaticky "neezoterické jazyky".
Přesně. Kdysi jsem si napsal vlastní jazyk, který jsem používal komerčně.
No to měli asi zákazníci radost.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 23. 06. 2018, 12:58:34
Přesně. Kdysi jsem si napsal vlastní jazyk, který jsem používal komerčně.
No to měli asi zákazníci radost.

Fungoval perfektně a hlavně mi urychlil vývoj aplikací.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 23. 06. 2018, 13:01:00
Přesně. Kdysi jsem si napsal vlastní jazyk, který jsem používal komerčně.
No to měli asi zákazníci radost.
Fungoval perfektně a hlavně mi urychlil vývoj aplikací.
A co vendor lock-in?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 23. 06. 2018, 13:04:13
Přesně. Kdysi jsem si napsal vlastní jazyk, který jsem používal komerčně.
No to měli asi zákazníci radost.
Fungoval perfektně a hlavně mi urychlil vývoj aplikací.
A co vendor lock-in?

Vendor lock-in tam nebyl, bylo to otevřené. Něco podobného na stejném principu později vydal i David Grudl a nikdo mu vendor lock-in nevyčítá.
Název: Re:Typový system versus unittesty
Přispěvatel: 123 23. 06. 2018, 13:31:10
Vyčítají si to akorát lidi, co to teď musí spravovat... Taky jsem pár podobných řešení vymyslel a s odstupem času... nebyl to dobrý nápad. Ten čas a energii, které jsem promrhal vymýšlením kulatějšího kola, jsem mohl radši věnovat do vývoje samotné aplikace - tam by ten investovaný čas byl aspoň vidět, což by ocenili jak zákazníci(kteří by nemuseli pracovat s nějakou ezoterickou vesmírnou technologií), tak uživatelé(kteří by měli propracovanější produkt).
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 23. 06. 2018, 13:47:26
Vyčítají si to akorát lidi, co to teď musí spravovat... Taky jsem pár podobných řešení vymyslel a s odstupem času... nebyl to dobrý nápad. Ten čas a energii, které jsem promrhal vymýšlením kulatějšího kola, jsem mohl radši věnovat do vývoje samotné aplikace - tam by ten investovaný čas byl aspoň vidět, což by ocenili jak zákazníci(kteří by nemuseli pracovat s nějakou ezoterickou vesmírnou technologií), tak uživatelé(kteří by měli propracovanější produkt).

Davidu Grudlovi dnes někdo vyčítá, že aplikace v Nette teď po něm musí spravovat?

Tenkrát nic takového neexistovalo, ani Nette, všechno obsahovalo lock-in. Můj jazyk ho naopak otevřel a zjednodušil modifikaci aplikace za provozu obyčejným editorem. Nechápu, proč by mi to měl dnes někdo vyčítat. S odstupem času to hodnotím jako skvělý nápad.
Název: Re:Typový system versus unittesty
Přispěvatel: 123 23. 06. 2018, 14:36:49
Nemluvím o nette, ale o tvojem řešení, které jsi použil jednou a nechal jsi ho tam jako artefakt pro budoucí generace. Vyvíjíš to i dál? Má to aspoň pořádnou dokumentaci? Neznám samozřejmě okolnosti, třeba to mělo opodstatnění, ale spíš mi to připadá jako když postavím celý projekt na vlastním UI frameworku, co jsem včeral slepil na koleně s postupy, které se nikde jinde nepoužívají a na námitky řeknu jenom: podívejte na React, vyčítá jim to někdo? Jenže React je samostatný projekt, který tady bude i za dalších X let, má komunitu, neustále se vyvíjí s ohledem na dění kolem a seženu dalších milión lidí, co v něm umí pracovat.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 23. 06. 2018, 14:49:27
To jsem jim tam měl dát zkompilovanou binárku, jako všichni ostatní?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 23. 06. 2018, 15:00:46
To své řešení jsem pak používal ve všech aplikacích pro firmy, protože se osvědčilo. Dokumentaci po mně nikdo nechtěl.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 23. 06. 2018, 15:41:32
To své řešení jsem pak používal ve všech aplikacích pro firmy, protože se osvědčilo. Dokumentaci po mně nikdo nechtěl.
Hádám že dneska bys tam místo vlastního jazyka použil Luu, či něco podobného, že?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 23. 06. 2018, 16:03:25
To své řešení jsem pak používal ve všech aplikacích pro firmy, protože se osvědčilo. Dokumentaci po mně nikdo nechtěl.
Hádám že dneska bys tam místo vlastního jazyka použil Luu, či něco podobného, že?
Nebo JS :)
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 23. 06. 2018, 17:25:49
To své řešení jsem pak používal ve všech aplikacích pro firmy, protože se osvědčilo. Dokumentaci po mně nikdo nechtěl.
Hádám že dneska bys tam místo vlastního jazyka použil Luu, či něco podobného, že?

Dnes pro tyto účely používám PHP s XSLT, všechno client-server. V DOSu už nedělám, přece jen doba mezitím trochu pokročila.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 23. 06. 2018, 22:45:28
To své řešení jsem pak používal ve všech aplikacích pro firmy, protože se osvědčilo. Dokumentaci po mně nikdo nechtěl.
Hádám že dneska bys tam místo vlastního jazyka použil Luu, či něco podobného, že?
Nevím, jestli je ta averze psát si vlastní jazyk opodstatněná. Elasticsearch má vlastní jazyk. Nevím, jak by to vyřešili s nějakou Luou... Mapbox styly mají vlastní expression jazyk. Dtto. Co mi připadá trošku srandovní je to, že v podstatě objevují závorky z lispu, akorát to místo toho cpou do JSONu... (ten mapbox jazyk aspoň evidentně navrhoval někdo, kdo funkcionálním jazykům trošku rozumí...elasticsearch je strašný).. nevím, jestli to je výhoda nebo ne... on ani ten lisp není zrovna výkvět přehlednosti....
Interpretovat lisp-like výrazy je dost triviální záležitost. Tak je trošku otázka, proč kvůli tomu hledat nějaké speciální knihovny...
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 23. 06. 2018, 23:51:32
Co mi připadá trošku srandovní je to, že v podstatě objevují závorky z lispu, akorát to místo toho cpou do JSONu...

Když se podívám na šablony Latte, tak je to skoro Lisp - jen místo kulatých závorek jsou chlupaté. Psát název funkce dovnitř závorky je pro interpret velmi praktické - zrychluje a zjednodušuje to zpracování. Někomu vadí velké množsví závorek v Lispu, ale je jich zhruba stejně (možná i méně) než ve srovnatelné javovské aplikaci.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 23. 06. 2018, 23:57:45
Nevím, jestli je ta averze psát si vlastní jazyk opodstatněná. Elasticsearch má vlastní jazyk. Nevím, jak by to vyřešili s nějakou Luou...
Lua je skvělá. Malá, kompaktní, šikovná, rychlá. Ale není funkcionální a nepřekvapivě nemá žádné typy.

Když bych hledal nějaký jazyk, který bych chtěl zakomponovat do svého programu, tak zase tak moc na výběr není. (Nebo tedy já nebyl úspěšný.)
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 24. 06. 2018, 00:22:25
Lua je skvělá. Malá, kompaktní, šikovná, rychlá. Ale není funkcionální a nepřekvapivě nemá žádné typy.
S typy je to pravda bídné, ale některé funkcionální věci tam jdou. Přes metatabulku se dá udělat libovolná lua table volatelná, takže tam jdou udělat minimálně funkce vyšších řádů. Dře to, ale jde to.

A je objektovější (v původním smyslu) než jakýkoliv mainstreamový jazyk. S drobnýma výhradama se tam dá psát skoro jako ve Smalltalku, nebo Selfu.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 24. 06. 2018, 00:33:52
Lua je skvělá. Malá, kompaktní, šikovná, rychlá. Ale není funkcionální a nepřekvapivě nemá žádné typy.
S typy je to pravda bídné, ale některé funkcionální věci tam jdou. Přes metatabulku se dá udělat libovolná lua table volatelná, takže tam jdou udělat minimálně funkce vyšších řádů. Dře to, ale jde to.

A je objektovější (v původním smyslu) než jakýkoliv mainstreamový jazyk. S drobnýma výhradama se tam dá psát skoro jako ve Smalltalku, nebo Selfu.
Ta "vyšší objektovost" je ale spíš nevýhoda, ne?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 24. 06. 2018, 00:37:18
Nevím, jestli je ta averze psát si vlastní jazyk opodstatněná. Elasticsearch má vlastní jazyk. Nevím, jak by to vyřešili s nějakou Luou...
Lua je skvělá. Malá, kompaktní, šikovná, rychlá. Ale není funkcionální a nepřekvapivě nemá žádné typy.

Lua má typy. Odvozené, ale má.

Když bych hledal nějaký jazyk, který bych chtěl zakomponovat do svého programu, tak zase tak moc na výběr není. (Nebo tedy já nebyl úspěšný.)

Co tak zmíněný Lisp? Funkcionální je, typy má také, makra na suprové úrovni,...

Jako alternativu z objektového světa jsem zkoušel Smalltalk. Má některé zajímavé vychytávky a jako zdroj inspirace pro tvorbu vlastního jazyka vůbec není špatný.

Lua zase má výhodu v tom, že je integrována do některých jazyků jako modul, např. PHP či Redis. Někdy se to prostě hodí.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 24. 06. 2018, 00:39:13
Ta "vyšší objektovost" je ale spíš nevýhoda, ne?

Proč by měla být "vyšší objektovost" nevýhodou?
Název: Re:Typový system versus unittesty
Přispěvatel: andy 24. 06. 2018, 00:51:38
Já si v rámci inspirace tady tím LLVM příkladem napsal interpret toho mapbox expression jazyka i s typecheckerem. Typechecker má 80 řádek, interpret dalších 80 (definice struktur/typů dalších 80). Faktem je, že díky Lisp-like syntaxi je parser asi na 25 řádek. Napsat si k tomu eventuálně nějaký parser, aby to bylo pro lidi, popravdě taky není zas až takový problém... ale pochopil jsem, proč mají lidi rádi lisp...

V každým případě nějak nevidím úplně nějaký zásadní problém v tom psát si vlastní jazyk... ani bych před pár lety nevěřil, že něco takového řeknu...

Citace
Lua má typy. Odvozené, ale má.
Nemá. Pierce jsem už tady citoval. "Tagování" proměnných nejsou typy.
Název: Re:Typový system versus unittesty
Přispěvatel: 123 24. 06. 2018, 09:02:05
Citace
Nevím, jestli je ta averze psát si vlastní jazyk opodstatněná. Elasticsearch má vlastní jazyk. Nevím, jak by to vyřešili s nějakou Luou... Mapbox styly mají vlastní expression jazyk. Dtto.

To ale není nějaký ad-hoc jazyk bez dokumentace, který se použije na jedné aplikaci a jede se dál, užijte si to. Tohle je úplně jiný případ.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 24. 06. 2018, 09:24:04
Citace
Nevím, jestli je ta averze psát si vlastní jazyk opodstatněná. Elasticsearch má vlastní jazyk. Nevím, jak by to vyřešili s nějakou Luou... Mapbox styly mají vlastní expression jazyk. Dtto.

To ale není nějaký ad-hoc jazyk bez dokumentace, který se použije na jedné aplikaci a jede se dál, užijte si to. Tohle je úplně jiný případ.
Ne, je to ad-hoc jazyk s dokumentací (někdy nejednoznacnou), který se použije na jedné aplikaci (elastic, aplikace mapboxu pro zobrazení map)... Je to úplně jiný případ..
Název: Re:Typový system versus unittesty
Přispěvatel: 123 24. 06. 2018, 10:35:34
ES není aplikace, ale knihovna, kterou někdo spravuje, opravuje v ní bugy, poskytuje support. Ano, je to jiný případ.
Název: Re:Typový system versus unittesty
Přispěvatel: v 24. 06. 2018, 12:37:52
ještě k prapůvodnímu dotazu: https://www.cs.kent.ac.uk/people/staff/sjt/TTFP/
Název: Re:Typový system versus unittesty
Přispěvatel: andy 24. 06. 2018, 20:57:27
ES není aplikace, ale knihovna, kterou někdo spravuje, opravuje v ní bugy, poskytuje support. Ano, je to jiný případ.
Aha... takže když někdo dodává aplikace, které nikdo nespravuje a neopravuje v nich bugy a neposkytuje support, tak by v těchto aplikacích neměl poskytovat konfiguraci přes vlastní jazyk, případě  by tu aplikaci neměl vyvíjet s použitím nějakého vlastního jazyka... (jako třeba v době, kdy nebylo XSLT, tak si rozhodně pro vývoj aplikací nepsat něco, co dělá něco podobného...)......
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 13:47:51
Ta "vyšší objektovost" je ale spíš nevýhoda, ne?
Objektovost bych jí nevyčítal.
Metatabulky jsou perfektní věc. Daj se pak děla i ty type-tagy. Akorát tedy nejde přiřadit meta ke scaláru.

Jedna věc, která mi přijde tak nějak navíc jsou eventy. Díky tomu mám problém to nazvat funkcionální :-)
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 25. 06. 2018, 14:14:32
Objektovost bych jí nevyčítal.
Ono říct “objektovost” je dost vágní. Je-li dostatečně pragmatická, je přínosem. Ty type tagy jsou dobrým příkladem. Takto se pak ale dostaneme k polymorfismu.

Jinak ještě k původnímu tématu - vedle typování a jednotkových testů se někdy taky používá obecné dokazování korektnosti při překladu, vývojář napíše podmínky v nějaké deklarativní notaci, které pak překladač vyhodnotí, než vygeneruje kód. Formálně to je jen zobecnění typové kontroly, ale za použití neomezené logiky. Například si můžu “staticky” vyžádat, že odmocnina prvočísla je vždy iracionální apod.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 14:25:29
vedle typování a jednotkových testů se někdy taky používá obecné dokazování korektnosti při překladu, vývojář napíše podmínky v nějaké deklarativní notaci, které pak překladač vyhodnotí, než vygeneruje kód. Formálně to je jen zobecnění typové kontroly, ale za použití neomezené logiky. Například si můžu “staticky” vyžádat, že odmocnina prvočísla je vždy iracionální apod.

Uniká mi v čem se to liší od typů. Já pomocí typu nemůžu "říct", že odmocnina z prvočísla je vždy iracionální?
Kód: [Vybrat]
nthRoot = x : PrimeNum -> IrrationalNum
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 25. 06. 2018, 14:45:20
vedle typování a jednotkových testů se někdy taky používá obecné dokazování korektnosti při překladu, vývojář napíše podmínky v nějaké deklarativní notaci, které pak překladač vyhodnotí, než vygeneruje kód. Formálně to je jen zobecnění typové kontroly, ale za použití neomezené logiky. Například si můžu “staticky” vyžádat, že odmocnina prvočísla je vždy iracionální apod.

Uniká mi v čem se to liší od typů. Já pomocí typu nemůžu "říct", že odmocnina z prvočísla je vždy iracionální?
Kód: [Vybrat]
nthRoot = x : PrimeNum -> IrrationalNum
To samozřejmě jde, měl jsem na mysli aparát, ve kterém se nadefinuje, co je prvočíslo, co je iracionální číslo a jak se odmocňuje. Možná jsem zvolil špatný příklad.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 15:07:01
To samozřejmě jde, měl jsem na mysli aparát, ve kterém se nadefinuje, co je prvočíslo, co je iracionální číslo a jak se odmocňuje. Možná jsem zvolil špatný příklad.

Jasně.

Právě, že v tom nevidím rozdíl. Pro mě jsou ty typy právě takový aparát.

Napadlo mě něco takového:
Kód: [Vybrat]
Person = {
    name: String 1 50
    surname: String 1 100
    birth: Date * now
    sex: Male | Female
    spouse: Person | None
} where [
    if spouse == Person:
       sex != spouse.sex
       birth < Now - (18 * year)
]

Ale považuji to také za typový systém.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 25. 06. 2018, 15:56:00
To samozřejmě jde, měl jsem na mysli aparát, ve kterém se nadefinuje, co je prvočíslo, co je iracionální číslo a jak se odmocňuje. Možná jsem zvolil špatný příklad.
Jasně.

Právě, že v tom nevidím rozdíl. Pro mě jsou ty typy právě takový aparát.

Napadlo mě něco takového:
Kód: [Vybrat]
Person = {
    name: String 1 50
    surname: String 1 100
    birth: Date * now
    sex: Male | Female
    spouse: Person | None
} where [
    if spouse == Person:
       sex != spouse.sex
       birth < Now - (18 * year)
]

Ale považuji to také za typový systém.
Ano. Možná mluvíme o tom samém každý jinak. Na dostatečně abstraktní úrovni a s kvantifikátory se jedná o to samé. Akorát teda pak zápis těch podmínek nebude moc připomínat typování, spíš nějaký lambda kalkul.
Název: Re:Typový system versus unittesty
Přispěvatel: Honza 25. 06. 2018, 16:25:23
Akorát teda pak zápis těch podmínek nebude moc připomínat typování, spíš nějaký lambda kalkul.
Ale hlavně se tomu nesmí říkat unit-testy... že?  ;D
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 16:28:45
Akorát teda pak zápis těch podmínek nebude moc připomínat typování, spíš nějaký lambda kalkul.
Ale hlavně se tomu nesmí říkat unit-testy... že?  ;D

A tak já proti unittestů zas v zásadě nic nemám. Ale tobě to přijde jako unittest?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 25. 06. 2018, 16:33:23
Akorát teda pak zápis těch podmínek nebude moc připomínat typování, spíš nějaký lambda kalkul.
Ale hlavně se tomu nesmí říkat unit-testy... že?  ;D
Unit testy se neprovádí v době překladu, na rozdíl od typové kontroly. Máš v tom guláš. A nepoužívej přebytečné pomlčky a smailíky.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 25. 06. 2018, 16:36:51
Akorát teda pak zápis těch podmínek nebude moc připomínat typování, spíš nějaký lambda kalkul.
Ale hlavně se tomu nesmí říkat unit-testy... že?  ;D
A tak já proti unittestů zas v zásadě nic nemám. Ale tobě to přijde jako unittest?
On neví, o čem mluví. Ale mám za to, že jsme se tu všichni shodli, že typová kontrola nemůže nahradit jednotkové testy ani naopak, byť se do značné míry překrývají (záleží na síle typového systému, v Javě je to tragédie, ale málokdo píše weby w Coqu nebo Agdě, to už spíš tíhnou k horším věcem).
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 16:38:46
Ale mám za to, že jsme se tu všichni shodli, že typová kontrola nemůže nahradit jednotkové testy ani naopak
Tak na to ať si udělá názor každý sám :-)
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 16:47:24
Akorát teda pak zápis těch podmínek nebude moc připomínat typování, spíš nějaký lambda kalkul.
Tak jak sis mohl všimnout, pro mnohé jsou Java typy vrchol toho co znají.

Jak jsem už uváděl. Pro mě je pro ty typy zásadní, že jsou deklarativní. Popisují a "vysvětlují" to kompilátoru, co to má být. Jestli to napíšeš tak či onak, je IMHO nepodstatné. Někdy si pomáhám slovíčkem "pravidla". Definuju pravidla, kterým ten element musí odpovídat, aby to označil za korektní. A ty pravdla samozřejmě nemusí být jen o "je" a "má", ale můžou být klidně docela komplexní. Klidně to je naféráka jazyk. Akorád nepoučuješ procesor, co má udělat, ale kompilátor, co má ten graf programu znamenat. V čemž vidím rozdíl oproti unittestů. Ty obvykle nejsou tak deklarativní, a hlavně compilátoru nepomáhají.

Název: Re:Typový system versus unittesty
Přispěvatel: Kit 25. 06. 2018, 17:23:52
Unit testy se neprovádí v době překladu, na rozdíl od typové kontroly.

Kdy jindy bys chtěl dělat jednotkové testy, než při překladu?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 25. 06. 2018, 17:41:11
Akorát teda pak zápis těch podmínek nebude moc připomínat typování, spíš nějaký lambda kalkul.
pro mnohé jsou Java typy vrchol toho co znají.
Ano, to jsme si všimnul. Je to smutné.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 25. 06. 2018, 17:43:37
Unit testy se neprovádí v době překladu, na rozdíl od typové kontroly.
Kdy jindy bys chtěl dělat jednotkové testy, než při překladu?
Jednotkové testy jsou kód jako každý jiný, normálně se přeloží (compile time) a spustí (run time). Typová kontrola probíhá při překladu nad oanotovaným syntaktickým stromem.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 25. 06. 2018, 18:45:08
Unit testy se neprovádí v době překladu, na rozdíl od typové kontroly.
Kdy jindy bys chtěl dělat jednotkové testy, než při překladu?
Jednotkové testy jsou kód jako každý jiný, normálně se přeloží (compile time) a spustí (run time). Typová kontrola probíhá při překladu nad oanotovaným syntaktickým stromem.

Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 21:44:16
Unit testy se neprovádí v době překladu, na rozdíl od typové kontroly.
Kdy jindy bys chtěl dělat jednotkové testy, než při překladu?
Jednotkové testy jsou kód jako každý jiný, normálně se přeloží (compile time) a spustí (run time). Typová kontrola probíhá při překladu nad oanotovaným syntaktickým stromem.

Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Ne. Testy se spouští při buildu. Build a compile není to samé.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 25. 06. 2018, 22:28:33
Unit testy se neprovádí v době překladu, na rozdíl od typové kontroly.
Kdy jindy bys chtěl dělat jednotkové testy, než při překladu?
Jednotkové testy jsou kód jako každý jiný, normálně se přeloží (compile time) a spustí (run time). Typová kontrola probíhá při překladu nad oanotovaným syntaktickým stromem.
Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Viz boneflutovo vysvětlení. Unit testy nejsou compile time.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 25. 06. 2018, 22:29:24
Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Ne. Testy se spouští při buildu. Build a compile není to samé.

To bych se načekal. Někdy spouštím testy i 3× za minutu.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 25. 06. 2018, 23:00:56
Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Ne. Testy se spouští při buildu. Build a compile není to samé.

To bych se načekal. Někdy spouštím testy i 3× za minutu.
Podle me nepoustis testy, ale aparatus. Aparatus zajisti, ze se prelozi "jednotka" (pricemz probehne typova kontrola) pak se prelozi test a nakonec se test spusti. Takze unit test se spusti (tesne) po prekladu, ale rozhodne ne pri nem.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 23:11:35
Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Ne. Testy se spouští při buildu. Build a compile není to samé.

To bych se načekal. Někdy spouštím testy i 3× za minutu.

No a?
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 23:12:49
Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Ne. Testy se spouští při buildu. Build a compile není to samé.

To bych se načekal. Někdy spouštím testy i 3× za minutu.
Podle me nepoustis testy, ale aparatus. Aparatus zajisti, ze se prelozi "jednotka" (pricemz probehne typova kontrola) pak se prelozi test a nakonec se test spusti. Takze unit test se spusti (tesne) po prekladu, ale rozhodne ne pri nem.
Sleduj. Teď zase odskočí někam jinam.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 25. 06. 2018, 23:14:50
To bych se načekal. Někdy spouštím testy i 3× za minutu.
Podle me nepoustis testy, ale aparatus. Aparatus zajisti, ze se prelozi "jednotka" (pricemz probehne typova kontrola) pak se prelozi test a nakonec se test spusti. Takze unit test se spusti (tesne) po prekladu, ale rozhodne ne pri nem.

Konečně to někdo pochopil :)

Jednotkové testy už prostě používám jako druhou fázi kompilace.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 23:26:21
To bych se načekal. Někdy spouštím testy i 3× za minutu.
Podle me nepoustis testy, ale aparatus. Aparatus zajisti, ze se prelozi "jednotka" (pricemz probehne typova kontrola) pak se prelozi test a nakonec se test spusti. Takze unit test se spusti (tesne) po prekladu, ale rozhodne ne pri nem.

Konečně to někdo pochopil :)

Jednotkové testy už prostě používám jako druhou fázi kompilace.
Až na to, že to kompilace není, protože nic nekompiluješ. No nic, log-off.
Název: Re:Typový system versus unittesty
Přispěvatel: . 25. 06. 2018, 23:33:46
Nemám sílu to už sledovat, takže se omlouvám, pokud něco opakuji.

Osobně vidím rozdíl mezi unittestem a kontrolu pomocí typového systémem tak, jak je zde popsán. Zatímco typový systém určuje omezení, kterým podléhá výsledek, unit test specifikuje vstupy a pro něj správný výstup. Rozumím tomu, že typový popis vypadá velmi elegantně a zachycuje všechny možné hodnoty. Ale nastavit správný typ pro komplexní funkce nemusí být triviální a může se v něm zrcadlit algoritmus výpočtu, což může snadno zanést chybu. Naproti tomu unit test, jakkoliv zachytí jen velmi omezenou množinu možných hodnot, je triviální - vstupy a požadovaný výstup. Možnost chyby velmi omezená. A proto se budou typový systém a unit testy, IMHO, vždy doplňovat. Čím dokonalejší typový systém, tím může být unit tetsů méně, ale nemyslím si, že je možné je zcela pominout. Chyba může vzniknout nejen při programování funkce, ale i při definici typu.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 25. 06. 2018, 23:39:57
Až na to, že to kompilace není, protože nic nekompiluješ. No nic, log-off.

V PHP je sice kompilace skryta, ale interpretr to už dávno není. A tato kompilace se spouští až po spuštění testů.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 25. 06. 2018, 23:52:34
Nemám sílu to už sledovat, takže se omlouvám, pokud něco opakuji.

Osobně vidím rozdíl mezi unittestem a kontrolu pomocí typového systémem tak, jak je zde popsán. Zatímco typový systém určuje omezení, kterým podléhá výsledek, unit test specifikuje vstupy a pro něj správný výstup. Rozumím tomu, že typový popis vypadá velmi elegantně a zachycuje všechny možné hodnoty. Ale nastavit správný typ pro komplexní funkce nemusí být triviální a může se v něm zrcadlit algoritmus výpočtu, což může snadno zanést chybu. Naproti tomu unit test, jakkoliv zachytí jen velmi omezenou množinu možných hodnot, je triviální - vstupy a požadovaný výstup. Možnost chyby velmi omezená. A proto se budou typový systém a unit testy, IMHO, vždy doplňovat. Čím dokonalejší typový systém, tím může být unit tetsů méně, ale nemyslím si, že je možné je zcela pominout. Chyba může vzniknout nejen při programování funkce, ale i při definici typu.
Rozumím. Ale chyba může vzniknout i při psaní testu. Vzhledem k tomu, jak často zoufale nečitelné mohou testy být - velmi snadno.

Jednou se mi stalo, že jsem našel chybu v kódu, který měl stoprocentní pokrytí testy. Byl to den, kdy jsem na coverage zanevřel.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 25. 06. 2018, 23:57:55
Rozumím. Ale chyba může vzniknout i při psaní testu. Vzhledem k tomu, jak často zoufale nečitelné mohou testy být - velmi snadno.

Jednou se mi stalo, že jsem našel chybu v kódu, který měl stoprocentní pokrytí testy. Byl to den, kdy jsem na coverage zanevřel.

Dnes i testy musí mít stejnou úroveň jako produkční kód. Pokud jsou nečitelné, tak to autorovi dřív nebo později někdo omlátí o hlavu. Pokud jsi našel chybu v kódu, tak zcela jistě neměl 100% pokrytí testy.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 01:19:54
Pokud jsi našel chybu v kódu, tak zcela jistě neměl 100% pokrytí testy.
ale no tak... test může být prostě blbě - buď je chyba v něčem, co nekontroluje (např. testuje, že delete smaže prvek, ale nezkontroluje, že nesmaže víc než je požadováno) - 100% pokrytí splněno. Nebo máš testy, kdy se testuje, že pro zadaný vstup to dává furt stejný výstup...až na to, že ten "stejný" výstup je od začátku blbě. Opět klidně 100% pokrytí..
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 07:29:46
Rozumím. Ale chyba může vzniknout i při psaní testu. Vzhledem k tomu, jak často zoufale nečitelné mohou testy být - velmi snadno.
To je ovšem dané špatným způsobem psaní testů. Jednotkové testy mají testovat, zda pro „zajímavé“ vstupy dává kód očekávané výstupy. Není důvod, proč by takový test měl být nečitelný. V testu samozřejmě může být chyba, ale pak se na ní obvykle přijde při spouštění testů, protože test neprojde. Vzhledem k tomu, že je test napsaný úplně jiným způsobem, než testovaný kód, je velmi nepravděpodobné, že by v něm byla stejná algoritmická chyba (zejména když v testu žádný algoritmus nemá být). Samozřejmě je možné, že tam bude systematická chyba – test bude očekávat chybný výstup, protože programátor špatně pochopil zadání. Jenže pokud programátor špatně pochopil zadání, bude chyba v kódu vždy, i když bude mít sebelepší typový systém nebo jakýkoli jiný systém kontroly. Tam je jediná šance, že ten test bude psát někdo jiný, kdo zadání pochopí jinak – ale ani to není stoprocentní cesta k úspěchu, protože problém bývá velmi často v tom zadání, takže je dost pravděpodobné, že ho dva programátoři pochopí stejně špatně. A konečně zřejmě nejčastější důvod, proč test neodhalí chybu, je ten, že nepokrývá všechny zajímavé případy – takže chyba bude jednoduše v něčem, co se netestuje. I tenhle typ chyby se bude objevovat u sebelepšího typového systému, protože když programátora nenapadne, že to je zajímavý případ a měl by na to udělat test, nenapadne ho ani ošetřit to v typovém systému.

Jednou se mi stalo, že jsem našel chybu v kódu, který měl stoprocentní pokrytí testy. Byl to den, kdy jsem na coverage zanevřel.
Vy se neustále míjíte s podstatou problémů. Stoprocentní pokrytí kódu testy znamená, že se při testech projdou všechny „řádky“ (ve skutečnosti instrukce) programu. To samozřejmě v žádném případě neznamená, že jsou otestované všechny případy. Pokrytí kódu testy se používá opačně – když nemáte stoprocentní pokrytí kódu testy, máte takřka jistotu, že nepokrytý kód není otestován žádným způsobem. (Zbývá malá možnost, že nepokrytý kód je nedostupný, pak by ale stejně v kódu neměl být.) Takže pokud jste chybu v kódu, který měl stoprocentní pokrytí testy, našel jenom jednou, zažil jste toho zatím opravdu málo. Že jste na code coverage zanevřel po nalezení jediné chyby svědčí pouze a jen o nedostatku pokory, a to vás pak nezachrání sebelepší nástroje. Proto jsem vám už minule psal, že nemáte hledat stříbrnou kulku, která nějak mechanicky zajistí, že budete psát bezchybné programy (to je nemožné), a radši byste se měl snažit pochopit, k čemu slouží nástroje, které máte k dispozici, a správně je používat. Pak můžete dobrý kód psát i v Javě, v JavaScriptu nebo PHP.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 08:31:52
Pokud jsi našel chybu v kódu, tak zcela jistě neměl 100% pokrytí testy.
ale no tak... test může být prostě blbě - buď je chyba v něčem, co nekontroluje (např. testuje, že delete smaže prvek, ale nezkontroluje, že nesmaže víc než je požadováno) - 100% pokrytí splněno. Nebo máš testy, kdy se testuje, že pro zadaný vstup to dává furt stejný výstup...až na to, že ten "stejný" výstup je od začátku blbě. Opět klidně 100% pokrytí..

To je jen formálně 100% pokrytí, které spočítají nějaké automatické vyhodnocovače. To bych mohl napsat prázdné testy, které by nic nedělaly a také tvrdit, že mám 100% pokrytí. Ostatně totéž se běžně dělá i u typů, protože se s tím nikdo nechce piplat.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 08:34:38
Vzhledem k tomu, že je test napsaný úplně jiným způsobem, než testovaný kód, je velmi nepravděpodobné, že by v něm byla stejná algoritmická chyba (zejména když v testu žádný algoritmus nemá být).
Až na to, že pokud algoritmus něco složitého "počítá", tak není moc šance na to psát unit test buď tak, že ten algoritmus implementuje někdo jiný/jinak, nebo tak, že se prostě výsledek algoritmu vezme jako že je "správně". Ono to má své opodstatěnění, při refaktoringu/optimalizaci to najde, co to rozbilo (nebo naopak spravilo), ale bohužel chyby to často moc nemá šanci najít.
Citace
A konečně zřejmě nejčastější důvod, proč test neodhalí chybu, je ten, že nepokrývá všechny zajímavé případy – takže chyba bude jednoduše v něčem, co se netestuje. I tenhle typ chyby se bude objevovat u sebelepšího typového systému, protože když programátora nenapadne, že to je zajímavý případ a měl by na to udělat test, nenapadne ho ani ošetřit to v typovém systému.
No... taková trapárna jako "null pointer exception". Problém je, že u silného typového systému člověk prostě dělá design tak, aby k té chybě vůbec nemohlo dojít už z principu. U testů je velmi jednoduché zapomenout testovat nějakou funkci na to, zda při nějaké konfiguraci vstupů nespadne na null pointer exception.

Takže čistě z praktického hlediska u této konkrétní kategorie chyby bude typický výsledek ten, že typované programy prostě nullpointerexception vyhazovat nebudou, netypované "testované" ano, protože to programátor zapomněl na spoustě míst ošetřit a testy to nenašly.

Já to spíš vidím tak, že některé věci prostě není praktické psát do typů (navíc  u některých věcí neexistuje třeba jazyk, který by tyhle věci byl schopen vůbec vyjádřit, u souladu se specifikací to IMO u spousty věcí fakt nejde), někdy by z toho i tak bylo víc práce než užitku.... (na druhou stranu, prakticky kdykoliv jsem nepoužil NonEmpty pro neprázdný list, tak se mi to vymstilo).

Ale konkrétně - jak jsem se inspiroval tím LLVM paperem, tak jsem napsal interpret na ten Mapbox style jazyk a běželo to bez testů napoprvé (po cca. 5 hodinách psaní) a doteď jsem v tom kódu interpretu žádnou chybu nenašel (měl jsem jednu chybu mimo interpret, kdy jsem ve 3 ráno omylem napsal && místo ||). A tady je mimo jiné odpověď na týkající se otázky na "méně kódu" - díky těm typům pak při interpretaci není potřeba kontrolovat, jakého typu jsou vstupy funkcí. Protože prostě mají ten správný typ.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 08:35:30
Pokud jsi našel chybu v kódu, tak zcela jistě neměl 100% pokrytí testy.
ale no tak... test může být prostě blbě - buď je chyba v něčem, co nekontroluje (např. testuje, že delete smaže prvek, ale nezkontroluje, že nesmaže víc než je požadováno) - 100% pokrytí splněno. Nebo máš testy, kdy se testuje, že pro zadaný vstup to dává furt stejný výstup...až na to, že ten "stejný" výstup je od začátku blbě. Opět klidně 100% pokrytí..

To je jen formálně 100% pokrytí, které spočítají nějaké automatické vyhodnocovače. To bych mohl napsat prázdné testy, které by nic nedělaly a také tvrdit, že mám 100% pokrytí. Ostatně totéž se běžně dělá i u typů, protože se s tím nikdo nechce piplat.
Chápu správně, že tvá definice "100% pokrytí" == "kód pracuje správně"?
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 08:38:28
trochu offtopic, ale nemáte někdo nějakou teorii tohohle vehementního odmítání moderních technologií?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 08:40:50
Rozumím. Ale chyba může vzniknout i při psaní testu. Vzhledem k tomu, jak často zoufale nečitelné mohou testy být - velmi snadno.
To je ovšem dané špatným způsobem psaní testů. Jednotkové testy mají testovat, zda pro „zajímavé“ vstupy dává kód očekávané výstupy. Není důvod, proč by takový test měl být nečitelný. V testu samozřejmě může být chyba, ale pak se na ní obvykle přijde při spouštění testů, protože test neprojde.

To je ten lepší případ. Horší je, když chybný test projde, což má BoneFlute zřejmě na mysli. Jenže pak nelze tvrdit, že tento test pokrývá testovaný kód - možná jen formálně.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 08:46:29
Pokud jsi našel chybu v kódu, tak zcela jistě neměl 100% pokrytí testy.
ale no tak... test může být prostě blbě - buď je chyba v něčem, co nekontroluje (např. testuje, že delete smaže prvek, ale nezkontroluje, že nesmaže víc než je požadováno) - 100% pokrytí splněno. Nebo máš testy, kdy se testuje, že pro zadaný vstup to dává furt stejný výstup...až na to, že ten "stejný" výstup je od začátku blbě. Opět klidně 100% pokrytí..

To je jen formálně 100% pokrytí, které spočítají nějaké automatické vyhodnocovače. To bych mohl napsat prázdné testy, které by nic nedělaly a také tvrdit, že mám 100% pokrytí. Ostatně totéž se běžně dělá i u typů, protože se s tím nikdo nechce piplat.
Chápu správně, že tvá definice "100% pokrytí" == "kód pracuje správně"?

Je snad jiná definice 100% pokrytí testy? Pokud se test tváří, že pokrývá nějakou vlastnost, ale ve skutečnosti nedělá nic, tak do této statistiky nemůže být zahrnut.
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 26. 06. 2018, 09:04:16
Pokud jsi našel chybu v kódu, tak zcela jistě neměl 100% pokrytí testy.
ale no tak... test může být prostě blbě - buď je chyba v něčem, co nekontroluje (např. testuje, že delete smaže prvek, ale nezkontroluje, že nesmaže víc než je požadováno) - 100% pokrytí splněno. Nebo máš testy, kdy se testuje, že pro zadaný vstup to dává furt stejný výstup...až na to, že ten "stejný" výstup je od začátku blbě. Opět klidně 100% pokrytí..

To je jen formálně 100% pokrytí, které spočítají nějaké automatické vyhodnocovače. To bych mohl napsat prázdné testy, které by nic nedělaly a také tvrdit, že mám 100% pokrytí. Ostatně totéž se běžně dělá i u typů, protože se s tím nikdo nechce piplat.
Chápu správně, že tvá definice "100% pokrytí" == "kód pracuje správně"?

Je snad jiná definice 100% pokrytí testy? Pokud se test tváří, že pokrývá nějakou vlastnost, ale ve skutečnosti nedělá nic, tak do této statistiky nemůže být zahrnut.

Coz ti zadny nastroj jen tak neprozradi. Napovedet muze az mutacni testovani.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 26. 06. 2018, 09:17:29
...Stoprocentní pokrytí kódu testy znamená, že se při testech projdou všechny „řádky“ (ve skutečnosti instrukce) programu...

Toto je chybné tvrzení. Vy sám jste napsal, že testy nesmějí obsahovat algoritmus, neboli duplikovat implementaci. Úkolem testů není ověření samotné implementace, ale ověření správnosti výstupů pro všechny kombinace možných vstupů, to je 100% pokrytí testem. To je ale obvykle nereálné, takže alespoň jejich části.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 09:28:13
...Stoprocentní pokrytí kódu testy znamená, že se při testech projdou všechny „řádky“ (ve skutečnosti instrukce) programu...

Toto je chybné tvrzení. Vy sám jste napsal, že testy nesmějí obsahovat algoritmus, neboli duplikovat implementaci. Úkolem testů není ověření samotné implementace, ale ověření správnosti výstupů pro všechny kombinace možných vstupů, to je 100% pokrytí testem. To je ale obvykle nereálné, takže alespoň jejich části.

Obvykle stačí testovat chování pro limitní a nadlimitní hodnoty vstupů. Testy tak vychází jen asi 2× delší než testovaný kód.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 09:36:00
...Stoprocentní pokrytí kódu testy znamená, že se při testech projdou všechny „řádky“ (ve skutečnosti instrukce) programu...

Toto je chybné tvrzení. Vy sám jste napsal, že testy nesmějí obsahovat algoritmus, neboli duplikovat implementaci. Úkolem testů není ověření samotné implementace, ale ověření správnosti výstupů pro všechny kombinace možných vstupů, to je 100% pokrytí testem. To je ale obvykle nereálné, takže alespoň jejich části.

Obvykle stačí testovat chování pro limitní a nadlimitní hodnoty vstupů. Testy tak vychází jen asi 2× delší než testovaný kód.
v dynamickém jazce? postněte nějaký jednoduchý příklad (funkce+testy), bylo by zajímavé zkusit co s tím udělá zavedení typů
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 09:47:01
Obvykle stačí testovat chování pro limitní a nadlimitní hodnoty vstupů. Testy tak vychází jen asi 2× delší než testovaný kód.
v dynamickém jazce? postněte nějaký jednoduchý příklad (funkce+testy), bylo by zajímavé zkusit co s tím udělá zavedení typů

Zavedení dalších typů s tím neudělá vůbec nic, protože typy nezkoumají funkčnost.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 09:52:57
Chápu správně, že tvá definice "100% pokrytí" == "kód pracuje správně"?
Je snad jiná definice 100% pokrytí testy? Pokud se test tváří, že pokrývá nějakou vlastnost, ale ve skutečnosti nedělá nic, tak do této statistiky nemůže být zahrnut.
Pokud definuješ 100% pokrytí testy jako "kód pracuje správně", tak pak tvoje rada zní "pište programy správně"...

Obvyklá definice je ve stylu "testy spustí všechny řádky kódu programu". Ideální by byla definice ve stylu "testy projdou všechen stavový prostor", což ale vzhledem ke state-explosion je dost nereálné. Ale i to  negarantuje, že výsledný program bude pracovat správně (např. pro "a * b" by vstup "2,2" prošel veškerý stavový prostor, ale že jsi napsal "a + b" by neodhalil). Další možnost je projít všechny vstupy programu a porovnat je s očekávanými výstupy, ale to je v podstatě reimplementace toho programu, což ten problém moc neřeší...

Jinak když teda definuješ 100% pokrytí testy jako kód pracuje správně, jak bys definoval 90% pokrytí testy?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 10:08:42
Chápu správně, že tvá definice "100% pokrytí" == "kód pracuje správně"?
Je snad jiná definice 100% pokrytí testy? Pokud se test tváří, že pokrývá nějakou vlastnost, ale ve skutečnosti nedělá nic, tak do této statistiky nemůže být zahrnut.
Pokud definuješ 100% pokrytí testy jako "kód pracuje správně", tak pak tvoje rada zní "pište programy správně"...

Zajímavá implikace. Na to jsi přišel matematickými postupy?

Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 10:09:34
Až na to, že pokud algoritmus něco složitého "počítá", tak není moc šance na to psát unit test buď tak, že ten algoritmus implementuje někdo jiný/jinak, nebo tak, že se prostě výsledek algoritmu vezme jako že je "správně". Ono to má své opodstatěnění, při refaktoringu/optimalizaci to najde, co to rozbilo (nebo naopak spravilo), ale bohužel chyby to často moc nemá šanci najít.
Jednotkový test nemá nic počítat. Když budu psát jednotkový test na odmocňování, budu testovat, že odmocnina ze dvou vrátí po zaokrouhlení 1,4142 (což si najdu třeba v tabulkách) a odmocnina z -2 vrátí chybu vstupu. Jak se ve skutečnosti odmocnina počítá nemusím pro psaní testu vůbec vědět. Ano, někdy je ten algoritmus tak netypický, že nikde jinde správné výsledky nenajdu, pak opravdu nezbývá, než testem zafixovat výsledky, co ten algoritmus spočítal. Ale to není tak častý případ.

No... taková trapárna jako "null pointer exception". Problém je, že u silného typového systému člověk prostě dělá design tak, aby k té chybě vůbec nemohlo dojít už z principu. U testů je velmi jednoduché zapomenout testovat nějakou funkci na to, zda při nějaké konfiguraci vstupů nespadne na null pointer exception.
„Null pointer exception“ je řekl bych ukázkový příklad. Můžu to ošetřit pomocí typů, pomocí assertů a nebo to můžu testovat. BoneFlute tu asserty řadí do typového systému a dospěl k tomu tak, že začal do typů vkládat přímo testy. Asserty jsou přitom záměrně navržené tak, aby jednoduché případy mohl vyhodnocovat už kompilátor (nebo něco k němu přilepeného). Takže dohadovat se, co přesně je ještě součástí kompilace a co už ne je trochu akademická diskuse, protože to záleží na konkrétní implementaci – právě asserty se obvykle vyhodnocují až za běhu (poprvé tedy typicky v testech), ale stejně tak je může vyhodnocovat už kompilátor.

Takže čistě z praktického hlediska u této konkrétní kategorie chyby bude typický výsledek ten, že typované programy prostě nullpointerexception vyhazovat nebudou, netypované "testované" ano, protože to programátor zapomněl na spoustě míst ošetřit a testy to nenašly.
Myslím, že je to opět spíš teoretický příklad. Z praktického hlediska bude k těm „null pointer exception“ docházet i v těch typových programech, protože ty nefungují ve vzduchoprázdnu, ale komunikují s okolím – a z něj ty NIL hodnoty dostávají. A i tam budou případy, kdy to programátor prostě přetypuje bez kontroly. Krásně je to vidět např. na Kotlinu, který nullable typy zavedl, ale když se někde váže na Javu, je to plné vykřičníků (tj. přetypování nullable typu na non-nullable, ze kterého může vypadnout NullPointerException).

Já to spíš vidím tak, že některé věci prostě není praktické psát do typů (navíc  u některých věcí neexistuje třeba jazyk, který by tyhle věci byl schopen vůbec vyjádřit, u souladu se specifikací to IMO u spousty věcí fakt nejde), někdy by z toho i tak bylo víc práce než užitku.... (na druhou stranu, prakticky kdykoliv jsem nepoužil NonEmpty pro neprázdný list, tak se mi to vymstilo).
Souhlasím. A stejně tak souhlasím s tím, že některé věci je naopak dobré mít v typech – třeba rozlišování typů na nullable/non-nullable považuju za hodně užitečné (i když to počet „null pointer exeception“ jen sníží, ale kromě akademických příkladů je nikdy nevymýtí úplně). Nikdy jsem netvrdil, že silnější typový systém nemůže některé testy učinit zbytečnými. Jenom tvrdím, že sebesilnější typový systém nedokáže nahradit všechny jednotkové testy – protože to, že se algoritmus pro nějaký vstup trefil do správného oboru hodnot ještě neznamená, že je výsledek správně.

Ale konkrétně - jak jsem se inspiroval tím LLVM paperem, tak jsem napsal interpret na ten Mapbox style jazyk a běželo to bez testů napoprvé (po cca. 5 hodinách psaní) a doteď jsem v tom kódu interpretu žádnou chybu nenašel (měl jsem jednu chybu mimo interpret, kdy jsem ve 3 ráno omylem napsal && místo ||). A tady je mimo jiné odpověď na týkající se otázky na "méně kódu" - díky těm typům pak při interpretaci není potřeba kontrolovat, jakého typu jsou vstupy funkcí. Protože prostě mají ten správný typ.
Tohle ale dobře funguje na nízké úrovni, v nějakých knihovnách (kde jsou zároveň nejsilnější i jednotkové testy). Jak se dostáváte výš, deklarativní popis typů by se začal komplikovat a srozumitelnější je použít asserty (i když osobně si myslím, že by programátor měl asserty považovat za deklaraci – ale pořád jsou to výrazy). A na ještě vyšších úrovních už se jenom propojují nějaké komponenty, tam už je řešení pomocí typů úplně nereálné (i kdyby jen proto, že ty komponenty vám dodává někdo jiný, koho nedonutíte detailně nadefinovat typy).
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 10:13:31
Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.
Ke slovesu pokrytí se váže předmět – tedy pokrytí čeho. Nemá smysl se tady dohadovat a neustále používat nevyjádřený předmět, když je zřejmé, že každý za předmět považuje něco jiného. Obvykle se „pokrytím testy“ myslí pokrytí kódu, tedy 100% pokrytí testy by znamenal pokrytí všech řádků/instrukcí. Které samozřejmě nezaručuje skoro nic, rozhodně nezaručuje bezchybnost. Vy asi myslíte 100% pokrytí všech možných případů, což je u jenom trošku větších věcí nedosažitelné.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 10:21:18
Chápu správně, že tvá definice "100% pokrytí" == "kód pracuje správně"?
Je snad jiná definice 100% pokrytí testy? Pokud se test tváří, že pokrývá nějakou vlastnost, ale ve skutečnosti nedělá nic, tak do této statistiky nemůže být zahrnut.
Pokud definuješ 100% pokrytí testy jako "kód pracuje správně", tak pak tvoje rada zní "pište programy správně"...
Zajímavá implikace. Na to jsi přišel matematickými postupy?
Tak pokud bys někomu radil "mějte 100% pokrytí testy", tak vzhledem k tomu, že to definuješ jako program pracuje správně, tak jim radíš "pište programy, které pracují správně"...

Citace
Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.
To samozřejmě můžeš. Stejně jako to, že program používá nějaký typový systém neimplikuje, že program pracuje správně.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 10:21:35
...Stoprocentní pokrytí kódu testy znamená, že se při testech projdou všechny „řádky“ (ve skutečnosti instrukce) programu...

Toto je chybné tvrzení. Vy sám jste napsal, že testy nesmějí obsahovat algoritmus, neboli duplikovat implementaci. Úkolem testů není ověření samotné implementace, ale ověření správnosti výstupů pro všechny kombinace možných vstupů, to je 100% pokrytí testem. To je ale obvykle nereálné, takže alespoň jejich části.
To spolu ale nesouvisí. Testy mohou pokrývat 100 % kódu, tj. při spuštění testů se spustí všechny instrukce kódu. To ale vůbec neznamená, že by test duplikoval implementaci. Za „pokrytí testy“ se obvykle označuje právě poměr počtu instrukcí procházených při testech k celkovému počtu instrukcí knihovny či aplikace, protože to se dá změřit. To je reálné (i když to nemusí být nutné, protože chybějící testy mohou nepokrývat nezajímavé části kódu), ale v žádném případě to neříká, že by se testovaly všechny možné vstupy, nebo že by program byl bezchybný, pokud testy projdou. Ukazatel „pokrytí kódu/řádků/instrukcí testy“ má opačný význam – pokud určitá větev programu není testem pokrytá, víme určitě, že pomocí testů určitě nedokážeme poznat, zda v dané části chyba je nebo není.
Název: Re:Typový system versus unittesty
Přispěvatel: netypová lopata 26. 06. 2018, 10:22:36
Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.

100% pokrytí testy nelze dosáhnout ani teoreticky, protože Halting problem: https://en.wikipedia.org/wiki/Halting_problem (https://en.wikipedia.org/wiki/Halting_problem)

Doporučuju, Kite, nastudovat alespoň základy computer science, nebudeš se potom tady na fóru ztrapňovat tak často. A než začneš argumetovat tím, že je to jen teoretická konstrukce a nic takového, jako počítač s nekonečnou pamětí neexistuje, přečti si na wikipedii ten odstavec, který začíná The halting problem is theoretically decidable for linear bounded automata... a pochopíš, že to reálně opravdu udělat nejde.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 10:25:54
Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.
Ke slovesu pokrytí se váže předmět – tedy pokrytí čeho. Nemá smysl se tady dohadovat a neustále používat nevyjádřený předmět, když je zřejmé, že každý za předmět považuje něco jiného. Obvykle se „pokrytím testy“ myslí pokrytí kódu, tedy 100% pokrytí testy by znamenal pokrytí všech řádků/instrukcí. Které samozřejmě nezaručuje skoro nic, rozhodně nezaručuje bezchybnost. Vy asi myslíte 100% pokrytí všech možných případů, což je u jenom trošku větších věcí nedosažitelné.

Je to dosažitelné, pokud testované jednotky jsou dostatečně malé a jednoduché (SRP).
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 10:26:40
trochu offtopic, ale nemáte někdo nějakou teorii tohohle vehementního odmítání moderních technologií?
Nevšiml jsem si, že by tu někdo odmítal moderní technologie. Vidím tu jen nekritické přijímání něčeho, čemu dotyčný moc nerozumí, ale je to pro něj nové (ve skutečnosti to ale ani nic nového není), a má pocit, že to vyřeší všechny problémy světa. Na technologiích není důležité to, jestli jsou nové, ale jaké problémy umí (doopravdy) řešit.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 10:29:43
No... taková trapárna jako "null pointer exception". Problém je, že u silného typového systému člověk prostě dělá design tak, aby k té chybě vůbec nemohlo dojít už z principu. U testů je velmi jednoduché zapomenout testovat nějakou funkci na to, zda při nějaké konfiguraci vstupů nespadne na null pointer exception.
„Null pointer exception“ je řekl bych ukázkový příklad. Můžu to ošetřit pomocí typů, pomocí assertů a nebo to můžu testovat. BoneFlute tu asserty řadí do typového systému a dospěl k tomu tak, že začal do typů vkládat přímo testy. Asserty jsou přitom záměrně navržené tak, aby jednoduché případy mohl vyhodnocovat už kompilátor (nebo něco k němu přilepeného). Takže dohadovat se, co přesně je ještě součástí kompilace a co už ne je trochu akademická diskuse, protože to záleží na konkrétní implementaci – právě asserty se obvykle vyhodnocují až za běhu (poprvé tedy typicky v testech), ale stejně tak je může vyhodnocovat už kompilátor.
Typ Maybe fakt není assert.

Citace
Myslím, že je to opět spíš teoretický příklad. Z praktického hlediska bude k těm „null pointer exception“ docházet i v těch typových programech, protože ty nefungují ve vzduchoprázdnu, ale komunikují s okolím – a z něj ty NIL hodnoty dostávají. A i tam budou případy, kdy to programátor prostě přetypuje bez kontroly. Krásně je to vidět např. na Kotlinu, který nullable typy zavedl, ale když se někde váže na Javu, je to plné vykřičníků (tj. přetypování nullable typu na non-nullable, ze kterého může vypadnout NullPointerException).
Pokud programátor napíše "int x = (unsafeCoerce) 'string'", tak ho fakt nic nezachrání. Ale řekl bych, že je dost velký rozdíl mezi tímto a jazykem, kde člověk může napsat akorát "x = 'string' # comment: x je typu int".
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 10:31:12
Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.
Ke slovesu pokrytí se váže předmět – tedy pokrytí čeho. Nemá smysl se tady dohadovat a neustále používat nevyjádřený předmět, když je zřejmé, že každý za předmět považuje něco jiného. Obvykle se „pokrytím testy“ myslí pokrytí kódu, tedy 100% pokrytí testy by znamenal pokrytí všech řádků/instrukcí. Které samozřejmě nezaručuje skoro nic, rozhodně nezaručuje bezchybnost. Vy asi myslíte 100% pokrytí všech možných případů, což je u jenom trošku větších věcí nedosažitelné.

Je to dosažitelné, pokud testované jednotky jsou dostatečně malé a jednoduché (SRP).
jak by teda vypadaly testy pro 100% pokrytí tohoto kódu v pythonu:
Kód: [Vybrat]
def x(y, z): return y + z
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 10:32:23
Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.

100% pokrytí testy nelze dosáhnout ani teoreticky, protože Halting problem: https://en.wikipedia.org/wiki/Halting_problem (https://en.wikipedia.org/wiki/Halting_problem)

Doporučuju, Kite, nastudovat alespoň základy computer science, nebudeš se potom tady na fóru ztrapňovat tak často. A než začneš argumetovat tím, že je to jen teoretická konstrukce a nic takového, jako počítač s nekonečnou pamětí neexistuje, přečti si na wikipedii ten odstavec, který začíná The halting problem is theoretically decidable for linear bounded automata... a pochopíš, že to reálně opravdu udělat nejde.

Nikde jsem netvrdil, že 100% pokrytí testy lze dosáhnout. Stejně tak nelze 100 % funkcionality pokrýt typy.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 10:33:06
Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.
Ke slovesu pokrytí se váže předmět – tedy pokrytí čeho. Nemá smysl se tady dohadovat a neustále používat nevyjádřený předmět, když je zřejmé, že každý za předmět považuje něco jiného. Obvykle se „pokrytím testy“ myslí pokrytí kódu, tedy 100% pokrytí testy by znamenal pokrytí všech řádků/instrukcí. Které samozřejmě nezaručuje skoro nic, rozhodně nezaručuje bezchybnost. Vy asi myslíte 100% pokrytí všech možných případů, což je u jenom trošku větších věcí nedosažitelné.

Je to dosažitelné, pokud testované jednotky jsou dostatečně malé a jednoduché (SRP).
Tzn. mají na vstupu málo parametrů (které nejsou typově omezené....) a vevnitř málo podmínek a radši toho moc nevolají... Jinak řečeno pro nějaký normální program nedosažitelné.
Název: Re:Typový system versus unittesty
Přispěvatel: netypová lopata 26. 06. 2018, 10:38:48
100% pokrytí testy nelze dosáhnout ani teoreticky, protože Halting problem: https://en.wikipedia.org/wiki/Halting_problem (https://en.wikipedia.org/wiki/Halting_problem)

Doporučuju, Kite, nastudovat alespoň základy computer science, nebudeš se potom tady na fóru ztrapňovat tak často. A než začneš argumetovat tím, že je to jen teoretická konstrukce a nic takového, jako počítač s nekonečnou pamětí neexistuje, přečti si na wikipedii ten odstavec, který začíná The halting problem is theoretically decidable for linear bounded automata... a pochopíš, že to reálně opravdu udělat nejde.

Nikde jsem netvrdil, že 100% pokrytí testy lze dosáhnout. Stejně tak nelze 100 % funkcionality pokrýt typy.

Jsi nějaký nekonzistentní, chlapče:
100% pokrytí všech možných případů, což je u jenom trošku větších věcí nedosažitelné.
Je to dosažitelné, pokud testované jednotky jsou dostatečně malé a jednoduché (SRP).
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 10:42:15
No hlavně pokud 100% pokrytí nelze dosáhnout, tak je možné komukoliv, kdo tvrdí, že má 100% pokrytí říct, že prostě nemá... protože to přece nejde dosáhnout  :P
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 10:46:34
Typ Maybe fakt není assert.
Nic takového jsem nepsal. Napsal jsem, že „null pointer exception“ můžete řešit pomocí typů (mít typ, který NIL hodnotu nepřipustí), pomocí assertů (typ připouští NIL, ale na vstupu deklarujete pomocí assertu, že NIL je neplatná vstupní hodnota) a můžete to ošetřit testem (který NIL hodnotu pošle na vstupu a otestuje, zda se kód zachová očekávaným způsobem). To jsou různé způsoby zápisu kódu, a druhá věc je, co s tím pak dělá kompilátor. U typů je to nejjednodušší, tam se tak nějak očekává, že kompilátor tuto informaci použije. Ale kompilátor může použít i jiné informace, třeba z anotací nebo právě assertů – třeba IntelliJ Idea dělá analýzu kódu (je to obohacený kompilátor) a na základě toho odvozuje, zda se jedná o nullable nebo non-null typ. Takže ve zdrojovém kódu ten typ není uveden, při kompilaci se pomocí type inference odvodí, ale pak se dostane ke slovu type erasure a do zkompilovaného kódu se informace o typu opět nedostane (resp. je tam obecnější nullable typ).

Pokud programátor napíše "int x = (unsafeCoerce) 'string'", tak ho fakt nic nezachrání. Ale řekl bych, že je dost velký rozdíl mezi tímto a jazykem, kde člověk může napsat akorát "x = 'string' # comment: x je typu int".
Někdy v tom je velký rozdíl a někdy prakticky žádný. Existují různé problémy, takže i nástroje k jejich řešení jsou různé. Na něco se hodí programovací jazyk s bohatým typovým systémem, na něco typy vůbec nepotřebujete.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 10:47:42
jak by teda vypadaly testy pro 100% pokrytí tohoto kódu v pythonu:
Kód: [Vybrat]
def x(y, z): return y + z

Stačí jeden test, který selže:
Kód: [Vybrat]
def testX(): assert(x("Ahoj", 42)=="Ahoj42")
Položil jsi otázku chybně. Nemáš funkci x. Zadáním pro test je: Napište funkci x, která sečte hodnoty parametrů. V tomto zadání však chybí specifikace parametrů. Co když na vstup někdo dá dva stringy nebo číslo a string? V posledně jmenovaném případu fuknce, kterou jsi nedůvodně napsal jako první, zahlásí chybu.

Název: Re:Typový system versus unittesty
Přispěvatel: Kamil Podlešák 26. 06. 2018, 10:57:20
100% pokrytí (pozor na to že jsou dvě metriky - podle řádek a podle větví!) říká jen to, že všechen kód prošel alespoň jednou. Dává nám jistotu, že v kódu nejsou vyloženě dementní chyby typu překlepů, opačných podmínek, přehozených proměnných stejného typu, použití špatného typu (v případě jazyků bez typové kontroly při překladu) a podobně.

Unittesty rozhodně nezaručí (a v principu nemohou) správnou funkci pro všechny možné hodnoty daných typů, nebo dokonce všechny kombinace. To se dá zajistit typovým systémem, ale ne tím v mainstream jazycích :-)

TLDR: Unittest je nástroj sloužící především autorovi kódu k tomu, aby nebyl za debila.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 11:02:00
trochu offtopic, ale nemáte někdo nějakou teorii tohohle vehementního odmítání moderních technologií?
Nevšiml jsem si, že by tu někdo odmítal moderní technologie. Vidím tu jen nekritické přijímání něčeho, čemu dotyčný moc nerozumí, ale je to pro něj nové (ve skutečnosti to ale ani nic nového není), a má pocit, že to vyřeší všechny problémy světa. Na technologiích není důležité to, jestli jsou nové, ale jaké problémy umí (doopravdy) řešit.
mj. jsem narážel na to vaše "sebelepší typový systém nemůže..."
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 11:11:07
jak by teda vypadaly testy pro 100% pokrytí tohoto kódu v pythonu:
Kód: [Vybrat]
def x(y, z): return y + z

Stačí jeden test, který selže:
Kód: [Vybrat]
def testX(): assert(x("Ahoj", 42)=="Ahoj42")
Položil jsi otázku chybně. Nemáš funkci x. Zadáním pro test je: Napište funkci x, která sečte hodnoty parametrů. V tomto zadání však chybí specifikace parametrů. Co když na vstup někdo dá dva stringy nebo číslo a string? V posledně jmenovaném případu fuknce, kterou jsi nedůvodně napsal jako první, zahlásí chybu.
děkuji za odpověď
předpokládejme tu vaši specifikaci ("sečte hodnoty parametrů") a zahoďme moji funkci, jak budou vypadat testy?
Název: Re:Typový system versus unittesty
Přispěvatel: Phi 26. 06. 2018, 11:11:33
Kocouři, když se tu hádáte - jste si vědomi toho že "pokrytí" je dost vágní výraz a že se můžeme bavit jak o pokrytí usecasů tak o pokrytí kódu a u pokrytí kódů se zase můžeme, já nevím, snad o tuctu metrik, od function coverage přes branch coverage po statement coverage?
Halting problem se týká univerzálního algoritmu který by dokázal pro jakýkoliv program s jakýmkoliv vstupem rozhodnout, zda dokončí nebo nedokončí běh. Turing nikdy neřekl, že neexistuje algoritmus, který by pro konkrétní program nedokázal rozhodnout, zda dokončí či nedokončí. To je velký rozdíl.
100% coverage (kteréhokoliv druhů) samozřejmě možná je, jen je neskutečně drahá pro cokoliv co není triviální aplikace.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 11:15:41
Typ Maybe fakt není assert.
Nic takového jsem nepsal. Napsal jsem, že „null pointer exception“ můžete řešit pomocí typů (mít typ, který NIL hodnotu nepřipustí), pomocí assertů (typ připouští NIL, ale na vstupu deklarujete pomocí assertu, že NIL je neplatná vstupní hodnota) a můžete to ošetřit testem (který NIL hodnotu pošle na vstupu a otestuje, zda se kód zachová očekávaným způsobem). To jsou různé způsoby zápisu kódu, a druhá věc je, co s tím pak dělá kompilátor. U typů je to nejjednodušší, tam se tak nějak očekává, že kompilátor tuto informaci použije. Ale kompilátor může použít i jiné informace, třeba z anotací nebo právě assertů – třeba IntelliJ Idea dělá analýzu kódu (je to obohacený kompilátor) a na základě toho odvozuje, zda se jedná o nullable nebo non-null typ. Takže ve zdrojovém kódu ten typ není uveden, při kompilaci se pomocí type inference odvodí, ale pak se dostane ke slovu type erasure a do zkompilovaného kódu se informace o typu opět nedostane (resp. je tam obecnější nullable typ).
Musel jsem si dohledal, na co jsem reagoval a bylo to toto:
Citace
I tenhle typ chyby se bude objevovat u sebelepšího typového systému, protože když programátora nenapadne, že to je zajímavý případ a měl by na to udělat test, nenapadne ho ani ošetřit to v typovém systému.
Tak bych si dovolil tvrdit, že programátora v jazyce s ADT null pointer exception chybu řešit fakt napadne, protože tam jinak ten "null" nedostane, zatímco u assertu toho programátor fakt mnohokrát nenapadne tam ten assert vůbec dát. Takže konkrétně nullpointerexception mi připadá jako protipříklad Tvého tvrzení, a nepřipadá mi, že by cokoliv, co jsi napsal poté (byť třeba s tím odstavcem výše souhlasím) jakkoliv tu ideu, že typový systém a unit testy jsou srovnatelné, protože v obojím může udělat programátor chybu, podporovalo.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 11:21:32
mj. jsem narážel na to vaše "sebelepší typový systém nemůže..."
To ale není odmítání moderních technologií nýbrž pouhé konstatování faktu. Když mne někdo bude přesvědčovat, že má vymyšlený stroj, do kterého nemusí vkládat žádnou energii a ten stroj jí vyrábí, a že už mu to skoro funguje, jenom ještě dořeší nějaké detaily, odmítnu to. Ne proto, že bych odmítal moderní technologie, ale proto, že podle současného stavu poznání perpetuum mobile nelze vyrobit.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 11:23:10
mj. jsem narážel na to vaše "sebelepší typový systém nemůže..."
To ale není odmítání moderních technologií nýbrž pouhé konstatování faktu. Když mne někdo bude přesvědčovat, že má vymyšlený stroj, do kterého nemusí vkládat žádnou energii a ten stroj jí vyrábí, a že už mu to skoro funguje, jenom ještě dořeší nějaké detaily, odmítnu to. Ne proto, že bych odmítal moderní technologie, ale proto, že podle současného stavu poznání perpetuum mobile nelze vyrobit.
a jste si jistý, že ten současný stav poznání máte podchycený? teď narážím na "dependent types"
Název: Re:Typový system versus unittesty
Přispěvatel: netypová lopata 26. 06. 2018, 11:47:42
Halting problem se týká univerzálního algoritmu který by dokázal pro jakýkoliv program s jakýmkoliv vstupem rozhodnout, zda dokončí nebo nedokončí běh. Turing nikdy neřekl, že neexistuje algoritmus, který by pro konkrétní program nedokázal rozhodnout, zda dokončí či nedokončí. To je velký rozdíl.

Zjevně jsi nepřečetl ten odstavec, který jsem doporučoval:

The halting problem is theoretically decidable for linear bounded automata (LBAs) or deterministic machines with finite memory. Minsky warns us, however, that machines such as computers with e.g., a million small parts, each with two states, will have at least 21,000,000 possible states: This is a 1 followed by about three hundred thousand zeroes ... Even if such a machine were to operate at the frequencies of cosmic rays, the aeons of galactic evolution would be as nothing compared to the time of a journey through such a cycle.

V dněšních počítačích a běžných programech je těch stavů ještě o mnoho řádů více. Mnoho štěstí s testováním.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 26. 06. 2018, 11:53:39
...Stoprocentní pokrytí kódu testy znamená, že se při testech projdou všechny „řádky“ (ve skutečnosti instrukce) programu...

Toto je chybné tvrzení. Vy sám jste napsal, že testy nesmějí obsahovat algoritmus, neboli duplikovat implementaci. Úkolem testů není ověření samotné implementace, ale ověření správnosti výstupů pro všechny kombinace možných vstupů, to je 100% pokrytí testem. To je ale obvykle nereálné, takže alespoň jejich části.
To spolu ale nesouvisí. Testy mohou pokrývat 100 % kódu, tj. při spuštění testů se spustí všechny instrukce kódu. To ale vůbec neznamená, že by test duplikoval implementaci. Za „pokrytí testy“ se obvykle označuje právě poměr počtu instrukcí procházených při testech k celkovému počtu instrukcí knihovny či aplikace, protože to se dá změřit. To je reálné (i když to nemusí být nutné, protože chybějící testy mohou nepokrývat nezajímavé části kódu), ale v žádném případě to neříká, že by se testovaly všechny možné vstupy, nebo že by program byl bezchybný, pokud testy projdou. Ukazatel „pokrytí kódu/řádků/instrukcí testy“ má opačný význam – pokud určitá větev programu není testem pokrytá, víme určitě, že pomocí testů určitě nedokážeme poznat, zda v dané části chyba je nebo není.

To se mi nějak nezdá - 100% pokrytím někteří myslí pokrytí celého protokolu objektu, tj. viditelných metod. Že testy nespustí některý vnitřní kód, nemusí znamenat vůbec nic, např. část kódu je nevyužitá (např. před refaktorizací). Nebo si představte, že vytvoříte testy cizí knihovny, do které vůbec nevidíte.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 26. 06. 2018, 12:07:56
Halting problem se týká univerzálního algoritmu který by dokázal pro jakýkoliv program s jakýmkoliv vstupem rozhodnout, zda dokončí nebo nedokončí běh. Turing nikdy neřekl, že neexistuje algoritmus, který by pro konkrétní program nedokázal rozhodnout, zda dokončí či nedokončí. To je velký rozdíl.

Zjevně jsi nepřečetl ten odstavec, který jsem doporučoval:

...
V dněšních počítačích a běžných programech je těch stavů ještě o mnoho řádů více. Mnoho štěstí s testováním.

Phi má recht, obecně to nejde, ale ve speciálních (neřešíme ale, jak často!) ano:

class Vědma:
    odpověďNaOtázkuŽivota():
        return 42

testVědmy:
    assert(Vědma().odpověďNaOtázkuŽivota() == 42)

A je to pokryto. Důkaz sporem.
Název: Re:Typový system versus unittesty
Přispěvatel: netypová lopata 26. 06. 2018, 12:24:08
Phi má recht, obecně to nejde, ale ve speciálních (neřešíme ale, jak často!) ano:

Já ale řeším, jak často. Je hezké, že jsi z nekonečného prostoru možných programů vytáhl jeden (který je mimochodem úplně k ničemu), na kterém něco prokážeš. Praktický přínos je nicméně nulový. Pro každý netriviální běžný program, který něco rozumného dělá, tvoje metoda selže. Lidé obvykle chtějí otestovat bežné programy, které mají nějaký užitek. A to neumíme, nedokážeme říct se 100% jistotou, že je program správný, nemáme na to metodu.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 12:28:00
předpokládejme tu vaši specifikaci ("sečte hodnoty parametrů") a zahoďme moji funkci, jak budou vypadat testy?

Tak především se test nekouká dovnitř, ale zvenčí. A kouká se jen na vlastnosti, které jsou od té funkce požadovány. Pokud je požadavkem "sečíst hodnotu numerických parametrů", tak obvykle stačí třeba:
Kód: [Vybrat]
def testX():
    assert(x(3, 5) == 8)
    assert(x(-3, 5) == 2)
    assert(x(3, -5) == -2)
    assert(x(-3, -5) == -8)

Pokud nebudu mít na vstupu např. záporná čísla, mohu odpovídající testy vypustit. Pokud budu chtít touto funkcí spojvat i řetězce nebo posouvat čas o offset, tak je do testu přidám. Pokud potřebuji, aby funkce při výsledku nad hodnotu 100 vyhodila výjimku nebo ten výsledek ořízla (např. životy u her), tak tam takový test také přidám. Dříve definovaná funkce tím přestane procházet a vývojář ji musí upravit.

Tímto způsobem mohu testovat i cizí knihovny, do kterých nevidím, ale očekávám od nich určité chování pro různé očekávané i méně očekávané vstupy. Pokud její autor změní něco, co bude mít vliv na moji aplikaci, dozvím se to.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 12:28:11
Tak bych si dovolil tvrdit, že programátora v jazyce s ADT null pointer exception chybu řešit fakt napadne, protože tam jinak ten "null" nedostane, zatímco u assertu toho programátor fakt mnohokrát nenapadne tam ten assert vůbec dát.
To záleží na kontextu. Pokud se bude pohybovat v kódu, kde bude většina typů non-null, a výjimečně narazí na nullable typ, ošetří to. Pokud bude z venku neustále dostávat nullable typy a použité typy a typový systém ho budou nutit neustále to přetypovávat, bude to dělat automaticky bez přemýšlení.

Takže bych to upřesnil, že komplexnější typový systém sám o sobě nic nezaručuje, pouze dává větší možnosti. A je na jeho uživatelích, zda ty možnosti využijí – přičemž je potřeba počítat i s tím, že (i podle typů projektů) je různá úroveň programátorů, a nedá se počítat s tím, že ty miliony webových aplikací budou programovat lidé, kteří budou důsledně používat složitý typový systém – bylo by to příliš drahé. Je ale dobré, když se podaří (jako to má třeba Google) využít typový systém v důležitých částech tak, že ty typy nadefinují specialisté, a řádový programátor pak už jen používá typy „obyčejný text“ (který nemůže do HTML vypsat jinak, než escapovaně), a typ „HTML text“, který se při výstupu do HTML neescapuje, ale zase v něm není možné vytvořit nebezpečnou HTML konstrukci (např. náchylnou na XSS).

Takže konkrétně nullpointerexception mi připadá jako protipříklad Tvého tvrzení, a nepřipadá mi, že by cokoliv, co jsi napsal poté (byť třeba s tím odstavcem výše souhlasím) jakkoliv tu ideu, že typový systém a unit testy jsou srovnatelné, protože v obojím může udělat programátor chybu, podporovalo.
Já ale netvrdím, že typový systém a jednotkové testy jsou srovnatelné. Tvrdím, že naopak každý řeší něco jiného, takže obecně nejsou navzájem nahraditelné – i když existuje určitá oblast, kterou je možné řešit oběma způsoby, a když používáte slabší typy, je vhodné danou oblast kontrolovat pomocí jednotkových testů. Jako v tom příkladu s XSS – kdo nepoužívá typy pro bezpečné HTML, jako Google, měl by mít alespoň jednotkové testy snažící se XSS odhalit (což je zrovna dost obtížné a podle mne je snazší řešit to pomocí těch typů).
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 12:31:27
Phi má recht, obecně to nejde, ale ve speciálních (neřešíme ale, jak často!) ano:

Já ale řeším, jak často. Je hezké, že jsi z nekonečného prostoru možných programů vytáhl jeden (který je mimochodem úplně k ničemu), na kterém něco prokážeš. Praktický přínos je nicméně nulový. Pro každý netriviální běžný program, který něco rozumného dělá, tvoje metoda selže. Lidé obvykle chtějí otestovat bežné programy, které mají nějaký užitek. A to neumíme, nedokážeme říct se 100% jistotou, že je program správný, nemáme na to metodu.

Zrovna kontrola, zda mají externí konstanty jednotky správné hodnoty, do testů patří.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 12:33:16
To se mi nějak nezdá - 100% pokrytím někteří myslí pokrytí celého protokolu objektu, tj. viditelných metod. Že testy nespustí některý vnitřní kód, nemusí znamenat vůbec nic, např. část kódu je nevyužitá (např. před refaktorizací). Nebo si představte, že vytvoříte testy cizí knihovny, do které vůbec nevidíte.
Pokrytí všech instrukcí kódu je to jediné, co se dá relativně snadno změřit, proto to bývá jedna z metrik, které se měří při sestavení projektu. Takže když na nějakém výstupu (třeba od https://codecov.io/) uvidíte metriku „pokrytí testy“, je to právě tohle. Jinak samozřejmě „pokrytí testy“ může znamenat i ledacos jiného, pak by ale každý, kdo to spojení použije, měl uvést, co tím vlastně myslím. Jinak to dopadne jako tady, kde se několik lidí hádá o pokrytí testy, a přitom tím každý myslí něco jiného.
Název: Re:Typový system versus unittesty
Přispěvatel: Ondra Satai Nekola 26. 06. 2018, 12:35:20
Chápu správně, že tvá definice "100% pokrytí" == "kód pracuje správně"?
Je snad jiná definice 100% pokrytí testy? Pokud se test tváří, že pokrývá nějakou vlastnost, ale ve skutečnosti nedělá nic, tak do této statistiky nemůže být zahrnut.
Pokud definuješ 100% pokrytí testy jako "kód pracuje správně", tak pak tvoje rada zní "pište programy správně"...

Zajímavá implikace. Na to jsi přišel matematickými postupy?

Pokud testy prochází a program přitom nepracuje správně, nemohu tvrdit, že má 100% pokrytí testy.

Samozreme, ze muzes. Pokryti testy je jedna metrika, kvalita tech testu vec jina...
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 12:51:08
a jste si jistý, že ten současný stav poznání máte podchycený? teď narážím na "dependent types"
Ano, jsem si tím jistý.

V různých dobách se perpetua mobile vytvářejí na základě v té době moderních věcí – někdy to byl „magnétismus“, někdy „paprsky X“, jindy „elektřina“, dneska to často budou „kvantové jevy“, „energie vakua“ nebo nejnověji nejspíš „temná hmota“. Což nic nemění na tom, že nemožnost konstrukce perpetua mobile plyne z fundamentálních zákonů, a nemusíme znát detailní fungování temné hmoty, nemusíme mít sjednocenou teorii gravitace a kvantové teorie, nemusíme tušit, co se ve fyzice objeví za padesát nebo za sto let, pořád si ale můžeme býti dost jistí, že ani pak nepůjde zkonstruovat perpetuum mobile.

Stejně tak si můžeme být dost jistí, že nepůjde mechanicky zkontrolovat, zda program bude fungovat správně – například i proto, že „správné fungování“ je subjektivní věc, a co může být v jednom případě považováno za správné fungování, v jiném případě tak být nemusí.

Pak je podstatná ještě jedna věc, která tu zatím moc nebyla zmíněna, a to je to, že typový systém může něco užitečného přinést jedině tehdy, když se používá, tedy když ho programátoři chtějí používat. Stačí se podívat na takové malinké vylepšení hloupého typového systému Javy, jakým jsou kontrolované výjimky. Ani tohle drobné typové omezení se prakticky neujalo, a to je velmi jednoduché kontrolované výjimky jak definovat, tak používat. I to připadá většině Java vývojářů jako zbytečně moc práce v porovnání s jejím přínosem. Takže navrhovat nové typy pro masové použití klidně můžete, ale pak se vám také klidně může stát, že budou vznikat a široce se používat knihovny, které budou jako jednu ze svých důležitých vlastností uvádět to, že ruší ten váš typový systém.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 13:18:15
Tak bych si dovolil tvrdit, že programátora v jazyce s ADT null pointer exception chybu řešit fakt napadne, protože tam jinak ten "null" nedostane, zatímco u assertu toho programátor fakt mnohokrát nenapadne tam ten assert vůbec dát.
To záleží na kontextu. Pokud se bude pohybovat v kódu, kde bude většina typů non-null, a výjimečně narazí na nullable typ, ošetří to. Pokud bude z venku neustále dostávat nullable typy a použité typy a typový systém ho budou nutit neustále to přetypovávat, bude to dělat automaticky bez přemýšlení.
Ano, a to jsem přesně měl na mysli, když jsem říkal, že typ Maybe není totéž co assert. Ukázka (ne-generického) dekódování JSONu s non-null a jedním nullable typem ..
Kód: [Vybrat]
data Obj {
    a :: Int
  , b :: Text
  , c :: [Int]
  , d :: NonEmpty Int -- neprazdne pole
  , e :: Maybe Double
  , f :: UTCTime
}
instance FromJSON Obj where
  parseJSON = withObject $ \o ->
     Obj <$> o .: "alpha" <*> o .: "beta" <*> o .: "cyril" <*> o .: "delta" <*> o .: "edward" <*> f .: "ftime"
Máš pravdu, když to píšu, tak to píšu bez přemýšlení... až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....

Jinak pokud jde o XSS, tak bych neřekl, že je to principálně věc typů.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 13:22:34
a jste si jistý, že ten současný stav poznání máte podchycený? teď narážím na "dependent types"
Ano, jsem si tím jistý.
z jakých materiálů jste čerpal? popř. v jakém jazyce jste to zkoušel?
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 13:23:11
Citace: andy
Jinak pokud jde o XSS, tak bych neřekl, že je to principálně věc typů.
Beru zpět, ano XSS jde řešit typy a zrovna docela hezky.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 13:26:04
Citace: andy
Jinak pokud jde o XSS, tak bych neřekl, že je to principálně věc typů.
Beru zpět, ano XSS jde řešit typy a zrovna docela hezky.
odkaz by nebyl?
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 26. 06. 2018, 13:30:06
Pak je podstatná ještě jedna věc, která tu zatím moc nebyla zmíněna, a to je to, že typový systém může něco užitečného přinést jedině tehdy, když se používá, tedy když ho programátoři chtějí používat. Stačí se podívat na takové malinké vylepšení hloupého typového systému Javy, jakým jsou kontrolované výjimky. Ani tohle drobné typové omezení se prakticky neujalo, a to je velmi jednoduché kontrolované výjimky jak definovat, tak používat. I to připadá většině Java vývojářů jako zbytečně moc práce v porovnání s jejím přínosem. Takže navrhovat nové typy pro masové použití klidně můžete, ale pak se vám také klidně může stát, že budou vznikat a široce se používat knihovny, které budou jako jednu ze svých důležitých vlastností uvádět to, že ruší ten váš typový systém.

Kdyby ten system za neco stal, ve smyslu ze pridana hodnota prevysi overhead ktery prinasi, tak by ho programatori radi pouzivali. Jenze tomu tak v jave prave neni.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 13:36:56
z jakých materiálů jste čerpal? popř. v jakém jazyce jste to zkoušel?
„Ale to je magnétismus, to je úplně nová fyzika, nechoďte na mně s nějakým zastaralým zákonem o zachování energie. Říkám vám, že mi to funguje, jenom maličko točit klikou musíte, ale to se doladí, to už jsou jenom takové maličkosti, jenom najít ten správný mazací olej…“
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 13:39:46
Máš pravdu, když to píšu, tak to píšu bez přemýšlení... až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....
Kdybych to psal v dynamickém jazyku, tak asi proto, abych typy nemusel řešit a poradilo si to s co největší škálou různých (i ne zcela správných) vstupů. Podle toho by vypadaly i jednotkové testy – poslal bych do toho JSON, kde by chyběly položky, místo Intu by tam bylo číslo jako text, text nepřevoditelný na číslo, null…
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 13:42:53
Citace: andy
Jinak pokud jde o XSS, tak bych neřekl, že je to principálně věc typů.
Beru zpět, ano XSS jde řešit typy a zrovna docela hezky.
odkaz by nebyl?
Jakub Vrána mluvil na Devel.cz o tom, jak to dělají v Googlu – Dokazatelná bezpečnost (https://slideslive.com/38908443/dokazatelna-bezpecnost).
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 13:43:10
z jakých materiálů jste čerpal? popř. v jakém jazyce jste to zkoušel?
„Ale to je magnétismus, to je úplně nová fyzika, nechoďte na mně s nějakým zastaralým zákonem o zachování energie. Říkám vám, že mi to funguje, jenom maličko točit klikou musíte, ale to se doladí, to už jsou jenom takové maličkosti, jenom najít ten správný mazací olej…“
ne magnétismus, "dependent types", jakožto příklad současného stavu věcí
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 13:47:15
Citace: andy
Jinak pokud jde o XSS, tak bych neřekl, že je to principálně věc typů.
Beru zpět, ano XSS jde řešit typy a zrovna docela hezky.
odkaz by nebyl?
Nebyl, ale v podstatě to tak řeší všichni - HTML výstup si obalit typem, který lze modifikovat/vytvářet pouze funkcemi, které dělají escaping.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 14:00:09
nuda, ale zjevně funkční
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 14:00:55
Máš pravdu, když to píšu, tak to píšu bez přemýšlení... až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....
Kdybych to psal v dynamickém jazyku, tak asi proto, abych typy nemusel řešit a poradilo si to s co největší škálou různých (i ne zcela správných) vstupů. Podle toho by vypadaly i jednotkové testy – poslal bych do toho JSON, kde by chyběly položky, místo Intu by tam bylo číslo jako text, text nepřevoditelný na číslo, null…
To by mě zajímalo, proč bys zrovna z těchto důvodů tohle psal v dynamickém jazyku.... kvůli tomu zpracování přece v té výsledné struktuře nakonec stejně chceš "Int" a ne text, a když tam nemá být null, tak stejně musíš kontrolovat, že tam není null...

ale zpět - já fakt nesouhlasím s:
Citace
To záleží na kontextu. Pokud se bude pohybovat v kódu, kde bude většina typů non-null, a výjimečně narazí na nullable typ, ošetří to. Pokud bude z venku neustále dostávat nullable typy a použité typy a typový systém ho budou nutit neustále to přetypovávat, bude to dělat automaticky bez přemýšlení.
a řekl bych že výše uvedený příklad ukazuje, že to prostě není pravda.

A ze stejných důvodů nesouhlasím s tímto:
Citace
I tenhle typ chyby se bude objevovat u sebelepšího typového systému, protože když programátora nenapadne, že to je zajímavý případ a měl by na to udělat test, nenapadne ho ani ošetřit to v typovém systému.
Protože například u té nullpointerexception je prostě používání "Maybe" typu na úplně jiné úrovni než dávat někam asserty a psát k tomu unit testy. V podstatě je to ekvivalentní těm "model checker" systémům. A dost mi to připomíná toto:
Citace
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 26. 06. 2018, 14:05:26
Obvykle stačí testovat chování pro limitní a nadlimitní hodnoty vstupů. Testy tak vychází jen asi 2× delší než testovaný kód.
v dynamickém jazce? postněte nějaký jednoduchý příklad (funkce+testy), bylo by zajímavé zkusit co s tím udělá zavedení typů

Zavedení dalších typů s tím neudělá vůbec nic, protože typy nezkoumají funkčnost.
Zkoumají. Už to ty bylo vysvětlováno.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 14:12:26
předpokládejme tu vaši specifikaci ("sečte hodnoty parametrů") a zahoďme moji funkci, jak budou vypadat testy?

Tak především se test nekouká dovnitř, ale zvenčí. A kouká se jen na vlastnosti, které jsou od té funkce požadovány. Pokud je požadavkem "sečíst hodnotu numerických parametrů", tak obvykle stačí třeba:
Kód: [Vybrat]
def testX():
    assert(x(3, 5) == 8)
    assert(x(-3, 5) == 2)
    assert(x(3, -5) == -2)
    assert(x(-3, -5) == -8)

Pokud nebudu mít na vstupu např. záporná čísla, mohu odpovídající testy vypustit. Pokud budu chtít touto funkcí spojvat i řetězce nebo posouvat čas o offset, tak je do testu přidám. Pokud potřebuji, aby funkce při výsledku nad hodnotu 100 vyhodila výjimku nebo ten výsledek ořízla (např. životy u her), tak tam takový test také přidám. Dříve definovaná funkce tím přestane procházet a vývojář ji musí upravit.

Tímto způsobem mohu testovat i cizí knihovny, do kterých nevidím, ale očekávám od nich určité chování pro různé očekávané i méně očekávané vstupy. Pokud její autor změní něco, co bude mít vliv na moji aplikaci, dozvím se to.
dík za doplnění, asi nemá smysl to dál rozebírat, z mojeho pohledu je to slaboučké, nelíbí se mi, že musím doufat, že do toho nikdo nepošle něco s čím jsem nepočítal
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 26. 06. 2018, 14:15:04
100% coverage (kteréhokoliv druhů) samozřejmě možná je, jen je neskutečně drahá pro cokoliv co není triviální aplikace.

Já měl funkci, která byla hlášena jako 100% pokryta. Prostě to už někdo napsal.

Druhak, v případě Typového systému máme 100% pokrytí z principu vždy. A kdo zaplatí tu cenu se posouvá od vývojáře aplikace k architektovi typového systému. A tam se samozřejmě rozhoduje, že něco Typama podchycovat nebudeme, protože něco, a pak se to tedy řeší (a nebo taky často ne) testy.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 26. 06. 2018, 14:17:08
Halting problem se týká univerzálního algoritmu který by dokázal pro jakýkoliv program s jakýmkoliv vstupem rozhodnout, zda dokončí nebo nedokončí běh. Turing nikdy neřekl, že neexistuje algoritmus, který by pro konkrétní program nedokázal rozhodnout, zda dokončí či nedokončí. To je velký rozdíl.

Zjevně jsi nepřečetl ten odstavec, který jsem doporučoval:

...
V dněšních počítačích a běžných programech je těch stavů ještě o mnoho řádů více. Mnoho štěstí s testováním.

Phi má recht, obecně to nejde, ale ve speciálních (neřešíme ale, jak často!) ano:

class Vědma:
    odpověďNaOtázkuŽivota():
        return 42

testVědmy:
    assert(Vědma().odpověďNaOtázkuŽivota() == 42)

A je to pokryto. Důkaz sporem.

Počkej, počkej, ještě musíš otestovat negativní případy :-)
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 14:20:39
dík za doplnění, asi nemá smysl to dál rozebírat, z mojeho pohledu je to slaboučké, nelíbí se mi, že musím doufat, že do toho nikdo nepošle něco s čím jsem nepočítal

To nebylo v zadání. Zcela v něm chybělo, jak se ta funkce má chovat, pokud dostane nějaké vstupy, které mají být z nějakého důvodu nevalidní.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 14:23:42
dík za doplnění, asi nemá smysl to dál rozebírat, z mojeho pohledu je to slaboučké, nelíbí se mi, že musím doufat, že do toho nikdo nepošle něco s čím jsem nepočítal

To nebylo v zadání. Zcela v něm chybělo, jak se ta funkce má chovat, pokud dostane nějaké vstupy, které mají být z nějakého důvodu nevalidní.
no právě, jakékoliv podmínky bych vymyslel, furt musím doufat, že volající je dodrží
Název: Re:Typový system versus unittesty
Přispěvatel: SB 26. 06. 2018, 14:34:33
Kód: [Vybrat]
data Obj {
    a :: Int
  , b :: Text
  , c :: [Int]
  , d :: NonEmpty Int -- neprazdne pole
  , e :: Maybe Double
  , f :: UTCTime
}
instance FromJSON Obj where
  parseJSON = withObject $ \o ->
     Obj <$> o .: "alpha" <*> o .: "beta" <*> o .: "cyril" <*> o .: "delta" <*> o .: "edward" <*> f .: "ftime"
...až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....

Tak především v OOP je (z podstaty) starostí objektu, aby si okontroloval, čím se plní, a naplnění i sám provedl (přestože to tak mnozí nedělají a omrdávají to jakýmisi dírami v implementaci, nebo anemickým modelem). Na to stačí metoda fromJson(json), fromDict(dict) atp. obsahující kontroly (klidně včetně rozsahů hodnot!) a jejich uložení. Jednotkovému testu stačí vyzkoušet, zda objekt pro daná data je možno vytvořit.

P. S.: Co je to zač hen ten paskvil, ve kterém jste to psal, nejde tomu ani rozumět...
Název: Re:Typový system versus unittesty
Přispěvatel: SB 26. 06. 2018, 14:41:20
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 14:47:26
dík za doplnění, asi nemá smysl to dál rozebírat, z mojeho pohledu je to slaboučké, nelíbí se mi, že musím doufat, že do toho nikdo nepošle něco s čím jsem nepočítal

To nebylo v zadání. Zcela v něm chybělo, jak se ta funkce má chovat, pokud dostane nějaké vstupy, které mají být z nějakého důvodu nevalidní.
no právě, jakékoliv podmínky bych vymyslel, furt musím doufat, že volající je dodrží

Jenže to je obráceně. Volající musí definovat, jaké vstupy má funkce předpokládat a které má odmítat. Ani jsi nedefinoval, že vstupy musí být int nebo string. Nic. Není tedy co testovat.

Mám tady i testy, které otestují chování pro rozdílné typy argumentů. Jenže jsi je nechtěl. Proč bych měl dávat do testů podmínky, které nejsou požadovány? Netestuji samotnou funkci, ale jen zda vyhovuje požadavkům na ni kladenou.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 26. 06. 2018, 14:48:08
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?
Tak povídej :-)
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 14:48:47
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?

To jen BoneFlute trolil. Nestála za povšimnutí.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 26. 06. 2018, 14:49:50
Ani jsi nedefinoval, že vstupy musí být int nebo string. Nic. Není tedy co testovat.
Počkej, počkej, máš to otestovat. Ne typovat. Hezky si to otestuj bez použití typů :-P
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 14:50:41
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?
já jsem to pochopil tak, že typová kontrola probíhá vždy nad celým kódem, ne jako test nad malou částí
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 14:54:54
dík za doplnění, asi nemá smysl to dál rozebírat, z mojeho pohledu je to slaboučké, nelíbí se mi, že musím doufat, že do toho nikdo nepošle něco s čím jsem nepočítal

To nebylo v zadání. Zcela v něm chybělo, jak se ta funkce má chovat, pokud dostane nějaké vstupy, které mají být z nějakého důvodu nevalidní.
no právě, jakékoliv podmínky bych vymyslel, furt musím doufat, že volající je dodrží

Jenže to je obráceně. Volající musí definovat, jaké vstupy má funkce předpokládat a které má odmítat. Ani jsi nedefinoval, že vstupy musí být int nebo string. Nic. Není tedy co testovat.

Mám tady i testy, které otestují chování pro rozdílné typy argumentů. Jenže jsi je nechtěl. Proč bych měl dávat do testů podmínky, které nejsou požadovány? Netestuji samotnou funkci, ale jen zda vyhovuje požadavkům na ni kladenou.
však to je přesně ono, není záruka, že volající něco dodrží
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 26. 06. 2018, 14:58:01
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?
Tak povídej :-)
Pokryti ceho a cim?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 15:02:01
To by mě zajímalo, proč bys zrovna z těchto důvodů tohle psal v dynamickém jazyku....
Že je to dynamický jazyk přece bylo vaše zadání. Kdybych chtěl kontrolovat, že jsou tam správné typy, budu to kontrolovat, a jednotkové testy budou dělat to, že budou mít vstupy s různě pokaženými typy a budou testovat, že funkce pro načtení dat skončí správnou chybou. Pak vůbec nezáleží, jaký je typový systém, protože třeba v souboru na disku můžu mít ta data jakákoli, a při načtení musím kontrolovat, že načítaná data jsou validní.

já fakt nesouhlasím s:
Citace
To záleží na kontextu. Pokud se bude pohybovat v kódu, kde bude většina typů non-null, a výjimečně narazí na nullable typ, ošetří to. Pokud bude z venku neustále dostávat nullable typy a použité typy a typový systém ho budou nutit neustále to přetypovávat, bude to dělat automaticky bez přemýšlení.
a řekl bych že výše uvedený příklad ukazuje, že to prostě není pravda.
Podle mne se tady nedá na jednom příkladu ukázat, že to není pravda. Vždyť tvrdím, že když donutíte člověka něco dělat opakovaně skoro pokaždé v nějaké situaci, bude to v podobných situacích dělat bez přemýšlení. To je úplně nezávislé na programování, lidé takhle automaticky odklepávají potvrzovací dotazy, pokud se jich aplikace pořád ptá na nějaké nesmysly (třeba jestli má smazat soubor), vjíždí na železniční přejezd, když nebliká červená – a úplně stejně budou do programu automaticky vkládat konstrukci na přetypování na non-null typ, pokud to tak budou používat ve většině případů. Jako příklad budiž třeba implementace escapování jako obrany před SQL injection nebo XSS – pokud se to někde nechalo tak, že si to musel každý ve svém kódu ošetřit sám, bylo vzápětí escapování všude, takže se jeden řetězec escapoval několikrát (což samozřejmě nefungovalo). Dotyčný autor nad tím vůbec nepřemýšlel, jestli je v kontextu kdy musí nebo nesmí escapovat, prostě tu konstrukci bez rozmýšlení mydlil všude.

A ze stejných důvodů nesouhlasím s tímto:
Citace
I tenhle typ chyby se bude objevovat u sebelepšího typového systému, protože když programátora nenapadne, že to je zajímavý případ a měl by na to udělat test, nenapadne ho ani ošetřit to v typovém systému.
Protože například u té nullpointerexception je prostě používání "Maybe" typu na úplně jiné úrovni než dávat někam asserty a psát k tomu unit testy.
Rozlišování nullable/non-null typů je myslím extrémní případ, kdy je použití extrémně snadné a pro programátora srozumitelné. Souhlasím s tím, že tohle je případ, kdy je řešení pomocí typů nejlepší řešení. Ale jen o málo složitější věci by typově správně byly nesmírně komplikované, a nebo tam zase musíte povolit potenciální chyby, a programátor to neuhlídá.

Zkuste vzít jako příklad jednoduché porovnání dvou čísel splňující kontrakt „pokud je první číslo větší, vrací zápornou hodnotu, pokud jsou stejná, vrací nulu, pokud je druhé číslo větší, vrací kladnou hodnotu“. Nejjednodušší řešení je čísla odečíst – jenže se může stát, že dojde k přetečení. Může se to ošetřit typově – při sčítání nebo odčítání dvou čísel bude mít návratový typ dvojnásobný rozsah. Jenže se to začne nabalovat, a za chvíli skončíte s datovým typem, který se ani nevejde do paměti. A nebo to budete ošetřovat a pokud by došlo k přetečení typu, vyhodí se výjimka. Jenže pak zase potřebujete jednotkové testy, protože typový systém by vám možná zajistil, že program neudělá skrytě nic špatně, ale raději vyhodí výjimku, ale testy pak potřebujete na to, abyste zkontroloval, že aspoň někdy to skončí jinak, než výjimkou.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 15:03:47
však to je přesně ono, není záruka, že volající něco dodrží

Zase obráceně. Volaná funkce se musí podřídit tomu, co chce volající. Zde zřejme narážíme na další konflikt FP vs. OOP.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 26. 06. 2018, 15:09:31
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?
Tak povídej :-)
Pokryti ceho a cim?

Měl jsem na mysli trivialitu v tom, že:
Kód: [Vybrat]
fn foo(Byte: x):
je ekvivalentní:

Kód: [Vybrat]
fn foo(x):

fn test_foo():
    foreach x in [0, 1, 2, 3, 4, 5 , 6, ... 255]:
        foo(x)

fn test_foo_fail_string():
    foreach x in ["a", "b", "c", ... "aa", "bb", ...]:
        exceptedException
        foo(x)

fn test_foo_fail_float():
    foreach x in [1.1, 1.2, 1.3, ...]:
        exceptedException
        foo(x)

a vlastně ten rozvoj je nekonečný...
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 15:17:12
však to je přesně ono, není záruka, že volající něco dodrží

Zase obráceně. Volaná funkce se musí podřídit tomu, co chce volající. Zde zřejme narážíme na další konflikt FP vs. OOP.
možná - "make illegal states unrepresentable"
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 15:53:57
Citace: Filip Jirsák
Kdybych to psal v dynamickém jazyku, tak asi proto, abych typy nemusel řešit a poradilo si to s co největší škálou různých (i ne zcela správných) vstupů.
...
To by mě zajímalo, proč bys zrovna z těchto důvodů tohle psal v dynamickém jazyku....
Že je to dynamický jazyk přece bylo vaše zadání.
Nějak nerozumím vašemu logickému uvažování. Giving up.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 16:08:30
Kód: [Vybrat]
data Obj {
    a :: Int
  , b :: Text
  , c :: [Int]
  , d :: NonEmpty Int -- neprazdne pole
  , e :: Maybe Double
  , f :: UTCTime
}
instance FromJSON Obj where
  parseJSON = withObject $ \o ->
     Obj <$> o .: "alpha" <*> o .: "beta" <*> o .: "cyril" <*> o .: "delta" <*> o .: "edward" <*> f .: "ftime"
...až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....

Tak především v OOP je (z podstaty) starostí objektu, aby si okontroloval, čím se plní, a naplnění i sám provedl (přestože to tak mnozí nedělají a omrdávají to jakýmisi dírami v implementaci, nebo anemickým modelem). Na to stačí metoda fromJson(json), fromDict(dict) atp. obsahující kontroly (klidně včetně rozsahů hodnot!) a jejich uložení. Jednotkovému testu stačí vyzkoušet, zda objekt pro daná data je možno vytvořit.
Ale tohle je diskuze nikoliv OOP vs FP, ale typy vs. unit testy (případně bez typů). Jinak moje praktická zkušnost myslím s "gson"em je ta, že mi to poctivě dávalo "null" do chybějících atributů (při generickém parsingu) a nebylo ochotné se to nechat přesvědčit jinak. Že by to samovolně zareagovalo na @NonNull, tak to už vůbec...
Citace
P. S.: Co je to zač hen ten paskvil, ve kterém jste to psal, nejde tomu ani rozumět...
Haskell. To první je deklarace typu. Ta řádka je v podstatě "Obj (o .: "alpha") (o .: "beta") ..", .: je oprátor "najdi v dictionary", akorát to celé běží v nějakém Parser monadu (což tady v podstatě jsou Checked exceptions), proto tam jsou ty divný '<$>' a '<*>' mezi jednotlivýma parametrama. (dá se to napsat i jinak, ale když si to člověk umí "zazávorkovat", tak je to takhle docela přehledné....)
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 26. 06. 2018, 16:16:56
trochu offtopic, ale nemáte někdo nějakou teorii tohohle vehementního odmítání moderních technologií?
Co se týče mě, tak neodmítám, jen jsem si z toho nesedl na zadek, protože to žádná zázračná stříbrná kulka není. Nejspíš na to časem taky přijdeš, obvykle se tak děje když se člověk dostane od učebnicových příkladů k většímu projektu.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 16:19:10
Ale tohle je diskuze nikoliv OOP vs FP, ale typy vs. unit testy (případně bez typů). Jinak moje praktická zkušnost myslím s "gson"em je ta, že mi to poctivě dávalo "null" do chybějících atributů (při generickém parsingu) a nebylo ochotné se to nechat přesvědčit jinak. Že by to samovolně zareagovalo na @NonNull, tak to už vůbec...

Jenže FP vs. OOP je ve své podstatě totéž jako typy vs. unit testy. OOP se obejde bez typů, FP se obejde bez testů. OOP bez testů je jak FP bez typů. Pro jednoduché úkoly to stačí, ale u složitějších je cítit jejich absence.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 16:25:13
trochu offtopic, ale nemáte někdo nějakou teorii tohohle vehementního odmítání moderních technologií?
Co se týče mě, tak neodmítám, jen jsem si z toho nesedl na zadek, protože to žádná zázračná stříbrná kulka není. Nejspíš na to časem taky přijdeš, obvykle se tak děje když se člověk dostane od učebnicových příkladů k většímu projektu.
můžete uvést nějaký příklad menšího většího projektu? třeba ten typově bezpečný AST jsem úspěšně aplikoval na reálný programovací jazyk (IEC61131 STL), je to učebnicový příklad?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 16:41:21
Citace: Filip Jirsák
Kdybych to psal v dynamickém jazyku, tak asi proto, abych typy nemusel řešit a poradilo si to s co největší škálou různých (i ne zcela správných) vstupů.
...
To by mě zajímalo, proč bys zrovna z těchto důvodů tohle psal v dynamickém jazyku....
Že je to dynamický jazyk přece bylo vaše zadání.
Nějak nerozumím vašemu logickému uvažování. Giving up.

Začalo to takhle:


Máš pravdu, když to píšu, tak to píšu bez přemýšlení... až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....
Název: Re:Typový system versus unittesty
Přispěvatel: SB 26. 06. 2018, 16:43:39
Kód: [Vybrat]
data Obj {
    a :: Int
  , b :: Text
  , c :: [Int]
  , d :: NonEmpty Int -- neprazdne pole
  , e :: Maybe Double
  , f :: UTCTime
}
instance FromJSON Obj where
  parseJSON = withObject $ \o ->
     Obj <$> o .: "alpha" <*> o .: "beta" <*> o .: "cyril" <*> o .: "delta" <*> o .: "edward" <*> f .: "ftime"
...až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....

Tak především v OOP je (z podstaty) starostí objektu, aby si okontroloval, čím se plní, a naplnění i sám provedl (přestože to tak mnozí nedělají a omrdávají to jakýmisi dírami v implementaci, nebo anemickým modelem). Na to stačí metoda fromJson(json), fromDict(dict) atp. obsahující kontroly (klidně včetně rozsahů hodnot!) a jejich uložení. Jednotkovému testu stačí vyzkoušet, zda objekt pro daná data je možno vytvořit.
Ale tohle je diskuze nikoliv OOP vs FP, ale typy vs. unit testy (případně bez typů). Jinak moje praktická zkušnost myslím s "gson"em je ta, že mi to poctivě dávalo "null" do chybějících atributů (při generickém parsingu) a nebylo ochotné se to nechat přesvědčit jinak. Že by to samovolně zareagovalo na @NonNull, tak to už vůbec...

Tak to se omlouvám, ale viděl jsem tam Obj, tak jsem si myslel, že se jedná o OOP. Každopádně jako příklad v dynamickém (netypovém) OO jazyku a s jednotkovými testy to mám správně.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 16:45:31
můžete uvést nějaký příklad menšího většího projektu? třeba ten typově bezpečný AST jsem úspěšně aplikoval na reálný programovací jazyk (IEC61131 STL), je to učebnicový příklad?
Co třeba taková kalkulačka? Jenom simulace té nejobyčejnější kalkulačky – zadávání čísel v desítkové soustavě, sčítání, odčítání, násobení a dělení. Žádné priority, žádné paměti, žádné další funkce. Můžete napsat, jaké byste tam použil typy, jak by vypadal kód – a zda byste tam měl nějaké testy, případně jaké?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 26. 06. 2018, 17:04:39
Tak to se omlouvám, ale viděl jsem tam Obj, tak jsem si myslel, že se jedná o OOP. Každopádně jako příklad v dynamickém (netypovém) OO jazyku a s jednotkovými testy to mám správně.

Obj v daném příkladu není objekt, ale typ.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 26. 06. 2018, 17:35:22
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?
Tak povídej :-)
Pokryti ceho a cim?

Měl jsem na mysli trivialitu v tom, že:
Kód: [Vybrat]
fn foo(Byte: x):
je ekvivalentní:

Kód: [Vybrat]
fn foo(x):

fn test_foo():
    foreach x in [0, 1, 2, 3, 4, 5 , 6, ... 255]:
        foo(x)

fn test_foo_fail_string():
    foreach x in ["a", "b", "c", ... "aa", "bb", ...]:
        exceptedException
        foo(x)

fn test_foo_fail_float():
    foreach x in [1.1, 1.2, 1.3, ...]:
        exceptedException
        foo(x)

a vlastně ten rozvoj je nekonečný...


Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).

Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy. A nejen smysl, ale vlastne ani nejdou napsat/spustit, protoze ta typovane verze funkce proste nejde zavolat s jinym typem argumentu.

A ted se pokusim odpovedet na otazku zivota vesmiru a vubec (a jelikoz nedelam v haskellu tak by to mohlo trknout i Filipa a Kita)

Funkce se da vyjadrit:

A potom je to uz jasne ne? Kdyz mam uz v definici vstupu a vystupu zakodovano chovani funkce (protoze jsem zapis funkce vlastne nahradil lookup tabulkou) tak prece nepotrebuju zadne unit testy ktere overi vysledek pro nejake mizive promile tech moznych vstupu. To je prece jasna duplicita.

A jako bonus dokonce ani nepotrebuju psat telo funkce, protoze vsechno je uz v podpisu.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 17:39:42
můžete uvést nějaký příklad menšího většího projektu? třeba ten typově bezpečný AST jsem úspěšně aplikoval na reálný programovací jazyk (IEC61131 STL), je to učebnicový příklad?
Co třeba taková kalkulačka? Jenom simulace té nejobyčejnější kalkulačky – zadávání čísel v desítkové soustavě, sčítání, odčítání, násobení a dělení. Žádné priority, žádné paměti, žádné další funkce. Můžete napsat, jaké byste tam použil typy, jak by vypadal kód – a zda byste tam měl nějaké testy, případně jaké?
nic neslibuju, ale můžu se o to pokusit, asi by bylo ideální abych se o to pokusil v tom jazyce, ve kterém jste si zkoušel dependent types, který že to byl?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 18:47:15
nic neslibuju, ale můžu se o to pokusit, asi by bylo ideální abych se o to pokusil v tom jazyce, ve kterém jste si zkoušel dependent types, který že to byl?
Bavíme se tu přece teoreticky – nezaznamenal jsem, že by tu BoneFlute jásal, že konečně objevil ten správný jazyk. Takže jsem vám záměrně ponechal volnost, abyste použil jazyk, jaký chcete – předpokládal jsem, že pro to budete muset nadefinovat vlastní jazyk. Ale nemusíte ho definovat nijak podrobně, stačí popsat, jak budou vypadat ty typy a kód. Na konkrétní syntaxi přece nezáleží.
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 18:57:49
nic neslibuju, ale můžu se o to pokusit, asi by bylo ideální abych se o to pokusil v tom jazyce, ve kterém jste si zkoušel dependent types, který že to byl?
Bavíme se tu přece teoreticky – nezaznamenal jsem, že by tu BoneFlute jásal, že konečně objevil ten správný jazyk. Takže jsem vám záměrně ponechal volnost, abyste použil jazyk, jaký chcete – předpokládal jsem, že pro to budete muset nadefinovat vlastní jazyk. Ale nemusíte ho definovat nijak podrobně, stačí popsat, jak budou vypadat ty typy a kód. Na konkrétní syntaxi přece nezáleží.
http://augustss.blogspot.com/2009/06/more-llvm-recently-someone-asked-me-on.html
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 19:06:17
Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy.
Což je ovšem dost slabé tvrzení oproti původnímu „nejsou potřeba žádné testy“.

A mimochodem ten BoneFluteův příklad je poněkud nekompletní, protože tam má jenom typ, ale žádnou funkci. Jednotkové testy se ale používají na právě na testování algoritmů. Kdyby se nezabýval jenom tím typem Byte, ale hlavně tou funkcí foo(), hned by měl co testovat.

Funkce se da vyjadrit:
  • analyticky - o to se vetsina programatoru snazi
  • graficky - o to se vetsina programatoru nesnazi, ale mohlo by to byt zajimave
  • vyctem hodnot - o to se vlastne snazi BoneFlute, akorat se mu nechce psat vsechny tak "zneuziva" typovy system

A potom je to uz jasne ne? Kdyz mam uz v definici vstupu a vystupu zakodovano chovani funkce (protoze jsem zapis funkce vlastne nahradil lookup tabulkou) tak prece nepotrebuju zadne unit testy ktere overi vysledek pro nejake mizive promile tech moznych vstupu. To je prece jasna duplicita.
Za prvé je z toho hned vidět, že definovat funkce výčtem hodnot je pro reálné programy v drtivé většině případů nepoužitelné. Až začnete psát o tom, že se to přece dá nějak redukovat a nevypisovat všechny hodnoty, ale nahradit to nějakým předpisem – pak právě přijdou na řadu ty testy, které porovnávají, jestli ten předpis pro některé zajímavé hodnoty dává opravdu tu hodnotu, která by měla být v tom výčtu.

Za druhé, pokud by vám nemožnost udělat úplný výčet připadala jako nějaké dočasné technické omezení, vzpomeňte si třeba na funkce rand() nebo na faktorizaci velkých čísel – kdybychom dokázali ty funkce definovat výčtem hodnot, přestaly by být zajímavé a nikdo by je nepoužíval.

Za třetí, pořád předpokládáte, že výkonný kód i test vzniká stejným způsobem a píše to ten samý programátor. Ve skutečnosti kdyby vám někdo dal funkci (i se zdrojákem) definovanou výčtem hodnot a tvrdil by vám, že ta funkce dělá X, první co byste udělal, že byste si v tom zdrojáku vyhledal pár hodnot a ověřil byste, že alespoň pro tyhle hodnoty opravdu dělá X.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 19:13:05
nic neslibuju, ale můžu se o to pokusit, asi by bylo ideální abych se o to pokusil v tom jazyce, ve kterém jste si zkoušel dependent types, který že to byl?
Bavíme se tu přece teoreticky – nezaznamenal jsem, že by tu BoneFlute jásal, že konečně objevil ten správný jazyk. Takže jsem vám záměrně ponechal volnost, abyste použil jazyk, jaký chcete – předpokládal jsem, že pro to budete muset nadefinovat vlastní jazyk. Ale nemusíte ho definovat nijak podrobně, stačí popsat, jak budou vypadat ty typy a kód. Na konkrétní syntaxi přece nezáleží.
http://augustss.blogspot.com/2009/06/more-llvm-recently-someone-asked-me-on.html
Hezký, akorát že to není ta požadovaná kalkulačka, že. Všimněte si, že jeden z implicitních požadavků na program je to, že když dostane nějaký vstup mimo zadání, oznámí chybu. Decimální kalkulačka, do které zadám krf % brf a ona vypíše peklo, asi není úplně bezchybná, nemyslíte?
Název: Re:Typový system versus unittesty
Přispěvatel: v 26. 06. 2018, 19:16:17
nic neslibuju, ale můžu se o to pokusit, asi by bylo ideální abych se o to pokusil v tom jazyce, ve kterém jste si zkoušel dependent types, který že to byl?
Bavíme se tu přece teoreticky – nezaznamenal jsem, že by tu BoneFlute jásal, že konečně objevil ten správný jazyk. Takže jsem vám záměrně ponechal volnost, abyste použil jazyk, jaký chcete – předpokládal jsem, že pro to budete muset nadefinovat vlastní jazyk. Ale nemusíte ho definovat nijak podrobně, stačí popsat, jak budou vypadat ty typy a kód. Na konkrétní syntaxi přece nezáleží.
http://augustss.blogspot.com/2009/06/more-llvm-recently-someone-asked-me-on.html
Hezký, akorát že to není ta požadovaná kalkulačka, že. Všimněte si, že jeden z implicitních požadavků na program je to, že když dostane nějaký vstup mimo zadání, oznámí chybu. Decimální kalkulačka, do které zadám krf % brf a ona vypíše peklo, asi není úplně bezchybná, nemyslíte?
požadovaná?? tak tohle je asi moje mez, jestli neukážete aspoň trochu snahy porozumět tématu, tak na vás asi nebudu reagovat
Název: Re:Typový system versus unittesty
Přispěvatel: andy 26. 06. 2018, 19:40:06
můžete uvést nějaký příklad menšího většího projektu? třeba ten typově bezpečný AST jsem úspěšně aplikoval na reálný programovací jazyk (IEC61131 STL), je to učebnicový příklad?
Co třeba taková kalkulačka? Jenom simulace té nejobyčejnější kalkulačky – zadávání čísel v desítkové soustavě, sčítání, odčítání, násobení a dělení. Žádné priority, žádné paměti, žádné další funkce. Můžete napsat, jaké byste tam použil typy, jak by vypadal kód – a zda byste tam měl nějaké testy, případně jaké?

https://gist.github.com/ondrap/69fa2162bc2516469642e5380b379f5c (https://gist.github.com/ondrap/69fa2162bc2516469642e5380b379f5c) (v reálu by tam byl zvlášť typ na operátor a Show instance pro jednodušší debugování, která se bohužel u toho ExprF nenageneruje sama)

Testy obvykle dělám na parsing, a pak asi nějaký test, že to nepočítá úplnou haluz (i.e. 100% code coverage, tady že jsem se neuklep v těch operátorech). Ono tam teda moc co testovat není....  jinak parser na "normální" výrazy není o moc delší, jen jsem línej to hledat... tam by se asi pak řešilo v testech, jestli se korektně respektuje priorita operátorů.

No, ale v podstatě je to to, co jsem psal - parsing typově moc obsáhnout nejde, vlastní výpočet má v podstatě 3 řádky a  není moc co tam splést.... aritmetika na Double je poměrně "totální", takže tam taky není moc co řešit...
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 26. 06. 2018, 21:52:40
Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy.
Což je ovšem dost slabé tvrzení oproti původnímu „nejsou potřeba žádné testy“.
Ja ani tak nerikam, nejsou potreba, ale spis nejdou napsat. Je to uplne odlisny vyrok. Nedaval bych to do souvislosti.

Za prvé je z toho hned vidět, že definovat funkce výčtem hodnot je pro reálné programy v drtivé většině případů nepoužitelné. Až začnete psát o tom, že se to přece dá nějak redukovat a nevypisovat všechny hodnoty, ale nahradit to nějakým předpisem – pak právě přijdou na řadu ty testy, které porovnávají, jestli ten předpis pro některé zajímavé hodnoty dává opravdu tu hodnotu, která by měla být v tom výčtu.
A ja myslel, ze sem se vyjadril fakt pochopitelne. Asi ne.

Za druhé, pokud by vám nemožnost udělat úplný výčet připadala jako nějaké dočasné technické omezení, vzpomeňte si třeba na funkce rand() nebo na faktorizaci velkých čísel – kdybychom dokázali ty funkce definovat výčtem hodnot, přestaly by být zajímavé a nikdo by je nepoužíval.
Mohl bych videt prosim nejaky unit test na "funkci" rand?


Za třetí, pořád předpokládáte, že výkonný kód i test vzniká stejným způsobem a píše to ten samý programátor. Ve skutečnosti kdyby vám někdo dal funkci (i se zdrojákem) definovanou výčtem hodnot a tvrdil by vám, že ta funkce dělá X, první co byste udělal, že byste si v tom zdrojáku vyhledal pár hodnot a ověřil byste, že alespoň pro tyhle hodnoty opravdu dělá X.

Urcite ne.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 26. 06. 2018, 22:57:53
Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).
To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?

Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy. A nejen smysl, ale vlastne ani nejdou napsat/spustit, protoze ta typovane verze funkce proste nejde zavolat s jinym typem argumentu.
Tak :-)

Funkce se da vyjadrit:
  • analyticky - o to se vetsina programatoru snazi
  • graficky - o to se vetsina programatoru nesnazi, ale mohlo by to byt zajimave
  • vyctem hodnot - o to se vlastne snazi BoneFlute, akorat se mu nechce psat vsechny tak "zneuziva" typovy system
Asi bych se nespokojil s tím, že chápu funkci jen jako výčet hodnot, ale uznávám, že většina mejch ukázek je o tom.

Ale to grafické vyjádření funkce by mě zajímalo. Můžeš to prosím rozvést?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 23:43:36
požadovaná?? tak tohle je asi moje mez, jestli neukážete aspoň trochu snahy porozumět tématu, tak na vás asi nebudu reagovat
Myslím, že tématu rozumím docela dobře. Téma je, že vy jste moderní borec a každý, kdo zpochybní vaše tvrzení, je zpátečník. A jakmile máte ukázat něco konkrétního, začnete se kroutit a vymlouvat, že tomu nikdo nerozumí. Přitom se po vás chce tak banální věc, abyste podle jednoduchého zadání napsal kód, u kterého nebude dávat žádný smysl něco testovat. Bez toho zadání se to samozřejmě neobejde, protože se testuje soulad se zadáním – kód bez zadání opravdu nemá smysl testovat.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 26. 06. 2018, 23:45:53
můžete uvést nějaký příklad menšího většího projektu? třeba ten typově bezpečný AST jsem úspěšně aplikoval na reálný programovací jazyk (IEC61131 STL), je to učebnicový příklad?
Co třeba taková kalkulačka? Jenom simulace té nejobyčejnější kalkulačky – zadávání čísel v desítkové soustavě, sčítání, odčítání, násobení a dělení. Žádné priority, žádné paměti, žádné další funkce. Můžete napsat, jaké byste tam použil typy, jak by vypadal kód – a zda byste tam měl nějaké testy, případně jaké?

https://gist.github.com/ondrap/69fa2162bc2516469642e5380b379f5c (https://gist.github.com/ondrap/69fa2162bc2516469642e5380b379f5c) (v reálu by tam byl zvlášť typ na operátor a Show instance pro jednodušší debugování, která se bohužel u toho ExprF nenageneruje sama)

Testy obvykle dělám na parsing, a pak asi nějaký test, že to nepočítá úplnou haluz (i.e. 100% code coverage, tady že jsem se neuklep v těch operátorech). Ono tam teda moc co testovat není....  jinak parser na "normální" výrazy není o moc delší, jen jsem línej to hledat... tam by se asi pak řešilo v testech, jestli se korektně respektuje priorita operátorů.

No, ale v podstatě je to to, co jsem psal - parsing typově moc obsáhnout nejde, vlastní výpočet má v podstatě 3 řádky a  není moc co tam splést.... aritmetika na Double je poměrně "totální", takže tam taky není moc co řešit...

Na tomhle se shodneme. Tak třeba to teď konečně vezme v nebo BoneFlute a upraví ten kód tak, aby byly zbytečné všechny testy.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 26. 06. 2018, 23:52:17
https://gist.github.com/ondrap/69fa2162bc2516469642e5380b379f5c (https://gist.github.com/ondrap/69fa2162bc2516469642e5380b379f5c) (v reálu by tam byl zvlášť typ na operátor a Show instance pro jednodušší debugování, která se bohužel u toho ExprF nenageneruje sama)

Testy obvykle dělám na parsing, a pak asi nějaký test, že to nepočítá úplnou haluz (i.e. 100% code coverage, tady že jsem se neuklep v těch operátorech). Ono tam teda moc co testovat není....  jinak parser na "normální" výrazy není o moc delší, jen jsem línej to hledat... tam by se asi pak řešilo v testech, jestli se korektně respektuje priorita operátorů.

No, ale v podstatě je to to, co jsem psal - parsing typově moc obsáhnout nejde, vlastní výpočet má v podstatě 3 řádky a  není moc co tam splést.... aritmetika na Double je poměrně "totální", takže tam taky není moc co řešit...

Moc pěkný. Díky!
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 27. 06. 2018, 00:01:41
Ja ani tak nerikam, nejsou potreba, ale spis nejdou napsat. Je to uplne odlisny vyrok. Nedaval bych to do souvislosti.
Ovšem celou dobu se tu řeší, zda je pravdivé tvrzení, že testy (v případě dobrého typového systému) vůbec nejsou potřeba. To tvrzení je samozřejmě možné dokázat i metodou, že vyjmenujete různé skupiny testů, u nich ukážete, že jsou zbytečné (nebo že ani nejdou zkompilovat), a pak ukážete, že jste takhle „vyřídil“ všechny skupiny testů. Ale nemá smysl dokazovat jenom tvrzení, že některé testy nebudou potřeba (nebo nepůjdou zkompilovat), protože to tady nikdo nerozporoval.

A ja myslel, ze sem se vyjadril fakt pochopitelne. Asi ne.
Jestli jste to myslel jako reálné řešení problému, pak vás zklamu, ale paměť dnešních počítačů je na tohle stále malá, takže úplným výčtem byste mohl řešit jen velmi jednoduché problémy. Ale zase je ta paměť dost velká na to, aby vás popis toho problému úplným výčtem možností přestal bavit mnohem dřív, než ta paměť dojde.

Mohl bych videt prosim nejaky unit test na "funkci" rand?
Zrovna testování náhodnosti není nic snadného, ale u důležitých systémů (třeba generátory pro kryptografii) se to samozřejmě dělá. Nejjednodušší test by mohl získat třeba 1000 náhodných hodnot, normalizovat je do rozsahu <0, 1) a otestovat, že se průměrná hodnota neliší od 0,5 o víc než nějaké delta. Rozumnější test by kontroloval i distribuci hodnot.

Urcite ne.
Takže věříte tomu, co je napsané v dokumentaci? A pokud něco není v dokumentaci jasně popsané, tak tu službu vůbec nepoužíváte? Nebo si všechno píšete sám, od jádra operačního systému?
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 27. 06. 2018, 00:43:41
trochu offtopic, ale nemáte někdo nějakou teorii tohohle vehementního odmítání moderních technologií?
Co se týče mě, tak neodmítám, jen jsem si z toho nesedl na zadek, protože to žádná zázračná stříbrná kulka není. Nejspíš na to časem taky přijdeš, obvykle se tak děje když se člověk dostane od učebnicových příkladů k většímu projektu.
můžete uvést nějaký příklad menšího většího projektu? třeba ten typově bezpečný AST jsem úspěšně aplikoval na reálný programovací jazyk (IEC61131 STL), je to učebnicový příklad?
No a závěr je teda jaký? Že bych si z toho měl sednout na zadek, protože... co?
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 08:44:10
trochu offtopic, ale nemáte někdo nějakou teorii tohohle vehementního odmítání moderních technologií?
Co se týče mě, tak neodmítám, jen jsem si z toho nesedl na zadek, protože to žádná zázračná stříbrná kulka není. Nejspíš na to časem taky přijdeš, obvykle se tak děje když se člověk dostane od učebnicových příkladů k většímu projektu.
můžete uvést nějaký příklad menšího většího projektu? třeba ten typově bezpečný AST jsem úspěšně aplikoval na reálný programovací jazyk (IEC61131 STL), je to učebnicový příklad?
No a závěr je teda jaký? Že bych si z toho měl sednout na zadek, protože... co?
dílčí závěr je, že sezení na zadku apod. není předmětem této diskuze (BoneFlute mě kdyžtak opraví), více možná až odpovíte na položené dotazy
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 08:44:59
Na tomhle se shodneme. Tak třeba to teď konečně vezme v nebo BoneFlute a upraví ten kód tak, aby byly zbytečné všechny testy.
[/quote]
proč by to vůbec někdo dělal?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 27. 06. 2018, 10:01:47
proč by to vůbec někdo dělal?
Například proto, aby dokázal pravdivost tvrzení, kterým celé tohle téma odstartovalo – a jehož pravdivost tady mnoho lidí zpochybnilo. BoneFlute na jeho pravdivosti stále trvá (zatím bez důkazu), tak by bylo hezké mít alespoň jeden příklad, kdy to platí.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 27. 06. 2018, 10:11:25
Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).
To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?
Ale jo, ale to pokryti zajima spis management nez programatory. Je to nejaka metrika ktere si mysli, ze rozumi. Ja na svem projektu rozhodne zadne pokryti nemerim.

Funkce se da vyjadrit:
  • analyticky - o to se vetsina programatoru snazi
  • graficky - o to se vetsina programatoru nesnazi, ale mohlo by to byt zajimave
  • vyctem hodnot - o to se vlastne snazi BoneFlute, akorat se mu nechce psat vsechny tak "zneuziva" typovy system
Asi bych se nespokojil s tím, že chápu funkci jen jako výčet hodnot, ale uznávám, že většina mejch ukázek je o tom.

Ale to grafické vyjádření funkce by mě zajímalo. Můžeš to prosím rozvést?
Nemuzu. Nerozumim tomu :-). Vychazel jsem jen z toho, ze v matematice lze funkci vyjadrit tremi zpusoby. Dva z nich jsou pouzitelne i v programovani, tak proc ne ten treti?
Jedine co si dovedu predstavit je nejake vzorkovani, ktere problem redukuje na vycet hodnot, takze vlastne nuda.
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 10:31:36
proč by to vůbec někdo dělal?
Například proto, aby dokázal pravdivost tvrzení, kterým celé tohle téma odstartovalo – a jehož pravdivost tady mnoho lidí zpochybnilo. BoneFlute na jeho pravdivosti stále trvá (zatím bez důkazu), tak by bylo hezké mít alespoň jeden příklad, kdy to platí.
zase to překrucujete, BoneFlute se ptal na příklad kdy to nejde
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 27. 06. 2018, 10:33:30
To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?
Ano, je to smutné, že programují i lidé, kterým to moc nejde, a běžně nedokážou určit ani ty potenciálně problematické vstupní hodnoty. Že na to nenapíší test je ten menší problém – horší je, že když o tom problému nevědí, neošetří ho ani v tom výkonném kódu.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 27. 06. 2018, 10:37:58
zase to překrucujete, BoneFlute se ptal na příklad kdy to nejde
Ano, a jeden takový příklad, kdy to nejde, tu právě máme. Pokud někdo tvrdí, že to jde vždy, očekával bych, že ten příklad nějak zpochybní, třeba že u jednotlivých testů dokáže, že jsou zbytečné.
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 10:54:10
zase to překrucujete, BoneFlute se ptal na příklad kdy to nejde
Ano, a jeden takový příklad, kdy to nejde, tu právě máme. Pokud někdo tvrdí, že to jde vždy, očekával bych, že ten příklad nějak zpochybní, třeba že u jednotlivých testů dokáže, že jsou zbytečné.
který příklad? v jakém systému a proč to nejde? vy furt opakujete, že to nejde, ale zatím váš jedinný argument byl, že to nejde
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 11:19:28
Funkce se da vyjadrit:
  • analyticky - o to se vetsina programatoru snazi
  • graficky - o to se vetsina programatoru nesnazi, ale mohlo by to byt zajimave
  • vyctem hodnot - o to se vlastne snazi BoneFlute, akorat se mu nechce psat vsechny tak "zneuziva" typovy system
Asi bych se nespokojil s tím, že chápu funkci jen jako výčet hodnot, ale uznávám, že většina mejch ukázek je o tom.

Ale to grafické vyjádření funkce by mě zajímalo. Můžeš to prosím rozvést?
Nemuzu. Nerozumim tomu :-). Vychazel jsem jen z toho, ze v matematice lze funkci vyjadrit tremi zpusoby. Dva z nich jsou pouzitelne i v programovani, tak proc ne ten treti?
Jedine co si dovedu predstavit je nejake vzorkovani, ktere problem redukuje na vycet hodnot, takze vlastne nuda.

Asi ne vždy, ale jde to i graficky. Vygeneruje se více testovacích hodnot a místo porovnání výsledků se vynesou do grafu. Pohledem na graf nebo srovnáním s etalonem můžeme snadno ověřit, zda funkce funguje jak má. Něco podobného jsem používal na vyhodnocení výsledků adaptivní metody Runge-Kutta pro různé velikosti základního kroku.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 27. 06. 2018, 11:29:29
který příklad? v jakém systému a proč to nejde? vy furt opakujete, že to nejde, ale zatím váš jedinný argument byl, že to nejde
Ten příklad, kterým začalo tohle vlákno diskuse, na které reagujete (https://forum.root.cz/index.php?topic=18804.msg271808#msg271808). Když už si to nepamatujete, máte v prohlížeči po straně takové táhlo, za to když potáhnete, bude se vám posouvat stránka na obrazovce, a tak se dostanete i k předchozím komentářům v tomto vlákně, můžete si je přečíst – jsou stále ještě na jedné obrazovce.

Máme tam příklad a v komentáři jsou popsané nějaké testy. Pokud jsou podle vás ty testy zbytečné, napište, čím byste je nahradil. Můj argument, proč to nahradit nejde (už jsem to vysvětloval, ale zřejmě jste to nepochopil), je dostatečný – vy jste zatím neuvedl jediný protipříklad, jak to tedy udělat, místo toho se pořád jen na něco vymlouváte.

Shrnu to pro vás ještě jednou –  když máte příklad s testy, a tvrdíte, že testy nejsou potřeba a i bez nich je možné získat minimálně stejnou míru jistoty o správné funkčnosti, předveďte to a upravte ten příklad tak, aby v něm žádné testy nebyly. Pak se můžeme bavit o tom, jestli ty vaše úpravy zaručují stejnou jistotu správné funkčnosti. Dokud to neuděláte, jenom tu plácáte.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 27. 06. 2018, 11:31:40
Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy.
Což je ovšem dost slabé tvrzení oproti původnímu „nejsou potřeba žádné testy“.
Ja ani tak nerikam, nejsou potreba, ale spis nejdou napsat. Je to uplne odlisny vyrok. Nedaval bych to do souvislosti.
Z toho ale zároveň plyne jedna velká nepříjemnost. Dost blbě se ověřuje, že nějaký obrat opravdu nejde zkompilovat. Spouštět nějakým scriptem kompilaci kousků kódu a testovat jestli to opravdu zdechne je nešikovné.
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 11:57:02
příklad jsem tu uváděl, pokud jste ho ignoroval, vaše škoda
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 12:03:51
Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy.
Což je ovšem dost slabé tvrzení oproti původnímu „nejsou potřeba žádné testy“.
Ja ani tak nerikam, nejsou potreba, ale spis nejdou napsat. Je to uplne odlisny vyrok. Nedaval bych to do souvislosti.
Z toho ale zároveň plyne jedna velká nepříjemnost. Dost blbě se ověřuje, že nějaký obrat opravdu nejde zkompilovat. Spouštět nějakým scriptem kompilaci kousků kódu a testovat jestli to opravdu zdechne je nešikovné.
tohle je zajímavý problém, existuje taková knihovna pro ghc, která se to pokouší řešit https://hackage.haskell.org/package/should-not-typecheck
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 27. 06. 2018, 12:06:51
příklad jsem tu uváděl, pokud jste ho ignoroval, vaše škoda
Tak dlouho tu trollujete, až jste vytrollil sám sebe.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 27. 06. 2018, 12:21:32
Testy obvykle dělám na parsing, a pak asi nějaký test, že to nepočítá úplnou haluz (i.e. 100% code coverage, tady že jsem se neuklep v těch operátorech). Ono tam teda moc co testovat není....  jinak parser na "normální" výrazy není o moc delší, jen jsem línej to hledat... tam by se asi pak řešilo v testech, jestli se korektně respektuje priorita operátorů.

No, ale v podstatě je to to, co jsem psal - parsing typově moc obsáhnout nejde, vlastní výpočet má v podstatě 3 řádky a  není moc co tam splést.... aritmetika na Double je poměrně "totální", takže tam taky není moc co řešit...

Jaktože tam není co testovat? Zde jsou testy efektivní - pro různé kombinace řetězcových výrazů (včetně chybných, s různými mezerami, závorkami atd.) můžu pokrýt mnoho jevů a otestovat, zda z kalkulačky padá, co má.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 27. 06. 2018, 12:29:42
Mohl bych videt prosim nejaky unit test na "funkci" rand?

Psát to sem nebudu, popis musí stačit: Lze testovat např. typ hodnot, interval, rozložení, shodu posloupností v případě implementace se seedem, ...
Název: Re:Typový system versus unittesty
Přispěvatel: andy 27. 06. 2018, 12:33:34
Testy obvykle dělám na parsing, a pak asi nějaký test, že to nepočítá úplnou haluz (i.e. 100% code coverage, tady že jsem se neuklep v těch operátorech). Ono tam teda moc co testovat není....  jinak parser na "normální" výrazy není o moc delší, jen jsem línej to hledat... tam by se asi pak řešilo v testech, jestli se korektně respektuje priorita operátorů.

No, ale v podstatě je to to, co jsem psal - parsing typově moc obsáhnout nejde, vlastní výpočet má v podstatě 3 řádky a  není moc co tam splést.... aritmetika na Double je poměrně "totální", takže tam taky není moc co řešit...
Jaktože tam není co testovat? Zde jsou testy efektivní - pro různé kombinace řetězcových výrazů (včetně chybných, s různými mezerami, závorkami atd.) můžu pokrýt mnoho jevů a otestovat, zda z kalkulačky padá, co má.
Do není pochopitelné na "testy dělám na parsing"?

A co chcete testovat na:
Kód: [Vybrat]
compute :: Expr -> Double
compute = cata go
  where
    go (Num n)       = n
    go (Op op a1 a2) = op a1 a2
Pokud bychom do jazyka přidali prioritu a závorky, tak to je všechno věc parsingu, na tohle to nebude mít žádný vliv.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 13:05:27
A co chcete testovat na:
Kód: [Vybrat]
compute :: Expr -> Double
compute = cata go
  where
    go (Num n)       = n
    go (Op op a1 a2) = op a1 a2
Pokud bychom do jazyka přidali prioritu a závorky, tak to je všechno věc parsingu, na tohle to nebude mít žádný vliv.

Testovat můžeš například to, jestli jsi omylem nezaměnil operátory, jestli jsi dal závorky tam, kam patří, jestli omylem nevoláš nevhodnou funkci z knihovny, jestli jsi nezaměnil proměnné nebo pořadí parametrů stejného typu,... Jistě, u jednoduchého příkladu se bez testů obejdeš, podobně jako v OOP, ale neprogramujeme jen jednoduché kalkulačky.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 27. 06. 2018, 13:09:52
A co chcete testovat na:
Kód: [Vybrat]
compute :: Expr -> Double
compute = cata go
  where
    go (Num n)       = n
    go (Op op a1 a2) = op a1 a2
Pokud bychom do jazyka přidali prioritu a závorky, tak to je všechno věc parsingu, na tohle to nebude mít žádný vliv.

Testovat můžeš například to, jestli jsi omylem nezaměnil operátory, jestli jsi dal závorky tam, kam patří, jestli omylem nevoláš nevhodnou funkci z knihovny, jestli jsi nezaměnil proměnné nebo pořadí parametrů stejného typu,... Jistě, u jednoduchého příkladu se bez testů obejdeš, podobně jako v OOP, ale neprogramujeme jen jednoduché kalkulačky.

Reagoval jsem na:

Citace
Jaktože tam není co testovat? Zde jsou testy efektivní - pro různé kombinace řetězcových výrazů (včetně chybných, s různými mezerami, závorkami atd.) můžu pokrýt mnoho jevů a otestovat, zda z kalkulačky padá, co má.
Takže rozumíme si, že na výše uvedeném kódu toho fakt k testování moc není?
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 27. 06. 2018, 13:17:55
Mohl bych videt prosim nejaky unit test na "funkci" rand?

Psát to sem nebudu, popis musí stačit: Lze testovat např. typ hodnot, interval, rozložení, shodu posloupností v případě implementace se seedem, ...
Nemel by prave typ hodnot podchytit typovy system? To same interval. Shodu s posloupnosti si taky dovedu predstavit.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 13:24:42
A co chcete testovat na:
Kód: [Vybrat]
compute :: Expr -> Double
compute = cata go
  where
    go (Num n)       = n
    go (Op op a1 a2) = op a1 a2
Pokud bychom do jazyka přidali prioritu a závorky, tak to je všechno věc parsingu, na tohle to nebude mít žádný vliv.

Testovat můžeš například to, jestli jsi omylem nezaměnil operátory, jestli jsi dal závorky tam, kam patří, jestli omylem nevoláš nevhodnou funkci z knihovny, jestli jsi nezaměnil proměnné nebo pořadí parametrů stejného typu,... Jistě, u jednoduchého příkladu se bez testů obejdeš, podobně jako v OOP, ale neprogramujeme jen jednoduché kalkulačky.

Reagoval jsem na:

Citace
Jaktože tam není co testovat? Zde jsou testy efektivní - pro různé kombinace řetězcových výrazů (včetně chybných, s různými mezerami, závorkami atd.) můžu pokrýt mnoho jevů a otestovat, zda z kalkulačky padá, co má.
Takže rozumíme si, že na výše uvedeném kódu toho fakt k testování moc není?

Psal jsem, co všechno na tomhle můžeš otestovat. Pokud místo posledního řádku omylem napíšeš
Kód: [Vybrat]
    go (Op op a1 a2) = op a2 a1tak to kompilátor sežere i s chlupama a přitom to bude špatně.
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 13:42:00
Kód: [Vybrat]
    go (Op op a1 a2) = op a2 a1tak to kompilátor sežere i s chlupama a přitom to bude špatně.
dalo by se to napsat jako
Kód: [Vybrat]
data Expr a where
    Op :: (x -> y -> z) -> Expr x -> Expr y -> Expr z
ale nevím jestli to jde s tím rekurzním schématem
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 14:02:41
Kód: [Vybrat]
    go (Op op a1 a2) = op a2 a1tak to kompilátor sežere i s chlupama a přitom to bude špatně.
dalo by se to napsat jako
Kód: [Vybrat]
data Expr a where
    Op :: (x -> y -> z) -> Expr x -> Expr y -> Expr z
ale nevím jestli to jde s tím rekurzním schématem

Pokud jsem dobře pochopil, tak se tohle dělá jen teoreticky. Stejně jako mnozí, kteří dělají testy také jen teoreticky - jenže na ně jsou aspoň metriky, u kterých je nepraktické podvádět.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 14:03:49
Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).
To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?
Ale jo, ale to pokryti zajima spis management nez programatory. Je to nejaka metrika ktere si mysli, ze rozumi. Ja na svem projektu rozhodne zadne pokryti nemerim.

Mám na mysli takové to, když vývojář napíše těch pár testů a posílá na produkci. Tím gestem říká, že je to otestované. Nemluvil jsem vysloveně o ceverage.

Nemuzu. Nerozumim tomu :-). Vychazel jsem jen z toho, ze v matematice lze funkci vyjadrit tremi zpusoby. Dva z nich jsou pouzitelne i v programovani, tak proc ne ten treti?
Jedine co si dovedu predstavit je nejake vzorkovani, ktere problem redukuje na vycet hodnot, takze vlastne nuda.
No já v matematice poněkud plavu, ale měl jsem za to, že ten algoritmus je funkce, která počítá hodnoty, ze kterých se dá udělat taková ta křivka ukazující charakteristiku, jak ty hodnoty jdou.
Asi bych si dovedl představit, že někdo bude "programovat" funkci tím, že ji myší vytáhne v nějakém prostoru, a kompiler z toho odvodí funkci. Ale nedovedu si představit, že by to bylo praktické.

Četl jsem zajímavej článek o tom, že máme matematiku řeckou, založenou na algoritmu, a babylonskou, založenou na tabulce (třeba takové ty tabulky odmocnin, co nám dávali na základce).

Máme reálnou množinu všech možných trojúhelníků.
Babyloňan z té množiny udělá podmnožinu několika pravoúhlých trojúhelníků, a tobě to musí stačit. Pythagoras vymyslí vzorec, kterým vytáhne libovolný pravúhlý trojúhelník jen na základě argumentů (vytvoří funktor? mezi množinou trojúhelníků a množinou těch argumentů).

Na tom typování je vtipné právě to, že na rozdíl od testování se pokouší o vytvoření těch ultimátních vzorečků díky kterým dosáhnu ultimátní jistoty.
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 14:15:12
Kód: [Vybrat]
    go (Op op a1 a2) = op a2 a1tak to kompilátor sežere i s chlupama a přitom to bude špatně.
dalo by se to napsat jako
Kód: [Vybrat]
data Expr a where
    Op :: (x -> y -> z) -> Expr x -> Expr y -> Expr z
ale nevím jestli to jde s tím rekurzním schématem

Pokud jsem dobře pochopil, tak se tohle dělá jen teoreticky. Stejně jako mnozí, kteří dělají testy také jen teoreticky - jenže na ně jsou aspoň metriky, u kterých je nepraktické podvádět.
jak teoreticky? je to normální, nudný haskell (-XGADTs)
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 27. 06. 2018, 14:18:17
Na tom typování je vtipné právě to, že na rozdíl od testování se pokouší o vytvoření těch ultimátních vzorečků díky kterým dosáhnu ultimátní jistoty.
… ultimátní jistoty v tom, že se ten vzoreček trefí do správného oboru hodnot. Ale neříká to vůbec nic o tom, jestli konkrétní vypočtené hodnoty jsou ty, které by člověk čekal.

To je ale pořád dokola.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 27. 06. 2018, 14:42:01
Mohl bych videt prosim nejaky unit test na "funkci" rand?

Psát to sem nebudu, popis musí stačit: Lze testovat např. typ hodnot, interval, rozložení, shodu posloupností v případě implementace se seedem, ...
Nemel by prave typ hodnot podchytit typovy system? To same interval. Shodu s posloupnosti si taky dovedu predstavit.

Samozřejmě že ano, to jsem dopsal jen proto, že to není problém a jde to. Problém pro typový systém už ale jsou to rozložení a opakovatelnost, to by mě zajímalo!
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 14:50:47
Mohl bych videt prosim nejaky unit test na "funkci" rand?

Psát to sem nebudu, popis musí stačit: Lze testovat např. typ hodnot, interval, rozložení, shodu posloupností v případě implementace se seedem, ...
Nemel by prave typ hodnot podchytit typovy system? To same interval. Shodu s posloupnosti si taky dovedu predstavit.

Samozřejmě že ano, to jsem dopsal jen proto, že to není problém a jde to. Problém pro typový systém už ale jsou to rozložení a opakovatelnost, to by mě zajímalo!
Obvykle se rand vystrkává do side-effektů.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 27. 06. 2018, 15:23:22
Kód: [Vybrat]
    go (Op op a1 a2) = op a2 a1tak to kompilátor sežere i s chlupama a přitom to bude špatně.
dalo by se to napsat jako
Kód: [Vybrat]
data Expr a where
    Op :: (x -> y -> z) -> Expr x -> Expr y -> Expr z
ale nevím jestli to jde s tím rekurzním schématem

Já zrovna tohle řešil v tom Mapboxu (ale nepotřeboval jsem to, tak jsem se na to vybod), kde by to bylo zhruba takhle:
Kód: [Vybrat]
  Op :: Callable (Function paramlist z) => Function paramlist z -> Args paramlist -> Expr z
Ono to sazmozřejmě nezabrání tomu, aby člověk někde nenapsal '("sin", sin), ("cos", sin)', ale tak to je pak otázka nakolik mají unit testy (který by měly kontrolovat tu nejmenší část kódu) kontrolovat konstanty... (našel jsem jeden bug tohoto typu přímo v GHC...) možná někde v raketovém výzkumu, kde jeden tým píše a druhý kontroluje, jinak mi to nedává moc smysl.

Unittesty/typy jsou prostě nástroj, díky kterému můžeme psát programy s méně chybama - a od nějakého momentu dost nedávají smysl. A díky těm typům lze dosáhnout výrazně vyšší kvality s výrazně menším použitím i těch testů (ta kalkulačka je pravděpodobně kvalitnější bez jakéhokoliv testu než co by většina lidí spáchala v JS/pythonu/... i s unit testama).
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 27. 06. 2018, 15:26:33
Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).
To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?
Ale jo, ale to pokryti zajima spis management nez programatory. Je to nejaka metrika ktere si mysli, ze rozumi. Ja na svem projektu rozhodne zadne pokryti nemerim.

Mám na mysli takové to, když vývojář napíše těch pár testů a posílá na produkci. Tím gestem říká, že je to otestované. Nemluvil jsem vysloveně o ceverage.
Doufam, ze ve vetsine pripadu jeste do nejakeho testovaciho prostredi kde se na to koukne nekdo z QA. Ale i tak, mas pravdu. Nemelo by mu to stacit.

Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.


Nemuzu. Nerozumim tomu :-). Vychazel jsem jen z toho, ze v matematice lze funkci vyjadrit tremi zpusoby. Dva z nich jsou pouzitelne i v programovani, tak proc ne ten treti?
Jedine co si dovedu predstavit je nejake vzorkovani, ktere problem redukuje na vycet hodnot, takze vlastne nuda.
No já v matematice poněkud plavu, ale měl jsem za to, že ten algoritmus je funkce, která počítá hodnoty, ze kterých se dá udělat taková ta křivka ukazující charakteristiku, jak ty hodnoty jdou.
Asi bych si dovedl představit, že někdo bude "programovat" funkci tím, že ji myší vytáhne v nějakém prostoru, a kompiler z toho odvodí funkci. Ale nedovedu si představit, že by to bylo praktické.

Dovedu si treba predstavit pripad, ze nejaky program generuje jako jeden z vystupu nejaky graf kam vynasi body ktere oznacuji nejaky konkretni pripad pouziti. Prijde business analytik a v grafu za posledni mesic vyznaci body, ktere jsou nezadouci. V pripade, ze se body pripadu pouziti budou shlukovat vhodne podle stejneho kriteria jako pouzije business analytik, muze byt prakticke nakreslit krivku ktera oddeli zadouci a nezadouci body a nechat si vyhodnotit funkci predpis kompilatorem. Ale jak kdysi rekl jeden mudrc: " na prakticnost vam prdim" :-)
Název: Re:Typový system versus unittesty
Přispěvatel: andy 27. 06. 2018, 15:27:56
Kód: [Vybrat]
data Expr a where
    Op :: (x -> y -> z) -> Expr x -> Expr y -> Expr z
ale nevím jestli to jde s tím rekurzním schématem

Zas blbě :) Jo, jde to i s tím rekurzivním schématem: http://www.timphilipwilliams.com/posts/2013-01-16-fixing-gadts.html (http://www.timphilipwilliams.com/posts/2013-01-16-fixing-gadts.html)
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 15:48:51
A díky těm typům lze dosáhnout výrazně vyšší kvality s výrazně menším použitím i těch testů (ta kalkulačka je pravděpodobně kvalitnější bez jakéhokoliv testu než co by většina lidí spáchala v JS/pythonu/... i s unit testama).

Zahráváš si s ohněm :D
Název: Re:Typový system versus unittesty
Přispěvatel: v 27. 06. 2018, 15:59:11
Kód: [Vybrat]
data Expr a where
    Op :: (x -> y -> z) -> Expr x -> Expr y -> Expr z
ale nevím jestli to jde s tím rekurzním schématem

Zas blbě :) Jo, jde to i s tím rekurzivním schématem: http://www.timphilipwilliams.com/posts/2013-01-16-fixing-gadts.html (http://www.timphilipwilliams.com/posts/2013-01-16-fixing-gadts.html)
hezké, díky
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 16:00:32
Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.
Domnívám se, že v tomto případě jde spíše o automaticky generované testy. Což je taky dobrý. Ale typy jsou imho o něčem jiném. Viz ta ukázka https://forum.root.cz/index.php?topic=18804.msg271719#msg271719

Můžeš udělat typy, které se budou checkovat třeba týden. Ale udělat testy na bambilion vstupů budou ještě mnohem horší s horší efektivitou.


Ale jak kdysi rekl jeden mudrc: " na prakticnost vam prdim" :-)
Au :-D Na svou obranu musím říct, že to bylo prohlášení uvedené v zoufalství ze zaspamování této diskuse, kdy se ani věci znalí lidé nechtěli bavit k tématu ze strachu z trollů.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 27. 06. 2018, 16:11:01
Ale jak kdysi rekl jeden mudrc: " na prakticnost vam prdim" :-)
Au :-D Na svou obranu musím říct, že to bylo prohlášení uvedené v zoufalství ze zaspamování této diskuse, kdy se ani věci znalí lidé nechtěli bavit k tématu ze strachu z trollů.
Sorry, ale za to zatrollení diskuze si můžeš IMO primárně sám. Většina téhle diskuze je o tom, že ostatní šijou do tvých kategorických tvrzení.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 16:15:21
Sorry, ale za to zatrollení diskuze si můžeš IMO primárně sám. Většina téhle diskuze je o tom, že ostatní šijou do tvých kategorických tvrzení.

Ale no tak!

Takže když napíšu "Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém." je to přes čáru? A místní smetánka, která věci sice nerozumí, ale má tím pádem právo mě trollit? To jako vážně?!
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 27. 06. 2018, 16:25:35
Sorry, ale za to zatrollení diskuze si můžeš IMO primárně sám. Většina téhle diskuze je o tom, že ostatní šijou do tvých kategorických tvrzení.

Ale no tak!

Takže když napíšu "Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém." je to přes čáru? A místní smetánka, která věci sice nerozumí, ale má tím pádem právo mě trollit? To jako vážně?!
Je to kategorické tvrzení. Taková přímo svádějí k vyvracení. A když místní smetánce otloukáš o hlavu že tomu nerozumí, tak si o to přímo říkáš. Obzvlášť když to vypadá, že jsi ani nepochopil jejich argumenty.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 16:39:31
Sorry, ale za to zatrollení diskuze si můžeš IMO primárně sám. Většina téhle diskuze je o tom, že ostatní šijou do tvých kategorických tvrzení.

Ale no tak!

Takže když napíšu "Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém." je to přes čáru? A místní smetánka, která věci sice nerozumí, ale má tím pádem právo mě trollit? To jako vážně?!
Je to kategorické tvrzení. Taková přímo svádějí k vyvracení. A když místní smetánce otloukáš o hlavu že tomu nerozumí, tak si o to přímo říkáš. Obzvlášť když to vypadá, že jsi ani nepochopil jejich argumenty.
Vyvracení není trollení.
Já nejsem ten, který tu na potkání tvrdí, že ten druhý je úplně blbej, a že tomu nerozumí, a že by měl to a to. Si mě s někým pleteš.
A co se týče argumentů, byl bych s něčím takovým výrazně méně kategorický. Ano, uznávám, že příspěvky Kita a Filipa Jirsáka nečtu. Určitě chápeš proč.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 27. 06. 2018, 17:13:40
Vyvracení není trollení.
Začalo to kultivovaným vyvracením. A to i ze strany Kitta a Jirsáka.
Citace
Já nejsem ten, který tu na potkání tvrdí, že ten druhý je úplně blbej, a že tomu nerozumí, a že by měl to a to. Si mě s někým pleteš.
Nepletu. Já napsal něco jiného. Prosím nevkládej mi do příspěvků něco, co tam není.
Citace
A co se týče argumentů, byl bych s něčím takovým výrazně méně kategorický. Ano, uznávám, že příspěvky Kita a Filipa Jirsáka nečtu. Určitě chápeš proč.
Minimálně příspěvky Filipa Jirsáka jsi četl a reagoval jsi na ně. A dost arogantně. Např:
Sorry, tvé příspěvky nejsou vůbec inspirativní. Nebudu se tedy tebou již zabejvat.
Ano, jeho argument byl jednoduchý, ale velmi relevantní.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 17:30:40
...
Je vidět, že naše metriky se zásadně liší. To je vše, co k tomu mohu říct.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 27. 06. 2018, 17:39:18
Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.
Domnívám se, že v tomto případě jde spíše o automaticky generované testy. Což je taky dobrý. Ale typy jsou imho o něčem jiném. Viz ta ukázka https://forum.root.cz/index.php?topic=18804.msg271719#msg271719

Můžeš udělat typy, které se budou checkovat třeba týden. Ale udělat testy na bambilion vstupů budou ještě mnohem horší s horší efektivitou.

Ja to vidim nekde mezi. V clojure (ale i v dalsich lispech) je totiz "write time" = runtime. To znamena, ze kazdy vyraz ktery napisu hned evaluuju a mam ho k dispozici v bezicim REPLu. Takze kdyz treba pisu funkci a jeji specifikaci viz https://clojure.org/guides/spec#_spec_ing_functions (https://clojure.org/guides/spec#_spec_ing_functions)  muzu klidne tam kde ji volam pomoci valid? nebo conform overit jestli je dane volani odpovida specifikaci. A kdyz si to budu nechavat instrumentovat abych to nemusel zkouset rucne tak se blizim typovemu systemu. (popravde ja to tak nedelam, ale ja taky uz dneska moc kodu nenapisu...)

To ze z toho generuju testy je side effect, ale velmi prijemny. Podle me to prave preklenuje tu mezeru kterou zpusobuji prakticka omezeni na strane unit testu a typoveho systemu. Tam kde by typova specifikace zacinala byt neprakticka a pri tom nebyla kriticka muzu nechat generator chroustat misto abych ja musel cucat z prstu hodnoty ktere se maji vyzkouset.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 18:09:21
Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.
Domnívám se, že v tomto případě jde spíše o automaticky generované testy. Což je taky dobrý. Ale typy jsou imho o něčem jiném. Viz ta ukázka https://forum.root.cz/index.php?topic=18804.msg271719#msg271719

Můžeš udělat typy, které se budou checkovat třeba týden. Ale udělat testy na bambilion vstupů budou ještě mnohem horší s horší efektivitou.

Ja to vidim nekde mezi. V clojure (ale i v dalsich lispech) je totiz "write time" = runtime. To znamena, ze kazdy vyraz ktery napisu hned evaluuju a mam ho k dispozici v bezicim REPLu. Takze kdyz treba pisu funkci a jeji specifikaci viz https://clojure.org/guides/spec#_spec_ing_functions (https://clojure.org/guides/spec#_spec_ing_functions)  muzu klidne tam kde ji volam pomoci valid? nebo conform overit jestli je dane volani odpovida specifikaci. A kdyz si to budu nechavat instrumentovat abych to nemusel zkouset rucne tak se blizim typovemu systemu. (popravde ja to tak nedelam, ale ja taky uz dneska moc kodu nenapisu...)
Já jsem to clojure spec viděl zatím jen z rychlíku (princip REPL ale znám). Když si tedy trochu zaspekuluju: buť tam tedy narve kontrolu na typ, něco jako (v jiném jazyce, chápu že v lispu se to zapíše jinak):
Kód: [Vybrat]
fn inc(a):
    assert(a, "int:1..100")
    ...
případně tam můžu narvat klasickej test aka:

Kód: [Vybrat]
fn inc(a):
    ...
with:
    assert inc(1) == 2
    assert inc(99) == 100

nebo
Kód: [Vybrat]
fn inc(a):
    ...
with:
    foreach x in datasample.rangeint(1..100):
        assert inc(x) == x + 1

Tak nějak?

V prvém případě se to chová jako typ s tím, že blbě vytáhnu signaturu tý funkce (což je ale asi jen otázka řešení toho spec-u, nikoliv principielní problém). V tom druhém a třetím případě je to klasický unittest s výhodami a nevýhodami, které testy mají.

Na druhou stranu je to kompaktní :-)

Výhodu toho spec-u bych viděl v tom, že by měl být deklarativní, tudíž čitelnější než klasické testy, a dají se na to udělat nějaká vizualizovátka, metriky a podobně. Souhlas?

To ze z toho generuju testy je side effect, ale velmi prijemny. Podle me to prave preklenuje tu mezeru kterou zpusobuji prakticka omezeni na strane unit testu a typoveho systemu. Tam kde by typova specifikace zacinala byt neprakticka a pri tom nebyla kriticka muzu nechat generator chroustat misto abych ja musel cucat z prstu hodnoty ktere se maji vyzkouset.

Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost. Že člověku se prostě někdy hodí tu kontrolu vypnout (ve výsledku často zjistí, že to byl blbej nápad, ale což). Nebo že vyžaduje příliš přemýšlení, když potřebuju jen něco vyzkoušet.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 27. 06. 2018, 21:15:20
V prvém případě se to chová jako typ s tím, že blbě vytáhnu signaturu tý funkce (což je ale asi jen otázka řešení toho spec-u, nikoliv principielní problém). V tom druhém a třetím případě je to klasický unittest s výhodami a nevýhodami, které testy mají.

Na druhou stranu je to kompaktní :-)

Podle me spis prvni pripad:
Kód: [Vybrat]
(ns spec-example.core
  (:require [clojure.spec.alpha :as s]
            [clojure.spec.test.alpha :as stest])
  (:gen-class))

;; definuju predikat a ulozim do registru => znovupouzitelnost
;; taky je videt ze to hezky komponuje skladam predikat z mensich predikatu
(s/def ::small-pos-int (s/and pos-int? #(<= % 100)))

;; definice funkce
(defn -inc
  [a]
  (+ a 1))
;; specifikace ktera zatim nic nedela
(s/fdef -inc
  :args  (s/cat :a ::small-pos-int)  ;; validace vstupu
  :ret pos-int?                      ;; validace vystupu
  :fn #(> (:ret %) (-> % :args :a))) ;; trivialni a neuplna validace vystupu vzhledem ke vstupum

;; zapnu instrumentaci
;; od ted se budou pred exekuci funkce validovat vstupy
;; :ret a :fn samozrejme vyzaduje aby byla funkce provedena,
;; protoze potrebuju navratovou hodnotu
;; takze to uz spada spis do testu nez do typu
(stest/instrument `-inc)

;; nekde v kodu budu chti funkci pouzit
(let [a 105]
  (-inc a))

;; vyhodi mi to:
;;  ExceptionInfo Call to #'spec-example.core/-inc did not conform to spec:
;;  In: [0] val: 105 fails spec: :spec-example.core/small-pos-int at: [:args :a] predicate: (<= % 100)
;;    clojure.core/ex-info (core.clj:4739)
;; drivejsi verze tusim dokonce vyhazovala CompilerException
;; coz mozna jeste vic dava najevo, ze funkce vlastne vubec nebyla spustena

Výhodu toho spec-u bych viděl v tom, že by měl být deklarativní, tudíž čitelnější než klasické testy, a dají se na to udělat nějaká vizualizovátka, metriky a podobně. Souhlas?
Asi uplne nerozumim, ale mozna ze ten priklad na to odpovida sam

To ze z toho generuju testy je side effect, ale velmi prijemny. Podle me to prave preklenuje tu mezeru kterou zpusobuji prakticka omezeni na strane unit testu a typoveho systemu. Tam kde by typova specifikace zacinala byt neprakticka a pri tom nebyla kriticka muzu nechat generator chroustat misto abych ja musel cucat z prstu hodnoty ktere se maji vyzkouset.

Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.
Cet sem tady na rootu clanek od tisnika o gherkin a domnivam se, ze v budoucnosti budou psat specifikaci testu business analitici ve forme given/when/then a potom uz se toho chytne automat

Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost. Že člověku se prostě někdy hodí tu kontrolu vypnout (ve výsledku často zjistí, že to byl blbej nápad, ale což). Nebo že vyžaduje příliš přemýšlení, když potřebuju jen něco vyzkoušet.
Spis mam na mysli to premysleni. To nekdy boli.
Takze u nekriticke casti aplikace specifikuju jen do chvile nez to zacne bolet a na zbytek pustim generator testu.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 21:24:04
Kód: [Vybrat]
(ns spec-example.core
  (:require [clojure.spec.alpha :as s]
            [clojure.spec.test.alpha :as stest])
  (:gen-class))

;; definuju predikat a ulozim do registru => znovupouzitelnost
;; taky je videt ze to hezky komponuje skladam predikat z mensich predikatu
(s/def ::small-pos-int (s/and pos-int? #(<= % 100)))

;; definice funkce
(defn -inc
  [a]
  (+ a 1))
;; specifikace ktera zatim nic nedela
(s/fdef -inc
  :args  (s/cat :a ::small-pos-int)  ;; validace vstupu
  :ret pos-int?                      ;; validace vystupu
  :fn #(> (:ret %) (-> % :args :a))) ;; trivialni a neuplna validace vystupu vzhledem ke vstupum

;; zapnu instrumentaci
;; od ted se budou pred exekuci funkce validovat vstupy
;; :ret a :fn samozrejme vyzaduje aby byla funkce provedena,
;; protoze potrebuju navratovou hodnotu
;; takze to uz spada spis do testu nez do typu
(stest/instrument `-inc)

;; nekde v kodu budu chti funkci pouzit
(let [a 105]
  (-inc a))

;; vyhodi mi to:
;;  ExceptionInfo Call to #'spec-example.core/-inc did not conform to spec:
;;  In: [0] val: 105 fails spec: :spec-example.core/small-pos-int at: [:args :a] predicate: (<= % 100)
;;    clojure.core/ex-info (core.clj:4739)
;; drivejsi verze tusim dokonce vyhazovala CompilerException
;; coz mozna jeste vic dava najevo, ze funkce vlastne vubec nebyla spustena
Budu se muset do toho spec-u ponořit. Díky za inspiraci.
Název: Re:Typový system versus unittesty
Přispěvatel: Kiwi 27. 06. 2018, 22:17:04
Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost.
A co je to vlastně ta "ultimátnost"? S tím slovem jsem se ještě nesetkal.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 22:36:16
Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jednotkové testy, tedy alespoň jejich boilerplates, ve Vimu generuji už dávno. Podobně mi generuje i signatury v Haskellu. Není třeba čekat na budoucnost.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 22:52:27
Sorry, ale za to zatrollení diskuze si můžeš IMO primárně sám. Většina téhle diskuze je o tom, že ostatní šijou do tvých kategorických tvrzení.

Ale no tak!

Takže když napíšu "Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém." je to přes čáru? A místní smetánka, která věci sice nerozumí, ale má tím pádem právo mě trollit? To jako vážně?!

Není to přes čáru. Je to názor, o kterém tu polemizujeme. Z opačné strany je můj názor, že statický typový systém není potřebný, pokud mám kvalitní testování. Pokud je někdo přesvědčen o svém názoru, musí být připraven na protiargumenty oponentů. Prohrává ten, kdo svého oponenta začne ponižovat, protože to je jasným důkazem, že mu došly argumenty.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 22:53:04
Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jednotkové testy, tedy alespoň jejich boilerplates, ve Vimu generuji už dávno.

A pak je mažeš?
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 23:06:33
Pokud je někdo přesvědčen o svém názoru, musí být připraven na protiargumenty oponentů. Prohrává ten, kdo svého oponenta začne ponižovat, protože to je jasným důkazem, že mu došly argumenty.

Když začnu oponenta ponižovat ukazuje to nedostatek mého charakteru. Třeba nedostatek sebeovládání.
A jsou i jiné důvody, proč člověk vzdá diskusi, než jen to, že by došli argumenty.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 23:13:36
Pokud je někdo přesvědčen o svém názoru, musí být připraven na protiargumenty oponentů. Prohrává ten, kdo svého oponenta začne ponižovat, protože to je jasným důkazem, že mu došly argumenty.

Když začnu oponenta ponižovat ukazuje to nedostatek mého charakteru. Třeba nedostatek sebeovládání.
A jsou i jiné důvody, proč člověk vzdá diskusi, než jen to, že by došli argumenty.

Když vzdáš diskuzi, tak to ještě nemusí být prohra. Prostě jste se nedobrali konsenzu, to se stává.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 23:13:45
Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost.
A co je to vlastně ta "ultimátnost"? S tím slovem jsem se ještě nesetkal.

Asi takhle. Pomocí testů můžeš otestovat pár vhodných případů, ale nemůžeš otestovat všechny. Nejen, že by si se upsal, ale u negativních to třeba vůbec nejde (https://forum.root.cz/index.php?topic=18804.msg271719#msg271719). Pomocí typů zajistíš naprosto bez výjimky všechny případy.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 23:17:57
Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jednotkové testy, tedy alespoň jejich boilerplates, ve Vimu generuji už dávno.

A pak je mažeš?

Ne. Stávají se součástí dokumentace. Pouze je rozšiřuji a modifikuji, aby lépe testovaly okrajové stavy a různé výjimky.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 23:24:48
Asi takhle. Pomocí testů můžeš otestovat pár vhodných případů, ale nemůžeš otestovat všechny. Nejen, že by si se upsal, ale u negativních to třeba vůbec nejde (https://forum.root.cz/index.php?topic=18804.msg271719#msg271719). Pomocí typů zajistíš naprosto bez výjimky všechny případy.

Testy na negativní případy se naopak píší zcela běžně, podle mne dokonce převažují nad pozitivními případy. Pokud metoda má vyhazovat tři výjimky při chybných vstupech, musím otestovat všechny.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 23:25:10
Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jednotkové testy, tedy alespoň jejich boilerplates, ve Vimu generuji už dávno.

A pak je mažeš?

Ne. Stávají se součástí dokumentace.
Tak to pak není to co mám na mysli.
Moje prognóza je, že IDE (nebo jakýkoliv jiný nástroj) perfektně rozumí kódu a je schopen na požádání vygenerovat ukázky kódu. Žádný další smysl nemají. Tudíž nebude mít smysl je uchovávat.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 23:27:38
Asi takhle. Pomocí testů můžeš otestovat pár vhodných případů, ale nemůžeš otestovat všechny. Nejen, že by si se upsal, ale u negativních to třeba vůbec nejde (https://forum.root.cz/index.php?topic=18804.msg271719#msg271719). Pomocí typů zajistíš naprosto bez výjimky všechny případy.

Testy na negativní případy se naopak píší zcela běžně, podle mne dokonce převažují nad pozitivními případy. Pokud metoda má vyhazovat tři výjimky při chybných vstupech, musím otestovat všechny.
Ty chybné vstupy nejsu tři, ale nekonečno.
Můžeš si všimnout, že v mém příspěvku nepíši o tom, že by se negativní testy nepsali vůbec.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 27. 06. 2018, 23:52:35
Moje prognóza je, že IDE (nebo jakýkoliv jiný nástroj) perfektně rozumí kódu a je schopen na požádání vygenerovat ukázky kódu. Žádný další smysl nemají. Tudíž nebude mít smysl je uchovávat.

To není problém, protože už v první fázi překladu získáš derivační strom, který je základem pro jeho pochopení strojem. Když to interpretuješ jiným derivačním stromem, dostaneš výslednou aplikaci nebo testy. Dosud se však nevyplatilo vytváření derivačního stromu pro generování testů, neboť se do něj stejně musí doplnit okrajové podmínky.

V praxi to pak bude vypadat tak, že v záhlaví testované metody budou definovány tyto okrajové podmínky. Pak už nebude nutné testy generovat do dalších souborů, ale budou se přímo interpretovat z těchto záhlaví. Přiblíží se tak k typovým signaturám, ale budou dokonalejší. Pro některé jazyky to už více či méně funguje.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 27. 06. 2018, 23:56:06
Přiblíží se tak k typovým signaturám, ale budou dokonalejší. Pro některé jazyky to už více či méně funguje.

Tak, o tom to celé je.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 28. 06. 2018, 00:11:07
Jinak tohle neznám, ale co jsem pochopil, tak je to automatické dokazování některých vlastností (refinement types)..

https://ucsd-progsys.github.io/liquidhaskell-blog/ (https://ucsd-progsys.github.io/liquidhaskell-blog/)

Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 28. 06. 2018, 00:30:32
Jinak tohle neznám, ale co jsem pochopil, tak je to automatické dokazování některých vlastností (refinement types)..

https://ucsd-progsys.github.io/liquidhaskell-blog/ (https://ucsd-progsys.github.io/liquidhaskell-blog/)

Hezký, díky.
Název: Re:Typový system versus unittesty
Přispěvatel: nv 28. 06. 2018, 00:41:01
Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost.
A co je to vlastně ta "ultimátnost"? S tím slovem jsem se ještě nesetkal.

Takové slovo vůbec neexistuje.
Ultimus znamená latinsky poslední.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 28. 06. 2018, 01:12:47
Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost.
A co je to vlastně ta "ultimátnost"? S tím slovem jsem se ještě nesetkal.

Takové slovo vůbec neexistuje.
Ultimus znamená latinsky poslední.
He, to jsem ani netušil :-)
Název: Re:Typový system versus unittesty
Přispěvatel: v 28. 06. 2018, 09:33:00
Jinak tohle neznám, ale co jsem pochopil, tak je to automatické dokazování některých vlastností (refinement types)..

https://ucsd-progsys.github.io/liquidhaskell-blog/ (https://ucsd-progsys.github.io/liquidhaskell-blog/)

Hezký, díky.
připomělo mi to tohle https://github.com/hwayne/lets-prove-leftpad
verze v idrisu je zajímavě stručná
Název: Re:Typový system versus unittesty
Přispěvatel: Ghhh 28. 06. 2018, 10:24:28
Jak nahradim unit test, kdyz chci otestovat funkci pro vypocet kvadraticke rovnice a spletu se ve vzorci?

Typovy system mi moc nepomuze, ne?
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 28. 06. 2018, 11:09:25
Jak nahradim unit test, kdyz chci otestovat funkci pro vypocet kvadraticke rovnice a spletu se ve vzorci?

Typovy system mi moc nepomuze, ne?

Možná by stačilo vypočtené kořeny dosadit do té kvadratické rovnice, což snad půjde také provést v těch typech.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 28. 06. 2018, 12:32:45
Jak nahradim unit test, kdyz chci otestovat funkci pro vypocet kvadraticke rovnice a spletu se ve vzorci?

Typovy system mi moc nepomuze, ne?

Možná by stačilo vypočtené kořeny dosadit do té kvadratické rovnice, což snad půjde také provést v těch typech.
Nevím, jak dobře půjde symbolicky kontrolovat floatové výpočty. Má to vycházet pro ideální reálná čísla, nebo pro floaty včetně nekonečen a nanů? A s jakou přesností?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 28. 06. 2018, 13:07:04
Jak nahradim unit test, kdyz chci otestovat funkci pro vypocet kvadraticke rovnice a spletu se ve vzorci?

Typovy system mi moc nepomuze, ne?

Možná by stačilo vypočtené kořeny dosadit do té kvadratické rovnice, což snad půjde také provést v těch typech.
Jenže kompilátor neví nic o kvadratických rovnicích, takže to z typů nijak neodvodí. Ale to je právě ten spor, který tady vedeme – existují určité doménové znalosti, a část z nich je přenesena do kódu, ať už v podobě příkazů nebo pravidel. Jednotkové testy nejsou nic jiného, než snaha nezávislým způsobem ověřit, že jsou ty doménové znalosti přenesené do kódu správně. Vedlejším efektem těchto testů je, že se zkontroluje, zda vůbec dává smysl kód sám o sobě – jestli se třeba nepokouší provádět nedefinovanou operaci (třeba násobení textů nebo dělení nulou). Někteří zde ovšem tento vedlejší efekt testů považují za jejich hlavní a jediný účel, z čehož plyne jejich přesvědčení, že by se jednotkové testy vlastně daly úplně zrušit.

Mimochodem, k představě, že všechny jednotkové testy bude umět vytvořit nějaký automat, je vhodné dodat, že až ten automat bude umět pochopit danou doménu a napsat testy, bude umět naprogramovat i ten výkonný kód.
Název: Re:Typový system versus unittesty
Přispěvatel: v 28. 06. 2018, 13:24:45
Jak nahradim unit test, kdyz chci otestovat funkci pro vypocet kvadraticke rovnice a spletu se ve vzorci?

Typovy system mi moc nepomuze, ne?

Možná by stačilo vypočtené kořeny dosadit do té kvadratické rovnice, což snad půjde také provést v těch typech.
v celých číslech si to docela umím představit (sčítání a násobení je jednoduché, už jsem tu dával odkaz, několikrát), s reálnýma si to představit už neumím :)
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 28. 06. 2018, 13:33:02
Jak nahradim unit test, kdyz chci otestovat funkci pro vypocet kvadraticke rovnice a spletu se ve vzorci?

Typovy system mi moc nepomuze, ne?

Možná by stačilo vypočtené kořeny dosadit do té kvadratické rovnice, což snad půjde také provést v těch typech.
v celých číslech si to docela umím představit (sčítání a násobení je jednoduché, už jsem tu dával odkaz, několikrát), s reálnýma si to představit už neumím :)

S reálnými čísly by to šlo taky, pokud by program skutečně pracoval s reálnými hodnotami. S něčím takovým jsem se setkal pouze u analogového počítače, což už je docela historie.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 28. 06. 2018, 13:34:08
Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.

Nepopisujete nic jiného než obdobu typového systému či jednotkového testu - z popisu nejde pozdnat, čemu je to blíže. Představa, že za vás nějaký jednoduchý systém bezpracně otestuje funkcionalitu, je nesmyslná.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 28. 06. 2018, 13:38:18
S reálnými čísly by to šlo taky, pokud by program skutečně pracoval s reálnými hodnotami. S něčím takovým jsem se setkal pouze u analogového počítače, což už je docela historie.
Co přesně myslíš těma "reálnýma hodnotama"? I analogové počítače měly jenom omezenou přesnost, takže i tam může nastat ztráta přesnosti.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 28. 06. 2018, 13:55:06
S reálnými čísly by to šlo taky, pokud by program skutečně pracoval s reálnými hodnotami. S něčím takovým jsem se setkal pouze u analogového počítače, což už je docela historie.
Co přesně myslíš těma "reálnýma hodnotama"? I analogové počítače měly jenom omezenou přesnost, takže i tam může nastat ztráta přesnosti.

Správně. V tom případě mohu s klidným svědomím prohlásit, že současné počítače s reálnými čísly nepracují. Pouze s čísly celými a racionálními. Racionální čísla jsou podílem celých čísel. Že se používají pojmy integer, decimal, float nebo complex znamená jen to, že jsme je potřebovali rozlišit v dřevních dobách, kdy se šetřilo každým bajtem. Dnešní programy však už umí pracovat s racionálními čísly téměř s neomezenou přesností. Otázkou však zůstává, k čemu by to bylo.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 28. 06. 2018, 14:00:59
V praxi to pak bude vypadat tak, že v záhlaví testované metody budou definovány tyto okrajové podmínky. Pak už nebude nutné testy generovat do dalších souborů, ale budou se přímo interpretovat z těchto záhlaví. Přiblíží se tak k typovým signaturám, ale budou dokonalejší. Pro některé jazyky to už více či méně funguje.

To jako toto? https://en.wikipedia.org/wiki/Design_by_contract (https://en.wikipedia.org/wiki/Design_by_contract) To je jen chytřejší variantou jednoduchých typů. Jednotkové testy tím nejde nahradit, protože tím nejde udělat test "když je na vstupu něco, bude na výstupu něco".
Název: Re:Typový system versus unittesty
Přispěvatel: SB 28. 06. 2018, 14:10:26
Jenže kompilátor neví nic o kvadratických rovnicích, takže to z typů nijak neodvodí. Ale to je právě ten spor, který tady vedeme – existují určité doménové znalosti, a část z nich je přenesena do kódu, ať už v podobě příkazů nebo pravidel. Jednotkové testy nejsou nic jiného, než snaha nezávislým způsobem ověřit, že jsou ty doménové znalosti přenesené do kódu správně. Vedlejším efektem těchto testů je, že se zkontroluje, zda vůbec dává smysl kód sám o sobě – jestli se třeba nepokouší provádět nedefinovanou operaci (třeba násobení textů nebo dělení nulou). Někteří zde ovšem tento vedlejší efekt testů považují za jejich hlavní a jediný účel, z čehož plyne jejich přesvědčení, že by se jednotkové testy vlastně daly úplně zrušit.

Mimochodem, k představě, že všechny jednotkové testy bude umět vytvořit nějaký automat, je vhodné dodat, že až ten automat bude umět pochopit danou doménu a napsat testy, bude umět naprogramovat i ten výkonný kód.

Tento komentář považuju za shrnující. Nenapadá mě, co dodat.
Název: Re:Typový system versus unittesty
Přispěvatel: v 28. 06. 2018, 14:17:41
Jenže kompilátor neví nic o kvadratických rovnicích, takže to z typů nijak neodvodí. Ale to je právě ten spor, který tady vedeme – existují určité doménové znalosti, a část z nich je přenesena do kódu, ať už v podobě příkazů nebo pravidel. Jednotkové testy nejsou nic jiného, než snaha nezávislým způsobem ověřit, že jsou ty doménové znalosti přenesené do kódu správně. Vedlejším efektem těchto testů je, že se zkontroluje, zda vůbec dává smysl kód sám o sobě – jestli se třeba nepokouší provádět nedefinovanou operaci (třeba násobení textů nebo dělení nulou). Někteří zde ovšem tento vedlejší efekt testů považují za jejich hlavní a jediný účel, z čehož plyne jejich přesvědčení, že by se jednotkové testy vlastně daly úplně zrušit.

Mimochodem, k představě, že všechny jednotkové testy bude umět vytvořit nějaký automat, je vhodné dodat, že až ten automat bude umět pochopit danou doménu a napsat testy, bude umět naprogramovat i ten výkonný kód.

Tento komentář považuju za shrnující. Nenapadá mě, co dodat.
naopak by šlo ubrat, stačila by jenom první věta
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 28. 06. 2018, 14:24:28
V praxi to pak bude vypadat tak, že v záhlaví testované metody budou definovány tyto okrajové podmínky. Pak už nebude nutné testy generovat do dalších souborů, ale budou se přímo interpretovat z těchto záhlaví. Přiblíží se tak k typovým signaturám, ale budou dokonalejší. Pro některé jazyky to už více či méně funguje.

To jako toto? https://en.wikipedia.org/wiki/Design_by_contract (https://en.wikipedia.org/wiki/Design_by_contract) To je jen chytřejší variantou jednoduchých typů. Jednotkové testy tím nejde nahradit, protože tím nejde udělat test "když je na vstupu něco, bude na výstupu něco".

Ne, v daném případě mám na mysli tohle:
Kód: [Vybrat]
<?php
class Calculator {
    
/**
     * @assert (0, 0) == 0
     * @assert (3, 5) == 8
     * @assert (-3, 5) == 2
     * @assert (3, -5) == -2
     * @assert (-3, -5) == 8
     */
    
public function sum($a$b) {
        return 
$a $b;
    }
}

Z tohoto kódu se dnes běžně generují testy, ovšem stejně dobře se z toho dají přímo interpretovat.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 28. 06. 2018, 14:27:37
Správně. V tom případě mohu s klidným svědomím prohlásit, že současné počítače s reálnými čísly nepracují. Pouze s čísly celými a racionálními. Racionální čísla jsou podílem celých čísel. Že se používají pojmy integer, decimal, float nebo complex znamená jen to, že jsme je potřebovali rozlišit v dřevních dobách, kdy se šetřilo každým bajtem. Dnešní programy však už umí pracovat s racionálními čísly téměř s neomezenou přesností. Otázkou však zůstává, k čemu by to bylo.
No ale o to mi jde. Jak pak ten typový systém může porovnávat nějaké výpočty? Jak může zkontrolovat že nějaký vzoreček tu kvadratickou rovnici opravdu řeší? Symbolickým dosazováním nějaké katastrofické krácení neodhalí.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 28. 06. 2018, 15:17:27
Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.

Nepopisujete nic jiného než obdobu typového systému či jednotkového testu - z popisu nejde pozdnat, čemu je to blíže. Představa, že za vás nějaký jednoduchý systém bezpracně otestuje funkcionalitu, je nesmyslná.

Nechapu. Prece tam sam pisu ze je to neco jako typovy system.  A nemam ani zminovanou predstavu.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 28. 06. 2018, 15:43:26
Citace
Jenže kompilátor neví nic o kvadratických rovnicích, takže to z typů nijak neodvodí
Ale kompilátor může vědět něco o symbolické matematice a nějaké další matematické axiomy ho můžeme naučit. Pokud bychom měli typový systém, který by uměl symolickou matematiku, tak jaký je problém napsat něco typu:
Kód: [Vybrat]
resKvadRovnici :: a : Num -> b : Num -> c : Num -> [x] | a * x^2 + b * x + c * x = 0
A systémy, které umí symbolickou matematiku tady máme a když se jich zeptáme, jestli daný vzoreček řeší kvadratickou rovnici, tak jsou schopny na to dát jasnou odpověď. Ne vždycky (halting problem), ale o to nejde.

Konec konců, ten příklad s leftPad je moc hezký - copak typový systém ví něco o zarovnávání z leva? Ale dá se mu to vysvětlit.

Ale myslím, že je trošku nepochopení, k čemu typový systém je. Byl tady dotaz, že jak testovat v tom mém příkladu, že u:
Kód: [Vybrat]
Num op a b = op a b
nedošlo k prohození "a" a b". Jenomže to jde otestovat leda tak, že se napíše specifikace, která bude vypadat přesně stejně. Takže se problém chyby přesune od kódu ke specifikaci a vůbec nic to nevyřeší, jen místo toho, zda kód je správně budeme řešit, jestli specifikace je správně. IMO typový systém (nebo obecně dokazování) má smysl tam, kde specifikace a kód není totéž. Ale jinak bych zopakoval, že u všech těchto věcí (testy, typy) je vhodné si položit otázku, zda se to vyplatí - a při dobrém využití typů (na doméně, kde to funguje dobře) výhoda těch testů dost klesá, protože těch chyb je tam z principu výrazně méně.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 28. 06. 2018, 15:55:12
Ne, v daném případě mám na mysli tohle:
Kód: [Vybrat]
<?php
class Calculator {
    
/**
     * @assert (0, 0) == 0
     * @assert (3, 5) == 8
     * @assert (-3, 5) == 2
     * @assert (3, -5) == -2
     * @assert (-3, -5) == 8
     */
    
public function sum($a$b) {
        return 
$a $b;
    }
}

Z tohoto kódu se dnes běžně generují testy, ovšem stejně dobře se z toho dají přímo interpretovat.

Supr, tak se začínáme blížit k těm jednotkovým testům, ale ještě tam nejsme, protože tato notace neřeší stav objektu, na kterém je výsledek té metody/funkce závislý (myšleno obecně, ne této triviální funkcičky). Generátor Rand tím taky neotestujete.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 28. 06. 2018, 16:19:55
Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.

Nepopisujete nic jiného než obdobu typového systému či jednotkového testu - z popisu nejde pozdnat, čemu je to blíže. Představa, že za vás nějaký jednoduchý systém bezpracně otestuje funkcionalitu, je nesmyslná.

Nechapu. Prece tam sam pisu ze je to neco jako typovy system.  A nemam ani zminovanou predstavu.

Ale ten my už máme, teď potřebujeme nějaký lepší (ale snesitelně složitý!), ze kterého si sedneme na pr-del a zavrhneme jednotkové testy jako překonané (na to se přece v této diskusi čeká).

Hromadná kontrola se dá udělat několika způsoby:
- ručně tam ty páry vstup-výstup naboucháte - to nechcete
- použijete data driven testing, to je ale to samé, protože to taky odněkud ta data potřebuje získat - taky k hovnu
- znovuimplementujete výpočet stejně - bude to tentokrát bezchybné?
- znovuimplementujete výpočet jinak - to samé jako výše
Takže s tou o řád vyšší kvalitou protestování bych byl opatrný.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 28. 06. 2018, 16:47:20
Supr, tak se začínáme blížit k těm jednotkovým testům, ale ještě tam nejsme, protože tato notace neřeší stav objektu, na kterém je výsledek té metody/funkce závislý (myšleno obecně, ne této triviální funkcičky). Generátor Rand tím taky neotestujete.

Tohle je jen primitivní ukázka, jak se dají jednotkové testy vložit do jazyka, který s nimi původně vůbec nepočítal. Tahle testuje bezstavovou metodu. Není to test jednotkový, ale vývojářský. Podobný test, tentokrát jednotkový a stavový, se dá vložit do záhlaví třídy. Nevýhodou tohoto řešení však je, že testy bývají zhruba 2× delší než produkční kód, po kompilaci na produkci v něm stále překáží - jsou součástí binárky.

V Javě je to o něco lepší - tam se dá test vložit přes statickou vnitřní třídu, která však do produkce nejde. Ovšem už se to nepodobá zmíněným typům.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 28. 06. 2018, 17:17:34
Ale kompilátor může vědět něco o symbolické matematice a nějaké další matematické axiomy ho můžeme naučit.
Ano, některé věci můžeme schovat do knihoven a knihovny klidně do kompilátoru nebo až do procesoru. Ty pak bereme za dané a podle míry jejich složitosti už je ani netestujeme. Programátoři dnes obvykle neprogramují, jak sečíst dvě 32bitová čísla, ale spoléhají na to, že to instrukce procesoru děla správně. Pořád je ale potřeba programátor na to, aby procesoru „vysvětlil“, že když má v jednom registru částku a v druhém registru DPH, cenu s DPH spočítá právě sečtením těch dvou registrů.

A systémy, které umí symbolickou matematiku tady máme a když se jich zeptáme, jestli daný vzoreček řeší kvadratickou rovnici, tak jsou schopny na to dát jasnou odpověď. Ne vždycky (halting problem), ale o to nejde.
Ano, ale k tomu musíme umět tou symbolickou matematikou popsat, co je to kvadratická rovnice. A pokud tomu systému popíšu kvadratickou rovnici jako součet násobku druhé mocniny proměnné a násobku proměnné, tj. zapomenu na to, že v kvadratické rovnici může být také konstanta, ten systém to nijak nezjistí. V systému symbolické matematiky je taková rovnice možná, je to podmnožina kvadratických rovnic. A není to chyba toho systému ani odvozování, je to chyba v převodu mezi reálným světem a formálním jazykem (v tomto případě symbolickou matematikou).

Konec konců, ten příklad s leftPad je moc hezký - copak typový systém ví něco o zarovnávání z leva? Ale dá se mu to vysvětlit.
Ano, naprogramovat se dá leccos, i mnohem složitější věci, než je zarovnávání zleva :-) A jsou různé způsoby, jak to naprogramovat, dá se to naprogramovat imperativně i deklarativně a je to vzájemně převoditelné. Rozdíl není na straně počítače (i když fakticky se nakonec vše převádí na imperativní, protože tak pracují dnešní procesory), rozdíl je na straně lidí – některé věci se nám lépe vyjadřují deklarativně, některé raději vyjadřujeme imperativně.

Ale myslím, že je trošku nepochopení, k čemu typový systém je.
Taky si myslím. Typový systém je jen jiný způsob vyjádření, nic míň, ale ani nic víc.

Jenomže to jde otestovat leda tak, že se napíše specifikace, která bude vypadat přesně stejně. Takže se problém chyby přesune od kódu ke specifikaci a vůbec nic to nevyřeší, jen místo toho, zda kód je správně budeme řešit, jestli specifikace je správně.
Ano, to tvrdím od začátku. Takhle se to ale dá odsouvat do nekonečna, a o správnosti se nedozvíme nikdy nic. Proto se často testuje to, že vezmu něco mnohem jednoduššího, než specifikaci, o čem ale vím, že je to správně, a otestuju jenom tyhle zaručeně správné případy. Tím nezískám odpověď na otázku, zda je to celé správně, ale dozvím se alespoň to, že tam je aspoň něco správně.

IMO typový systém (nebo obecně dokazování) má smysl tam, kde specifikace a kód není totéž. Ale jinak bych zopakoval, že u všech těchto věcí (testy, typy) je vhodné si položit otázku, zda se to vyplatí - a při dobrém využití typů (na doméně, kde to funguje dobře) výhoda těch testů dost klesá, protože těch chyb je tam z principu výrazně méně.
A stejně tak existují domény, kde nesou potřeba žádné složité typy a kde zároveň největší množství chyb vzniká při převodu mezi neformálním zadáním a formálním programovacím jazykem. A tam je zase minimum chyb, které by bylo možné odstranit lepšími typy.
Název: Re:Typový system versus unittesty
Přispěvatel: Phi 28. 06. 2018, 18:17:19
Halting problem se týká univerzálního algoritmu který by dokázal pro jakýkoliv program s jakýmkoliv vstupem rozhodnout, zda dokončí nebo nedokončí běh. Turing nikdy neřekl, že neexistuje algoritmus, který by pro konkrétní program nedokázal rozhodnout, zda dokončí či nedokončí. To je velký rozdíl.

Zjevně jsi nepřečetl ten odstavec, který jsem doporučoval:

The halting problem is theoretically decidable for linear bounded automata (LBAs) or deterministic machines with finite memory. Minsky warns us, however, that machines such as computers with e.g., a million small parts, each with two states, will have at least 21,000,000 possible states: This is a 1 followed by about three hundred thousand zeroes ... Even if such a machine were to operate at the frequencies of cosmic rays, the aeons of galactic evolution would be as nothing compared to the time of a journey through such a cycle.

V dněšních počítačích a běžných programech je těch stavů ještě o mnoho řádů více. Mnoho štěstí s testováním.
A drtivá většina z těch stavů je irrelevantních nebo je lze považovat za víceméně duplicity.
Při testování mne typicky nezajímá, jestli je program otestován při kompilaci na na adresu 0, na adresu 1, na adresu 2 nebo na adresu 10000000. Stejně tak mne nezajímá, jestli je o testován na jádru 1, na jádru 2, nebo kam nahrál OS runtime knihovny. Zajímají mne stavy možné v doméně jazyka v kterém programuji.
Jiný příklad je ten random(), ten se taky netestuje výčtem stavů, ale tím že na vzorku pustím statistické testy. Překvapivě to funguje, i když podle vás by nemělo.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 28. 06. 2018, 18:20:18
Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.

Nepopisujete nic jiného než obdobu typového systému či jednotkového testu - z popisu nejde pozdnat, čemu je to blíže. Představa, že za vás nějaký jednoduchý systém bezpracně otestuje funkcionalitu, je nesmyslná.

Nechapu. Prece tam sam pisu ze je to neco jako typovy system.  A nemam ani zminovanou predstavu.

Ale ten my už máme, teď potřebujeme nějaký lepší (ale snesitelně složitý!), ze kterého si sedneme na pr-del a zavrhneme jednotkové testy jako překonané (na to se přece v této diskusi čeká).

Hromadná kontrola se dá udělat několika způsoby:
- ručně tam ty páry vstup-výstup naboucháte - to nechcete
- použijete data driven testing, to je ale to samé, protože to taky odněkud ta data potřebuje získat - taky k hovnu
- znovuimplementujete výpočet stejně - bude to tentokrát bezchybné?
- znovuimplementujete výpočet jinak - to samé jako výše
Takže s tou o řád vyšší kvalitou protestování bych byl opatrný.

Myslim, ze u rady problemu je overeni spravnosti vypoctu trivialni kdezto vypocet samotny je slozity.
A kdyz zakomponuju overeni spravnosti do konstrukce navratoveho typu zarucim tim ze nepujde vytvorit navratovy typ obsahujici nespravny vysledek.

Ano je to v podstate znovuimplementace jinak, a da se v tom taky udelat chyba, ale pokud je to overeni opravdu radove jednodussi dava mi to vetsi smysl, nez napsat par testu rucne.


 
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 28. 06. 2018, 18:52:50
Myslim, ze u rady problemu je overeni spravnosti vypoctu trivialni kdezto vypocet samotny je slozity.
A kdyz zakomponuju overeni spravnosti do konstrukce navratoveho typu zarucim tim ze nepujde vytvorit navratovy typ obsahujici nespravny vysledek.
Jistě existuje řada takových problémů, ale podle mne se to netýká drtivé většiny problémů řešených dnešními programy. Navíc to ověření správnosti zabere nějaký výkon za běhu – lepší je (obvykle) ověřit správnost v době vytváření programu a za běhu se už jen spoléhat na to, že to prostě je správně.
Název: Re:Typový system versus unittesty
Přispěvatel: hawran diskuse 28. 06. 2018, 19:38:51
....
Jenže kompilátor neví nic o kvadratických rovnicích, takže to z typů nijak neodvodí. Ale to je právě ten spor, který tady vedeme – existují určité doménové znalosti, a část z nich je přenesena do kódu, ať už v podobě příkazů nebo pravidel. Jednotkové testy nejsou nic jiného, než snaha nezávislým způsobem ověřit, že jsou ty doménové znalosti přenesené do kódu správně. Vedlejším efektem těchto testů je, že se zkontroluje, zda vůbec dává smysl kód sám o sobě – jestli se třeba nepokouší provádět nedefinovanou operaci (třeba násobení textů nebo dělení nulou). Někteří zde ovšem tento vedlejší efekt testů považují za jejich hlavní a jediný účel, z čehož plyne jejich přesvědčení, že by se jednotkové testy vlastně daly úplně zrušit.

Mimochodem, k představě, že všechny jednotkové testy bude umět vytvořit nějaký automat, je vhodné dodat, že až ten automat bude umět pochopit danou doménu a napsat testy, bude umět naprogramovat i ten výkonný kód.
+1
(obdivuji Tvou trpělivost)
Název: Re:Typový system versus unittesty
Přispěvatel: hawran diskuse 28. 06. 2018, 19:43:25
...
A kdyz zakomponuju overeni spravnosti do konstrukce navratoveho typu zarucim tim ze nepujde vytvorit navratovy typ obsahujici nespravny vysledek.
Huh?

Citace
Ano je to v podstate znovuimplementace jinak, ...
Asi tak.
Název: Re:Typový system versus unittesty
Přispěvatel: gll 28. 06. 2018, 20:09:05
Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

nebo automatika nahradí psaní programů a zůstane jen psaní testů (generování testových dat), ze kterých se budou učit neuronové sítě.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 28. 06. 2018, 20:57:16
Mimochodem, k představě, že všechny jednotkové testy bude umět vytvořit nějaký automat, je vhodné dodat, že až ten automat bude umět pochopit danou doménu a napsat testy, bude umět naprogramovat i ten výkonný kód.
Což je cíl, ke kterému směřujeme.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 28. 06. 2018, 21:02:21
Ale myslím, že je trošku nepochopení, k čemu typový systém je. Byl tady dotaz, že jak testovat v tom mém příkladu, že u:
Kód: [Vybrat]
Num op a b = op a b
nedošlo k prohození "a" a b".
Nutno zopakovat, že to, že došlo k prohození "a" a "b" se v Typu neopodchytí, stejně jako se nepodchytí toto prohození v Unittestech. Tudíž vzhledem k námětu tohoto vlákna je tento dotaz irelevantní.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 28. 06. 2018, 21:07:05
Ale kompilátor může vědět něco o symbolické matematice a nějaké další matematické axiomy ho můžeme naučit.
Ano, některé věci můžeme schovat do knihoven a knihovny klidně do kompilátoru nebo až do procesoru. Ty pak bereme za dané a podle míry jejich složitosti už je ani netestujeme. Programátoři dnes obvykle neprogramují, jak sečíst dvě 32bitová čísla, ale spoléhají na to, že to instrukce procesoru děla správně. Pořád je ale potřeba programátor na to, aby procesoru „vysvětlil“, že když má v jednom registru částku a v druhém registru DPH, cenu s DPH spočítá právě sečtením těch dvou registrů.
Nějak jsem nepochopil, co to má společného s tím, že když naučíme compiler pracovat se symbolickou matematikou, tak pro něj není problém odvodit, že standardní řešení kvadratické rovnice splňuje specifikace požadovanou po té funkci. Je to asi tak na stejné úrovni, jako že ten Liquid haskell je pro (některé) programy schopen dovodit, že výsledkem funkce je neprázdné pole.

Takže reakce na tebe:
Citace
Jenže kompilátor neví nic o kvadratických rovnicích, takže to z typů nijak neodvodí.
Kompilátor, který neví nic o kvadratických rovnicích, ale umí pracovat s matematickými výrazy (nepovažoval bych za vyloučené, že by tím směrem ty idrisy a spol. ohnout šly), je schopen dokázat, že daná funkce tu kvadratickou rovnici řeší.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 28. 06. 2018, 21:10:11
Ale myslím, že je trošku nepochopení, k čemu typový systém je. Byl tady dotaz, že jak testovat v tom mém příkladu, že u:
Kód: [Vybrat]
Num op a b = op a b
nedošlo k prohození "a" a b".
Nutno zopakovat, že to, že došlo k prohození "a" a "b" se v Typu neopodchytí, stejně jako se nepodchytí toto prohození v Unittestech. Tudíž vzhledem k námětu tohoto vlákna je tento dotaz irelevantní.

Jednotkové testy to právě odhalí velmi rychle už při odečítání.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 28. 06. 2018, 21:13:46
Ale myslím, že je trošku nepochopení, k čemu typový systém je. Byl tady dotaz, že jak testovat v tom mém příkladu, že u:
Kód: [Vybrat]
Num op a b = op a b
nedošlo k prohození "a" a b".
Nutno zopakovat, že to, že došlo k prohození "a" a "b" se v Typu neopodchytí, stejně jako se nepodchytí toto prohození v Unittestech. Tudíž vzhledem k námětu tohoto vlákna je tento dotaz irelevantní.

Jednotkové testy to právě odhalí velmi rychle už při odečítání.
Narážíš-li na komutativitu, tak tímto způsobem to zase odhalí i Typ.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 28. 06. 2018, 21:20:09
Ale myslím, že je trošku nepochopení, k čemu typový systém je. Byl tady dotaz, že jak testovat v tom mém příkladu, že u:
Kód: [Vybrat]
Num op a b = op a b
nedošlo k prohození "a" a b".
Nutno zopakovat, že to, že došlo k prohození "a" a "b" se v Typu neopodchytí, stejně jako se nepodchytí toto prohození v Unittestech. Tudíž vzhledem k námětu tohoto vlákna je tento dotaz irelevantní.
Jednotkové testy to právě odhalí velmi rychle už při odečítání.
Narážíš-li na komutativitu, tak tímto způsobem to zase odhalí i Typ.

Jak ten typ bude vypadat?
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 28. 06. 2018, 21:21:42
Myslim, ze u rady problemu je overeni spravnosti vypoctu trivialni kdezto vypocet samotny je slozity.
A kdyz zakomponuju overeni spravnosti do konstrukce navratoveho typu zarucim tim ze nepujde vytvorit navratovy typ obsahujici nespravny vysledek.
Jistě existuje řada takových problémů, ale podle mne se to netýká drtivé většiny problémů řešených dnešními programy. Navíc to ověření správnosti zabere nějaký výkon za běhu – lepší je (obvykle) ověřit správnost v době vytváření programu a za běhu se už jen spoléhat na to, že to prostě je správně.

Ten prispevek je prece o generativnim testovani u dynamicky typovaneho jazyka.
Za behu prece nebudu zapinat "typovou" instrumentaci.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 28. 06. 2018, 21:27:15
Narážíš-li na komutativitu, tak tímto způsobem to zase odhalí i Typ.

Jak ten typ bude vypadat?

Přiznávám se bez mučení, že zde mé znalosti končí. Ale mám rámcovou představu, jak by to mělo jít: pokud vím, že operátor sčítání je, a operátor odčítání není komutativní, tak IMHO není problém to kompilátoru říct. Jak konkrétně by se to zapsalo, to netuším. Mám toho ještě hodně k nastudování.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 28. 06. 2018, 21:28:27
Nějak jsem nepochopil, co to má společného s tím, že když naučíme compiler pracovat se symbolickou matematikou, tak pro něj není problém odvodit, že standardní řešení kvadratické rovnice splňuje specifikace požadovanou po té funkci. Je to asi tak na stejné úrovni, jako že ten Liquid haskell je pro (některé) programy schopen dovodit, že výsledkem funkce je neprázdné pole.
Jenom jsem upřesnil, že to, co popisujete, je jenom vytčení něčeho jednoduchého do knihovny nebo kompilátoru, které pak jako programátor používáte už bez testování. To ale není nic nového. Takhle už máte něco implementováno třeba v C kompilátoru nebo standardní knihovně – a ty implementace se zase testují.

Kompilátor, který neví nic o kvadratických rovnicích, ale umí pracovat s matematickými výrazy (nepovažoval bych za vyloučené, že by tím směrem ty idrisy a spol. ohnout šly), je schopen dokázat, že daná funkce tu kvadratickou rovnici řeší.
Ne, kompilátor není schopen dokázat, že daná funkce řeší kvadratickou rovnici. Kompilátor je schopen dokázat, že daná funkce řeší něco, co programátor prohlašuje za kvadratickou rovnici.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 28. 06. 2018, 21:35:57
Ten prispevek je prece o generativnim testovani u dynamicky typovaneho jazyka.
Za behu prece nebudu zapinat "typovou" instrumentaci.
Jak zakomponujete ověření správnosti výsledku do konstukce návratového typu, aby se to ověření nedělalo až za běhu, ale už při překladu?
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 28. 06. 2018, 21:40:11
...
A kdyz zakomponuju overeni spravnosti do konstrukce navratoveho typu zarucim tim ze nepujde vytvorit navratovy typ obsahujici nespravny vysledek.
Huh?

Citace
Ano je to v podstate znovuimplementace jinak, ...
Asi tak.

Nekde tady byla otazka na kvadratickou rovnici.
Zkusim tu myslenku v te citaci ukazat na tom.
Podotykam moji myslenku z te citace a ne kompletne problem reseny v tomto vlakne.
BoneFlute se z toho osype, protoze to neni ani zdaleka to o cem mluvil on.
A taky protoze to bude v jazyce velmi podobnem jave :-)
Vlastne jedinny rozdil proti jave je, ze umi presne floating point operace.

Kód: [Vybrat]
    final static RuntimeException up = new IllegalArgumentException("Does not compute");

    private static Result getRoots(double a, double b, double c){
        double detBody = b*b - 4*a*c;
        if(detBody < 0){
            throw new IllegalArgumentException("Fuck it! I don't have imaginary friends. " + detBody);
        }
        double det = Math.sqrt(detBody);
        double root1 = (-b + det)/2*a;
        double root2 = (-b - det)/2*a;
        return new Result(a,b,c,root1,root2);
    }

    static class Result {
        double root1; double root2;

        Result (double a, double b, double c, double root1, double root2){
            if(root1 + root2 != -(b/a) || root1*root2 != c/a) throw up;
            this.root1 = root1;
            this.root2 = root2;
        }
    }
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 28. 06. 2018, 21:43:54
Ten prispevek je prece o generativnim testovani u dynamicky typovaneho jazyka.
Za behu prece nebudu zapinat "typovou" instrumentaci.
Jak zakomponujete ověření správnosti výsledku do konstukce návratového typu, aby se to ověření nedělalo až za běhu, ale už při překladu?
To prece delat nechci. Ja chci napsat tu specifikaci a pak na to pustit ten generator testu.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 28. 06. 2018, 21:54:14
To prece delat nechci. Ja chci napsat tu specifikaci a pak na to pustit ten generator testu.
Pak tedy nebude ověření správnosti sioučástí typu, ale bude v tom testu.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 28. 06. 2018, 22:00:07
To prece delat nechci. Ja chci napsat tu specifikaci a pak na to pustit ten generator testu.
Pak tedy nebude ověření správnosti sioučástí typu, ale bude v tom testu.
Ne. Bude v te specifikaci podle ktere se testy vygeneruji.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 28. 06. 2018, 22:07:39
Narážíš-li na komutativitu, tak tímto způsobem to zase odhalí i Typ.

Jak ten typ bude vypadat?

Přiznávám se bez mučení, že zde mé znalosti končí. Ale mám rámcovou představu, jak by to mělo jít: pokud vím, že operátor sčítání je, a operátor odčítání není komutativní, tak IMHO není problém to kompilátoru říct. Jak konkrétně by se to zapsalo, to netuším. Mám toho ještě hodně k nastudování.
Mám to chápat tak, že netušíš, jak by se to dalo udělat? Ale trváš na tom, že to jde?
Nejde o to, jestli je nebo není komutativní. Jde o to, že ve chvíli kdy to odčítání nebude brát dva stejné typy, tak najednou nemáme grupu. To je kapku drsná cena.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 28. 06. 2018, 22:08:39
Nekde tady byla otazka na kvadratickou rovnici.
Zkusim tu myslenku v te citaci ukazat na tom.
Podotykam moji myslenku z te citace a ne kompletne problem reseny v tomto vlakne.
BoneFlute se z toho osype, protoze to neni ani zdaleka to o cem mluvil on.
A taky protoze to bude v jazyce velmi podobnem jave :-)
Vlastne jedinny rozdil proti jave je, ze umi presne floating point operace.

Kód: [Vybrat]
    final static RuntimeException up = new IllegalArgumentException("Does not compute");

    private static Result getRoots(double a, double b, double c){
        double detBody = b*b - 4*a*c;
        if(detBody < 0){
            throw new IllegalArgumentException("Fuck it! I don't have imaginary friends. " + detBody);
        }
        double det = Math.sqrt(detBody);
        double root1 = (-b + det)/2*a;
        double root2 = (-b - det)/2*a;
        return new Result(a,b,c,root1,root2);
    }

    static class Result {
        double root1; double root2;

        Result (double a, double b, double c, double root1, double root2){
            if(root1 + root2 != -(b/a) || root1*root2 != c/a) throw up;
            this.root1 = root1;
            this.root2 = root2;
        }
    }
Nejvíc bych tomu vytknoul, že si nedovedu představit, že by z takového zápisu byl stroj schopen "pochopit" tu kvadratickou rovnici. Takže nemůže (hypoteticky) "vyvinout" jinou, alternativní implementaci. Zdá se mi to jako algoritmus, který musím "otestovat".
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 28. 06. 2018, 22:11:07
Přiznávám se bez mučení, že zde mé znalosti končí. Ale mám rámcovou představu, jak by to mělo jít: pokud vím, že operátor sčítání je, a operátor odčítání není komutativní, tak IMHO není problém to kompilátoru říct. Jak konkrétně by se to zapsalo, to netuším. Mám toho ještě hodně k nastudování.
Mám to chápat tak, že netušíš, jak by se to dalo udělat?
Píšu, že mám rámcovou představu takže evidentně tuším.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 28. 06. 2018, 22:20:54
Nekde tady byla otazka na kvadratickou rovnici.
Zkusim tu myslenku v te citaci ukazat na tom.
Podotykam moji myslenku z te citace a ne kompletne problem reseny v tomto vlakne.
BoneFlute se z toho osype, protoze to neni ani zdaleka to o cem mluvil on.
A taky protoze to bude v jazyce velmi podobnem jave :-)
Vlastne jedinny rozdil proti jave je, ze umi presne floating point operace.

Kód: [Vybrat]
    final static RuntimeException up = new IllegalArgumentException("Does not compute");

    private static Result getRoots(double a, double b, double c){
        double detBody = b*b - 4*a*c;
        if(detBody < 0){
            throw new IllegalArgumentException("Fuck it! I don't have imaginary friends. " + detBody);
        }
        double det = Math.sqrt(detBody);
        double root1 = (-b + det)/2*a;
        double root2 = (-b - det)/2*a;
        return new Result(a,b,c,root1,root2);
    }

    static class Result {
        double root1; double root2;

        Result (double a, double b, double c, double root1, double root2){
            if(root1 + root2 != -(b/a) || root1*root2 != c/a) throw up;
            this.root1 = root1;
            this.root2 = root2;
        }
    }
Nejvíc bych tomu vytknoul, že si nedovedu představit, že by z takového zápisu byl stroj schopen "pochopit" tu kvadratickou rovnici. Takže nemůže (hypoteticky) "vyvinout" jinou, alternativní implementaci. Zdá se mi to jako algoritmus, který musím "otestovat".

Ano. Je to tak. Pokud bude funkce getRoots spatne tak se vyhodi RuntimeException coz je na produkci stejne nezadouci.
Melo to jen ilustrovat to overeni v ramci konstruktoru navratoveho typu tem co mluvi javistinou.
Ale kdyz si vygeneruju ten bambilion vstupu tak jen odchytim vyjimku a nemusim do testu na tvrdo psat hodnoty.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 28. 06. 2018, 22:32:36
Nějak jsem nepochopil, co to má společného s tím, že když naučíme compiler pracovat se symbolickou matematikou, tak pro něj není problém odvodit, že standardní řešení kvadratické rovnice splňuje specifikace požadovanou po té funkci. Je to asi tak na stejné úrovni, jako že ten Liquid haskell je pro (některé) programy schopen dovodit, že výsledkem funkce je neprázdné pole.
Jenom jsem upřesnil, že to, co popisujete, je jenom vytčení něčeho jednoduchého do knihovny nebo kompilátoru, které pak jako programátor používáte už bez testování. To ale není nic nového. Takhle už máte něco implementováno třeba v C kompilátoru nebo standardní knihovně – a ty implementace se zase testují.
???? Vůbec nerozumím. Celý tenhle thread je o tom, že mám k dispozici kompilátor, který "něco"(typy) umí, a zda s pomocí toho "něčeho" jsem schopen nějaký další program verifikovat tak, že unit testy potřebovat nebudu. Takže když píšu, že pokud bychom měli kompilátor schopný řešit matematické výrazy, tak to umí i verifikovat řešení kvadratické rovnice. Vůbec nechápu, co s tím má společného,

Citace
Kompilátor, který neví nic o kvadratických rovnicích, ale umí pracovat s matematickými výrazy (nepovažoval bych za vyloučené, že by tím směrem ty idrisy a spol. ohnout šly), je schopen dokázat, že daná funkce tu kvadratickou rovnici řeší.
Ne, kompilátor není schopen dokázat, že daná funkce řeší kvadratickou rovnici. Kompilátor je schopen dokázat, že daná funkce řeší něco, co programátor prohlašuje za kvadratickou rovnici.
Jako chcete říct, že když programátor kompilátoru nesdělí, aby kontroloval kvadratickou rovnici, tak to kompilátor neudělá...?
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 28. 06. 2018, 23:36:51
Kompilátor, který neví nic o kvadratických rovnicích, ale umí pracovat s matematickými výrazy (nepovažoval bych za vyloučené, že by tím směrem ty idrisy a spol. ohnout šly), je schopen dokázat, že daná funkce tu kvadratickou rovnici řeší.
Tohle umí třeba Coq.
Název: Re:Typový system versus unittesty
Přispěvatel: Gődel 28. 06. 2018, 23:40:35
chvíli kdy to odčítání nebude brát dva stejné typy, tak najednou nemáme grupu. To je kapku drsná cena.
To by byla sice drsná cena, akorát to ale není pravda.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 29. 06. 2018, 07:13:20
Ne. Bude v te specifikaci podle ktere se testy vygeneruji.
To už je jenom nepodstatný detail, čemu přesně říkáte „test“. Já říkám „testy“ celé části kódu, která stojí vedle hlavního kódu a je určená pro testování. Vy asi myslíte nějaký konkrétní testovací framework a „testem“ myslíte například jednu jeho funkci. Na principu to ale nic nemění.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 29. 06. 2018, 07:28:42
???? Vůbec nerozumím. Celý tenhle thread je o tom, že mám k dispozici kompilátor, který "něco"(typy) umí, a zda s pomocí toho "něčeho" jsem schopen nějaký další program verifikovat tak, že unit testy potřebovat nebudu. Takže když píšu, že pokud bychom měli kompilátor schopný řešit matematické výrazy, tak to umí i verifikovat řešení kvadratické rovnice. Vůbec nechápu, co s tím má společného,
Kompilátor, který umí řešit matematické výrazy, je jenom knihovna kódu, který programátor používá, ale netestuje. Nic jiného. Kompilátory běžných jazyků například umí zpracovávat základní algebraické výrazy, tj. umí transformovat sčítáí, odčítání, násobení a dělení na instrukce procesoru, umí správně zpracovat prioritu těch operátorů.

Jako chcete říct, že když programátor kompilátoru nesdělí, aby kontroloval kvadratickou rovnici, tak to kompilátor neudělá...?
Ne, chci říct, že kompilátor nezná pojem „kvadratická rovnice“. Ten pojem nijak neplyne z matematického aparátu, ten název tomu dali lidé, klidně by se to mohlo jmenovat třeba „malá rovnice“ nebo „druhá věta“. Jenže lidé to chtějí používat pod názvem „kvadratické rovnice“, takže musí nějaký člověk přijít a kompilátoru vysvětlit, že to, co má tyhle a tyhle vlastnisti, se nazývá „kvadratická rovnice“. A tenhle popis vlastností je to, kde se často dělají chyby a co je nutné testovat. Kvadratickou rovnici dá asi většina programátorů správně, ale dnešní programy obvykle řeší jiné problémy, než jsou přesně definované matematické funkce.

Pořád jde jen o to, že kompilátor dokáže vyřešit jenom to, co má formálně a bezrosporně zadané. Jenže takováhle zadání programátoři obvykle nemají, ostatně je to jejich práce převádět neformální a neúplné zadání popsané přirozeným jazykem do formální a přesné řeči počítačů. V tomhle převodu se dělají chyby a je snaha těm chybám předcházet, mimo jiné i testováním.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 29. 06. 2018, 07:43:33
Ne. Bude v te specifikaci podle ktere se testy vygeneruji.
To už je jenom nepodstatný detail, čemu přesně říkáte „test“. Já říkám „testy“ celé části kódu, která stojí vedle hlavního kódu a je určená pro testování. Vy asi myslíte nějaký konkrétní testovací framework a „testem“ myslíte například jednu jeho funkci. Na principu to ale nic nemění.

Testovaci framework je spis ten testcheck. Spec je podle me spis neco jako typovy system. Ale to uz jsem psal vyse. To jak to spolu hezky integruje je bonus.
Název: Re:Typový system versus unittesty
Přispěvatel: andy 29. 06. 2018, 09:37:10
???? Vůbec nerozumím. Celý tenhle thread je o tom, že mám k dispozici kompilátor, který "něco"(typy) umí, a zda s pomocí toho "něčeho" jsem schopen nějaký další program verifikovat tak, že unit testy potřebovat nebudu. Takže když píšu, že pokud bychom měli kompilátor schopný řešit matematické výrazy, tak to umí i verifikovat řešení kvadratické rovnice. Vůbec nechápu, co s tím má společného,
Kompilátor, který umí řešit matematické výrazy, je jenom knihovna kódu, který programátor používá, ale netestuje. Nic jiného. Kompilátory běžných jazyků například umí zpracovávat základní algebraické výrazy, tj. umí transformovat sčítáí, odčítání, násobení a dělení na instrukce procesoru, umí správně zpracovat prioritu těch operátorů.
No..vždyť jo. Bavíme se o tom, že tu máme kompilátor, který něco umí (typy) a BoneFlute se ptá, jestli tímto nástrojem (typy) lze nahradit unit testy při ověřování, že ten kód je správně. Což nemá nutně nic společného s tím, jestli to pak skutečně počítá to, co má (z důvodu chyby HW, kompileru apod.).

Citace
Jako chcete říct, že když programátor kompilátoru nesdělí, aby kontroloval kvadratickou rovnici, tak to kompilátor neudělá...?
Ne, chci říct, že kompilátor nezná pojem „kvadratická rovnice“. Ten pojem nijak neplyne z matematického aparátu, ten název tomu dali lidé, klidně by se to mohlo jmenovat třeba „malá rovnice“ nebo „druhá věta“. Jenže lidé to chtějí používat pod názvem „kvadratické rovnice“, takže musí nějaký člověk přijít a kompilátoru vysvětlit, že to, co má tyhle a tyhle vlastnisti, se nazývá „kvadratická rovnice“. A tenhle popis vlastností je to, kde se často dělají chyby a co je nutné testovat. Kvadratickou rovnici dá asi většina programátorů správně, ale dnešní programy obvykle řeší jiné problémy, než jsou přesně definované matematické funkce.
Kvadratická rovnice je definovaná jako ax^2 + bx +c = 0. Takže když se člověk zeptá "kompilátore, řeší tenhle vzoreček ax^2+bx+c=0, tak se ptá, jestli řeší kvadratickou rovnici jazykem, kterému kompilátor rozumí. Když tam dá jiný (neekvivalentní) vzoreček, tak se na to neptá.
Citace
Pořád jde jen o to, že kompilátor dokáže vyřešit jenom to, co má formálně a bezrosporně zadané. Jenže takováhle zadání programátoři obvykle nemají, ostatně je to jejich práce převádět neformální a neúplné zadání popsané přirozeným jazykem do formální a přesné řeči počítačů. V tomhle převodu se dělají chyby a je snaha těm chybám předcházet, mimo jiné i testováním.
No, takže fakt říkáte, že když kompilátor nepožádám, aby ověřil, že funkce řeší kvadratickou rovnici, tak to kompilátor neověří. Bingo.
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 29. 06. 2018, 09:57:50
Kvadratická rovnice je definovaná jako ax^2 + bx +c = 0. Takže když se člověk zeptá "kompilátore, řeší tenhle vzoreček ax^2+bx+c=0, tak se ptá, jestli řeší kvadratickou rovnici jazykem, kterému kompilátor rozumí. Když tam dá jiný (neekvivalentní) vzoreček, tak se na to neptá.
Citace
Pořád jde jen o to, že kompilátor dokáže vyřešit jenom to, co má formálně a bezrosporně zadané. Jenže takováhle zadání programátoři obvykle nemají, ostatně je to jejich práce převádět neformální a neúplné zadání popsané přirozeným jazykem do formální a přesné řeči počítačů. V tomhle převodu se dělají chyby a je snaha těm chybám předcházet, mimo jiné i testováním.
No, takže fakt říkáte, že když kompilátor nepožádám, aby ověřil, že funkce řeší kvadratickou rovnici, tak to kompilátor neověří. Bingo.

Spíš se ptáme, jak ten kompilátor požádám, aby ověřil, že funkce řeší kvadratickou rovnici. Typem nebo testem? Jak bude vypadat zápis?
Název: Re:Typový system versus unittesty
Přispěvatel: SB 29. 06. 2018, 10:04:45
Tohle je jen primitivní ukázka, jak se dají jednotkové testy vložit do jazyka, který s nimi původně vůbec nepočítal. Tahle testuje bezstavovou metodu. Není to test jednotkový, ale vývojářský. Podobný test, tentokrát jednotkový a stavový, se dá vložit do záhlaví třídy. Nevýhodou tohoto řešení však je, že testy bývají zhruba 2× delší než produkční kód, po kompilaci na produkci v něm stále překáží - jsou součástí binárky.

V Javě je to o něco lepší - tam se dá test vložit přes statickou vnitřní třídu, která však do produkce nejde. Ovšem už se to nepodobá zmíněným typům.

Ale k čemu je to dobré, když jednotkové testy můžete vytvořit v jakémkoliv jazyku bez potřeby doplnění syntaxe či preprocesoru, a to při větší vyjadřovací schopnosti, protože není třeba vytvářet nový (aťto deklarativní či imperativní) jazyk, ale stačí ten vlastní.
Ono asi to (nepovinné) vyčlenění testů do extra kódu bude mít něco do sebe...
Název: Re:Typový system versus unittesty
Přispěvatel: andy 29. 06. 2018, 11:08:58
Kvadratická rovnice je definovaná jako ax^2 + bx +c = 0. Takže když se člověk zeptá "kompilátore, řeší tenhle vzoreček ax^2+bx+c=0, tak se ptá, jestli řeší kvadratickou rovnici jazykem, kterému kompilátor rozumí. Když tam dá jiný (neekvivalentní) vzoreček, tak se na to neptá.
Citace
Pořád jde jen o to, že kompilátor dokáže vyřešit jenom to, co má formálně a bezrosporně zadané. Jenže takováhle zadání programátoři obvykle nemají, ostatně je to jejich práce převádět neformální a neúplné zadání popsané přirozeným jazykem do formální a přesné řeči počítačů. V tomhle převodu se dělají chyby a je snaha těm chybám předcházet, mimo jiné i testováním.
No, takže fakt říkáte, že když kompilátor nepožádám, aby ověřil, že funkce řeší kvadratickou rovnici, tak to kompilátor neověří. Bingo.

Spíš se ptáme, jak ten kompilátor požádám, aby ověřil, že funkce řeší kvadratickou rovnici. Typem nebo testem? Jak bude vypadat zápis?
No uměl bych si představit něco takového (hypoteticky):
Kód: [Vybrat]
getRoots :: a : Num -> b : Num -> c : Num -> [x] : [Num] | a * (x * x) + b * x + c = 0

Tohle je reálný příklad nějaké "vlastnosti" v liquid haskellu:
Kód: [Vybrat]
{-@ type NonEmpty a = {v:[a] | 0 < len v} @-}
{-@ group :: (Eq a) => [a] -> [ NonEmpty a ] @-}
group [] = []
group (x:xs) = (x:ys) : group zs
  where
    (ys,zs) = span (x ==) xs
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 29. 06. 2018, 11:42:12
Kvadratická rovnice je definovaná jako ax^2 + bx +c = 0. Takže když se člověk zeptá "kompilátore, řeší tenhle vzoreček ax^2+bx+c=0, tak se ptá, jestli řeší kvadratickou rovnici jazykem, kterému kompilátor rozumí. Když tam dá jiný (neekvivalentní) vzoreček, tak se na to neptá.
No, a když si programátor bude myslet, že kvadratická rovnice je definovaná jako ax^2 + bx = 0, tak se zeptá „kompilátore, řeší tenhle vzoreček ax^2+bx=0?“, tak si bude myslet, že se ptá, jestli řeší kvadratickou rovnici, jazykem, kterému kompilátor rozumí. Programátor pak odevzdá naprogramovanou funkci pro výpočet kvadratické rovnice, kompilátor nebude hlásit žádnou chybu – akorát ta funkce bude ve spoustě případů počítat špatně.

No, takže fakt říkáte, že když kompilátor nepožádám, aby ověřil, že funkce řeší kvadratickou rovnici, tak to kompilátor neověří. Bingo.
Ne, kompilátor nepožádáte, aby ověřil, že funkce řeší kvadratickou rovnici. Protože kompilátor neví, co je kvadratická rovnice. Kompilátor ví, co je ax^2 + bx = 0 nebo ax^2 + bx + c = 0. Že něco z toho je kvadratická rovnice mu musí říct programátor. A může mu to říct špatně.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 29. 06. 2018, 11:57:52
Kvadratická rovnice je definovaná jako ax^2 + bx +c = 0. Takže když se člověk zeptá "kompilátore, řeší tenhle vzoreček ax^2+bx+c=0, tak se ptá, jestli řeší kvadratickou rovnici jazykem, kterému kompilátor rozumí. Když tam dá jiný (neekvivalentní) vzoreček, tak se na to neptá.
No, a když si programátor bude myslet, že kvadratická rovnice je definovaná jako ax^2 + bx = 0, tak se zeptá „kompilátore, řeší tenhle vzoreček ax^2+bx=0?“, tak si bude myslet, že se ptá, jestli řeší kvadratickou rovnici, jazykem, kterému kompilátor rozumí. Programátor pak odevzdá naprogramovanou funkci pro výpočet kvadratické rovnice, kompilátor nebude hlásit žádnou chybu – akorát ta funkce bude ve spoustě případů počítat špatně.

Zatimco testem se to da vyresit lip, protoze ten co pise test prece vi, ze vysledek kvadraticke rovnice je (7, 10) nebo (12.333, -1).
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 29. 06. 2018, 11:58:38
No uměl bych si představit něco takového (hypoteticky):
Kód: [Vybrat]
getRoots :: a : Num -> b : Num -> c : Num -> [x] : [Num] | a * (x * x) + b * x + c = 0
Tak pro inty by to fungovat hypoteticky mohlo. Ale pro floaty si nedokážu představit ani to, jak bych takovýhle předpis ověřoval sám. Minimálně bych tam musel přidat hromadu dalších předpokladů o vstupech a o požadované toleranci.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 29. 06. 2018, 12:05:08
Zatimco testem se to da vyresit lip, protoze ten co pise test prece vi, ze vysledek kvadraticke rovnice je (7, 10) nebo (12.333, -1).
V testu se hlavně porovnávají dva diametrálně odlišné popisy. Tam je přece jenom menší šance, že by programátor udělal 2x podobnou chybu.
Název: Re:Typový system versus unittesty
Přispěvatel: SB 29. 06. 2018, 13:30:08
Tato diskuse už tu nějaký ten den jede. Čím déle nad tím přemýšlím...

Pozor, další myšlenka!:

Použiju-li pro kontrolu jednoduchý typový systém, bude implementačně snadný, ale zároveň vlivem jeho širokých kategorií bude schopen POUZE v rámci těchto kategorií (tj. s jejich přesností) určit správnost výpočtu, což může dostačovat pouze na to, abych zjistil, zda jsem někde neudělal KONCEPČNÍ chybu.

Dokonalý typový systém (bez rozdílu na jeho druh), tj. takový, který přesně rozpozná chybu, by tedy musel mít kategorie mnohem užší (třeba až do kategorie pro každou hodnotu; včetně jejich vztahů), tedy by NĚJAKÝM způsobem musel duplikovat/nahrazovat testovaný výpočet, jinak by nebyl schopen posoudit správnost. Zduplikuju-li onen výpočet (bez ohledu na to, zda bude onen typový systém zapsaný deklarativně či imperativně), pak

1. to má smysl pouze tehdy, bude-li se to lišit, takže půjde o test porovnáním různých implementací,
2. musím počítat s obdobnou složitostí jako u původního výpočtu,
3. vlivem oné složitosti bude pravděpodobněji v tomto typovém systému chyba,
4. každopádně dělám 2x to samé (i když jinak)

ALE!

Jednotkový test sice jde napsat jako znovuimplementace výpočtu, ale nikdy takhle nebyl zamýšlen, protože by trpěl stejnými nevýhodami jako dokonalý typový systém. Proto na to jde opačně - nesnaží se o úplnost, tj. pokrytí všech vstupních kombinací, ale jen těch, u kterých s vysokou pravděpodobností očekává chybu, nebo které reprezentují typické hodnoty, a to tím nejpřímočařejším způsobem, tj. ověření konkrétního výstupu pro konkrétní vstup, čímž dosahuje vysoké efektivity vzhledem k složitosti potřebného aparátu.

Hadžime!
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 29. 06. 2018, 14:16:28
Spíš se ptáme, jak ten kompilátor požádám, aby ověřil, že funkce řeší kvadratickou rovnici. Typem nebo testem? Jak bude vypadat zápis?
Ne, neptáme. Ptáme se kompilátoru typem. Tak zní zadání.

Ono asi to (nepovinné) vyčlenění testů do extra kódu bude mít něco do sebe...
A otázka zní, jaké to tedy má výhody? A dá se to napsat jinak? Typem?

Jednotkový test sice jde napsat jako znovuimplementace výpočtu, ale nikdy takhle nebyl zamýšlen, protože by trpěl stejnými nevýhodami jako dokonalý typový systém. Proto na to jde opačně - nesnaží se o úplnost, tj. pokrytí všech vstupních kombinací, ale jen těch, u kterých s vysokou pravděpodobností očekává chybu, nebo které reprezentují typické hodnoty, a to tím nejpřímočařejším způsobem, tj. ověření konkrétního výstupu pro konkrétní vstup, čímž dosahuje vysoké efektivity vzhledem k složitosti potřebného aparátu.
V testu se hlavně porovnávají dva diametrálně odlišné popisy. Tam je přece jenom menší šance, že by programátor udělal 2x podobnou chybu.
Ano, křížová kontrola, to jsem unittestům přiznal jako bod :-) To si moc nedovedu představit jak by se dělalo jinak. Ale třeba časem :-)


Ale k čemu je to dobré, když jednotkové testy můžete vytvořit v jakémkoliv jazyku bez potřeby doplnění syntaxe či preprocesoru, a to při větší vyjadřovací schopnosti, protože není třeba vytvářet nový (aťto deklarativní či imperativní) jazyk, ale stačí ten vlastní.

Viděl jsem spoustu testů. A nedomnívám se, že by to byl nějaký zázrak. Je to ukecané, nudlovité, neexpresivní, nedostatečné.
Název: Re:Typový system versus unittesty
Přispěvatel: gll 29. 06. 2018, 14:39:09
A otázka zní, jaké to tedy má výhody? A dá se to napsat jinak? Typem?

funguje to se současnými technologiemi, nejen s nějakým sci-fi překladačem.
Název: Re:Typový system versus unittesty
Přispěvatel: v 29. 06. 2018, 14:50:28
není jenom java a coq, výběr je větší a metod k potlačení chyb taky můžeme použíc víc než jednu (QuickCheck třeba ještě)
Název: Re:Typový system versus unittesty
Přispěvatel: SB 29. 06. 2018, 15:02:08
není jenom java a coq, výběr je větší a metod k potlačení chyb taky můžeme použíc víc než jednu (QuickCheck třeba ještě)

O žádné konkrétní implementaci jsem nemluvil. Všechno jsou to jen variace na dané téma.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 29. 06. 2018, 15:56:09
Ano, křížová kontrola, to jsem unittestům přiznal jako bod :-) To si moc nedovedu představit jak by se dělalo jinak. Ale třeba časem :-)
Možná tak v době, kdy si účetní pokecá s AI, přidá k tomu sbírku zákonů a ven vypadne hotový soft.

Seznam ukázkových příkladů je blízko neformálnímu popisu problému. Dokonce ho může dodat i klient s minimální představou o programování. Jakýkoliv typový systém je už o úroveň abstrakce dál. Takže i když už programátoři nebudou hrnout kód, ale jenom formální specifikace, tak budou testy užitečné.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 29. 06. 2018, 16:11:09
Seznam ukázkových příkladů je blízko neformálnímu popisu problému. ... Jakýkoliv typový systém je už o úroveň abstrakce dál. Takže i když už programátoři nebudou hrnout kód, ale jenom formální specifikace, tak budou testy užitečné.
Přijde mi zajímavější, aby ukázkové příklady generoval nástroj na základě specifikace. Včetně okamžiku vývoje.

Dokonce ho může dodat i klient s minimální představou o programování.
No já nevim. To už je otázka spíše psychologická. Veškeré mé zkušenosti s takto neznalími klienty bylo, že mi to museli vysvětlit ústně, protože sami jinak nehli prstem.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 29. 06. 2018, 16:12:31
A otázka zní, jaké to tedy má výhody? A dá se to napsat jinak? Typem?

funguje to se současnými technologiemi, nejen s nějakým sci-fi překladačem.
Dobře, máš pravdu. Ale vzhledem k námětu tohoto vlákna nás zajímá právě ten sci-fi překladač.
Takže, dá se to napsat jinak? Typem?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 29. 06. 2018, 16:28:58
Přijde mi zajímavější, aby ukázkové příklady generoval nástroj na základě specifikace.
Což ovšem význam ukázkových příkladů staví na hlavu. Ukázkové příklady mají ten význam, že je velmi jednoduché je vytvořit a pochopit, řádově jednodušší, než vytvořit správnou specifikaci. Proto je u nich také mnohem větší pravděpodobnost, že budou správně. Když se budou tvořit z té složité specifikace, budou pro její kontrolu k ničemu. Kdybyste chtěl vygenerovat ze specifikace hezké ukázkové příklady, které zkontroluje někdo neznalý programování, bude to ještě podstatně složitější (jak automaticky poznáte ty „hezké“ příklady?), a i pokud by se vám to podařilo, bude existovat velké nebezpečí, že programátor sestaví specifikaci tak, aby mu vycházely ty hezké příklady, a zbytek bude špatně. To je přece známý problém testů (a velké problémy s tím má třeba školství nebo věda), že když něco testujete stále stejnými testy, má to tendency degenerovat a uzpůsobit se tak, aby to perfektně procházelo těmi testy – a nic jiného rozumného to nedělá.
Název: Re:Typový system versus unittesty
Přispěvatel: JSH 29. 06. 2018, 17:01:35
Přijde mi zajímavější, aby ukázkové příklady generoval nástroj na základě specifikace. Včetně okamžiku vývoje.
Filip Jirsák to v
Což ovšem význam...
celkem vystihl.

Pokud bych psal např. daňový soft, tak mi dává smysl sednout si s účetní a spočítat si pár ukázkových lidí. Zároveň si tak utřídím vlastní představu o problému. Pak ty ukázky překlopím na testy. Jestli nebudou testy sedět, tak budu kontrolovat i kód a když nic nenajdu tak pak případně ručně přepočítáme pro kontrolu i ty ukázky.

Přijde mi to spolehlivější než kdybychom ručně kontrolovali něco nagenerovaného. Hledání chyb v cizích výsledcích mi nikdy moc nešlo. A taky to svádí k tomu, jenom to prolítnout. Pokud to nebude moc velký úlet, tak ta chyba může projít.
Název: Re:Typový system versus unittesty
Přispěvatel: gll 29. 06. 2018, 17:06:16
Dobře, máš pravdu. Ale vzhledem k námětu tohoto vlákna nás zajímá právě ten sci-fi překladač.
Takže, dá se to napsat jinak? Typem?

jestli tomu rozumím správně, vy překladači zadáte dva vzorce a on ověří, že jsou ekvivalentní. Jak to souvisí s typem?
Název: Re:Typový system versus unittesty
Přispěvatel: gll 29. 06. 2018, 17:52:37
v unittestu ty vzorce mohu otestoval nějak tak

Kód: [Vybrat]
from sympy import solve, symbols, var, sqrt, simplify

a, b, c = symbols('a b c')
x = var('x')

def roots():
    return [simplify((-b + sqrt(-4*a*c + b**2))/(2*a)),
            simplify(-(b + sqrt(-4*a*c + b**2))/(2*a))]

def test():
    assert roots() == solve(a*x**2 + b*x + c, x)

chci vidět, jak to stejné otestuješ typovým systémem
Název: Re:Typový system versus unittesty
Přispěvatel: andy 29. 06. 2018, 19:07:26
No uměl bych si představit něco takového (hypoteticky):
Kód: [Vybrat]
getRoots :: a : Num -> b : Num -> c : Num -> [x] : [Num] | a * (x * x) + b * x + c = 0
Tak pro inty by to fungovat hypoteticky mohlo. Ale pro floaty si nedokážu představit ani to, jak bych takovýhle předpis ověřoval sám. Minimálně bych tam musel přidat hromadu dalších předpokladů o vstupech a o požadované toleranci.
Právě že by to fungovalo symbolicky pro reálná čísla. Zda by to pak při konkrétní implementaci třeba pro "Num=Double" bylo numericky stabilní je druhá věc.

Citace
Dokonalý typový systém (bez rozdílu na jeho druh), tj. takový, který přesně rozpozná chybu, by tedy musel mít kategorie mnohem užší (třeba až do kategorie pro každou hodnotu; včetně jejich vztahů), tedy by NĚJAKÝM způsobem musel duplikovat/nahrazovat testovaný výpočet, jinak by nebyl schopen posoudit správnost.
Třeba ta kvadratická rovnice je zrovna ukázka, že tomu tak vůbec být nemusí.

Na druhou stranu ta ukázka:
Kód: [Vybrat]
Op op a b -> op a bTak tady je specifikace a konkrétní řešení identické.

Dneska je tendence když mám zadání alespoň trochu formálně popsané zadání to řešit tak, že si napíšu DSL, a v tom DSL pak popíšu tu specifikaci. A samozřejmě tam většina věcí bude vypadat jako to "op a b" - to prostě "je" ta specifikace. A tam se pak dostáváme k otázce, jak otestovat, že ta specifikace je správně - a tam nějaké testy (nevím, jestli zrovna "unit" testy) jsou asi jediné možné řešení.
Název: Re:Typový system versus unittesty
Přispěvatel: v 29. 06. 2018, 20:05:12
něco ostřejšího https://ncatlab.org/nlab/show/completion+monad ?
Název: Re:Typový system versus unittesty
Přispěvatel: ffd 29. 06. 2018, 21:35:32
v unittestu ty vzorce mohu otestoval nějak tak

Kód: [Vybrat]
from sympy import solve, symbols, var, sqrt, simplify

a, b, c = symbols('a b c')
x = var('x')

def roots():
    return [simplify((-b + sqrt(-4*a*c + b**2))/(2*a)),
            simplify(-(b + sqrt(-4*a*c + b**2))/(2*a))]

def test():
    assert roots() == solve(a*x**2 + b*x + c, x)

chci vidět, jak to stejné otestuješ typovým systémem

Ja jsem prave myslel, ze unit test pro kvadratickou rovnici bude obsahovat
asserty pro a,b,c <0, = 0, >0, cili nejakych 8 assertu, ktere si vytvorim manualne...
Název: Re:Typový system versus unittesty
Přispěvatel: Kit 29. 06. 2018, 21:41:39
Spíš se ptáme, jak ten kompilátor požádám, aby ověřil, že funkce řeší kvadratickou rovnici. Typem nebo testem? Jak bude vypadat zápis?
Ne, neptáme. Ptáme se kompilátoru typem. Tak zní zadání.

Ukázka by nebyla? Chci se tedy zeptat kompilátoru typem, zda daná funkce řeší kvadratickou rovnici. Jak to bude vypadat?
Název: Re:Typový system versus unittesty
Přispěvatel: Typolog 05. 07. 2018, 13:42:10
Kvadratická rovnice je definovaná jako ax^2 + bx +c = 0. Takže když se člověk zeptá "kompilátore, řeší tenhle vzoreček ax^2+bx+c=0, tak se ptá, jestli řeší kvadratickou rovnici jazykem, kterému kompilátor rozumí. Když tam dá jiný (neekvivalentní) vzoreček, tak se na to neptá.
Citace
Pořád jde jen o to, že kompilátor dokáže vyřešit jenom to, co má formálně a bezrosporně zadané. Jenže takováhle zadání programátoři obvykle nemají, ostatně je to jejich práce převádět neformální a neúplné zadání popsané přirozeným jazykem do formální a přesné řeči počítačů. V tomhle převodu se dělají chyby a je snaha těm chybám předcházet, mimo jiné i testováním.
No, takže fakt říkáte, že když kompilátor nepožádám, aby ověřil, že funkce řeší kvadratickou rovnici, tak to kompilátor neověří. Bingo.
Spíš se ptáme, jak ten kompilátor požádám, aby ověřil, že funkce řeší kvadratickou rovnici. Typem nebo testem? Jak bude vypadat zápis?
Takový příklad je uveden v článku “If monads are the answer, what’s the question?” (který je jinak o něčem úplně jiném). Tamní typový systém umí líně vyhodnocovat a má něco jako “statické jednotkové testy” - to je tak trochu protimluv, překladač v podstatě umožňuje specifikovat podmínky integrity, které se symbolicky ověřují během překladu. Vychází to z nějaké disertace, jejíž název si už nevybavuji (je stará, 80.-90. léta, což naznačuje, že jsme se za pár desetiletí moc daleko neposunuli).
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 17. 08. 2018, 15:24:52
Nedavno jsem zmenil projekt a po trech mesicich na tom novem mi doslo k cemu vlastne jsou unit testy a vzpomel sem si na tohle vlakno. Rikal jsem si, ze ho doplnim.
Tak pro me je hlavni duvod proc pisu unit testy:
"Ochrana meho kodu pred neuvazenymi zmenami ostatnich"

Kdekdo mi hrabe do "mych" funkci a ohyba si je pro svuj use case a je mu jedno, ze tim rozbije ten muj.
Kdyz nenapisu testy tak mi pristanou defekty a ja budu slozite hledat kde,kdo a co rozbil.

Kdyz testy mam tak "ohybac" musi zmenit i ty testy aby prosel build a tim padem se snad lepe zamysli.
A kdyz se nezamysli (jako treba ze cele vnitrky testu zakomentuje) tak mam aspon dukazy jakej to je lempl...

Myslim, ze tohle typovy system nedokaze podchytit.
Název: Re:Typový system versus unittesty
Přispěvatel: Bacsa 17. 08. 2018, 15:29:46
Nedavno jsem zmenil projekt a po trech mesicich na tom novem mi doslo k cemu vlastne jsou unit testy a vzpomel sem si na tohle vlakno. Rikal jsem si, ze ho doplnim.
Tak pro me je hlavni duvod proc pisu unit testy:
"Ochrana meho kodu pred neuvazenymi zmenami ostatnich"

Kdekdo mi hrabe do "mych" funkci a ohyba si je pro svuj use case a je mu jedno, ze tim rozbije ten muj.
Kdyz nenapisu testy tak mi pristanou defekty a ja budu slozite hledat kde,kdo a co rozbil.

Kdyz testy mam tak "ohybac" musi zmenit i ty testy aby prosel build a tim padem se snad lepe zamysli.
A kdyz se nezamysli (jako treba ze cele vnitrky testu zakomentuje) tak mam aspon dukazy jakej to je lempl...

Myslim, ze tohle typovy system nedokaze podchytit.
Toto je velice zajímavý postřeh. +1
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 17. 08. 2018, 16:13:09
...

Myslim, ze tohle typovy system nedokaze podchytit.

Je to myslím moc pěkný usecase, ač už jsem na něco podobného tuším reagoval.

Zdá se, že mnoho přispěvovatelů si tu vyláme zuby na rozdílu mezi "tohle typový systém nedokáže podchytit protože princip" versus "nesetkal jsem se s typovým systémem, který by to dokázal podchytit".

Například jazyk Elm by toto mohl dát. Jakmile někdo vezme funkci, a ohne si ji, tak se změní major verze té funkce a už nepůjde napasovat, a celé to nepůjde zkompilovat. Což je IMHO právě ta ochrana (ochrana rozhodně užitečná), o které mluvíš.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 17. 08. 2018, 16:16:10
Dobře, máš pravdu. Ale vzhledem k námětu tohoto vlákna nás zajímá právě ten sci-fi překladač.
Takže, dá se to napsat jinak? Typem?

jestli tomu rozumím správně, vy překladači zadáte dva vzorce a on ověří, že jsou ekvivalentní.
Ano. Taky.

Jak to souvisí s typem?
Proč se ptáš?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 17. 08. 2018, 16:32:30
Například jazyk Elm by toto mohl dát. Jakmile někdo vezme funkci, a ohne si ji, tak se změní major verze té funkce a už nepůjde napasovat, a celé to nepůjde zkompilovat. Což je IMHO právě ta ochrana (ochrana rozhodně užitečná), o které mluvíš.
Při popisu toho, proč se používají testy, jste popsal jenom jednu možnou změnu. Druhá možná změna je, že někdo vezme funkci, zachová její API na kterém závisí ostatní a které testují testy, ale upraví její implementaci (např. funkci optimalizuje). Užitečnost ochrany testy spočívá i v tom, že testy dále úspěšně procházejí, přestože se implementace změnila. Testy nejsou určené k tomu, aby nacházely změny, ale aby nacházely takové změny, které něco rozbijí.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 17. 08. 2018, 17:01:50
Například jazyk Elm by toto mohl dát. Jakmile někdo vezme funkci, a ohne si ji, tak se změní major verze té funkce a už nepůjde napasovat, a celé to nepůjde zkompilovat. Což je IMHO právě ta ochrana (ochrana rozhodně užitečná), o které mluvíš.
Při popisu toho, proč se používají testy, jste popsal jenom jednu možnou změnu. Druhá možná změna je, že někdo vezme funkci, zachová její API na kterém závisí ostatní a které testují testy, ale upraví její implementaci (např. funkci optimalizuje). Užitečnost ochrany testy spočívá i v tom, že testy dále úspěšně procházejí, přestože se implementace změnila. Testy nejsou určené k tomu, aby nacházely změny, ale aby nacházely takové změny, které něco rozbijí.

Ale ne. On ma BoneFlute zase pravdu. Uz mi to doslo.
Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.
Název: Re:Typový system versus unittesty
Přispěvatel: Bacsa 17. 08. 2018, 17:05:00
Například jazyk Elm by toto mohl dát. Jakmile někdo vezme funkci, a ohne si ji, tak se změní major verze té funkce a už nepůjde napasovat, a celé to nepůjde zkompilovat. Což je IMHO právě ta ochrana (ochrana rozhodně užitečná), o které mluvíš.
Při popisu toho, proč se používají testy, jste popsal jenom jednu možnou změnu. Druhá možná změna je, že někdo vezme funkci, zachová její API na kterém závisí ostatní a které testují testy, ale upraví její implementaci (např. funkci optimalizuje). Užitečnost ochrany testy spočívá i v tom, že testy dále úspěšně procházejí, přestože se implementace změnila. Testy nejsou určené k tomu, aby nacházely změny, ale aby nacházely takové změny, které něco rozbijí.
Ale ne. On ma BoneFlute zase pravdu. Uz mi to doslo.
Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.
Něco podobného je popsáno v Seven more languages in seven weeks.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 17. 08. 2018, 17:32:10
Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.

Ano, přesně tak.

Mimochodem docela inspirativní, a dokonce z produkce je jazyk Rust a jeho borrows. Což je zase něco jiného než s čím se obvykle setkáváme. Je zajímavé, kolik chyb je schopen při kompilaci najít.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 17. 08. 2018, 18:32:01
Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.
Nechápu, proč to píšete jako reakci na můj komentář, když jste jen znovu napsal to, na co jsem já reagoval. Já jsem psal o opačném případu, kdy používané API funkce zůstane stejné, ale implementace se změní (což nemusí nutně znamenat, že nová implementace bude ekvivalentní té původní – nesmí se změnit API, ale vlastnosti, na kterých nic nezávisí, se změnit mohou).
Název: Re:Typový system versus unittesty
Přispěvatel: optimizer 17. 08. 2018, 19:06:56
zatím se tu neobjevil jediný kus fungujícího kódu.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 17. 08. 2018, 19:32:05
Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.
Nechápu, proč to píšete jako reakci na můj komentář, když jste jen znovu napsal to, na co jsem já reagoval. Já jsem psal o opačném případu, kdy používané API funkce zůstane stejné, ale implementace se změní (což nemusí nutně znamenat, že nová implementace bude ekvivalentní té původní – nesmí se změnit API, ale vlastnosti, na kterých nic nezávisí, se změnit mohou).

Mozna proto, ze ten typovy system muze zajistit, ze (breaking) zmena  implementace nepujde udelat beze zmeny API?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 17. 08. 2018, 19:54:47
Mozna proto, ze ten typovy system muze zajistit, ze (breaking) zmena  implementace nepujde udelat beze zmeny API?
Zkusím to ještě potřetí: aby to mohlo nahradit jednotkové testy, musel by ten typový systém zároveň zajistit, že změna implementace, která nezmění používané API, nic nerozbije – tedy že např. nedojde k nekompatibilní změně typů. Pro jistotu ještě explicitně uvedu, že „nemění používané API“ neznamená, že se nijak nezmění chování té funkce navenek. Např. pokud se ta funkce používala jen pro vstupní hodnoty 1–10, když se změní výsledek, který vrací pro 11, není to změna používaného API.
Název: Re:Typový system versus unittesty
Přispěvatel: Honza 17. 08. 2018, 19:56:04
Je to jenom jiný úhel pohledu pořád na totéž:

Formální správnost programu vs. zamýšlená funkčnost.

...zatímco nepřátelé jednotkových testů přitom marně čekají na akademický důkaz, že obojí typový systém NEzvládne, aby se mohli při tom čekání chlácholit tím, že do té doby mají pravdu...

Takhle tu budete v tom případě asi debatovat ještě hodně dlouho...
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 17. 08. 2018, 20:33:04
Pro jistotu ještě explicitně uvedu, že „nemění používané API“ neznamená, že se nijak nezmění chování té funkce navenek. Např. pokud se ta funkce používala jen pro vstupní hodnoty 1–10, když se změní výsledek, který vrací pro 11, není to změna používaného API.
Pokud je vstupni typ funkce integer 1 - 10 tak aby zacala vracet i pro 11 budu muset zmenit typ vstupu. Takze API.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 17. 08. 2018, 21:06:35
Pokud je vstupni typ funkce integer 1 - 10
Není. Opravdu je nutné to explicitně psát, není to zřejmé z předchozího komentáře?
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 17. 08. 2018, 21:10:25
zatím se tu neobjevil jediný kus fungujícího kódu.
Bez ohledu na to, zda máte pravdu, toto nebylo požadavkem.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 17. 08. 2018, 21:16:15
Je to jenom jiný úhel pohledu pořád na totéž:

Formální správnost programu vs. zamýšlená funkčnost.

...zatímco nepřátelé jednotkových testů přitom marně čekají na akademický důkaz, že obojí typový systém NEzvládne, aby se mohli při tom čekání chlácholit tím, že do té doby mají pravdu...

Takhle tu budete v tom případě asi debatovat ještě hodně dlouho...

Já si pamatuju na kdysi, kdysi nějaký vlákno fóra, kde se rozebíralo statické typování, haskell, python. Bylo to dlouhý, a hodně inspirativní. Třeba jen od tohoto vlákna očekáváš něco, co není jeho cílem. Někteří z nás tu třeba nechtějí najít univerzální rozhodnutí, nebo si nepotřebují nic dokazovat. Jen se pokoušíme zjistit, co kdo k tomu ví zajímavého. Můžeš k tomu pomoct. (Ale taky nemusíš :-) )
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 17. 08. 2018, 21:22:35
Pro jistotu ještě explicitně uvedu, že „nemění používané API“ neznamená, že se nijak nezmění chování té funkce navenek. Např. pokud se ta funkce používala jen pro vstupní hodnoty 1–10, když se změní výsledek, který vrací pro 11, není to změna používaného API.
Pokud je vstupni typ funkce integer 1 - 10 tak aby zacala vracet i pro 11 budu muset zmenit typ vstupu. Takze API.

Jen doplním, že ten Elm si zjistí, zda došlo k nekompatabilní změně algoritmu, a tuto změnu propíše do API jako tu major verzi. Takže ten semver je součástí toho typu. Vzhledem k tomu, že Elm je téměř pure, tak to nepřekvapí. Bylo by zajímavé zjistit, kde má hranice (já jsem se tomu žel nevěnoval tolik, kolik bych chtěl - zatím).
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 17. 08. 2018, 21:28:16
Jen doplním, že ten Elm si zjistí, zda došlo k nekompatabilní změně algoritmu, a tuto změnu propíše do API jako tu major verzi.
Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 17. 08. 2018, 21:35:50
Jen doplním, že ten Elm si zjistí, zda došlo k nekompatabilní změně algoritmu, a tuto změnu propíše do API jako tu major verzi.
Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.
A to prave nemusi byt pravda.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 17. 08. 2018, 21:42:47
Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.
A to prave nemusi byt pravda.
Asi jste můj komentář špatně přečetl. Psal jsem, že existují takové nekompatibilní změny implementace, které nemění API. Tvrzení o existenci se vyvrací tvrzením, že neexistuje žádný takový případ. Tedy žádné „nemusí“, ale „nemůže existovat“.

Nezapomínejte na to, že definice API nemusí být jenom to, co je v kódu, ale mohou to být další podmínky nebo omezení popsané třeba v dokumentaci. A tu si žádný kompilátor nepřečte.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 17. 08. 2018, 21:59:09
Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.
A to prave nemusi byt pravda.
Asi jste můj komentář špatně přečetl. Psal jsem, že existují takové nekompatibilní změny implementace, které nemění API. Tvrzení o existenci se vyvrací tvrzením, že neexistuje žádný takový případ. Tedy žádné „nemusí“, ale „nemůže existovat“.

Nezapomínejte na to, že definice API nemusí být jenom to, co je v kódu, ale mohou to být další podmínky nebo omezení popsané třeba v dokumentaci. A tu si žádný kompilátor nepřečte.

Ja nechci vyvracet to tvrzeni, ze takove zmeny existuji. To je samozrejme, jelikoz existuji jazyky se slabym typovym systemem.
Ja se snazim jenom rict, ze kdyz budu mit silny typovy system tam muzu napsat funkci tak, ze kazda nekompatibilni zmena nutne zmeni API.



Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 08. 2018, 09:18:24
Ja nechci vyvracet to tvrzeni, ze takove zmeny existuji. To je samozrejme, jelikoz existuji jazyky se slabym typovym systemem.
Ja se snazim jenom rict, ze kdyz budu mit silny typovy system tam muzu napsat funkci tak, ze kazda nekompatibilni zmena nutne zmeni API.
Já jsem ale nepsal o žádných jazycích se slabým typovým systémem. Psal jsem o tom bájném BoneFluteovu jazyku s nejsilnějším možným typovým systémem.

Rozumím tomu, co se snažíte říct. A už po několikáté se vám snažím vysvětlit, že ne každá nekompatibilní změna implementace znamená i nekompatibilní změnu API. Příklad takové funkce už jsem uváděl. Pokud taková změna, která nezpůsobuje nekompatibilní změnu API, vyvolá konflikt (chybu překladu v extra silném typovém systému, selhání testu u slabších typových systémů), je to špatně. Protože pak bude muset programátor neustále řešit tyhle neexistující chyby, bude to dělat automaticky a udělá to i tehdy, když změna vyvolá nekompatibilní změnu API. Mimochodem, to, jestli daná změna je nebo není nekompatibilní změnou API, je v mnoha případech věcí názoru. Takže to opravdu žádný typový systém nevyřeší, protože dva typy nemohou být navzájem kompatibilní u jednoho programátora, a nekompatibilní u jiného, který na to má jiný názor.
Název: Re:Typový system versus unittesty
Přispěvatel: Vlado 18. 08. 2018, 13:16:21
On existuje aj zlý typový systém? A vtedy akože treba unit testy? Alebo ako to myslíš? Môžeš byť konkrétnejší? Lebo ja som sa ešte so zlým typovým systémom nestretol a tak ani nechápem, čo si mám pod tým predstaviť.
Název: Re:Typový system versus unittesty
Přispěvatel: Vlado 18. 08. 2018, 13:32:45
Prieskum, porovnanie či má statický typový systém navrch oproti dynamicky typovaným jazykom nepreukázal pozitívny vplyv na hustotu výskytu chýb. Z čoho jasne vyplýva, že je jedno aký druh jazyka použiješ, testy by si mal písať tak či onak. A ak tým svojim zistením máš na mysli klasický flame TS vs JS, tak realita je taká, že si môžeš dovoliť vynechať TS, ale nie testy. Vynechať testy na úkor TS je naprosto neodporúčané práve z dôvodu, že použiť čisto TS ti dá akurát tak falošný pocit bezpečia. Ergo, TDD je reálny "problem solver", nie TS.
Název: Re:Typový system versus unittesty
Přispěvatel: Bacsa 18. 08. 2018, 14:13:18
Prieskum, porovnanie či má statický typový systém navrch oproti dynamicky typovaným jazykom nepreukázal pozitívny vplyv na hustotu výskytu chýb.
Jaký průzkum? Někde na salaši v Hornouhrách?
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 18. 08. 2018, 16:52:15
A už po několikáté se vám snažím vysvětlit, že ne každá nekompatibilní změna implementace znamená i nekompatibilní změnu API.
A ja uz se po nekolikate snazim rict, ze to nemusi byt pravda. Kdyz budu mit vhodny typovy system a budu chtit, tak muzu zaridit aby kazda nekompatibilni zmena implementace nutne znamenala zmenu API.

Pokud taková změna, která nezpůsobuje nekompatibilní změnu API, vyvolá konflikt (chybu překladu v extra silném typovém systému, selhání testu u slabších typových systémů), je to špatně. Protože pak bude muset programátor neustále řešit tyhle neexistující chyby, bude to dělat automaticky a udělá to i tehdy, když změna vyvolá nekompatibilní změnu API.
Chyba kompilace mi neprijde jako neexistujici chyba.

Mimochodem, to, jestli daná změna je nebo není nekompatibilní změnou API, je v mnoha případech věcí názoru. Takže to opravdu žádný typový systém nevyřeší, protože dva typy nemohou být navzájem kompatibilní u jednoho programátora, a nekompatibilní u jiného, který na to má jiný názor.
To rekne kompilator co je kompatibilni a co je nekompatibilni. To nemuze byt vec nazoru.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 08. 2018, 17:15:09
A ja uz se po nekolikate snazim rict, ze to nemusi byt pravda. Kdyz budu mit vhodny typovy system a budu chtit, tak muzu zaridit aby kazda nekompatibilni zmena implementace nutne znamenala zmenu API.
Ano, vy jste už poněkolikáté zaměnil kompatibilitu API a kompatibilitu implementace. Já stále píšu o kompatibilitě API a vy na to pokaždé reagujete kompatibilitou implementace. Ne každá změna implementace znamená změnu API.

To rekne kompilator co je kompatibilni a co je nekompatibilni. To nemuze byt vec nazoru.
Možná to nemůže být věc názoru, ale je to tak. Je změnou API třeba to, jak je funkce rychlá, jak dlouho trvá, než se provede? Třeba u webových stránek se v JavaScriptu hlavně dříve spousta věcí, která měla být asynchronní, řešila voláním setTimeout – daný kód se odložil a zavolal třeba za 100 ms. Nebo i dneska to často lidé používají v init skriptech – „dej tam pauzu minutu, za tu dobu ta závislost určitě naběhne“. Spousta lidí k tomu má přístup „teď mi to funguje, tak je to v pořádku“. No a někde místo explicitní pauzy funguje kód, který se provádí delší dobu. A teď si představte, že někdo takový kód optimalizuje a zrychlí. Ten kód, který závisel na tom, že to trvá určitou dobu, se rozbije.

Je to zrychlení nekompatibilní změna API? I když ta doba trvání nikde nebyla zdokumentovaná, nebyl to účel té funkce a jenom to tak náhodou vyšlo. Dá se na takový případ napsat jednotkový test? Mohl by to typový systém řešit jinak, než že by každá změna implementace znamenala nekompatibilní změnu, a tím pádem by veškerá typovost šla k šípku, protože by nic nezáviselo na typech ale na konkrétních implementacích?
Název: Re:Typový system versus unittesty
Přispěvatel: Vlado 18. 08. 2018, 19:50:32
Pre lamy ako Bacsa:

The broken promise of static typing:
https://labs.ig.com/static-typing-promise

The Shocking Secret About Static Types:
https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3

You Might Not Need TypeScript (or Static Types):
https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 08. 2018, 20:57:56
A ja uz se po nekolikate snazim rict, ze to nemusi byt pravda. Kdyz budu mit vhodny typovy system a budu chtit, tak muzu zaridit aby kazda nekompatibilni zmena implementace nutne znamenala zmenu API.
Ano, vy jste už poněkolikáté zaměnil kompatibilitu API a kompatibilitu implementace. Já stále píšu o kompatibilitě API a vy na to pokaždé reagujete kompatibilitou implementace. Ne každá změna implementace znamená změnu API.
Obávám se, že on to nezaměňuje. On mluví o tom, že API zasahuje i do implementace. Že typ, nebo API vidí, že se změnila implementace (přesněji ani ne tak implementace, jako chování). Ty vycházíš z předpokladu, že API a implementace jsou od sebe rozdílné. My uvádíme důkazy (Elm), že to tak není.

... Ten kód, který závisel na tom, že to trvá určitou dobu, se rozbije.

Je to zrychlení nekompatibilní změna API?
Ano. Samozřejmě je to změna API.

I když ta doba trvání nikde nebyla zdokumentovaná, nebyl to účel té funkce a jenom to tak náhodou vyšlo. Dá se na takový případ napsat jednotkový test? Mohl by to typový systém řešit jinak, než že by každá změna implementace znamenala nekompatibilní změnu, a tím pádem by veškerá typovost šla k šípku, protože by nic nezáviselo na typech ale na konkrétních implementacích?
Takhle to ale přeci vůbec není.

Funkce:
foo1 x y = x + y
a
foo1 x y = y + x

Jsou různé implemnetace, ale mají stejné API, protože stejnou funkčnost.

Zatímco
foo2 x y = x / y
a
foo2 x y = y / x

už mají různé API, protože různou funkčnost.

Název: Re:Typový system versus unittesty
Přispěvatel: Honza 18. 08. 2018, 21:26:02
Funkce:
foo1 x y = x + y
a
foo1 x y = y + x

Jsou různé implemnetace, ale mají stejné API, protože stejnou funkčnost.

Ale tohle je přeci krásný příklad toho, že to tak není! Dokud bude operátor + komutativní, tak předpoklad platí, ale pokud ho někdo přepíše tak, že komutativní už nebude, tak to přestane fungovat správně, ale API zůstalo stejné. No a to ohlídají právě unit testy.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 18. 08. 2018, 21:39:53
Ty vycházíš z předpokladu, že API a implementace jsou od sebe rozdílné.
To není předpoklad, to je definice API.

My uvádíme důkazy (Elm), že to tak není.
Vy pouze uvádíte příklady, kde jazyk neumožňuje definovat žádné API – takže nezbývá, než být API definované někde bokem, v dokumentaci. A na kontrolu toho API opět potřebujete testy.

Samozřejmě je to změna API.
Takže každá změna implementace je změna API. To pak ale není API. A co se týče praktického použití by takový systém byl úplně stejný, jako dynamicky typované jazyky. Protože byste při každé změně implementace automaticky všude změnil typy.

Takhle to ale přeci vůbec není.

Funkce:
foo1 x y = x + y
a
foo1 x y = y + x

Jsou různé implemnetace, ale mají stejné API, protože stejnou funkčnost.

Zatímco
foo2 x y = x / y
a
foo2 x y = y / x

už mají různé API, protože různou funkčnost.
Nesmysl. Dvě různé implementace, které mají (pro většinu použití) stejnou funkčnost a tedy stejné API vypadají např. takhle:

Kód: [Vybrat]
function sum1(addends) {
  var sum = 0;
  for(var i = addends.length -1; i >= 0; i--) {
    sum += addends[i];
  }
  return sum;
}

function sum2(addends) {
  var sum = 0;
  for(var i = 0; i < addends.length; i++) {
    sum += addends[i];
  }
  return sum;
}
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 08. 2018, 23:01:58
Funkce:
foo1 x y = x + y
a
foo1 x y = y + x

Jsou různé implemnetace, ale mají stejné API, protože stejnou funkčnost.

Ale tohle je přeci krásný příklad toho, že to tak není! Dokud bude operátor + komutativní, tak předpoklad platí, ale pokud ho někdo přepíše tak, že komutativní už nebude, tak to přestane fungovat správně, ale API zůstalo stejné. No a to ohlídají právě unit testy.

Zkuste se naladit na tu myšlenku: v okamžiku když by se změnil ten operátor, a přestal být komutativní, tak se změní typová signatura toho operátoru. Díky tomu se samozřejmě transitivně změní všechny typy, které na tom závisí. Takže to nepůjde přeložit. Což je přesně to, co řeší testy, a typy mohou taky.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 18. 08. 2018, 23:13:19
My uvádíme důkazy (Elm), že to tak není.
Vy pouze uvádíte příklady, kde jazyk neumožňuje definovat žádné API – takže nezbývá, než být API definované někde bokem, v dokumentaci. A na kontrolu toho API opět potřebujete testy.

Toto nepozoruju. Uvedl jsem konkrétní příklad jazyka. Ten jazyk umožňuje definovat API. A tento jazyk si dokáže ohlídat nekompatabilní změny v implementaci, kdy by implementace změnila chování.

Samozřejmě je to změna API.
Takže každá změna implementace je změna API. To pak ale není API. A co se týče praktického použití by takový systém byl úplně stejný, jako dynamicky typované jazyky. Protože byste při každé změně implementace automaticky všude změnil typy.
Je to zcela stejné jako testy. Změním-li implementaci tak, že se změní chování, musím tomu zohlednit testy. Změním-li v Elmu imlementaci tak, že se změní chování, musím to zohlednit v typech. Pokud změním implementaci tak, že chování bude zachováno, nezmění se API, a nemusím nic měnit. Nehledal bych v tom žádnou složitost.



No, na závěr tohoto můžu maximálně doporučit, aby si se na ten Elm mrknul, mohlo by to být pro tebe poučné. Námětem tohoto vlákna nebylo to, někoho tady učit typy, nebo přesvědčovat co všechno se dá pomocí typů udělat, takže já to tady za sebe uzavírám.
Název: Re:Typový system versus unittesty
Přispěvatel: gll 18. 08. 2018, 23:53:35
jak by tedy vypadaly ty funkce v Elmu?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 08. 2018, 09:22:06
A tento jazyk si dokáže ohlídat nekompatabilní změny v implementaci, kdy by implementace změnila chování.
Jenže já tu celou dobu řeším opačný případ. Tedy kompatibilní změnu v implementaci, která z pohledu dohodnutého API chování nemění. Jako příklad jsem uvedl ty dvě různé implementace sumy, které ve většině případů použití implementují stejné API.

Je to zcela stejné jako testy. Změním-li implementaci tak, že se změní chování, musím tomu zohlednit testy. Změním-li v Elmu imlementaci tak, že se změní chování, musím to zohlednit v typech. Pokud změním implementaci tak, že chování bude zachováno, nezmění se API, a nemusím nic měnit. Nehledal bych v tom žádnou složitost.
V komentáři, na který reagujete, jsem uvedl dvě funkce. Tak v tom nehledejte žádnou složitost, nevymlouvejte se a napište je v Elmu ve dvou variantách. Jednou jako funkce s kompatibilním API, které může jejich uživatel vzájemně zaměňovat, a podruhé jako funkce s nekompatibilním API, protože uživatel závisí i na době jejich provedení, která obecně bude různá.

No, na závěr tohoto můžu maximálně doporučit, aby si se na ten Elm mrknul, mohlo by to být pro tebe poučné. Námětem tohoto vlákna nebylo to, někoho tady učit typy, nebo přesvědčovat co všechno se dá pomocí typů udělat, takže já to tady za sebe uzavírám.
Smyslem komentářů v posledních dnech opravdu nebylo naučit vás typy nebo vás přesvědčovat, co se pomocí typů dá a co nedá dělat. Smyslem bylo vysvětlit některým (například vám), že změna v implementaci může a nemusí znamenat změnu API, a že dokonce stejná změna v implementaci pro někoho může a pro jiného nemusí být změnou API.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 19. 08. 2018, 15:48:07
Ty vycházíš z předpokladu, že API a implementace jsou od sebe rozdílné.
To není předpoklad, to je definice API.
Je to Jiraskova definice? Nebo muzes postnout nejaky odkaz?
Název: Re:Typový system versus unittesty
Přispěvatel: Bacsa 19. 08. 2018, 16:29:23
Ty vycházíš z předpokladu, že API a implementace jsou od sebe rozdílné.
To není předpoklad, to je definice API.
Je to Jiraskova definice? Nebo muzes postnout nejaky odkaz?
Ne, Alois Jirásek nic takového nedefinoval.
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 08. 2018, 16:42:09
To není předpoklad, to je definice API.
Je to Jiraskova definice? Nebo muzes postnout nejaky odkaz?
Klidně můžu postnout odkaz. API (https://techterms.com/definition/api). Nebo vám to můžu i rovnou napsat. „API“ je zkratka pro „Application programming interface“. „Interface“ je „rozhraní“, vrstva mezi implementací a volajícím kódem, která zajišťuje jejich částečné oddělení, určitou abstrakci implementace.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 19. 08. 2018, 17:27:19
To není předpoklad, to je definice API.
Je to Jiraskova definice? Nebo muzes postnout nejaky odkaz?
Klidně můžu postnout odkaz. API (https://techterms.com/definition/api). Nebo vám to můžu i rovnou napsat. „API“ je zkratka pro „Application programming interface“. „Interface“ je „rozhraní“, vrstva mezi implementací a volajícím kódem, která zajišťuje jejich částečné oddělení, určitou abstrakci implementace.

Podle toho co sem si tam precetl tak API je velice nevhodny termin pro to co tim tady nazyvame.
Tam se mluvi o systemech a aplikacich. My resime jednotlive funkce (aspon doufam).

Mozna pro nas ucel je lepsi pouzivat slovo podpis?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 08. 2018, 18:00:29
Podle toho co sem si tam precetl tak API je velice nevhodny termin pro to co tim tady nazyvame.
Tam se mluvi o systemech a aplikacich. My resime jednotlive funkce (aspon doufam).

Mozna pro nas ucel je lepsi pouzivat slovo podpis?
API má obvykle více funkcí, my řešíme jednu funkci z toho API. Podpis by podle mne bylo horší slovo, protože podpis evokuje nějakou identitu. A to je právě něco jiného – API znamená, že mám nějaké definované chování, a zbytek chování, který je pro mne nepodstatný, definovaný není. Takže to API pak může být implementováno různými způsoby, různými identitami – všechny musí mít stejné to dohodnuté chování, ale chování, které dohodnuté není, může být libovolné. Třeba jako u té funkce sum, kterou jsem uváděl, by nejspíš bylo dohodnuté, že ta funkce vrací součet všech hodnot v poli. Ve většině případů by ale už asi nebylo dohodnuté, jakým způsobem má ta funkce pole procházet – jestli od začátku do konce, od konce do začátku nebo třeba paralelně. Ale v některých případech může být dohodnuté i tohle. Proto je API věcí dohody, která může být částečně vyjádřena ve zdrojovém kódu (třeba pomocí typů), ale některé závazky API prostě nijak formálně vyjádřit nelze. A proto ani nelze automaticky zjistit, jestli změna implementace změnila nebo nezměnila API.
Název: Re:Typový system versus unittesty
Přispěvatel: listoper 19. 08. 2018, 18:24:45
... ale některé závazky API prostě nijak formálně vyjádřit nelze. A proto ani nelze automaticky zjistit, jestli změna implementace změnila nebo nezměnila API.

A muzes teda uvest priklad zavazku, ktery formalne vyjadrit nelze?
Název: Re:Typový system versus unittesty
Přispěvatel: Filip Jirsák 19. 08. 2018, 20:24:11
A muzes teda uvest priklad zavazku, ktery formalne vyjadrit nelze?
Třeba spousta her napsaných v Turbo Pascalu měla na novějších platformách potíže s rychlostí – byly příliš rychlé a nedaly se hrát. Protože rychlost závisela na něčem, co záviselo na rychlosti procesoru. Takže tam by ten závazek zněl nějak jako „časovač musí běžet tak rychle, aby normální lidé mohli tu hru hrát“. Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 08. 2018, 20:30:04
jak by tedy vypadaly ty funkce v Elmu?

Ha, omlouvám se! Zde jsem se extrémně nešťastně vyjádřil.

Elm samozřejmě neumí to všechno, o čem jsem hovořil. Elm umí ošetřit právě tu změnu kontraktu na úrovni API. Tedy uvedl jsem ho jako příklad pro použití, kdy testy hlídají, zda se něco změnilo, a abych si toho byl schopen všimnout.

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. (Případně se tu objevili příspěvky o dalších technikách.)

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.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 08. 2018, 20:42:40
Ty vycházíš z předpokladu, že API a implementace jsou od sebe rozdílné.
To není předpoklad, to je definice API.

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.
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 08. 2018, 20:46:05
Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 08. 2018, 20:50:18
Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
překladač nezná frekvenci hodin cílového CPU, ta se navíc může za běhu měnit, to nemusí až tak moc vadit, pokud bychom se zabývali jenom nejhorším možným případem
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 08. 2018, 20:53:02
Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
překladač nezná frekvenci hodin cílového CPU, ta se navíc může za běhu měnit, to nemusí až tak moc vadit, pokud bychom se zabývali jenom nejhorším možným případem
Já tam vidím "ms", takže na frekvenci CPU nezáleží.

Ostatně, to, že rychlost funkce závisela na rychlosti procesoru je pradávná historie. Dneska když se píše hra, tak se určitě nebude opírat o frekvenci CPU, ale o hodiny.
Název: Re:Typový system versus unittesty
Přispěvatel: v 19. 08. 2018, 21:07:40
Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
překladač nezná frekvenci hodin cílového CPU, ta se navíc může za běhu měnit, to nemusí až tak moc vadit, pokud bychom se zabývali jenom nejhorším možným případem
Já tam vidím "ms", takže na frekvenci CPU nezáleží.

Ostatně, to, že rychlost funkce závisela na rychlosti procesoru je pradávná historie. Dneska když se píše hra, tak se určitě nebude opírat o frekvenci CPU, ale o hodiny.
kde byste vzal dobu trvání fragmentu kódu?
Název: Re:Typový system versus unittesty
Přispěvatel: BoneFlute 19. 08. 2018, 21:17:05
Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
překladač nezná frekvenci hodin cílového CPU, ta se navíc může