Rychlost Haskell vs. C++

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #255 kdy: 03. 09. 2018, 04:19:22 »
Haskell je matematický zápis. Například následující v R:
Kód: [Vybrat]
sqrt(-3)je nekorektní. Je to stejně nekorektní, jako třeba:
Kód: [Vybrat]
sqrt("hello world")Proč? Protože funkce druhá odmocnina má definiční obor (v R) "x v R, x >= 0". To znamená, že když napíšeš něco z toho výše, tak je to prostě nesmysl. A je úplně jedno, jestli ten program se následně chová deterministicky nebo ne. Je prostě blbě. Formálně blbě a věcně blbě.
To je právě tvůj problém, že tyhle dvě rozdílné věci nerozlišuješ. sqrt je stejně jako div funkce definovaná pro nějaká čísla. Pro čísla to (většinou) funguje. Pro stringy to nefunguje nikdy. Správně bys měl pro div zadefinovat typ, kde druhý argument by mohlo být jakékoliv číslo kromě 0. Jenže to tak není udělané. Funkce div vyhazuje výjimku, když je dělitel 0. Takže sqrt(-3) typ sedí, protože nemáme typ kladná čísla, máme jen typ reálná čísla. Stejně tak div(1, 0) typ sedí, protože nemáme typ integer čísla mimo 0. Žádná typová chyba tam není. Bylo by hezké, kdyby byly typy definované přesně pro definiční obory všech funkcí, ale nejsou. Proto div vyhazuje výjimku.

Souhlasíš s tímto tvrzením? Obor hodnot odpovědi je: ANO a NE.
Citace
Pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů a neobsahuje konstrukce s nedefinovaným chováním, pak v něm nelze napsat nekorektní program.
Nesmyslnýma otázkama se odmítám zabývat. Jinak odpověď je ne.

Vysvětlení, proč je kód nekorektní: Ve specifikaci funkce catch a po typové inferenci vychází, že jako první parametr očekává hodnotu typu "IO ()". To je specifikace. Implementace této specifikaci neodpovídá. Souhlas? Obor odpovědi: ANO/NE, pokud ne, tak prosím vysvětlení proč.
Úplně nevím, který parametr konkrétně myslíš, ale to je jedno. Všechno typově sedí. Kdyby nesedělo, vůbec se to nepřeloží.


Re:Rychlost Haskell vs. C++
« Odpověď #256 kdy: 03. 09. 2018, 06:18:00 »
Úplně stejný argument je, že když dereferencuju NULL pointer v C, tak ten SIGSEGV můžu taky odchytit, tudíž je to v pořádku. Jsi trotl, nebo to myslíš vážně?
Už jsem ti to psal asi 100x. Dereference NULL pointeru je UNDEFINED BEHAVIOR. NULL pointer NEMŮŽEŠ derefenrencovat, protože nemáš zaručeno vůbec nic, může se stát cokoliv. Výjimku v Haskellu chytat můžeš, protože máš zaručeno, co se stane, je to definované. Jsi opravdu tak hloupý, nebo jenom nechceš takovou základní věc pochopit?

Kdyby sis přečetl aspoň jednou to, co ti tu celou dobu píšeme, tak bys věděl, v čem se pleteš.

Vysvětlení, proč je kód nekorektní: Ve specifikaci funkce catch a po typové inferenci vychází, že jako první parametr očekává hodnotu typu "IO ()". To je specifikace. Implementace této specifikaci neodpovídá. Souhlas? Obor odpovědi: ANO/NE, pokud ne, tak prosím vysvětlení proč.
Úplně nevím, který parametr konkrétně myslíš, ale to je jedno. Všechno typově sedí. Kdyby nesedělo, vůbec se to nepřeloží.

Opravdu? Četl jsi to tu?

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #257 kdy: 03. 09. 2018, 09:57:57 »
Úplně stejný argument je, že když dereferencuju NULL pointer v C, tak ten SIGSEGV můžu taky odchytit, tudíž je to v pořádku. Jsi trotl, nebo to myslíš vážně?
Už jsem ti to psal asi 100x. Dereference NULL pointeru je UNDEFINED BEHAVIOR. NULL pointer NEMŮŽEŠ derefenrencovat, protože nemáš zaručeno vůbec nic, může se stát cokoliv. Výjimku v Haskellu chytat můžeš, protože máš zaručeno, co se stane, je to definované. Jsi opravdu tak hloupý, nebo jenom nechceš takovou základní věc pochopit?

