Dědičnost dnes

JS

Re:Dědičnost dnes
« Odpověď #510 kdy: 28. 01. 2017, 08:45:36 »
Haskell, v pořádku. Každopádně já argumenty přiložil, pan Armstrong spíš spekulace a dojmy. Ale nakonec proč ne, jako já nerozumím FP, on nerozumí OOP.

Jak vis, ze nerozumi OOP? Zato vime, ze ty neznas FP.. Me prijde, ze tak trochu popiras, ze by sly veci delat lepe.

Ja asi neznam nikoho (slavnejsiho) kdo zna oboji, a netvrdil by, ze FP je minimalne stejne dobre jako OOP, a pokud ano, tak jsou to casto Smalltalkiste (mozna Gilad Bracha).

Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Ono ostatne i existence mnoha "design patterns" naznacuje, ze takova ta originalni predstava OOP, ze lze pomoci trid modelovat domenove objekty, tak docela nevysla.


čumil

Re:Dědičnost dnes
« Odpověď #511 kdy: 28. 01. 2017, 09:54:54 »
 :o
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.
Stěžejní je IMHO forwardSelector, jinak si člověk celkem vystačí s virtuálními metodami.
Virtualky jsou jen chaba nahrada toho co máš třeba v js.
Jakejkoli typovej system nejde dohromady s oop, pak vznikaj jenom kompromisy..

OOP nie je o tom, ci sa pouziva staticke, alebo dynamicke typovanie. Oboje ma svoje nevyhody a vyhody.
Su tam podobne problemy ako v inych paradigmach so statickym a dynamickym typovanim.  Staticke typovanie ide dobre dokopy s OOP.
Je :D přesně o tom oop je, v opačném případě jsi ho těžce nepochopil.
Konec konců, říkám jen to co říká Alan :)

balki

Re:Dědičnost dnes
« Odpověď #512 kdy: 28. 01. 2017, 11:05:12 »
:o
OK, tady pisatel, předpokládám, myslel přinejmenším bod 1) mého úkolu. Ten C++ neumí, takže předávání ve smalltalku není stejné jako v C++ a nemáš pravdu. Nebo bod 1) nepovažuješ za předávání zpráv ale za reflexi, a potom reaguješ na příspěvek, který se předávání zpráv (podle tebe) netýká. Jsem zmaten, a končím s touto debatou, není plodná.
Stěžejní je IMHO forwardSelector, jinak si člověk celkem vystačí s virtuálními metodami.
Virtualky jsou jen chaba nahrada toho co máš třeba v js.
Jakejkoli typovej system nejde dohromady s oop, pak vznikaj jenom kompromisy..

OOP nie je o tom, ci sa pouziva staticke, alebo dynamicke typovanie. Oboje ma svoje nevyhody a vyhody.
Su tam podobne problemy ako v inych paradigmach so statickym a dynamickym typovanim.  Staticke typovanie ide dobre dokopy s OOP.
Je :D přesně o tom oop je, v opačném případě jsi ho těžce nepochopil.
Konec konců, říkám jen to co říká Alan :)

Citaciu prosim. Pokial viem, Alan Key (Dufam, ze som ho zasa neskomolil), dynamicke typovanie preferuje, ale nezavrhuje staticke typovanie.

Kiwi

Re:Dědičnost dnes
« Odpověď #513 kdy: 28. 01. 2017, 11:39:51 »
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad. A s tim bych souhlasil, vede to k problemum. Chces poprit, ze to vede k problemum? Klasicky priklad je trida matice a vektor, ktery se treba v C++ resi pres spratelene tridy.

Popravdě, aniž bych si to zkusil napsat mě teď od židle nenapadá, v čem že je u matic a vektorů problém. Mohl bys naznačit?

Ono ostatne i existence mnoha "design patterns" naznacuje, ze takova ta originalni predstava OOP, ze lze pomoci trid modelovat domenove objekty, tak docela nevysla.

To se ale týká právě těch jazyků typu C++ či Java, v nichž se pomocí design patterns dohání ta jejich objektová polovičatost.

Kiwi

Re:Dědičnost dnes
« Odpověď #514 kdy: 28. 01. 2017, 11:44:35 »
Alan Key (Dufam, ze som ho zasa neskomolil)

Bohužel, ani napodruhé ti to nevyšlo.  :)


balki

Re:Dědičnost dnes
« Odpověď #515 kdy: 28. 01. 2017, 12:20:23 »
Alan Key (Dufam, ze som ho zasa neskomolil)

Bohužel, ani napodruhé ti to nevyšlo.  :)

Do krista, zasa. Na skole som musel mat na neho latexove makro :)

Re:Dědičnost dnes
« Odpověď #516 kdy: 28. 01. 2017, 12:33:36 »
Tady jsme si spíš nerozuměli, předpokládal jsem, že se porovnává funkce z imperativních jazyků (tj. v podstatě procedura) s objektovým posíláním. Funkcionální funkci (tj. v podstatě matematickou funkci) jsem na mysli neměl.
Ok.

