Co si myslíte o OOP?

[v]

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.

zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python

[Reklama]

[Kadet]

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.

[Kadet]

Moje zavery nejsou zavery ale pouze tvrzeni ktera jsou pokud mozno vyvratitelna (falsifiability). Jinak receno jdu s kuzi na trh a usnadnuju vam ostatnim mi moje tvrzeni lehceji vyvratit.

Rad bych aby mi moje tvrzeni lidi zacali rozebirat na padrt a konstruktivne vyvracet. Casto moje 'zavery' zde ale ocividne lidi urazi.

Aplikace postavena na posilani zprav. To je pohled na vec, ne vec implementace. Kdyz mam distribuovany system z vic pocitacu, tak mi nezbyde nez mezi nimi skutecne poslat pres sit nejakou zpravu. Kdyz se podivam dovnitr jedny masiny nebo dovnitr konkretniho programu, muzu rict, ze zavolani metody je taky poslani zpravy.

No jak mam polemizovat s tim, ze objekt je dict a trida zbytecny syntakticky cukr? Jako zjednoduseni to nejaky smysl dava, prehlednou syntaxi mam vysoko v osobnich prioritach, proc se o to hadat v situaci, kdy je Tvuj nazor dost minoritni a vyvoj jde jinudy (podobne v kauze prototypy, kde Self a spol. evolucne prohravaji).

Zpravu ja si predstavuju ve smyslu pozdni vazby - mam nejaky dohodnuty protokol a pres obecny komunikacni kanal poslu zpravu a doufam, ze ji prijemce porozumi. Volani funkce v situaci, kdy mi to validuje kompilator nebo linter, je trosku neco jineho. Nemam potrebu se na to divat jako na komunikaci autonomnich objektu, protoze funkcim vidim pod prsty. Predstavovat si to muzeme ruzne, o tom zadna.

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

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.

Kratkodobe vyhrava tenhle majoritni ovci nazor ale kdyz se vlastne sam zabije tim ze poskace ze skaly, dlouhodobe to zas takova konkurence neni.

Ano, nekdy se pohled na system jako mnozinu komunikujicich objektu hodi, jindy ne. Za me je to pouze pohled na vec. Pohled jak probiha vypocet. Muzu vzit jakykoliv system, i ten kde nikdo s zadnym posilanim zprav nepocital, a videt v nem posilani zprav.

[operator]

Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.

Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.

V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.

Uvedomujes si, ze si protirecis?

Vadi ti syntakticky cukr a zaroven ti vadi, ze ind si vybere modul nebo tridu. Kdyz budes mit jazyk, kde si budes muset objekty implementovat sam z dictu, tak ten ind je bude zarucene implementovat jinak nez ty a tech moznych implementaci nebude jen trida nebo modul, bude jich prakticky nekonecne mnoho. Modul nebo trida,vto jsou ruzne abstrakce a ma smysl je mit. Ale mit nekonecne mnoho implementaci te same abstrakce, to smysl nedava. To je jeden z duvod, proc v pythonu pouzivas standardizovanou abstrakci class a ne vlastni reseni postavene nad dicty i kdyz muzes. Aby ses jednoduseji domluvil. Vsechno co ti zjednodusuje pouziti jazyka je uzitecne, nikoliv nadbytecne.

Mohl bys mi ukazat konkretni dve teze ve kterych si protirecim?

Ta spoluprace s indem je organizacni problem. Pokud ho nedokazu vyresit na urovni lidi tak me zadna trida nebo modul nespasi jinak pozdrav panbu. Vratim se k moji starsi tezi. Praseci kod a vic lidi co na nem pracuje? Vyres nejdriv problem praseciho kodu nez budes hledat nastroj co omezi ostatni cleny tymu tak aby neudelaly radsi zadnou chyby a taky zadny pokrok.

Ja v pythonu classy ani pokud mozno nepouzivam btw. Pro me je python jen host language pro vytvoreni lepsiho jazyka (embedded dsl), napr. proto ze python ma dobrej ekosystem knihoven.

Protirecis si  ve svych pozadavcich a jejich dusledcich. Odmitas vyssi abstrakci v jazyce, prijde ti zbytecna, kdyz tehoz muzes dosahnout existujicimi prostredky, byt sloziteji. A zaroven si stezujes na slozitost, ktera ti stezuje spolupraci s indem. Kdyz ti vadi vyssi pocet abstrakci zavedenych do jazyku, mel by ti idealne vyhovovat lisp, ale myslim ze ve skutecnosti i s nim bys mel problemy.

Ze v pythonu nepouzivas tridy muze mit ruzne duvody, namatkou neresis ulohy, kde je jejich pouziti vyhodne, nebo je neumis pouzivat a nebo jejich pouzivani odmitas z ideologickych duvodu. At tak nebo tak, Pythonu je to jedno a umoznuje ti psat dobre programy i bez toho.

[operator]

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.

zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python

Mozna jo, ja ho neznam. Ale ziskal jsem dojem, ze v nem nejde psat jinak nez funkcionalne a ze se v nem proto nejde vyjadrovat objektove nebo proceduralne.

[Reklama]

[v]

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.

zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python

