Příspěvky

481

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 02. 09. 2018, 10:49:58 »

Je v něm typová chyba: vrací se bottom tam, kde se očekává typ, který bottom neobsahuje. Haskell tento typ chyby není schopen odhalit při překladu, slítne to v runtimu.

Neslítne to. Haskell language report někde říká, že když se vrátí bottom, je to nedefinované chování? Neříká. Vyhodí to ArithException, která se dá chytit. Haskell to umožňuje a je to definované chování. Já chápu, že se ti nelíbí, jak je to udělané a že tu výjimku chytám. Mně se to taky nelíbí, dělám to z toho důvodu, protože jsi tvrdil, že v Haskellu nemůže existovat program, který závisí na strict vyhodnocení. Může.

Ú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ě?

De facto jsi napsal program, který jde popsat takto "jsi-li ve strictu, vrať toto, jinak spadni/vypiš toto", pointou ale je, že ti minimálně nesedí typy...

482

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 31. 08. 2018, 10:23:03 »

Ten důkaz 0=1 nesplňuje základní podmínku: Není korektní podle MĚ. Fakt?

Ten tvůj “důkaz" je úplná blbost a nijak nesouvisí s chytání výjimky při dělení nulou v Haskellu. Nechápu, proč takové nesmysly píšeš?

Právě že souvisí A až to pochopíš, tak taky pochopíš, proč celé vlákno píšeš kraviny.

483

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 30. 08. 2018, 23:04:04 »

Ty s tím nedáš pokoj, i když ti tu bylo stokrát vysvětleno, v čem máš chybu?

484

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 30. 08. 2018, 14:56:58 »

Tak teď jsem opravdu zvědavý na odpověď.

485

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 30. 08. 2018, 07:12:42 »

Závisí na tom, že spadne.

Definuj spadne.

Jako vážně?

Může reálně nastat, že někoho napadne udělat podobnou věc? Může.

To není argument.

To je velmi silný argument. Nevím, jestli jsi někdy vyvíjel v týmu nebo přebíral cizí kód. Opravdu by ses divil, co se dá vymyslet za prasárny.

Jenže s takovým přístupem se dá zneužít cokoliv, tudíž je irelevantní na tom stavět kritiku. Židle je špatná, protože někoho může napadnout s ní mlátit lidi... úplně stejně validní.

Zaručuje Haskell, že výsledek strict a lazy vyhodnocení bude stejný? Nezaručuje.

O tomto nikdo nemluví (a není to ani otázka Haskellu). Řeč byla o tom, že kód napsaný v Haskellu striktně (ne)pojede v lazy.

Težko se s tebou bavit, když používáš termíny jako nepojede. Pod tím si můžeš představit cokoliv. Máš nějaké předpoklady o výstupu a tomu skutečný výstup buď opovídá, nebo ne.

Nepojede - nebude fungovat, v tomto kontextu. Zatím jsme se dostali jen k ukázkám kódu, které jsouna úrovni dereference NULL pointeru v C. Teď už jen abys to pochopil...

Musím se rozdíly mezi strict a lazy vyhodnocením zabývat, když chci ho převzít cizí kód? Musím, protože se nemůžu spoléhat na to, že někdo nevymyslí podobnou prasárnu.

A ty přebíráš někdy kód bez toho, aniž by ses podíval, co přebíráš? 
Jinak sorry, ale to není argument, stejně můžu napsat: Musím se zabývat tím, co je a co není "undefined behavior" v C, když chci převzít cizí kód? Musím, protože...

Samozřejmě se musíš zabývat undefined behavior v C, stejně jako se musíš zabývat rozdíly strict versus lazy vyhodnocení v Haskellu, to je jasná věc.

Takže jsme došli k tomu, jak validní argument to byl... pěkné

Jo, rád bych věděl, jestli jen trollíš, nebo jo...

Tady trolí úplně všichni.

Ne, kupodivu jsou tu i tací, co se snaží pomáhat nebo diskutovat...

486

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 29. 08. 2018, 23:30:40 »

Závisí. Máš tam logický vztah "bottom -> není dělitelné". Bottom je non-observable, tak by ses k tomu tak měl chovat

To není undefined behavior. Jen jsem zadefinoval, že případ dělení se řeší voláním error a error má definované chování. V Haskellu error observable je, jak jsi sám postoval před chvíli: A call to error terminates execution of the program and returns an appropriate error indication to the operating system. Je to prasárna, ale není to undefined.

Zase si pleteš pojmy a dojmy? Možná si přečti, co se ti tu snažíme celou dobu vysvětlit...

487

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 29. 08. 2018, 23:28:03 »

Závisí ten můj kód někde na undefined behavior? Nezávisí.

Závisí na tom, že spadne.

Dělá věci tak, jak by se normálně dělat měly? Nedělá.

