Příspěvky

1951

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 17. 09. 2019, 23:56:08 »

A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.

třeba jedno rozšíření Haskellu ověřuje platnost podmínek ohledně (endo)funktorů, které běžný překladač prostě ignoruje.

Měl by si hint?

Tohle je stravitelnější: http://kindsoftware.com/documents/reports/Green10.pdf

1952

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 17. 09. 2019, 23:33:55 »

A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.

třeba jedno rozšíření Haskellu ověřuje platnost podmínek ohledně (endo)funktorů, které běžný překladač prostě ignoruje.

Měl by si hint?

http://www.cse.chalmers.se/~peterd/papers/TestingModelChecking.pdf

1953

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 17. 09. 2019, 20:55:51 »

A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.

Také existuje formální verifikace (při překladu), kdy se ověřují různé invarianty pomocí symbolických dokazovačů (theorem provers), třeba jedno rozšíření Haskellu ověřuje platnost podmínek ohledně (endo)funktorů, které běžný překladač prostě ignoruje. Problém s takovouto verifikací je, že naučit se ji používat je samo o sobě náročné (nemluvě o pochopení implementace). V této inherentní složitosti je podobná závislostním typům, u kterých si také málokdo z fleku představí, proč jsou o řád lepší než běžná typová kontrola.

1954

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 17. 09. 2019, 16:50:32 »

Vecko sa da otestovat.

Třeba souběh (race condition) se otestovat moc nedá.

Jednotkově ne, ale existují metody pro ověření při překladu i běhu, třeba Go je pro své gorutiny používá.

1955

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 17. 09. 2019, 16:49:20 »

Vecko sa da otestovat.

“Vécko” určitě, Java a PHP k němu pasují nejlépe 

1956

/dev/null / Re:Jak si uzivate sluzebni cesty s brzkym vstavanim z postele?

« kdy: 15. 09. 2019, 23:15:01 »

Co je “těžká duševní práce”?

1957

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 15. 09. 2019, 11:28:04 »

Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.

Soubory, sockety a další alokované prostředky neřeší GC, ale destruktory, které se aktivují ihned po zrušení deskriptoru na objekt. GC se aktivuje až když dochází volná paměť. Takhle to funguje alespoň ve slušně napsaných jazycích.

O kterém jazyce je teď řeč? Třeba Java AFAIK destruktory nemá. A soubory se v ní musí uklízet ručně, aby nezůstávaly viset než se GC probere.

Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.

No tak nějaký všežravý catch blok v main loopu je zrovna dost pochybný obrat. Ok, chytnu v něm nějakou nečekanou výjimku. Je pravděpodobně nečekaná, protože očekávanou bych chytl nějakým cíleným catchem. Nevím o ní nic, takže ji můžu akorát tak zalogovat. Co vím o stavu programu? Akorát to, že se mi nečekaně přerušil nějaký kus kódu před dokončením. Co vím o invariantech? Ta výjimka byla nečekaná, takže klidně mohla vyletět v momentě, kdy byly invarianty rozbité.
Jediný způsob, jak se v takovém případě dostat do známého stavu, je zahodit úplně všechno a začít odznova. To už můžu místo toho použít nějaký výrazně jednodušší watchdog proces.

Všežravý catch blok je code smell, ale aspoň může říct, že program nepadá.

1958

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 15. 09. 2019, 11:25:35 »

Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.

Soubory, sockety a další alokované prostředky neřeší GC, ale destruktory, které se aktivují ihned po zrušení deskriptoru na objekt. GC se aktivuje až když dochází volná paměť. Takhle to funguje alespoň ve slušně napsaných jazycích.

O kterém jazyce je teď řeč? Třeba Java AFAIK destruktory nemá. A soubory se v ní musí uklízet ručně, aby nezůstávaly viset než se GC probere.

Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.

No tak nějaký všežravý catch blok v main loopu je zrovna dost pochybný obrat. Ok, chytnu v něm nějakou nečekanou výjimku. Je pravděpodobně nečekaná, protože očekávanou bych chytl nějakým cíleným catchem. Nevím o ní nic, takže ji můžu akorát tak zalogovat. Co vím o stavu programu? Akorát to, že se mi nečekaně přerušil nějaký kus kódu před dokončením. Co vím o invariantech? Ta výjimka byla nečekaná, takže klidně mohla vyletět v momentě, kdy byly invarianty rozbité.
Jediný způsob, jak se v takovém případě dostat do známého stavu, je zahodit úplně všechno a začít odznova. To už můžu místo toho použít nějaký výrazně jednodušší watchdog proces.

