Příspěvky

Takže omluvu dlužíš spíš ty mě. Šup šup

Jak's na to přišel?! Ještě pořád to není jasný?

Vám dvěma asi ne. Ještě jednou a pečlivěji si přečtěte, co jsem psal, viz

V Haskellu se operátor bind (>>=) deklaruje následovně:

(>>=):: Monad m => m a → (a → m b) → m b

M. Prýmek má v tomto případě pravdu.

Přesně, jde o kovariantní funktory.

no a ne každá šablona (s jedním parametrem) je kovariantní funktor

Od kdy ne?

V odkazované prezentaci se ale o nutnosti opuštění OOP nikde nepíše. Pouze o reorganizaci dat před spuštěním konkrétního algoritmu. Správné seřazení dat samozřejmě může zvýšit výkon, o tom žádná.

Dost často stačí použít něco jiného než Javu, každý rozumný jazyk má hodnotové typy, čímž se obejde indirekce (největší problém Javy, jejž nebyli dodnes schopni vyřešit).

panic/recover (jen jinak pojmenované výjimky)

Aha, na to jsem ještě nenarazil Na první pohled to nevypadá úplně blbě, problém je, že se to nikde nepoužívá - všude jsou ty explicitní návratový kódy.

Používá se to pro uklízení gorutin, když 3rd party kód zpanikaří (třeba na blbém out of index, nepřípustném přetypování nebo něco takového), runtime zlikviduje tuto jednu padlou gorutinu a jde-li třeba o obsluhu http požadavku, musí knihovna po sobě uklidit.

Výjimky tam jsou.

Kde/jaky?

panic/recover (jen jinak pojmenované výjimky)

Tohle je trochu problém Go

Na Go jsem právě myslel, když jsem to psal. Ten jejich error handling mě fakt otravuje. Neexistence výjimek a generik mě osobně na Go vysírá nejvíc.

Výjimky tam jsou. Ta generika jsou jiná otázka, je fakt, že pro někoho z FP může být jejich absence bolestná, ale jakmile se člověk naučí používat správně ta jejich rozhraní, tak se bez nich dá obejít.

Způsobuje separaci místa vzniku chyby od místa jejího zpracování, a to i vertikálně, přes úrovně jednotlivých vrstev, což je IMO zlo. [...] A tak se na to kašle, nechá se to zpropagovat až kdo ví kam a tam se teprve chyba řeší. Jenže takové místo je z hlediska struktury, tj. viditelnosti a rozsahu platnosti jednotlivých entit, izolované od místa vzniku. Vlastně už se tam nedá dělat nic, než jen vzít na vědomí, že "někde dole" vznikla chyba

Kdybys měl opravdu na každém místě řešit úplně všechny chybové stavy, ke kterým může dojít (včetně lowlevel věcí jako např. "out of memory" apod.), tak v té změti checkování bude ten samotný algoritmus jako jehla v kupce sena.

Tohle je trochu problém Go (až na OoM, to panikaří vždy v knihovně), protože výjimky (ve smyslu longjmp) sice má, ale kód z toho elegantní neleze. Proto třeba ve Swiftu přepsali knihovny tak, aby se daly používat stylem "do {try ...} catch {...}"s tím, že lze použít rethrow. Na ošetření chyb jsou ale stejně pořád nejlepší monády 

Hask se může brát jako prostě nějaká obecná kartézsky uzavřená kategorie s morfismy jako vyjádřitelnými funkcemi (bez ohledu na vyčíslitelnost, on i takový halting problém je při vhodné restrikci rozhodnutelný, zrovna před rokem jsem o tom viděl hezkou přednášku na Oxfordu, ale to odbočuju). Rozklad morfismu je předpoklad pro to tvrzení, čili například f.g.h (wlog stačí uvažovat binární rozklad). Když si ho zadáš jako f.id, tak klidně můžeš, jen to pak je poměrně triviální. To tvrzení říká, že můžu jít jinou cestou (přes jiné objekty dané kategorie), přičemž ty morfismy na alternativní cestě jsou restrikcemi těch původních a když vyberu epimorfismy, tak budou vyčíslitelné, je-li jejich kompozice taktéž.

Ok, díky, to už mi trochu začíná dávat smysl.

Ono to je vlastně intuitivně jednoduché a v KT to jen zní nabubřele.

Ta otázka je nepřesná, zřejmě jde o to, že když mám vyčíslitelný morfismus a nějaký jeho rozklad, tak z něj vždy dostanu takový rozklad, kde každá komponenta je restrikcí nějaké dané a zároveň vyčíslitelná, protože můžu vždy jít přes epimorfismy. Existence je zaručená, protože všechny morfismy jsou totální funkce. Důkaz je přes komutativní diagramy celkem názorný (byť ne zcela triviální).

To's mi to teda pořád moc neosvětlil "Vyčíslitelný morfismus" je co? Pokud se bavíme o Hasku, jsou morfismy funkce a vyčíslitelné jsou z definice (Hask iirc neobsahuje bottom).

"Rozklad morfismu" znamená co? Rozklad nějaké množiny, nebo to, že f můžu vyjádřit jako složení nějakého g a h? (proto jsem se ptal, jestli jedno z toho může být id)