Aspoň že se přiznáš.

Může reálně nastat, že někoho napadne udělat podobnou věc? Může.

To není argument.

Zaručuje Haskell, že výsledek strict a lazy vyhodnocení bude stejný? Nezaručuje.

O tomto nikdo nemluví (a není to ani otázka Haskellu). Řeč byla o tom, že kód napsaný v Haskellu striktně (ne)pojede v lazy.

Musím se rozdíly mezi strict a lazy vyhodnocením zabývat, když chci ho převzít cizí kód? Musím, protože se nemůžu spoléhat na to, že někdo nevymyslí podobnou prasárnu.

A ty přebíráš někdy kód bez toho, aniž by ses podíval, co přebíráš? 
Jinak sorry, ale to není argument, stejně můžu napsat: Musím se zabývat tím, co je a co není "undefined behavior" v C, když chci převzít cizí kód? Musím, protože...

Máš ještě v něčem zmatek a potřebuješ to dále vysvětlit? Rád ti pomohu. Mám docela trpělivost a věřím, že jsi schopný to pochopit a nakonec to dáš.

Jo, rád bych věděl, jestli jen trollíš, nebo jo...

488

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 29. 08. 2018, 23:02:06 »

Naopak, jde vidět, že ví, o čem mluví. Zatím jsi mimo spíš ty - minimálně co se Haskellu týče nás o tom přesvědčuješ celé vlákno.

Kecy v kleci.

Si to přečti

Ne, chci vidět příklad kódu, který funguje korektně ve strict režimu a jeho vypnutím (tj. "s výchozím" lazy evaluation) přestane fungovat (obávám se, že to není možné). Zatím jsi ukázal kód, který 1) to měl obráceně 2) nebyl funkční.

https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-230003.1
A call to error terminates execution of the program and returns an appropriate error indication to the operating system.

Někomu se tu teď zhroutil svět 

Tak tady máš ten kód, který funguje ve strict režimu a v lazy ne:

Kód: [Vybrat]

spoooooousta hnusných věcí

Takže mi chceš říct, že jako příklad korektního kódu je podle tebe kód, který rozhoduje na základě toho, zdali se k vykonávání řádku dostaneme, nebo chcípneme po cestě?

nevím, jestli jsi měl někde vyčíslitelnost

Z vlákna soudím, že nikoliv.

489

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 29. 08. 2018, 20:52:32 »

Ne, chci vidět příklad kódu, který funguje korektně ve strict režimu a jeho vypnutím (tj. "s výchozím" lazy evaluation) přestane fungovat (obávám se, že to není možné).

Nestačí pouhé

Kód: [Vybrat]

foldl (+) hodneDlouhySeznamCisel

?

To vybuchne na stack overflow.

To je zajímavá myšlenka, ale ne. Ano, lazy evaluation je žravější, tudíž může vést častěji k nedostatku systémových prostředků, ale není to "rozbití" jakožto spíše "nešikovnost programátora." (hned mne napadlo srovnání s nevhodnou rekurzivní funkcí -> rekurze to rozbije)
Měl jsem namysli případ v kontextu diskuse, tedy pod strictem něco funguje a s lazy to fungovat přestane, resp. změní to chování/výstup (stack overflow je spíš nešikovnost autora).

Ale děkuji za snahu

490

Windows a jiné systémy / Re:Koupit Macbook Pro 2015 nebo 2018?

« kdy: 29. 08. 2018, 19:56:14 »

Jednoznačně 2015. Mám osobní zkušenosti s 2015 a 2017, ale pokud vím tak v modelu 2018 žádný průser nevyřešili.

Ale jo, pod klávesy strčily membránu, tudíž už by neměly odcházet kvůli prachu... ale samozřejmě to tam dali proto, aby ten zážitek z inovativní klávesnice byl ještě tišší... 

491

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 29. 08. 2018, 19:46:55 »

Všechny implementace při volání error provedou něco, podle čeho můžeš identifikovat, co máš v programu špatně. A žádná ani v principu nemůže provést něco, co bys chtěl aby se stávalo u zákazníka. Jestli při volání error program vypíše něco do konzole, segfaultuje, nebo zatuhne a zabije ho watchdog je na zákaznickém stroji +- putna. Není to úplně identické, ale nějaký zásadní rozdíl v tom není.

Sorry, ale jsi úplně mimo. Vůbec nemáš ponětí o řízení kvality a o tom, jak nasazovat a provozovat aplikaci u zákazníka. Pokud aplikace u zákazníka spadne, tak chci sakra co nejrychleji a co nejpodrobněji vědět, co se stalo a proč. Protože zákazník na mě bude řvát, že mu to nefunguje a že mi nezaplatí. Zákazníka vůbec nezajímá, že ty si myslíš, že je +- putna co to dělá na jeho stroji. On chce, aby to fungovalo.

