Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: anonym 27. 04. 2018, 22:31:31
-
Přijde mi, že je těžké něco pěkně naprogramovat samo o sobě, v OOP. Musí si to člověk řádně promyslet. V Javě 8 přibyly Streamy a podle mě situaci zkomplikovaly. Dneska se mě kolega nadšeně zeptal, co na ně říkám. Trochu mi vzal vítr z plachet, protože na ně neříkám nic. Zaprvé nevím, kde bych je použil a řekl "tak tohle je jednoznačně přehlednější, než smyčky". Zadruhé kdekoliv v kódu jsem viděl, jak někdo používá Streamy, vždycky to byla sračka typu "musím to udělat přes stream, protože je to Java 8 a ta má streamy". Zatřetí málokdy se setkám se situací, kdy nepotřebuju zachytávat vyjímky, abych mohl specificky reagovat na chybu, a proto mi i chainování funkcí za sebe do streamu přijde naprosto useless. I kdybych nepotřeboval try catch zrovna teď, stejně nepoužiju spičeny Stream, protože se já nebo někdo další ke kódu vrátí a bude chtít odchytávat vyjímky. Doposud jsem viděl jeden jediný smysluplný usecase pro Streamy a ten je stejný jako ho má LINQ, tzn. manipulace s daty.
-
co treba takovy stream.filter.collect(toList) elegantne vybrat jenom prvky, ktere se nam hodi. a prikladu je hodne.
-
Paralelní streamy jsou asi nejjednodušší způsob jak něco v Javě paralelizovat. Velkou úsporu kódu přináší i collectory jako group by atd.
-
Přijde mi, že je těžké něco pěkně naprogramovat samo o sobě, v OOP. Musí si to člověk řádně promyslet. V Javě 8 přibyly Streamy a podle mě situaci zkomplikovaly.
problem je mozno v tom, ze streamy su v podstate funkcionalne programovanie, takze OOP unfriendly.
-
Doposud jsem viděl jeden jediný smysluplný usecase pro Streamy a ten je stejný jako ho má LINQ, tzn. manipulace s daty.
k čemu jinému bys to chtěl použít? Streamy jsou data.
-
Paralelní streamy jsou asi nejjednodušší způsob jak něco v Javě paralelizovat. Velkou úsporu kódu přináší i collectory jako group by atd.
A taky pekne nahovno.
Mnohem bych radsi, kdyby do Jawy implementovali Gorutiny a channely.
Streamy v Jawe vypadaj jak rovnak na ohybak.
-
Streamy do Javy přidali, aby byla víc funkcionální, protože to je teď cool :) Koukám, že ne každý to ocení... Ale buď rád, že tam ještě nejsou monadické transformery, komonády a další perly funkcionalismu...
-
Streamy do Javy přidali, aby byla víc funkcionální, protože to je teď cool :) Koukám, že ne každý to ocení... Ale buď rád, že tam ještě nejsou monadické transformery, komonády a další perly funkcionalismu...
Abys moh dostat doktorat z Computer Sciences, musis v ramci disertacky vymyslet neco noveho.
A kdyz uz z duvod vycerpani tematu uz nic rozumneho vymyslet jen tak nejde, musis zacit vymyslet picoviny.
Picoviny, ale nove, to je cesta k doktoratu.
-
Streamy do Javy přidali, aby byla víc funkcionální, protože to je teď cool :) Koukám, že ne každý to ocení... Ale buď rád, že tam ještě nejsou monadické transformery, komonády a další perly funkcionalismu...
Abys moh dostat doktorat z Computer Sciences, musis v ramci disertacky vymyslet neco noveho.
A kdyz uz z duvod vycerpani tematu uz nic rozumneho vymyslet jen tak nejde, musis zacit vymyslet picoviny.
Picoviny, ale nove, to je cesta k doktoratu.
Nejen v computer science, to platí i ve fyzice nebo chemii. O tzv. společenských "vědách" raději pomlčme, tam se dává PhD za totální bláboly, čím debilnější, tím lepší.
-
Jak specificky reagujete na chybu při zpracovávání seznamu, že to nejde udělat přes streamy např. lambdou s try - catch?
Streamy jsou právě náhrada za LINQ v Javě. S tím, že jsou mnohem flexibilnější, třeba vůbec není problém mít nekonečný stream, protože mají líné vyhodnocování.
-
Mnohem bych radsi, kdyby do Jawy implementovali Gorutiny a channely.
Takže Executor a Flow?
-
Stream musíte použít tak, aby k žádné chybě nemohlo dojít už z principu, pokud potřebujete odchytávat chyby, máte to špatně navrženo, nebo špatně uvažujete, je třeba si uvědomit, že ve streamu máte pracovat jen s daty, která potřebujete a tím výběrem ty možné chyby odfiltrujete a žádný try-catch nepotřebujete, protože ho máte ho implementovaný pomocí filter.
Takže i tady platí, že si musíte věc dobře promyslet, aby to bylo elegantní, ale s trochu jinou filosofií.
V podstatě dříve jste uvažoval takto, dej další záznam, je to typ A, udělám to, je to typ B, udělám zase toto, ...
A nyní musíte uvažovat takto, ze souboru záznamů vyberu záznamy typu A a s nimi udělám toto, dále ze souboru záznamů vyberu záznamy typu B a udělám zase toto. Výsledky pak spojím do jiného seznamu.
A co za to dostanu? Možnost paralelizace, protože výběr ze souboru můžete dělat na jednom procesoru, použítí funkce paraleleně na mnoha procesorech, protože na pořadí zpracování nezáleží a dopředu víte co se všemi vybranými prvky máte udělat. Což pro první uvedený příklad neplatí.
-
Mnohem bych radsi, kdyby do Jawy implementovali Gorutiny a channely.
Takže Executor a Flow?
Kdyz uz, tak Spring executor service.
http://www.baeldung.com/java-executor-service-tutorial
A podivej se do odkazu, kolik je s tim srani.
Srovnej se spustenim go func() a smytec.
A kazdy task je separatni java vlakno, gorutina je velice lightweight reseni
-
Přijde mi, že je těžké něco pěkně naprogramovat samo o sobě, v OOP. Musí si to člověk řádně promyslet. V Javě 8 přibyly Streamy a podle mě situaci zkomplikovaly.
problem je mozno v tom, ze streamy su v podstate funkcionalne programovanie, takze OOP unfriendly.
To nám ovšem nebrání v tom, abychom jednu vrstvu aplikace měli strukturovaně, druhou objektově, třetí funkcionálně a doplnili to deklarativními šablonami.
-
Streamy do Javy přidali, aby byla víc funkcionální, protože to je teď cool :) Koukám, že ne každý to ocení... Ale buď rád, že tam ještě nejsou monadické transformery, komonády a další perly funkcionalismu...
Abys moh dostat doktorat z Computer Sciences, musis v ramci disertacky vymyslet neco noveho.
A kdyz uz z duvod vycerpani tematu uz nic rozumneho vymyslet jen tak nejde, musis zacit vymyslet picoviny.
Picoviny, ale nove, to je cesta k doktoratu.
Je otázkou, či je toto problém len v Computer Science. Koľko zbytočných pičovín (ale originálnych!) vznikne na jednu ozaj užitočnú, tiež originálnu myšlienku (ktorú nakoniec asi zadupu pod zem lebo málo citácii a pod.)
-
Streamy do Javy přidali, aby byla víc funkcionální, protože to je teď cool :) Koukám, že ne každý to ocení... Ale buď rád, že tam ještě nejsou monadické transformery, komonády a další perly funkcionalismu...
Abys moh dostat doktorat z Computer Sciences, musis v ramci disertacky vymyslet neco noveho.
A kdyz uz z duvod vycerpani tematu uz nic rozumneho vymyslet jen tak nejde, musis zacit vymyslet picoviny.
Picoviny, ale nove, to je cesta k doktoratu.
Je otázkou, či je toto problém len v Computer Science. Koľko zbytočných pičovín (ale originálnych!) vznikne na jednu ozaj užitočnú, tiež originálnu myšlienku (ktorú nakoniec asi zadupu pod zem lebo málo citácii a pod.)
Např. derivace algebraických datových typů :) ty ovšem patří k tomu užitečnějšímu...
-
Streamy sú nesmierne mocný nástroj na spracovanie dát. Keď som sa s tým prvý krát oboznámil, tak som bol nadšený.
Vzbudilo to tiež vo mne hlbší záujem o funkcionálne programovanie. Jazyk Python tieť nie je primárne fukcionálny jazyk, ale má svoje list comprehensions, ktoré sú veľmi efektívne pri práci s dátami.
Vezmime si nasledujúci kód:
int[] vals = { -4, 3, 5, 5, 7, -9, 0, 0, 12, 15, 11, -5, 2, 1, 7 };
Arrays.sort(vals);
System.out.println(Arrays.toString(vals));
Má jeden veľmi nepríjemný side effect, a to je in-place sorting dát. Čo je ale nemusí byť to, čo potrebujem.
Funkcionálne programovanie nás takýchto side-effektov ušetrí.
int[] vals = { 199, 199, 199, 199, -4, 3, 5, 5, 7, -9, 0, 0, 12, 15, 11, -5, 2, 1, 7 };
Arrays.stream(vals).skip(4).distinct().filter(e -> e > 0).map(e -> e * 2)
.filter(e -> e < 25).forEach(System.out::println);
Koľko smyčiek budeme potrebovať, aby sme toto spravili bez streamov?
-
Mnohem bych radsi, kdyby do Jawy implementovali Gorutiny
To by ovšem šlo dost těžko, to chce podporu runtimu pro kooperativní multitasking.
-
Kdyz uz, tak Spring executor service.
http://www.baeldung.com/java-executor-service-tutorial
Executor Service není Spring, ale součást JDK
A podivej se do odkazu, kolik je s tim srani.
Srovnej se spustenim go func() a smytec.
Samotné spouštění úloh je jen jedna metoda (execute, resp. submit). To všechno předtím za vás může řešit framework. Na rozdíl od Go ale máte možnost měnit, jak se to zpracovává (paralelně? sériově? vzdáleně? v jak velkém thread poolu? s jakou prioritou?). Flexibilita nejde udělat jednoduše. Ale jestli chcete, aby se to chovalo přesně jako Go, použijte Go, ne Javu ;)
-
Paralelní streamy jsou asi nejjednodušší způsob jak něco v Javě paralelizovat. Velkou úsporu kódu přináší i collectory jako group by atd.
A taky pekne nahovno.
Mnohem bych radsi, kdyby do Jawy implementovali Gorutiny a channely.
Streamy v Jawe vypadaj jak rovnak na ohybak.
Na tom sa prave pracuje. preview mal byt uz v 10, ale nestihlo sa. Kazdopadne, ma to prioritu a officialny backing od Oracle.
-
Mnohem bych radsi, kdyby do Jawy implementovali Gorutiny
To by ovšem šlo dost těžko, to chce podporu runtimu pro kooperativní multitasking.
Prvotna implementacia v podobe externej kniznice existuje uz najmenej 4 roky a na JDKckovej/nativnej podpore sa aktivne pracuje. Co si pamatam, bude k tomu treba aj Graal, ktory sa opozdil.
-
Přijde mi, že je těžké něco pěkně naprogramovat samo o sobě, v OOP. Musí si to člověk řádně promyslet. V Javě 8 přibyly Streamy a podle mě situaci zkomplikovaly. Dneska se mě kolega nadšeně zeptal, co na ně říkám. Trochu mi vzal vítr z plachet, protože na ně neříkám nic. Zaprvé nevím, kde bych je použil ... atd.
Osobne ich pouzivam, ked mam vybrat prvky s urcitymi vlastnostami z kolekcie potom nejakym sposobom ich spracovat bud pomocou .map.reduce() alebo v horsom pripade .forEach() , . Pripadne len ich vybrat do kolekcie pomocou .collect() .
Na streamoch ocenujem ich nazornost, ale problem je casova penalizacia pri ich pouziti. (co sa vsak v buducnosti verim ze vyriesi). Holt si to nemozem hocikde dovolit.
Ale jeden nas externista, co rad pouzival novoty bez rozumu pachal tym kadejake hrozy, ze do zatvorky dal 20 riadkovy imperativny kod a podobne. To som len gulal ocami. Kod v ztvorkach v streamovch by mal byt strucny.
-
Přijde mi, že je těžké něco pěkně naprogramovat samo o sobě, v OOP. Musí si to člověk řádně promyslet. V Javě 8 přibyly Streamy a podle mě situaci zkomplikovaly. Dneska se mě kolega nadšeně zeptal, co na ně říkám. Trochu mi vzal vítr z plachet, protože na ně neříkám nic. Zaprvé nevím, kde bych je použil ... atd.
Osobne ich pouzivam, ked mam vybrat prvky s urcitymi vlastnostami z kolekcie potom nejakym sposobom ich spracovat bud pomocou .map.reduce() alebo v horsom pripade .forEach() , . Pripadne len ich vybrat do kolekcie pomocou .collect() .
Na streamoch ocenujem ich nazornost, ale problem je casova penalizacia pri ich pouziti. (co sa vsak v buducnosti verim ze vyriesi). Holt si to nemozem hocikde dovolit.
Ale jeden nas externista, co rad pouzival novoty bez rozumu pachal tym kadejake hrozy, ze do zatvorky dal 20 riadkovy imperativny kod a podobne. To som len gulal ocami. Kod v ztvorkach v streamovch by mal byt strucny.
To si asi nevidel perl.
-
int[] vals = { 199, 199, 199, 199, -4, 3, 5, 5, 7, -9, 0, 0, 12, 15, 11, -5, 2, 1, 7 };
Arrays.stream(vals).skip(4).distinct().filter(e -> e > 0).map(e -> e * 2)
.filter(e -> e < 25).forEach(System.out::println);
Koľko smyčiek budeme potrebovať, aby sme toto spravili bez streamov?
jednu
-
Streamy sú nesmierne mocný nástroj na spracovanie dát. Keď som sa s tým prvý krát oboznámil, tak som bol nadšený.
Vzbudilo to tiež vo mne hlbší záujem o funkcionálne programovanie. Jazyk Python tieť nie je primárne fukcionálny jazyk, ale má svoje list comprehensions, ktoré sú veľmi efektívne pri práci s dátami.
Vezmime si nasledujúci kód:
int[] vals = { -4, 3, 5, 5, 7, -9, 0, 0, 12, 15, 11, -5, 2, 1, 7 };
Arrays.sort(vals);
System.out.println(Arrays.toString(vals));
Má jeden veľmi nepríjemný side effect, a to je in-place sorting dát. Čo je ale nemusí byť to, čo potrebujem.
Funkcionálne programovanie nás takýchto side-effektov ušetrí.
int[] vals = { 199, 199, 199, 199, -4, 3, 5, 5, 7, -9, 0, 0, 12, 15, 11, -5, 2, 1, 7 };
Arrays.stream(vals).skip(4).distinct().filter(e -> e > 0).map(e -> e * 2)
.filter(e -> e < 25).forEach(System.out::println);
Koľko smyčiek budeme potrebovať, aby sme toto spravili bez streamov?
Ach jaj, zrovna array primitivnych typov je prakticky jediny typ arrayu v Jave, ktory sa da iterovat bez nutnosti dereferencovania hodnot na jednotlivych indexoch. Silou mocou potrebujete spomalit jednu z najrychlejsie iterovatelnych struktur.
4 staticke lambdy - pre kazdu sa bude musiet vygenerovat factory bytecode, nasledne naloadovat cez class loader, ani sa to nestihne odJITovat... a to vsetko kvoli forEach, ktory podporuje Java aj cez iny konstrukt, kde nemusite pouzivat index (ak vam tak vadi).
-
int[] vals = { 199, 199, 199, 199, -4, 3, 5, 5, 7, -9, 0, 0, 12, 15, 11, -5, 2, 1, 7 };
Arrays.stream(vals).skip(4).distinct().filter(e -> e > 0).map(e -> e * 2)
.filter(e -> e < 25).forEach(System.out::println);
Koľko smyčiek budeme potrebovať, aby sme toto spravili bez streamov?
jednu
A teď co bude pomalejší, průchod stejným polem několikrát po sobě a vyřešení jedné operace, nebo jeden průchod a složitá logika akcí, kterou poslepujete kdoví jak a kdoví proč a která bude i tak zvyšovat režii systému?
Stav virtuálního automatu, v jakém se bude v jednotlivých průchodech nacházet, bude jen stěží z hlavy predikovatelný.
Co se bude snadněji udržovat a modifikovat.
-
Najlepšie by bolo, keby všetci intelektuáli spáchali samovraždu. Všetko len komplikujú a vytvárajú problémy tam, kde žiadne nie su.
-
A teď co bude pomalejší, průchod stejným polem několikrát po sobě a vyřešení jedné operace, nebo jeden průchod a složitá logika akcí, kterou poslepujete kdoví jak a kdoví proč a která bude i tak zvyšovat režii systému?
Stav virtuálního automatu, v jakém se bude v jednotlivých průchodech nacházet, bude jen stěží z hlavy predikovatelný.
Co se bude snadněji udržovat a modifikovat.
Ja som iba odpovedal na otazku :). Ak vas to zaujima prvy priechod je asi 300x pomalejsi, druhe volanie uz je na urovni kde zacina loop, ale loop je tiez rychlejsi, pri piatom volani je loop 2x rychlejsi.
Co sa tyka zliepania kodu 'ktovi jak a proc' to plati aj o streamoch a streamy sa budu mozno 'snadneji udrzovat' aj ked som uz videl talk na temu v zmysle don't do this (streamy na 20-30 riadkov..).
Nevidim zmysel v tom robit jednoduchy loop cez streamy, ale pri paralelnom spracovani to ma nieco do seba. Myslim ze netreba vsade bezhlavo pchat streamy. Ak clovek nieco moze, tak to neznamena, ze by aj mal..
-
Najlepšie by bolo, keby všetci intelektuáli spáchali samovraždu. Všetko len komplikujú a vytvárajú problémy tam, kde žiadne nie su.
To bys ještě lovil veverky s klackem v ruce, aby nechcíp hlady ;)
-
Najlepšie by bolo, keby všetci intelektuáli spáchali samovraždu. Všetko len komplikujú a vytvárajú problémy tam, kde žiadne nie su.
To bychom se naráz ocitli v Idiokracii. Spíše by to chtělo zbavit se těch slaboduchých, hned by se lépe žilo :)
-
Najlepšie by bolo, keby všetci intelektuáli spáchali samovraždu. Všetko len komplikujú a vytvárajú problémy tam, kde žiadne nie su.
To bychom se naráz ocitli v Idiokracii. Spíše by to chtělo zbavit se těch slaboduchých, hned by se lépe žilo :)
Jen intelekt nestačí, ještě potřebujete vhodný civilizační základ, a neomarxismus jím není.