Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - zboj

Stran: 1 ... 26 27 [28] 29 30 ... 101
406
OOP se vzdyt dela v Jave. C++ je jen nepovedeny hack. Vzdyt i samotny kernel je psan radeji v cistem C.

Presne tak, jestli C++ opravdu nutne nepotrebujes, utec dokud je cas. Timhle

For(int i = 0; i<10; i++)
 someVector.push_back( Trida() )

uz si potencialne zadelavas na segmentation fault, kdyz se treba budes pokouset pristupovat k polozkam toho vektoru mimo kontext kde vznikly. Techto oseru je C++ plne. Jestli potrebujes neco podobneho C++, ale done right, zkus radsi Rust, obzvlast kdyz mas svobodu teprve si vybirat.
Kecy, v tomto případě si kolekce dělá kopii nebo move (podle verze/třídy), ale chovat se to bude korektně. Akorát lepší než push je emplace.

407
Nejsem C++kář a potřebuju si v tom něco napsat OOP.

Naco jsou tam ty hlavičkové souboru *.h a k nim vždycky ještě *.cpp, když to budu psát OOP a už samotná třída definuje svoje rozhraní sama o sobě? Chápu to správně, že hlavičky slouží jen jako interface k binárce? Potom by mi ovšem stačil jen hlavičkový soubor k binárce, nemusím ho dělat ke každé třídě v rámci jedné binárky, ni?

Další věc statická alokace paměti. Veškeré třídy, jejichž instance se nebudou množit za běhu aplikace, můžu alokovat staticky bez operátoru new. Dá se to tak brát? Tzn. řekněme v praxi by mělo být tak cca 90% všech alokací v C++ statických.

Pokud nějakou instanci alokuji dynamicky, ale v rámci té třídy už alokuju staticky, pak předpokládám, že kompilátor není blbý a i ty statické alokace budou na heapu a ne ve stacku. Jako např. budu mít nějaký vector a do toho budu v cyklu přidávat staticky alokované instance, tak potom tyto instance budou ve výsledku alokovány na heapu, je to tak? Doufám že jo.

Díky.

New je lepší vůbec nepoužívat. Překladač není blbý, objekt se buď zkopíruje nebo se udělá move. Vnitřně to typicky skončí někde na haldě, ale to si řeší STL interně, konkrétně kolekce podporují && a objekty se tak paměťově spravují korektně.

408
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 26. 04. 2017, 12:22:19 »
Ale teď vážně, co je "instance monády"? Řekl bych, že "promise je monáda", je v tom něco hlubšího nebo jde jen o přešlap v terminologii?
Chtěl jsem zdůraznit (pro javascriptaře), že ten Promise v JS je jednou z instancí obecného konceptu "monáda". "Promise je monáda" je terminologicky správnější - stejně jako "sčítání nad celými čísly je grupa", akorát to může někoho zmýlit - může si myslet, že když umí sčítat, tak pochopil, co je to grupa, a když umí použít Promise, tak ví, co je to monáda :)
Nesouhlasím, ale nebudu rejpat (slovíčkařit)  ;)

409
Je tady někdo, kdo vyzkoušel práci v jednom a tom samém korporátu (např. IBM, Tieto, CGI) v ČR a potom ten samý korporát v nějaké ekonomicky vyspělé zemi typu USA nebo Německo? Jaká tam byla úroveň vývojářů, stejná nebo lepší?

Proč se ptám. V korporaci vidím, jaké programátoři, Češi, programujou neskutečné sračky. Senioři, kteří po X letech praxe neznají základní konstrukce a metodologie jazyka. Takové něskutečné sračky, že někdy mám co dělat, abych rozchodil, co jsem právě viděl.

