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 - Ink

Stran: 1 ... 28 29 [30] 31 32 ... 44
436
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 03. 11. 2020, 14:35:58 »
Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.

Co jsi tedy myslel timhle:

kontrolovat typy pri kompilaci je trochu pozde ze?

437
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 03. 11. 2020, 13:47:58 »
S tim sem si nikdy nehral...
Pouzivam https://clojure.org/guides/spec obcas... a kdysi sem si hral s https://github.com/arohner/spectrum.

Ale hlavne RDD (repl driven development) prece jenom kontrolovat typy pri kompilaci je trochu pozde ze? (:-D)

Podle mych zkusenosti ty typy u dynamickych jazycich nejvic chybeji az pri upravach produkcniho systemu.

438
Teď se Ti myslím povedla demonstrace jedné ze skutečných výhod výjimek, která ale může fungovat asi jenom v dynamických jazycích typu Pythonu - ten context manager pozná výjimku podle parametru, který ji identifikuje.

Jinak je to věc, která se dá řešit destruktorem při výstupu z rozsahu platnosti proměnné - třeba v Rustu se udělá drop v opačném pořadí (vzhledem k pořadí definice proměnné) automaticky a je vymalováno taky.

Obávám se, že rozhodně nemohu souhlasit. Už jsem tu toto téma někdy rozebíral, žel neúspěšně. Má aktuální úroveň poznání mi říká, že dynamické jazyky nepřináší nic co by principielně nešlo ve statických jazycích (a stáli bychom o to). Každopádně, asi zůstaňme u tématu.

Principiálně ano. Přemýšlím, jak by se to dělalo v C++. Pokud si pamatuju dobře, můžeš jako výjimku házet leccos, takže by maximálně šlo do exit metody poslat info, jestli výjimka byla nebo ne. U dynamických jazyků typu Pythonu je hodnota proměnné libovolná.

No ale zase, kdybychom měli k dispozici jenom bool, šlo by něco podobného i bez výjimek - třeba v Rustu. Tam se mi dokonce rýsuje i řešení s identifikací typu Erroru - pomocí downcastu by to mělo být možné vydolovat i z wrapperu, jaký dělá třeba anyhow! Tudíž asi musím vzít zpět svoje tvrzení o výhodě výjimky, protože podle všeho by to mělo jít postavit i nad Resultem - musel by se udělat příslušný trait (nebo změnit protokol Dropu) a jazyk by tomu musel vyjít vstříc.

439
Kód: [Vybrat]
# Python
with open('dog_breeds.txt') as src, threading.Lock(), db.connection() as con:
    con.insert(src.readlines())

(GoLang má defer, což je něco podobného ale hnusnějšího.)

Řekl bych, ty tak docela nepotřebuješ rozlišovat co může selhat a co ne. Jako spíše zajistit tu atomicitu.

Ten with řeší dvě věci, automaticky uzavřít zdroj, když něco selže, a rollback při chybě v bloku.

Tohle je zatím nejhezčí s čím jsem se setkal.

Teď se Ti myslím povedla demonstrace jedné ze skutečných výhod výjimek, která ale může fungovat asi jenom v dynamických jazycích typu Pythonu - ten context manager pozná výjimku podle parametru, který ji identifikuje.

Jinak je to věc, která se dá řešit destruktorem při výstupu z rozsahu platnosti proměnné - třeba v Rustu se udělá drop v opačném pořadí (vzhledem k pořadí definice proměnné) automaticky a je vymalováno taky.

440
Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)
No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...
To “zahodit” znamená, že výpočet se v monádě dostane na vedlejší kolej. Ten kód oddělený není, jen pracuje v rámci složitějšího typového systému. BoneFlute má pravdu, že to je v podstatě zdarma.

Však já polemizuju pouze s tím "Tady trochu provokuju". "kód oddělený není, jen pracuje v rámci složitějšího typového systému" - není to slovíčkaření? Prostě se ví, která funkce má efekty a která ne a dokud se výpočet dělá v bezefektové funkci, víme, že výsledek se může zahodit.

441
Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...

