Příspěvky

2701

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 10:22:33 »

Tohle by bylo třeba dořešit, protože tu vznikl dojem, že FP je tak nějak celé immutable, což mi bylo hned od začátku jasné, že je to hovadina. Proto jsem se ptal, jak přechází systém (jako celek) mezi stavy.

"Tak nějak celé immutable" nevím, co znamená. V čistém FP jsou data immutable a ohledně fcí platí referenční transparentnost. Tyhle dvě věci asi celkem stačí na popis toho, o co jde, víc není potřeba říkat.

Jak (čistě funkcionální) celej přechází mezi stavy už tady bylo řečeno víckrát: "uvnitř jazyka" nic nikam nepřechází, protože celý systém je de facto čistě statický. To, co nějak mění stav, je runtime (na základě těch statických instrukcí).

2702

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 06:24:20 »

Rozhodně. Jenže na tom taky OOP založeno není, ačkoli si to většina lidí zblbnutých javským a cépluspluskovým pojetím myslí. Objektový program jsou škatulky, které si vzájemně vyměňují zprávy, a pochopení tohoto konceptu zpráv je naprosto klíčové k správnému pochopení celého objektového programování, protože právě v tom vězí celá ta síla a tvárnost.

No právě. Jenže většina těch nesmyslných nekonečných debat "o OOP" jsou právě debaty o tom co je "správné" dědit z čeho a jestli je "správné" mít k atributům accessory... Prostě nudné, zbytečné pseudoproblémy, které vnějšího pozorovatele vedou k úvaze, jestli (takhle chápané) OOP víc problémů nepřináší, než jich řeší...

Velmi správně píšeš, že vztah potomka k rodiči musí být zásadně specializační. A velmi správně píšeš, že to sotva může stačit k modelování problémů reálného světa. Ale je třeba mít na paměti, že odvozování podtříd je jen jedním z pomocných nástrojů objektového modelování.

Pak nám ovšem vyvstává otázka, jestli neexistují jiné, "neobjektové" způsoby modelování, které problém neřeší elegantněji - protože zprávy mají, (rozumné) zapouzdření mají, reuse kódu mají, ... a navíc ještě nejsou svázané tím, že vlastnosti je možné jenom vršit, ale počítají s tím, že je možné je dle potřeby volně kombinovat (typeclasses, go interfaces apod.) a navíc ještě třeba netrpí problémem mutability, kde musím každou krávovinu zamykat, až se z toho uzamykám k smrti

2703

Vývoj / Re:Dědičnost dnes

« kdy: 29. 01. 2017, 19:53:29 »

Ach jo. Tento akademický pseudoproblém je dobrý jen k tomu, aby poukázal na fakt, že v různých případech se mohou hodit různé přístupy. Ne, že jeden je dobře a druhý špatně, nebo snad že to je neřešitelný problém. Tím méně to představuje problém u matic. Takže znovu:
Se čtvercovou maticí mohu dělat všechno co s obecnou a pár operací navíc.

Já bych ani neřekl, že je to pseudoproblém. Není to náhodou spíš narážka na to, že můžu mít objekty/třídy A a B, které se mi zdají nějak související/podobné, ale z nějakého pohledu má A o pár vlastností navíc, z jiného má o pár vlastností navíc B a do toho všeho nejsem schopný jejich společnou podmnožinu nějak rozumně nazvat?

Jinými slovy: modelování světa do stromu, kde děti mají vždycky jenom jednoho rodiče a vždycky se jenom specializují, je prostě trochu problematický, reálnýmu světu to moc neodpovídá

2704

Vývoj / Re:Dědičnost dnes

« kdy: 29. 01. 2017, 19:42:49 »

Proc je enkapsulace tak dulezita? Z perspektivy nekoho, jako je Armstrong, zastance funkcionalniho programovani, to nedava smysl, protoze data jsou immutable (jinak receno, pracuje se s hodnotami, nikoli s promennymi).

Jenom tak pro zajímavost: ono je to ještě trochu zamotanější: Erlang má enkapsulaci taky - pokud mám uvnitř nějakého procesu nějaká data, ale proces nemá implementovanou žádnou zprávu, na kterou by je vydal, tak se k nim nejde žádným způsobem dostat. Je to v podstatě úplně to samý jako private u OOP, spíš ještě striktnější. Kromě toho existuje ještě jeden způsob skryvání dat, který je standardní: procesu se neposílá přímo zpráva, ale zavolá se funkce z příslušnýho modulu (takže přesně nevím, co se vlastně procesu posílá, je to ode mě odstíněný).

Předpokládal bych, že Armstrong by nekritizoval enkapsulaci per se, ale spíš její dogmatické využívání všude a na všechno a nikdy jinak.

Jinak ale máš naprosto pravdu v tom, že když mám data striktně imutabilní, nemusím s nima dělat takové caviky a můžu je klidně i zveřejnit, protože mi je stejně nikdo nemůže změnit.

2705

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 29. 01. 2017, 14:46:02 »

