Typový system versus unittesty

[BoneFlute]

tady někdo píše k tématu https://blog.root.cz/scientia/

Paráda!

[Reklama]

[Scripter]

tady někdo píše k tématu https://blog.root.cz/scientia/

Paráda!

Doufám, že se tam přesune relevantní diskuse a blitky trotlů se budou mazat.

[listoper]

Potrebuju jeste na chvilku vyhrabat tohle vlakno, protoze si myslim, ze jsem narazil na oblast kde unit testy predci typy.
A chtel bych si nechat poradit jestli je to tak nebo ne...

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Ve vetsine pripadu to asi nebude velky problem, ale co kdyz se budu u nejakeho projektu rozhodovat, ze vymenim kompilator za jiny, protoze ma nejake vyhody, kterych chci vyuzit(napada me jen rychlost, ale muze jich asi byt vic).

Co myslite?

[Bacsa]

Potrebuju jeste na chvilku vyhrabat tohle vlakno, protoze si myslim, ze jsem narazil na oblast kde unit testy predci typy.
A chtel bych si nechat poradit jestli je to tak nebo ne...

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Ve vetsine pripadu to asi nebude velky problem, ale co kdyz se budu u nejakeho projektu rozhodovat, ze vymenim kompilator za jiny, protoze ma nejake vyhody, kterych chci vyuzit(napada me jen rychlost, ale muze jich asi byt vic).

Co myslite?

Jo, musí se věřit překladači, ale překladače stejného jazyka budou fungovat stejně na stejném kódu.

[Kit]

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Dobře je to vidět například u PHP, kde se každá verze chová mírně odlišně. Navíc u stejné verze ještě závisí na konfiguraci a na verzích instalovaných frameworků. Nedovedu si už představit dělat v PHP bez testů.

[Reklama]

[BoneFlute]

Potrebuju jeste na chvilku vyhrabat tohle vlakno, protoze si myslim, ze jsem narazil na oblast kde unit testy predci typy.
A chtel bych si nechat poradit jestli je to tak nebo ne...

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Ve vetsine pripadu to asi nebude velky problem, ale co kdyz se budu u nejakeho projektu rozhodovat, ze vymenim kompilator za jiny, protoze ma nejake vyhody, kterych chci vyuzit(napada me jen rychlost, ale muze jich asi byt vic).

Co myslite?

Částečně máš pravdu. Ale když si to rozebereš:
- U typů musíš věřit kompilátoru, který napsali lepší programátoři, stavějící na teorii lepších matematiků, ověřený miliardami iterací jednotlivých vývojářů-uživatelů, kteří "ověřili" že se ten typový systém chová "inteligentně".
- U unittestů musíš věřit autorovi těch testů.

Svobodně si vyber, komu svěříš svou důvěru :-)

[Kiwi]

Potrebuju jeste na chvilku vyhrabat tohle vlakno, protoze si myslim, ze jsem narazil na oblast kde unit testy predci typy.
A chtel bych si nechat poradit jestli je to tak nebo ne...

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Ve vetsine pripadu to asi nebude velky problem, ale co kdyz se budu u nejakeho projektu rozhodovat, ze vymenim kompilator za jiny, protoze ma nejake vyhody, kterych chci vyuzit(napada me jen rychlost, ale muze jich asi byt vic).

Co myslite?

Částečně máš pravdu. Ale když si to rozebereš:
- U typů musíš věřit kompilátoru, který napsali lepší programátoři, stavějící na teorii lepších matematiků, ověřený miliardami iterací jednotlivých vývojářů-uživatelů, kteří "ověřili" že se ten typový systém chová "inteligentně".
- U unittestů musíš věřit autorovi těch testů.

Svobodně si vyber, komu svěříš svou důvěru :-)

Ta urputnost je až zarážející. Unit testy ověřují, zda kus kódu dělá to, co se po něm chce podle specifikace. Typový systém je jedna z možných součástí nástrojů k modelování problémů pomocí počítačů. Dva mimoběžné světy. Celá tahle debata vznikla jako poznámka, že kniha by za určitých okolností (když bude o jídle) mohla nahrazovat jídlo. Odpověď je ne, nemohla. Kniha je kniha a jídlo je jídlo.

[Kit]

