Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Prograt 17. 02. 2018, 22:08:16
-
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
-
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.
-
Kotlin moc neznám. Rust má něco trochu podobného formou autoimplementace traitů (trait v Rustu = protokol ve Swiftu). Zjednodušeně řečeno je možné deklarovat, že cokoli implementuje např. traity Kráva a Prase, případně s dalšími podmínkami ohledně přidružených typů, konstant apod., má automaticky i nějakou výchozí implementaci traitu Debil. V podstatě je to jakási náhrada za tzv. kachní typování, které Rust nemá, sice těžkopádnější, než pravý duck typing jako má např. Go, ale za to je bezpečná, staticky kontrolovatelná a výborně se optimalizuje.
-
Kotlin moc neznám. Rust má něco trochu podobného formou autoimplementace traitů (trait v Rustu = protokol ve Swiftu). Zjednodušeně řečeno je možné deklarovat, že cokoli implementuje např. traity Kráva a Prase, případně s dalšími podmínkami ohledně přidružených typů, konstant apod., má automaticky i nějakou výchozí implementaci traitu Debil. V podstatě je to jakási náhrada za tzv. kachní typování, které Rust nemá, sice těžkopádnější, než pravý duck typing jako má např. Go, ale za to je bezpečná, staticky kontrolovatelná a výborně se optimalizuje.
Go taky nemá pravé duck typing (pročež je bezpečné a staticky typované). Ta podmíněná konformita akorát umožňuje flexibilnější a úspornější implementaci protokolů u generických typů (ať už tříd nebo struktur). Ovšem bez higher kinds (viz "vyšší druhy" na Wikipedii) bude typový systém Swiftu stále neúplný.
-
Myslím, že Go má k pravému duck typingu nejblíže ze statických jazyků. Není ale pravda, že by bylo bezpečné. V tom smyslu jako Rust bezpečné není.
Se Swiftem jsem nikdy nic nedělal, tak mě překvapuje, že ani on nemá typy vyšších druhů. Stejně je na tom Rust a patří to k věcem, které mu bývají vytýkány. Rust si částečně vypomáhá přidruženými typy, což je ale jenom bastl, jak se v některých případech obejít bez vyšších druhů, které by se tam výborně hodily. Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
-
Myslím, že Go má k pravému duck typingu nejblíže ze statických jazyků. Není ale pravda, že by bylo bezpečné. V tom smyslu jako Rust bezpečné není.
Se Swiftem jsem nikdy nic nedělal, tak mě překvapuje, že ani on nemá typy vyšších druhů. Stejně je na tom Rust a patří to k věcem, které mu bývají vytýkány. Rust si částečně vypomáhá přidruženými typy, což je ale jenom bastl, jak se v některých případech obejít bez vyšších druhů, které by se tam výborně hodily. Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
Duck typing je záležitost běhu (runtime), kdežto v Go se všechny typy řeší při kompilaci, je to normální statické typování s rozhraními. Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.
-
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.
To je dost podivné chování.
-
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.
To je dost podivné chování.
ale ma to logiku, zkompiluje se jen to co se pouzije.
-
Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.
HAHAHAHA. A ten o policajtech, co musí chodit ve třech, znáte?
Programy v Javě padají naprosto běžně. V C++ se ve vyjímečných případech může stát, že to, co projde překladem, nespadne. Go má drtivou většinu stejných zdrojů pádů, jako C++: neinicializované nebo náhodné ukazatele, dereference NULL, race conditions, paměťové leaky (které garbage collector neodchytí), divoké přetypovávání atd. Snad jedině nekontrolovatelné duplikace a kontrola mezí polí jsou v Go přece jenom trochu líp řešené.
Statický duck typing à la Go je taky nebezpečný, protože když u nějakého parametru předpokládáte metodu tentononc(), úplně klidně se může stát, že se úplně jiná metoda stejného jména objeví třeba v knihovně, nebo ji jinde implementuje jiný člen týmu. Překladač to vezme a bude spokojený, že nároky na rozhraní objektu jsou splněné, ovšem při běhu to pak bude dělat psí kusy.
Což vůbec neznamená, že Go není dobrý jazyk. Je, mám ho docela rád, a na to, k čemu je primárně určený, je dokonce výborný, stejně jako Python nebo Smalltalk jsou skvělé jazyky ve svých vlastních oborech. Ale bezpečné Go prostě není, a staticky prokazatelně bezpečné už vůbec ne. Na bezpečnost je Rust nebo případně Ada, na snadné programování na vysoké úrovni je Python, a Go je výborný kompromis mezi snadnou použitelností jazyků, jako Python, a rychlostí staticky kompilovaných jazyků.
-
Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.
-
Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.
HAHAHAHA. A ten o policajtech, co musí chodit ve třech, znáte?
Programy v Javě padají naprosto běžně. V C++ se ve vyjímečných případech může stát, že to, co projde překladem, nespadne. Go má drtivou většinu stejných zdrojů pádů, jako C++: neinicializované nebo náhodné ukazatele, dereference NULL, race conditions, paměťové leaky (které garbage collector neodchytí), divoké přetypovávání atd. Snad jedině nekontrolovatelné duplikace a kontrola mezí polí jsou v Go přece jenom trochu líp řešené.
Statický duck typing à la Go je taky nebezpečný, protože když u nějakého parametru předpokládáte metodu tentononc(), úplně klidně se může stát, že se úplně jiná metoda stejného jména objeví třeba v knihovně, nebo ji jinde implementuje jiný člen týmu. Překladač to vezme a bude spokojený, že nároky na rozhraní objektu jsou splněné, ovšem při běhu to pak bude dělat psí kusy.
Což vůbec neznamená, že Go není dobrý jazyk. Je, mám ho docela rád, a na to, k čemu je primárně určený, je dokonce výborný, stejně jako Python nebo Smalltalk jsou skvělé jazyky ve svých vlastních oborech. Ale bezpečné Go prostě není, a staticky prokazatelně bezpečné už vůbec ne. Na bezpečnost je Rust nebo případně Ada, na snadné programování na vysoké úrovni je Python, a Go je výborný kompromis mezi snadnou použitelností jazyků, jako Python, a rychlostí staticky kompilovaných jazyků.
Leaky? GC v současném Go odchytne vše (na rozdíl od první verze), co je na GC haldě (legální je ovšem i přetahování odkazu na pole z C).
K bezpečnosti, Go je bezpečné do té míry, že pokud kontroluju chybové hodnoty, program nechcípne. To znamená testovat návratovou hodnotu ok u map a přetypování, err všude, kde se vrací jako druhá hodnota apod.
-
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.
Totéž tvrdí vývojáři Rustu. Možná, že konkrétně v případě Swiftu na tom něco je, přece jenom je to jazyk určený především na vývoj appek pro iPhone, takže HKT a monádám v této cílové skupině asi hodně lidí opravdu moc nerozumí (ačkoli nevím, jestli to je dobrý důvod pro to, aby to nebylo).
-
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.
Totéž tvrdí vývojáři Rustu. Možná, že konkrétně v případě Swiftu na tom něco je, přece jenom je to jazyk určený především na vývoj appek pro iPhone, takže HKT a monádám v této cílové skupině asi hodně lidí opravdu moc nerozumí (ačkoli nevím, jestli to je dobrý důvod pro to, aby to nebylo).
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.
-
Leaky? GC v současném Go odchytne vše (na rozdíl od první verze), co je na GC haldě (legální je ovšem i přetahování odkazu na pole z C).
Tak jo, nesledoval jsem to zas tak bedlivě, takže jestli to opravili, tím líp. Řeší to i známý bug, kdy GC neuvolňoval kanál, na který čekala gorutina, po té, co skončil producer?
K bezpečnosti, Go je bezpečné do té míry, že pokud kontroluju chybové hodnoty, program nechcípne. To znamená testovat návratovou hodnotu ok u map a přetypování, err všude, kde se vrací jako druhá hodnota apod.
To není pravda. Příklad:
func main() {
c := make(chan string)
go func() {
msg := <- c
fmt.Println(msg)
c <- "hello"
}()
msg := <- c
fmt.Println(msg)
c <- "world"
}
Žádné chybové hodnoty nikde nejsou, přeloží se to v pohodě bez warningů, ale zkuste si to pustit. Bum.
NB: v Rustu se stejný program ani nepřeloží, protože vede k typové chybě, kterou kompiler detektuje.
-
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.
Jakže děláte HKT v C++? To by mě docela zajímalo.
-
https://stackoverflow.com/questions/2565097/higher-kinded-types-with-c
-
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
V Haskellu. A je to dost geniální vlastnost, když se to použije rekurzivně, tak to vypadá jako černá magie.
-
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
V Haskellu. A je to dost geniální vlastnost, když se to použije rekurzivně, tak to vypadá jako černá magie.
jako že "instance (A b) => A (C b)"?
-
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.
Jakže děláte HKT v C++? To by mě docela zajímalo.
Částečnou specializací šablon. Jdou tak napsat generické monády. Spíš jsem si jen hrál, když jsem to chtěl v C++ napsat haskellím stylem. Inspirací byl článek o F-algebrách v C++.
-
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
V Haskellu. A je to dost geniální vlastnost, když se to použije rekurzivně, tak to vypadá jako černá magie.
jako že "instance (A b) => A (C b)"?
Přesně.
-
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.
Ono nejen ta konformance, celý koncept extensions je velmi mocný, protože umožňuje vzít jakýkoliv typ a rozšířit ho pro libovolný protokol bez dědění. A to vše s typovou kontrolou při překladu.
-
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.
Jakže děláte HKT v C++? To by mě docela zajímalo.
V C++ přece může být parametrem šablony šablona, což je přesně definice HKT. Žádná hluboká věda v tom není a vůbec nemusíme zmiňovat fujmonády :)
-
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.
Jakže děláte HKT v C++? To by mě docela zajímalo.
V C++ přece může být parametrem šablony šablona, což je přesně definice HKT. Žádná hluboká věda v tom není a vůbec nemusíme zmiňovat fujmonády :)
jj, jak jsem pastnul vyse: https://stackoverflow.com/questions/2565097/higher-kinded-types-with-c
kde je teda sice zrovna priklad monady, ale whatever... :)
templatama se da v c++ napsat vsecko, i kdyz teda pro nezkuseneho je to dost tezce citelne :) ..ale zas pouziti uz muze byt celkem pekne...
-
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.
Totéž tvrdí vývojáři Rustu. Možná, že konkrétně v případě Swiftu na tom něco je, přece jenom je to jazyk určený především na vývoj appek pro iPhone, takže HKT a monádám v této cílové skupině asi hodně lidí opravdu moc nerozumí (ačkoli nevím, jestli to je dobrý důvod pro to, aby to nebylo).
Tohle je sice hodně zrezivělé (pun intended) vlákno, ale ať je to v kontextu: Rust už HKT má.
-
Jestli tomu dobře rozumím, tak to je jako koncepty v C++20. Což je v podstatě jen syntaxe pro SFINAE, který se v C++ používá od doby zavedení šablon.
-
Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.
Rust používá monády a má na nich postaven systém řešení chyb. Nemyslím si že jsou monády nepochopitelné, není to zrovna nic dvakrát složitého.
-
Jestli tomu dobře rozumím, tak to je jako koncepty v C++20. Což je v podstatě jen syntaxe pro SFINAE, který se v C++ používá od doby zavedení šablon.
V Rustu to je přes přifařené typy. Jenže ty původně nebyly generické, takže nešlo implementovat HKT. Teď už jsou, takže to už jde.