Příspěvky

3241

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 25. 03. 2016, 00:20:41 »

To asi všichni víme...

No když to víš, tak si ujasni, na co se vlastně ptáš. Na definice pojmů "beztypový" a "dynamicky typovaný"? Nebo na co vlastně?

3242

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 24. 03. 2016, 21:38:05 »

Jak sem řek nazačátku, dynamický typování může být úžasný, a taky úžasně strašný...a proto ho moc nemiluju.

Moje osobní pozorování, možná chybný: mám pocit, že pythoneři nemají moc tendence dělat velký kejkle. Oproti tomu v Ruby mi přijde že to bývá zvykem daleko častěji. Proto Ruby moc nemusím.

3243

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 24. 03. 2016, 21:35:32 »

Já bych chtěl vysvětlení té beztypovosti (různé zdroje se v této interpretaci liší); a kdyby to rozsekl Radek Miček bylo by to fajn .)

Co na tom chceš rozsekávat? Pythonovský objekt je v principu jenom slovník (podobně jako v Javascriptu nebo Lua) s tím, že některé klíče mají speciální význam. Konkrétně třeba nás tady může zajímat atribut __dict__. A to je vše. Na tom je to celé postavené. Můžu si vytvořit prázdný objekt (bez metod) a pak si do něj přidat metody jaké budu chtít. Jaký by to potom měl být typ? Žádný, v takovém prostředí pojem typ de facto neexistuje. Smysluplně se dá mluvit jenom o tom, jestli daný objekt splňuje nebo nesplňuje nějaký protokol/rozhraní (tj. disponuje v dané chvíli nějakou množinou metod). Ale pokud bych to chtěl opravdu korektně checkovat, musím to dělat za běhu.

Samozřejmě si můžu vymyslet, že nějaké další atributy budou mít nějaký další speciální význam. Například do nějakého atributu uložím referenci na něco, čemu začnu říkat "třída" a od té doby už z toho slovníku mám s trochou bižuterie "instanci"

Ironií osudu je takhle postavené OOP bližší té původní myšlence (SmallTalk) než C++ nebo java

Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.

Přesně tak. A ani nemusíme jít tak daleko, stačí nám obyčejný null Jestli se někdo ptá, jak to hergot pythonisti dělají, aby jim to nepadalo na to, že někam místo stringu dají int, tak odpověď je "dělají to v principu podobně jako javisti zabezpečují, aby jim to nepadalo na NullPointerException"


Jinak ale mimo flame k tématu: ví někdo, jak použitelné to typování v Pythonu 3 je? Např. kolik kódu std. knihovny je pokryto typy? Jak kvalitní jsou nástroje pro statickou analýzu?

V Erlangu taky typy de facto nejsou, ale dá se použít buť velice silné "manuální typování" (místo čísla dám dvojici {number_of_seconds_since_mireks_birth, 2453461}) nebo typové anotace + docela kvalitní statická analýza (dialyzer). Plus má teda Erlang oproti Pythonu výhodu v tom, že má excelentní podporu pro práci s chybovými stavy. To Python jenom těžko může dohnat, ale tu statickou analýzu by mohl mít snad poměrně dobrou...

3244

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

« kdy: 24. 03. 2016, 19:07:57 »

Otestovani se da udelat prakticky nazivo upravou bezici aplikace (to neni vlastnost FP, spis konkretniho jazyka)

Není to sice vlastnost FP, ale docela to s tím souvisí - u FP jazyků se to dá určitě udělat snadněji, čistěji a s lepšími garancemi. Excelentně udělaný erlangovský hot swap hodně využívá toho, že ví, který proces právě leze do kterého kódu, může ho pozastavit a kód mu vyměnit před nosem a taky že neexistují žádné reference na data. Dokonce v paměti může držet dvě verze jednoho modulu (aktuální a předchozí). To je v jiném prostředí dost těžko představitelné, že by se něco takového dalo udělat čistě.

Btw, na wiki se píše

Only a few programming languages support hot swapping natively, including Pike, Lisp, Erlang, Smalltalk, Visual Basic 6 (Not VB.net), Java and most recently Elm and Elixir.

Zajímalo by mě, jestli je to úplný výčet a jak dobře to který jazyk má zmáknuté.

