Příspěvky

1171

Vývoj / Re:Jak se vyhnout frustraci s Java eventy?

« kdy: 03. 02. 2016, 02:43:21 »

Ano, je rychlejší, ale pořád to je bída, aspoň na 32-bitových procesorech, s 64-bitovými zkušenosti nemám.

Měřil jsi to někdy? (Psal jsi vůbec někdy něco v Javě?)

Android má naprostou většinu UI taky v Javě. Dokonce většina aplikací pro Android plynule poběží s 16 až 24 MiB haldy. Hodně štěstí s takovými limity v KDE

Kdybych to neměřil, tak o tom nepíšu. A bavíme se o Javě od Oraclu, ta v Androidu není. Jinak dost blbý argument vzhledem k tomu, jak Android furt laguje, ale to je momentálně off topic. Až někdo ukáže, že se Java na armv7 rychlostí aspoň blíží C++/Go/Swiftu, rád se na kód podívám. Jinak zůstanu u svých zkušeností (jinak se tu o tom už diskutovalo včetně kódu a testech na RPi2).

1172

Vývoj / Re:Jak se vyhnout frustraci s Java eventy?

« kdy: 03. 02. 2016, 00:44:03 »

Nejsem Java guru, ale, pokud chceš odpověď jak na to, řeknu ti: nepoužívej Javu. Java má jednu ohromnou výhodu, běží všude a je plně zpětně kompatibilní. Dnešní programy v Javě poběží i za deset let na jakékoli super hyper funky procesorové architektuře která se zrovna rozhodne dobít svět. Na druhou stranu, chybné rozhodnutí před 15 lety ovlivňuje Javu doteď. Kuli bezpečnosti třeba nejde udělat override operátorů, nejsou pořádné jak ty říkáš eventy, a není toho asi mnohem víc, zas tak se ale o svět Javy nezajímám, takže nebudu víc kecat.

Běží všude ... stejně blbě. Sice může běžet na různých (budoucích) architekturách, ale třeba na ARM je výkon mizerný. Dobře škálovatelné je do budoucnosti Go. Čím dál víc firem láme nad Javou hůl.

To je přinejmenším hodně zavádějící tvrzení. Výkonnostní problémy se týkají pouze OpenJDK, které neumí využít ThumbEE (nemá JIT) ani hard-float. Oracle Java je výrazně rychlejší.

Ano, je rychlejší, ale pořád to je bída, aspoň na 32-bitových procesorech, s 64-bitovými zkušenosti nemám.

1173

Vývoj / Re:Jak se vyhnout frustraci s Java eventy?

« kdy: 02. 02. 2016, 22:19:00 »

Nejsem Java guru, ale, pokud chceš odpověď jak na to, řeknu ti: nepoužívej Javu. Java má jednu ohromnou výhodu, běží všude a je plně zpětně kompatibilní. Dnešní programy v Javě poběží i za deset let na jakékoli super hyper funky procesorové architektuře která se zrovna rozhodne dobít svět. Na druhou stranu, chybné rozhodnutí před 15 lety ovlivňuje Javu doteď. Kuli bezpečnosti třeba nejde udělat override operátorů, nejsou pořádné jak ty říkáš eventy, a není toho asi mnohem víc, zas tak se ale o svět Javy nezajímám, takže nebudu víc kecat.

Běží všude ... stejně blbě. Sice může běžet na různých (budoucích) architekturách, ale třeba na ARM je výkon mizerný. Dobře škálovatelné je do budoucnosti Go. Čím dál víc firem láme nad Javou hůl.

1174

/dev/null / Re:Java je nejhorší jazyk, jaký kdy byl stvořen

« kdy: 31. 01. 2016, 18:26:38 »

Jsou i horší jazyky. Java jako jazyk (syntax) je akorát trochu ukecaná a VM zase trochu nenažraná. Dohromady takový slabší průměr. Za rozšíření poděkujme "kompetentním" IT manažerům.

V době, kdy se ve větším měřítku začala prosazovat Java, jsem pracoval jako programátor v C++ (hlavně pod Windows) a viděl jsem, co jsou v tomto jazyce byli leckteří poměrně chytří lidé schopni udělat, jak vypadaly knihovny a multiplatformní podpora pro C++. K tomu příšerně dlouhá kompilace, kterou ve Visual C++ naštěstí vylepšovaly předkompilované hlavičkové soubory. Java v té době vypadala jako dost dobrý nápad, stála za ním poměrně silná firma a že se prosadila, jak se prosadila, podle mě znamená, že ostatní možnosti holt byly horší.

Že v Sunu padlo několik skutečně pitomých rozhodnutí (nepodpora generik a přetěžování operátorů, například), na věci nic nemění.

Jistě, v historickém kontextu je to pochopitelné. Já měl na mysli nedávnou dobu, cca. od 2010. A když už se o tom bavíme, tak v dnešní době by mohly C++ i Javu začít vytlačovat jazyky jako Go a Swift. Minimálně startupy už s tím začínají.

1175

/dev/null / Re:Java je nejhorší jazyk, jaký kdy byl stvořen

