Dědičnost dnes

noef

  • *****
  • 897
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #600 kdy: 30. 01. 2017, 13:51:16 »
...
Chápu. Tím se objevuje další otázka, jak se modelují vzájemné závislosti (cykly) v datech.

Rekl bych, ze uplne stejne jako v relacni DB - tj. idcka (ale nejsem zadny guru ;D, tak treba to jde i jinak).


SB

Re:Dědičnost dnes
« Odpověď #601 kdy: 30. 01. 2017, 13:55:05 »
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...

Klidně tenzory nebo fázory, o to tu nejde, podstatou bylo odpálkovat jakékoliv pokusy o hledání specializace/generalizace mezi maticí a vektorem.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #602 kdy: 30. 01. 2017, 13:55:24 »
...
Chápu. Tím se objevuje další otázka, jak se modelují vzájemné závislosti (cykly) v datech.

Rekl bych, ze uplne stejne jako v relacni DB - tj. idcka (ale nejsem zadny guru ;D, tak treba to jde i jinak).
Je to podobné jako problém autoreference v logice, prostě se vytvoří další metaúroveň (akorát se jí tak neříká).

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #603 kdy: 30. 01. 2017, 13:57:52 »
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...

Klidně tenzory nebo fázory, o to tu nejde, podstatou bylo odpálkovat jakékoliv pokusy o hledání specializace/generalizace mezi maticí a vektorem.
Fázory asi těžko. Jinak ta specializace tam samozřejmě je (velice zřetelná), jen u dimenzí v řádech tisíců a více vůbec nic nepřináší.

Kiwi

Re:Dědičnost dnes
« Odpověď #604 kdy: 30. 01. 2017, 13:58:23 »
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.

Tak jinak. "OOP" tak, jak ho nabízí C++ či Java, je jenom určitý odvar z OOP. To není jen má původní myšlenka, to v mnoha rozhovorech říkají i otcové-zakladatelé OOP. Jistě autory těch dvou výše zmiňovaných jazyků vedly určité záměry, proč zvolili zrovna tuto podmnožinu. Osobně si myslím, že to bylo z toho důvodu, že na určitý okruh problémů to stačí - typicky GUI a určitý druh aplikačního software. Např. jinak neobjektový Oberon má oproti Pascalu možnost definovat záznam přidáním dalších položek analogickou cestou, jakou se odvozuje podtřída. To je vše a stačí mu to. Další důvod je asi ten, že to původní, plně dynamické pojetí, je výpočetně náročnější. Smalltalk byl navržen pro počítač, který byl oproti v té době běžným asi tak o dvě generace napřed.
No a u Javy speciálně podle mne sehrálo největší roli to, že za ní stála silná korporace.
Pokud jde o to původní OOP, tak z prakticky používaných a oblíbených jazyků se mu nejvíc blíží Objective C (podle githubu a počtu debat na stackoverflow je v první desítce jazyků) nebo Ruby (také v první desítce, takže bych netvrdil, že to nikdo nepoužívá, i když podobné statistiky je vždycky dobré brát s určitou rezervou).

Ovšem nic z výše uvedeného nemění nic na faktu, že objektově orientované programování je trošku něco jiného než Java. A že problémy, které jsou představovány jako problémy OOP, jsou ve skutečnosti problémy Javy. Jinou otázkou je, jak moc jsou ty problémy v praxi palčivé a nakolik jsou spíš akademické. Dalším nemilosrdným faktem je taky skutečnost, že průměrný program v Javě je stále mnohonásobně rychlejší a méně náročnější na paměť než program ve Smalltalku, ale i Objective C.

Možná tu budím dojem nějakého advokáta smalltalkovského OOP. Ve skutečnosti se jen pokouším vyvrátit určité předsudky a omyly ohledně OOP. Sám jsem se s "OOP" poprvé setkal u Turbo Pascalu a u Borland C++ na začátku 90. let, spolu se jejich slavným Turbo Vision, a celý ten koncept mi připadal takový nějaký zbytečný, obzvláště když člověk zná Xaw nebo GTK. Teprve na Smalltalku mi docvaklo, co se tím ve skutečnosti myslí a jaká "kouzla" se s tím dají dělat. Ale ne v C++ ani v Javě. Sám jsem moc příležitostí profesionálně se tím zabývat neměl, vlastně jen asi půl roku jsem měl co do činění s Objective C a s Cocoa, ovšem musím říci, že to byla celkem příjemná zkušenost. Jinak mě živí C++ a dříve sem tam i ta Java. Ale jako embeďák je to především to C++. A bohužel musím konstatovat, že ve většině případů, s nimiž se setkávám, bylo upřednostnění C++ před C nešťastným krokem, protože to žádný benefit nepřineslo. Jen samá negativa.


