Těžké OOP problémy

Ink

  • ****
  • 388
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #180 kdy: 10. 11. 2019, 07:24:58 »
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.

Koukám třeba sem: https://golang.org/pkg/math/big/#pkg-examples - konkrétně u příkladu Fibonacci:

Kód: [Vybrat]
// Compute the next Fibonacci number, storing it in a.
a.Add(a, b)

Dobré psycho. Ale to není všechno, z jiného příkladu:

Kód: [Vybrat]
return term.Add(term, frac)

Abych si mohl sečíst 2 čísla typu BigNum, musím si:

1. Vytvořit obě čísla pomocí new()
2. Naplnit si je nějakou Set* metodou
3. Sečíst si je in-place do nějaké proměnné

Když tuhle operaci chci udělat ve funkci a ty dvě čísla si tam pošlu jako parametry a vrátit výsledek, mám dvě možnosti:

a) Použít jako "receiver" jeden z parametrů - pak se ale nejenom vrátí jeho hodnota, nýbrž se změní i obsah proměnné, kterou jsem si poslal přes parametr
b) Vyrobit si ve volané funkci dočasnou proměnnou, použít ji jako "receiver" a vrátit tu

No a když to spletu (když ta funkce je netriviální), chyba je na světě. Určitě je ale možné, že něco přehlížím a že existuje idiomatický způsob, jak to napsat hezky a bez rizika podobných chyb.
« Poslední změna: 10. 11. 2019, 07:26:55 od Ink »


gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #181 kdy: 10. 11. 2019, 08:47:10 »
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.

potom javascriptové async funkce nesplňují definici červených funkcí z toho článku.

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

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

Re:Těžké OOP problémy
« Odpověď #184 kdy: 10. 11. 2019, 10:14:14 »
(...) 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.

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.

 ::) ::)

potom javascriptové async funkce nesplňují definici červených funkcí z toho článku.

(...) Pokud bys chtěl, aby ji splňovaly i funkce z JS, (...).

Nechcete se víc vnímat?


Re:Těžké OOP problémy
« Odpověď #185 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.
« Poslední změna: 10. 11. 2019, 10:23:00 od Mirek Prýmek »

gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #186 kdy: 10. 11. 2019, 10:34:27 »
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.

neplatil ani po úpravách, vytvoření promisu bez čekání na návratovou hodnotu je naprosto validní kód. Narozdíl od pythonu, kde nespuštění vytvořené coroutiny vygeneruje warning. Promise v JS se spustí (naplánuje) automaticky při vytvoření.
« Poslední změna: 10. 11. 2019, 10:37:32 od gill »

Re:Těžké OOP problémy
« Odpověď #187 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
async funkce je typu
Kód: [Vybrat]
T -> Promise[U]
Jsou to dva různé světy, jeden červený, druhý modrý. Jestli to nechápeš, nebo nechceš chápat, je celkem jedno. Tak jako tak diskuse s tebou nemá smysl.
« Poslední změna: 10. 11. 2019, 10:48:44 od Mirek Prýmek »

Idris

  • *****
  • 1 589
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #188 kdy: 10. 11. 2019, 10:54:00 »
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
async funkce je typu
Kód: [Vybrat]
T -> Promise[U]
Jsou to dva různé světy, jeden červený, druhý modrý. Jestli to nechápeš, nebo nechceš chápat, je celkem jedno. Tak jako tak diskuse s tebou nemá smysl.
Když už máš tu trpělivost na diskusi s trotlama, vysvětli mu, kde tam je bind ;)

gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #189 kdy: 10. 11. 2019, 10:58:59 »
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
async funkce je typu
Kód: [Vybrat]
T -> Promise[U]
Jsou to dva různé světy, jeden červený, druhý modrý. Jestli to nechápeš, nebo nechceš chápat, je celkem jedno. Tak jako tak diskuse s tebou nemá smysl.

návratovou hodnotu dostáváš z promisu, ne z funkce. async funkce obyčejná funkce vracející promise. Je to naprosto blbuvzdorné.

Re:Těžké OOP problémy
« Odpověď #190 kdy: 10. 11. 2019, 10:59:40 »
Když už máš tu trpělivost na diskusi s trotlama, vysvětli mu, kde tam je bind ;)
Zas 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

Re:Těžké OOP problémy
« Odpověď #191 kdy: 10. 11. 2019, 11:01:25 »
async funkce obyčejná funkce vracející promise
Jistě, protože platí, že Promise[T] je podmnožina U.

Zjevně nechápeš pointu, nevadí, stane se.

Idris

  • *****
  • 1 589
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #192 kdy: 10. 11. 2019, 11:15:33 »
async funkce obyčejná funkce vracející promise
Jistě, protože platí, že Promise[T] je podmnožina U.

Zjevně nechápeš pointu, nevadí, stane se.
Trapné je, když se to někomu děje furt dokola  ;D

Idris

  • *****
  • 1 589
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #193 kdy: 10. 11. 2019, 11:18:12 »
Když už máš tu trpělivost na diskusi s trotlama, vysvětli mu, kde tam je bind ;)
Zas 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
Tohle je slušná prasárna. Aspoň se to nejmenuje flatMap.

Ink

  • ****
  • 388
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #194 kdy: 10. 11. 2019, 14:35:03 »
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ší.

Dík za odkazy, je to síla. Ten můj příklad s operátory byl hlavně míněn jako podpora mému tvrzení, že Go je spíš snaha o evoluci C než o přepsání/napravení C++ a že se návrháři vydali stejnými blátivými cestičkami jako návrháři Javy. Tímto za mě téma Go je docela vyčerpáno a můžeme se vrátit třeba k hejtování OOP.