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 ... 10 11 [12] 13 14 ... 101
166
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 :)
Pravda, ale oba víme, že to je utopie  :(

167
Vývoj / Re:Kotlin - nový officiální jazyk Androidu.
« kdy: 31. 05. 2017, 11:14:17 »
Zavisi jak na to Google pripravi prostredi a vyvojare. Treba u Applu byl prechod z Objective-C na Swift celkem v pohode a komunita to prijala vcelku pozitivne.
Se nedivím, cokoliv je lepší než Objective-C.
Jasně, a právě proto se jím tolik novějších jazyků inspirovalo.

168

Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.

Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
Jazyky se dají hodnotit podle (akademické) čistoty a pragmatičnosti. Takový Haskell je až matematicky "čistý", ale nepříliš pragmatický. Go je třeba naopak vysoce pragmatické, ale na teorii CS zvysoka - ehm - kašle. JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický. Fakt je to pomsta :) nebo rafinovaný nástroj k odhalování trotlů (IF likes Javascript THEN is thicko)  ;)
co je v tomto kontextu "pragmatičnost"?

"[A]n approach that evaluates theories or beliefs in terms of the success of their practical application."

Člověk by řekl, že to bude jedna škála se dvěma protipóly, ale "díky" JS to jsou dvě nezávislé veličiny.

169
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.
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.

170
JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický.
JS byl celkem pragmatický a relativně OK ve svém původním účelu: jednořádkový handler kliknutí někam. Že se z něj pak stal jazyk, ve kterém se budují dnešní webové jaderné elektrárny, je jiná věc, spíš historická nahodilost.

Mně spíš doteď není jasný, proč se výrobci prohlížečů nemůžou domluvit na nějakém bytecodu+standardizovaném VM typu CLR, aby se konečně toho JS dalo elegantně zbavit bez transpilace...
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).

171
Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.
Určitě. Ale ORM framework mu v tom mocně sekunduje a pěkně za ručičku vede do pekla ;) Čím jednodušší na použití, tím horší.
To asi jo, mám vlastní zkušenost s jedním  "juniorem", co za použití automatického ORM dával do DB objekty dědící z UIView  >:(

172

Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.

Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
Jazyky se dají hodnotit podle (akademické) čistoty a pragmatičnosti. Takový Haskell je až matematicky "čistý", ale nepříliš pragmatický. Go je třeba naopak vysoce pragmatické, ale na teorii CS zvysoka - ehm - kašle. JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický. Fakt je to pomsta :) nebo rafinovaný nástroj k odhalování trotlů (IF likes Javascript THEN is thicko)  ;)

173
Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.
To se dá ale ošetřit, taková db4o měla svého času konfigurovatelná omezení (není to ORM, ale čistě objektová databáze, což je zde ovšem irelevantní). Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.

174
Vývoj / Re:Webový framework pro HTTP v Go
« kdy: 31. 05. 2017, 08:46:37 »
Chtěl jsem použít MySQL, možná Postgre. Myslel jsem že optimálnost použití zajišťuje hlavně knihovna. V čem přesně by to nebylo optimální?
Jde-li o malou aplikaci, je vhodné mít vše v jednom procesu, a pak nemá cenu volat knihovny v C, s tím je spojený jistý overhead. DB knihoven přímo v Go je k dispozici několik (vesměs ale NoSQL). Pokud to ale má vše běžet na jednom serveru a požadavků bude málo, tak je to pochopitelně jedno a nějaký DB server přes síť bude naprosto v pohodě.

175
Vývoj / Re:Webový framework pro HTTP v Go
« kdy: 31. 05. 2017, 00:41:12 »
Chtěl bych v tom napsat rest api, která by sloužila jako feed pro webové rozhraní, případně android app. V net/http mi chybí spíše minoritní věci (např. parametry v url/middlewary/routování podle http metody/route groupy). Otázka je jestli mám dopsat co mi chybí a nebo použít hotové řešení ve formě frameworku.
Parametry v URL to má. U routování asi není problém napsat vlastní. Obecně je lepší frameworky nepoužívat, čím méně cizího kódu, tím lépe. Standardní knihovna je dobře otestovaná a vyladěná. Jen databáze musí být externí, nejlépe nějaká přímo v Go, jinak to nebude zcela optimální.

