Příspěvky

3226

Vývoj / Re:Typový system versus unittesty

« kdy: 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 ytý succ 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ů.

3227

Vývoj / Re:Typový system versus unittesty

« kdy: 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.

3228

Vývoj / Re:Typový system versus unittesty

« kdy: 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í.

3229

Vývoj / Re:Typový system versus unittesty

« kdy: 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.

3230

Vývoj / Re:Typový system versus unittesty

« kdy: 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.

3231

Vývoj / Re:Typový system versus unittesty

« kdy: 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

3232

Vývoj / Re:Typový system versus unittesty

« kdy: 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.

3233

Vývoj / Re:JetBrains nechá Kotlin kompilovat do nativního bytecode

« kdy: 18. 06. 2018, 13:36:57 »

Proč nemůžeš v Kotlinu používat Java knihovny při kompilaci do nativního kódu? To nechápu, Java je určitě transofrmovatelná do Kotlinu a díky OpenJDK musí být i přístup do standardní knihovny i do těch jejich nativ částí psaných v Céčku. Tam nemůže být v principu žádná překážka, ne?

Kotlin není jazyk nad JVM, je to samostatný jazyk, který se dá kompilovat do nativního kódu, Java bajtkódu a do JavaScriptu. Přeložit javovské zdrojáky do Kotlinu by asi šlo, ale pořád tam budou chybět ty služby, které běžící aplikaci poskytuje JVM (případně ve spolupráci s nativním kódem ve standardní knihovně).

Teoreticky by to asi všechno šlo udělat, ale není to směr, kterým by se v současné době Kotlin vyvíjel. A osobně si nemyslím, že by to dávalo velký smysl – smysluplnější mi připadá cesta, kterou jde GraalVM. Navíc doménou autorů Kotlinu jsou programovací jazyky, ne kompilátory a virtuální stroje, takže ani nečekám, že by se Kotlin vydal tímhle směrem.

3234

Vývoj / Re:Typový system versus unittesty

« kdy: 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;
}

3235

Vývoj / Re:Typový system versus unittesty

« kdy: 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.

3236

Vývoj / Re:Typový system versus unittesty

« kdy: 18. 06. 2018, 12:14:51 »

Kde?

Hned v komentáři #6.

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

3237

Vývoj / Re:Typový system versus unittesty

« kdy: 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.

3238

Vývoj / Re:Typový system versus unittesty

« kdy: 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.

3239

Sítě / Re:Stoprocentně bezpečný 5GHz/LAN router?

« kdy: 18. 06. 2018, 07:24:21 »

Žádná / žádný.

Toho je možné dosáhnout tehdy, pokud dělá jen a pouze to, co má, tedy routuje.

Ani tak toho není možné dosáhnout.

Můj požadavek tedy je, aby router neumožňoval jakoukoliv změnu konfigurace

K čemu by takový router byl? To by jako měl z továrny nastavenou IP adresu plus masku a bránu na WAN rozhraní a IP adresu s maskou na LAN rozhraní?

A pokud by změnu konfigurace umožňoval, dělá i něco jiného, než routování, a ten konfigurátor je další software, ve kterém může být chyba a který by měl mít možnost aktualizace.

Navíc když k té konfiguraci nepovolíte přístup z WAN, přidáváte k tomu routeru a konfigurátoru ještě firewall.

nebo dokonce přes WiFi

Vždyť má jen routovat, tak jaké WiFi?

3240

Vývoj / Re:JetBrains nechá Kotlin kompilovat do nativního bytecode

« kdy: 18. 06. 2018, 07:13:17 »

To není žádná novinka. Kotlin lze překládat pro JVM, do JS a do nativního kódu. JVM do důchodu nepůjde, protože jde pořád jen o překlad toho kódu v Kotlinu, takže když to přeložíte do JS nebo do nativního kódu, nemůžete použít žádné Java knihovny, prostě je to stejné,jako kdybyste to napsal v TypeScriptu nebo v C++.

Mnohem zajímavější je GraalVM, jejíž součástí je i nástroj na vytvoření nativního obrazu aplikace. Mimochodem, GraalVM je od Oracle.