Kdyby sis přečetl aspoň jednou to, co ti tu celou dobu píšeme, tak bys věděl, v čem se pleteš.
Hele srovnávat dereferenci NULL pointeru, o čemž standard jasně říká, že je to undefined behavior, s vyhazováním a chytáním výjimky, což ja jasně definovné, to je od tebe fail jako prase. Můžeš se to snažit okecat jak chceš, ale jasně to ukazuje na fakt, že vůbec nevíš, o čem mluvíš.

Vysvětlení, proč je kód nekorektní: Ve specifikaci funkce catch a po typové inferenci vychází, že jako první parametr očekává hodnotu typu "IO ()". To je specifikace. Implementace této specifikaci neodpovídá. Souhlas? Obor odpovědi: ANO/NE, pokud ne, tak prosím vysvětlení proč.
Úplně nevím, který parametr konkrétně myslíš, ale to je jedno. Všechno typově sedí. Kdyby nesedělo, vůbec se to nepřeloží.

Opravdu? Četl jsi to tu?
Ty nečteš, co ti píšu já.

Re:Rychlost Haskell vs. C++
« Odpověď #258 kdy: 03. 09. 2018, 10:11:34 »
Úplně stejný argument je, že když dereferencuju NULL pointer v C, tak ten SIGSEGV můžu taky odchytit, tudíž je to v pořádku. Jsi trotl, nebo to myslíš vážně?
Už jsem ti to psal asi 100x. Dereference NULL pointeru je UNDEFINED BEHAVIOR. NULL pointer NEMŮŽEŠ derefenrencovat, protože nemáš zaručeno vůbec nic, může se stát cokoliv. Výjimku v Haskellu chytat můžeš, protože máš zaručeno, co se stane, je to definované. Jsi opravdu tak hloupý, nebo jenom nechceš takovou základní věc pochopit?

Kdyby sis přečetl aspoň jednou to, co ti tu celou dobu píšeme, tak bys věděl, v čem se pleteš.
Hele srovnávat dereferenci NULL pointeru, o čemž standard jasně říká, že je to undefined behavior, s vyhazováním a chytáním výjimky, což ja jasně definovné, to je od tebe fail jako prase. Můžeš se to snažit okecat jak chceš, ale jasně to ukazuje na fakt, že vůbec nevíš, o čem mluvíš.

Tak si to tu přečti znovu. Bottom a tak, ostatní ti to tu psali hezky... ale asi je to fakt marný...

Vysvětlení, proč je kód nekorektní: Ve specifikaci funkce catch a po typové inferenci vychází, že jako první parametr očekává hodnotu typu "IO ()". To je specifikace. Implementace této specifikaci neodpovídá. Souhlas? Obor odpovědi: ANO/NE, pokud ne, tak prosím vysvětlení proč.
Úplně nevím, který parametr konkrétně myslíš, ale to je jedno. Všechno typově sedí. Kdyby nesedělo, vůbec se to nepřeloží.

Opravdu? Četl jsi to tu?
Ty nečteš, co ti píšu já.

Nesedí ti typy.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #259 kdy: 03. 09. 2018, 10:27:15 »
Tak si to tu přečti znovu. Bottom a tak, ostatní ti to tu psali hezky... ale asi je to fakt marný...
Bottom je hrozně široký pojem. Může to být nikdy nekončící výpočet, nebo taky výjimka. Výjimka v Haskellu má jasně definované chování.

Nesedí ti typy.
Hele ráno jsem si zkoušel kloubouk a neseděl mi. Překladač mi říkal, že typy jsou v pohodě a já mu věřím.


lopata

Re:Rychlost Haskell vs. C++
« Odpověď #260 kdy: 03. 09. 2018, 10:27:51 »
Ono je to stejně zajímavé, jak rozdílně může fungovat komunita. Snažím se tady upozornit, že domýšlet důsledky strict/lazy vyhodnocení v Haskellu není jednoduché a že strict <-> lazy transformace v Haskellu může změnit chování programu až tak, že bude dávat jiný výstup. Haskell komunita na to má jiný názor, prý strict -> lazy transformace změnit výstup nemůže. Tak jim člověk dá důkaz, když si ho nejsou schopni vymyslet sami (ano Haskell asi fakt není pro každého...). Následně se začnou vztekat, co jsem si to jako dovolil! Použil jsem výjimky, jak jsem mohl! No použil, mohl, Haskell to umožňuje...

Soudruzi, takhle nové zákazníky nezískáte. Máte to naprosto špatně marketingově zvládnuté. Můžu vám garantovat, že každý, kdo si tohle vlákno přečte, nebude chtít mít s Haskellem nic společného. A já ho naprosto chápu.

