Příspěvky

361

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 01. 05. 2017, 15:40:43 »

...
Na typovém systému se prozatím nic nezměnilo, generické jsou jen kolekce. Nicméně trefná je právě ta poznámka, že Go není (nemá být) univerzální jazyk, jeho doména je poměrně omezená (z toho možná vznikají různá nedorozumění a následně flamy).

Bohuzel casto vidim lidi, jak Go srovnavaji s Javou, JS nebo ho vyobrazuji jako zabijaka Pythonu. Ostatne neni nahrada Pythonu snad duvod, proc Go vznikl? Mozna proto ta vsudypritomna nedorouzmneni a click-bait prispevky na blozich provokujici flame...

Tvůrci tvrdí, že chtěli nahradit C++. Co si myslí jiní, je bezpředmětné.

Možná už je čas vyrůst z kritizování pouze syntaxe (ať už Go nebo třeba ObjC). Na Go je pěkná rychlost, obsáhlá a efektivní standardní knihovna a neuvěřitelně výkonný GC. Zrovna syntax je dle mého čistě *subjektivního* pohledu celkem hnusná, ale objektivní výhody to dostatečně vyvažují. Třeba boilerplatu se dá úspěšně vyhnout používáním rozhraní.

362

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 01. 05. 2017, 14:49:59 »

Kdyz jsem se na Go naposledy dival, tak jeho typovy system byl slabsi nez ten Javy - neumelo to ani generika, muselo se to nejak hackovat. I tvurce sam rika, ze hlavnim cilem je, aby se podprumerny programator (clovek bez zkusenosti - student po skole) byl to rychle schopen naucit. Podle me je to uplne zcestny cil jazyka. Kolikrat se ucim novy jazyk do zamestnani? Ja osobne jeden za par (mozna i vic) let, navic casto velmi podobny nejakemu jinemu, takze problem nebyva. IMO je lepsi se dobre naucit jeden jazyk + ekosystem, nez "umet" 5x mini-jazyk trpici vaznymi nedostatky typu Go.

Na uceni programovani mozna dobre, ale pracovat bych v tom nechtel. Boileplatu jako v Jave, mene moznosti (napr. podradny typovy system) nez v Jave, horsi ekosystem nez v Jave. Mozna na nejake specificke pripady je vhodny, ale jako univerzalni jazyk me prijde dost nepovedeny.

Na typovém systému se prozatím nic nezměnilo, generické jsou jen kolekce. Nicméně trefná je právě ta poznámka, že Go není (nemá být) univerzální jazyk, jeho doména je poměrně omezená (z toho možná vznikají různá nedorozumění a následně flamy).

363

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 01. 05. 2017, 02:45:57 »

nejlepší je učit se jej z prací Pika

https://en.wikipedia.org/wiki/Pika bych určitě nedoporučoval, to není ani hlodavec! Jedině z prací https://cs.wikipedia.org/wiki/Pytlono%C5%A1ovit%C3%AD !

A o genitivu jsi už slyšel? 

364

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 30. 04. 2017, 23:07:20 »

Že aktuálně neznám ekvivalent. C je moc low level, v C++ je překomplikovaný relikt, Python je pomalý a nic jiného, co by se kompilovalo přímo do strojového kódy, mělo to GC a bylo to populární, tu není, jen Go.

Okrem go je tu este D, Rust, Swift a Vala...

Rust vypadá poměrně zajímavě, ale nemám s ním bližší zkušenosti. D dtto. Swift je hodně slibný, ale je prozatím zabugovaný (překladač i standardní knihovna). Go je oproti Swiftu zralejší a podstatně jednodušší (KISS), i když čím více v něm člověk dělá, tím víc objevuje různé záludnosti. Rozhodně však není pomalé, oproti Javě je znatelně efektivnější (na optimalizovaný kód v C se pochopitelně nechytá nic). A taky o něm evidentně existuje hodně mýtů (nejlepší je učit se jej z prací Pika a spol.), jak dosvědčují příspěvky místního ksindlu.

365

Vývoj / Re:Java vs. Swift

« kdy: 29. 04. 2017, 22:05:50 »

Pozerate RSS? Treba pouzit nejake profiling tooliky, pozriet ci nie je prilis casu straveneho v gc, urobit heap dump a pozriet sa cez eclipse memory analyzer v com je problem. Mozno ten heap je prazdny a je zle nastavene GC. Mam taku skusenost, ze takto vyziera heap spracovanie XML (napr SOAP). GC v jave funguje trosku inak ako reference counting, takze s tym ze by si sa dostal na uroven swiftu zabudni. Navyse swift nepotrebuje metaspace a code cache a ine zrace pamate. Na druhu stranu sa tam daju lahko narobit mem leaky.
Inac ten IBM framework (kitura) bol trochu rozozrany, efektivnejsi by mal byt perfect.org.

Než řešit profiling, to už je lepší použít přímo jazyk, ve kterém to jede svižně.

366

Vývoj / Re:CPS a bind

« kdy: 29. 04. 2017, 21:11:49 »

Nechci prudit ale k cemu je tohle dobre kdyz pominu mentalni cviceni a vubec vsechny mozne 'akademicke' duvody?