176
Vývoj / Re:Webový framework pro HTTP v Go
« kdy: 30. 05. 2017, 23:55:35 »
Zdravím,

Má někdo zkušenosti s http servery napsanými v GO? Používáte nějaký framework nebo všechno píšete sami nad net/http?
net/http většinou stačí, jde o to, co to má dělat.

177
Jinak i ve stavebnictví, v oboru s tisíciletou tradicí, se od nepaměti vede boj mezi stavebními konstruktéry, architekty na jedné straně a políry a zedníky na druhé straně. Jedni o druhých si myslí, že to jsou blbci a jejich výtvory stojí za zlámanou grešli :-)))
;D Tak to už bývá...

178
Jestli máš na mysli tu slavnou debatu o objektové hierarchii čísel (tam to klasicky dospělo, samotného by mě zajímalo, jak to dnes učí), tak tam bylo dost vidět, jak má Virius dost omezený pohled tím, jak je OOP implementováno v C++. On je na C++ hodně dobrej, ale chyběl mu rozhled.

Souhlasím. Mimochodem, když si někde obstaráte postupně starší skripta od Viriuse, tak zjistíte, že ještě tak v polovině 90. let v tom OOP velmi solidně plaval.

A ty debaty o hierarchii vejce-slepice nebo u čísel jsou docela úsměvné. Problém OOP je, že v životě se dají tytéž věci klasifikovat různě, záleží na úhlu pohledu a na tom, k čemu to má celé sloužit. Auta můžu hierarchizovat podle barvy, podle velikosti, podle účelu, podle počtu náprav, podle počtu míst, podle užitného nákladu, podle výrobce, podle druhu pohonu... Žádná z nich není ta jediná správná, každá se hodí k něčemu jinému. Ale při návrhu objektového modelu je třeba zvolit takovou, která usnadní implementaci. A která nemusí mít s reálným životem dokonce nic společného - ale za to může odrážet nějaké implementační souvislosti, jako třeba reprezentaci v paměti apod. A to je ten kámen úrazu, protože to je ve skutečnosti poměrně náročný úkol, který když uděláte špatně, tak už se to potáhne navždy celým projektem a nejde s tím nic udělat. U jiných paradigmat, např. strukturovaného, je samozřejmě také nezbytné navrhnout datový model a strukturu procedur, ale řekl bych, že tam to není tak fatální jako u OOP.
On to je trochu problém čistě technický, a sice (jednoduché) dědičnosti. Lepší je asi používat protokoly, pak jde totiž mít ty různé "hierarchizace" v kódu současně. Haskell, Swift nebo třeba Go jdou v tomto ohledu s dobou a vlastně se ukazuje, že dědičnost à la C++ až tak potřebná není. Celé by to mělo směřovat ke "complexion reduction". Kdy se to prosadí u většiny zkušených vývojářů, to už je věc jiná. Přinejmenším je ale přínosné kouknout se na tuto alternativu a zvážit, jak lze psát efektivněji. Pravděpodobně to bude pozvolný plynulý přechod.

179
Server / Re:SAMBA - Ban pri kopirovani vetsiho mnozstvi dat
« kdy: 30. 05. 2017, 11:52:06 »
ps: nastroj na vyhazovani hliny = javaman to nebere
To chce nahlásit, ať si to na rootu opraví :)

180
OOP není vůbec zvrácené. Pro ty, kteří ho zcela nepochopili, bývá často výhodnější FP, neboť v něm nemohou dělat chyby, kterých se dopouštěli v OOP.

Nevím, každopádně by to mnohé vysvětlovalo.
Problém je v tom, že OOP programátoři se ani mezi sebou neshodnou, co je chyba a co ne. A to nemluvím o nějakých hlupáčcích, ani špičky v oboru se neshodnou (viz třeba ten zmíněný Virius vs. Čada).
  Čada není špička, ale major.

Stran: 1 ... 10 11 [12] 13 14 ... 101