2416
Vývoj / Re:Funktory v C++
« kdy: 10. 05. 2017, 14:32:54 »U seznamu to je jasný, ale třeba u kontinuace?Ty bys toho taky chtěl, furt!
P.S. asi radši skončíme, ne, rozjeli jsme tady solidní off-topic
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.S. asi radši skončíme, ne, rozjeli jsme tady solidní off-topic
2417
Vývoj / Re:Funktory v C++
« kdy: 10. 05. 2017, 14:30:04 »Podobně, proč se používá "fmap" (to je možná ještě horší, protože "type constructor" je aspoň výstižné)?Jednoduše proto, že to má stejnou signaturu jako List.map, tak si to každej aspoň zapamatuje a je mu to intuitivně jasný
Myslím, že to trochu hrotíš
2419
Vývoj / Re:Funktory v C++
« kdy: 10. 05. 2017, 14:17:37 »Já ale nekritizuju, jak to je udělané v kódu, jen jsem kritizoval terminologii. Je jasné, že v implementaci vždy budou kompromisy a zjednodušení.Takže by ti v podstatě stačilo, kdyby se typovému konstruktoru říkalo nějak jako "the object-mapping functor part". Tak ti nevím
2420
Vývoj / Re:Funktory v C++
« kdy: 10. 05. 2017, 14:09:47 »Já tu motivaci chápu, ale je to matoucí pro lidi, co do toho vidí do hloubky. Možná to je kompromis mezi "uděláme to přesně do puntíku superformálně matematicky" a "uděláme to nějak tak jakž takž, aby to pobral i Pepa, co sedí za rohem v Lidlu za kasou". Jenže v prvním případě to je pak dost nepřesné a v tom druhém to stejně nakonec skončí přidáváním různých epicyklů, takže to stejně skončí jako složitost. Nedávno (tebou) zmíněný Prolog mimochodem dtto, vyjde se z jednoduché a jasné (a jasně a přesně už dříve nezávisle na konkrétním použití formulované) myšlenky a skončí to kočkopsem s hromadou vlastních výjimek (a vlastní terminologií).No jo, jenže se prostě bavíme o programovacích jazycích, kde primární motivace je vytvořit něco, v čem se dá dobře programovat a ne něco, co supervěrně modeluje matematickou teorii. Dovedeš si představit, jak by ten formálně přesný functor mohl vypadat?
Kód: [Vybrat]
mapObject : ??? -> ???
mapMorphism : ??? -> ???
Kód: [Vybrat]
???U toho Prologu je to imho podobně - zjistilo se, že pro praktické generické použití ten jednoduchý model nestačí a šup, je potřeba tam přidat různý specialitky
Osobně mi to taky sympatický není, kdyby Prolog zůstal jenom jako "dotazovací jazyk" (podobně jako Datalog) a nedělal se z něho generický programovací jazyk (který pak stejně máo kdo umí dobře použít), přišel by mi sympatičtější.2421
Vývoj / Re:Funktory v C++
« kdy: 10. 05. 2017, 13:56:10 »Tak třeba že jedné části funktoru se říká "typový konstruktor" a druhé "fmap", to nejen že nemá oporu jinde (je to vycucané z prstu), ale navíc to svádí k domněnce, že jde o dvě různé věci.No jo no, tak to je asi daný tím, že tu první část (mapování objektů) máš už v "hlavičce"
Kód: [Vybrat]
class Functor (f :: * -> *) where
Kdyby měl být Functor jakýkoli obecný functor, tak už by tomu asi nerozuměl vůbec nikdo, když už i takhle s tím lidi mají problémy
Člověk to musí brát tak, že Haskell nemá modelovat CT v její obecnosti, ale jenom ji využívá pro jeden konkrétní účel...2422
Vývoj / Re:Funktory v C++
« kdy: 10. 05. 2017, 13:35:25 »V Haskellu je ten problém, že zavádí svou terminologii. Pak je v tom ještě větší brajgl.Co máš namysli?
2423
Vývoj / Re:Funktory v C++
« kdy: 09. 05. 2017, 23:04:16 »Nekritizoval tě tu někdo v nějakém jiném vlákně za něco podobného?Ne, za přesně opačnou věc
a jako zajímavost, function object, který vrací T je funktor taky (a že se na to, svým způsobem, taky dá dívat jako na kontejner).Functor může být cokoli, když si kategorie nadefinuješ tak, aby byly splněna ta definice, co jsi psal. Ale v tom běžném chápání, jak je v Haskellu ("kategorie Hask"), jsou funkce morfismy. Viz https://en.wikibooks.org/wiki/Haskell/Category_theory#Functors_on_Hask
Citace
Translating categorical concepts into Haskell
Functors provide a good example of how category theory gets translated into Haskell. The key points to remember are that:
We work in the category Hask and its subcategories.
Objects are types.
Morphisms are functions.
Things that take a type and return another type are type constructors.
Things that take a function and return another function are higher-order functions.
Typeclasses, along with the polymorphism they provide, make a nice way of capturing the fact that in category theory things are often defined over a number of objects at once.
2424
Vývoj / Re:Funktory v C++
« kdy: 09. 05. 2017, 20:04:45 »ostatně je zde asi tak jediný, co v teorii kategorií neplave.Já bych spíš řekl, že jsem k ní jenom tak velmi zlehounka, z velké dálky a s velkou opatrností, abych se moc nezakuckal, přičichl
2425
Vývoj / Re:Funktory v C++
« kdy: 09. 05. 2017, 20:03:20 »Řekl bych, že ho zmatu mnohem míň, než, když napíšu:Jasně, však jsem to říkal:
když už se mermomoci chceš posunovat k větší míře abstrakce, než je podle mě u "polopatického" vysvětlení vhodné
Ono normálnímu C++ programátorovi vysvětlovat, že "funkce je funktor" by znamenalo nejdřív mu vysvětlit, co to je "funkce"...Ale on pojem funkce zná, akorát ho používá v jiném smyslu než ty, proto je to matoucí
Takže bych řekl, že normální programátor se v klidu může spokojit s tím, že funktor je kontejner.Určitě, ale měl by vědět, že to je jenom (velmi dobrý) způsob, jak si to představit, ne že to "je ono".
Čili při diskuzi o různých pojmejch je nutné dodat i kontext. A to je to, co se tu, myslím, plete dohromady... Možná by dávalo větší smysl se o tomhle bavit v kontextu Haskellu a jeho bláznivého type-systému.To není v kontextu Haskellu, ale v kontextu matematiky, konrétně teorie kategorií. Ta je jenom v Haskellu využita - a ty pojmy se tam používají (víceméně) v tom smyslu, jako v matematice. Že C++ použije ten samý pojem v úplně jiném smyslu, není problém matematiky
...ale žádnej céčkař z toho nemusí být dotčenej, v Prologu je podobnej problém
http://www.cse.unsw.edu.au/~billw/dictionaries/prolog/functor.html
2426
Vývoj / Re:Funktory v C++
« kdy: 09. 05. 2017, 17:07:00 »A jak to, že funkce není kontejner? Je to normální kontejner indexovatelný parametrem!No za prvé, pokud programátorovi v C++ řekneš, že funkce je kontejner, tak ho akorát tak zmateš.
Za druhé, pokud přijmeme takovou definici "kontejneru", že i funkce je kontejner, pak bude kontejner všechno a ten pojem ztratí smysl. Přitom v (ne-funkcionálním) programování ten pojem má smysl - je to "úložiště na hodnoty", nějaké místo v paměti, kam můžeš něco uložit. Zatímco funkce je nějaký kód, který můžeš spustit a on ti něco vygeneruje (případně na základě nějakých parametrů). V ne-funkcionálním programování tohle rozlišení má smysl a je zaužívané.
A za třetí, když už se mermomoci chceš posunovat k větší míře abstrakce, než je podle mě u "polopatického" vysvětlení vhodné, tak functor je především (jak psal zboj) homomorfismus mezi kategoriemi (což si můžeš přejmenovat na "kontejner", ale uděláš tím víc škody než užitku).
2427
Vývoj / Re:Funktory v C++
« kdy: 09. 05. 2017, 14:18:10 »Po lopatě, funktor je kontejner, který má operaci pro práci s prvkyTo je sice pěkně po lopatě, ale je to zavádějící. I funkce může být functor...
2428
Vývoj / Re:Funktory v C++
« kdy: 09. 05. 2017, 14:05:12 »Bohužel sis nepřečetl zadání: Může mi někdo polopatisticky vysvětlit...Pokud někdo chcete polopatistické vysvětlení toho "skutečného" funktoru, tak tohle je docela dobrý: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
2429
Vývoj / Re:React v .NET projekte
« kdy: 09. 05. 2017, 07:36:37 »Ano, to by som mohol pouzit v pripade, ze by som vyuzil Views z MVC struktury ... a teraz ma napadla este jedna vec, a to co ak by som teda to view v projekte naozaj ponechal, ale bolo by to len jedno view, popripade 2 (Index - registracia a prihlasenie, a Home - kde by bola kompletne UI aplikacie v reacte). Je to dobry alebo zly napad?.NET ASP neznám, takže s detaily neporadím, ale každopádně aspoň jednu stránku musí ten backend nějak naservírovat, že jo
Mít nějakých pár oddělených statických stránek, servírovaných backendem, a zbytek už jako SPA je taky varianta. V jedné aplikaci to tak mám, že přihlášení je jedna stránka - ověření se provede klasicky backendem, a po ověření se spustí aplikace, což je druhá stránka (z pohledu backendu), ve které už klikání řeší čistě frontend.
Akorát pokud bys to tak dělal, tak bych doporučoval si to prvně vyzkoušet na nějakém malém demu. Mixování routování na úrovni backendu a frontendu může způsobit nečekané komplikace. Já to mám tak, že z hlediska backendu jsou tři stránky:
- /login - vykreslí statický formulář pro přihlášení
- /logout - odhlásí uživatele
- / - samotná aplikace
Stránky v aplikaci jsou pak routované pomocí hashe, takže tam máš třeba urls:
- /#uzivatele
- /#faktury
- /#vtipy
- /#zmrzliny
Tj. část url před hashem routuje backend, část za hashem routuje frontend. Není to jediná možnost, jak to udělat, musíš si to vyzkoušet, jestli by to takhle vyhovovalo tvému use case (pokud vůbec opravdu chceš SPA).
2430
Vývoj / Re:React v .NET projekte
« kdy: 08. 05. 2017, 23:50:52 »Lenze to ukladanie tokenu na strane klienta, a nasledne posielanie na server s requestom kvoli autorizacii je skor nejaky zauzivany koncept z kategorie "the best practices", a nie sucas fw nie?Zauzivany koncept je spis sessionId ulozene v cookie. Viz https://msdn.microsoft.com/en-us/library/ms178194.aspx
