Ako komplikovane programujete?

Re:Ako komplikovane programujete?
« Odpověď #30 kdy: 26. 03. 2019, 11:13:49 »
A ty externi knihovny zpusobi, ze musite pouzivat Maven. A ze se musi pouzivat Maven zpusobi, ze se musi pouzivat i Gradle. A ze se musi pouzivat Gradle zpusobi, ze se bude pouzivat i Ant. Vsechno se na sebe vrstvi a pak toho je hromada.
Co je to za nesmysl? Používáte buď Gradle, nebo Maven, nebo Ant, nebo třeba Ivy. Všechno jsou to systémy pro sestavení aplikace a budete je používat i kdybyste měl závislost jenom na JDK.

Ja se ptam, kdyz nekomu prijde Spring moc velky overhead pro jeho aplikaci, tak v cem jinem to ma potom fidlat?
V čem? Spíš pomocí jakých nástrojů, ne? A tak nějak mi připadá normální použít nástroje, které jsou pro daný účel vhodné. Pokud budu psát aplikaci pro příkazovou řádku, která dostane na vstupu XML, transformuje ho a zapíše do databáze, tak použiju Saxon, dom4j, JDBC driver, možná nějakou nadstavbovou knihovnu nad JDBC a možná něco na parsování argumentů příkazové řádky. K čemu by mi tam byl Spring?

O cehokoliv jineho nez Springu si uz budu klast otazku, jestli si ten backend nemam rovnou udelat v Node.js
Proč „rovnou“? Svět Javy a Node.js jsou dost odlišné, v Node.js se teď řeší věci, které má Java vyřešené třeba deset patnáct let, znovu se objevuje to samé.

A u veci slozitejsich uz se zase dobre hodi ten Spring, protoze ten overhead se ztrati.
Existují i jiné frameworky, než Spring. Spring je takové nové J2EE… Má nepopiratelné místo v historii, usnadnil spoustu věcí, ale už má příliš velkou zátěž z minulosti a snaží se řešit úplně všechno. Ale už vedle něho vyrůstají nástupci, kteří (nebo jejich následníci) Spring nahradí. Berou si ze Springu to dobré, opravují věci, které má Spring špatně ale kvůli zpětné kompatibilitě je nemůže opravit, umí se na Spring napojit tam, kde se to hodí. Třeba Micronaout.

Za me, Java se proste bohuzel nehodi na mensi veci, nez na ktere uz je vhodny Spring. Si myslim. Schvalne uvedte nejaky jiny priklad z praxe.
Podívejte se na Micronaout – DI inspirovaná Springem, ale udělaná správně (v compile-time místo run-time). Umí spolupracovat s GraalVM a vytvořit miniaturní binárky. Založený na neblokující síťové komunikaci, ale bez problémů můžete programovat synchronní kód a bude to fungovat správně. A protože máloco vzniká na zelené louce, potřebujete často nějaké vazby na Hibernate nebo Spring – a máte je tam. Klidně v tom můžete psát microservisy nebo cloudové lambdafunkce, a dává to smysl, protože pořád kolem sebe máte ten obrovský svět Javy, kdykoli můžete sáhnout po nějaké knihovně, a nemusíte se bát, že až vám těch microservis přibyde víc, bude to neudržovatelné.


Re:Ako komplikovane programujete?
« Odpověď #31 kdy: 26. 03. 2019, 15:29:32 »
A ty externi knihovny zpusobi, ze musite pouzivat Maven. A ze se musi pouzivat Maven zpusobi, ze se musi pouzivat i Gradle. A ze se musi pouzivat Gradle zpusobi, ze se bude pouzivat i Ant. Vsechno se na sebe vrstvi a pak toho je hromada.

