Co si myslíte o OOP?

[BoneFlute]

Metoda se staticky typovanym atributen tedy NEMUZE dostat nekorektni data ve smyslu, ze to neni objekt HttpRequest.

Je rozdíl mezi tím, když se s dotyčným objektem domluvíš na určitých podmínkách, a mezi tím, když se domluvíš na všech (Haskell) a na ničem (Python).

Aktory jsou mezi sebou (často fyzicky) nezávislí. Ty můžeš tomu objektu poslat zprávu, která bude zcela korektní, ale v tom danném okamžiku (0:52hodin) prostě ten aktor tu zprávu nezná. Ale třeba od od 4:00 už jo.

Je pak otázka, co znamená to "nezná". Proč, a jak se to projevuje.

[Reklama]

[Kadet]

Nejak me ta nase rozprava nad posilanim zprav mate.

Mluvime o fyzicky oddelenych systemech a jak orchestrovat jejich komunikaci? Nebo nas orchestrace vubec nezajima, ale dulezity je, ze se mezi sebou nejak domluvi a dosahnou vysledku autonomni choreografii?

Na oddelenych systemech kompiler nepomuze obavam se. Mozna TLA+?

Orchestrace - nejakej treti dirigent to koordinuje
Choreografie - agenti se koordinujou sami mezi sebou

[operator]

Metoda se staticky typovanym atributen tedy NEMUZE dostat nekorektni data ve smyslu, ze to neni objekt HttpRequest.

Je rozdíl mezi tím, když se s dotyčným objektem domluvíš na určitých podmínkách, a mezi tím, když se domluvíš na všech (Haskell) a na ničem (Python).

Python neni pripad, ze se nedomluvis na nicem. U pythonu mas domluvenu jednu zasadni vec, ze vsechno je objekt, tj. vsechno ma nejaky zakladni protokol pomoci ktereho umi kazdy komunikovat s kazdym, treba se ho zeptat na identitu a dalsi veci a kazdy na to umi odpovedet.

[operator]

Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.

Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál

Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).

Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

[operator]

P.S. pokud je to potřeba vyloženě polopaticky:

Mezi voláním metody a předáním zprávy je podobný rozdíl jako mezi voláním metody a HTTP requestem. Pokud někdo bude tvrdit, že volání metody a HTTP request je totéž, tak podle mě jenom zbytečně mate pojmy. Vyvrátit se mu to ale nedá, protože ten člověk prostě jenom zbytečně označuje dvě meritorně rozdílné věci (neobvykle) stejným slovem. Jeho věc.

Rozdil je technicky, u posilani zprav muzu komunikovat skrze ruzna rozhrani, treba i socket a mit tak distribuovany system, za tuto flexibilitu se, jako vzdy, plati vykonem a navic je to komplikovanejsi na spravu. Jaky je v tom rozdil ale pro navrh programu? Imho zadny, protoze z pohledu abstrakce je to to same. Tedy v pripade, ze se bude jednat o objekty v ramci jednoho programu.  U distribuovaneho systemu me to bude nutit delat co nejvetsi objekty s co nejdelsi zivotnosti.

[Reklama]

[operator]

Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?

V důsledku by to znamenalo, že by každý klient musel přesně vědět, na co se smí kterého serveru zeptat. Ostatní požadavky by musel ten klient stornovat ještě před jeho odesláním. Tohle může splňovat tzv. tlustý klient.

Vlastně to můžeme zobecnit, že u statického typování je klient tlustý, ale server tenký. U dynamického typování je tomu naopak.

To je dobry postreh, ktery by nekomu mohl pomoci pochopit vyhody dynamickeho programovani.

[operator]

Jak? Funkcionalitu tridy muzes implementovat skrz prototypy. Prototypy muzes implementovat skrz dicty. Ergo dict je obecnejsi abstrakce nez trida.

Tahle logika kulhá na všechny čtyři. Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).

Super, tak na tom postav intuitivni programovaci jazyk a budes mit perfektni system.

To same lze doporucit i tobe, akorat s dicty :-). Implementovat tu mou ukazku jen pomoci dictu se asi nikdo ani nepokusi, co? Beru to jako dukaz toho, ze vyssi abstrakce ma smysl a neni nadbytecna.

[operator]

Sproste slovo.. to zalezi na pohledu pozorovatele. Ja hovorim neutralne pokud mozno.

