Příspěvky

316

Vývoj / Re:Ideálny programovací jazyk

« kdy: 13. 05. 2019, 13:29:37 »

Asi bychom si nejprve měli ujasnit, co je await/async – je to syntaktický cukr, aby kód, který se provádí asynchronně, byl zapsaný jako klasický synchronní kód. Normálně u asynchronního volání určíte, co se má dít po do dokončení příslušného kódu. Await/async znamená, že to asynchronní volání nějak označíte (pokud má podporu přímo jazyk, obvykle klíčovým slovem await), a kód, který se má provést po dokončení asynchronního volání pak píšete pod to asynchronní volání. Ohledně možností toho, co můžete napsat, se nic nemění.

Pane Jirsak, ja jsem to rekl nepresne, ale to vy taky.

V C#, Await by se dal povazovat za syntakticky cukr pro neco jako "CompletableFuture.get()" ale Async cukr uz neni. O keyword Async uz nemuzete rict, ze je to cukr pro ktery kompilator provede neco jako "CompletableFuture.supplyAsync(()->.)" Na zklade klicoveho slova Async se musi nejak vygenerovat stavovy stroj, predstavu jak funguje mam jen pribliznou.

A to je to, co Java neumi. Kotlin to umi ale je to experimentalni feature.

V Javascriptu si nejsem jisty, zda Promise predstavuje stejny mechanismus jako Coroutiny v C#.

317

Vývoj / Re:Ideálny programovací jazyk

« kdy: 13. 05. 2019, 13:04:01 »

A je jedno, ze si nekdo mysli, jak se da neco zbastlit s await async a coroutinami. Zbastlit se da totiz uplne vsechno.

Java NEUMI Coroutiny a rovnocenna nahrada za ne neexistuje. Tecka.

A neumi coroutiny proto, ze by byly uplna na hovno, kdyz Java dodneska nema neblokujici API prinejmensim k JDBC. Protoze vyzirkove z Oracle teprve minuly rok zacali vyvije standard pro asynchronni JDBC, ikdyz .NET uz to davno vsechno ma zmaknute.

318

Vývoj / Re:Ideálny programovací jazyk

« kdy: 13. 05. 2019, 12:59:38 »

To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async - a proto nemuzete vyrabet novy thread pokade kdyz se vola nejaka metoda.

Neber si to osobně, ale tohle je dost odstrašující příklad přístupu k asynchronnímu programování.

1. chci používat jazyk s mutabilními strukturami (navíc OOP!)
2. async/paralelizaci si představuju tak, že všude možně prsknu async a await
3. očekávám, že to po mně nebude nic chtít, protože to bude "jakože běžet v jednom vlákně"
4. díky tomu, že mám sem tam ten async a await, to bude automagicky škálovat

Prvně by asi nebylo od věci si uvědomit, že

1. async/await není nic jiného než syntaktický cukr, který z programátora jenom snímá nutnost používat napřímo promisy (nebo jiný podobný mechanismus) a překladač je tam doplňuje sám. Takže všechno, co platí pro promisy (popř. ten jiný podobný mechanismus), platí i pro async/await kód.

2. neexistuje žádný zázračný "neblokující kód", který automagicky vede k vyššímu výkonu. Celý je to zcela prostý: pokud mám operace A, B, C, kde A a B jsou vzájemně nezávislé a C je závislé na A i B, tak se hodí A a B spustit zaráz a C až potom, co A i B doběhnou. Zázračný "neblokující kód" je samozřejmě při čekání na A+B blokovaný To je celý princip a je úplně jedno, jaká syntaktická wifikundace se použije k jeho zápisu.

3. díky async/await zápisu sice kód vypadá jako seriový (synchronní), ale to jenom vypadá a pořád je potřeba myslet na to, že smyslem té celé srandy je to, aby A a B mohly běžet potenciálně paralelně, protože to jediné je zdrojem toho potenciálního nárůstu výkonu, žádnej jinej magickej zrychlovací mechanismus tam není a být nemůže.

https://stackoverflow.com/questions/14455293/how-and-when-to-use-async-and-await

Await/async neni v C# v zadne pripade "jen" syntakticky cukr. Kdyby byl, tak jak to udelas v Jave? Nijak. Pod Await/Async je totiz v C# stavovy stroj, Java to neumi.

