Zdroje k rozvoji OOP myšlení

javaman ()

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #195 kdy: 01. 04. 2017, 22:23:45 »
A kteří neumějí vyvíjet.


Polymath

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #196 kdy: 01. 04. 2017, 22:30:18 »
A co třeba clojure? Taková moderní implementace lispu... a může sloužit i jako odpověď na otázku, co místo oop...

jinak scala je IMHO příliš expresivní, umí toho příliš moc... nikdy mi nesedla...

Dobře se mi pracuje s Groovy ale vadí mi, že je to dynamický jazyk...

Dále tu máme Kotlin... staticky typový, umí spoustu věcí, co má Scala a Groovy... moc se mi líbí...


bohužel, u mě v práci skousnou leda Groovy, protože některé systémy, se kterými pracujeme, ho používají... jinak Scala, Clojure, Kotlin... jedním slovem NE

btw http://www.itworld.com/article/2693998/big-data/clojure-developers-are-the-happiest-developers.html

a v práci mi na to řekli:
hola hoj,jedním slovem "ne". to raději začnu přidávat lidem do kafe LSD, aby jste se cítili šťastnější.
Příslovečné "vectors headed up" jsou staticky typované jazyky, co se tváří jako dynamické a nechají žít programátora v iluzi OOP, i když ve skutečnosti se nativně kompilují a umožňují FP (lehce, bez vynucování).

Předpokládám, že mluvíš o Go. To může být jen přechodná móda. Zatím ten jazyk propagují lidé, kteří předtím ujížděli na jiných hypech.
Nejen. V případě Go na něm "ujíždí" ti, co předním dělali v C(++). Ten jazyk je by design hypeless, v něčem možná až moc - celá jeho filosofie je hezky shrnutá v přednáškách Pika. Já ale myslel trend, kam patří i Rust nebo i Swift, ten je ale zatím ve stavu vysoké entropie.

gll

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #197 kdy: 01. 04. 2017, 22:42:43 »
Nejen. V případě Go na něm "ujíždí" ti, co předním dělali v C(++). Ten jazyk je by design hypeless, v něčem možná až moc - celá jeho filosofie je hezky shrnutá v přednáškách Pika. Já ale myslel trend, kam patří i Rust nebo i Swift, ten je ale zatím ve stavu vysoké entropie.

Lidé mají tendenci otáčet o 180 stupňů. Nedávno byly v módě jazyky s vysokou mírou abstrakce (například Scala) a Go je protireakce.

Polymath

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #198 kdy: 01. 04. 2017, 22:46:42 »
Nejen. V případě Go na něm "ujíždí" ti, co předním dělali v C(++). Ten jazyk je by design hypeless, v něčem možná až moc - celá jeho filosofie je hezky shrnutá v přednáškách Pika. Já ale myslel trend, kam patří i Rust nebo i Swift, ten je ale zatím ve stavu vysoké entropie.

Lidé mají tendenci otáčet o 180 stupňů. Nedávno byly v módě jazyky s vysokou mírou abstrakce (například Scala) a Go je protireakce.
Cílová skupina je jiná.

SB

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #199 kdy: 03. 04. 2017, 09:29:05 »
Kurna, teraz som si uvedomil, ked to tak citam, ze som zabudol pridat link. Zaujimal ma nazor na vyjadrenia tych ludi ohladom OOP
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html

V podstatě tam píší, že objektové jazyky bývají systematicky zneužívány ke psaní procedurálního kódu a tedy nesplňují původní očekávání. Dědičnost se potlačuje ve prospěch kompozice, zapouzdření se systematicky porušuje a polymorfismus je pro spoustu programátorů jen cizím slovem. K tomu příšerný přístup k definicím rozhraní a máme tady procedurální kód zabalený do tříd, který se jen tváří, že je objektový.

Ti programátoři si vlastně jen stěžují, že principy OOP zůstaly většinou vývojářů nepochopeny.