Zboj nebo Mirek Prýmek ti místo toho ochotně doporučí nějakou naprosto dokonalou technologii ... která má jedinou vadu ... skoro nikdo jí nepoužívá.

Jistě.

Doporučuju Go, je nádherné blbuvzdorné, takže i méně kvalitní tým může vyprodukovat něco funkčního.

Se stackem radit nebudu, na to situaci málo sleduju

2706

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 29. 01. 2017, 11:49:03 »

Nerikam, ze Angular je nejaka hitparada. Jen tvrdim, ze primarni problem neni v pouzite technologii/jazyce/frameworku.

Pokud budu mit tym Angular veteranu tak asi nejspis nebudu novy projekt politicky tlacit na React/Ember/Elm/whatever jen protoze "to je lepsi". Stejne tak kdyz budu mit tym zkusenych PHPkaru na frameworku XY tak nebudu z politickeho duvodu tlacit Haskell jen protoze je podle nekoho sexy a in.

Pokud máš něco napsané v něčem, do čeho se ti nechce sahat, tak to nemusí být v technologii, ale určitě je to ve vztahu tebe a té technologie

Opačný extrém toho, co píšeš, je, že můžeš skončit s programem napsaným v Cobolu pro S/360

2707

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 29. 01. 2017, 02:13:51 »

BTW jak se řeší NIO v FP?

Runtime GHC (Haskell) má green thready, takže to typicky spustíš s N OS threadama, kde N~počet corů a mezi tím ti tak nějak migrují green thready, takže sice píšeš "blocking", ale ve skutečnosti to je všechno non-blocking.

Erlang to má stejně.

Já si to bez typeclass nějak fakt neumim představit...v haskellu to používám docela hodně.

Hele, já to neumím přesně vyargumentovat, nejsem haskellista, takže do té praxe dost nevidím. Ale tak laicky bych řekl, že tam hrají roli dvě věci:

1. problémová doména - co si budeme povídat, weby nejsou žádná raketová věda, máš nějaké datové struktury a chceš je nějak zobrazit, máš nějaké události a chceš je poslat na backend a zpátky. To je celý. 3D raytracing tam psát nebudeš. Pokud nemáš možnost dělat nějaké wifikundační abstrakce, tak je prostě dělat nebudeš a nezblázníš se z toho. Sem tam to znamená, že musíš nějaký kód vzít a zkopírovat jinam a při refaktoringu máš víc práce než kdybys měl k dispozici lepší abstrakci. Ale tak co no, i tak je to lepší než se střelit do nohy nebo programovat v JS

2. Nevím, jestli Haskell má něco podobného, ale v Elmu sem tam nějakou abstrakci zastanou "neúplné recordy" (teď nevím, jak se to oficiálně jmenuje) - prostě řekneš, že typ je {a|s : String, t: Int} - tj. record, který má položky s a t plus možná něco navíc, co tě v té fci nezajímá (to je to "a").

Taky mám pocit, že ten typový systém je i v nějakých detailech trochu volnější než u Haskellu, ale konkrétní příklad teď fakt nedám. Myslím, že jde třeba udělat fce typu "a -> b" (a ani b nijak nespecifikuju) a překladač se s tím nějak popere. To myslím v Haskellu nejde, ne? Teď si fakt nejsem jistej a nechce se mi to už takhle v noci zkoušet a zkoumat. Spíš si to fakt zkus, ty to posoudíš líp než já, já to beru jenom fakt pragmaticky jako menší zlo než JS a nijak moc se nad tím nezamýšlím, dokud to dělá to, co od toho potřebuju

ani tím pořádně nejde napsat JSON serializaci

Elm má (de)serializaci JSONu moc pěknou: http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Decode a http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Encode

2708

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 28. 01. 2017, 23:12:05 »

Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval

Jo, tak jsem to kupodivu našel (level: Google master! ): https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a

2709

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 28. 01. 2017, 23:05:18 »

Pux by měl být elm-like binding na react.

Pokud to správně chápu na první pohled, tak se tím myslí asi spíš Elm 0.16. To bylo fakt FRP, hodně jako React. Od 0.17 Elm prošel dost zásadní změnou, která není úplně jasná, když v tom neděláš (úplně bez urážky, to určitě chápeš), ale v 17ce se fakt píše líp. Viz http://elm-lang.org/blog/farewell-to-frp Přijde mi, jakoby Elm pokukoval po užší spolupráci s Elixirem/Phoenixem, což by bylo megacool

Elm konkrétně jsem nezkoušel, ale co jsem četl, tak je to dobré intro do FP...a tím to tak končí. Nemá to TypeClassy, což mi osobně připadá jako docela problém.

Jako haskellistu by tě to mohlo štvát, to určitě. Ale je to myslím vědomej krok - nejspíš proto, aby se jazyk nekomplikoval, a mně osobně to zas tak moc neva - v té konkrétní doméně webovýho programování se bez nich dá obejít a tam, kde to fakt nejde (např. obecná fce toString) má runtime "výjimky" - on může dělat a dělá věci, který bys v jazyce neudělal