442
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 29. 10. 2020, 17:55:37 »
Já dělal několik let ve Scale, a možná bych víc doporučil Kotlin, ve kterém jsem nedělal nikdy :-) Scala je dost složitý jazyk s featurami (hlavně implicity), u kterých není bez zkušeností moc jasné, jak je správně používat. Řekl bych že mi trvalo alespoň rok než jsem v ní začal dělat jakžtakž idiomaticky. A i to je dost relativní, protože má více táborů - lidi, co jí považují za lepší Javu (a těm bych opravdu doporučil Kotlin), a lidi co jedou hardcore FP (používají knihovny jako cats nebo scalaz, nebo nedejbože shapeless), a to FP je zas mnohem líp vidět a snáz a čistěji se naučí v jazycích jako je Haskell. Navíc se těžko shání spolupracovníci.

Ale jestli máš chuť, určitě ti Scala hodně dá. A jako staticky typovaný, rel. rozšířený FP jazyk nad JVM asi nejsou moc lepší volby.

A jakou zkušenost jsi měl s rychlostí kompilace a ekosystémem/toolingem? Když jsem se o Scalu zajímal já, přišlo mi, že to jsou hlavní potenciálně problematické věci. Samozřejmě, ta vysoká heterogenita může být nepříjemná, ale to je designové rozhodnutí a podle mě se tam dá zvolit nějaká podmnožina idiomů, které člověk používá, ale když to celé funguje divně nebo pomalu, je to zásadní problém.

443
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.

444
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 {
    }

445
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.

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

Kód: [Vybrat]
use std::fs::read_dir;
use anyhow::{anyhow, Result, Context};
use std::path::Path;

fn count_of_files(path: &str) -> Result<usize> {
    let dirs = read_dir(path)?;
    Ok(dirs.count())
}

fn safe_divide(dividend: usize, divisor: usize) -> Result<usize> {
  if divisor == 0 {
    Err(anyhow!("Zero divisor, check it dude"))
  } else {
    Ok(dividend / divisor)
  }
}

fn hausnumero(first: usize, second: usize, third: usize) -> Result<usize> {
    safe_divide(first + second, third)
}


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(())
}

446
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.

Sorry, anyhow to mělo být: https://docs.rs/anyhow/1.0.33/anyhow/

447
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.

448
Ahoj, díky za názory a odkazy na různé materiály. Jsem z toho právě takovej roztěkanej - čím víc možností tím se mi hůř rozhoduje, rád bych uměl všechno ale času na to tolik mít nebudu - můžu se tomu věnovat maximálně 2-3 hodiny denně.

Mám teď pár nápadů na jednoduché webové aplikace které bych chtěl zhmotnit.

Zkoušel jsem si například pár základních věcí v PHP a přišlo mi to takové jednoduché (třeba proti Jave) ovšem názory na internetu ohledně PHP jsou takové rozporuplné (možná spíš až negativní).

Vím že výběr jazyka není rozhodující ale pokud chci věnovat nečemu čas a usílí tak bych chtěl aby mě to někam posunulo, například a to mě opravte okud se pletu:

Když budu chtít vytvořit nějakou webovou aplikaci budu potřebovat HTML+CSS+JS+PHP - ale z tohohle hlediska mi přijde lepší využit node js místo PHP  protože se tím naučím syntaxi JS pro vytváření front endu (rozumnější by to asi bylo spíš obráceně). Pak když nad tím přemýšlím tak backend jde udělat i v Javě tak proč ztrácet čas s PHP nebo node js a prostě se to vše naučit v Javě.

Omlouvám se asi to moc řeším, jen v tom chci nějak zorientovat a efektivně využít svůj čas.

Paralýza možnostmi (option paralysis), to je normální. V zásadě ale řešíš několik různých cílů:

1. Udělat něco rychle a dostatečně dobře.
2. Pochopit obecné principy a umět optimalizovat řešení (na rychlost vývoje, rychlost běhu produktu, škálovatelnost, udržovatelnost). Prostě se intelektuálně rozvíjet a růst.
3. Naučit se něco, o co je zájem na trhu (ale viz bod 4).
4. V neposlední řadě - dělat něco, co Tě baví, protože je to tvůj čas a chceš ho strávit i příjemně.

