Dědičnost dnes

[javaman ()]

Rozhodně. Jenže na tom taky OOP založeno není, ačkoli si to většina lidí zblbnutých javským a cépluspluskovým pojetím myslí. Objektový program jsou škatulky, které si vzájemně vyměňují zprávy, a pochopení tohoto konceptu zpráv je naprosto klíčové k správnému pochopení celého objektového programování, protože právě v tom vězí celá ta síla a tvárnost.

No právě. Jenže většina těch nesmyslných nekonečných debat "o OOP" jsou právě debaty o tom co je "správné" dědit z čeho a jestli je "správné" mít k atributům accessory... Prostě nudné, zbytečné pseudoproblémy, které vnějšího pozorovatele vedou k úvaze, jestli (takhle chápané) OOP víc problémů nepřináší, než jich řeší...

Když to celé někdo (autoři C++, autoři Javy) nesprávně pochopili a nesprávně implementovali, tak je taková úvaha správná. Jenže to se pak nebavíme o objektovém, ale o jakémsi podtřídně-typovém programování.

Pak nám ovšem vyvstává otázka, jestli neexistují jiné, "neobjektové" způsoby modelování, které problém neřeší elegantněji

Možná jo, i když za těch 30 let, co se motám kolem počítačů, už na žádné zázračné stříbrné kulky, co dokážou skolit každý problém jedinou ranou, fakt věřit nezačnu. Jednu nesnáz vyřeší, další dvě způsobí. Ale když už porovnávat a vylepšovat, tak pro boha ne s javským (nebo nedej bože dokonce C++kovým), ale se smalltalkovským pojetí OOP. Pak totiž třeba přijdeš na to, že všechny ty pseudoproblémy OOP jsou ve skutečnosti problémy Javy nebo C++ a jejich podtřídně-typového programování, ale ne samotného objektového programování, s nímž mají společnou vážně jen možnost odvozovat podtřídy.

Spíše jestli to nechápeš špatně ty. Proč se teda ten tvůj Smalltalk a dynamické typování skoro na nic nepoužívá? Pochybuju, že tvůrci C++ a Javy byli úplně mimo a nic nechápali. Neříkám, že musejí být lepší než ty, ale podle těch tvých hlášek tady pochybuju, že bys uměl programovat. Pokud máš problém jen s tím, že Java je OOP, tak je na čase si to tu pro tu debatu trochu změnit.

Takže ještě jednou, proč se používá skoro na všechno Java, když je tak špatná? Dyť by ti podnikatelé raději mohli ušetřit a prodávat luxusní věci, ne? Neříkám, že je úžasná na všechno, ale ty máš určitě hromadu lepších přístupů, které plno problémů odstraní. A nebo jsi jen nic pořádného nedělal, nevím.

[Reklama]

[balki]

JS, poprosim k Vasim tvrdeniam literaturu. Funkcionalne programovanie je momentalne moje hobby, a rad by som si teda precital.

• o tom, ako je enkapsulacia zbytocna
• ako robi FP zo vzorov trivialne veci, co nemaju pomenovanie
• ako robia abstrakcie funkcionalneho programovania objektove abstrakcie zbytocnymi

Potom budem schopny polemizovat, lebo zatial nechapem suvislosti.

Dakujem

Ahoj,
mrkni na přednášku https://www.youtube.com/watch?v=Rmer37g9AZM , mohlo by to být pro tebe zajímavé.

Dik pozrem, aj ked to vyzera ako convention a nie seriozna konferencia. Mozno bude mat nejaky point.

[javaman ()]

...Ale ten standard povědomí o OOP, který nastavilo především C++, je prostě k zblití...

Jinak řečeno se jedná o únos termínu OOP.

Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká

[SB]

Ach jo. Tento akademický pseudoproblém je dobrý jen k tomu, aby poukázal na fakt, že v různých případech se mohou hodit různé přístupy. Ne, že jeden je dobře a druhý špatně, nebo snad že to je neřešitelný problém. Tím méně to představuje problém u matic...

