Dědičnost dnes

[bob]

Ctverec vs obdelnik je priklad, ktery ma ukazat obtiznost navrhu OO i na nektere na prvni pohled snadne veci. Neni vubec dulezite, jak to ma byt spravne. (spravne je to tak, ze obdelnik dedi ctverec ).

Tady se ale člověk doví sraček
Mutability a OOP je silně svázáno.
Podle (jednoho) tvůrce OOP (Kay) je OOP pouze o zasílání zpráv a pozdní vazbě kde to jen jde.
Jinými slovy, maximální dynamika + sync/async zprávy mezi objekty běžící ve stejném či úplně jiném vlákně exekuce (a nebo rovnou i stroji).
Jakmile je objekt immutable, celá filozofie zasílání zpráv jde do pr de le.
Je to jako kdyby každá buňka tvýho těla umřela když by dostala nějaký info.
Takže laskavě se k tomuhle nevyjadřuj, díky tobě podobnej debilum používáme ty sračky co používáme.
Děkujeme !

Jo a map, filter, fold a podobný kokotiny nemaj nic co dočinění s FP, to jen tak pro tvoje info abys aspoň v tomhle nešířil sračky.
FP, to je jen jedno, referenční transparetnost.

A FP není superior nad OOP a vice versa, oboje jsou stejně použitelné a silné strategie, každá ale hledí na problém trošku z jinýho úhlu.
Takový ten biologický vs matematický pohled...

Vzhledem k tomu, že používáš slova "analíza" a "rozbylo se", by ses měl hluboce stydět a hlavně stýkat s kamarády tobě rovnými, nejspíš asi prvoky. Máš IQ menší Bushe mladšího a dokud se nenaučíš aspoň základní pravopis, nevracej se sem.

čumilův příspěvek je i s pravopisnými chybami věcný a k tématu, váš příspěvek je mimo, sprostý a ubohý - a to si myslím i o vás

Čumilovy příspěvky jsou často nejenom sprosté (včetně Tebou citovaného), ale i pitomé (včetně Tebou citovaného). Jeho pravopis už je jenom taková třešnička na dortu. A Ty asi neumíš číst, když obhajuješ někoho takového (i se zmíněným citátem).

A nebylo by lepší se zbavit těch předsudků? Podle pravopisných chyb měřit IQ?

Kdo neumí správně ani pravopis, těžko může rozumět mnohem složitějším věcem jako programování. Zrovna čumil navíc většinou sprostě uráží. Je to zakomplexovaný, nepříliš inteligentní ubožák. Obhajovat ho taky o něčem svědčí, ale to už je každého problém.

I kdyz to napsal jak kreten, tak ma pravdu. OOP bylo mysleno jako message oriented programming. Implementace Actor modelu. To, ze si drzi reference na jiny objekt, aby se mu dala poslat zprava (zavolat na nem metodu) znamena, ze kazdy objekt v sobe obsahuje stav cele aplikace (skrz tu referenci).

Pritom kazdy objekt ma byt black box, o kterem idealne nic nevite a on si drzi jen privatni data a komunikuje skrz rozhrani, ale kdyz se zmeni jedna promenna, tak se to promitne v nejhorsim pripade do vsech trid v programu. Kde je pak ta zapouzdritelnost? Problem je, ze tohle neni na prvni pohled videt a prijde zakaznik a zepta se, jak dlouho bude trvat XXX a vy nevite, protoze, kdyz se tim zmeni jen ta jedna trida, tak je to na hodinu, kdyz se tim zmeni vsechno, tak na pul roku.

FP je ted tak popularni, protoze se s immutability mnohem lepe pracuje v multithread systemech, je to snazsi cesta nez vsude davat zamky, resit pristupy. Predej hodnotou a zapomen. Problem vyresen.

[Reklama]

[zboj]

Ctverec vs obdelnik je priklad, ktery ma ukazat obtiznost navrhu OO i na nektere na prvni pohled snadne veci. Neni vubec dulezite, jak to ma byt spravne. (spravne je to tak, ze obdelnik dedi ctverec ).

I kdyz to napsal jak kreten, tak ma pravdu. OOP bylo mysleno jako message oriented programming. Implementace Actor modelu. To, ze si drzi reference na jiny objekt, aby se mu dala poslat zprava (zavolat na nem metodu) znamena, ze kazdy objekt v sobe obsahuje stav cele aplikace (skrz tu referenci).

