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 33
436
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 12:29:39 »
No a s tím sleepem a joinem je zrovna pár hodin starý dotaz a vysvětlení na Redditu: https://www.reddit.com/r/rust/comments/dtp6z7/what_can_i_actually_do_with_the_new_async_fn/

437
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 12:20:45 »
Máš na mysli paralelní polling, něco jako https://docs.rs/futures/0.3.1/futures/macro.join.html ? Nebo něco komplikovanějšího? V téhle problematice nemám zkušenosti.
Napadají mě minimálně dva rozdílné způsoby, jak by se to dalo implementovat:

1. Promisy běží (potenciálně) skutečně paralelně, každý (potenciálně) na svém jádře

2. Promisy jsou odstartované "zaráz" (rychle po sobě), ale paralelně běží jenom operace "mimo jazyk" (typicky IO)

To první je asi jasný. To druhý je jenom "jakože paralelní" v JS stylu. Od serializovaných awaitů by se to poznalo tak, že
Kód: [Vybrat]
await sleep(1)
await sleep(1)
await sleep(1)
by netrvalo ~ tři sekundy, ale ~ jednu.

To druhé v JS jde implementovat, ale musí se to (AFAIK) udělat ručně přes Promise.all()

V tom je ten vtip - Rust není magický jazyk, nedělá žádné legrácky typu GC a automatickou paralelizaci. Programátor v Rustu by vždycky měl rozumět tomu, co dělá, když překročí hranice, kompilátor ho pošle k šípku a pak se dotyčný musí zamyslet a konflikt představ vyřešit. Třeba si vem takový Rayon - na první pohled to vypadá jako velká magie, která vyřeší něco za Tebe, on skutečně leccos umí díky možnostem, které Rust a jeho typový systém umožňuje, jenže pak zjistíš, že pro paralelní iterátor buďto musíš použít nějakou kolekci, kterou Rayon podporuje nebo si budeš muset naimplementovat příslušný trait nebo se na to (jako já, když jsem si s tím hrál) vykašleš úplně a prostě si uděláš vlastní paralelní iterátor, který si synchronizaci řeší sám. To není moc těžké, ale musíš u toho přemýšlet a narazíš pak (jako já) třeba na to, že objekt má delší životnost, než ses domníval a najednou se výpočet provádí de facto sekvenčně.

Proto bych osobně neočekával, že tohle Rust kdy bude dělat sám - můžeš mít simultánní polling, ale ty přesahy mezi vlákny si řešíš sám v nižší vrstvě. Nebo tam holt budeš mít nějaký objekt, který to bude umět řešit elegantně za Tebe oboje, ale zase budeš muset splnit nějaké podmínky na obou koncích - v té paralelní metodě pro multithread a v tom "klientu" v původním vláknu.

438
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 10:44:29 »
To je implementační detail bez jakéhokoliv dopadu na cokoliv, co jsem napsal.
BTW, kdybys chtěl nějaký větší rozdíl, tak největší, co mě napadá, je že await může být lazy nebo eager. Jak teď koukám, Rust má lazy. JS má eager (AFAIK).

Taky by šlo promisy z awaitů paralelizovat (k tomu právě směřovala ta moje testovací otázka). Jestli to nějaký jazyk skutečně dělá, to nevím. Obávám se, že spíš ne, protože v jazyce s mutable shared state by to bylo obtížné až nemožné udělat korektně.

Máš na mysli paralelní polling, něco jako https://docs.rs/futures/0.3.1/futures/macro.join.html ? Nebo něco komplikovanějšího? V téhle problematice nemám zkušenosti.

439
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 09:11:29 »
Koukám právě narvali async/await do Rustu. To je fakt mor.

Na tom "moru" vývojáři Rustu pracovali spoustu měsíců a komunita se na to dost těšila. Možná víš něco, co oni nevědí, ale žádné zděšení jsem nikdy na příslušných fórech nezaznamenal.

440
/dev/null / Re:Těžké OOP problémy
« kdy: 08. 11. 2019, 11:34:37 »
Dobře zvolená abstrakce naopak nevyžaduje, abys někam skákal, prostě o sobě říká, co dělá a typicky se o vnitřek zajímat vůbec nemusíš.
Nemusím se o vnitřek starat, pokud jsem si dostatečně jistý tím, 1. co je výsledkem její činnosti (pokud je to funkce) 2. že neobsahuje žádnou chybu.