Ja se ptam, kdyz nekomu prijde Spring moc velky overhead pro jeho aplikaci, tak v cem jinem to ma potom fidlat? (Doufam ze tu nejaky debil nenapise ze mam zkusit Play Framework a Scalu) O cehokoliv jineho nez Springu si uz budu klast otazku, jestli si ten backend nemam rovnou udelat v Node.js - protoze frontend uz asi dneska tezko budu fidlat na backendu a tak proste rovnou udelam i ten backend javascriptovy. A u veci slozitejsich uz se zase dobre hodi ten Spring, protoze ten overhead se ztrati.

Za me, Java se proste bohuzel nehodi na mensi veci, nez na ktere uz je vhodny Spring. Si myslim. Schvalne uvedte nejaky jiny priklad z praxe.

Jo a mluvim o vyvoji inf. systemu, stejne se dneska skoro nic jineho nedela.
Uvediem dva aktualne prilady z mojej praxe:
1) vyvoj nativnych rychlych command line toolov s minimom zavislosti na dynamickych knizniciach tretich stran v systeme
2) vyvoj nativnych mockovanych REST serverov s okamzitym startom a sub milisekundovym response time

Jak to udelas v Jave nativne?

kimec

Re:Ako komplikovane programujete?
« Odpověď #32 kdy: 26. 03. 2019, 15:59:04 »
Jak to udelas v Jave nativne?

Uplne normalne. Zoberiem Java bytecode, prezeniem ho AOT kompilerom a vybuildujem nativny binar pre Linux ci Mac. Binar bude obsahovat nativny kod mojej aplikacie a malinkaty runtime SubstrateVM s garbage collectorom. Je to nieco ako go, ale Java.

Re:Ako komplikovane programujete?
« Odpověď #33 kdy: 26. 03. 2019, 17:11:16 »

Re:Ako komplikovane programujete?
« Odpověď #34 kdy: 26. 03. 2019, 18:36:04 »
A ty externi knihovny zpusobi, ze musite pouzivat Maven. A ze se musi pouzivat Maven zpusobi, ze se musi pouzivat i Gradle. A ze se musi pouzivat Gradle zpusobi, ze se bude pouzivat i Ant. Vsechno se na sebe vrstvi a pak toho je hromada.
Co je to za nesmysl? Používáte buď Gradle, nebo Maven, nebo Ant, nebo třeba Ivy. Všechno jsou to systémy pro sestavení aplikace a budete je používat i kdybyste měl závislost jenom na JDK.

Ty nevis, jak to v enterprsise enviromentech chodi? Chodi to tak, ze budes pouzivat vsechny 3. Protoze jeden frajer pouzije Maven, druhy na sousedni komponente si mysli, ze Maven je moc oldschool tak pouzije Gradle, a treti si mysli ze Maven a Gradle na to jdou moc slozite a pouzije Ant nebo Ivy. Vsechny ty 3(4) pripady maji jednoho spolecneho predchudce - bordel v Jave, kde existuje hromada nic moc externich knihoven delajicich plus minus jedno a to same, protoze v zakladnim JDK na to serou a neudelali tam hromadu veci poradne.

V .NETu proste pouzijes vzdycky Nuget a to jeste ne vzdycky, protoze dost casto si vystaics s vecma co uz v .NETu jsou.

Uz jsem tu s tebou diskuzi v tomto stylu vedl v minulosti a neminim to delat znova, protoze to nema smysl, protoze ty mas proste problem pochopit takoveto nuance. Ty jsi technik typu knihomol, co ma hromadu veci nastudovane zpameti, ale davat si to do souvislosti trochu vice do siroka nezvladas. Nehlede na to ze diskuze s tebou na tema Java bude vzdycky stret zajmu, protoze ty jsi skolitel Java technologii a ke vsemu tu vystupujes pod svym vlastnim jmenem - takze asi tezko bys prohlasil na Internetu ze to co je v jave je proste sracka a to ikdyby sis to myslel.


