Příspěvky

3256

Vývoj / Re:Popis architektury GPU

« kdy: 23. 03. 2016, 19:53:07 »

Nechce se mi trávit příliš času vynalézáním kola...

Můžu se zeptat, na co to chceš? Chceš vynalézat vlastní GPU?!

3257

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 23. 03. 2016, 19:34:50 »

Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))

To je ale naprosto v pořádku. Funkci +/2 mám taky na spoustě míst v programu. Protože na všech těch místech dělá to, co tam dělat má. Hezké je na tom právě to, že na kontextu nezáleží a záležet nesmí.

3258

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 23. 03. 2016, 11:06:25 »

BTW, jeden z důvodů, proč bych chtěl vykreslovat čistě na frontendu, je ten, že ty události chodí fakt kdykoli (z nižší vrstvy aplikace, úplně mimo web) a mezi vykreslením na backendu a připojením na websocket je mezera, ve které se nějaká událost může ztratit - na webu se neobjeví. Ne že by to byl nějakej třeskutej problém prakticky, ale pocitově mě to silně dráždí, protože to je návrhový nedostatek

3259

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 23. 03. 2016, 11:01:43 »

Erlang přístup

Jj. Moje největší webová aplikace je frontend k monitoringu a správě sítí, takže to jsou pořád nějaký tabulky a grafy a všechno by to mělo být pokud možno dynamický. Takže události, události, události, většina asynchronní - ideální use case pro Erlang

Nejčastější věc, kterou řeším, je vygenerování tabulky z nějaké datové struktury + její updaty (z obou stran - události ze server, události od uživatele). Doteď jsem to dělal "po staru": počáteční tabulka se vygeneruje pomocí tamplatu na backendu a úpravy pak řeší pomocí jquery. Ale už mě to začíná silně prudit, protože se ten kód duplikuje a špatně udržuje. Vždycky to začne s tím, že "jquery stačí, událostí bude málo" a jak se to postupně komplikuje, je to čímdál větší opruz.

Takže moje současná představa je dělat to tak, že template vytvoří jenom omáčku: vlastní stránku + menu a připojení na websocket. Hned po připojení se přes WS pošle init stav, který se vykreslí už čistě na frontendu, a změny se posílají už jenom přes WS. Blbý na tom je, že tímhle způsobem tam vznikne lag mezi vykreslením menu a contentu, ale co jsem to zatím testoval, je to celkem rychlý, takže by to nemělo vadit. Pokud bych zjistil, že to problém je, nechal bych komplet stránku vykreslit na frontendu. Lag tam sice pořád bude, ale aspoň se vykreslí všechno naráz, což je asi pocitově příjemnější.

Tahle představa je teď ve fázi testování, možná se to ukáže jako blbost a udělám to jinak Ale teď momentálně se mi ta představa líbí, je to takový hezky jednotný a přímočarý

3260

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 23. 03. 2016, 10:03:26 »

Díky, Andy, za zajímavý zkušnosti!

S umístění view logiky na frontend jsem začal s Angularem - a v momentě, kdy to uděláš, tak na backendu v podstatě nepotřebuješ framework a vznikne ti SPA. [...] Mám trochu pocit, že SPA a "view logika na frontendu" je v podstatě totéž (protože když už tu view logiku děláš na frontendu, tak mi trochu nedává smysl dělat ovládání toho view na backendu).

Mně vyhovuje, že když mám oddělené stránky, můžu si na backendu řešit, která je jak autentizovaná apod. Tohle určitě měnit nechci. Navíc celej ten koncept SPA se mi nelíbí (nemožnost odkazovat přes URL zvnějšku apod.)

stačí mít serializační instance pro data (auto-generované), která si posíláš, "a je to". Když v API něco změníš, kompilátor ti pohlídá, že ti to na frontendu i backendu souhlasí