Pritom kazdy objekt ma byt black box, o kterem idealne nic nevite a on si drzi jen privatni data a komunikuje skrz rozhrani, ale kdyz se zmeni jedna promenna, tak se to promitne v nejhorsim pripade do vsech trid v programu. Kde je pak ta zapouzdritelnost? Problem je, ze tohle neni na prvni pohled videt a prijde zakaznik a zepta se, jak dlouho bude trvat XXX a vy nevite, protoze, kdyz se tim zmeni jen ta jedna trida, tak je to na hodinu, kdyz se tim zmeni vsechno, tak na pul roku.

FP je ted tak popularni, protoze se s immutability mnohem lepe pracuje v multithread systemech, je to snazsi cesta nez vsude davat zamky, resit pristupy. Predej hodnotou a zapomen. Problem vyresen.

1. Obdélník dědí čtverec? To je na vyhození od zkoušky v prvním ročníku

2. Není snad sporu o tom, že ryzí OOP (tak, jak bylo navrženo a implementováno ve Smalltalku a potažmo Objective-C) má řadu výhod a v neposlední řadě je elegantní, nicméně vývoj software je veskrze pragmatická záležitost, takže i pseudo-OOP v C++ má své opodstatnění, jen se hodí na něco trochu jiného. Vrcholem pragmatičnosti pak je Go, jež je sice z akademického pohledu přehnaně osekané, ale v praxi nadmíru užitečné.

3. FP je k OOP ortogonální a ano, má mnohé výhody, a bez něčeho dalšího (OOP) moc praktické není.

[SB]

A FP není superior nad OOP a vice versa, oboje jsou stejně použitelné a silné strategie, každá ale hledí na problém trošku z jinýho úhlu.
Takový ten biologický vs matematický pohled...

...prevest do FP tak, ze misto predavani dat (typicky v nejakych objektech) do jinych objektu budeme predavat funkce (operatory) opacnym smerem. Jinak receno, v OOP vybalujes (delegovanim) vstupni data z objektu, v FP nabalujes (skladanim) funkce, ktere nad daty pracuji.

...Jak uz to tak byva, vyvoj temer vzdy probiha od slozitejsiho k jednodussimu.

Obávám se, že toto je jeden z dalších příspěvků ukazujících nepochopení OOP - data z objektu nejde nijak vybalit, protože když je vybalíte, buďto získáte anemický model, nebo to není objekt (primitivní typy), takže to není OOP. Představa, že by delegace bylo nějaké "vybalování", je úplně nesmyslná.

O FP se tu bavit nechci, neznám jej dost, ale znám OOP a z toho, co tuším o FP (které mi stejně jako OOP většina lidí nedokáže vysvětlit), tak jsou v přímém protikladu - OOP považuje chování a stavy za neoddělitelné a zapouzdřuje je, schopnost modelovat změnu stavů je přímo jeho cílem při zachování identity, FP na samostatná, otevřená data používá samostatné (rádoby) univerzální funkce (či jejich zřetězení), stavy nemodeluje a identitu zahazováním mezivýsledků popírá. Takže v podstatě Čumilovo tvrzení, že OOP a FP spolu nemají nic společného, je pravdivé.
Zbytek příspěvku, co je a není FP, považuju za deklarativní konstrukce či dojmy bez důkazů či příkladů.

[zboj]

A FP není superior nad OOP a vice versa, oboje jsou stejně použitelné a silné strategie, každá ale hledí na problém trošku z jinýho úhlu.
Takový ten biologický vs matematický pohled...

...prevest do FP tak, ze misto predavani dat (typicky v nejakych objektech) do jinych objektu budeme predavat funkce (operatory) opacnym smerem. Jinak receno, v OOP vybalujes (delegovanim) vstupni data z objektu, v FP nabalujes (skladanim) funkce, ktere nad daty pracuji.

...Jak uz to tak byva, vyvoj temer vzdy probiha od slozitejsiho k jednodussimu.

Obávám se, že toto je jeden z dalších příspěvků ukazujících nepochopení OOP - data z objektu nejde nijak vybalit, protože když je vybalíte, buďto získáte anemický model, nebo to není objekt (primitivní typy), takže to není OOP. Představa, že by delegace bylo nějaké "vybalování", je úplně nesmyslná.

O FP se tu bavit nechci, neznám jej dost, ale znám OOP a z toho, co tuším o FP (které mi stejně jako OOP většina lidí nedokáže vysvětlit), tak jsou v přímém protikladu - OOP považuje chování a stavy za neoddělitelné a zapouzdřuje je, schopnost modelovat změnu stavů je přímo jeho cílem při zachování identity, FP na samostatná, otevřená data používá samostatné (rádoby) univerzální funkce (či jejich zřetězení), stavy nemodeluje a identitu zahazováním mezivýsledků popírá. Takže v podstatě Čumilovo tvrzení, že OOP a FP spolu nemají nic společného, je pravdivé.
Zbytek příspěvku, co je a není FP, považuju za deklarativní konstrukce či dojmy bez důkazů či příkladů.

