Těžké OOP problémy

Ink

  • ****
  • 388
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #165 kdy: 09. 11. 2019, 20:08:32 »
Že je Rust "přepis C++"? No a? To je Go taky a autoři zvolili ("rozvolněné") CSP.

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

Ty důvody, proč zvolili await, můžou být různé, klidně i netechnické - třeba to, že async/await prostě zná a chápe (ať už to znamená cokoli) víc lidí.

Určitě.

Nebo by důvod mohl být třeba ten, že async/await se asi dá implementovat tak, aby byl zaručeně korektní - protože má menší míru volnosti a tím i větší kontrolu nad tím, co se spustí kdy. U CSP (i toho "rozvolněného" ve stylu Go) si člověk musí víc lámat hlavu třeba s tím, v jakém okamžiku má kontexty přepínat. Rust moc neznám, tím míň nějaký jeho internals, takže třeba autoři došli k názoru, že se jim tohle prostě nechce řešit (nebo to dost dobře ani nejde). To nevím. Ale je mi to líto, že se vydali touhle cestou.

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á.
« Poslední změna: 09. 11. 2019, 20:11:42 od Ink »


Re:Těžké OOP problémy
« Odpověď #166 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 :)

Re:Těžké OOP problémy
« Odpověď #167 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

Idris

  • *****
  • 1 562
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #168 kdy: 09. 11. 2019, 20:40:41 »
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
Jinak vznikne prasopes jako Swift.

Idris

  • *****
  • 1 562
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #169 kdy: 09. 11. 2019, 21:04:14 »
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 :)
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.


Re:Těžké OOP problémy
« Odpověď #170 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 :))

Idris

  • *****
  • 1 562
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #171 kdy: 09. 11. 2019, 21:09:40 »
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 :))
To jsem zrovna nemyslel.

Ink

  • ****
  • 388
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #172 kdy: 09. 11. 2019, 21:34:59 »
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...

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.

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.

gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #173 kdy: 09. 11. 2019, 21:39:09 »
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):
     [...]

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.
« Poslední změna: 09. 11. 2019, 21:41:09 od gill »

Re:Těžké OOP problémy
« Odpověď #174 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.

Re:Těžké OOP problémy
« Odpověď #175 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.

gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #176 kdy: 09. 11. 2019, 22:24:43 »
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.

myslíš modré a červené tak jak jsou popsané v článku http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ ? On kritizuje speciálně C#, který neznám, ale podle mě dost těch výtek v JS neplatí.
Citace
When calling a function, you need to use the call that corresponds to its color. If you get it wrong—call a red function with •blue after the parentheses or vice versa—it does something bad.
to není pravda. Oba způsoby volání "červených funkcí" se používají, jak jsem ukázal výše.

Re:Těžké OOP problémy
« Odpověď #177 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.

Re:Těžké OOP problémy
« Odpověď #178 kdy: 09. 11. 2019, 23:10:10 »
Normální vývojář se neřídí tím, co mu řekne “koncept,”
Po dlouhé době s tebou velmi zásadně nesouhasím. OOP naučí lidi nějak myslet. V pojmech "mám žárovku", "řeknu žárovce, aby se rozsvítila". Což je naprosto perfektně OOP a nemám proti tomu nic. Až na to, že implementace dělá něco úplně jiného, v tom je problém :)
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. ;-)

Re:Těžké OOP problémy
« Odpověď #179 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.