Tohle bych právě hodně chtěl, ale určitě kvůli tomu nebudu přecházet na Haskell na backendu. Spíš si asi zkusím promyslet, jestli by se to nedalo pořešit nějakýma makrama v Elixiru, který by mi třeba vygenerovaly boilerplate v JS pro přístup k datům. Momentálně se snažím všechna data přenášet přes websockety (REST jsem už víceméně pohřbil), takže to je jenom otázka definice handlerů pro události ze strany serveru a funkcí pro volání z druhé strany. Nechám si to projít hlavou, možná spojení tohodle + nějaký rozumný framework (Cycle.js nebo React) by bylo pro mě nejlepší.

- Zkompilovaný js je VELKÝ (1MB+)

To bych určitě nebyl ochotnej akceptovat. Jednak mě to dráždí principielně ale hlavně taky potřebuju servírovat mobilům a tam je to s těma datama pořád na štíru... Kolem 100kb je ok, níž se dneska člověk nedostane, kolem 200 už začínám brblat a 400 a víc by bylo vyloženě nepřijatelný

3261

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 23. 03. 2016, 09:12:41 »

Jestli to nebude tím, že v FP se vytváří výhradně nové projekty a vše je nové, svěží a čisté. Po pár letech provozu projektu to takové nebude.

RabbitMQ je devět let starý, CouchDB 11 let, Ejabberd 14 let. Nezaznamenal jsem, že by si někdo stěžoval na codebase.

Jinak FP taky obsahuje dědičnost, negativní důsledky dědičnosti v FP představuje použití funkce uvnitř funkce.

To je asi tak jako bys řekl, že v autě je taky dědičnost a tou dědičností je šaltrpáka. Proč mást pojmy? Dědičnost je dědičnost a v FP není.

Změní-li se chování té vnitřní funkce rozhodí to ne zcela odvoditelným způsobem chování jiných funkcí. Což taky zatemňuje. Závislosti mezi funkcemi jsou taky časem hodně složité a dostatečně temné.

Pokud mám funkci add(a,b) a "+" v ní přepíšu na "-", tak se ten program samozřejmě rozbije. Proti špatně napsanému kódu mě žádné paradigma neochrání. Výhoda FP je v tom, že ty funkce bývají tak jednoduché a dobře definované, že je jasné, jestli dělají co mají nebo nedělají. U Haskellu pak mám navíc silný typový systém, který spoustu chyb odhalí.

Zamotané závislosti je samozřejmě možné napsat v jakémkoliv jazyce. Rozdíl je v tom, že v OOP se tomu prakticky nedá vyhnout, zatímco v FP se člověk musí docela snažit, aby způsobil nějaký problém. Klíčem ke guláši nejsou funkce a jejich volání, ale STAV a jeho nepřehledné změny. A v FP je stav vždycky dobře izolovaný - z principu, vynuceného jazykem, který se nedá porušit i kdyby člověk chtěl.

3262

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 23. 03. 2016, 08:54:31 »

Tomuhle nerozumím. Vždyť JavaScript je také funkcionální. Chcete jazyk, který bude jen funkcionální a nebude podporovat jiná paradigmata?