https://stackoverflow.com/questions/2846664/implementing-coroutines-in-java

Thread-based coroutines
This "solution" is pathological. The whole point of coroutines is to avoid the overhead of threading, locking, kernel scheduling, etc. Coroutines are supposed to be light and fast and to execute only in user space. Implementing them in terms of full-tilt threads with tight restrictions gets rid of all the advantages.

Za dalsi, neznam nic jako "jen syntakticky cukr" - vyprosuju si vypustit to "jen". Protoze to uz potom muzeme rict, ze monitor je jen syntakticky cukr pro jen programatora, protoze frajeri pouzivaji multimetr a osciloskop pro zjisteni stavu jednotlivych bitu.

319

Vývoj / Re:Ideálny programovací jazyk

« kdy: 13. 05. 2019, 09:29:42 »

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Není to nesmysl, běžně se dělá to, že pro zpracování síťové komunikace (přijetí požadavku) se používá jeden pool vláken, a pro vlastní zpracování požadavku (výpočet, dotaz do databáze, odeslání jiného požadavku) jiný pool vláken.

Dalsi vec i kdybyste mel nejakou singleuser komponentu, tak pokud pokud jsou hlavnim problemem blokujici operace, tak na to zase nechcete pouzivat vlakna, akorat si budete komplikovat zivot. Takze v Jave nahrada za await async neni. Resp. je, ve Springu "@Async" a nakonfigurovat to at se berou vlakna z Quasar, ale to je zase tak pres koleno...

To je těžké, když jediné, co znáte, je Spring. Ve standardní knihovně máte concurrent framework, máte RxJava nebo Reactor, Netty (a tím pádem Micronaut) používá zmíněný pool IO vláken a pool workerů, Jetty má Continuations a tím byly inspirovány Asynchronous servlets. Přičemž Continuations jsou právě koncept await/async. Springovské @Async je něco jiného, je to klasické asynchronní zpracování, není tam to await.

To by me zajimalo jak chcete s thready napsat aynchronni kod. Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async - a proto nemuzete vyrabet novy thread pokade kdyz se vola nejaka metoda. Jenom tak se vam bude spoustet kaskada operaci zatimco normalne pisete relativne standardni kod a nesnazite se komplikovat si design paralelnim zpracovanim.

Springovske Async neni neco jineho, kdyz se to spravne pouzije (kdyz se budou vyrabet Fibery z Quasaru), tak je to prave TO  Await Async, podobne jako je v C#. Akorat je to zatizene prasackou reflexi Springu, protoze Java await async neumi. A pri blokujicich operaci to bude stejne vyrabet thread, protoze v Jave ejste neni moc standardni mit neblokujici operace, neblokujici JDBC se zacalo vyrabet snad teprve pred 1 rokem. (!!!!!!)

320

Vývoj / Re:Ideálny programovací jazyk

« kdy: 13. 05. 2019, 08:48:21 »

To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.

Jistě, použít jediné vlákno je na dnešních mnohojádrových procesorech výborný nápad.

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Dalsi vec i kdybyste mel nejakou singleuser komponentu, tak pokud pokud jsou hlavnim problemem blokujici operace, tak na to zase nechcete pouzivat vlakna, akorat si budete komplikovat zivot. Takze v Jave nahrada za await async neni. Resp. je, ve Springu "@Async" a nakonfigurovat to at se berou vlakna z Quasar, ale to je zase tak pres koleno...

321

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 23:41:08 »

Nicmene co me tesi na GraalVM a kompilaci do nativniho kodu je to, ze to zmeni design Javovskych frameworku k lepsimu. Ale to potrva leta. Protoze ta kompilaci na native ma nejake problemy s reflexi, a ja si myslim, ze Spring pouziva reflexi az presprilis. Takze treba ten Micronaut je v tomhle vice odlehceny a mozna je to castecne zasluha toho GraalVM. Akorat nevim jak se tam treba resi anotace typu @Transactional, asi nijak. Snad se jednou dockam jazyka, kde se @Transactonal a podobne veci poresi uz v prubehu kompilace, protoze se mi nelibi, kdyz se porad vsechno musi volat pres proxy beany.

322

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 23:31:42 »