3245

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

« kdy: 24. 03. 2016, 18:53:09 »

Myslím, že to není úplně jako guards - F# má také guards a také pomocí when. Rozdíl je v tom, že active patterns mohou mít i výstup. Například

Aha, chápu. No tak to už je úplná divočina Pěkně!

3246

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

« kdy: 24. 03. 2016, 13:42:58 »

Aha, takže něco jako guards v Erlangu, ale pojmenované a znovupoužitelné. To je dobrý, to se mi líbí.

Jak nad tím teď tak uvažuju, v Elixiru by se to dalo udělat pomocí makra. Ale bylo by to asi trochu syntakticky kostrbatější a byl by tam potenciál pro špatně čitelný chyby.

3247

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

« kdy: 24. 03. 2016, 13:35:25 »

Můžete si definovat vlastní vzory pro pattern matching.

Aha, takže něco jako guards v Erlangu, ale pojmenované a znovupoužitelné. To je dobrý, to se mi líbí.

Pro zajímavost: v tom patternu můžu použít libovolnou fci? V Erlangu je to omezené jenom na některé jednoduché fce, aby se v rámci matchování neděla nějaká zvěrstva

Ve Scale s knihovnou circe stačí deklarovat case classu (záznam) a pak napsat jen decode[Foo], kde Foo je název deklarované case classy. Pokud není k dispozici dekodér pro Foo, tak se pomocí implicitního makra vygeneruje automaticky.

Hmm, to je taky dobrý!

Polymorfní varianty dovolují napsat funkci, jenž zpracovává pouze zprávy Ok a | Zelena | Cervena (a když do ní zkusíte dát Modra nebo Err nebo něco jiného, tak to kompilátor označí za chybu).

Aha, takže můžu vybrat jenom některé varianty z různých typů? To je teda dost divočina A jaký typ se z toho pak inferuje, když je to částečně Result a částečně Color? Vytvoří automaticky při kompilaci nějaký interní typ "XXXX a = Ok a | Zelena | Cervena"?

3248

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

« kdy: 24. 03. 2016, 12:18:02 »

Dále tam chybí třeba rozšiřitelný pattern matching

Co si pod tím mám představit?

nebo automatické generování kódu (například parsování hodnot z JSONu nebo porovnávání hodnot si budete muset pro každý typ napsat ručně).

Parsování JSONu jsem už zkoušel (kvůli těm WS zprávám) a je to pracné. Už jsem o tom psal výš. Zas ale se to dá docela hezky parametrizovat a navíc to člověka donutí k pečlivosti (z BE prostě musím poslat správně strukturovaný JSON). Je to takové pro a proti, to je přesně ten důvod, proč nad tím dumám

Utěšuju se tím, že se mi tam ty zprávy budou asi docela opakovat, takže nějaká znovupoužitelnost by se tam mohla vyklubat...

Často mi také chybí polymorfní varianty z OCamlu - zejména, když systém pracuje s mnoha událostmi a různé jeho části zpracovávají různé podmnožiny událostí (ve Scale jsme k tomu používali Coproduct z knihovny shapeless, nicméně komfortem je to daleko za OCamlem).

BTW při výběru jazyka (a knihoven) doporučuji dát pozor na rychlost kompilace.

OCaml neznám skoro vůbec a Scalu málo, takže závažnost tohodle taky neumím posoudit. Pokud správně tuším problém, asi na to člověk musí jít v Elmu dost "ručně" pomocí klasických "union types" (tak tomu říkají v Elmu, teď si nevybavím, jestli to má nějaký spešl název v Haskellu - prostě klasické "Result a = Err | Ok a"). Akorát takhle ošperkovat pak člověk musí všechny ty podčásti, se kterými bude chtít zvlášť pracovat a to je pracné, tomu rozumím.

Taky jsem moc nepochopil, proč se v Elmu nemůže stejně jmenovat typový a hodnotový konstruktor. Autor asi chtěl předejít zmatení začátečníků, ale přijde mi to trochu nepraktické (zbytečně nové identifikátory).

3249

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

« kdy: 24. 03. 2016, 11:43:56 »

Nevím jak je na tom Elm teď, hodně dlouho jsem ho nezkoušel