V JS se dají používat některé FP patterny. Napsal jsem, že bych byl ochotný používat framework, založený jenom na nich (jako je např. ten cycle.js - viz http://cycle.js.org/ ) a pro moje účely by to možná bylo i racionálnější než čistě funkcionální jazyk.

3263

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 22. 03. 2016, 23:45:04 »

Mám dobrou zkušenost s F# a frameworkem WebSharper. HTML však renderuji pomocí Reactu.

Matně si vzpomínám, že jsem o WebSharperu něco někdy slyšel. Díky za tip, kouknu. Jak je to ale s praktickým používáním? Vidím tam VisualStudio, NuGet... to jsou vody, do kterých bych se nerad namočil jenom kvůli frontendu

A jaký je ten React? Pracuje se s tím dobře, je to dobře navržené? Četl jsem tak porůznu všelijaké poznámky, že si to na FRP jenom hraje...

Obdobně dobrou zkušenost mám se Scalou a ScalaJS. Navíc ScalaJS má binding pro React (osobně jsem ho však nezkoušel, když jsem to používal, tak ještě neexistoval).

Díky, to jsem taky nezkoumal.

V těchto jazycích ale nejde napsat serverovou část, nebo ano?

Nejde mi o sjednocení frontendu a backendu (možná jsem to napsal trochu nesrozumitelně). S Phoenixem jsem extrémně spokojenej a nedám ho ani za nic Hlavní motivace, proč uvažuju o změně, jsou asi tyhle:

• činí mi utrpení se neustále přepínat z funkcionálního (Elixir) módu myšlení do JS
• JS celkově nemám rád (ES6 je výrazně stravitelnější, ale pořád nepříjemný)
• nebaví mě řešit neustále boilerplate kolem komunikace tam a zpátky
• doteď jsem si docela vystačil s vlastním JS kódem+jquery, ale jakmile věci trochu narostou, je to utrpení

ad 1 - celkem bych byl ochotnej akceptovat i JS framework, který je napsaný funkcionálním stylem. Ten Cycle.js mi přijde v pohodě. Opravdu funkcionální jazyk je spíš takový trochu bonus navíc, úplně nutně na tom netrvám.

ad 4 - teď řeším view převážně templatama ve Phoenixu, s tím, že když potom chci něco udělat dynamičtější, tak k tomu napíšu nějaké ty transformace v jquery. Vede to ale k tomu, že ty věci pak píšu dvakrát, někdy i třikrát. Chtěl bych nějakou modularitu, nějaké komponenty, ale zase ne šílenou jadernou elektrárnu. Proto mi přijde, že funkcionální framework by byl prima - hodím mu data, vykreslí HTML. Snadným, předvídatelným, srozumitelným způsobem. Žádné tisíce monkeypatchovaných JS objektů dělajících kdovíco kdovíkde...

Navíc budou mít menší komunitu než F# a Scala.

To rozhodně - předpokládám, že o několik řádů

3264

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 22. 03. 2016, 23:17:56 »

Nějaký úplně skvělý framework, okolo kterého by byl hype jako v dobách RoR, tady asi (pro CljS) není. Spíš to jsou jednotlivé knihovny, které si člověk sám poskládá dohromady přesně tak, jak potřebuje. Takže možná to F#.

Tak to by nebylo nic pro mě, to mi za prošoupané klávesy se závorkami nestojí )

3265

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 22. 03. 2016, 23:02:21 »

Uvazoval jsi o ClojureScriptu?

Ne, protože LISP-like jazyky nějak nejsem schopnej překousnout Je v Clojure-světě nějaký vyloženě famózní framework, který by stál za to se kousnout a tu nechuť překonat?

Tak mě napadá, nerozhlížel jsem se ani v F# světě, jestli něco nemají. Nebo že by OCamláři?

3266

Vývoj / Funkcionální frontend - zkušenosti?

« kdy: 22. 03. 2016, 22:36:40 »

Zdar vespolek,

chtěl bych se zeptat na vaše názory a zkušenosti s funkcionálními jazyky/frameworky na webovém frontendu. Konkrétně mě zajímá, jak vidíte zralost, použitelnost a přínosnost jednotlivých řešení, která se poslední dobou vynořují. ...a taky, jakou cestou podle vás má smysl v současné době jít pro jaký usecase a míru odvahy Weby mě neživí, dělám je jenom pro interní potřebu, takže tu oblast úplně detailně nesleduju a budu rád za postřehy vás, kteří se v tom pohybujete víc a máte smysl pro FP.