Mozna jo, ja ho neznam. Ale ziskal jsem dojem, ze v nem nejde psat jinak nez funkcionalne a ze se v nem proto nejde vyjadrovat objektove nebo proceduralne.

je to čistě funkcionální jazyk, ale neřekl bych, že to brání objektovému (YMMV...) nebo procedurálnímu (tomu určitě ne) programování

[BoneFlute]

proto chapu, ze nekteri Haskell opevuji, kdyz maji pracovat treba s Indy.

Kdyby jen s Indy.

[Inkvizitor]

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.

Kratkodobe vyhrava tenhle majoritni ovci nazor ale kdyz se vlastne sam zabije tim ze poskace ze skaly, dlouhodobe to zas takova konkurence neni.

Ano, nekdy se pohled na system jako mnozinu komunikujicich objektu hodi, jindy ne. Za me je to pouze pohled na vec. Pohled jak probiha vypocet. Muzu vzit jakykoliv system, i ten kde nikdo s zadnym posilanim zprav nepocital, a videt v nem posilani zprav.

Jsi si ale vedom toho, ze mit minoritni nazor jeste nutne neznamena mit lepsi nazor, vid?

[JSH]

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

[Mirek Prýmek]

Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.

Já bych to takhle příkře nestavěl. Skoro bych řekl, že naopak tenhle způsob dívání se na systémy se poslední dobou docela rozšiřuje, akorát ne na té "druhé nejnižší úrovní" (samotný programovací jazyk). Na vyšších urovních se mi ale zdá, že docela kvete.

Když se koukneš na RTOSy v embedded , tak tam jsou tasky, mezi kterými se předávají zprávy, základním stavebním kamenem. Stejně goroutiny/channely v Go, REST, microservices, ... Myslím, že ta základní cesta "rozdělíme velký systém na součásti, které spolu komunikují dobře definovanými zprávami" se naopak ukázal jako docela správná cesta - jiné způsoby ve velkých, masivně paralelních systémech dost naráží na limity toho, co jsme vůbec schopní umenežovat (z hlediska návrhu, implementace i provozu). Jak už jsem psal výš, i to rozdělení programu na dvě vlákna, která si předávají nějaká data, je vlastně ono.

Přijde mi, že OOP přišlo s hodně dobrou myšlenkou, akorát trochu moc brzo. To už se tak v IT docela často stává, že výborné myšlenky prvně zkrachují a za nějakých deset dvacet let bombasticky převálcují svět v mírně obměněné podobě

[Mirek Prýmek]

Stejně goroutiny/channely v Go, REST, microservices, ...

Jo, málem bych zapomněl na výpočetní clustery - tam to funguje už hodně dlouho - MPI, Hadoop, Spark, ... To je všechno o předávání zpráv mezi dost autonomními, "svéprávnými" jednotkami.

[Mirek Prýmek]

muzu rict, ze zavolani metody je taky poslani zpravy.

Říct to samozřejmě můžeš, ale naděláš tím víc škody než užitku, protože jsou to dva zásadně odlišné koncepty. Už jsme o tom tady mluvili: pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.

V nejčistší podobě je rozdíl vidět na multiagentních systémech, kde si skutečně inteligentní agenti jenom sdělují informace, upravují svoje lokální knowledge bases a podle jejich obsahu pak vyvijejí nějakou činnost.

[Inkvizitor]

Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.

Já bych to takhle příkře nestavěl. Skoro bych řekl, že naopak tenhle způsob dívání se na systémy se poslední dobou docela rozšiřuje, akorát ne na té "druhé nejnižší úrovní" (samotný programovací jazyk). Na vyšších urovních se mi ale zdá, že docela kvete.

Nedovedl jsem si predstavit, ze se zrovna Ty na tohle nechytnes. ;-) Mne slo hlavne o tu pozdni vazbu coby deklarovanou ctnost programovaciho jazyka (spolu se zapouzdrenim dat). Reseni konkurence a rozumnou dekompozici beru.

[Mirek Prýmek]

Haskell je prilis striktni, neodpovida lidske intuici

Z mýho pohledu hlavně většinové programátorské intuici neodpovídá líné vyhodnocování. Většina z nás začínala a nejvíc času strávila přemýšlením v intencích "algoritmus je posloupnost kroků [...]".

Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce.

Majoritní názor taky je, že je Země kulatá. Minoritní názor je, že je placka.

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

Ještě lepší je logický NOR, s ním si dospělej chlap vystačí

Nedovedl jsem si predstavit, ze se zrovna Ty na tohle nechytnes. ;-)

Tak jasně, pro mě je to prostě srdcovka. S multiagentními systémy jsem si pohrával ještě když jsem tahal kačera po škole

[Kadet]

muzu rict, ze zavolani metody je taky poslani zpravy.

Říct to samozřejmě můžeš, ale naděláš tím víc škody než užitku, protože jsou to dva zásadně odlišné koncepty. Už jsme o tom tady mluvili: pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.

V nejčistší podobě je rozdíl vidět na multiagentních systémech, kde si skutečně inteligentní agenti jenom sdělují informace, upravují svoje lokální knowledge bases a podle jejich obsahu pak vyvijejí nějakou činnost.

V tomhle jsme si predtim nerozumeli na stopro.

Bud mam asynchronni poslani zpravy. Fire and forget.

Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.