Myslím si v podstatě to samé - OOP se vlastně nikdy pořádně nepoužívalo, jeho potenciál nebyl nikdy využit. Že něco nechápu, neznamená, že je to na hovno. Další otázkou je, odkud pocházejí zkušenosti oněch komentátorů - jestli z něčeho jako C++ (např. komentář Torvaldse), dávalo by to smysl. A každý by se měl věnovat jen tomu, čemu rozumí.


Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:Zdroje k rozvoji OOP myšlení
« Odpověď #200 kdy: 03. 04. 2017, 09:55:26 »
A já to říkám pořád... OOP je především dobré pro práci s daty, v některých případech to dává smysl i jinde, ale pokud chce mít někdo jako objekt úplně všechno a tvoří v tom i lineární aplikace, nedává to smysl. Je to neefektivní a kód to zesložiťuje.

Mám opačnou zkušenost: OOP mi aplikace zkracuje a zefektivňuje. Hlavně mi zlepšuje přehled o tom, kde mám kterou část kódu. Když se mi změní zadání, tak většinou stačí vyměnit nějakou třídu za novou a jede se dál.
Všeho s mírou. Jak jsem psal, dává to smysl i v některých jiných případech, ale nic se nemá přehánět. Procedurální "zobjektovaný" 1:1 jen proto, že je to cool, není nic hezkého a bohužel to nejí výjimka.

Kit

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #201 kdy: 03. 04. 2017, 10:58:37 »
A já to říkám pořád... OOP je především dobré pro práci s daty, v některých případech to dává smysl i jinde, ale pokud chce mít někdo jako objekt úplně všechno a tvoří v tom i lineární aplikace, nedává to smysl. Je to neefektivní a kód to zesložiťuje.

Mám opačnou zkušenost: OOP mi aplikace zkracuje a zefektivňuje. Hlavně mi zlepšuje přehled o tom, kde mám kterou část kódu. Když se mi změní zadání, tak většinou stačí vyměnit nějakou třídu za novou a jede se dál.
Všeho s mírou. Jak jsem psal, dává to smysl i v některých jiných případech, ale nic se nemá přehánět. Procedurální "zobjektovaný" 1:1 jen proto, že je to cool, není nic hezkého a bohužel to nejí výjimka.

Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:Zdroje k rozvoji OOP myšlení
« Odpověď #202 kdy: 03. 04. 2017, 11:10:11 »
Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".
No a jsme u toho. OOP vyžaduje rozumný návrh a pokud se očekává, že aplikace poroste a budou jí přibývat nové funkcionality, musí se na to včas myslet. Tím nechci říct, že u procedurálního programování se špatný návrh ztratí, ale u OOP mně to přijde kritičtější. Ono takový dohledávání dědičností, dědiců, vyděděnců, nevlastních dětí a retardovaných bratranců, to je masakr.

SB

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #203 kdy: 03. 04. 2017, 11:40:38 »
- Jaké triviality se musí v Javě rozepisovat na několik řádek?

Pokud jsem si všimnul, tak Collection z iterací umí jen "do" (forEach), nezná select, collect (map), inject (reduce), anySatisfy, allSatisfy, ...

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #204 kdy: 03. 04. 2017, 11:59:22 »
- Jaké triviality se musí v Javě rozepisovat na několik řádek?

Pokud jsem si všimnul, tak Collection z iterací umí jen "do" (forEach), nezná select, collect (map), inject (reduce), anySatisfy, allSatisfy, ...

Nutno podotknout, ze od tehle moznosti jsi vetsinou jenom jedno volani .stream() daleko...