Ad Micronaut - diky za tip, asi se na to nekdy podivam, nicmene prijde mi, ze uz se tu pres sebe v Jave placa pate pres devate, ani na GraalVM uz jsem se nedival, protoze v tom nevidim realne budoucnost. Podle me proste Java je uz zahraba v moc velkem bordelu a ja neverim tomu, ze to rozdycha. A nejak pochybuju, ze to zachrani Kotlin. Takovou vec proste musi mit nejaka spolecnost pod zastitou a valit do toho penize, protoze jinak to bude vypadat jako Java nebo jeste hur jako JS platforma (mysleno na stupnici srackoidity komunitnich vyrobku). Mimochodem at GraalVM tak Micronout tak cokoliv si neumim predstavit, ze by se nasazovalo tam, kde je Java doma - v korporacich. O duvod min pro me proc se o to zajimat.

Go na to jde dobre a od podlahy tim, ze osekava zbytecne veci, z OOP si nechal jen to co je opravdu uzitecne (polymorfismus pres interfacy) programy jsou rychle a malinke, ma komunitu co nebude chtit pridavat do jazyka kdejakou zbytecnou kravinu, atp.

Uz se tesim, az tato nova generace jazyku zacne vytlacovat Javu pryc. (jeste to dlouho potrva)
« Poslední změna: 26. 03. 2019, 18:41:21 od prihlaseny_uzivatel »


Re:Ako komplikovane programujete?
« Odpověď #35 kdy: 26. 03. 2019, 18:46:15 »
Jeste jsem chtel rict, ze hodne lidi vidi budoucnost v tom, ze se do jazyku pridavaji nove featury (treba streamy) a ze to je ten svaty gral, jak se to pohne dopredu a bude lip. Ja s tim zasadne nesouhlasim, myslim si, ze budoucnost je praveze jinde, je v osekavani zbytecnych veci, tak jak to dela Go. Myslim si, ze tento pristup do budoucna vyhraje.

kimec

Re:Ako komplikovane programujete?
« Odpověď #36 kdy: 26. 03. 2019, 19:33:38 »
Jeste jsem chtel rict, ze hodne lidi vidi budoucnost v tom, ze se do jazyku pridavaji nove featury (treba streamy) a ze to je ten svaty gral, jak se to pohne dopredu a bude lip. Ja s tim zasadne nesouhlasim, myslim si, ze budoucnost je praveze jinde, je v osekavani zbytecnych veci, tak jak to dela Go. Myslim si, ze tento pristup do budoucna vyhraje.
To iste sa predsa deje aj v Jave - modularizacia JDK - project Jigsaw.
So streamami nemate pravdu. Kazdy Javista, ktory za nieco stoji, predsa vie, ze streamy svojou pomalostou nikdy nenahradia iteraciu cez for slucku. Je to podmiene implementaciou a pouzitim invokedynamic. Nikdo predsa nikdy nepovedal, ze streamy musite bezpodmienecne pouzivat na vsetko a ze je to buducnost jazyka. To by bolo trochu stupidne, nie? Alokacie v tesnej slucke vytvaraju zbytocny tlak na garbage collector a vo vysledku spomaluju iteraciu. Ked robite IO nemusi to vadit, ale ked iterujete pole v pamati, naco streamy? Snad si vyberam nastroj podla charakteru problemu, ktory riesim, nie?

Re:Ako komplikovane programujete?
« Odpověď #37 kdy: 26. 03. 2019, 20:31:55 »
Zabudnite na go, javy, .Net-y a podobne blbosti. Borci aj tak pouzivaju iba Haskell.

Re:Ako komplikovane programujete?
« Odpověď #38 kdy: 26. 03. 2019, 21:19:43 »
Ty nevis, jak to v enterprsise enviromentech chodi? Chodi to tak, ze budes pouzivat vsechny 3. Protoze jeden frajer pouzije Maven, druhy na sousedni komponente si mysli, ze Maven je moc oldschool tak pouzije Gradle, a treti si mysli ze Maven a Gradle na to jdou moc slozite a pouzije Ant nebo Ivy.
To bych chtěl vidět, jak ty tři/čtyři nástroje použijete najednou k sestavení jedné komponenty. Spíš bych si tipnul, že si vymýšlíte. Pokud se ty nástroje používají pro „sousední“ komponenty, je vám úplně jedno, jaký nástroj se pro sestavení používá – vy dostanete hotové JARko, případně obohacené o model závislostí (např. pom.xml), ke kterému se chováte jako k jakékoli jiné knihovně.