« kdy: 31. 01. 2016, 17:45:13 »

Asi jsem rozmazlený z Qt, ale to co zažívám v Javě, z toho mě chytá amok. V tomto programovcím jazyce, NEJDE napsat pěkný kód. Připadám si v tom jak v C++ bez Boost nebo Qt, jen s tím rozdílem, že v C++ jedou ty aplikace alespoň svižně.

1. V Javě chybí eventy. Je neuvěřítelné, že je tu už přes 15 let a pořád nemá přimou implementaci eventů.
2. To co se dělá v Javě, není ani náhodou OOP, to je bastl mezi OOP a procedurálním programováním.
3. Java je multiplatformní v tomto smylu: na všech platformách běží stejný shit.
4. Protože jazyk je shit, nativní knihovny Javy jsou shit taky, a knihovny komunitní tento shit opisují.

Jak tohle může být nejpoužívánější jazyk na světě, to mi není jasné. Je velice smutné, že takový bastl má tak širokou komunitu a tolik knihoven, kdežto pro kvalitní programovací jazyky jako je C++ je problém sehnat i dobrou knihovnu na vykreslování grafů. Je taky smutné, že tento bastl jménem Java přihrává do kapsy microsoftímu .NET. Dneska studenti, jenom co zažijí Javu a poté .NET, se na Javu z vysoka vykašlou, protože hned vidí, jaký shit to je, a microsoft tím získává na popularitě.

Jsou i horší jazyky. Java jako jazyk (syntax) je akorát trochu ukecaná a VM zase trochu nenažraná. Dohromady takový slabší průměr. Za rozšíření poděkujme "kompetentním" IT manažerům.

1176

Vývoj / Re:LR parsing

« kdy: 24. 01. 2016, 12:52:20 »

Implementuju LR parser a na následujícím fragmentu gramatiky mám shift-shift konflikt:

N -> I
N -> R
I -> n
R -> n . n

Je tato gramatika vůbec LR(k)? Pokud ano, jaké budou kernel sety?

Pro silnou LR(k) gramatiku musí platit
Pro kazˇdou dvojici pravidel v P
0 ve tvaru
(a) A → αX, B → βX,
(b) A → αX, B → ε, kde X ∈ BEFORE(B),
(c) A → ε, B → ε, kde X ∈ BEFORE(A), X ∈ BEFORE(B),
platı´ FOLLOWk(A) ∩ FOLLOWk(B) = ∅.
2 Pro kazˇdou dvojici pravidel v P
0 ve tvaru
(a) A → αX, B → βXγ,
(b) A → ε, B → βXγ, kde X ∈ BEFORE(A),
(c) A → ε, B → γ, kde X ∈ BEFORE(A), X ∈ BEFORE(B),
platı´ FOLLOWk(A) ∩ EFFk(γ · FOLLOWk(B)) = ∅.

A co takhle napsat něco k věci místo trapného copy-paste?

Jen jsem chtěl naznačit, že existují standardní postupy a algoritmy k testování gramatik, které nevhodná pravidla vyloučí nebo transformují. A testem, že daný soubor pravidel vyhovuje LR(k) se při implementaci začíná. Pokud to otestovat nelze, je lepší s takovou gramatikou či jazykem nepracovat, protože neskýtá záruky, že implementace bude spolehlivá. S pravidly typu S ← 'x' S 'x' | 'x' si poradí CYK algoritmus. Ale to bych bral jako poslední možnost, pokud by selhaly transformace na LR(k) původní gramatiky.

Chytrému napověz, hloupého kopni :-)))

CYK by použil jen vůl.

1177

Vývoj / Re:LR parsing

« kdy: 23. 01. 2016, 16:28:56 »

Implementuju LR parser a na následujícím fragmentu gramatiky mám shift-shift konflikt:

N -> I
N -> R
I -> n
R -> n . n

Je tato gramatika vůbec LR(k)? Pokud ano, jaké budou kernel sety?

Shift-shift konflikt nastat nemůže, takže chyba je v implementaci. V té gramatice je shift-reduce konflikt.

1178

Vývoj / Re:LR parsing

« kdy: 23. 01. 2016, 16:26:25 »

Implementuju LR parser a na následujícím fragmentu gramatiky mám shift-shift konflikt:

N -> I
N -> R
I -> n
R -> n . n

Je tato gramatika vůbec LR(k)? Pokud ano, jaké budou kernel sety?

Pro silnou LR(k) gramatiku musí platit
Pro kazˇdou dvojici pravidel v P
0 ve tvaru
(a) A → αX, B → βX,
(b) A → αX, B → ε, kde X ∈ BEFORE(B),
(c) A → ε, B → ε, kde X ∈ BEFORE(A), X ∈ BEFORE(B),
platı´ FOLLOWk(A) ∩ FOLLOWk(B) = ∅.
2 Pro kazˇdou dvojici pravidel v P
0 ve tvaru
(a) A → αX, B → βXγ,
(b) A → ε, B → βXγ, kde X ∈ BEFORE(A),
(c) A → ε, B → γ, kde X ∈ BEFORE(A), X ∈ BEFORE(B),
platı´ FOLLOWk(A) ∩ EFFk(γ · FOLLOWk(B)) = ∅.