Naopak, jde vidět, že ví, o čem mluví. Zatím jsi mimo spíš ty - minimálně co se Haskellu týče nás o tom přesvědčuješ celé vlákno.

Hlavně pořád bychom rádi viděli případ, kdy lazy evaluation rozbije strict kód...

Definuj rozbije. Dostaneš jiný výstup.

Ne, chci vidět příklad kódu, který funguje korektně ve strict režimu a jeho vypnutím (tj. "s výchozím" lazy evaluation) přestane fungovat (obávám se, že to není možné). Zatím jsi ukázal kód, který 1) to měl obráceně 2) nebyl funkční.

https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-230003.1

A call to error terminates execution of the program and returns an appropriate error indication to the operating system.

Někomu se tu teď zhroutil svět 

492

Windows a jiné systémy / Re:Koupit Macbook Pro 2015 nebo 2018?

« kdy: 29. 08. 2018, 19:39:42 »

Pokud bych kupoval Macbook Pro 15" 16GB RAM 2015 tak jedine repas. I kdyz je novy (se zarukou) je desne drahy. Ty nove macbooky me hrozne stvou chybejicim magsafe, debilni klavesnici, a hlavne chybejicicim sviticim jabkem

a nezapomínej na touchbar...

493

Windows a jiné systémy / Re:Koupit Macbook Pro 2015 nebo 2018?

« kdy: 29. 08. 2018, 15:14:41 »

2015 Je haswell zroku 2013, jeho cena se pohybuje mezi 20-30000Kč, čtyřjádro.
Příjde mi úchylné za to dát 30 klacků navíc, je to vlastně model late 2013 + lepší grafika + force touchpad (kravina jako touchbar)

a dát dalších 30 klacků (tedy za cenu 3 notebooku) za mít možnost tentokrát konečně novějšího apple, stále má mizerné chlazení jako 2013 modely. Samozřejmě nepopírám špičkový LCD, ale to je asi tak vše. a USB-C je diskutabilní.

Prostě je to předražené

https://www.datart.cz/Notebook-APPLE-MacBook-Pro-15-Ret-i7-2-2GHz-16G-256FS-CZ.html?utm_source=dooce.com&utm_medium=magor&utm_campaign=ignorant&utm_term=dylina

Pletes se, kupoval bych kdyz uz tak jedine Dell a to prinejmensim Latitude, odmitam mit za 2-3 roky notebook na rozpadnuti. A na jejich ceny se podivej sam:

https://www.czc.cz/notebooky/produkty?q-c-1-producer=s5fp7k911hgctq929de6mhsvj5e&q-c-0-f_135417054=s8750H(2.2%2F4.1GHz%206jader%2F12vl%C3%A1ken)&q-c-3-f_2029058=s3840%20x%202160%20(UHD%204K)&q-c-2-f_2029058=s2560%20x%201440%20(WQHD)

Zenbooky, XPSka... několik modelů, několik let a schytal to pouze jeden starší ZenBook - vylomené panty po více než dvou letech "tvrdé šikany"

A takovy Dell IPS neni ani nahodou levnejsi nez Macbook.

Mno to možná ne, ale je to trochu jiný stroj... disk můžu vyměnit doma, klávesnice je lepší, displej taky (matný!), atd.

494

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 29. 08. 2018, 13:03:41 »

Hlavně pořád bychom rádi viděli případ, kdy lazy evaluation rozbije strict kód...

495

Vývoj / Re:Rychlost Haskell vs. C++

« kdy: 28. 08. 2018, 23:02:11 »

Tak Andy a Cikádo, času jste měli dost, ale nedali jste to. Haskell asi opravdu není pro každého. Dám vám něco k přemýšlení:

Kód: [Vybrat]

{-# LANGUAGE ScopedTypeVariables #-}

import Control.Exception

myDiv :: Float -> Float -> Float
myDiv x 0 = error "Division by zero"
myDiv x y = x / y

main = catch 
          (do
               let a = myDiv 1 0
               putStrLn "Předpověď: zítra BUDE krásné počasi"
          )
          (\(err :: SomeException) -> putStrLn "Předpověď: zítra NEBUDE krásné počasi")

Lazy:

Kód: [Vybrat]

ghc -O2 test.hs
./test
Předpověď: zítra BUDE krásné počasi

Strict:

Kód: [Vybrat]

ghc -O2 -XStrict test.hs
./test
Předpověď: zítra NEBUDE krásné počasi

Když odhlédneme od toho, že jde o stejný příklad jako předtím, jen místo error používáš výjimky, tak pořád nevidím příklad, kdy lazy evaluation rozbije strict kód. Ale ano, máš pravdu, že Haskell (a programování obecně) není pro každého.