Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - BoneFlute

Stran: 1 ... 32 33 [34] 35 36 ... 133
496
No jo no, to už jsou ale zase ty monády. A ani to není moc hezký.

Možná, abych se lépe vyjádřil:

Rozhodně očekávám, že když mi kompilátor přeloží kód, tak že mi zajistí, že všechny chybové stavy jsou pokryty. Což pochopitelně Result splňuje.

Jenže stejně jako od jazyka očekávám, že si validitu vstupů nebudu hlídat sám, ale že mi to bude hlídat jazyk - třeba pomocí typů; tak stejnou logikou očekávám, že mi jazyk usnadní práci s chybami. A ne, že si to budu řešit sám pomocí jiných konstruktů jazyka.

Pořád moc nerozumím. Rust se rozhodl, že ošetření chyb bude dělat pomocí složených typů. Určitě je možné, že práce s nimi může být náročnější, než třeba použití try-catch, ale oč je - v principu - horší řešení pomocí typového systému, než je (poměrně násilný, řekněme) způsob pomocí výjimek?

Rust transformuje data, je třeba si podle toho strukturovat aplikaci. Těch způsobů, jak řešit vícero Error typů na jednom místě je více - třeba pomocí wrapperů. Je s tím zase nějaká práce, nemyslím, že to je tak zlé. Je to jako se vším v Rustu nebo jinde. Musíš tancovat s tím, co má v repertoáru a ne si chtít dělat svoje pogo, když se jede lambada.

Já ale nekritizuju Rust. Rust je skvělej jazyk a mám ho moc rád.

497
No jo no, to už jsou ale zase ty monády. A ani to není moc hezký.

Možná, abych se lépe vyjádřil:

Rozhodně očekávám, že když mi kompilátor přeloží kód, tak že mi zajistí, že všechny chybové stavy jsou pokryty. Což pochopitelně Result splňuje.

Jenže stejně jako od jazyka očekávám, že si validitu vstupů nebudu hlídat sám, ale že mi to bude hlídat jazyk - třeba pomocí typů; tak stejnou logikou očekávám, že mi jazyk usnadní práci s chybami. A ne, že si to budu řešit sám pomocí jiných konstruktů jazyka.

498
Podle vkusu každého soudruha, třeba takhle nějak:

Kód: [Vybrat]

Přesněji teda ale:

Kód: [Vybrat]
    if safe_divide(count_of_files("/etc")? + count_of_files("/home")?, count_of_files("/tmp")?)? == 0 {
    }

Tak tohle už se dá číst. Ale obávám se, že ty otazníčky jen zabrání chcípnutí. Jaká chyba a podrobnosti z toho vytáhnout nejde, že?

Kód: [Vybrat]
fn main() -> Result<()>{
    let hausn: usize = hausnumero(count_of_files("AAA").context("First dir")?,
                                  count_of_files("BBB").context("Second dir")?,
                                  count_of_files("CCC").context("Third dir")?)?;
    println!("Result: {}", hausn);
    Ok(())
}
No jo no, to už jsou ale zase ty monády. A ani to není moc hezký.

Já vím, že se dá ten Result zabalit do funkce, která to celé zpracuje jako výraz a sama vrátí Result. V principu je to pak jako try-catch. Ale není to hezké, a je to dost matoucí. Zatím mě přijde, že když to umí jazyk, že je to takové šikovnější. Ale kritika výjimek mě zajímá. Idris zmínil, že je pak těžší zajistit typovou bezpečnost, ok.

499
Rust jsem uváděl jako příklad jazyka s hezkými chybovkami, ale výjimky nemá. A já jsem se z počátečního nadšením nad Maybe/Result vystřízlivěl zase zpět k výjimkám.