Vsechny ty 3(4) pripady maji jednoho spolecneho predchudce - bordel v Jave, kde existuje hromada nic moc externich knihoven delajicich plus minus jedno a to same, protoze v zakladnim JDK na to serou a neudelali tam hromadu veci poradne.
To samé máte třeba v opensource, firmy na trhu nebo živí tvorové – také hromada nic moc různých variant téhož, místo aby se napsal jeden program, existovala jedna firma a jeden živý tvor, které by ale byli udělané pořádne.

Uz jsem tu s tebou diskuzi v tomto stylu vedl v minulosti a neminim to delat znova, protoze to nema smysl, protoze ty mas proste problem pochopit takoveto nuance.
Nemám problém to pochopit. Akorát si myslím, že jste si kód, kde se používá pro sestavení Maven, Gradle i Ant, prostě vymyslel.

protoze ty jsi skolitel Java technologii
Tak určitě. A pak se divíte, že vaše komentáře beru s velkou rezervou, když vidím,jak si vymýšlíte.

Ad Micronaut - diky za tip, asi se na to nekdy podivam, nicmene prijde mi, ze uz se tu pres sebe v Jave placa pate pres devate, ani na GraalVM uz jsem se nedival
Hlavně že máte ty praktické zkušenosti.

A nejak pochybuju, ze to zachrani Kotlin.
Ne, Kotlin to určitě nezachrání. Jednak teda není co zachraňovat, jednak Kotlin je jen zajímavý experiment, ze kterého se vezme pár věcí, které se osvědčí, a nebude to tak bolet, když s ním zaniknou ty věci, které se neosvědčily.

Uz se tesim, az tato nova generace jazyku zacne vytlacovat Javu pryc. (jeste to dlouho potrva)
Nemyslím si, že Kotlin nebo Go budou ty jazyky, které se dlouhodobě prosadí. Hodně experimentují, a jazyk, který se dlouhodobě prosadí, musí být dost konzervativní. Kotlin i Go jsou taková líheň nápadů, ale ještě nejsou ty pravé, to přijde až někdy po nich.

Jeste jsem chtel rict, ze hodne lidi vidi budoucnost v tom, ze se do jazyku pridavaji nove featury (treba streamy) a ze to je ten svaty gral, jak se to pohne dopredu a bude lip. Ja s tim zasadne nesouhlasim, myslim si, ze budoucnost je praveze jinde, je v osekavani zbytecnych veci, tak jak to dela Go. Myslim si, ze tento pristup do budoucna vyhraje.
Osekávání vlastností, přílišná jednoduchost, je to, co se většinou vytýká Javě. A vy byste chtěl osekávat ještě víc. Což je přesně ten důvod, proč nikdy nevyhrají ani extrémně složité jazyky (teda s výjimkou C++), ani ty extrémně jednoduché. Protože by je nikdo z toho druhého tábora nechtěl ani neuměl používat. Zatímco na jazyk, který je někde uprostřed, sice oba tábory svorně nadávají, ale nakonec ho používají, protože se díky němu mohou potkat.

Re:Ako komplikovane programujete?
« Odpověď #39 kdy: 26. 03. 2019, 21:30:54 »
Je to podmiene implementaciou a pouzitim invokedynamic.
K čemu se v implementaci Java Stream API používá invokedynamic? A kde je to implementováno? Podle mne je celé Stream API implementováno v Javě a nevyžaduje žádnou magii na straně kompilátoru.

Re:Ako komplikovane programujete?
« Odpověď #40 kdy: 26. 03. 2019, 21:36:58 »
Zabudnite na go, javy, .Net-y a podobne blbosti. Borci aj tak pouzivaju iba Haskell.