Co mě zajímá je, jestli jsme postkomunistiká země nejen ekonomicky, ale rovněž i úrovní vývoje a úrovní programátorů. Jestli si Němci, když dostanou do týmu outsourcované Čechy, říkají "omg, Češi" tak jako my si říkáme "omg, Indi".
Až na špičky jako Google apod. je kvalita vývojářů v ČR znatelně vyšší, už nikdy víc nechci spolupracovat na projektu z Američanem (resp. někým z US CS vzděláním), pokud to nebude ze Stanfordu, MIT nebo podobně elitní instituce. Člověk je furt musí vodit za ručičku a pořád dokola vysvětlovat triviální věci (nejen MSc, ani PhD z USA není zárukou mozku). V Německu to je dle mé zkušenosti průměr, vzdělávání na tamních univerzitách je takové nemastné neslané, ale v práci (praxi) to pak překvapivě funguje. Obecně to je ale individuální, v ČR je často vidět mentalita "urob si sám", Čech prostě všechno nějak vykoumá a pak ukuchtí, kdežto Amík se pos..., když mu někdo v ukázkovém kódu změní jméno proměnné. Suma sumárum, v ČR si v tomto oboru není co stěžovat, lidi jsou vesměs dobří (od určité úrovně zaměstnavatele, nepočítám Pepu v garáži, co si přivydělává PHPčkem).

410
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 26. 04. 2017, 10:06:04 »
S bluebirdem bych to zapsal asi takto:

Kód: [Vybrat]
Promise.map(urls, getJSON).each(j => addToPage(j.html));

Je to stejně dlouhé jako vaše řešení v purescriptu.
...což bude nejspíš tím, že Promise je instance monády, akorát se to nesmí říkat, aby to javascriptaře neděsilo ;)
Nestraš  :P

Ale teď vážně, co je "instance monády"? Řekl bych, že "promise je monáda", je v tom něco hlubšího nebo jde jen o přešlap v terminologii?

411
Vývoj / Re:Proč je Java pořád tak populární?
« kdy: 24. 04. 2017, 16:00:13 »
Ahoj, roky slýchávám, jak je Java stará a už nemá co nabídnout. I proto ji nedělám, ale mrzí mě, že je pořád nejpopulárnější. Proč to tak je? Co má proti třeba Pythonu a novějším jazykům? Nebo je to jen setrvačnost, že lidé se nechtějí učit novější věci? Na škole jsme ji měli, ale moc mě nezaujala. Startupy ji často vůbec nemají, protože potřebují mít rychle výsledky. Tak jen jestli se tu najdou odborníci z praxe, kteří to chápou.
Ano, nejlepsi je dat na nazory lidi, idealne tech kteri kazdych 5 let evangelizuji IT komunitu nejakym novym jazykem :)
Java ma co nabidnout a pokud fakticky delate byznys v horizontu delsim nez dva roky, tak vas zajima jestli budete mit za tri pet let jeste lidske zdroje schopne na tom projektu pracovat.
Ze startupy nepouzivaji Javu neni ani tak jejimi nevyhodami ale spis lidmi. Pokud je plan spalit co v nejkratsim horizntu co nejvice investorskych penez a pak to strelit, tak vas udrzivatelnost projektu asi moc nezajima.
Na druhou stranu nepujdete a neprepisete celou infrastrukturu banky ci telca jen proto, ze posledni dva roky je ve freekulinske komunite zrovna popularni neco jineho. Jen za mou necelou dekadu to byl Python, Ruby a ted frci funkcionalni jazyky. Ono z toho asi casem vyplyne novy industry standard, ale to jeste minimalne dekadu potrva. 70., 80.  a 90. letech vladlo C a Jave zase patri prvni tri dekady 21.stoleti. Tecka. 
  Aneb slovy klasika - "Java is not lanaguage, Java is industry"
Ten klasik je Tatar, že píše lámanou angličtinou?

412
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 24. 04. 2017, 14:41:33 »
V JS máte jistotu, že posloupnost operací přistupující ke sdíleným prostředkům proběhne bez přerušení. V Go tu jistotu nemáte.
Ale to přece není otázka blocking/non-blocking, ale důsledek toho, že JS nemá žádnou podporu pro multithreading (i user-level). Ale dobrá reklama na JS: je to super-jazyk, nemusíte řešit zámky, protože to neumí multithreading a rozhodně mezi 2 příkazy vám "omylem" nic nevleze, protože kód "po" tom prvním příkazu musíte dát jako callback a tím pádem je vidět, že tam něco vleze. Ale blbě se s tím programovalo, takže jsme vynalezli "async await", který způsobí, že vám mezi ty 2 příkazy něco klidně může vlízt a tím pádem se to chová jako ty všechny ostatní jazyky, ale jinak je to fakt lepší....