Syntakticky cukr je tady jako kafe nebo jako droga. Kafe ti umozni zustat vzhuru dele dneska, ale na ukor spanku zitra. Cukr ti umozni pochopit jazyk driv dneska ale na ukor toho, ze kdyz budes chtit udelat neco slozitejsiho, tak to nepujde, protoze jazykove bozstvo rozhodlo, ze se budou pouzivat classy a ne nic jinyho.

Marketing je pozitivni, jeho smyslem je efektivne investovat zdroje. V pripade jazyka by tedy mel vest k vyvoji smerem, po kterem je nejvetsi poptavka, ktery ten jazyk nejlepe zhodnoti. Pokud je to jinak, neni to kvuli marketingu, ale jeho absenci. V lepsim pripade jsou zdroje promarneny, v horsim to jazyk pokazi a bude opusten.

Syntakticky cukr neni ani jako kafe ani jako cukr. Ani jedno neni zavedeni zjednodusujici abstrakce, ani jedno z toho nesnizuje slozitost systemu. Python neni Haskell, tam ti zadne bozstvo neprikazalo pouzivat classy a nic jineho. A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.

Neshodnem se na vyznamu slova marketing. Ja pod marketingem chapu sales operaci s sirokym zaberem, tj. ne obvolavani jednotlivych klientu, ale neco co ma dosah k tisicum az milionum. V marketingu te nezajima kvalita produktu. Jediny cil je prodat. At uz je to smejd nebo super produkt, ktery se pak ale vetsinou prodava sam. Trh kratkodobe reaguje na marketing, ale dlouhodobe vyhrava lepsi produkt.

Analogie s kafem a drogou byla ve smyslu Chci neco ted hned ale rozesere me to pozdeji.
cukr, kafe, droga, dluh, vyber si

Python, Haskell, Javascript. V kazdem bozstvo rozhodlo jaky bude syntax. Rozhodli se ho udelat citelnejsi pro blbecky za cenu flexibility pro pokrocilejsi uzivatele. Podle me spravne rozhodnuti z pohledu adopce uzivateli ale schazi na trhu nastroje pro power usery.

Souhlasim, ze Haskell je prilis striktni, neodpovida lidske intuici, pusobi jako sveraci kazajka. Na druhou stranu clovek v sveraci kazajce nenadela prilis skody okolo, proto chapu, ze nekteri Haskell opevuji, kdyz maji pracovat treba s Indy.

V marketingu te kvalita produktu zajima, ale nema absolutni prioritu. Zvazuji se i dalsi aspekty. Ve vysledku se v idealnim pripade na kvalitu klade takovy duraz, jaky na nej kladou zakaznici. Ano, vyhrava lepsi produkt, ale to nutne neznamena ten nejkvalitnejsi.

Ta analogie nedava smysl. Syntakticky cukr tu neni proto, ze chceme neco rychle bez ohledu na nasledky, neni to vykonova optimalizace. Je tu pro zjednoduseni sloziteho.

Ano, bozstvo rozhodlo o syntaxi. Jde snad navrhnout jazyk bez syntaxe? Rozhodli se ho udelat citelnejsi (a jednodussi) pro vsechny, to vyuziji jak blbecci, tak chytraci. Nedava smysl navrhovat necitelny jazyk, kdo by o nej stal? A pokud nejaky takovy masochista existuje, muze se realizovat ve strojovem kodu, tam si te necitelnosti uzije do sytosti. Neni pravda, ze je to za cenu flexibility. Porad mluvis o dictech. Tak v pythonu implementuj tu mou ukazku pomoci dictu. Uvidis sam, ze je to pomoci nizsi abstrakce mnohem pracnejsi a neprehlednejsi. Nechapu, jakou v tom vidis vyhodu? Jediny validni argument je vykon. Ale i ten, v pripade interpretovanych jazyku, hovori pro vyssi abstrakci.

Jak by sis takovy flexibilni nastroj pro power usery predstavoval?

[operator]

Minoritni nazor. Tohle by bylo dobry tema. Mas pravdu ze muj nazor je minoritni. Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce. Takova ovce nasleduje druhou ovci az se nasleduje cely stado a nakonec poskacou vsichni se srazu. Bud doslova nebo v nejaky financni krizi spadnou na hubu v akciich, nemovitostech, apod.