A co takhle napsat něco k věci místo trapného copy-paste?

1179

Studium a uplatnění / Re:Jsem jen lepič kódu?

« kdy: 23. 01. 2016, 16:25:18 »

Zaujimave ponuky su alebo po znamostiach, lebo zohnat odbornika na trhu fakt nie je jednoduche a nema zmysel davat ponuky, na ktore sa prihlasi 90% neschopnych ludi. Ked uz ani znamosti  nepomahaju, tak sa vacsinou pouzije www.startupjobs.cz alebo zeebra.cz, vynimocne na root.cz v sekcii praca.

Odborníků je totiž málo a nedělají za almužnu.

1180

Studium a uplatnění / Re:Má IoT finančně budoucnost?

« kdy: 22. 01. 2016, 13:19:38 »

Finanční budoucnost mají věci okolo, HW, platformy atd. IoT je teď trochu buzzword, ale vývoj jednoznačně směřuje k "chytrým věcem". Určitě je dobré mít přehled a sledovat vývoj.

1181

Studium a uplatnění / Re:Trénink SQL

« kdy: 17. 01. 2016, 13:14:08 »

Datalog je mnohem snazší na pochopení, ale SQL je na některé úlohy lepší.

Zatim jsem se s zadnou takovou ulohou nesetkal a ani me teoreticky zadna takova nenapada Docela by me to zajimalo (castecne strkam nos do vyzkumu o databazich) - mate nejake priklady uloh, kde je SQL lepsi?

Jinak ohledne pochopeni SQL myslim, ze ciste relacni usporadani a algebra je vyrazne snazsi na pochopeni nez Datalog (jeste aby ne, vyjadrovaci schopnost Datalogu je silnejsi nez relacni algebry), ale SQL ma tolik vyjimek a divnych konstrukci apod., ze s vami mohu souhlasit, ze Datalog je z hlediska nauceni se (nikoliv pochopeni "co a proc se deje na pozadi") snazsi nez SQL. To jen tak pro uplnost, protoze co me zajima jsou ty ulohy, pro ktere je SQL "lepsi" (tedy neporovnavame samotne jazyky Datalog a SQL, nybrz jejich pouziti v praxi).

Datalog je syntakticky osekaný prastarý Prolog, ale s SLG rezolucí nebo něčím ekvivalentním pro inferenci. Hodí se tedy na různé ontologie a sémantické blbinky, ale ne na analýzu číselných dat hrubou silou. Numerické úlohy okolo "big data" by řešil obtížněji nebo přinejmenším pomaleji.

1182

Odkladiště / Re:Programátorův pohled na svět

« kdy: 17. 01. 2016, 13:04:32 »

Pro informatika by ještě mohl být zajímavý třeba Ivan Havel a knížky o umění od Jaroslava Nešetřila. Ten první mě ale moc za srdce nechytl a k tomu druhýmu jsem se ještě nedostal...

když už jsme u toho, tak ještě Vopěnka (to je filozofie smíchaná s logikou, geometrií, teorií množin a navíc vše je psané hezkou češtinou)

1183

Odkladiště / Re:Programátorův pohled na svět

« kdy: 17. 01. 2016, 12:58:53 »

No přiznám se, že na HasServer si nějak zvyknout nemůžu.

Zvykneš si

Asi nezvyknu. Dobře, Servable zní blbě, tak přinejhorším IsServer nebo CanServe, ale HasServer je nepochopitelné. Vždyť to žádný server nemá.

Servable zní blbě, protože -able implikuje trpný rod. Rozhraní většinou znamenají "capable of VP" a podle slovesného rodu oné VP se vybere pojmenování (mnohdy stačí nechat jen hlavní sloveso s příslušnou koncovkou).

1184

Odkladiště / Re:Programátorův pohled na svět

« kdy: 17. 01. 2016, 12:55:48 »

No přiznám se, že na HasServer si nějak zvyknout nemůžu.

Zvykneš si

Asi nezvyknu. Dobře, Servable zní blbě, tak přinejhorším IsServer nebo CanServe, ale HasServer je nepochopitelné. Vždyť to žádný server nemá.

Tak to dopadá, když jména vymýšlí někdo, kdo neumí anglicky.

1185

Odkladiště / Re:Programátorův pohled na svět

« kdy: 17. 01. 2016, 12:53:30 »

Aerable je stejným nesmyslem jako IArea.

jak je to teda správně?

HasArea

To je blbě, to není příčestí.

Na příčestí s8ru. Souhlasím s http://verraes.net/2013/09/sensible-interfaces/ . Raději to udělám pěkné a čitelné než se za každou cenu držet blbých nestandardizovaných "standardů". Radši budu mít HasTimestamp než Timestampable. Radši něco pojmenuju "x má Obsah" než "x je mající Obsah", sorry, I no speak americano.

No přiznám se, že na HasServer si nějak zvyknout nemůžu.

Zvykneš si

Timestampable ti asi poradil Kit. Ale HasTimestamp je taky blbost, i když menší.