Java má using jako C#, jen se jmenuje stupidně try, aby se hned nepoznalo, jak se opičí.

1959

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 14. 09. 2019, 23:57:21 »

Zásadní problém výjimek je IMO právě to, že jsou oddělené od výkonného kódu a nejsou vidět.
Při pohledu na cizí kód nevím, co může a nemůže házet.

+1

Chtělo by to něco do syntaxe, kterou by se dalo jasně specifikovat jaké výjimky to může házet. Skutečnost v Javě, kdy musíš definovat co ti to vrátí za výsledek, ale nemusíš definovat co ti to háže za výjimky mi přijde takové nekonzistentní.

Ono také záleží na tom, jaké výjimky mohou nastat. Force majeure (například “file not found” nebo “out of memory”) se nedá předpokládat (=odchytit při typové kontrole), kdežto takové “index out of bounds” není force majeure, protože to umí eliminovat závislostní typy. Čím méně výjimek je přípustných, tím snazší je explicitně je specifikovat. Otázka pak jen je, jestli má smysl se s nimi otravovat, když kombinace silného (závislostního) systému a maybe pro nepředvídatelné výjimečné situace vede k přehlednějšímu kódu.

1960

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 14. 09. 2019, 20:55:09 »

Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.

To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.

Dvojice se používají např. v Golang. V C++ a Javě vy to působilo poněkud nepatřičně.

V Javě působí nepatřičně všechno. Ale C++ má n-tice přímo v syntaxi. I když lepší je použít optional nebo něco podobného, to je přímo v STL.

1961

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 14. 09. 2019, 17:15:58 »

Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.

V Javě jsou zvykem výjimky, dělal bych to tedy výjimkami. Ne proto, že by to byla nějaká zvláštní výhra, ale protože je to tam zvykem.
C++ nedělám, to je hnusnej jazyk.

Je možno si všimnout, že mnoho, zvláště staticky typovaných jazyků, používají návratovou hodnotu. Mnoho dalších jazyků používá výjimky. Šermovat tu s CleanCode a brát výjimky jako písmo svaté je poněkud... nezkušené.

C++ a Java jsou staticky typované? Skaláry možná, ale objekty jsou typované dynamicky.

Ty v tom máš slušný guláš. Tak jo, C++ je dynamicky typované a Zeman není dementní alkoholik.

1962

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 14. 09. 2019, 16:51:40 »

Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.

O monádách jsi už slyšel? 

Ano, slyšel. A také jsem slyšel, že Maybe je izomorfní s výjimkami.

Tak proč se ptáš?

Přečti si diskuzi. Používám výjimky tam, kde mají být. Někteří diskutující píší, že by se neměly používat, protože jsou drahé, že by se měly používat návratové hodnoty. Z mého pohledu jen s výjimkami neumí pracovat.

Je snad logické, že se jich ptám, jak by to tedy řešili v C++ a Javě, kdyby nesměli výjimky používat. Nabízí se mi pouze kostrbatá řešení, které buď používají, anebo mají něco lepšího.

Máš selektivní slepotu na Maybe? Vždyť ti to tu píšou furt dokola.

1963

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 14. 09. 2019, 16:21:43 »

Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.

O monádách jsi už slyšel? 

Ano, slyšel. A také jsem slyšel, že Maybe je izomorfní s výjimkami.

Tak proč se ptáš?

1964

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 14. 09. 2019, 16:08:11 »

Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.

O monádách jsi už slyšel? 

1965

Studium a uplatnění / Re:Hledám knihy: Myslíme v C++ a v Javě

« kdy: 14. 09. 2019, 12:19:35 »

Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?

Jenže ty ho můžeš vrátit a parametry lze samozřejmě předávat odkazem.

Už nejsme ve 20. století. Tyto archaismy do moderního programování nepatří.

Co sis šlehnul?