Fortran 77 alebo LISP. V núdzi (keď ide o ms odozvy a kvalitu kódu) BASIC.

kimec

Re:Ako komplikovane programujete?
« Odpověď #41 kdy: 26. 03. 2019, 22:50:05 »
Je to podmiene implementaciou a pouzitim invokedynamic.
K čemu se v implementaci Java Stream API používá invokedynamic? A kde je to implementováno? Podle mne je celé Stream API implementováno v Javě a nevyžaduje žádnou magii na straně kompilátoru.
Hovorim o pomalosti streamov v Jave. Ta je sposobena samotnou implementaciou, ktora vyzaduje alokacie podpornych instancii s kratkodobou zivnotnostou, ktore je nasledne nutne dealokovat a teda zvysuje tlak na garbage collector. Kvoli charakteru implementacie streamov, kde referencie na podporne instancie unikaju mimo metody, kde boli alokovane, tu nezafunguje ani Escape Analysis tak ako je dostupny vo vanilla HotSpote.
Dalsim zdrojom pomalosti su lambdy, ktore sa v streamoch bezne pouzivaju, a ktore su implementovane cez invokedynamic. Prvotna warmup faza bude vzdy draha kvoli generovaniu anonymnej triedy, ktora bude sluzit ako factory pre lambdy daneho typu - toto sposobi spomalnie iba pri prvotnom pouziti. Avsak horsie je, ze lambdy, ktore referencuju premenene metody alebo fieldy instancie, kde je lambda zadeklarovana, vyzaduju rovnako alokacie na heape a nasledne dealokacie.

Predpokladam, ze Graal so svojou Partial Escape Analysis pomoze streamom prave oddalovanim materializacie instancii na heape... ale snad nebudem upgradovat VM na 3 urovnovi JIT kompiler, aby som zrychlil jednu forEach() slucku, ktoru dokazem zrychlit jednoduchym prepisom na for.

Uz rozumiete ako som to myslel?
 

Re:Ako komplikovane programujete?
« Odpověď #42 kdy: 26. 03. 2019, 23:17:11 »
Jako skoro vsechno jde snad prepsat na "for", potiz ale je v tom, poznat, co ten optimalizovanej "for" loop dela. For-loop vs foreach s lambdou, to je imho presne ta vec, co by mel delat kompilator, ne programator. Taky programator v C nedela rucne loop-unwind a udela to za nej prekladac

kimec

Re:Ako komplikovane programujete?
« Odpověď #43 kdy: 26. 03. 2019, 23:50:03 »
Jako skoro vsechno jde snad prepsat na "for", potiz ale je v tom, poznat, co ten optimalizovanej "for" loop dela. For-loop vs foreach s lambdou, to je imho presne ta vec, co by mel delat kompilator, ne programator. Taky programator v C nedela rucne loop-unwind a udela to za nej prekladac
Rozumiem vam, ale zrovna tento pripad je znamy fakt. Je to nestastna kombinacia viacerych faktorov.

Inak, rychly google search ponukol clanok Better Java Streams performance with GraalVM. Myslim, ze som ten clanok aj cital, ale uz si nepamatam presne. Kazdopadne, povedal by som, ze pri Java streamoch Graal doslova pletie z h*vna bic.

Re:Ako komplikovane programujete?
« Odpověď #44 kdy: 27. 03. 2019, 07:17:54 »
For-loop vs foreach s lambdou, to je imho presne ta vec, co by mel delat kompilator, ne programator.
Ještě lepší je, když to nedělá kompilátor, ale běhové prostředí, protože to má informace o aktuálním běhu programu, takže může dělat i optimalizace, které kompilátor dělat nemůže.

Když to ale vrátím k původnímu tématu diskuse, optimalizace rychlosti aplikace inlineováním kódu ve smyčkách je na světelné roky daleko od situace, kdy někdo používá v aplikaci nějaký framework a vůbec neví proč.