SB

Re:Dědičnost dnes
« Odpověď #605 kdy: 30. 01. 2017, 13:58:53 »
Je to podobné jako problém autoreference v logice, prostě se vytvoří další metaúroveň (akorát se jí tak neříká).

Tak zde musím přiznat, že jsem mimo, nic mi to nepřipomíná.

balki

Re:Dědičnost dnes
« Odpověď #606 kdy: 30. 01. 2017, 14:00:51 »
Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká :D

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

Ako sa to vezme, objekt vzdy smalltalku nesie o sebe vedomost, akeho je typu/triedy. Je na programatorovi, ci sa na ten typ spyta (Ci ocakava nejake rozhranie, alebo nejaky typ navratovej hodnoty atd)

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #607 kdy: 30. 01. 2017, 14:07:54 »
Ovšem nic z výše uvedeného nemění nic na faktu, že objektově orientované programování je trošku něco jiného než Java. A že problémy, které jsou představovány jako problémy OOP, jsou ve skutečnosti problémy Javy. Jinou otázkou je, jak moc jsou ty problémy v praxi palčivé a nakolik jsou spíš akademické. Dalším nemilosrdným faktem je taky skutečnost, že průměrný program v Javě je stále mnohonásobně rychlejší a méně náročnější na paměť než program ve Smalltalku, ale i Objective C.
Smalltalk jsem nikdy neměřil, ale pro ObjC to neplatí ani náhodou, rychlost je srovnatelná (někdy vyšší, protože value types), a paměťově náročnější je Java v podstatě vždy (pokud se teda nepoužije ObjC s GC, ale ten už ani Xcode neumí použít a v macOS už taky ani nejsou příslušné knihovny). Zrovna nízká náročnost na paměť je důvodem, proč Apple zahodil svůj celkem pokročilý GC a nasadil statickou analýzu (ARC).

javaman ()

Re:Dědičnost dnes
« Odpověď #608 kdy: 30. 01. 2017, 14:10:29 »
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.


OK, dík za info. Těžko říct. Mně je v podstatě jedno, jak budeme Javě říkat. Pro mě je OOP a pro wikipedii také, ale klidně pro účely debaty tomu můžeme říkat jinak. Prostě mám dojem, že tam pořád vidíš něco, co tam není. Nebo to právě mně jen nedocvaklo.

Na druhou stranu nemám moc rád dnešní vývoj, kdy plno lidí umí návrhové vzory a patlání. Většina vzorů je totiž fakt jen opruz navíc, který to spíše zkomplikuje. Jak kdy, ale obecně Java se píše daleko složitější a nedá se pak ani číst. Což je škoda. Takže možná na tom něco bude. Ale pořád nechápu, jak mi dynamičnost může s něčím pomoct. Ano, ztratím plno návrhových vzorů, protože najednou nejsou potřeba a zároveň ztratím skoro vše další. Pak jsem někde na úrovni skriptovacích jazyků jako Bash a Python.

Právě třeba to Ruby je přesně ono. Pro mě je to dynamický shit, který nelze stejně na nic použít. Frčí to hlavně kvůli webům. To je jako PHP. Takže beru, že je populární, ale ne u pořádného vývoje. Proto pořád zůstává otázka, jestli lze tyhle dynamické "hračky" použít na seriozní vývoj.

A jsem rád, že to probíráme, takže to není nic proti nikomu. Možná ale embedded je právě o menších a přesných programech? Tam bych si dovedl představit dynamické typování, protože ta velikost nemusí být tak velká. Ale nevím, třeba je to velké i tak.

ava

Re:Dědičnost dnes
« Odpověď #609 kdy: 30. 01. 2017, 14:17:18 »
Takže pravé OOP musí být dynamicky typované? Nebo pořád mi prostě něco uniká :D

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

Ako sa to vezme, objekt vzdy smalltalku nesie o sebe vedomost, akeho je typu/triedy. Je na programatorovi, ci sa na ten typ spyta (Ci ocakava nejake rozhranie, alebo nejaky typ navratovej hodnoty atd)

Přesně, já taky nejradši rozlišuji typování ve dvou osách - při překladu a při běhu, a tyto úrovně jsou u většiny jazyků nezávislé.

Typování při překladu ("statické typování") - hodnoty se anotují typy, většinou nominálně, tj. napíše se "foo" je Int a "bar" je instance třídy Bar. Anotují se i parametry metod/funkcí. Většinou si typy musí sedět, jinak se program nepřeloží (ne nutně, existuje i optional nebo pluggable typing).