Implementaci knihovních funkcí typu map budu prolízat až jako poslední, protože je nejmenší šance, že chyba bude právě v ní. Naopak konstrukce, které napsali kolegové před půl rokem a jsou v kódu použité jenom dvakrát, prolízt musím, protože pravděpodobnost chyby je veliká. V případě, že jsou srozumitelné a snadno zapamatovatelné, prolezu je jednou. Jinak je musím prolízat pořád dokola, protože prostě nejsem schopný si zapamatovat nebo vůbec pochopit, co mají dělat.

No a teď jsme myslím u toho - abstrakce jsou OK, když jsou dobře navržené a odladěné. Tudíž asi nechceme, aby je psal "kdokoli", ale pustíme na to člověka, který to umí, děláme review kódu a pak máme rozumnou jistotu, že ten vnitřek funguje a "pojídači koláčů" nasekají co nejméně chyb a ty jsou dobře viditelné. Je to jiný přístup, než když všichni "jedí z jedné mísy" - neříkám, že jediný možný, neříkám, že vždy optimální, ale podle mě dost užitečný a s úspěchem aplikovaný.

441
/dev/null / Re:Těžké OOP problémy
« kdy: 08. 11. 2019, 08:38:29 »
dobře zvolená a napsaná abstrakce kód nemůže znepřehlednit.
S tím bych nesouhlasil. Dokonce bych spíš tvrdil skoro opak: každá abstrakce z definice přidává další indirekci v tom smyslu, že když sleduju flow programu a narazím na abstrakci, musím odskočit jinam (do souboru, kde je ta abstrakce definovaná).

Jediné, co rozhoduje, je, jestli převáží nevýhody použití nebo nepoužití abstrakce. Což je typicky počet abstrakcí (jestli jsem schopen si je zapamatovat a ušetřit si tak odskoky) a jejich srozumitelnost (po jednom přečtení chápu smysl abstrakce, nedělám to tak, že sleduju jenom ten jeden průchod, který zrovna řeším).

Dobře zvolená abstrakce naopak nevyžaduje, abys někam skákal, prostě o sobě říká, co dělá a typicky se o vnitřek zajímat vůbec nemusíš. Co je abstrakce, je datová struktura abstrakce? Je bufferovaný soubor abstrakce, je check box abstrakce? Je volání dobře pojmenované funkce zbytečná překážka v čitelnosti kódu, když se to přece dá naprasit na jednom místě a překladač to snese? Proč používat map() a filter(), když všichni známe cyklus a taky funguje. Proč požívat cyklus, když máme goto...

442
/dev/null / Re:Těžké OOP problémy
« kdy: 08. 11. 2019, 08:17:30 »
Já bych taky doporučoval vystříhat se zobecňování.

Viděl jsem programy "lidí z praxe", kteří vystudovali jiný obor. Jakmile systém přesáhne určitou velikost, často nevědí moc co s tím, protože jim scházejí zkušenosti, nemají to osahané ani odkoukané. Programování je řemeslo úplně odlišné od jiných a jeho znalost nedá se nahradit ani selským rozumem ani vysokým IQ, vyjma prdlikání prográmků o pár tisících řádek. Mimochodem, lidé z jiných oborů, kteří mají ultravýkonný mozek, sice nevrství abstrakce, ale zase občas píší špagetový kód, ve kterém se vyznají přinejlepším oni sami a udržovatelnost je mizivá.

Co se týče "zbytečných" abstrakcí, je to otázka míry a odhadu. Kolikrát jsem zažil situaci, kdy kolegové tíhli k "custom" implementaci, pak se udělal jeden copy/paste, pak druhý, pak další a už to šlo tak nějak ze zvyku a když to po nich někdo přepíše, málem aby si za to dal facku, když "to přece takhle funguje" a "proč to neudělat zase tak, když máme dost jiné práce". Že se to pak další měsíce a roky s úspěchem dělá ponovu a co se řešilo kopírováním funkce o 100 řádcích nebo větší třídy, je teď na jedno volání, už nikdo nevidí, protože se to "teď dělá takhle, no". Nebo ty abstrakce daný tým znovupoužívá v dalších a dalších produktech, ale to už jaksi není vždycky vidět. No a navíc - dobře zvolená a napsaná abstrakce kód nemůže znepřehlednit. Naopak by měla vést k tomu, že se pořád dokola řeší pár řádek namísto špagetového monstra, kde "všechno souvisí se vším" a "nic není navíc".