Idealni to neni, ale zrovna tohle neni zas takova tragedie.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Zdroje k rozvoji OOP myšlení
« Odpověď #205 kdy: 03. 04. 2017, 12:06:17 »
Zrovna koukám na aplikaci napsanou v shellu "lineárně". Aby to nebylo v jednom souboru, je tam hromada "source", tedy includů jiných souborů. V objektech to určitě bude vypadat mnohem lépe, ale v podstatě tu aplikaci budu muset navrhnout znovu a pořádně. O nějakém "zobjektování" nemůže být řeč. V případě ponechání shellu by se jednalo spíš o "zfunkcionálnění".
No a jsme u toho. OOP vyžaduje rozumný návrh a pokud se očekává, že aplikace poroste a budou jí přibývat nové funkcionality, musí se na to včas myslet. Tím nechci říct, že u procedurálního programování se špatný návrh ztratí, ale u OOP mně to přijde kritičtější. Ono takový dohledávání dědičností, dědiců, vyděděnců, nevlastních dětí a retardovaných bratranců, to je masakr.

Moje zkušenost je taková, že největší problém OOP je v tom, že ho prakticky nikdo neumí. Takže jako koncept je tímto dost naprd.

Opravovat zobjektizovaný kód je dost na prd.
Opravovat funkcionální kód mi přišlo mnohem snazší. Přijde mi, že v tom nemůžeš udělat takové špagety jako v OOP. Aktivněji ti v tom brání.


SB

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #206 kdy: 03. 04. 2017, 12:10:43 »

Nutno podotknout, ze od tehle moznosti jsi vetsinou jenom jedno volani .stream() daleko...

Idealni to neni, ale zrovna tohle neni zas takova tragedie.

Určitě to jde vždycky nějak ojebat, ale proč? Upozorňuju, že se bavíme o základní funkcionalitě seznamů, žádné specializované, obskurní, okrajové operace.

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:Zdroje k rozvoji OOP myšlení
« Odpověď #207 kdy: 03. 04. 2017, 12:20:32 »
Opravovat zobjektizovaný kód je dost na prd.
Opravovat funkcionální kód mi přišlo mnohem snazší. Přijde mi, že v tom nemůžeš udělat takové špagety jako v OOP. Aktivněji ti v tom brání.
No... ne že by v tom přímo bránil, ale v OOP je víc špagetovacích možností... třeba právě dědičnost. Už jsem viděl objekt, který se jmenoval nějak mainobject, jedinou vlastností bylo nějaký ID a všechny ostatní objekty byly jeho potomkem. V podobném duchu se to neslo dál, takže než se člověk prokousal přes x úrovní, aby zjistil, proč se to se.. kazí, tak měl skoro fousatý děti.

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #208 kdy: 03. 04. 2017, 12:32:03 »

Nutno podotknout, ze od tehle moznosti jsi vetsinou jenom jedno volani .stream() daleko...

Idealni to neni, ale zrovna tohle neni zas takova tragedie.

Určitě to jde vždycky nějak ojebat, ale proč? Upozorňuju, že se bavíme o základní funkcionalitě seznamů, žádné specializované, obskurní, okrajové operace.

To neni zadne ojebat. To je zakladni API.

Re:Zdroje k rozvoji OOP myšlení
« Odpověď #209 kdy: 03. 04. 2017, 12:41:39 »
Nutno podotknout, ze od tehle moznosti jsi vetsinou jenom jedno volani .stream() daleko...
Idealni to neni, ale zrovna tohle neni zas takova tragedie.
Určitě to jde vždycky nějak ojebat, ale proč? Upozorňuju, že se bavíme o základní funkcionalitě seznamů, žádné specializované, obskurní, okrajové operace.
Protože všechny tyto operace nejsou základní funkcionalitou jen seznamů, a dokonce ani nejsou omezeny na kolekce. Takže jsou součástí samostatného interface Stream, nikoliv Collection (nebo dokonce List).

Jistě, je otázkou proč vlastně Collection neimplementuje Stream (tj. je to "kompozice" místo "dědičnosti"), ale to už je hodně technikálie (a při rozhodování hrála velkou roli nejenom omezení jazyka, ale i zpětná kompatabilita).
Ideální to nikdy nebude, protože Java je prostě low-level jazyk a tohle roubování bude vždy skřípat. Nejlepší je prostě použít jiný jazyk nad JVM, ale do toho se moc lidem nechce...