- U typů musíš věřit kompilátoru, který napsali lepší programátoři, stavějící na teorii lepších matematiků, ověřený miliardami iterací jednotlivých vývojářů-uživatelů, kteří "ověřili" že se ten typový systém chová "inteligentně".
- U unittestů musíš věřit autorovi těch testů.

Svobodně si vyber, komu svěříš svou důvěru :-)

U typů musíš také věřit autorovi těch typů.

[Bacsa]

Potrebuju jeste na chvilku vyhrabat tohle vlakno, protoze si myslim, ze jsem narazil na oblast kde unit testy predci typy.
A chtel bych si nechat poradit jestli je to tak nebo ne...

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Ve vetsine pripadu to asi nebude velky problem, ale co kdyz se budu u nejakeho projektu rozhodovat, ze vymenim kompilator za jiny, protoze ma nejake vyhody, kterych chci vyuzit(napada me jen rychlost, ale muze jich asi byt vic).

Co myslite?

Částečně máš pravdu. Ale když si to rozebereš:
- U typů musíš věřit kompilátoru, který napsali lepší programátoři, stavějící na teorii lepších matematiků, ověřený miliardami iterací jednotlivých vývojářů-uživatelů, kteří "ověřili" že se ten typový systém chová "inteligentně".
- U unittestů musíš věřit autorovi těch testů.

Svobodně si vyber, komu svěříš svou důvěru :-)

Ta urputnost je až zarážející. Unit testy ověřují, zda kus kódu dělá to, co se po něm chce podle specifikace. Typový systém je jedna z možných součástí nástrojů k modelování problémů pomocí počítačů. Dva mimoběžné světy. Celá tahle debata vznikla jako poznámka, že kniha by za určitých okolností (když bude o jídle) mohla nahrazovat jídlo. Odpověď je ne, nemohla. Kniha je kniha a jídlo je jídlo.

Typy (závislostní) a jednotkové testy se na úrovni sémantiky docela protínají, tedy alespoň v případě “extrinsics”. Některé jazyky umí ověřovat kód symbolicky.

[Bacsa]

- U typů musíš věřit kompilátoru, který napsali lepší programátoři, stavějící na teorii lepších matematiků, ověřený miliardami iterací jednotlivých vývojářů-uživatelů, kteří "ověřili" že se ten typový systém chová "inteligentně".
- U unittestů musíš věřit autorovi těch testů.

Svobodně si vyber, komu svěříš svou důvěru :-)

U typů musíš také věřit autorovi těch typů.

Kite, typy - a to je moje zvláštnost - si zásadně míchám sám 

[Kit]

Typy (závislostní) a jednotkové testy se na úrovni sémantiky docela protínají, tedy alespoň v případě “extrinsics”. Některé jazyky umí ověřovat kód symbolicky.

Symbolicky můžeš ověřit maximálně syntaxi, ale už ne sémantiku.

[Kit]

- U typů musíš věřit kompilátoru, který napsali lepší programátoři, stavějící na teorii lepších matematiků, ověřený miliardami iterací jednotlivých vývojářů-uživatelů, kteří "ověřili" že se ten typový systém chová "inteligentně".
- U unittestů musíš věřit autorovi těch testů.

Svobodně si vyber, komu svěříš svou důvěru :-)

U typů musíš také věřit autorovi těch typů.

Kite, typy - a to je moje zvláštnost - si zásadně míchám sám 

Takže sám sobě věříš? To neděláš dobře, Jaromíre. Jednou se ti to vymstí.

[Bacsa]

Typy (závislostní) a jednotkové testy se na úrovni sémantiky docela protínají, tedy alespoň v případě “extrinsics”. Některé jazyky umí ověřovat kód symbolicky.

Symbolicky můžeš ověřit maximálně syntaxi, ale už ne sémantiku.

To není pravda, viz závislostní typy v Agdě nebo Idrisu. Ale to se tu už řešilo včetně příkladů.

[Petr]

Potrebuju jeste na chvilku vyhrabat tohle vlakno, protoze si myslim, ze jsem narazil na oblast kde unit testy predci typy.
A chtel bych si nechat poradit jestli je to tak nebo ne...

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Ve vetsine pripadu to asi nebude velky problem, ale co kdyz se budu u nejakeho projektu rozhodovat, ze vymenim kompilator za jiny, protoze ma nejake vyhody, kterych chci vyuzit(napada me jen rychlost, ale muze jich asi byt vic).

Co myslite?

