Co si myslíte o OOP?

Re:Co si myslíte o OOP?
« Odpověď #1170 kdy: 21. 01. 2019, 18:07:30 »
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.

BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
A hlavne, i kdyz pada, tak jen na semanticke chyby, a ty BoneFlute obecne nepocita :-).

Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.

To je pořád dokola tvůj strawman.


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Co si myslíte o OOP?
« Odpověď #1171 kdy: 21. 01. 2019, 18:19:43 »
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.

Kit

Re:Co si myslíte o OOP?
« Odpověď #1172 kdy: 21. 01. 2019, 18:24:23 »
Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
To je pořád dokola tvůj strawman.

Takže pokud aplikaci se statickými typy přeložíš, dáš ho s klidným svědomím bez vyzkoušení ihned na produkci?

Re:Co si myslíte o OOP?
« Odpověď #1173 kdy: 21. 01. 2019, 18:25:10 »
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.

Je to celkem prirozene pro nektere reprezentace grafu.

Re:Co si myslíte o OOP?
« Odpověď #1174 kdy: 21. 01. 2019, 18:25:35 »
Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
To je pořád dokola tvůj strawman.

Takže pokud aplikaci se statickými typy přeložíš, dáš ho s klidným svědomím bez vyzkoušení ihned na produkci?

Umis cist?


v

Re:Co si myslíte o OOP?
« Odpověď #1175 kdy: 21. 01. 2019, 18:26:25 »
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)

Kadet

Re:Co si myslíte o OOP?
« Odpověď #1176 kdy: 21. 01. 2019, 18:28:00 »
Paráda. Tákže:

Napr. zapouzdreni je vlastnost modulovyho systemu. Ktery si lidi casto pletou s objektovym. Nebo je to treba taky totez.
Imho znepřístupňovat vlastnosti a funkcionalitu má smysl na úrovni modulů i na úrovni tříd. Jsem zvyklý při zapouzdřování myslet hlavně na to znepřístupňování na úrovni tříd, ale musí se s tím velmi opatrně. Špatně se to pak jednotkově testuje (což se dá většinou obejít), ale hlavně to často není potřeba, pokud se dodržuje SRP.

Polymorfismus je zalezitost typovyho systemu. V dynamickym jazyku me tohle netrapi, ve statickym musim mit po ruce interfacy nebo abstraktni tridy.
V dynamickém jazyku mě právě trápí, že ten interface kolegové často použít nemusí a tím se zhoršuje orientace v kódu.

OO navrh je staticky pohled na relace mezi objekty. Taky znamo jako ER diagram.
Dostal jsi mě. Ale víš co jsem myslel.

Design patterny tohohle typu jsou take znamy jako 'chybejici vlastnost jazyka'. Tj. napr. namisto factory patternu muzu pouzit proste obycejnou funkci.

Viz http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
Asi úplně nerozumím argumentu. Místo factory patternu můžu použít i obyčejnou funkci. Můžu i nalinkovat funkčnost zkompilovanou z assembleru. Jsem programátor. Můžu cokoliv. :)

Dependency injection znamena 'posli mi objekt jako parametr, at si ho nemusim vytvaret sam'.
Tak hlavně by mělo platit, že ho nemůžu vytvářet sám. Protože v různých situacích chci různé implementace toho samého rozhraní. Tam kde ten objekt potřebuji, tak tam se nechci starat o to, jaká ta implementace to bude. Např. mock při jednotkovém testování. Nebo implementace pro konkrétní databázi, jako je to např v PDO v PHP.

Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.
SOLID je celá sada doporučení a težko se udělá příklad do jednoho komentáře. Ale benefity jsou např: Snadná znovupoužitelnost již naprogramovaného. Dobře testovatelné jednotkovými testy. Minimalizace stavů, kdy opravou jedné funkcionality rozbiji jinou.

Ale samozřejmě OOP může být dobrý sluha ale velmi zlý pán.

Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict

Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.


Pokud je problem ze kolegove nemuzou byt svazani sveraci kazajkou jazyka, jako v pripade chybejicich rozhrani v dynamickych jazycich, pak je to organizacni problem. V dynamickym jazyce bouchne driv nez ve statickym. Co je lepsi, tezko rict. Pro me je lepsi kdyz ten bolak praskne driv nez pozdeji a zacne se resit skutecny problem - spatna organizace lidi.

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.

O SOLID a dependency injection se hadat nebudu, nemam s tim zkusenosti. Ale prijde mi to zbytecne komplikovany.

Kadet

Re:Co si myslíte o OOP?
« Odpověď #1177 kdy: 21. 01. 2019, 18:50:14 »
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)