Já bych ani neřekl, že je to pseudoproblém. Není to náhodou spíš narážka na to, že můžu mít objekty/třídy A a B, které se mi zdají nějak související/podobné, ale z nějakého pohledu má A o pár vlastností navíc, z jiného má o pár vlastností navíc B a do toho všeho nejsem schopný jejich společnou podmnožinu nějak rozumně nazvat?

Jinými slovy: modelování světa do stromu, kde děti mají vždycky jenom jednoho rodiče a vždycky se jenom specializují, je prostě trochu problematický, reálnýmu světu to moc neodpovídá

Kiwi to napsal dobře.
Problém je hlavně v tom, že když se něco "zdá", tak to ještě nemusí znamenat "je". To je příčina, na kterou obvykle dojedou začátečníci.
Nikdo přece nevyžaduje, aby všechny třídy byly v jednom stromu.

[balki]

JS, poprosim k Vasim tvrdeniam literaturu. Funkcionalne programovanie je momentalne moje hobby, a rad by som si teda precital.

• o tom, ako je enkapsulacia zbytocna
• ako robi FP zo vzorov trivialne veci, co nemaju pomenovanie
• ako robia abstrakcie funkcionalneho programovania objektove abstrakcie zbytocnymi

Potom budem schopny polemizovat, lebo zatial nechapem suvislosti.

Dakujem

Ahoj,
mrkni na přednášku https://www.youtube.com/watch?v=Rmer37g9AZM , mohlo by to být pro tebe zajímavé.

Dik pozrem, aj ked to vyzera ako convention a nie seriozna konferencia. Mozno bude mat nejaky point.

Jedine co robil bolo, ze vyberal spravanie s objektov. Nic zaujimave. Ziadna analyzu ci spravil identicku vec nebola. Len to skonstatoval.

[Reklama]

[SB]

Ani nemůže být hlavním proudem, protože OOP navážno je okrajovou záležitostí. Na druhou stranu je neuvěřitelné, že za 35 let nebyl Smalltalk nejen překonán, ale ani dohnán. Svědčí to 1. o jeho nadčasovosti, 2. o stavu SW inženýrství dnes.

3. že oop je slepá ulička

Tak pro někoho každopádně.

[javaman ()]

Jedine co robil bolo, ze vyberal spravanie s objektov. Nic zaujimave. Ziadna analyzu ci spravil identicku vec nebola. Len to skonstatoval.

Taky ti trochu uniká, co se tu vlastně řeší? Když tu někdo ukáže "lepší" přístup, tak má zase hromady jiných problémů. A zároveň dnešní OOP se ukazuje jako velmi dobré i na obrovské věci.

[SB]

Nuda, operujete tu s terminom "ciste oop", ani poriadne neviete podlozit, co to je. Termin dynamicky typovany je oproti roznym "pozdnim vazbam" a podobnym laxne definovanym frikulinstinam bezne zauzivana terminologia.  Tu je clanok z root https://www.root.cz/clanky/staticka-dynamicka-typova-kontrola/.  Tu je wikipedia  https://en.wikipedia.org/wiki/Type_system. Literaturu smalltalkarov som cital v ramci studia, ale iba seriozne publikacie.

Na tohle fakt nemám.

[SB]

"Tak nějak celé immutable" nevím, co znamená. V čistém FP jsou data immutable a ohledně fcí platí referenční transparentnost. Tyhle dvě věci asi celkem stačí na popis toho, o co jde, víc není potřeba říkat.

Jak (čistě funkcionální) celej přechází mezi stavy už tady bylo řečeno víckrát: "uvnitř jazyka" nic nikam nepřechází, protože celý systém je de facto čistě statický. To, co nějak mění stav, je runtime (na základě těch statických instrukcí).