V FP je taky "chování" a zapouzdřené stavy, dokonce "zapouzdřenější" než v OOP.

[SB]

I kdybych se držel Kayovi definice, není proti tomu co píšu. Nezapomínej, že zprávy ve smalltalku jsou synchronní, tj. vrací hodnoty, poslání zprávy neznamená že je spolknutá, ale s jejím výsledkem můžeš dál pracovat. Nepřipomíná ti to něco? Jo, funkce Tj. klidně je možné mít celý Smalltalk immutable, referenčně transparentní, a jen někde na okraji světa mít pár side-effectujících metod pro komunikaci s periferiemi.

...

Co se týče toho, jestli je FP lepší než OOP, jasně, to je subjektivní, ale (mutable) OOP se začíná dostávat do problémů s tím, jak se rozšiřuje nutnost paralelizovat (takt CPU moc nestoupá, ale  počet jo), mutabilita by default nutně vede k race conditions, pak se musí řešit hluboké kopie, zámky, .... Pro paralelní aplikace může být lepší používat vyšší abstrakce, třeba aktorový model nebo FRP...

Zprávy mají s funkcemi společnou jedinou věc, a to, že synchronně vracejí odpověď. Tím jejich podobnost končí. Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.

Aktorový model je samozřejmě taky mutable, je asynchronní obdobou objektů, tj. zachovává identitu. Jeho simulace v OOP je triviální (jestli mi něco neušlo) - objekt přijímá zprávy (obsahující nějakou formu callbacku) asynchronně (tj. odpověď je třeba pouze dobrý/špatný) a štosuje si je do fronty, kterou postupně zpracovává.

[Reklama]

[Ondra Satai Nekola]

I kdybych se držel Kayovi definice, není proti tomu co píšu. Nezapomínej, že zprávy ve smalltalku jsou synchronní, tj. vrací hodnoty, poslání zprávy neznamená že je spolknutá, ale s jejím výsledkem můžeš dál pracovat. Nepřipomíná ti to něco? Jo, funkce Tj. klidně je možné mít celý Smalltalk immutable, referenčně transparentní, a jen někde na okraji světa mít pár side-effectujících metod pro komunikaci s periferiemi.

...

Co se týče toho, jestli je FP lepší než OOP, jasně, to je subjektivní, ale (mutable) OOP se začíná dostávat do problémů s tím, jak se rozšiřuje nutnost paralelizovat (takt CPU moc nestoupá, ale  počet jo), mutabilita by default nutně vede k race conditions, pak se musí řešit hluboké kopie, zámky, .... Pro paralelní aplikace může být lepší používat vyšší abstrakce, třeba aktorový model nebo FRP...

Zprávy mají s funkcemi společnou jedinou věc, a to, že synchronně vracejí odpověď. Tím jejich podobnost končí. Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.

Zalezi, co chces. Jedna moznost je trebas nejaka podoba event-sourcingu, kde je mutabilita omezena prakticky na jediny bod.

[zboj]

Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.

Monády.

[SB]

...
S tim Smalltalkem a Akka actory jsem spis mel na mysli pozdni vazbu. Nikdy nevite, jakeho typu (ve vyznamu typoveho systemu Scaly) je aktor na druhe strane - proste je to vzdy instance nejake jedne tridy. A i kdyby typ bylo povoleno pouzivat (myslim, ze technicky to lze, ale obchazi se tim aktor model), tak to neni moc uzitecne, protoze aktori muzou menit za behu na ktere zpravy reaguji - coz IMO odpovida tomu, kdyby se za behu pridavaly/odebiraly metody, napr. jako v JavaScriptu (coz nad JVM nebude trivialni jako v JS, navic tim ztratite vsechny vyhody statickeho jazyka jako treba podporu IDE, protoze z toho jazyka vlastne delate dynamicky).

Nějak nevidím překážku v typovaných aktorech a jejich receptorech, poslat zprávu jde i typovaně. Ale nechám se poučit.
Reakce na zprávy se dá nasimulovat i jinak než přidáváním a odebíráním metod.

[bob]