Co jsem tak koukal kolem a kolem, vypadá to, že jde rychle dopředu, možná, že už leccos neplatí...

Kupříkladu mi tam scházeli eventy na klávesnici s vetší granularitou [...]Co je (bylo?) tragické byla absence oficiální podpory node.js. A GUI blbinek v STD lib které znemožněj něco podobného v budoucnosti.

To mě zrovna vůbec netrápí. Můj typickej use-case je tabulka nějakých položek, u každé je několik tlačítek (smaž, zobraz detaily,...) a přes WS přichází nové položky, které je do tabulky potřeba doplnit.

Takže potřebuju, aby FE uměl vzít data, vykreslit z nich tabulku, umět na stisknutí tlačítka poslat na BE přes WS událost ve stylu ["delete",ID], BE v DB smaže položku a zpátky pošle něco ve stylu ["remove",ID] a FE ten patřičný řádek z tabulky odstraní. Plus samozřejmě taková ta klasika jako uspořádání tabulky podle sloupce, na který se klikne apod. Technicky žádné extra špeky. Pokud by se to dalo napsat obecně, jako generická logika, které by se jenom předhodila definice struktury dat a seznam událostí, co to má umět, a všechny tabulky by byly obsluhovaný jedním kódem, bylo by to úplně ideální.

Taky mám pár trochu složitějších vizualizací v D3, ale ty můžu případně nechat v JS, to mi tolik žíly netrhá.

3250

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

« kdy: 24. 03. 2016, 11:05:56 »

Já jsem v Elmu nic nenaprogramoval, ale asi by mi chyběla řada vlastností z jiných funkcionálních jazyků (zvláště, pokud by se jednalo o větší program).

Co máš namysli? Hodně se probírá absence (haskellovských) tříd. Ještě něco? Jako jazyk jsem to nijak detailně nezkoumal, zatím mi šlo spíš o to si to vyzkoušet prakticky - získat z toho nějaký pocit, jak by se mi tímhle způsobem pracovalo...

Můžeš pls krátce napsat, jestli je tam něco, co by na (spíš jednodušší) praktické programování mohlo mít vliv?

3251

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

« kdy: 24. 03. 2016, 10:39:11 »

ELM a nebo v JS skus React, dost si toho vypujčil z FRP.

ELM je momentálně můj favorit. Myslel jsem, že bych šel spíš do Motorcycle, ale jak jsem to testoval, tak bych si pro něj asi stejně musel dopsat tu logiku, která v Elmu je jako základ (událost -> stav -> view) a jedna věc mě dost drasticky odrazuje: pokud dojde k výjimce uvnitř promise (který se tam používají všude), tak prohlížeč nevyplivne řádek původního zdrojáku, ale řádek ve vnitřnostech knihovny. To je dost drastická komplikace, pokud se to nedá nějak řešit (a nevím jak by to šlo). Je to pěkně vymyšlený framework, ale to JS je tam prostě koule na noze...

3252

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

« kdy: 24. 03. 2016, 10:11:59 »

O SPA premyslej jako o applikaci na smartphone, klientovi se jednou prenese (nainstaluje) a appka si sama vse rendruje a otravuje server jen kvuli datum a operace s daty, ne kvuli kazdemu prekresleni stranky, ktere musi byt specialne reseno pro kazdeho klienta.

Já ten koncept chápu, uznávám, že dává smysl, a kdybych stavěl komerční aplikaci na zelené louce s týmem lidí včetně kovaného frontenďáka, tak bych do toho asi šel. Ale to není moje situace.

Tak jiste, pokud mas uz BE hotovy vcetne sablon stranek, tak to za to nestoji.

Což je přesně moje situace Jeden z těch bodů motivace je, že mě baví Elixir a nebaví JS. A ty mi radíš vzít spoustu bezproblémově funkčního kódu v Elixiru a přepsat ho do JS frameworku, který neznám. To mi nepřijde, že by řešilo můj problém

3253

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

« kdy: 24. 03. 2016, 03:44:33 »

Me se ted hodne zalibilo prave to Elm (vlastne si to myslim daval ty ten odkaz na nejakou prezentaci na YT), ale nemel jsem moc casu se na to podivat nejak podrobneji, protoze ted fusuju do neceho jinyho. To Elm pry resi vsechno co React a jeste daleko lepe a elegantneji (hlavne protoze to neni JavaScript).