Ano, to je jeden z problémů, ktdrý skrz své malé zkušenosti nevnímáš v celé jeho šíři. Změna kompilátoru není výjimečná, je běžná. Stačí změna platformy (multiplatformní program) či architektury. Kompilátor se mění i s jeho verzí.

Tyto nemají zaručeně ani stejný výstup, ani stejnou kontrolu. Často pak upravuješ program ne proto, že je chybný, ale aby prošel tím ne o onním kompilátorem.

A to ani nemusíme zabředávat do typů, které mění své vlastnosti podle architektury.

Ve výsledku statické typy představují spíše překážku než pomoc, protože překáží, kód je kvůli nim zbytečně těžkopádný a nepřehledný, což zvyšuje počet jiných chyb, které kompilátor neodhalí, a tak se stejně program musí testovat tak jako tak.

Typový systém není cesta k bezchybnému kódu a dokonce ani cesta ke snížení počtu chyb v programu.

Testy jsou lepší cesta. Sice se dá argumentovat, že to je také zbytečný kód navíc podobně jako u statických typů (což je pravda, práci to neušetří), ale je to kód, který není součástí výsledného programu.

Cesta k ideálu bezchybného kódu vede podle mě jinudy. Je to cesta krátkého, přehledného a dobře srozumitelného kódu. Čím méně má program řádků, tím méně má spolehlivě statisticky chyb, čím má jazyk pokročilejší konstrukce, které program zkracují a zpřehledňují či dokonce zabraňují udělat některé chyby, tím lépe.

Přičemž přehlednost a krátkost se mohou navzájem tlouci, takže zkracovat ano, ale nikdy na úkor přehlednosti.

Líbí se mi třeba konstrukce with, nebo zákaz používání přiřazení v podmínkách a podobně. To jsou jednoduchá opatření, která snižují počet chyb spolehlivěji, než statické typy, protože oproti nim si nenesou s sebou negativa.

[Bacsa]

Potrebuju jeste na chvilku vyhrabat tohle vlakno, protoze si myslim, ze jsem narazil na oblast kde unit testy predci typy.
A chtel bych si nechat poradit jestli je to tak nebo ne...

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Ve vetsine pripadu to asi nebude velky problem, ale co kdyz se budu u nejakeho projektu rozhodovat, ze vymenim kompilator za jiny, protoze ma nejake vyhody, kterych chci vyuzit(napada me jen rychlost, ale muze jich asi byt vic).

Co myslite?

Ano, to je jeden z problémů, ktdrý skrz své malé zkušenosti nevnímáš v celé jeho šíři. Změna kompilátoru není výjimečná, je běžná. Stačí změna platformy (multiplatformní program) či architektury. Kompilátor se mění i s jeho verzí.

Tyto nemají zaručeně ani stejný výstup, ani stejnou kontrolu. Často pak upravuješ program ne proto, že je chybný, ale aby prošel tím ne o onním kompilátorem.

A to ani nemusíme zabředávat do typů, které mění své vlastnosti podle architektury.

Ve výsledku statické typy představují spíše překážku než pomoc, protože překáží, kód je kvůli nim zbytečně těžkopádný a nepřehledný, což zvyšuje počet jiných chyb, které kompilátor neodhalí, a tak se stejně program musí testovat tak jako tak.

Typový systém není cesta k bezchybnému kódu a dokonce ani cesta ke snížení počtu chyb v programu.

Testy jsou lepší cesta. Sice se dá argumentovat, že to je také zbytečný kód navíc podobně jako u statických typů (což je pravda, práci to neušetří), ale je to kód, který není součástí výsledného programu.

Cesta k ideálu bezchybného kódu vede podle mě jinudy. Je to cesta krátkého, přehledného a dobře srozumitelného kódu. Čím méně má program řádků, tím méně má spolehlivě statisticky chyb, čím má jazyk pokročilejší konstrukce, které program zkracují a zpřehledňují či dokonce zabraňují udělat některé chyby, tím lépe.

Přičemž přehlednost a krátkost se mohou navzájem tlouci, takže zkracovat ano, ale nikdy na úkor přehlednosti.

Líbí se mi třeba konstrukce with, nebo zákaz používání přiřazení v podmínkách a podobně. To jsou jednoduchá opatření, která snižují počet chyb spolehlivěji, než statické typy, protože oproti nim si nenesou s sebou negativa.

To je zase blábol