Citace
Awaitovat můžete jen uvnitř async funkce. Composable to je. Můžete awaitovat vše co vrací promise, tedy i jiné async funkce. Tomu tazateli by stačilo místo forEach použít obyčejný for.

Pythonovské generátory jsou composable. Co jiného dělá yield from?
Vida, vývoj pythonu už delší dobu nesleduju, to tam tehdy nebylo :) Ovšem bez "yield from" to taky bylo composable, stačilo použít for...yield... to je v podstatě další syntaktický cukr, podobně jako async await. Prostě to není composable ale nějak to syntaxí přiohnem, aby se aspoň ty nejčastějc používané věci dali rozumně použít a člověk se přitom neškrábal nohou za uchem.

Ale jo, ty jazyky se postupně zlepšují. Ještě pár desítek let a budou všechny docela použitelné....

Citace
Dokonce můžete kombinovat generátory s async await a vytvářet async generátory. V Go podobné věci zdaleka tak elegantně zapsat nejdou.
Protože je (často) prostě zapsat nepotřebuju. Celý async-await je prostě automaticky zapnutý....
Ono celé slavné async/await je jen mnoho povyku pro nic, je to nic nepřinášející zhnusnění kódu. Čistě formálně je to jen zbytečně složitě vyjádřená monáda.

413
Vývoj / Re:Proč je Java pořád tak populární?
« kdy: 23. 04. 2017, 23:22:58 »
V tomto prispevku vysvetlim OP, preco Java este zije. Bude to dlhy prispevok, ale o to zaujimavejsi.

Na uvod male odlahcenie v podobe lacneho vtipu.
Co má [Java] proti třeba Pythonu a novějším jazykům?
Len pre tvoju informaciu, Java je novsia ako Python. Asi si nedaval pozor na hodine (haha-h). Ked najblizsie budete mat Python, mozes ohurit skolitela.

A teraz uvediem perlu (takzvany red pill), ktora nenecha Haskellistu, Lispistu a ineho funkcionalistu v klude:
Citace
Od jari 2014 v produkcnych systemoch (banky, vlady atd.) po celom svete a v masovej skale pribudli monady. Bez toho, aby o tom hlasali v televizii alebo pisali na root.cz bombasticke clanky, svet sa stal zo dna na den o trochu viac funkcionalnejsi...

A nestalo sa tak preto, ze od jari 2014 je Haskell najpopularnejsim jazykom. Stalo sa tak preto, ze vysla Java 8, do ktorej pribudli monadicke API, ktore su sucastou zakladneho JDK a teda su pritomne vsade tam, kde je Java 8 a vyssie. Tato myslienka nie je samozrejme moja, inak by som ju tak sebaisto neprezentoval. Povedal ju Ron Pressler na konferencii Curry on. Publikum sa sice zasmialo, ale bohuzial to nebol vtip. Okrem ineho do Javy pribudli aj lambdy...
Ako a kedy sme sa sem dostali? Su lambdy a monady listok pre Javu ako sa vratit medzi "nove" jazyky? Ale kdeze, v Jave su predsa aj lahke vlakna s kanalmi a kooperativnym multitaskingom podobne ako maju gorutiny v Go alebo procesy v Erlangu. Su tu aj namenej tri aktor frameworky (Akka, Orbit a Quasar) a samozrejme tzv. big data technologie, ci uz starucky YARN a MapReduce alebo mladsi Spark, near-realtime a adhoc analyticke nastroje ako Druid alebo Drill, zbierace a analyzatory prietokovych senzorickych dat Storm a NiFi, za tatru in-memory gridov (Genode, Hazelcast, Ignite) schopne spravovat PB v datalakeoch v RAMke, vyhladavace a indexery, ktore v inych jazykoch nemaju alternativne popularnu implementaciu. Alternativa k Spark ML? V neposlednom rade ma Java aj svoj polyglotny event driven "node.js"  s nazvom Vertx.io a dokonca aj port Rx kniznice, ak by mal niekto potrebu ukojit svoje FRP tuzby.