Že je abstrakce nástroj, který může být použit špatně? Ale jistě, jako každý nástroj!

443
/dev/null / Re:Těžké OOP problémy
« kdy: 06. 11. 2019, 21:07:35 »
Nic take nejestvuje, kedze tu mame teoriu vypocitelnosti.
vsteko co vies namodelovat cez FP vies namodelovat aj cez OOP, su to len dva pohlady na to istu vec.

Zrovna tak lze vhodně upraveným kladivem utáhnout šroubek a šroubovákem zatlouct hřebík.

444
Vývoj / Re:Python - šíře nasazení
« kdy: 02. 10. 2019, 07:26:58 »
Ahoj, i když se díky svému zaměření pohybuji ponejvíce ve sféře embedded systémů (a tudíž moji "jazykovou" stáj tvoří hlavně dvojice C a C++), používám již léta Python k podpoře vývoje - parsování dat, zpracování naměřených dat, analýza logů atd. Pokud potřebuji vytvořit nějakou tu appku s GUI na desktop, sáhnu automaticky po C# a WPF, či po C++ a Qt, když to má běžet na Linuxu. I v Pythonu se nechá GUI aplikace vyvinout, třeba s derivátem již zmíněné Qt knihovny PySide, ale přijde mi to celé takové těžkopádné  :) . A navíc si ani nedokážu představit, jak zákazníkovi předávám testovací aplikaci a přitom se ho ptám, zda má nainstalovaný interpret Pythonu atd.  ;D

Jsem tu sám, nebo i někomu jinému připadá, že se Python používá i v oblastech, na které nebyl koncipován?

Na PyQt nic těžkopádného neshledávám, vývoj je rychlý, aplikace svižné, minimálně ta GUI část není žádná brzda.

445
Odkladiště / Re:(Rádoby)frikulínská komunikace firem
« kdy: 08. 09. 2019, 18:40:19 »
Myslím, že firem, kde to bude někdo bránit, aby sis v kuchyňce uvařil kafe sám, těch moc nebude.

Pokud chceš slušné espresso, tak to už začíná být problém.

+1

Dobrá káva vyžaduje především dobrý kávovar. Nic proti baristkám, ale...

446
Odkladiště / Re:(Rádoby)frikulínská komunikace firem
« kdy: 07. 09. 2019, 21:45:39 »
Ano, jsem osloven upřímnou zpovědí špatných herců této komédie. Mým snem je za pár korun měsíčně trávit celé dny a noci ve firmě, kde mají fotbálek, boxovací pytel, mezi nohama běhají psi a na každém patře je lednice se zlevněnými bagetami a energy drinky.

447
Docela by mě zajímalo, jak to víš. To Ti to někdo vždycky reportuje, že za ním byl ten a ten a říkal o Tobě něco?

448
Vývoj / Re:Prototypové OOP
« kdy: 18. 07. 2019, 11:13:36 »
Co přesně má to (prototypové) OOP řešit, zajímá Tě to jenom tak, nebo s tím chceš i něco dělat? Úplně chápu, pokud někdo studuje exotické (lidské) jazyky, kultury a organismy, ale z praktického hlediska...

Pro každého je praktické něco jiného. IMHO javascript je stále populární a může se hodit vědět, jak funguje. Anebo se pak člověk dostane k lepší práci, protože tam třeba bude mít možnost uplatnit rozhled (i když k tomuto levelu je ještě delší cesta, nestačí obecně vědět co to prototypové OOP je).

Jsem ten poslední člověk na světě, který by byl proti obecnému rozhledu. Nicméně i do toho JavaScriptu přibylo třídy, domnívám se, že prototypové OOP obecně není moc osvědčený způsob psaní programů, proto jsem se ptal, co s tím chtěl původní tazatel řešit.

449
Vývoj / Re:Prototypové OOP
« kdy: 17. 07. 2019, 07:39:26 »
Co přesně má to (prototypové) OOP řešit, zajímá Tě to jenom tak, nebo s tím chceš i něco dělat? Úplně chápu, pokud někdo studuje exotické (lidské) jazyky, kultury a organismy, ale z praktického hlediska...

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