Supr, tak se k tomu začínáme posunovat: V runtime se nějakým způsobem udržují stavy. Od tohoto se můžeme odpíchnout.

[balki]

Jedine co robil bolo, ze vyberal spravanie s objektov. Nic zaujimave. Ziadna analyzu ci spravil identicku vec nebola. Len to skonstatoval.

Taky ti trochu uniká, co se tu vlastně řeší? Když tu někdo ukáže "lepší" přístup, tak má zase hromady jiných problémů. A zároveň dnešní OOP se ukazuje jako velmi dobré i na obrovské věci.

Hlavne ten pan vyberal von z objektu spravanie. Kontext aplikacie musel mat naviac vedomost spravania. Cize v konecnom dosledku zhorsil znovupouzitelnost. Kebyze toto skusi na OOPSLA, alebo na ECOOP, tak by to nepreslo ani peer review. Niekedy ale aj na dev convetions zvyknu mat dobre myslienky no, tento vylial dieta aj s vanickou a ani si nedal pracu vysvetlit ze preco, len konstatoval.

[SB]

Podstata je v tom, že když se programátor v záchvatu oop-vitosti rozhodne ten list uvnitř objektu skrýt, tak na něm ten reverse neudělám.

Tak buďto to má nějaký důvod, nebo je debil. Ale opět: S OOP to nemá co dělat, neschopnost vývojáře nebudu řešit tím, že rezignuju na zapouzdření. (https://en.wikipedia.org/wiki/Anemic_domain_model, https://en.wikipedia.org/wiki/Object_orgy)

[zboj]

Matici je možno modelovat vektory, pak půjde o skládání!!!

V žádné rozumné implementaci nebude matice implementovaná jako kompozice vektorů, tím by byl přístup jen k řádkům nebo sloupcům. Nejflexibilnější řešení je mít obecnou kolekci pro vícerozměrné pole (pro modelování tenzorů) s metodami charakteristickými pro matice a vektory. Pro různé pohledy na příslušná data se použijí views nebo slices, tedy "něco jako" rozhraní. Nejen že to je takto nejefektivnější, ale zároveň se dodrží myšlenka "čistého" OOP (chceme-li na ní trvat). Praktický problém s takovouto implementací je jen jeden: ve většině jazyků to takto nepůjde (mně známými výjimkami jsou Smalltalk, ObjC a možná Swift).

[SB]

Zde pořád nějak nevidím tu výhodu FP od OOP (teď nemám na mysli optimalizaci a paralelizaci, ale model) - když potřebuju objekt immutable, udělám si ho, když ne, nic mě nenutí. Rozhoduju se dle použití.

Jedna z výhod je nabíledni: pokud si můžu vybrat, potom o výsledku neexistuje žádná garance.

Pokud jsou data zaručeně imutabilní => mám garanci, že obsahují jenom backward reference (nemůžou tam z principu být cykly) => můžu mít např. výrazně efektivnější GC.

Můžu si vybrat => garance není => musím počítat s nejhorší variantou => v nejhorším případě jsem si vybral imutabilitu a přesto z ní nemůžu těžit.

Chápu. Tím se objevuje další otázka, jak se modelují vzájemné závislosti (cykly) v datech.

[SB]

Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká

Budeme radši říkat netypované (protože u zasílání zpráv se nic netypuje/netříduje, alespoň ne na straně odesílatele). Ano, to je původní koncept (důsledky a použití zde byly uvedeny).

[javaman ()]

Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká

Budeme radši říkat netypované (protože u zasílání zpráv se nic netypuje/netříduje, alespoň ne na straně odesílatele). Ano, to je původní koncept (důsledky a použití zde byly uvedeny).

Super, díky. Tak to trochu promyslím, jestli z toho lze získat nějaké výhody. Protože pokud je třeba Smalltalk fakt lepší než Java, tak je zbytečné ji používat a čím dřív začnu, tím lépe.