Elm se mi líbí hodně. Ale pořád si nejsem jistý praktičností. Přece jenom jeto haskellovitost - nemůžeš jenom tak někam šáhnou a udělat rychlou úpravu, protože se ti rozjedou typy... Mají skvělou JSON knihovnu http://package.elm-lang.org/packages/elm-lang/core/1.1.0/Json-Decode jenže zas - struktura JSONu musí přesně sedět. Když se tam objeví null někde, kde jsi ho nevyspecifikoval, celý JSON spadne pod stůl, protože se nenamatchuje...

Na kvalitní precizní práci a na větší projekty to musí být skvělý, to si umím přestavit. Jenom nevím, jestli já ty svoje věci nedělám trochu moc živelně na to, abych tohle mohl efektivně použít. A navíc Haskell sice trochu znám, ale nic reálnýho jsem v něm nedělal, takže je to pro mě trochu mindfuck Uvidím, jestli seberu odvahu se do toho pustit. Zatím se mi to líbí hodně.

3254

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

« kdy: 23. 03. 2016, 23:22:58 »

Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží

Ne, nezáleží na kontextu, nemaťme pojmy. Funkce f aplikovaná kdekoli na stejné argumenty dává stejný výsledek. To je princip FP a jeho hlavní deviza. U různých FP jazyků je to různě striktně dodržováno, ale v principu se to dodržuje všude, kde není pádný důvod to nedodržovat.

, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje

Neexistuje. V OOP nikde nemáte mapu, že metoda M1 objektu O1 používá metodu M4 objektu 04, pokud si ji nějakým spešl toolem nevygenerujete z AST.

Vezměte si libovolný středně velký OOP projekt určený pro jednovláknový běh, na pět náhodně vybraných míst dejte nějaký ten skok do jiného vlákna a celé to pusťte na sto vláknech. Jestli dokážete předem přesně identifikovat místa, na kterých může dojít k nějakému problému, tak jste buď geniální, nebo lžete. Spíš ale lžete Abyste to udělal, musíte ten kód kompletně projít, analyzovat si stromy volání a pravděpodobný výsledek bude, že všechno v důsledku volá všechno, takže problém může nastat kdekoli.

Čili u OOP i FP máme jeden společný pseudoproblém "když změním chování fce, tak se změní chování fce" a navíc má OOP jeden megaproblém, na který se v praxi naráží.

Erlangovský program můžu spustit na kolika chci vláknech a nestane se vůbec nic. Protože neexistuje způsob, jak by si procesy mohly do stavů šahat. Prostě není. Funkce přijímají data a vrací data, sdílená data neexistují (kromě databáze) a s procesy se komunikuje výhradně zprávami.

Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat.

To není potřeba si představovat, stačí se podívat na ejabberd. Je z něj po (více než) deseti letech jeden z nejúspěšnějších jabber serverů (ne-li úplně nejúspěšnější).

3255

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

« kdy: 23. 03. 2016, 23:03:20 »

Nemoznost odkazovat se na SPA - takovy problem davno neni. V Angularu to resi napr. ui-router a o vsechno to prepisovani URL a historii se to stara samo. K "apod." a "SPA se mi nelíbí" se bohuzel nemohu moc vyjadrit, chce to uvest konkretnejsi duvody.

Jak jsem říkal, weby mě neživí, takže to nemám nastudované kdovíjak do hloubky. Věřím, že všechny problémy nějak řešit jdou, ale nemám motivaci je řešit, když ty problémy nemám Pro mě osobně je to dost narovnávák na ohýbák... Začít dělat SPA by mi nepřineslo nic než spoustu práce a problémů.

Presne jak popisujete to generovani na serveru a pak znovu na FE, tak by to SPA elegantne preklenulo

To ano, ale taky by se na FE přenesla logika, kterou tam mít nechci, protože si ji pohodlně a příjemně řeším na BE a nemám motivaci to měnit. Ten způsob s websockety, který jsem popisoval výš, je prakticky stejný, jenom ty stránky zůstávají. Kdybych časem zjistil, že se jich chci zbavit a přejít na SPA, tak už to potom bude snazší.