Diky za odkaz. Vic podobnych linku by sem mohli lidi hodit.

Projel jsem slidy toho jak funguje tahle algebraicka reprezentace grafu. Musel bych ale videt metodu jak reprezentovat libovolny netrivialni graf timhle zpusobem. Pak bych potreboval videt jak se nad tim delaji klasicky algoritmy, alespon pruchody grafem. Napada me z toho vygenerovat klasickou adjacency matici a pak s tim pracovat zase klasicky.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Co si myslíte o OOP?
« Odpověď #1178 kdy: 21. 01. 2019, 18:54:16 »
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)

Mohl by si se více rozepsat. Shodou okolností jsem zrovna nějaké to ASTčko nedávno dělal. A na žádný cyklický graf jsem nenarazil. Vždy jsem si vystačil se stromem. Buď jsem tak šikovnej (nepravděpodobné), nebo jsem se jen náhodou vyhnul nějakému scénáři... Předem dík.

v

Re:Co si myslíte o OOP?
« Odpověď #1179 kdy: 21. 01. 2019, 18:59:51 »
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)

Mohl by si se více rozepsat. Shodou okolností jsem zrovna nějaké to ASTčko nedávno dělal. A na žádný cyklický graf jsem nenarazil. Vždy jsem si vystačil se stromem. Buď jsem tak šikovnej (nepravděpodobné), nebo jsem se jen náhodou vyhnul nějakému scénáři... Předem dík.
a jo vlastně, to T v AST znamená strom :D
v mém scénáři začnu se strukturovaným AST (podmínky + cykly, fakt strom) a přeložím ho na seznam příkazů se skokama (tohle jsem měl původně na mysli, když jsem psal AST) a tady už jsou cykly kdy se příkaz skoku odkazuje na jiný příkaz ve stejném seznamu

v

Re:Co si myslíte o OOP?
« Odpověď #1180 kdy: 21. 01. 2019, 19:08:53 »
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)

Diky za odkaz. Vic podobnych linku by sem mohli lidi hodit.

Projel jsem slidy toho jak funguje tahle algebraicka reprezentace grafu. Musel bych ale videt metodu jak reprezentovat libovolny netrivialni graf timhle zpusobem. Pak bych potreboval videt jak se nad tim delaji klasicky algoritmy, alespon pruchody grafem. Napada me z toho vygenerovat klasickou adjacency matici a pak s tim pracovat zase klasicky.
paper není nezbytný k využití knihovny, tak jsem ho radši nečet, ale ten základní trik je vidět z deklarace typu:
http://hackage.haskell.org/package/algebraic-graphs-0.3/docs/src/Algebra.Graph.html#Graph
Kód: [Vybrat]
data Graph a = Empty
             | Vertex a
             | Overlay (Graph a) (Graph a)
             | Connect (Graph a) (Graph a)

Re:Co si myslíte o OOP?
« Odpověď #1181 kdy: 21. 01. 2019, 20:30:51 »
Je to pouzitelne. Pouzivam to bezne pri vyvoji webu. Main aplikace porovnava cas py a pyc souboru a kdyz je py novejsi, tak modul, typicky nejaky handler requestu, automaticky reloadne. Nemusim kvuli tomu restartovat celou aplikaci.
No jistě, funguje ti to proto, že handler requestu je "fire and forget". Pokud by to byl modul, který pořád běží (někdo někde, nikdo neví kde všude ho přímo nebo nepřímo používá), tak by ti to nefungovalo.

operator

Re:Co si myslíte o OOP?
« Odpověď #1182 kdy: 21. 01. 2019, 20:38:21 »
A hlavne, i kdyz pada, tak jen na semanticke chyby
Nikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
Logicke chyby povazuji za podmnozinu semantickych
Tak to považuješ chybně.
Nejsem si jist, ale doufal jsem, ze to reknes. Vyplyva z toho, ze zijes v domeni, ze kompiler ti diky statickym typum odchyti logicke chyby. Protoze jak jsi uvedl, po uspesne kompilaci je obecne vse hotovo, zbyvaji jen semanticke chyby.

operator

Re:Co si myslíte o OOP?
« Odpověď #1183 kdy: 21. 01. 2019, 20:39:51 »
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.

BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
A hlavne, i kdyz pada, tak jen na semanticke chyby, a ty BoneFlute obecne nepocita :-).

Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
To je pořád dokola tvůj strawman.
Neni, je to reakce na tvrzeni, ktere tu zaznelo.

operator

Re:Co si myslíte o OOP?
« Odpověď #1184 kdy: 21. 01. 2019, 20:44:23 »
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?