Jestli mohu doporucit, utvor si a zastavej vlastni nazory a neres, jestli jsou majoritni nebo minoritni, protoze oboji muze byt chybne i spravne.

[Mirek Prýmek]

Rozdil je technicky, u posilani zprav muzu komunikovat skrze ruzna rozhrani, treba i socket a mit tak distribuovany system, za tuto flexibilitu se, jako vzdy, plati vykonem

To je pravda.

a navic je to komplikovanejsi na spravu.

Ne vždycky, záleží na okolnostech.

Např. v Erlangu je datový typ "Process Identifier" (PID), který se používá jako identifikátor adresáta zprávy a vždycky obsahuje i jakousi "adresu" VM, na které proces běží (v erlangovské terminologii "node"). Takže pokud chce proces A poslat nějakou zprávu procesu B, tak vůbec neřeší, kde B fyzicky běží - kód je stejný pro lokální i vzdálené volání. V principu tak můžeš libovolný proces vzít a přesunout někam jinam, bez změny kódu. Kdybys chtěl tohle udělat v systému s voláním metod, musíš mezi A a B vrazit dvě proxy. V nejhorším myslitelném případě dokonce specializované právě pro ten konkrétní objekt (call stub) a při jakékoliv změně B proxy taky překompilovat (to je pro správu dost peklo).

A tohle je právě jeden z technických důsledků toho zásadního rozdílu - předání informace se velice snadno zakóduje jakkoli (request může putovat klidně třeba mailem a A vůbec nepozná rozdíl), zatímco volání metody typicky využívá přímo instrukce procesoru, takže pokud chci udělat RPC, musím tam vrazit nějakou proxy, která to nafejkuje.

V praxi to pak dopadne tak, že když se rozhodneš monolit rozsekat na nějaké microservices (protože chceš mít tenhle buzzword v letáku), musíš:

1. systém zásadně přepsat (málo kdo to umí napsat dobře, protože to není triviální)
2. nemáš moc způsob, jak komunikaci sjednotit, takže skončíš s nějakým hrůzostrašným HTTP/JSON
3. ve finále teda jak blázen pořád převádíš interní datové struktury do JSONu a zpátky, což je ideální příležitost na domrvení dat, a třetinu energie spálíš na dumání nad tím, jak designovat HTTP endpointy
4. celé je to děsivě náročný proces jak z hlediska nároků na kvalitu designu/analýzy, tak z hlediska řízení exekuce

Srovnej s tím, že v Erlangu jenom tak "mimochodem" napsali distribuovanou databázi (Mnesia) s dost pokročilými vlastnostmi (failover, dynamické přidávání a odebírání nodů, změny způsobu replikace za běhu, ...), která je přímo součástí standardní knihovny. Protože jakmile máš podvozek, který umí skvěle distribuovat sám o sobě, není ta úloha tak těžká, spoustu problémů ti odpadne. Srovnej s mainstreamovými RDBMS, kde udělat to samý je na desetiletí a Turingovu cenu pro hlavního designéra...

(Samozřejmě, Mnesia má svoje problémy, netvrdím, že je to všespásné řešení, ale přijde mi to jako dobrá ilustrace)

Jaky je v tom rozdil ale pro navrh programu? Imho zadny, protoze z pohledu abstrakce je to to same. Tedy v pripade, ze se bude jednat o objekty v ramci jednoho programu.  U distribuovaneho systemu me to bude nutit delat co nejvetsi objekty s co nejdelsi zivotnosti.

I v rámci jednoho programu je rozdíl zásadní - buď píšu autonomní objekty, které se samy rozhodují, nebo píšu tupé recepty "když X, tak Y".

[operator]

A tohle je právě jeden z technických důsledků toho zásadního rozdílu - předání informace se velice snadno zakóduje jakkoli (request může putovat klidně třeba mailem a A vůbec nepozná rozdíl), zatímco volání metody typicky využívá přímo instrukce procesoru, takže pokud chci udělat RPC, musím tam vrazit nějakou proxy, která to nafejkuje.

Ale tohle je jen technicky problem, nijak to nemeni abstrakci objektoveho programovani. Volani metod nebo posilani zprav jsou jen ruzne formy komunikace. Je to podobne jako staticke/dynamicke typy. Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.