A teraz k povodnej otazke
Ahoj, roky slýchávám, jak je Java stará a už nemá co nabídnout. I proto ji nedělám, ale mrzí mě, že je pořád nejpopulárnější. Proč to tak je?

Bezpochyby ma Java stale momentum. No je jasne, ze o toto momentum pomaly prichadza v prospech jazykov ako Go. Avsak treba si uvedomit, ze Java robi aj velmi riskantne kroky vo velmi (relativne) kratkom case, ktore inym jazykom trvaju roky (tymto pozdravujem Perl 6). Osobne si myslim, ze je to prave kombinacia riskovania, momentu a tiez schopnost Javy rozsirit "nove" technologie a koncepty na masovej skale medzi beznych programatorov, ktore drzia Javu nad vodou. Preto su ludia, ktory sa na Jave vezu, jeden den na koni a druhy den rukojemnici.

V Jave sa deju velke-male revolucie, ktore ale bezneho cloveka z ulice obchadzaju alebo o nich nikdy nepocul, lebo to nepotreboval. Napr. v roku 2010 to bolo zavedenie novej bytecodovej instrukcie invokedynamic a v roku 2017 to bude v znameni IoT. V Java 9 sa bude balit do bundlov ako cez Webpack a pribudne AOT kompilcia do nativneho kodu - zatial iba na Linuxe. Pribude aj interaktivny shell. Stane sa Java potom dostatocne "mlada" ako Python?

Apropo, prave vdaka invokedynamic sa stal JVM plnohodnotny domov novych jazykov (Scala, Closure, Kotlin, Python, Ruby, Haskell). Vtip je v tom, ze ked Java 7 vysla, samotny Java jazyk tuto instrukciu nijako nepouzival a kompiler ju ani nedokazal emittovat pre ziaden zo syntaktickych konstruktov. Ludia ako Charles Oliver Nutter (tvorca JRuby) s ludmi zo Sun-u vtedy JVM riadne prefackali k zivotu aspon na dalsiu dekadu. Predsa ziaden zo staticky typovanych Javistov nepotreboval dynamicke prepajanie call site a target asistovane vlastnou bootstrap metodou pocas runtimu. Samotnemu jazyku Java trvalo dalsie 4 roky nez zacal invokedynamic vyuzivat.

Dnes tuto dynamickost v Jave pouzijes tak, ze v IntelliJ kliknes prehodit slucku for() na forEach(). Alebo si do klastra 200 Ignite nodov posles () -> { System.out.println("Hello World")} (Technicku diskusiu o tom, ze kompiler desugaruje lambdu na privatnu metodu na triede, kde je zadefinovana, vyemittuje invokedynamic call site v mieste volania a potom runtime musi za behu vytvorit ad hoc lambda factory triedu cez ASM kniznicu, nechame bokom).

Zaver z mojho prispevku je: Java sa vyvyja aj ked sa na nu nepozeras alebo inak dnesna Java nie je ta ista, v ktorej zacinal pisat tvoj otec <-- velmi good read

[flame bait] Apropo, asi sa zhodneme, ze dochadza k istemu "revivalu typovosti" aj v dynamickych jazykoch, inak by TypeScript nenaberal tolko na popularite a nebol by primarnym vyvojovym jazykom Angular 4. Jasne, ze je to iny typ typovosti ako ma Java, ale stale lepsie ako JavaScript... Ze by to soudruzili architekti Javy odhadli v '96 spravnejsie ako Guido 5 rokov pred nimi?
Jenže slovy klasika "[...] monads require writing code at a level of sophistication not available to the average programmer". A Java byla cíleně navržena pro průměrného programátora. Takže tudy cesta nevede.

