Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: tralala5 24. 03. 2019, 12:17:46
-
Caute,
vela programujem v Jave a v poslednom case som sa prichytil pri tom, ze som zacal preferovat komponenty a libky ktore su v Jave samotnej. Dlho som napriklad pouzival Jackson a ekosystem okolo na JSON alebo Apache HTTP libky na HTTP klientov ale uz celkom dlho existuje JSON-B / JSON-P a Java ma v sebe HttpClient-a ... Najprv som sa bal ze to nebude vela vediet ale cuduj sa svete, ono to ani nie je treba. Co zacinam nove projekty tak zamerne programujem uplne jednoducho v cistej Jave takze som zavisly na minime externych veci a ono to na pocudovanie aj celkom funguje. Zahodil som cely Spring a zacal som pouzivat Guice a Javalin. Na JWT tokeny java-jwt z com.auth0 a tiez to uplne v pohode fici jak ma ... raketovo sa v tom programuje.
Pouzivate externe libky aj ked nemusite? Zacal som to brat z uplne ineho konca, co najmenej externalit a vyuzit platformu na 100% a zatial sa mi nestalo, ze by mi tam nieco chybalo. Podla mna sa da vela krat dosiahnut ten isty ciel aj jednoduchsie, vsetky tie frameworky su vela krat len uplne zbytocne nadstavby.
-
Problem tady toho nahrazovani Springu a podobne je v tom, ze v korporatu v tom lidi budou prasit. Lidi nejsou schopni ani nezprasit REST api, jsou zmateni, maji problem se zamyslet. Byl by to jeden velky bordel, ustavicne objeovani kola atd.
Taky jsem to zkousel, protoze me stvala tezkopadnost Spring Bootu a Jersey a dalsich a muj zaver z toho vseho je, ze Java na to co delas ty proste neni delana. Bohuzel :( Cela ta platforma je delana jako tezka zemedelska technika do korporatu, vsechny ty frameworky kolem toho at.
Servlet API je stare a otresne a kdyz budes chtit delat REST, tak rucne bez anotaci je to proste na houby, je to skarede. Ja zkousel Spark... I ten Spark je v podstate zdupany.
Tzn. zaver ktery jsem si udelal je, ze na ne-corporate male veci Node.js. A je to. Stejne se to hodi do stacku to znat tak co. A doma uz nic neprgramuju, nemam na to cas. A v praci mi dupani se Springem plati, tak co.
Taky to nemam rad, kdyz se porad vymysli narovnavaky na ohybaky a znovu a znovu, ale Javu uz v tomto nikdo nezachrani podle me.
Budoucnost vidim v Go-like platforme.
-
Mimochodem ten Go me zaujal velice prevelice, web aplikace dokaze bleskurychle nastartovat, neveme si skoro zadnou RAM.
Mimochodem ted kdyz mluvim o Go, tak ja pouzivam Mac a fascinujou me velikosti aplikaci v Appstoru, napr. jsem si stahoval graficky peknou RSS ctecku a mela jenom nejake 3MB! A tohle je uplne bezne, ze ty Apple devkit aplikace jsou takove male.
Podle me Java proste bohuzel uz pomalu zacina patrit do minuleho stoleti. Lidi si zacinaji uvedomovat, ze takove to porekadlo ze na rychlosti nezalezi, mas na to koupit silnejsi stroj, proste neplati. Zalezi na tom a zalezi na tom docela dost.
-
pouzivam Mac a fascinujou me velikosti aplikaci v Appstoru, napr. jsem si stahoval graficky peknou RSS ctecku a mela jenom nejake 3MB! A tohle je uplne bezne, ze ty Apple devkit aplikace jsou takove male.
Většina kódu je v libSystem, Foundation a AppKitu, což jsou dynamické knihovny.
-
Podle me Java proste bohuzel uz pomalu zacina patrit do minuleho stoleti. Lidi si zacinaji uvedomovat, ze takove to porekadlo ze na rychlosti nezalezi, mas na to koupit silnejsi stroj, proste neplati. Zalezi na tom a zalezi na tom docela dost.
Každý, kdo má mozek, tohle viděl už přinejmenším od roku 2010.
-
pouzivam Mac a fascinujou me velikosti aplikaci v Appstoru, napr. jsem si stahoval graficky peknou RSS ctecku a mela jenom nejake 3MB! A tohle je uplne bezne, ze ty Apple devkit aplikace jsou takove male.
Většina kódu je v libSystem, Foundation a AppKitu, což jsou dynamické knihovny.
No tak to je jasne.
-
Podle me Java proste bohuzel uz pomalu zacina patrit do minuleho stoleti. Lidi si zacinaji uvedomovat, ze takove to porekadlo ze na rychlosti nezalezi, mas na to koupit silnejsi stroj, proste neplati. Zalezi na tom a zalezi na tom docela dost.
Každý, kdo má mozek, tohle viděl už přinejmenším od roku 2010.
A každý kdo má ještě větší mozek to viděl už v roce 2000?
-
Podle me Java proste bohuzel uz pomalu zacina patrit do minuleho stoleti. Lidi si zacinaji uvedomovat, ze takove to porekadlo ze na rychlosti nezalezi, mas na to koupit silnejsi stroj, proste neplati. Zalezi na tom a zalezi na tom docela dost.
Každý, kdo má mozek, tohle viděl už přinejmenším od roku 2010.
A každý kdo má ještě větší mozek to viděl už v roce 2000?
Každý, kdo má mozek, tohle viděl už v roce 1980. Potom z BASICu urychleně přešel buď na C nebo rovnou na assembler!
-
Každý, kdo má mozek, tohle viděl už v roce 1980. Potom z BASICu urychleně přešel buď na C nebo rovnou na assembler!
Tehdy jsem šel do Pascalu, ve kterém jsou aplikace stejně rychlé, ale nemusím přitom tolik přemýšlet, na jakém HW to poběží. Dnes jen lituji, že jsem se už tenkrát nenaučil Lisp.
-
snazim sa programovat co najmenej komplikovane. inspiraciu a osvietenie cerpam odtialto:
https://en.wikipedia.org/wiki/KISS_principle
http://suckless.org/
-
snazim sa programovat co najmenej komplikovane. inspiraciu a osvietenie cerpam odtialto:
https://en.wikipedia.org/wiki/KISS_principle
http://suckless.org/
Suckless sucks.
-
Tak a je to tady, jasný důkaz že root umřel, žádná diskuze na zajímavé téma se tu nekoná. Redakce Root poškodila nás věrné přispěvatele, protože odradila spoustu lidí, kteří k tomuto tématu mohli mít co říct.
-
Povedal tu niekto Haskell?
-
no ja som sa dostaldo tazkej depky z tohoto, nepomaha ani chlast :D zistujem ze najlepsie sa mi pracuje samemu, ono ked je nejaky korporatny projekt tak paradoxne najrychlejsie a najlepsie to spravi minimum az jeden clovek od zaciatku do konca pretoze akonahle sa na to nasadi skupina ludi tak to je uplny chaos. fakt nechapem, preco si manazeri myslia ze medzi produktivitou a poctom ludi je priama umera. prave naopak. jeden az traja schopny programatori ked vedia co robia to naprogramuju od piky omnoho rychlejsie a kvalitnejsie ako desat ludi pretoze ten overhead s komunikaciou a meetingami a preberanim nepodstatneho je tam potom obrovsky.
-
fakt nechapem, preco si manazeri myslia ze medzi produktivitou a poctom ludi je priama umera. prave naopak.
Lebo vacsinou na menezerskych poziciar robia rozni elektrikari, zootechnici a filozofi. Pripadne kodili pred 40-timi rokmi vo fortrane. Ak by mali nieco nastudovane o softverovom inzinierstve a jeho metodikach, tak by si take nemysleli. To, co si napisal plati do urcitej velkosti projektu, ak je projekt vacsi a spravne sa modularizuje, tak je produktivita lepsia samozrejme, ked to robi viac ludi. (Samozrejme, ze tam tiez vznikaju rozne sumy, nedorozumenia, prestoje atd ...)
-
Protoze se snazi prodat co nejvice lidi zakaznikovi jednak, a taky mit nejakou redundanci lidi. Jestli delas v korporatu a vadi ti tohleto, tak je pritlac ke zdi at te daji na jiny projekt kde toto neni - kazdy korporat ma dobre a i horsi projekty. Jestli ti nekde dali zbytecne 10 lidi tak si tipnu, ze to aroven bude solidni zumpa, kdyz i zakaznik je tak blby ze si tohle necha libit.
-
... jeden az traja schopny programatori ked vedia co robia to naprogramuju od piky omnoho rychlejsie a kvalitnejsie ako desat ludi pretoze ten overhead s komunikaciou a meetingami a preberanim nepodstatneho je tam potom obrovsky.
Kdyz mam 3 schopne seniorni programatory tak aby meli cas na programovani a nemuseli resit p******y tak k nim posadim nekoho kdo:
- Bude reportovat zakaznikovi a starat se o rozpocet - project manager nebo tak neco +1
- Kdo bude analyzovat business pozadavky a psat funkcni dokumentaci +2
- Nekoho kdo se postara o testovani (at uz manual nebo auto) +3
- A mel bych si vychovat nejake juniory at mam priste kde brat ty seniory +2
3 + 1 + 2 + 3 + 2 = 11
Takove tymy casto vidam a prijde mi to unosne i kdyz komunikacni overhead tam znatelny je.
Jeste sem nevidel tym o deseti programatorech.
-
snazim sa programovat co najmenej komplikovane. inspiraciu a osvietenie cerpam odtialto:
https://en.wikipedia.org/wiki/KISS_principle
http://suckless.org/
Suckless sucks.
Suckless sucks less.
-
snazim sa programovat co najmenej komplikovane. inspiraciu a osvietenie cerpam odtialto:
https://en.wikipedia.org/wiki/KISS_principle
http://suckless.org/
Suckless sucks.
Suckless sucks less.
Suckless sucks. Terribly.
-
Najprv som sa bal ze to nebude vela vediet ale cuduj sa svete, ono to ani nie je treba. Co zacinam nove projekty tak zamerne programujem uplne jednoducho v cistej Jave takze som zavisly na minime externych veci a ono to na pocudovanie aj celkom funguje. Zahodil som cely Spring a zacal som pouzivat Guice a Javalin. Na JWT tokeny java-jwt z com.auth0 a tiez to uplne v pohode fici jak ma ... raketovo sa v tom programuje.[
...] vsetky tie frameworky su vela krat len uplne zbytocne nadstavby.
Nahradili ste jeden framework za druhy a pouzivate viac prostrdiekov, ktore ponuka JDK. Ci to skomplikovalo programovanie, ukaze cas, ked vas kod prejde do "maintenance modu", popripade pribudne uplne nova funkcionalita (ktora nebola sucastou provodneho zadania), projekt bude treba nadalej udrziavat funkcny a pripadne ho preberie niekto iny.
Jeden z dovodov, preco sa v korporatnom svete pouziva Spring je ten, ze su viac menej zname "naklady" na jednotlive fazy zivota projektu. Inymi slovami, ked toho jedneho cloveka (http://"https://github.com/tipsy/javalin/graphs/contributors"), ktory Javalin vyvyja, prejde autobus, alebo ho prestane bavit vyvyjat, mozete mat problem.
Toto samozrejme neplati pre prostriedky pochadzajuce z JDK. Tam robite velmi dobre, ked pouzivate to, co mate dostupne. Problem s vecami z JDK je casto krat casovanie, kedy tato funkcionalita do JDK pribudne. Mnohe frameworky nemohli cakat X rokov, kym vyjde JDK a preto prisli s vlastnymi rieseniami. Do JDK bola funkcionalita pridana ex post, no uzus nastoleny frameworkami sa uz nevykorenil.
Narozdiel od vyvojara, frameworky maju jasnu predstavu o zavislostiach na knizniciach 3tich stran a ocakavaju nejake konkretne prostredie - niekedy moze byt paradoxne jednoduchsie pouzivat neJDK veci, bohuzial.
-
Este by som rad reagoval na "sub thread" o Jave, ktory sa tiez rozbehol v tomto trheade.
Myslim si, ze aktualne sa ma Java velmi dobre.
Co sa tyka technologickej stranky, Java pravdepodobne zaziva najvacsi rozvoj za poslednu dekadu. Znacne tomu pomohol aj novy release model.
Nova funkcionalita moze pribudat iba vtedy, ked su veci v pohybe, ale dramaticke zmeny so sebou prinasaju aj rozbijanie rozhrani a starej funkcionality.
Osobne si myslim, ze treba este chvilu pockat, kym sa cely ekosystem stabilizuje, ale uz sa viac menej crta cesta:
a) staticky kompilovana depdency injection
b) nativne kompilovane binarky a la go
c) neblokujuce IO a korutiny
d) structy ako z C
Skratka, pritiahnute za vlasy, ked prach usadne, nebude treba ani Go ani node.js a trapna servletova aplikacia bude mat rovnake performance charakteristiky.
Treba si uvedomit, ze Java ma nadalej velke memomentum, samozrejem aj vdaka korportanemu svetu. Akykolvek technologicky refresh Javy ma dopad na velku cast biznis sveta.
-
Caute,
vela programujem v Jave a v poslednom case som sa prichytil pri tom, ze som zacal preferovat komponenty a libky ktore su v Jave samotnej. Dlho som napriklad pouzival Jackson a ekosystem okolo na JSON alebo Apache HTTP libky na HTTP klientov ale uz celkom dlho existuje JSON-B / JSON-P a Java ma v sebe HttpClient-a ... Najprv som sa bal ze to nebude vela vediet ale cuduj sa svete, ono to ani nie je treba. Co zacinam nove projekty tak zamerne programujem uplne jednoducho v cistej Jave takze som zavisly na minime externych veci a ono to na pocudovanie aj celkom funguje. Zahodil som cely Spring a zacal som pouzivat Guice a Javalin. Na JWT tokeny java-jwt z com.auth0 a tiez to uplne v pohode fici jak ma ... raketovo sa v tom programuje.
Já moc nechápu, o čem vlastně chcete diskutovat. V titulku máte „komplikovanost“, ale v samotné otázce k ní pak není ani čárka.
Co se týče knihoven, samozřejmě nemá smysl používat externí knihovnu, pokud vašim potřebám vyhovuje i vestavěná runtime knihovna.
Knihoven pro JSON vzniklo několik, Jackson je mezi nim i asi nejrozšířenější. Používá ho i spousta dalších knihoven, takže občas jste k jeho použití donucen jinou knihovnou. Na druhou stranu to, jak je ta knihovna navržená, není žádná sláva. JSON-P je dobře navržené API, bylo to standardizováno, doufám, že postupně převezme roli toho standardního API pro JSON v Javě, že ho bude implementovat i Jackson a další. JSON-B je jiný případ, sice také snaha o standardní API, ale to API je nešťastně navržené a špatně zdokumentované. Referenční implementaci jsem naposledy zkoušel krátce před verzí 1.0 a bylo to docela dobrodružné – v jednom případě se něco špatně přetypovávalo a vyhazovalo o výjimku, v druhém případě dokonce bylo evidentní, že to nikdo nikdy neotestoval na mapě s více než jedním klíčem, protože zbytek mapy se prostě zahodil.
Původní HTTP klient v Javě byla tragédie a nemohl ho použít nikdo, kdo alespoň z rychlíku zaslechl něco o tom, jak má vypadat programování síťové komunikace. Nešlo tam nastavit nic, ani tak základní věc, jako timeouty. Proto se používaly externí knihovny. Teď už má Java HTTP klienta, který vypadá podstatně lépe, ale abych pravdu řekl, je to snad jediná věc z nových vlastností Javy, na kterou jsem se ještě víc nedíval – protože ta původní implementace byla opravdu tragédie, a být „podstatně lepší“ než to pořád ještě nezaručuje, že to bude alespoň dobré. Ale pokud už má vlastnosti, které potřebujete, a nepotřebujete podporu starších verzí Javy, proč to nepoužít?
To samé se týká i Springu – pokud ho nepotřebujete, tak proč ho používat? Spring spoustu věcí také implementuje tak, že akorát zabalí nějakou externí knihovnu tak, aby se používala stejně, jako ostatní komponenty Springu. Tak pokud potřebuju jenom funkcionalitu dané knihovny, použiju tu knihovnu a ne celý Spring.
Pouzivate externe libky aj ked nemusite? Zacal som to brat z uplne ineho konca, co najmenej externalit a vyuzit platformu na 100% a zatial sa mi nestalo, ze by mi tam nieco chybalo. Podla mna sa da vela krat dosiahnut ten isty ciel aj jednoduchsie, vsetky tie frameworky su vela krat len uplne zbytocne nadstavby.
Ta zbytečnost není vlastností frameworku ale jeho použití. Mne by spíš zajímalo, jak se vám stalo, že používáte externí knihovnu, i když nemusíte, nebo používáte zbytečně nějaký framework. Já se s takovými případy nesetkávám a moc si nedovedu představit, jak to vznikne.
-
Tak a je to tu, pan Jirsak zde dal opet erudovanou odpoved, ale pointu diskuze uz moc nepochopil, jak sam nekolikrat zminuje. Jak tradicni u pana Jirsaka. Ja jsem to treba pochopil a myslim si, ze mnozi dalsi taky, pane Jirsaku.
Tazatele stve overhead frameworku a importovani hromady externich knihoven, klade si spravnou otazku, proc se neda vystacit se zakladnimi vecmi, ktere poskytuje Java. Normalni jeste zdravy clovek si totiz kladu otazku, proc se neco dela slozite, kdyz to jde jednoduse.
No v Jave to bohuzel moc dobre nejde a to kvuli tomu, ze zakladni knihovna nedisponuje dostatecne kvalitne udelanymi vecmi. Pokud nekdo nevi jak to myslim, tak at se podiva jak to maji vsechno pekne vyresene v .NETu. Tak by to melo vypadat, kdyz se majitel platformy o ni stara.
Ja treba pridam jeste naprosto vtipny Unzip v JDK, ktery nejenom ze je pomaly jako snek, ale jeste navic v podstate zcela znemozni odzipovavat vnorene zipy kompletne v pameti - mezirozbalovacky se musi vzdycky ukladat na hdd.
-
.NET je uz daleko pred JAVOU. Nakolko sa rozbieha v plnej krase .NET Core, je dost mozne, ze JAVA bude pomalicky vytlacana aj z miest, kde prevlada JAVA.
-
.NET je uz daleko pred JAVOU. Nakolko sa rozbieha v plnej krase .NET Core, je dost mozne, ze JAVA bude pomalicky vytlacana aj z miest, kde prevlada JAVA.
.NET je pred Javou, ale .NETisti ne, chlapce. A o tom jestli .NET stihne Javu prevalcovat bych se hadal, protoze Windows a MS veci jsou utter crap a dokud nebude .NET plne nezavisly na Win, coz se podle me nikdy nestane, tak ma utrum.
(http://ammonsonline.com/content/images/2014/Mar/CarWars.png)
-
Java je umierajúci <píp>... čo kecá kimec kecá totálne <píp>, skôr by som povedal že práve Golang a Node.js nahrádzajú Javu v plnej sile, a nie naopak... Ešte bych k tej dvojici pridal Scalu... Java ako platforma skvelá vec, ale ako programovací jazyk totálne <píp> <píp>... A áno .NET a MS vieme jak je na tom kvalitou, ale i tak je pred Javou.
-
Tazatele stve overhead frameworku a importovani hromady externich knihoven, klade si spravnou otazku, proc se neda vystacit se zakladnimi vecmi, ktere poskytuje Java. Normalni jeste zdravy clovek si totiz kladu otazku, proc se neco dela slozite, kdyz to jde jednoduse.
Já jsem se ptal na otázku, která tomuhle ještě předchází – jak se stane, že to někdo začne dělat složitě, když to jde dělat i jednoduše. Vy řešíte případ, že někdo už začal špatně a pak se ptá, jestli to nejde lépe. Já se ptám, jak se stane, že někdo začne špatně.
Určitou teorii na to mám – že lidé neznají JDK a neznají různé knihovny, znají akorát Spring (v téhle souvislosti se vždy objevuje jen Spring, často dotyčný píše o Javě a najednou píše o Springu, jako by to bylo jedno a to samé). Tím pádem se snaží vše dělat ve Springu.
No v Jave to bohuzel moc dobre nejde a to kvuli tomu, ze zakladni knihovna nedisponuje dostatecne kvalitne udelanymi vecmi. Pokud nekdo nevi jak to myslim, tak at se podiva jak to maji vsechno pekne vyresene v .NETu. Tak by to melo vypadat, kdyz se majitel platformy o ni stara.
V základní knihovně Javy existují i dobře udělané věci, například kolekce – nejspíš těch věcí dokonce bude většina, když se Java tak rozšířila. A cílem samozřejmě není mít vše narvané v základní knihovně, naopak je dobře, že máte spoustu specializovaných knihoven a vyberete si tu, která vám vyhovuje nejlépe.
Ja treba pridam jeste naprosto vtipny Unzip v JDK, ktery nejenom ze je pomaly jako snek, ale jeste navic v podstate zcela znemozni odzipovavat vnorene zipy kompletne v pameti - mezirozbalovacky se musi vzdycky ukladat na hdd.
Otázkou je, proč by zrovna propracovaný unzip měl být v základní knihovně Javy. Jaký podíl Java aplikací asi potřebuje rozbalovat zip v zipu? Není lepší, když takové aplikace použijí externí knihovnu, která může mít rychlejší vývojový cyklus a poskytovat toho mnohem víc?
-
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.
-
no ja som sa dostaldo tazkej depky z tohoto, nepomaha ani chlast :D zistujem ze najlepsie sa mi pracuje samemu, ono ked je nejaky korporatny projekt tak paradoxne najrychlejsie a najlepsie to spravi minimum az jeden clovek od zaciatku do konca pretoze akonahle sa na to nasadi skupina ludi tak to je uplny chaos. fakt nechapem, preco si manazeri myslia ze medzi produktivitou a poctom ludi je priama umera. prave naopak. jeden az traja schopny programatori ked vedia co robia to naprogramuju od piky omnoho rychlejsie a kvalitnejsie ako desat ludi pretoze ten overhead s komunikaciou a meetingami a preberanim nepodstatneho je tam potom obrovsky.
To je tvoj pohlad. ale co ked sa ten jeden programator jedneho dna zdvihne a pojde prec. Prebrat projekt nie je otazka 10 minut, zvlast, ked sa vyvijal niekolko rokov. Preto sa casto vyuziva parove programovanie, alebo je do toho zapojenych viac ludi.
Nejde len o naprogramovanie, ale co v pripade problemov v produkcii, ak hlavny programator bude niekde na dovolenke. To bude firma cakat kym sa nevrati? Radsej si to nechaju nakodit v systeme, ktoremu rozumie viac ludi a vedia sa kedykolvek nahradit.
Casto tie meetingy su strata casu, ale na druhej strane velakrat sa tam dozvies "nepodstatne malickosti", ktore dost podstatne zasiahnu do vyvoja. napr. ze zabudli na nejaku funkcionalitu, alebo hlanicne situacie v urcitych pripadoch.
Programator sa casto pozera len zo svojho pohladu - ja to nakodim takto a bude to dobre. Ale z pohladu bussinnessu tam ide aj o to, aby sa o ten sw mal kto postarat, fixnut chybu, pripadne rozsirit nielen teraz, ale aj o 1, 2, 5 rokov (taky interny firemny system zije aj 10 rokov).
-
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
-
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é.
-
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?
-
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.
-
Jak to udelas v Jave nativne?
GraalVM (https://www.graalvm.org/)
-
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)
-
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.
-
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?
-
Zabudnite na go, javy, .Net-y a podobne blbosti. Borci aj tak pouzivaju iba Haskell.
-
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.
-
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.
-
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.
-
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?
-
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
-
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 (http://"https://medium.com/graalvm/stream-api-performance-with-graalvm-be6cfe7fbb52"). 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.
-
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č.
-
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.
Možná je to myšleno jako vtip, ale Lisp s knihovnami ve Fortranu skutečně nemá chybu.