Příspěvky

2311

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 01. 06. 2017, 12:04:26 »

Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.

Jiste, kazde prirovnani v necem kulha.

Ze je atom v principu imutabilni, deduplikovany string, jsem uz napsal. Pokud chcete, muzete si atomy v libovolnem jazyce takhle implementovat. Ale tak jako tak to bude jiny typ nez string a budete se k nemu muset chovat jinak (kdyz prijde treba po siti, musite atom deduplikovat, string nemusite a v mnoha pripadech ani nemuzete). Cili je potreba je odlisit a JSON k tomu nedava zadny nastroj, narozdil od poradnych serializacnich formatu. Cili skoncite u "formatu nad formatem", napriklad takto:

Kód: [Vybrat]

{
"atom": {"type": "atom", value: "my_atom"},
"string": "myString"
}

Pokud chcete dobrou serializaci, musite totez udelat i pro int a float. A porad jeste nemate vyhrano, porad tady mame problem map s klici, ktere JSON nepodporuje. Takze tu budete muset pro zmenu implementovat nejspis jako

Kód: [Vybrat]

{"type": "general_map", "key_type": "...", value: [[..,..],[..,..]]
}

...coz je proste na palici. Ergo JSON je proste se skripenim zubu zkousnutelny pro jednoduche veci, ale jako obecny serializacni format je to peklo. A nechapu, proc opet musite krecovite obhajovat neobhajitelne...

2312

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 01. 06. 2017, 10:39:53 »

Asi tak. Problémem je především skutečnost, že p. Prýmek považuje použití ORM (což je logické, jinak by aplikace musela zůstat relační) za chybu, ale použití RDB na objektovou doménu mu přijde zcela v pořádku.

Ne. Já považuju za chybu používat jakoukoli knihovnu/framework/abstrakci, která je natolik složitá a neprůhledná, že programátor nedokáže pohledem na kód říct, co vlastně v danou chvíli udělá, a zároveň má potenciálně velmi zásadní vliv na výkon aplikace.

Můžu přidat i osobní zkušenost: v jednom projektu byla komponenta provádějící jakýsi relativně jednoduchý (kontextem parametrizovaný) výpočet nad daty přicházejícímu z vnějšku. Kdyby to dělal člověk ručně, načte si z DB předem cca pět čísel jedním dotazem a pak spustí výpočet, už kompletně bez side effectů, čili snadno paralelizovatelný atd. Ovšem historie tomu chtěla, že danou komponentu psal djangista, čili konfigurace byla uložena pomocí django ORM, načítala se pomocí nějakých magických django objektů a když to bylo v provozu, lámali jsme si hlavu nad tím, proč tak děsně zatěžuje DB. No, nenačítalo se pět čísel, ale nějaké modely, ORM se z nějakého důvodu rozhodl, že k tomu potřebuje i nějaké související hodnoty, takže se ve finále pořádně košatým JOINem načítalo i spousta věcí, které pro výpočet vůbec nebyly potřeba, a to ještě vesele kdykoli jakkoli, třeba uprostřed výpočtu. Nekontrolovatelně. Nádhera...

(Nechci se hádat o to, jestli tahle konkrétní situace jde nebo nejde v Djangu nějak potunit, pointa je v tom, že místo aby se udělala jednoduchá DB s jasnou strukturou a jednoduché SQL dotazy, kterým by každý rozuměl a uměl je ladit, použil se "pohodlný nástroj", který ve finále aplikaci úplně zabil)

2313

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 01. 06. 2017, 09:29:56 »

V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?

To je jako byste se ptal na příklad použití enumu, pro který nelze použít string.

2314

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 19:38:32 »

Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?

Pokud by ty immutable stringy byly uložené v paměti jenom jednou a vždycky a všude by byly používány jenom reference (včetně toho, že když vytvořím nový string, podívám se, jestli už ho v paměti nemám), tak by to bylo prakticky totéž. Atom je v Erlangu reference do "atoms table" - velikost 1 slovo.

Nicméně v tom kontextu, o kterém se bavíme, jde o to, že to typově není ani string ani int - tj. potřebuju explicitně vědět, že tuhle hodnotu mám načíst jako atom. Rozumné serializační formáty umí uživatelské typy, takže to tam není problém snadno a čistě doplnit (pokud formát sám o sobě atomy neumí, což většinou neumí). JSON nic takového nemá. Musím si udělat vlastní proprietární formát nad formátem, úplně zbytečně.

2315

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 15:31:38 »

Když dekódujete číslo s desetiným místem, logicky chcete float. Když číslo bez desetiného místa, tak vám může být jedno co dostanete.

Ne a ne. Jestli se JSON "3.0" vyparsuje jako int nebo float je nedefinované. Naopak zakódovat int 3 jako 3.0 je plně legitimní. Z čeho a jak plyne, že "logicky chci float", to fakt nevím. Od serializačního formátu především chci, abych z něj dostal to, co jsem do něj dal. Pokud to neplatí ani pro základní věc jako číslo, je to prostě debilní serializační formát a není o čem diskutovat.

JSON se rozšířil, protože je jednoduchý. Když vám nevyhovuje, alternativy existují.