Propagace jazyka se dělá úplně jinak, základem je být vstřícný k začátečníkům a mít co nejvíc příkladů a best practices včetně vyčerpávající dokumentace. Haskell nemá ani jedno. Můžu srovnávat s Rustem a je to prostě úplně jinde než Haskell. Má Haskell něco podobně dobrého a podrobného jak Rust Book (https://doc.rust-lang.org/book/)?. Přístup Rust komunity je taky. Takhle si každý myslí, že ti Haskellisté jsou banda akademických nerdů, kteří si bastlí ten svůj akademický jazyk a vůbec se nevěnují potřebám a problémům bežných uživatelů.

Re:Rychlost Haskell vs. C++
« Odpověď #261 kdy: 03. 09. 2018, 10:38:15 »
Ten tvůj "důkaz" je úplně na stejné úrovni jako

Citace
a = b                                | *a
a^2 = ab                          | + a^2 - 2ab
2a^2 - 2ab = a^2 - ab
2(a^2 - ab) = a^2 - ab    | : (a^2 - ab)
2 = 1

Pokud ti to přijde ok, o něčem to vypovídá.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #262 kdy: 03. 09. 2018, 11:06:12 »
Ten tvůj "důkaz" je úplně na stejné úrovni jako
Ne není. A tahle věta co jsem napsal, má stejnou vypovídající hodnotu (nulovou), jak tvůj předešlý příspěvěk. Vy jste fakt banda akademických nerdů, kterým nechochází úplně základní praktické věci.

Re:Rychlost Haskell vs. C++
« Odpověď #263 kdy: 03. 09. 2018, 11:09:39 »
Možná kdyby sis přečetl, co jsme ti tu psali... Nenapadlo tě, že to možná nedochází tobě...?

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #264 kdy: 03. 09. 2018, 11:38:09 »
Možná kdyby sis přečetl, co jsme ti tu psali... Nenapadlo tě, že to možná nedochází tobě...?
Možná kdyby sis přečetl, co jsem ti tu psal? Už je ti jasný rozdíl mezi dereferencováním NULL pointeru a chytáním výjimky? Nenapadlo tě, že to možná nedochází tobě?

Re:Rychlost Haskell vs. C++
« Odpověď #265 kdy: 03. 09. 2018, 11:47:31 »
Možná kdyby sis přečetl, co jsme ti tu psali... Nenapadlo tě, že to možná nedochází tobě...?
Možná kdyby sis přečetl, co jsem ti tu psal? Už je ti jasný rozdíl mezi dereferencováním NULL pointeru a chytáním výjimky? Nenapadlo tě, že to možná nedochází tobě?

A "rozdíl" mezi undefined behavior a bottom ti je taky jasný? Typy taky sedí? Nebo ty blbosti natáhneš i na 19. stránku?

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #266 kdy: 03. 09. 2018, 11:53:29 »
A "rozdíl" mezi undefined behavior a bottom ti je taky jasný? Typy taky sedí? Nebo ty blbosti natáhneš i na 19. stránku?
Mně ten rozdíl jasný je, tobě ne. Výjimka v Haskellu NENÍ undefined behavior. Nerozumím tomu, proč tak jasnou věc nejsi schopen pochopit? Není to přece žádná složitá věda?

andy

Re:Rychlost Haskell vs. C++
« Odpověď #267 kdy: 03. 09. 2018, 16:25:53 »
Haskell je matematický zápis. Například následující v R:
Kód: [Vybrat]
sqrt(-3)je nekorektní. Je to stejně nekorektní, jako třeba:
Kód: [Vybrat]
sqrt("hello world")Proč? Protože funkce druhá odmocnina má definiční obor (v R) "x v R, x >= 0". To znamená, že když napíšeš něco z toho výše, tak je to prostě nesmysl. A je úplně jedno, jestli ten program se následně chová deterministicky nebo ne. Je prostě blbě. Formálně blbě a věcně blbě.
To je právě tvůj problém, že tyhle dvě rozdílné věci nerozlišuješ. sqrt je stejně jako div funkce definovaná pro nějaká čísla. Pro čísla to (většinou) funguje. Pro stringy to nefunguje nikdy. Správně bys měl pro div zadefinovat typ, kde druhý argument by mohlo být jakékoliv číslo kromě 0.
Přesně!
Citace
Jenže to tak není udělané. Funkce div vyhazuje výjimku, když je dělitel 0. Takže sqrt(-3) typ sedí, protože nemáme typ kladná čísla, máme jen typ reálná čísla.
Nebo jinými slovy: typový systém, který se snaží zabránit nekoretkním programů, propustí nekorektní program. Protože to je obecně nerozhodnutelný problém...
Citace
Stejně tak div(1, 0) typ sedí, protože nemáme typ integer čísla mimo 0. Žádná typová chyba tam není. Bylo by hezké, kdyby byly typy definované přesně pro definiční obory všech funkcí, ale nejsou. Proto div vyhazuje výjimku.
Hele, napadlo tě, že typový systém může propustit nekorektní program? Nebo naopak zabránit korektnímu programu, aby prošel?

Citace
Souhlasíš s tímto tvrzením? Obor hodnot odpovědi je: ANO a NE.
Citace
Pokud jazyk obsahuje deterministické a plně specifikované rutiny pro handling nekorektních stavů programů a neobsahuje konstrukce s nedefinovaným chováním, pak v něm nelze napsat nekorektní program.
Nesmyslnýma otázkama se odmítám zabývat. Jinak odpověď je ne.
Ne, ty se nehodláš zabývat otázkama, které by jaksi ukázaly tvou nekonzistenci. Prostě na to nemáš.

Jinak pokud bych do té věty teda dodal, že ten program splňuje požadavky zákazníka, tak by odpověď byla ano?

Citace
Vysvětlení, proč je kód nekorektní: Ve specifikaci funkce catch a po typové inferenci vychází, že jako první parametr očekává hodnotu typu "IO ()". To je specifikace. Implementace této specifikaci neodpovídá. Souhlas? Obor odpovědi: ANO/NE, pokud ne, tak prosím vysvětlení proč.
Úplně nevím, který parametr konkrétně myslíš, ale to je jedno. Všechno typově sedí. Kdyby nesedělo, vůbec se to nepřeloží.
To není pravda, stačí dát "-fdefer-type-check" a přeloží... je ten přeložený program, který má blbě typy korektní nebo ne? Ty si fakt myslíš, že fakt, že to projde překladačem, říká něco o korektnosti programu?? Kde jsi na takovou blbost přišel?

Citace
Mně ten rozdíl jasný je, tobě ne. Výjimka v Haskellu NENÍ undefined behavior. Nerozumím tomu, proč tak jasnou věc nejsi schopen pochopit? Není to přece žádná složitá věda?
Protože v haskellu není behaviour.... v haskellu jsou pouze výrazy, které nemají behaviour.... ale to je židle, budeš opakovat furt to samý....

andy

Re:Rychlost Haskell vs. C++
« Odpověď #268 kdy: 03. 09. 2018, 16:41:13 »
A jinak teď konkrétně, proč je to blbě: Typový systém je (mimo jiné) od toho, aby dokázal zabránit některým nežádoucím stavům programu. Vzhledem k tomu, že to je obecně nerozhodnutelný problém, tak ve výsledku některé korektní programy nepropustí, nebo naopak některé nekorektní programy projdou. Třeba v Liquid haskellu bys možná u toho sqrt mohl vynutit, aby to bylo pouze pro pozitivní čísla (nejsem si úplně jistý, jestli umí s floatama, ale pro celá čísla by to měl umět). Jaký je teda rozdíl mezi "sqrt(-3)", který kompiler odmítne, protože už předem zjistí, že to není definovaná hodnota - a "sqrt(-3)", které spadne až za běhu, protože to kompilerem prošlo? Jak je možné, že to první je "nekorektní program", to druhé "korektní program", přitom se to akorát liší schopnostma překladače?

Jazyky, které mají totality checking by přesně tenhle program vyhodily jako nekorektní. Protože jsou schopny v typovém systému postihnout "non-termination". Haskell to neumí, takže ten program projde typovým systémem a selže až při běhu. Úplně stejně, jako ti projde typová chyba, když tomu dáš "-fdefer-type-check". Non-termination je bug. Undefined behaviour to není, protože haskellové programy nemají "behaviour". Behaviour má akorát tak ten "IO engine", který ty IO akce spouští.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #269 kdy: 03. 09. 2018, 17:10:11 »
Hele to je strašně dlouhé a teoretizuješ o ničem. Kdyby Haskell uměl zajistit, že argumenty funkcí budou jen v definičním oboru funkcí, třeba typovým systémem, možná bychom se mohli bavit o tom, co jsi napsal. Jenomže Haskell to zajistit NEUMÍ. To znamená, že nemáš žádné záruky.

Použil jsem knihovní funkci div, která ti žádné typové záruky nedává. Dělení nulou řeší jako výjimku. To je celé. Souhlasím, že design toho programu není dobrý. Ale to nebylo cílem. Cílem bylo ukázat, že program v Haskellu může záviset na strict vyhodnocení, což platí. Bez ohledu na nějaké hypotetické typové záruky, které v Haskellu nemáš.