Obecně mě zaujala myšlenka virtuálního DOMu, kompletní umístění view logiky na frontend (konec dvoukolejnosti) a její znovupoužitelnost a možnost nepřepínání se z funkcionálního světa (v mém případě http://www.phoenixframework.org/) do [doplňte sami] javascriptu.

Co jsem tak koukal, mám dojem, že jsou dvě základní možnosti:

• buď nějaký javascriptový framework, který FP principy aspoň trochu ctí a využívá (React, Flux? Hodně mě zaujal Cycle.js a ještě víc jeho úspornější varianta Motorcycle)
• nebo plnotučný jazyk překládaný do JS: Elm, Purescript

Víc mě láká druhá varianta, protože bych rád z JS světa utekl, ale nejsem si jistý, jak zralé ty věci jsou (pro ne úplně kritické nasazení, ale i tak chce člověk rozumnou zralost minimálně aby se to dobře používalo a nemusel řešit koniny) a taky si nejsem jistý, jestli se výhoda striktně čistého haskelloidního FP neprojeví spíš na větším projektu. Prostě, lidově řečeno, jestli si u menšího projektu člověk trochu nenaběhne na vidle - propojit pár tlačítek a WS událostí s nějakou víceméně jednoduchou akcí může být příjemnější pár řádky JS (?), ne-čistý jazyk umožňuje pohodlně si někam přidat ladící výpis, rychle drobně doladit logiku a neřešit změnu typu v půlce kódu...

Prostě, sečteno a podtrženo, docela mě ta představa láká, ale je to dost velká investice a nejsem si jistej, jestli to dává racionálně smysl. V současnosti jsem nejvíc nakloněnej Elmu, ale nechám si poradit

Dík za vaše zkušenosti a názory. Hlavně těm, kdo s něčím z popsanýho mají větší reálné zkušenosti.

EDIT: jo, ještě jsem zapomněl důležitou poznámku: SPAs mě nezajímají, dělám klasické "stránkové" aplikace, i když třeba s dynamickým obsahem ládovaným pomocí WS.

3267

Server / Re:Jak aktualizujete servery?

« kdy: 22. 03. 2016, 21:01:57 »

Šlo by trochu rozvést, co je na tomhle příkazu špatně?

Nic, jenom je to možná trochu nevhodný příklad. Ta nevhodnost se Saltem jako takovým nijak nesouvisí.

3268

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 22. 03. 2016, 13:11:46 »

jakýkoliv normální profesionál když vidí někde "nová technologie", tak zavře uši a nic už vědět nechce, s terminologií to nemá nic společného

No, frontenďáci jsou celí říční, aby měli každej týdej úplně novej make systém a co 14 dní jinej framework. Ale je samozřejmě otázka, jestli jsou frontenďáci "normální profesionálové"

3269

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 22. 03. 2016, 12:08:56 »

Varující je, že čisté FP se prakticky nepoužívá

To video, co jsem odkazoval výš, se právě docela detailně zabývá tím, proč to tak je (podle řečníka). A ve spoustě věcí má podle mě pravdu. Jakmile normální programátor uvidí někde napsáno "IO monády", tak zavře uši a nic už vědět nechce. Kdyby viděl "print x `andThen` print y", nemá problém. Čisté FP jazyky doteď žily/žijí převážně v akademickém prostředí a z toho vychází i všechna ta kultura a texty kolem toho. Nejlíp to vyjadřuje okřídlené:

Haskell gets some resistance due to the complexity of using monads to control side effects. Wadler tries to appease critics by explaining that "a monad is a monoid in the category of endofunctors, what's the problem?"

Navíc je myslím dobrý si uvědomit, že FP nutně neznamená pure&lazy. Erlang je sympatický jazyk, kde se na mikroúrovni používá docela pěkné FP, které ale není ani pure, ani lazy, ani silně typované (v obvyklém slova smyslu), takže většina té bižuterie z Haskellu tam není potřeba. Totéž F#, Scala (nakolik můžu posoudit, detailně je neznám). Je to kompromis, kterým se jazyk připraví o některé sympatické vlastnosti a garance, ale použitelnost (pro "obyčejné" programátory) je podstatně vyšší. A touhle cestou se nejspíš půjde, na čemž nevidím nic špatného. Jazyky, které dělají dobře promyšlené, teoreticky vyfutrované kompromisy, bývají fajn. To ale není případ OOP, které udělalo kompromis z technického (implementačního), ne designového důvodu.

3270

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 21. 03. 2016, 21:51:58 »

já ho za lopatu nemám (prakticky netuším kdo to je), ale IMHO mele blbosti, ty analogie jsou chybné

Je to autor Elmu. http://elm-lang.org/