Typový system versus unittesty

[SB]

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)?

[Reklama]

[Kit]

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.

[SB]

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

[Kit]

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?

[Gődel]

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

[Reklama]

[Gődel]

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

[v]

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

[Gődel]

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.

[Kit]

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 

[v]

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

[Gődel]

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

[Gődel]

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

[Gődel]

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.

[Kit]

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.

[Kit]

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