Asi jsi chtěl napsat Either/Result. Co přesně Tě vedlo k "vystřízlivění"? Na ergonomii práce s Result (Error) se udělal kus práce - viz třeba crate anohow.
Zde jsem možná nedovzdělán. Jak by si přepsal následující kód:
Kód: [Vybrat]
if (((countOfFilesIn(dir1) + countOfFilesIn(dir2)) / countOfFilesIn(dir3)) == 0) { ... }
Dělení nulou, špatná cesta, odmítnuté právo pro čtení z adresáře.

500
Domníváš se, že Efekty nejsou lepší řešení takovýchto záležitostí? Nic nebrání, aby to bylo součástí signatury. Jen ta informace teče jinudy - cukr. Řekl bych.
Je to v podstatě to samé, prašť jako uhoď. A furt to je složité, běžný Franta to nepobere. V praxi je nejlepší co nejjednodušší jazyk, aby v něm nešla páchat zvěrstva :) FP je v podstatě pro fajnšmekry, kteří jsou schopní si napsat vlastní překladač, takže do detailu vědí, kudy v programu tečou data.

Já chci jazyk, který mě nepustí udělat chybu. Je mi jedno, zda to bude jednoduchostí, nebo díky AI.
Za druhé chci, aby když dělám něco špatně, tak abych to byl schopen z té chybovky pochopit ("no jo, text místo čísla, jasný").

Navrhnout jednoduchý jazyk je jednoduché (Lua, Python) - stačí vyrazit typy. Napsat jazyk, kterej mě bude hlídat, a přitom budu produktivní, to už je jinej kumšt (Rust).
Ten Rust to ale splňuje, tak kde je problém? Ono i moderní C++ (C++20) je na tom podobně. Na neexistenci rozumného jazyka bych si nestěžoval.

Rust jsem uváděl jako příklad jazyka s hezkými chybovkami, ale výjimky nemá. A já jsem se z počátečního nadšením nad Maybe/Result vystřízlivěl zase zpět k výjimkám.

501
Domníváš se, že Efekty nejsou lepší řešení takovýchto záležitostí? Nic nebrání, aby to bylo součástí signatury. Jen ta informace teče jinudy - cukr. Řekl bych.
Je to v podstatě to samé, prašť jako uhoď. A furt to je složité, běžný Franta to nepobere. V praxi je nejlepší co nejjednodušší jazyk, aby v něm nešla páchat zvěrstva :) FP je v podstatě pro fajnšmekry, kteří jsou schopní si napsat vlastní překladač, takže do detailu vědí, kudy v programu tečou data.

Já chci jazyk, který mě nepustí udělat chybu. Je mi jedno, zda to bude jednoduchostí, nebo díky AI.
Za druhé chci, aby když dělám něco špatně, tak abych to byl schopen z té chybovky pochopit ("no jo, text místo čísla, jasný").

Navrhnout jednoduchý jazyk je jednoduché (Lua, Python) - stačí vyrazit typy. Napsat jazyk, kterej mě bude hlídat, a přitom budu produktivní, to už je jinej kumšt (Rust).

502
V hlavách bych neškrtal, vždyť ten null se občas hodí.