No tak jsem zvedavy jak to s tim GraalVM dopadne. Ja bych byl v soucasnosti mohem radeji, kdyby v Jave slo konecne nejak normalne pouzivat Await Async. Protoze to co umi CompletableFuture nahrada neni ani nahodou, uz treba proto, ze clovek u toho musi resit problemy se soubehem vicero vlaken. To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread. Sice existuje ten projekt Quasar, ale kdyz jsem se dival na ukozakovy kod, tak jsem moc nadseny nebyl. Chtel bych neco jednoducheho, kde muzu udelat:

CompletableFuture.supplyAsync(() -> doSomething());

A cus. Protoze na tom, jak se neco pouziva a jak slozite je to nakonfigurovat, setsakramentsky zalezi. To ma problem pochopit Jirsak. Protoze pokud se neco nepouziva dobre, tak to v praxi pro 9 z 10 javistu v enterprise znamena, ze se k tomu nikdy nedostane, protoze ta technologie pak do enterprise enviromentu nikdy neprobubla.

Java proste doted await async neumi a je to podle me velka ostuda. My co delame v enterprise tak nevim jestli nam k necemu je GraalVM, ale sakra bych vyuzili v nasich komponentach await async. Ale to proste je techbologie, ktera musi byt pripravena a musi se dat pouzit lusknutum prstu.

323

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 11:38:41 »

1. Oracle - kolik bude GraalVM stat, jake bude srani s licencemi?
2. Kompilace - jak dlouho se to kompiluje v porovnani s Go?
3. GraalVM a Spring - nedari se mi vyrobit image - uz se s tim zase seru, hodina a pul zabita.
4. Konfigurace - neni to lusknutim prstu, s Go dam 1x download a mam vse.
5. Kdy bude GraalVM pripraven pro produkcni nasazeni v enterprise?

Tvl ta Java to je takova hydra, a ted ji akorat zase narostla dalsi hlava 

GraalVM Community Edition je pod GPL. Argumenty vás ale zjevně nezajímají, vy máte jasno, a když jsem vaše argumenty vyvrátil, vymyslel jste si jiné – co na tom, že jsou úplně nesmyslné. Nebo vás vážně trápí, kolik sekund trvá vytvoření nativního obrazu někde na build serveru? GraalVM vyšla zrovna před pár dny v oficiální produkční verzi. Pro nasazení v enterprise bude vhodná tak během roku dvou. Na rozdíl od Go, které by pro nasazení v enterprise potřebovalo ještě aspoň tak pět (pokud by se na tom opravdu pořádně makalo) nebo deset let vývoje celého ekosystému. Jenže ve skutečnosti nebude Go pro nasazení do enterprise vhodné nejspíš nikdy, protože k tomu není určené. Java tak sice původně také nebyla zaměřená, ale nemyslím si, že by Go zopakovalo cestu Javy. Největší smůla Go je ta, že se teď na něj lepí takoví ti rozumbradové, kteří jenom opakují memy zaslechnuté někde na internetu, ale ve skutečnosti o tom nic neví.

Pane Jirsak, me uz asi nepresvedcite. Devil is in the details. Muzete se izolovane zamerit na co chcete, ale Java ukazala v podlednich 2 dekadach co je zac. Je to pomalá těžkotonážní hydra.

Já ještě teď rozdýchávám, jak mi referenční implementace pro JAX-RS, Jersey, přidala 1 vteřinu ke startu servletové Hello World aplikace.

Můžete mít GraalVM, můžete mít cokoliv, ale v Javě se, když se to vezme kolem a kolem, píšou vyrábí hrozné sračky, celá ta platfroma je složitá, stdlib je outdated a musí se furt všechno odněkud natahovat přes Maven, buildy dlouho trvají... a teď celá ta entropie platformy ještě narostla dalším featurou. Java jazyk sucks a lot, Kotlin se skoro nepoužívá, Scala už vůbec ne. Java platforma dojede na bídnou kvalitu a údržbu, je to ja jak stará zaprášená továrna z 90 let, teď do ni vestavěli sice nový blok, ale stejně už každý čeká na to, až se to celé zbourá.

No nic, zitra zase do prace, Java me dobre zivi, v enterprise nic lepsiho neni, ale uz se tesim na neco noveho.

Priznam se, ze vcelku zavidim C#-pistum .NET, ale plnohodnotna nahrada to jeste neni A navic mi C# prijdou jako hrozne nafintene nemehla.

