Typový system versus unittesty

[listoper]

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.

[Reklama]

[Filip Jirsák]

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.

[Vlado]

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ť.

[Vlado]

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.

[Bacsa]

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?

[Reklama]

[listoper]

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.

[Filip Jirsák]

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?

[Vlado]

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

[BoneFlute]

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.

[Honza]

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.

[Filip Jirsák]

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;
}


[BoneFlute]

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.

[BoneFlute]

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.

[gll]

jak by tedy vypadaly ty funkce v Elmu?

[Filip Jirsák]

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.