414
Vývoj / Re:Sockety v Linuxu
« kdy: 23. 04. 2017, 23:17:33 »
Zdravim,
potřeboval bych pomoct s návrhem třídy, která mi vytvoří socket pro komunikaci klient - server, v mém případě klient.
Píšu to v C++ a g++ mi, při použití sys/un.h nebo netdb.h, netinet/in.h háže chyby.
Stačí mi jen mne nakopnout a nějak nasměrovat u socketů a OOP.
Na jakém OS?

415
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 22. 04. 2017, 23:03:23 »
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.

1. - o tom opravdu nic nevím.

2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.

goroutina != coroutina

http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.

preemptivní používám ve významu nekooperativní. V Go přepíná kontext runtime bez toho, abyste mu to explicitně museli říct. Kooperativní jsou právě coroutiny v js, pythonu nebo c#. Zboj používá to slovo špatně.
Viz ještě https://news.ycombinator.com/item?id=4704898, a pokud teď neuznáš svůj přešlap, tak jsi do skonání světa lopata.

416
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 22. 04. 2017, 22:57:55 »
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.

1. - o tom opravdu nic nevím.

2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.

goroutina != coroutina

http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.

preemptivní používám ve významu nekooperativní. V Go přepíná kontext runtime bez toho, abyste mu to explicitně museli říct. Kooperativní jsou právě coroutiny v js, pythonu nebo c#. Zboj používá to slovo špatně.
Tak si počti: http://blog.nindalf.com/how-goroutines-work/
Buď neznáš Go, nebo význam slova kooperativní. Sorry jako, ale preferuji diskusi s někým, kdo má aspoň základní znalosti. V Go jde scheduler vyšachovat, což znamená kooperativnost. (Doufám, že Babiš nemá na "sorry jako" copyright...).

417
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 22. 04. 2017, 22:33:13 »
Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
100% souhlas se soubory, bavím se výhradně o síťové komunikaci.

OK, tam je to fakt v C na jednu obrazovku, jak říkáš. A pokud už člověk používá nějaký C nebo C++ framework, ještě jsem nenarazil na to, že by neměl podporu pro poll, epoll, select nad deskriptorem. Ostatně třeba V4L2 se používá taky s (e)pollem a bylo naprosto bez problémů ho připojit jednou proxy třídou do Qt aplikace.

Já jenom nevím, proč se zbytečně izolovat od low level implementace už na úrovni jazyka, když to můžu udělat stejně dobře knihovnou a v případě nouze se můžu povrtat i níž.

Mimochodem, za coroutines v C bych vraždil. Kolikrát člověk nepotřebuje paralelismus, jen víc kontextů, zejména na bare-metal hw.
V C se mi osvědčily bloky ve spojení s kqueue nebo epoll. Jinak předpokládám, že v normálním případě člověk použije něco jako libevent nebo libev nebo libuv.

418
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 22. 04. 2017, 22:21:33 »
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.

Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.

Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.

Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
NIO nemá s vlákny nic společného a upřímně, OS vlákna by byla kontraproduktivní overkill.

Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
100% souhlas ohledně souborů, bavím se výhradně o síťové komunikaci.

419
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 22. 04. 2017, 22:19:50 »
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.

Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.

Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.

Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.

Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
Ne, nepoužívá.

Používá. I Go používá thread pool systémových vláken. Jediný rozdíl je v tom, že Go routiny jsou preemptivní. Což může někdo považovat za výhodu, ale u IO náročných aplikací je to k ničemu.
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.

420
Vývoj / Re:Node.js a multiplexed IO obecně
« kdy: 22. 04. 2017, 22:17:02 »
P.S. Jakmile začne někdo v souvislosti s node.js mluvit o thread poolu, demonstruje esenciální neznalost node.js a NIO obecně. Účelem NIO je obejít vlákna a klasické implementace běží kompletně v jednom vlákně (například node.js), byť rozumný kód si vytvoří tolik vláken, kolik má procesorů (resp. logických vláken v případě HT). Kqueue (a zkriplený epoll) má výhodu právě v tom, že nevyžaduje vlákna (pomíjím opičárny à la Go, korutiny jsou něco zcela jiného než vlákna).

Stran: 1 ... 26 27 [28] 29 30 ... 101