324

Vývoj / Re:Ideálny programovací jazyk

« kdy: 12. 05. 2019, 11:02:44 »

Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

Ne, to „víte“ jenom vy. A řešíme to proto, abyste se dozvěděl, jak je to doopravdy. Když provedení aplikace v Go trvá průměrně 260 ms a doba běhu aplikace (s tím samým algoritmem) v Javě trvá průměrně 166 ms, nevypadá to, že by Java byla v porovnání s Go pomalejší. Spíš to vypadá opačně.

1. Oracle - kolik bude GraalVM stat, jake bude srani s licencemi?
2. Kompilace - jak dlouho se to kompiluje v porovnani s Go?
3. GraalVM a Spring - nedari se mi vyrobit image - uz se s tim zase seru, hodina a pul zabita.
4. Konfigurace - neni to lusknutim prstu, s Go dam 1x download a mam vse.
5. Kdy bude GraalVM pripraven pro produkcni nasazeni v enterprise?

Tvl ta Java to je takova hydra, a ted ji akorat zase narostla dalsi hlava 

325

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 23:10:56 »

Dam dalsi priklad - jak dlouho startuje Spring, treba pri JUnit springovych testech? To vsechno tak nejak s tou zravosti Javy souvisi.

Jak dlouho startují JUnit testy bez Springu?

Dost dlouho, na to ze je to jenom takovy psouk :-) A kdyz je tech psouku 1000 (Spring), tak uz to jde i dost videt. Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.

326

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 22:57:50 »

Ze se ale za tu RAM vzdycky tolik plati, kdyz si nekde porizujes virtualni server. Porovnej treba hostingy PHP vs Java No nevim nevim, do jake miry to porekadlo s vykonem a ram plati.

Ja jeste doted zadny svuj virtualni server nemam - protoze delam v Jave a stalo by me to tak moc penez, si neco jen tak ze srandy koupit...

Kdybych delal v PHP, tak mam hosting lusknutim prstu, protoze to stoji par slupek.

Prosimtě ty děláš jakoby to byly nějaký horentní sumy a jako kdyby java automaticky žrala nějaký giga. Virtuál s 2GB RAM stojí asi 1500kč/rok (to jsou 2 hodiny programátora). Já na tom provozuju web, mysql a java server, na který je připojeno několik set klientů, momentálně celý systém žere 375MB RAM.

No, ono 100x nic zabilo vola. Ja si myslim, ze na vykonu a zravosti zalezi. Je to o tech detailech. Dam dalsi priklad - jak dlouho startuje Spring, treba pri JUnit springovych testech? To vsechno tak nejak s tou zravosti Javy souvisi.

A kde ti to stoji 1500,- za rok? U active24 je VPS 2GB za 400,- mesic, mel jsem VPS u Forpsi, tam jsem mel jen 1GB a stalo to pulku. Tak to by me zajimalo, kde jsi narazil na takovy kauf - 2gb jen za 1500,-. Moc ti neverim.

327

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 15:12:37 »

Nemyslím to v situacích, kde by šel shared_ptr nahradit pomocí unique nebo move apod. Já se s tím běžně setkávám u grafových algoritmů, kde prostě není jeden vlastník objektu, ale je jich víc rovnocenných. V takovém případě buď použiju shared a daný objekt zmizí s posledním vlastníkem nebo bych si to musel evidovat někde bokem.

Tak je otázkou, jestli by se měly vrcholy vlastnit mezi sebou... U stromů to není problém, ale tam není problém použít unique_ptr. U jiných grafů si dovedu představit, že si je všechny držím v nějaké struktuře a mezi sebou mají jen pointery, nebo seznam id ostatních vrcholů. Se shared_ptr by mohl být problém např. u cyklů, když nad tím přemýšlím...

Představ si to třeba jako když polygony vlastní své nody (a ty jsou sdíleny mezi sousedními polygony). Pokud bych měl evidenci (a tím i životnost) nodů řešit bokem tak to je přesně ten argument, který jsem dal na začátku. S GC mi stačí řešit přímo daný problém a VM se postará o výkon i paměť. V C++ mám na výběr - buď si ten GC musím pro každý algoritmus odsimulovat bokem abych se dostal na úroveň JVM, nebo využiju těch super vlastností C++11, ale poběží to třeba 10x pomaleji. To je ta údajná možnost volby. A tohle se v menší či větší míře děje všude, kde není k dispozici GC. Za to dostanu deterministickou dealokaci, kterou po mě v praxi ještě nikdo nechtěl.