To vypadá dobře. I když implementovat asynchronní v synchronním jde tady.
Jde, ale je to míň praktické - musím pro každé volání rezervovat thread/process. Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".

3. odeslání zprávy nemusí nic "vracet" nebo může "vracet" víc hodnot postupně
...
To už je věcí implementace na druhé straně, to bych tu nerozebíral. Ale vypadá to zajímavě.
Chtěl jsem tím říct, že (asynchronní) posílání zpráv je "obecnější" než volání funkce - v takovém spíš sémantickém než technickém smyslu, protože samozřejmě funkci taky můžu předat callback, který pak bude volat znovu a znovu...


Monády mi stačila, jen jsem je nestihl prostudovat.
Monády jsou v principu celkem jednoduché, ale bývá problém je vysvětlit/pochopit, proto jsem dal příklad, který je myslím každému programátorovi jasný na první pohled.

Každopádně důsledkem je, že vnitřně je modul sice immutable, ale navenek (a to mě v interakci s ostatními zajímá) pochopitelně mutable.
Tady nebezpečně motáš pojmy. Mutabilita se týká dat. Co je "mutabilita modulu", to bysme si museli nějak zadefinovat, jinak to bude plácání o koze a o voze :)

Tzn. tvrzení, že v FP je vše immutable, asi nebude pravdivé. Dále předpokládám, že jsou hodnoty při volání funkce či posílání zprávy předávány odkazem, jinak by celé toto čarování nemělo smysl.
V různých jazycích je to různě. V tom Elixiru, ve kterém příklad byl, platí, že jakmile mám jednou nějaká data, tak je už nikdy nemůžu změnit. Čili tam vůbec nedává smysl mluvit o volání odkazem nebo hodnotou - je to úplně to samé, je mi úplně jedno, jak je to implementované, protože třeba asoc. pole {'a' => 1} bude už navždy mít jenom jeden klíč, nikdo tam nijak nemůže přidat druhý. Čili to pole můžu úplně klidně předávat kamkoli, do kolika vláken chci a nemusím se bát, že by mi ho nějaké jiné vlákno neočekávaně změnilo pod rukama. Pokud někdo chce do pole přidat další klíč, vznikne mu nové pole, které s tím starým nemá nic společného (a navíc protože původní už nikdo nemůže změnit, můžou ty dvě pole úplně klidně a bezpečně sdílet data - ale to už je otázka implementace, která mě jako uživatele jazyka nezajímá).

Nicméně Elixir (a jeho "podvozek" Erlang) negarantují to, že když dvakrát zavolám tu stejnou funkci se stejnými parametry, dostanu stajný výsledek. Čili k tomu stavu můžu přistupovat přes funkci (která obalí posílání zpráv) a dostanu pokaždé stav, který je aktuální v daném okamžiku.

Ve víc striktních jazycích (Haskell, Elm, ...) tohle neplatí. Tam ta garance je ještě tvrdší než v Elixiru. Proto jsem říkal, že v různých je zycích je "míra imutability" (a tím i míra platných garancí) různá.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #517 kdy: 28. 01. 2017, 12:44:02 »
To vypadá dobře. I když implementovat asynchronní v synchronním jde tady.
Jde, ale je to míň praktické - musím pro každé volání rezervovat thread/process. Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".
To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.

Re:Dědičnost dnes
« Odpověď #518 kdy: 28. 01. 2017, 12:44:28 »
Tail-call je o optimizaci návratu po návratu. V uvedeném příkladu zavolání loop(něco) se odnikud nevrací, naopak buďto je to rekurze a zásobník roste, nebo je to skok a stejně je třeba vytvořit nový kontext, ale starý je zahoditelný.
Ano, starý kontext se zahazuje v případě, že dojde ke změně stavu. Tím se to liší od těch monád, kde jde spíš o f(g(h(x))).

Re:Dědičnost dnes
« Odpověď #519 kdy: 28. 01. 2017, 12:52:36 »
To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.
Myslel jsem prostředky toho jazyka samotného. Pokud mám fci, která blokuje, třeba http_get_content(uri), tak programátorskými prostředky (uvnitř jazyka) z ní asynchronní neudělám jinak než (pseudokód):
Kód: [Vybrat]
start_thread(fun(){
  content = http_get_content(uri)
  do_something_with(content)
})
this_is_not_blocked(x,y,z)