Netvrdil jsem, že neexistují.

Kdyz jsou u tebe typy smysl vesmiru

Ne nejsou. Pro mě je smyslem serializace, aby z ní lezlo to, co do ní dám, a nemusel jsem kolem toho dělat milion opiček.

Jaký je rozdíl mezi atomem a stringem?

Asi tak stejný jako mezi stringem a intem.

2316

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 13:41:18 »

Co si představuješ pod pojmem "horko těžko"? Serializace do JSONu je prkotina, tedy alespoň v PHP.

Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?

A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...

2317

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 12:01:59 »

asm.js už dnes funguje celkem dobře. Třeba emulaci starých her zvládá bez problémů.

Jiste no. Emulator Androidu na Xenu ve VirtualBoxu na bare metal hypervisoru by taky nejspis zvladl spustit Dooma

2318

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 11:51:42 »

Tady bych nebyl zas tak ostry. Ta podmnozina je vybrana tak, ze to dava (zda se) celkem rozumny bytecode. Ma sice hodne mizernou serializaci, ale to neni zas takova tragedie - prida to data na prenos, parsovani neni tak snadne, jak by mohlo byt, ale beh a optimalizace uz budou cajk.

No a kdyby se z toho to JS vyhodilo a zůstal jenom rozumný VM, byli bysme tam, kde bych svět rád viděl

2319

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 11:42:37 »

co se vám na tom nelíbí? nemám to nastudováno, prakticky jenom vím, že to existuje, ale zdá se to jako docela výrazné zlepšení proti js

Nelíbí se mi na tom to, že to je nad asm.js. Což je přesně ta "jakžtakž použitelná podmnožina shitu".

2320

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 11:36:54 »

Rovnou javu by si nechtel ?

Javu ne, ale něco na způsob JVM jo.

To ze v zakladu toho moc neumi je spise vyhodou

Ne, není. Nejlíp je to vidět na JSONu, ze kterého se bohužel stala lingua franca. Všichni trávíme tuny času tím, že svoje bohaté datové struktury horko těžko serializujeme do formátu, který neumí spolehlivě odlišit ani int a float. A s JS je to podobný. Transpilovat slušné jazyky do podmnožiny shitu je ztráta času.

Nechtěl byste se raději naučit alespoň základy JS? Možná byste zjistil, že to není tak špatné, aby to bylo nutné nahrazovat.

Tak rozhodně musím kvitovat, že jste se mnou nikdy nepracoval, ani mě neviděl, ale přesně víte, co neumím. Nechcete po 11té na Nově předpovídat lidem budoucnost?

2321

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 11:23:13 »

Stejnou vlastnost považujete v haskellu za výhodu.

Ani ne. Zrovna nedávno jsem tady psal, že na Haskellu moc nemám rád příliš moc vrstev abstrakce, které běžnému Frantovi programátorovi zatemňují schopnost říct, co doopravdy kód dělá. Třeba taková do notace mi přijde jako spíš ke škodě než k užitku.

Haskell podle mě pro běžného Frantu moc není. Daleko lepší je pro něj imho Elm. Stačilo by ho jenom maličko posunout směrem k silnějším abstrakcím, ale ne tolik jako Haskell.

2322

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 11:18:42 »

Pravda, ale oba víme, že to je utopie 

Těžko říct. Dneska, když už je MS víceméně ze hry, by se Mozilla Foundation s Googlem a Applem třeba domluvit mohli

2323

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 11:16:59 »

https://en.wikipedia.org/wiki/WebAssembly ?

No ale to je typicky webový narovnávák na ohýbák. To je asi jako mít na mašině hypervizor, v něm OS s VirtualBoxem, v něm Xen a nad ním emulátor Androidu

2324

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 11:09:39 »

Možná, ale JS na serveru je krávovina a v prohlížeči už to může být jedno, navíc Safari, Chrome etc. mají poměrně rychlý JS.

JS jako jazyk samozřejmě. Ale pokud bys měl v prohlížeči nějaký rozumný, dobře definovaný a standardizovaný jakožeCLR, i to rozdělení na backend a frontend by se dělalo příjemněji (polovina problémů webovýho programování se nějak týká komunikace BE-FE, serializace, převodu do toho dementně-omezenýho-JSONu atd.)

Jako ne, že by to v současnosti nešlo (viz Node, ClojureScript, ...), ale obávám se, že se strašný množství lidské energie pálí na řešení totálně zbytečných problémů, který by vůbec nemusely být, kdyby se webový svět dokázal rozumně domluvit a nepoužíval se všude jenom nejmenší-společná-podmnožina-shitu-která-jakžtakž-funguje

2325

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 31. 05. 2017, 10:47:11 »

Ona ta transpilace do JS nevadí, transpiler si většinou nestěžuje, že musí generovat prasokód (pokud to je program, ne nějaký Ind).

To ne, ale zbytečně to transpiler limituje a dává (nejspíš) o hodně nižší výkon. Zbytečně se řeší úplně zbytečná dilemmata typu "mám generovat čitelný JS (PureScript) nebo pohodlný/efektivní JS (Elm)" atd. atd.