[Mirek Prýmek]

Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.

Ale jistě, pokud chceš, můžeš všechno. Ale pokud máš nějaké prostředky, tak jim design přizpůsobuješ. Pokud máš jako hlavní prostředek volání metod, tak se ti prostě nebude chtít jít třeba do té distribuovanosti (a je to racionální). Navíc tě to bude motivovat udělat rozhraní objektu určitým způsobem.

Jinými slovy: pokud sis zvolil menší flexibilitu, nebudeš dělat designová rozhodnutí, která by se dobře implementovala jedině v systému s větší flexibilitou. Ne že by to nešlo, ale "nazapadá to do sebe", nemělo by to logiku.

...no a protože mainstream staví jednoznačně na volání metod, tak se v sw inženýrství prosadily metody, které tomu odpovídají. A teprve teď, později, se učíme, jak se vlastně ty víc flexibilní systémy designují a implementují (to jsou právě třeba ty microservices, které jenom málo kdo dokáže navrhnout dobře, aniž by to udělal úplně tupě).

[operator]

Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.

Ale jistě, pokud chceš, můžeš všechno. Ale pokud máš nějaké prostředky, tak jim design přizpůsobuješ. Pokud máš jako hlavní prostředek volání metod, tak se ti prostě nebude chtít jít třeba do té distribuovanosti (a je to racionální). Navíc tě to bude motivovat udělat rozhraní objektu určitým způsobem.

Jinými slovy: pokud sis zvolil menší flexibilitu, nebudeš dělat designová rozhodnutí, která by se dobře implementovala jedině v systému s větší flexibilitou. Ne že by to nešlo, ale "nazapadá to do sebe", nemělo by to logiku.

...no a protože mainstream staví jednoznačně na volání metod, tak se v sw inženýrství prosadily metody, které tomu odpovídají. A teprve teď, později, se učíme, jak se vlastně ty víc flexibilní systémy designují a implementují (to jsou právě třeba ty microservices, které jenom málo kdo dokáže navrhnout dobře, aniž by to udělal úplně tupě).

Vzhledem k tomu, ze to neni zadarmo, tak tu distribuovatelnost chci jen v pripade, ze ji potrebuji a ne pro strycka prihodu co kdyby. Protoze zpomalit si signifikantne system jen pro strycka prihodu nedava smysl. Kdyz dospeju k tomu, ze distribuovatelnost potrebuji, stejne ji z toho duvodu zaridim jen mezi objekty, ktere ji potrebuji a ne mezi vsemi. Jo, neni to tak flexibilni, ale za to je to pouzitelne. Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.

Ano, volani metod je omezujici, omezeni je vlastnosti efektivity. To same se tyka statickych a dynamickych typu, vykon s omezenim nebo flexibilita s pomalosti. Volani metod misto posilani zprav neni chyba, je to racionalni  rozhodnuti. Cas pro masivni posilani zprav prijde az s technologickym vyvojem IT, kdy nebude problem udrzovat statisice otevrenych spojeni a nebo je budeme umet navazovat bez ekonomicky podstatneho zpozdeni. Stejne jako cas dynamickych jazyku prisel az s tim, kdy vykon byl natolik levny, ze jejich pomalost prestala byt probkem a vyhoda jejich flexibility ekonomicky vyvazila nutnost vyssiho vykonu cpu.

[operator]

...no a protože mainstream staví jednoznačně na volání metod, tak se v sw inženýrství prosadily metody, které tomu odpovídají. A teprve teď, později, se učíme, jak se vlastně ty víc flexibilní systémy designují a implementují (to jsou právě třeba ty microservices, které jenom málo kdo dokáže navrhnout dobře, aniž by to udělal úplně tupě).

To je proste proces. Az to bude v praxi pouzitelne a prinosne, tak se s tim lide nauci pracovat. Ne vsichni, nekteri zustanou zamrzli na oop realizovanem pomoci metod, stejne jako nekteri zustali zamrzli na statickych jazycich. Tak to proste je.

[Mirek Prýmek]

Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.

To ani není nutně potřeba. Zase příklad z Elixiru: komunikace pomocí zpráv se dělá jenom mezi procesy. V rámci jednoho procesu se dělá (víceméně) standardní volání funkcí.

Jinak ale celkem souhlas se vším, co píšeš.