A je tenhle fakt nějak využitelný, má nějaké praktické důsledky?

Hask se může brát jako prostě nějaká obecná kartézsky uzavřená kategorie s morfismy jako vyjádřitelnými funkcemi (bez ohledu na vyčíslitelnost, on i takový halting problém je při vhodné restrikci rozhodnutelný, zrovna před rokem jsem o tom viděl hezkou přednášku na Oxfordu, ale to odbočuju). Rozklad morfismu je předpoklad pro to tvrzení, čili například f.g.h (wlog stačí uvažovat binární rozklad). Když si ho zadáš jako f.id, tak klidně můžeš, jen to pak je poměrně triviální. To tvrzení říká, že můžu jít jinou cestou (přes jiné objekty dané kategorie), přičemž ty morfismy na alternativní cestě jsou restrikcemi těch původních a když vyberu epimorfismy, tak budou vyčíslitelné, je-li jejich kompozice taktéž. Využitelné je to spíš naopak, když se mi podaří faktorizovat nějakou složitější funkci a dokázat, že příslušné epimorfismy nejsou vyčíslitelné (aspoň jeden), tak kompozice je v pytli a nic s tím neudělám. Většinou se hledá nějaký bottleneck v algoritmu, kde se provede faktorizace zaručující restrikci s vyčíslitelností (třeba v parsingu přirozených jazyků se omezujucící podmínky převádějí na algebru rysů (feature algebra), nad kterou se pak řeší word problem pro ukázání bezespornosti; dá-li si daný model vyjádřit jako třeba polycyklická grupa, tak dostanu faktorizaci, jejíž druhá komponenta je vyčíslitelná, byť obecně je word problem nerozhodnutelný).

Dá se dokázat, že každý vyčíslitelný morfismus se dá rozložit na vyčíslitelné komponenty?

Mohl bys mi jako čtyřletýmu dítěti vysvětlit, co tím myslíš? Není mi moc jasný pojem "vyčíslitelný morfismus", ani "rozložit", ani "komponent".

Mám-li f: X -> Y, je f . id "rozložení na komponenty" nebo ne?

Nedávno tu zaznělo, že ne

Kde přesně?

Ta otázka je nepřesná, zřejmě jde o to, že když mám vyčíslitelný morfismus a nějaký jeho rozklad, tak z něj vždy dostanu takový rozklad, kde každá komponenta je restrikcí nějaké dané a zároveň vyčíslitelná, protože můžu vždy jít přes epimorfismy. Existence je zaručená, protože všechny morfismy jsou totální funkce. Důkaz je přes komutativní diagramy celkem názorný (byť ne zcela triviální).

To je hodně přiblblá analogie hodná trola.

Ze o necem existuje kniha, opravdu nic nedoklada.

Že nechápeš souvislosti neznamená, že neexistují, jen že takové knihy nejsou pro tupé lopaty.

Kolik jich třeba ví, co to je katamorfismus, nemluvě o to, aby věděli, jak jim může pomoci zkrátit kód a překladači pomoci s optimalizací odstraněním rekurze?

Znalost teorie kategorii je pro funkcionalni programovani zhruba stejne dulezita, jako je dulezita znalost teorie grup pro vypocet ucetni uzaverky.

Jasně, a právě proto máme knížky jako Category theory for computing science apod.

A existence knihy o krestanstvi v manzelstvi je dukazem nepostradatelnosti krestanstvi v manzelstvi?

To je hodně přiblblá analogie hodná trola. Navíc nejde o nepostradatelnost, "jen" užitečnost.

Kolik jich třeba ví, co to je katamorfismus, nemluvě o to, aby věděli, jak jim může pomoci zkrátit kód a překladači pomoci s optimalizací odstraněním rekurze?

Znalost teorie kategorii je pro funkcionalni programovani zhruba stejne dulezita, jako je dulezita znalost teorie grup pro vypocet ucetni uzaverky.

Jasně, a právě proto máme knížky jako Category theory for computing science apod.

Je mi 37, zatím práci programátora zvládám ale bojuji s čím dál tím větší nechutí učit se další a další framework. Tak mě napadlo, tu práci bych měl dělat ještě 30 let!

Máte už plán co dělat, když Vám bude třeba 45 a prostě přestanete dávat tu vývojářskou práci? QA? Analýzu? Databáze? Administrátora? Učit nebo úplně z IT jít prodávat preclíky nebo uklízet na nádraží?

Dělat vývoj nebo něco podobného kreativního.

este by bolo vhodne napisat, kolko prispievatelov na roote robi vysokoodbornu pracu, nevyuziva nic vymyslene, vsetko si robia sami, alebo tu robia len ramena, pritom su to normalni programatori, ale len frustrovani . To by sme ostali naozaj prekvapeni.
Ale tu asi kazdy riesi fourierove transformacie, gramatiky, pise si vlastne kompilatory, spracovava signaly a vymysla nove algoritmy, sme predsa na roooooote

Spíše tu je hodně debilů, co jsou schopni napsat kreténismus jako "kdyby jsi se" apod. Pokud už chce něco takového mermomocí programovat, bylo by nejlepší začít grammar checkerem pro vlastní použití