Hodnoty znají své typy při běhu - "dynamické typování" - pošlu objektu zprávu (= zavolám metodu), a on se polymorfně zachová podle toho, jakého konkrétního typu je.

A teď nezávislost obou typování:

Assembler (víceméně) nemá ani jedno, registr se dá interpretovat jako číslo, znak, ukazatel do paměti, ....

C-čko/C++ bez RTTI mají statické, ale ne dynamické typování, za překladu anotuji hodnoty typy, ale za běhu už z pointerů nic nezjistím, můžu si přetypovat cokoliv na něco jiného.

Python/Smalltalk/... mají dynamické typy, ale za překladu nic neanotuji, za běhu se ale mohu ptát, jaké třídy jsou objekty instance, posílat jim libovolné zprávy a ony na ně správně reagují

Java, Scala atp.. mají i statické typování, i dynamické.

BoneFlute

  • *****
  • 2 047
    • Zobrazit profil
Re:Dědičnost dnes
« Odpověď #610 kdy: 30. 01. 2017, 14:43:12 »
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad.

Měl jsem za to, že v Haskellu (při troše fantazie) je všechno funkce, nic nejsou data. I takový symbol 42 je jen nulární funkce.

balki

Re:Dědičnost dnes
« Odpověď #611 kdy: 30. 01. 2017, 14:47:12 »
....Ale pořád nechápu, jak mi dynamičnost může s něčím pomoct. Ano, ztratím plno návrhových vzorů, protože najednou nejsou potřeba a zároveň ztratím skoro vše další. Pak jsem někde na úrovni skriptovacích jazyků jako Bash a Python.

Navrhove vzory nezavisia od toho, ma jazyk dynamicku, alebo staticku typovu kontrolu. Vo vzoroch sa predpokladaju len nejake vztahy objektov a urcite rozhranie, ktore nemusi byt ani explicitne zadefinovane. Skor nez o typoch su vzory o roliach.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #612 kdy: 30. 01. 2017, 14:48:44 »
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad.

Měl jsem za to, že v Haskellu (při troše fantazie) je všechno funkce, nic nejsou data. I takový symbol 42 je jen nulární funkce.

Teoreticky jo, každá konstanta je funkce. Ovšem každé číslo je čistě matematicky taky tenzor a stejně z něj v IT Integer nebo Float nedědí. Proto spíše než dědičnost - abychom se vrátili k tématu vlákna - je lepší používat hierarchii rozhraní, pak můžu Integer nebo Float modelovat třeba jako speciální případ komplexního čísla, což by sice dědičností šlo taky, ale má to v klasicky pojatém OOP dost negativních důsledků.

javaman ()

Re:Dědičnost dnes
« Odpověď #613 kdy: 30. 01. 2017, 14:51:37 »
....Ale pořád nechápu, jak mi dynamičnost může s něčím pomoct. Ano, ztratím plno návrhových vzorů, protože najednou nejsou potřeba a zároveň ztratím skoro vše další. Pak jsem někde na úrovni skriptovacích jazyků jako Bash a Python.

Navrhove vzory nezavisia od toho, ma jazyk dynamicku, alebo staticku typovu kontrolu. Vo vzoroch sa predpokladaju len nejake vztahy objektov a urcite rozhranie, ktore nemusi byt ani explicitne zadefinovane. Skor nez o typoch su vzory o roliach.

To asi jo, ale když Python nemá rozhraní, tak asi třetina vzorů najednou není potřeba, protože to tam naprasím napřímo :D Zase takový singleton skoro ani neudělám, protože to jednoduše nejde. Ale jsme přece dospělí, tak na co singleton...

Honza

Re:Dědičnost dnes
« Odpověď #614 kdy: 30. 01. 2017, 15:12:49 »
To asi jo, ale když Python nemá rozhraní, tak asi třetina vzorů najednou není potřeba, protože to tam naprasím napřímo :D Zase takový singleton skoro ani neudělám, protože to jednoduše nejde. Ale jsme přece dospělí, tak na co singleton...
Tak zrovna Singleton je legitimní návrhový vzor. Ale zrovna v Javě, pokud udělám private konstruktor, tak sice zajistím pouze jednu instanci, ale nemůžu to vůbec testovat. Na to bych potřeboval instanci ještě jednu pro testy.
No nevím, tvrdit o tom, že je právě tohle v Javě výhoda... Vždycky přece můžu mít přece více instancí, a stále to bude dle vzoru Singleton. Ale vždycky se najde někdo, kdo bude tvrdit, že bez private konstruktoru v Javě to není Singleton...