916
/dev/null / Re:Těžké OOP problémy
« kdy: 10. 11. 2019, 11:01:25 »async funkce obyčejná funkce vracející promiseJistě, protože platí, že Promise[T] je podmnožina U.
Zjevně nechápeš pointu, nevadí, stane se.
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.
Zjevně nechápeš pointu, nevadí, stane se.
917
/dev/null / Re:Těžké OOP problémy
« kdy: 10. 11. 2019, 10:59:40 »Když už máš tu trpělivost na diskusi s trotlama, vysvětli mu, kde tam je bindZas ale nemám trpělivost na to, poslouchat, že bind[1] je něco úplně jinýho a co že to melu za bláboly
)[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind
918
/dev/null / Re:Těžké OOP problémy
« kdy: 10. 11. 2019, 10:43:57 »neplatil ani po úpravách, vytvoření promisu bez čekání na návratovou hodnotu je naprosto validní kód.Ještě jednou a naposledy:
Pokud chci ze sync funkce dostat návratovou hodnotu, nesmím ji awaitovat. Pokud chci z async funkce dostat návratovou hodnotu, musím ji awaitovat.
Že spuštění async funkce bez await je možné a vrací Promise, je naprosto irelevantní. Že vrácený Promise můžu probublat přes libovolný počet proměnných nebo funkcí, je irelevantní.
Jak říkal Idris výš: sync funkce je typu
Kód: [Vybrat]
T -> U
Kód: [Vybrat]
T -> Promise[U]
919
/dev/null / Re:Těžké OOP problémy
« kdy: 10. 11. 2019, 10:21:02 »Nechcete se víc vnímat?V čem vidíš problém? Ten článek má ty definice udělané tak, aby seděly na nějakou implementaci. Implementace v JS je mírně odlišná, takže pokud chci, aby ty definice seděly na JS, musím je mírně upravit. Po takových drobných technicistních úpravách by článek platil i pro JS. Protože platí pro libovolnou implementaci async/await.
...a nechci být zlý, ale kdyby gill nechtěl jenom rejpat, ale snažil by se pointu článku pochopit, došlo by mu to samo.
920
/dev/null / Re:Těžké OOP problémy
« kdy: 10. 11. 2019, 10:00:22 »potom javascriptové async funkce nesplňují definici červených funkcí z toho článku.Jak jsi psal, ten článek je asi spíš o C#. Pokud bys chtěl, aby ji splňovaly i funkce z JS, stačí do definice doplnit "pokud chci z funkce dostat návratovou hodnotu":
Pokud chci z funkce dostat návratovou hodnotu, musím červenou funkci volat červeným způsobem a modrou modrým způsobem.
921
/dev/null / Re:Těžké OOP problémy
« kdy: 10. 11. 2019, 09:53:47 »Koukám třeba sem: https://golang.org/pkg/math/big/#pkg-examples - konkrétně u příkladu Fibonacci:Aha, to jsem zatím nepotřeboval, na běžné výpočty stačí float.
Všechny ty krkolomnosti jsou způsobené tím, že to je implementované jako knihovní funkce. A Go nemá uživatelské přetěžování funkcí, natož operátorů.
Ono když se nad tím zamyslíš, v podstatě úplně stejná by byla situace v C - viz např. https://en.wikipedia.org/wiki/GNU_Multiple_Precision_Arithmetic_Library#Examples
Jednoduchost jazyka prostě občas způsobuje ukecanost kódu, tak to je, s tím nic moc nenaděláš.
Ono obecně Go je hodně slabý pro vytváření jakýchkoli abstrakcí. Tenhle tvůj příklad by mě až tak netrápil. Daleko víc mě děsí situace, kde prostě z principu potřebuješ přijímat hodně různých typů, nedejmatkopřírodo i uživatelských, jako třeba u logování. Když člověk koukne na API https://godoc.org/go.uber.org/zap je mu zle... Tohle snad vyřeší generika plánovaná pro 2.0, pokud je zas nevymyslí nějakým "invenčně jednoduchým" způsobem
Jinak když koukneš na https://github.com/ksimka/go-is-not-good najdeš tam spooooustu daleko zásadnějších problémů. Osobně jsem dost zvědavej, kolik z nich a jakým způsobem ve dvojce vyřeší.
922
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 23:13:40 »Tak to přece není, žárovka nevykonává žádné pokyny, pouze reaguje na "mám elektriku => svítím" a "nemám elektriku => nesvítím", tedy máte špatně model. Nebo máte chytrou žárovku, která pokyny přijímá a máte se tedy zaměřit na componentu, která ty pokyny posílá. Zase máte špatně model. ;-)A jak by vypadal správný model, když tam bude žárovka, "elektrika" (ta, o které mluvíš) a třeba vypínač?
Stačí pseudokód.
923
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 22:37:24 »to není pravda. Oba způsoby volání "červených funkcí" se používají, jak jsem ukázal výše.To je definice. Definice nemuze byt nepravdiva.
924
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 21:58:51 »ten dekorátor říká, že pytest má tu async funkci spustit v asyncio event loopu. To je problém specifický pro python, kde neexistuje jednotný event loop. V jascriptových test frameworcích nic takového specifikovat nemusíš. V pytestu to můžeš spouštět ručně uvnitř obyčejných test casů, nemusíš používat async funkce.OMG.
Cili, abych byl opet zcela explicitni: jo, zkusil jsem to. A prave proto me to tak sere.
Je to asi potreba jeste explicitneji a min diplomaticky: s await/async delam denne, kamo. Dokonce prave ted, mam to na druhym monitoru. Netrivialni serverovy kod. Nedavno jsem psal vlastni implementaci Nursery, protoze ta z Tria z nejakeho duvodu nevyhovovala a ani aiojobs nebylo reseni. A ver mi, ze implementace async context manageru neni uplne bez podivnych zakouti a clovek musi vedet, co dela a proc to dela...
...cili fakt nepotrebuju tvoje rady, abych si async programovani vyzkousel. Hele, udelejme takovou dohodu: ty si nech svoje knizeci rady a ja se budu tvarit, ze jsem se podle nich zaridil. A na dalsi reagovani na sebe se uz vykasleme. Ok? Pokud nekde udelam faktickou chybu, tak samozrejme budu rad, kdyz ji fakticky opravis, s odkazem na relevantni zdroj. Za to jsem rad vzdycky a od kohokoliv.
925
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 21:46:33 »No je to opět otázka míry. Pokud někdo vymyslí v dnešní době jazyk, v němž jeden číselný typ sčítáme pomocí infixového operátoru a u druhého se musí použít funkce typu add() protože proto, je to IMO dost podivné, to se dá těžko okecat nějakou ortogonalitou, když trpí konzistence.To ale nemluvis o Go, ne? Nepamatuju se, ze bych potkal funkci add().
Go ma bambilion problemu, o tom me vubec nemusis presvedcovat, sam si u nej casto rvu vlasy. Treba reseni enumu pres iota a neschopnost kompileru zkontrolovat vycerpavajicnost jejich zpracovani, to je vylozene na pet let na tvrdo
Jak rikam, Rust je mi sympatictejsi.A teď ses dopustil docela zajímavého faulu - jestliže někdo polévku přesolí, nedá to zapravdu někomu, kdo raději vůbec nesolí. Chybu udělali oba, pravdu měl někdo třetí, kdo solí akorát.Rozumim ti, ale neni to tak uplne faul. Dosolit se totiz da vzdycky, odsolit uz ne.
926
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 21:07:13 »Zajímavé, jak se viralita vyskytuje v různých obměnách, kromě těch dvou zmíněných třeba u součtových závislostních typů, na to musí existovat nějaká matematická abstrakce.Jasne, https://en.wikipedia.org/wiki/Mathematical_modelling_of_infectious_disease
927
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 20:31:34 »Já jsem si vždycky myslel, že Go je spíš snaha o evoluci C - něco jako Java, ale od lidí, kteří nesnášejí OOP, ale sdílejí názor, že jazyk má být "hloupý" (svazovat programátora v maximální snesitelné míře).Mimochodem, jeste k tomuhle, kdyz uz jsme beztak v offtopicu jako prase
Ta motivace neni uplne "svazovat programatora", ale spis zvolit jenom ty featury, ktere jsou navzajem ortogonalni. A zaroven jenom ty featury, na kterych se vsichni tri autori jednomyslne shodnou. Oboji mi prijde jako prevelice rozumny kriterium. A jestli Rust zacne nejak vyrazne bobtnat, tak jim da vyvoj za pravdu...Tady to mas primo od Pikea: https://youtu.be/rFejpH_tAHM?t=588
928
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 20:25:55 »Snad jsou k nalezení diskuse ohledně použití jiného podobného modelu. Nic moc rozumného jsem nenašel, pořád předpokládám, že základ je v tom, že to do filosofie a vnitřností Rustu nezapadá.Mne se podarilo najit dost dobry vysvetleni: https://users.rust-lang.org/t/goroutines-csp-in-rust-wasm32/28207/2
Ze je potreba velkej nebo growable stack, to je jasny (a zaroven je to jedna z nevyhod CSP, na ktery ses ptal). Nakolik jsou ty komplikace, co popisuje, nejak prekonatelny nebo ne, to absolutne nejsem schopnej posoudit, do takhle low level detailu vubec nevidim. Ale je to skoda no... Tak aspon ten Actix porad v Rustu zustane k dispozici, at si nakrasne pod poklickou implementovanej nad async/await
929
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 19:33:24 »Tvé oblíbené slovo je teď “virální”?Opsal jsem ho od tebe, je to dobre vystizny a srozumitelny.
Když už jsme u té vitality, všimnul sis, že async/await je jen type lifting? Konkrétně T->Future<T>? A že to zobrazení je funktoriální? Nepřipomíná ti to něco?
jako haskellista poznáš, že vlastně jenom zbytečně zdlouhavě popisuje monády
Nevíš o nějakém jazyce/formalismu, kde by toto bylo ošetřené?To fakt nevim
930
/dev/null / Re:Těžké OOP problémy
« kdy: 09. 11. 2019, 19:10:38 »už několikátá diskuze, ve které kritizuješ async/await. Zkus to nějaký čas používat a až potom hodnotit. Zrovna v Javascriptu to podle mě funguje docela dobře.1. To neni odpoved na zadnou z polozenych otazek. Ok, beru to tak, ze nemas zajem reagovat na to, co pisu. Cili nemas zajem o diskusi. Beru na vedomi.
2. Kritizuju ten koncept jako takovy, zadna implementace na tom nemuze nic zmenit. To, ze "funguje dobre" snad znamena, ze A) kod neni rozpolcen na "modrou" a "cervenou" cast? B) Ze async se viralne nesiri kodem a ze starsiho kodu se neda pouzit? Ne, neznamena, ze. Protoze to je fundamentalni vlastnost toho konceptu. S JS, Pythonem ani jakymkoli jinym jazykem to nesouvisi.
Kdybys byval byl cetl, co pisu, a reagoval na to, co jsem napsal a ne na to, co jsem nenapsal, melo by ti to byt jasny, protoze jsem to zopakoval nekolikrat, zcela explicitne.
3. Jenom tak z pleziru, vis, co mam ted na druhym monitoru?
Kód: [Vybrat]
@pytest.mark.asyncio
async def test_multiple_gateways(service_config, multiple_gateways_sim,
eso5_test1_mqtt, eos6_os_test1_mqtt,
etm3_test1_mqtt):
[...]
Cili, abych byl opet zcela explicitni: jo, zkusil jsem to. A prave proto me to tak sere.
-----
To je z me strany k tobe vse. Respektuju, ze o diskusi se mnou nemas zajem a taky se o ni nebudu dal pokouset.