Maximálně bych mohl mít v jazyce nějakou spešl konstrukci, která se vnitřně přeloží nějak speciálně, třeba samostatná vlákna runtime simuluje v rámci jednoho vlákna, ale to je z louže pod okap... Ta situace s asynchronností jako defaultem mi prostě přijde lepší (YMMV).

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #520 kdy: 28. 01. 2017, 12:56:42 »
To není tak úplně pravda, stačí jen vytvořit/přepnout kontext, podobně jako v Go, kde klidně může běžet plně asynchronní program na jednom vlákně. V C by se to dělalo typicky přes ucontext. Pak se dá snadno napsat kupříkladu něco jako node.js bez callbacků.
Myslel jsem prostředky toho jazyka samotného. Pokud mám fci, která blokuje, třeba http_get_content(uri), tak programátorskými prostředky (uvnitř jazyka) z ní asynchronní neudělám jinak než (pseudokód):
Kód: [Vybrat]
start_thread(fun(){
  content = http_get_content(uri)
  do_something_with(content)
})
this_is_not_blocked(x,y,z)

Maximálně bych mohl mít v jazyce nějakou spešl konstrukci, která se vnitřně přeloží nějak speciálně, třeba samostatná vlákna runtime simuluje v rámci jednoho vlákna, ale to je z louže pod okap... Ta situace s asynchronností jako defaultem mi prostě přijde lepší (YMMV).
Jen jsem upozornil, že to nemusí být vlákno, tedy místo start_thread je obecně start_routine (viz. obecněji concurrency vs. parallelism).

Re:Dědičnost dnes
« Odpověď #521 kdy: 28. 01. 2017, 12:58:32 »
Jen jsem upozornil, že to nemusí být vlákno, tedy místo start_thread je obecně start_routine (viz. obecněji concurrency vs. parallelism).
Souhlas, dík za doplnění. Nic to ale nemění na tom, že:
Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #522 kdy: 28. 01. 2017, 13:12:49 »
Jen jsem upozornil, že to nemusí být vlákno, tedy místo start_thread je obecně start_routine (viz. obecněji concurrency vs. parallelism).
Souhlas, dík za doplnění. Nic to ale nemění na tom, že:
Proto je defaultní asynchronnost lepší, protože asynchronní je prostě asynchronní a pokud chci blokovat, tak blokuju přímo ve vlákně volajícího, něpotřebuju nic "navíc".
To mi přijde trochu subjektivní, protože i blokování je věc runtimu, ale pravda je, že příslušný kód je trochu přímočařejší. I když pokud má jazyk/runtime třeba channels, tak to vyjde nastejno i v opačném směru, asynchronizační funkce vrátí "channel rettype" a hodnotu si pak přečtu asynchronně, ale kód vlastně bude vypadat synchronně.

Re:Dědičnost dnes
« Odpověď #523 kdy: 28. 01. 2017, 13:14:17 »
Nevim, mě na tom nic složitého nepřijde a dá se to snadno pochopit i bez znalostí tuny teorie. IMHO to spousta lidí používá v praxi i mimo FP aniž by znali pojem monáda (což bude asi největší problém, že neznají pojem a ne myšlenku). Např. optional template v boostu.
Už jsme se tady o tom bavili spoustukrát, tak to nechci rozpitvávat, ale jednu poznámku si dovolím (opakovaně): koncept monády je obecný koncept, který má mnoho instancí. "Chápat monády" znamená chápat ten obecný koncept, chápat, že jeho jednotlivé instance mají nějaké společné vlastnosti, že je to z nějakého pohledu totéž. Např. že list, maybe a future mají stejný princip. A to je úplně něco jiného než umět používat list nebo future.

To, cos řekl, je úplně to samé, jako bys řekl:
Citace
Spousta lidí používá v praxi sčítání aniž by znali pojem monoid.
...jistě. Protože chápat sčítání a chápad monoid jsou dvě dost rozdílné věci.

Moc se mi líbilo, když Evan Czaplicki (autor jazyka Elm) říkal (volně):
Citace
- Nemluvme o monádách! Vůbec ten pojem nepoužívejme, mluvme o x,y,z...
- Ale jak pak pojmenujeme jejich společné vlastnosti?
- Jejich společné vlastnosti samozřejmě jsou "monáda", my o nich ale nepotřebujeme mluvit.


Re:Dědičnost dnes
« Odpověď #524 kdy: 28. 01. 2017, 13:19:46 »
I když pokud má jazyk/runtime třeba channels, tak to vyjde nastejno i v opačném směru, asynchronizační funkce vrátí "channel rettype" a hodnotu si pak přečtu asynchronně, ale kód vlastně bude vypadat synchronně.
Jo, channel tam vlastně sehraje úlohu toho "asynchronizačního bufferu". Pořád je to ale to "něco navíc", co musím někde vytvořit, má to (aspoň teoreticky) nějakou režii, nějak to komplikuje kód. Přijde mi daleko přímočařejší kód, který když nechci, aby blokoval, tak nedělám nic, když chci, aby blokoval, tak prostě čekám na místě, dokud nedojde k události. Vytvářet thread/rutinu/channel kvůli jednomu volání je prostě (pocitově) pro mě míň estetické ;)

...ale to jsme se dostali do zbytečných detailů, myslím, že si rozumíme a nejsme v žádném sporu :)