A teď si polož otázky:

Je možno v PHP udělat něco rychle a dostatečně dobře? Můžu se s jeho použitím rozvíjet? Je o něj zájem na trhu? Baví mě práce v PHP, nebo mě nudí a děsí?

To samé pro Javu. To samé pro JS. To samé pro jakýkoli další jazyk.

Třeba v mém případě: Shellové skripty mě nejenom nebaví, ale přijdou mi z programátorského hlediska jako strašná prasárna. PHP mi nevadí, ale víc mě baví Python. V Pythonu se dá naprogramovat "všechno", ale má svoje zjevné nevýhody. Určitě se v něm uživím. Ještě víc mě baví Rust, ale to je takový seriózní drsný pán, není to kamarád na rychlou akci. Spojení Rustu a Pythonu mi řeší prakticky úplně všechno a baví mě. Pokud Tě Java baví, klidně v ní pokračuj, pro mě to není, ale to není podstatné.

Určitě bych zvládl psát v několika dalších jazycích (a živilo mě to), ale nedělám to, pokud nemusím.

449
Software / Re:Rozbity GIT
« kdy: 22. 10. 2020, 08:25:01 »
To je divné, skoro bych řekl, že problém není v samotném Gitu. Ale zkus si zkompilovat a nainstalovat Git ze zdrojáků.

https://www.digitalocean.com/community/tutorials/how-to-install-git-from-source-on-ubuntu-20-04-quickstart

450
Vývoj / Re:Programovací jazyk Nim
« kdy: 28. 09. 2020, 20:25:47 »
ukaz mi konkretni chybu, kterou Rust detekuje a bezne pouzivane lintery/kompilery nedetekuji. Podle me se vsechny takove chyby tykaji spravy pameti a soubezneho pristupu do pameti v paralelnich programech. Takove chyby hrozi jen v urcitem typu aplikaci. Kdyz pouzivas model pararelismu zalozeny na posilani zprav/komunikaci pomoci front a jazyk s GC, nic takoveho nemuze nastat.

Několik příkladů, které typový systém a další prostředky Rustu řeší:

1. Pattern matching a úplnost vyhodnocení možností a tím pádem:
2. Řádné ošetření nullable typů (Option rulez)
3. Řádné ošetření chybových výsledků (Result rulez)
4. Statická kontrola formátování řetězce (hygienic macro rulez)
5. Skvělá podpora pro serializaci pomocí maker (serde rulez)
6. Úžasná podpora pro budování parseru argumentů, opět pomocí maker a pomocí vyspělých složených typů (Enum atd.) (structopt rulez)
7. Oproti GC zcela deterministické uvolňování VŠECH možných prostředků, nejenom paměti, ale i třeba zámků nebo otevřených souborů a nevím čeho ještě. Na rozdíl od různých GC jazyků NEEXISTUJE, že by se volal nebo nevolal "destruktor" v závislosti na tom, jak se runtime zrovna rozmyslí (RAII rulez)

Rust není "jenom" hlídač paměti, ale autoři si dali hodně práce s tím, aby jazyk měl pokročilé vlastnosti známé z FP jazyků při zachování efektivity srovnatelné s C++ (protože zero cost abstractions) a v ideálním případě ne za cenu zhoršené ergonomie. Člověk často zjistí, že co mu chybělo oproti jiným jazykům, má Rust implementováno podobně nebo malinko jinými prostředky, ale se srovnatelným pohodlím.

Platí za to hlavně tím, že se musí dost věcí učit a že nad svým programem musí přemýšlet dopředu, případně vychytat fígle, které mu umožní část rozhodnutí přesunout do pozdějších fází vývoje. A pokud už do jazyka investoval, otevřou se mu další domény a věř tomu, že komunita kolem Rustu je hodně vitální a činí se, takže jeho využitelnost je od high performance web serverů přes embedded systémy a výpočetně náročné paralelní výpočty (Rayon rulez) k CLI utilitám a klidně i webovému frontendu s využitím WASM (Yew).

Už jsme na hraně flamewaru, takže za sebe tímto končím.

Stran: 1 ... 28 29 [30] 31 32 ... 44