Co se na tomto hodí? >:(
Kód: [Vybrat]
[TestMethod]
public void Test()
{
Print(null);
}

private void Print(Foo x)
{
System.Console.WriteLine(x.GetType());
}

Tohle beru:
Kód: [Vybrat]
[TestMethod]
public void Test()
{
Print(null);
}

private void Print(int? x)
{
if (x != null) {
System.Console.WriteLine(x.GetType());
}
}

503
Jsem silně poznamenaný funkcionálním programováním a způsob ošetřování chyb v Go se mi extrémně nelíbí.

V žádném jazyce, co má rozumné součtové typy a pattern matching, jsem neviděl že by někdo vracel chyby tuplem. Ono to nedává smysl. Obvyke nechci vrátit hodnotu A chybu, ale hodnotu NEBO chybu. Go mě nutí aby každý typ měl nějakou defaultní/prázdnou/nesmyslnou hodnotu, kterou můžu vrátit v případě chyby, i když jinak není k ničemu a ani nedává smysl.
To je otázka zvyku a nedostatku představivosti.

Haskelliho Maybe/Either taky není jen hodnota. Vždycky vracíš dvojici. V Go to prostě udělali bez typu. Může se ti to nelíbit, může se mi to nelíbit, ale principielně je to prašť jak uhoď - v porovnání s výjimkama.
Zrovna Maybe/Either je implementačně to, co v Go interface{}, ale ono jde spíš o koncept. Ono ale není tak snadné rozumně spojit podtypový polymorfismus a generické typové operátory, mám čerstvou zkušenost s implementací a je to peklo, ten typový systém vždycky někde kulhá, není třeba sound, potřebuje podporu v runtimu apod. Po takové zkušenosti se člověk nediví, že v Javě je typový systém tak tupý, ono totiž každé jeho rozšíření přináší bolehlav.
Java je stará věc. Člověk to chápe.
Jenže pak vyšel C# a člověk se zděšením zjišťuje, že je to úplně stejná záležitost. V ničem není vidět ty desítky let zkušeností a vývoje.
A pak narazíš na kód a zjišťuješ, že i to C# je pro mnoho programátorů složité...

Jak velká práce by bylo v jazyce vyškrtnout null? A kolik zisku by to přineslo. Ale on ten problém je v tom vyškrtnout ho z hlavy programátorů.

Co třeba Kotlin dokonce Scala? Ty se s těmi typy IMHO poprali velice slušně.

- Výjimky byli vymyšleny, aby se dalo psát toto:
Kód: [Vybrat]
if (((countOfFilesIn(dir1) + countOfFilesIn(dir2)) / countOfFilesIn(dir3)) == 0) { ... }
. Což bez nich prostě nejde.
Ve funkcionálních jazycích to jde ;) Akorát dá o dost víc práce pochopit, jak kód v takovém případě funguje.
Právě.
Ale stojí to za to :)
Proč myslíš?

Domníváš se, že Efekty nejsou lepší řešení takovýchto záležitostí? Nic nebrání, aby to bylo součástí signatury. Jen ta informace teče jinudy - cukr. Řekl bych.

504
- Výjimky byli vymyšleny, aby se dalo psát toto:
Kód: [Vybrat]
if (((countOfFilesIn(dir1) + countOfFilesIn(dir2)) / countOfFilesIn(dir3)) == 0) { ... }
. Což bez nich prostě nejde.
Ve funkcionálních jazycích to jde ;) Akorát dá o dost víc práce pochopit, jak kód v takovém případě funguje.
Právě.

505
Jsem silně poznamenaný funkcionálním programováním a způsob ošetřování chyb v Go se mi extrémně nelíbí.

V žádném jazyce, co má rozumné součtové typy a pattern matching, jsem neviděl že by někdo vracel chyby tuplem. Ono to nedává smysl. Obvyke nechci vrátit hodnotu A chybu, ale hodnotu NEBO chybu. Go mě nutí aby každý typ měl nějakou defaultní/prázdnou/nesmyslnou hodnotu, kterou můžu vrátit v případě chyby, i když jinak není k ničemu a ani nedává smysl.

To je otázka zvyku a nedostatku představivosti.

Haskelliho Maybe/Either taky není jen hodnota. Vždycky vracíš dvojici. V Go to prostě udělali bez typu. Může se ti to nelíbit, může se mi to nelíbit, ale principielně je to prašť jak uhoď - v porovnání s výjimkama.

506
Ono to ošetřování chyb v GO má svoji logiku (i když, přiznávám, jako Javista jsem tomu nepřišel na chuť :)).