Korektně musim dodat, že JVM přitom sežere násobně víc paměti, ale to mi přijde jako dobrý kompromis. Čas programátora a čas CPU jsou dražší než RAM.

Ze se ale za tu RAM vzdycky tolik plati, kdyz si nekde porizujes virtualni server. Porovnej treba hostingy PHP vs Java No nevim nevim, do jake miry to porekadlo s vykonem a ram plati.

Ja jeste doted zadny svuj virtualni server nemam - protoze delam v Jave a stalo by me to tak moc penez, si neco jen tak ze srandy koupit...

Kdybych delal v PHP, tak mam hosting lusknutim prstu, protoze to stoji par slupek.

328

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 00:17:56 »

Naopak od C++11 se o to neni potreba starat a funguje to. Narozdil od GC jazyku jako java navic i deterministicky

Ještě k té deterministické dealokaci - dobře že to zmiňuješ, protože to názorně ukazuje posunuté myšlení C++ programátorů. Deterministická dealokace je sama o sobě zbytečná, řešený problém si ji sám o sobě nežádá. Ovšem v C++  je to způsob, jak uvolnit zdroje, takže se tak používá na vše. Jenže už se nemyslí na to, že to má neblahý vliv na výkon dealokace. Ta kdyby se nedělala pro každý objekt zvlášť, ale pro větší bloky, tak je to mnohem výhodnější a právě to je moment, ve kterém získává GC navrch - uklízí až když je to nutné, což je v běžných scénářích mnohem výhodnější než se starat o každý mazaný objekt.

Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.

Kde jsi v Jave proboha potreboval ladit GC?

329

Vývoj / Re:Ideálny programovací jazyk

« kdy: 09. 05. 2019, 23:16:34 »

Dekuji za priklad. Presto si myslim, ze mi zde neco v C paradigmatu unika. Ono neni vzdycky nutne ani ten polymorfismus pouzivat. Mam treba ted komponentu o 300k radku kodu v Jave, kde polymorfismus a generika se pouziva velice vzacne - v podstate hlavne v testech pri mockovani. A taky to jde a je to prehledne, ne-li prehlednejsi, protoze tam nejsou zaludnosti.

Myslim si, ze k programovani se da pristupovat i jinak, ale jsem zvykly na Javu a OOP paradigma a ono to na to C-paradigma napasovat nejde, ale dost mozna ani to jit nemusi.

Me se moc OOP programovani v C nelibi, ikdyz to jde. Ale profi zkusenost s C nemam. Ze zvyku hned vyhledavam jak udelat polymorfismus, ikdyz to treba vlastne ani neni nutne a da se to vymyslet jinak.

Ono kolikrat jazyk obsahuje nejruznejsi funkcionality, treba C#, a clovek pak muze nabyt klameho dojmu ze bez nich to nejde a dokonce je pouziva zbytecne a spatne, jako napr. psat vsechno async, vsude se snazit napasovat generikum, vsude se snazit strcit yield, vsude pouzivat "?" misto toho aby se clovek zamyslel proc musi porad checkovat neco na null, jestli neni  nekde chyba v designu.

C umi vsechno co je k napsani aplikace potreba, mozna jestli neni nekdy chyba mezi klavesnici a zidli :-) Ja vlastne ani nevim, jak se ma v C spravne aplikace psat, pcinaje VS delam jen v OOP jazycich.

330

Vývoj / Re:Ajax, Json, jQuery: použití value jako hodnota atributu

« kdy: 09. 05. 2019, 20:56:35 »

Hochu, dyt to mas spatne by design, ach jo, proc to tak delas. Pouzij React, nebo Angular (lehci je jednicka), v obojim bys to co chces udelal na brnk. Ty potrebujes neco, v cem muzes Templatovat, a od toho jsou ty 2 frameworky. Uz chapu ten tvuj podpis, tebe asi casto nekdo odrazuje, kdyz delas tak by design spatne veci. Kup si za 600 mesicni permanentku na pluralsight.com a vyber si skoleni na React nebo na Angular a nemusis se uz tady na Rootu ptat, protoze ti to bude jasne.