Kdyby typeclassy měl, mohl bys dělat větší abstrakce a měl bys míň boilerplate, ale otázka je, jestli to stojí za to Neumím to vysvětlit, musel bys to vyzkoušet sám (docela doporučuju). Pro haskellistu to asi bude trochu opruz z těch omezení, ale na druhou stranu, podle mě má Elm větší šanci získat větší publikum, právě proto, jak moc se Evan soustředí na jednoduchost, přístupnost a user friendliness.

Četl jsem o praktickém provozu Node.js dost škaredé věci...

Bylo by něco konkrétního? Kolega na to chce právě přepisovat něco rozsáhlejšího, tak by mě to zajímalo...

Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval

Nechci o Node nic tvrdit, zkušenosti nemám, ale k čemukoli z JS světa bych byl extra podezřívavej a před nasazením si to teda pořádně proklepl... Jako Python a Ruby jsou sice taky nic moc světy, ale aspoň mají nějakou historii a spousty instalací, že jo, tak se člověk asi tak nespálí...

2710

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 28. 01. 2017, 21:01:10 »

Snadná administrace je naopak jednou z výhod node.js. Je to jen jeden proces. Když chcete, aby se po pádu restartoval, spustíte ho pomocí forever. To je vše.

No já jsem spíš myslel takové věci jako ladění výkonu, nasazení v clusteru, debug apod. Tím, že něco nastavím a spustím celá ta legrace teprve začíná

2711

Vývoj / Re:Dědičnost dnes

« kdy: 28. 01. 2017, 20:57:53 »

Souhlasím, že je přínos OOP zveličován. Ale ta kritika platí jen pro jazyky typu Java.

Já myslím, že to kritici vidí trochu jinak: z OOP-jak-ho-dnes-každý-chápe je děláno zlaté tele, je přeceňován význam konkrétních konceptů, které zas tak zásadní nejsou (typicky ta dědičnost) na úkor jiných důležitých konceptů (třeba toho skládání nebo posílání zpráv), a takhle zmršené OOP se vydává za "to OOP" (čti zlaté tele).

Pokud by se místo C++ a Javy masově programovalo v ObjC, myslím, že by s tím nikdo neměl moc problém, protože problémy takového přístupu by byly srovnatelné s problémy jinde (there's no silver bullet). Ale ten standard povědomí o OOP, který nastavilo především C++, je prostě k zblití...

2712

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 28. 01. 2017, 18:28:59 »

Obecně se mi už teď líbí serverside javascript, tak abych nekombinoval jazyky a aby se v případě nutnosti mohli částečně zastoupit client a server side developeři.

Četl jsem o praktickém provozu Node.js dost škaredé věci... A představa, že bych adminoval JS na backendu je moje nejhorší noční můra. No... možná až po adminování web serveru na Windows

Se stackem radit nebudu, na to situaci málo sleduju, jenom moje 2 halíře: možná by mohlo pro inspiraci pomoct kouknout na https://stackshare.io/stacks (nebrat smrtelně vážně, jenom tak kouknout, co se v praxi vyskytuje ve světě...)

...

+100!

Jestli je něco určitě potřeba o webařině vědět, tak to, že "nejnovější trendy" budou zaručeně za dva roky úplně jiné, takže je úplně jedno, jaká technologie se dneska vybere. Za dva roky bude beztak out jak slipy do zvonů

2713

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 28. 01. 2017, 18:28:44 »

Příští projekt budu zkoušet Haskell na backendu a Purescript (asi zkusím s "pux" (i.e. React)) na frontendu. A za pár let zjistím, jestli to byl dobrý krok či nikoliv...

Skvělá odvaha a vývěr technologií, to mi imponuje

Zvažoval jsi Elm? Vyřadil jsi ho na základě něčeho konkrétního? (pokud už jsem se tě na to ptal, tak sorry, jsem hlava děravá )

2714

Vývoj / Re:Dědičnost dnes

« kdy: 28. 01. 2017, 18:00:16 »

Super, Mirku. Díky za info. Musím se tím probrat.

Určitě se na Elixir koukni, fakt je to zajímavý i jenom na hraní, jako osvěžení. Kdyžtak klidně napiš třeba tady přes fórum, nebo si na mě vygoogli mail, rád s Elixirem pomůžu komukoli, je to pro dobro lidstva

2715

Vývoj / Re:Dědičnost dnes

« kdy: 28. 01. 2017, 16:44:39 »

Při zkoušení příkladů z tutoriálů (dál jsem se nedostal) je to užitečná vlastnost.

Ano, je to příjemná změna syntaxe.

Jak funguje třeba funkce Map.put? Vytvoří kopii celé původní mapy nebo na ní odkáže?

Já vlastně ani nevím a je mi to jedno Dležitý je, že starou i novou mapu můžu pořád někam předávat  a nemusím se bát, že by mi je někdo změnil. Jestli to vnitřně nějaká data sdílí (předpokládám že jo), je mi jako programátorovi šuma fuk, mě zajímají ty vnější garance.