Funkce typicky vrací dvojici hodnot - výsledek a chybu (result, err). Takto jsou napsané interní funkce a většinou se tak píšou i všechny ostatní. Obojí člověk musí do nějaké proměnné přiřadit  (result, err := func() ). A když už  něco do proměnné přiřadí, musí ji v kódu použít (jinak chyba, hlídá to kompilátor). Existuje ale placeholder "_" kdy můžu explicitně říct, že chybu ignoruju (result, _  := func() ). Takto explicitně kompilátoru řeknu, že chybový výstup funkce mě nezajímá a nechci ho ošetřit vůbec. Další možnost je  chybu ošetřít v kódu v místě vzniku nebo "poslat dál" v návratovém kódu funkce. Vždyť je to v jádru podobný mechanismus jako checked exceptions v javě (akorát s primitivnější konstrukcí).

Filozofie GO je, že chyba je jedna z možností, jak volání funkce může dopadnout. Je to plnohodnotná (a očekávaná!) alternativa k tomu, že funkce vrátí výsledek. Nikoliv něco jako corner case. Něco co "SE nějak" pořeší (frameworkem atp.). Rovnocenná varianta, která si zaslouží stejnou pozornost jako to, že funkce vrátila nějaký výsledek.

...

Ano, pohodlně se s tím žije. Ale někdy je těžké (narozdíl od toho explicitního ošetřování) říct, co se stane, když... třeba server, který volám neopdoví. Data nejde načíst. Vstup je špatný... 

Hezky shrnuto. V mnohém souhlasím.

Zdrůraznil bych:
- Výjimky byli vymyšleny, aby se dalo psát toto:
Kód: [Vybrat]
if (((countOfFilesIn(dir1) + countOfFilesIn(dir2)) / countOfFilesIn(dir3)) == 0) { ... }
. Což bez nich prostě nejde.
- Nevynucovat odchytávání - tedy unchecked exceptions jsou zlo, a celé to to kazí.
- Výjimky jsou naprosto regulérní návratový stav. Jen jinou cestou. Problém je jen v tom, když jazyk nevynucuje jejich zpracování.
- To co dělá GO je stejnej mechanisumus jako mají funkcionální jazyky (Haskell). Jen je to takové odlehčené.

507
Vývoj / Re:Discriminated unions v C++
« kdy: 24. 10. 2020, 14:17:30 »
C++ baví z viacerých dôvodov (je univerzálne, je rozšírené, dá sa tam hrať z detailami a optimalizovať, je to hlavný jazyk pre Unreal Engine, je to jazyk orientovaný na rýchlosť, nič pred programátorom neskrýva atď).

Řekl bych, že o Rustu to všechno platí taky až na "rozšířené" (to se doufám změní :-) a "hlavní jazyk pro Unreal Engine" (to chápu, že může být blocker). Ale nechci ho nikomu vnucovat.

Naprosto souhlas.

IMHO Rust sestřelil C na úroveň udržovacího legaci kódu. Má všechny výhody C a málo z jeho nevýhod.

508
Kotlin, Haskell

Na to, zda se učit Haskell mám rozporuplné pocity. Sice se naučíš a pochopíš spousta věcí z programování, jenže... Já třeba teď dělám v C# a furt zakopávám o to, že se samozřejmostí očekávám věci, které C# prostě neumí. Typové varianty, gradual typing, a tak.

509
O serveru Root.cz / Re:placené odběry
« kdy: 22. 10. 2020, 15:50:29 »
Teda, říkám si, chtěl bych mít Krčmářovi nervy. Dělat fórum pro tyhle lidi... by mě kleplo.

510
Vývoj / Re:Bootstrap: počet prvků na řádek
« kdy: 11. 10. 2020, 00:42:58 »
Nepoužij row. Vytvoř si box, do kterého budeš umisťovat prvky, které budeš pozicovat pomocí flex pravidel. Baj vočko, dle ukázky, by si mohl zkusit použít jako základ pro prvek karty (cards) - ale to není podstatné. Zajímá tě to nepoužití bootstrap row, a použít css vlastnosti flex.

Stran: 1 ... 32 33 [34] 35 36 ... 133