Aktorový model je samozřejmě taky mutable, je asynchronní obdobou objektů, tj. zachovává identitu. Jeho simulace v OOP je triviální (jestli mi něco neušlo) - objekt přijímá zprávy (obsahující nějakou formu callbacku) asynchronně (tj. odpověď je třeba pouze dobrý/špatný) a štosuje si je do fronty, kterou postupně zpracovává.

On je mutable v ramci objektu, ktery je ale zvenci black box. Ono zapouzdreni neni, ze se vsechny promenne udelaji private a napisi k tomu gettery a settery. Zapouzdreni znamena, ze nevidis z venci, jak to uvnitr funguje a neleakuje ven implementace. Takze pokud to je vhodne tam klidne je public promenna a at si s tim kazdy dela co chce.

jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

[bob]

Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.

Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.

[JS]

Obávám se, že toto je jeden z dalších příspěvků ukazujících nepochopení OOP - data z objektu nejde nijak vybalit, protože když je vybalíte, buďto získáte anemický model, nebo to není objekt (primitivní typy), takže to není OOP. Představa, že by delegace bylo nějaké "vybalování", je úplně nesmyslná.

Myslel jsem to tak, ze v OOP se data vybaluji v metodach toho objektu, v tom smyslu je to "delegovani". S delegaty to nema nic spolecneho.

Zbytek příspěvku, co je a není FP, považuju za deklarativní konstrukce či dojmy bez důkazů či příkladů.

Zkus si to precist znovu a zamyslet se nad tim.. Muzu nektere veci dovysvetlit.

Je to trochu podobne zmene vztazne soustavy. Zatimco v OOP systemem prochazeji data, v FP systemem prochazeji funkce. Proto je take FP tak uzitecne v distribuovanych systemech typu Hadoop, Spark apod., protoze ty jsou zalozene na zasilani operaci nad daty a nikoli dat (lze-li se tomu vyhnout).

[zboj]

Jak se modelují změny stavů pomocí immutable, jsem se stále nedozvěděl, ale to neznamená, že to nejde, třeba jo.

Nijak, stary stav se zahodi a vytvori se novy, kopie stareho s pozmenymi vlastnostmi.

U monád se nic nezahazuje.

[SB]

...To, ze si drzi reference na jiny objekt, aby se mu dala poslat zprava (zavolat na nem metodu) znamena, ze kazdy objekt v sobe obsahuje stav cele aplikace (skrz tu referenci).
...

Jako tvrzení je to pochopitelně úplný nesmysl, odkaz (skládání) neznamená, že je něco uvnitř, to je taková naivní představa ještě pocházející z procedurálního programování s primitivními, nereferenčními typy. Zadruhé skutečnost, že objekt vidí kámoše, ještě neznamená, že vidí i kámoše kámoše, naopak je to vyloženě nechtěný stav porušující zapouzdření.
Zbytek příspěvku o propagaci změny modelovanou doménou je nesrozumitelný.

[phpmág]

jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Neni to trochu komplikovaný a zbytečný? Normálně máš odkaz na rozhraní a přes to voláš. Jestli je za tím ta tvoje fronta a nebo něco jiného, je tobě úplně jedno. Nějak nechápu, proč tam přidávat další abstrakci, která mě ještě víc odstíní od problému.

To už pak fakt můžu používat nějaký dynamický jazyk, který je reálně nepoužitelný, protože je právě dynamický.

[bob]

jak pises. Mezi objekty se posilaji immutable zpravy, trebas pres sync queue. Jednotlive objekty se prihlasi k odberu zprav, co je zajimaji... takze se nikomu neposila nic primo. Kdo chce neco rici, da to na frontu, koho to zajima, ten si to vezme. A v tomhle je ten rozdil, ja kdyz mam referenci na jiny objekt, ktery volam primo (posilam mu zpravu), tak v tom mem objektu je tim padem i cely stav toho druheho... Takze kdyz se neco zmeni, tak se zmeni vsechno. U Actor modelu to neplati. Nevis komu to chodi, je ti to jedno. Zmeny v tom jsou pak snazsi.

Neni to trochu komplikovaný a zbytečný? Normálně máš odkaz na rozhraní a přes to voláš. Jestli je za tím ta tvoje fronta a nebo něco jiného, je tobě úplně jedno. Nějak nechápu, proč tam přidávat další abstrakci, která mě ještě víc odstíní od problému.

To už pak fakt můžu používat nějaký dynamický jazyk, který je reálně nepoužitelný, protože je právě dynamický.

Ja psal jak to bylo puvodne navrzeny a nekomu se taky zdalo, ze je to komplikovany a vznikla... Java