P.S. "Akademické" postupy jsou obvykle rychlejší a bezpečnější právě proto, že jsou mnohem promyšlenější a abstraktnější, je to něco jako psát řekněme web server v asembleru vs. Javě. Jen ještě o úroveň výš.

367

Vývoj / Re:CPS a bind

« kdy: 29. 04. 2017, 20:13:26 »

Nechci prudit ale k cemu je tohle dobre kdyz pominu mentalni cviceni a vubec vsechny mozne 'akademicke' duvody?

Je to praktické a užitečné, ale je to vyšší level (liga). Senioři jsou mnohem produktivnější právě proto, že používají takové sofistikované postupy.

Takze pokud se na to budu divat jako na jazyk tak dva kteri pisou a ctou stejne jsou daleko efektivnejsi a mohou resit daleko slozitejsi ulohy.

Nebo nějakou běžnou úlohu mnohem rychleji.

368

Vývoj / Re:CPS a bind

« kdy: 29. 04. 2017, 19:58:13 »

Nechci prudit ale k cemu je tohle dobre kdyz pominu mentalni cviceni a vubec vsechny mozne 'akademicke' duvody?

Je to praktické a užitečné, ale je to vyšší level (liga). Senioři jsou mnohem produktivnější právě proto, že používají takové sofistikované postupy.

369

Vývoj / Re:Java a C# - porovnání práce se Zip souborem

« kdy: 29. 04. 2017, 18:23:08 »

Nezlobte se, ale nemám o diskuzi podobného typu moc zájem, obzvlášť o víkendu .

To je škoda. Nejsnazší způsob, jak může člověk zjistit, že dělá chybu, je ten, když ho na to někdo jiný upozorní. Když na to má přijít sám, trvá to mnohem déle. Nejsem si vědom toho, že bych v nějaké diskusi začal jednat nefér jinak, než jako reakci na nefér diskusi z druhé strany. Ale samozřejmě je možné, že se mýlím – pak bych to rád věděl. Nebo považujete za špatné i to oplácet druhému stejnou mincí?

ByCzech je místní šašek, doporučuji ignorovat.

370

Vývoj / Re:Java a C# - porovnání práce se Zip souborem

« kdy: 29. 04. 2017, 18:11:01 »

Souhlasím, nemyslel jsem to tak, že je lehké naprogramovat cokoli. Chtěl jsem tím říct, že naprogramovat jednoduché věci není složité. Nejtěžší na tom je poznat, kdy nejde o jednoduchou věc :-)

Souhlasím, ale jak nám říkal jeden vyučující - musíte chápat i složitější věci, aby se vám zdály ty snadné skutečně snadné. Jak je vidět z průběhu tohoto tématu, někteří se ještě nedostali ani do této fáze.

Čím méně člověk ví, tím víc si myslí, že ví všechno.

371

Vývoj / Re:Java vs. Swift

« kdy: 28. 04. 2017, 21:40:55 »

[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.

Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.

Seznam/pole čísel o dynamické velikosti.

Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.

Seznam/pole čísel o dynamické velikosti.

Pole  dynamickej velkosti sa da implementovat cez pole statickej velkosti. Dvojrozmerne pole sa da implementovat ako jednorozmerne. Zavisi od toho, aka funkcionalita je potrebna a usit to vhodne pre danu situaciu.

Tak to jde vždy, ale nejde udělat dynamické nativně, což je taky to jediné, co jsem tvrdil.

372

Vývoj / Re:Java vs. Swift

« kdy: 28. 04. 2017, 21:18:31 »

[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.

Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.

Seznam/pole čísel o dynamické velikosti.

Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.

Seznam/pole čísel o dynamické velikosti.

samozřejmě to jde, jen ne genericky.

Tak se ukaž. Aby to nedopadlo jako s preemptivním schedulingem v Go...

373

Vývoj / Re:Java vs. Swift

« kdy: 28. 04. 2017, 19:37:46 »

[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.

Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.

Seznam/pole čísel o dynamické velikosti.

Co na tom nejde inak napisat v jave? Dvojrozmerne pole obsahujuce double, alebo indexaciu prvku pomocou integeru?
To mate dost slabu predstavivost.

Seznam/pole čísel o dynamické velikosti.

374

Vývoj / Re:Java vs. Swift

« kdy: 28. 04. 2017, 18:36:00 »

[...] Pokud tam někdo naivně použije něco typu Map<Integer, List<List<Double>>> tak se GC (a tedy i CPU) fakt pěkně zapotí. A bohužel, takové věci opravdu efektivně a zároveň elegantně to prostě v Javě udělat nejde a nepůjde.

Tento popis přesně vystihuje obecný problém Javy. Akorát nevím, proč tam je "naivně", ono to totiž jinak nejde, pokud člověk nechce mít část kódu v C.

375

Vývoj / Re:Java vs. Swift

« kdy: 28. 04. 2017, 14:13:16 »

Nepotrebuji 63GB pro garbage collector

Aneb slovy klasika (možná Chris Lattner, už nevím): "Tracing GC is a poor man's automatic memory management." Ani vlastně nevím, jestli to je narážka na Android.