Funkcionální programátor

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Funkcionální programátor
« Odpověď #300 kdy: 06. 07. 2015, 21:41:27 »
Protože přece o přesně o tomhle to bylo. Ty sám jsi tuším řekl, že napsat to čistě bez vláken je triviální.
Nebylo. Bylo to o tom, že Clean to má údajně uděláno dobře. Akorátže jenom pro jedno vlákno. Což je podmínka, za které jsou monády úplně stejně dobré.
Clean neznám. Ale pokud je schopen používat IO bez souběhu, tak to řeší dobře. A že to implementuje tím, že zakáže vlákna? Hm, no a?

Pokud ti monády zajišťují pořadí výpočtu, ale jen někdy, tak je to zajištění dost hloupé, to se na mě nezlob.
No zajišťují ti pořadí výpočtu v jednom vlákně - vytvářejí ti prostě možnost kousek kódu psát "imperativně" (do block). Pokud chceš nějakou synchronizaci mezi vlákny, je na to potřeba jiný nástroj. Na tom mi nepřijde nic polovičatého. Monády prostě dělají to, co dělat mají.

Jak to chápu a jak jsem tomu porozuměl, jsou dva rozměry:
a/ Monády, které definují pořadí vyhodnocení výrazů, které jsou uvnitř. Unique typing, které definuje, že nějaký výraz bude jen jednou (zde trochu plavu, přiznávám, doufám, že to mám dobře).
b/ Haskell, který na IO používá systém monád, který ale nefunguje korektně ve více vláknech, protože Monádám je to jedno, o vlákna ani o unikátnost se nestarají.
Clean (a nebo další jazyky), které na IO používají  Unique typing (nebo react, nebo cokoliv), což řeší problém ve více vláknech, protože Unique typingu to jedno není, a tak se to řeší během v jednom vláknu.

Monády se nestarají o unikátnost, tudíž jim vlákna nevadí, a proto vzniká problém až v dalším kole. Zatím Unique typing (jak jsem to pochopil) řeší unikátnost, tak se s vlákny musí vývojář interpretu - ne jazyka, poprat.

Ano, pokud bych spouštěl aplikaci v jednom vláknu, tak jsou na to Monády stejně dobré jako UT. Jenže z ideového hlediska mi nic nebrání, abych Monády pouštěl ve více vláknech. Sice to nebude fungovat, ale můžu. Zatímco u Unique typingu to ideově vadí.


Re:Funkcionální programátor
« Odpověď #301 kdy: 06. 07. 2015, 21:46:12 »
Zatímco u Unique typingu to ideově vadí.
No a tohle omezení můžeš úplně klidně k monadickému řešení přidat a máš totéž (imho). To je ta pointa. Vezmeš Linux, vyhážeš z něj drivery pro síťovky a máš rázem SuperBezpečnýNehacknutelnýSystém(R), daleko lepší než Linux!

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Funkcionální programátor
« Odpověď #302 kdy: 06. 07. 2015, 21:50:50 »
Zatímco u Unique typingu to ideově vadí.
No a tohle omezení můžeš úplně klidně k monadickému řešení přidat a máš totéž (imho). To je ta pointa.
Vtip je v tom, že nemůžeš.

Re:Funkcionální programátor
« Odpověď #303 kdy: 06. 07. 2015, 21:52:29 »
Vtip je v tom, že nemůžeš.
Proč?

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Funkcionální programátor
« Odpověď #304 kdy: 06. 07. 2015, 21:56:36 »
Vtip je v tom, že nemůžeš.
Proč?
Nepřekračoval by si její (ideovou) zodpovědnost?


Re:Funkcionální programátor
« Odpověď #305 kdy: 06. 07. 2015, 22:04:17 »
Nepřekračoval by si její (ideovou) zodpovědnost?
Myslím že ne, protože stačí k tomu forku prostě nedát nástroj. Ale nejsem haskellista, v tomhle se můžu mýlit.

xyz

Re:Funkcionální programátor
« Odpověď #306 kdy: 06. 07. 2015, 22:41:13 »
Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú.

V principu to je velmi jednoduché - stačí znát definici jazyka - tj. typový systém, termy, hodnoty, redukci a na základě toho určíte, zda je jazyk čistě funkcionální.
To je vcelku jasné, napokon to zaznelo už aj v tomto vlákne. Toho sa moja reakcia netýkala. Samotná znalosť definície ešte nezaručuje jasnosť či pochopenie pojmu. Napríklad, z predstavy spojitej funkcie ako funkcie "ktorej graf sa netrhá" možno dôjsť k definícii, ktorá je vcelku jednoduchá a logická. Problém môže nastať vo chvíli, keď narazíme na Cantorovu funkciu či Riemannovu funkciu a zrazu zistíme, že naše pochopenie pojmu nebolo zďaleka také dobré, ako sme si mysleli. A problém nie je v definícii alebo v náročnosti dôkazu spojitosti/nespojitosti pri týchto funkciách, ale v tom, že výsledky sú iné ako by sme intuitívne očakávali.

Blog, ktorý som odkazoval, naznačil, že čosi podobné nás môže stretnúť pri čistom funkcionálnom jazyku. Ako odpoveď som (bez akéhokoľvek vysvetlenia) dostal, že uvedený príklad debatu nijako nevyjasňuje, ale naopak zahmlieva. No a toho sa týkala moja vyššie citovaná reakcia, na ktorú som však (presne podľa očakávania) aj tak nijakú odpoveď nedostal.

Vůbec ne, protože řazení funkcí ve správném pořadí je to jediné, co u lazy jazyka pro IO potřebuješ. Nebýt línosti, monády bys vůbec nepotřeboval,...
A nepotrebuješ ich ani pri lenivom vyhodnocovaní, ako ukazuje príklad Mirandy.

Radek Miček

Re:Funkcionální programátor
« Odpověď #307 kdy: 06. 07. 2015, 22:52:14 »
Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú.

V principu to je velmi jednoduché - stačí znát definici jazyka - tj. typový systém, termy, hodnoty, redukci a na základě toho určíte, zda je jazyk čistě funkcionální.

keď narazíme na Cantorovu funkciu či Riemannovu funkciu a zrazu zistíme, že naše pochopenie pojmu nebolo zďaleka také dobré

Možná, ale zatím jsme na žádný takový příklad nenarazili, nebo ano?

xyz

Re:Funkcionální programátor
« Odpověď #308 kdy: 06. 07. 2015, 23:07:25 »
Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú.

V principu to je velmi jednoduché - stačí znát definici jazyka - tj. typový systém, termy, hodnoty, redukci a na základě toho určíte, zda je jazyk čistě funkcionální.

keď narazíme na Cantorovu funkciu či Riemannovu funkciu a zrazu zistíme, že naše pochopenie pojmu nebolo zďaleka také dobré

Možná, ale zatím jsme na žádný takový příklad nenarazili, nebo ano?
To závisí od toho, či nám tá Cantorova alebo Riemannova funkcia naozaj pripadá divná alebo nie. Ako ukazuje diskusia v tomto vlákne (ale aj na iných fórach), tak čistota Haskellu jednoznačne mnohým ľuďom divná pripadá. Čím, pravdaže, nevylučujem, že niekomu by nemusel pripadať divný ani funkcionálne čistý jazyk "obsahujúci C-čko".

Re:Funkcionální programátor
« Odpověď #309 kdy: 07. 07. 2015, 09:55:12 »
To závisí od toho, či nám tá Cantorova alebo Riemannova funkcia naozaj pripadá divná alebo nie. Ako ukazuje diskusia v tomto vlákne (ale aj na iných fórach), tak čistota Haskellu jednoznačne mnohým ľuďom divná pripadá. Čím, pravdaže, nevylučujem, že niekomu by nemusel pripadať divný ani funkcionálne čistý jazyk "obsahujúci C-čko".
Nebylo by lepší opustit ty mlhavé analogie a napsat to polopaticky? V čem Haskell není čistý? Zatím jsme narazili jenom na to, že forknutí IO je nečisté (což je jasný z principu). Něco dál? A v jakém smyslu by měl být čistý "funkcionální jazyk obsahující céčko"? Jak by měl vypadat? V čem by se od Haskellu lišil?

JSH

Re:Funkcionální programátor
« Odpověď #310 kdy: 07. 07. 2015, 16:35:14 »
Clean neznám. Ale pokud je schopen používat IO bez souběhu, tak to řeší dobře. A že to implementuje tím, že zakáže vlákna? Hm, no a?
A není to řešení jakési neuspokojivé? Stejným způsobem by se přece daly vyřešit problémy s paralelismem i v C :
Kód: [Vybrat]
#define pthread_create trhni_si_nohou
Už tu padlo asi tisíckrát, že Haskell bez použití vláken je v tomhle identický s Cleanem.


Citace
Jak to chápu a jak jsem tomu porozuměl, jsou dva rozměry:
a/ Monády, které definují pořadí vyhodnocení výrazů, které jsou uvnitř. Unique typing, které definuje, že nějaký výraz bude jen jednou (zde trochu plavu, přiznávám, doufám, že to mám dobře).
Pokud si alokuješ objekt na haldě, tak unique typing zajistí že ti na něj může ukazovat jeden jediný ukazatel. Takových objektů na haldě můžeš mít milion ale na každý bude ukazovat jenom jeden ukazatel.

V cleanu se to využívá tak, že se vytvoří objekt Svět. Každá funkce co dělá IO ho bere jako parametr a vrací. Protože ten ukazatel může být jenom jeden, tak se ty io funkce dají jenom spojit jedna za druhou. A teď překvapení : V IO monádě je schovaný přesně takovýhle objekt. Jenom tam ta unikátnost není zajištěná speciálním pravidlem jazyka ale omezenou sadou funkcí, ktrýma se dají IO akce kombinovat.

Citace
b/ Haskell, který na IO používá systém monád, který ale nefunguje korektně ve více vláknech, protože Monádám je to jedno, o vlákna ani o unikátnost se nestarají.
Clean (a nebo další jazyky), které na IO používají  Unique typing (nebo react, nebo cokoliv), což řeší problém ve více vláknech, protože Unique typingu to jedno není, a tak se to řeší během v jednom vláknu.
Unique typing vlákna neřeší, protože se stará jen o jeden objekt. Pokud má každé vlákno vlastní World objekt, je to unique typingu úplně putna. V tomhle jsou Haskell a Clean jako přes kopírák. Clean te "řeší" tak, že tam ty vlákna prostě zatím nikdo neimplementoval. Tohle si bohužel může dovolit jen experimentální jazyk, který skoro nikdo nepoužívá.

Citace
Monády se nestarají o unikátnost, tudíž jim vlákna nevadí, a proto vzniká problém až v dalším kole. Zatím Unique typing (jak jsem to pochopil) řeší unikátnost, tak se s vlákny musí vývojář interpretu - ne jazyka, poprat.

Ano, pokud bych spouštěl aplikaci v jednom vláknu, tak jsou na to Monády stejně dobré jako UT. Jenže z ideového hlediska mi nic nebrání, abych Monády pouštěl ve více vláknech. Sice to nebude fungovat, ale můžu. Zatímco u Unique typingu to ideově vadí.
Ideově to nevadí unique typingu. Ideově to může vadit maximálně tak někomu, kdo si plete vlastnosti UT a singletonu. Milion objektů typu Svět, pro každé vlákno jeden, je podle UT 100% správně. Pokud teda na každý bude ukazovat jediný ukazatel, ale to monády zvládnou zajistit taky.

Monády a UT jsou trochu něco jiného, ale v tomhle případě jsou jejich výsledky naprosto stejné.

Greenhorn

Re:Funkcionální programátor
« Odpověď #311 kdy: 07. 07. 2015, 18:46:52 »
Clean neznám. Ale pokud je schopen používat IO bez souběhu, tak to řeší dobře. A že to implementuje tím, že zakáže vlákna? Hm, no a?
A není to řešení jakési neuspokojivé? Stejným způsobem by se přece daly vyřešit problémy s paralelismem i v C :
Kód: [Vybrat]
#define pthread_create trhni_si_nohou
Už tu padlo asi tisíckrát, že Haskell bez použití vláken je v tomhle identický s Cleanem.


Citace
Jak to chápu a jak jsem tomu porozuměl, jsou dva rozměry:
a/ Monády, které definují pořadí vyhodnocení výrazů, které jsou uvnitř. Unique typing, které definuje, že nějaký výraz bude jen jednou (zde trochu plavu, přiznávám, doufám, že to mám dobře).
Pokud si alokuješ objekt na haldě, tak unique typing zajistí že ti na něj může ukazovat jeden jediný ukazatel. Takových objektů na haldě můžeš mít milion ale na každý bude ukazovat jenom jeden ukazatel.

V cleanu se to využívá tak, že se vytvoří objekt Svět. Každá funkce co dělá IO ho bere jako parametr a vrací. Protože ten ukazatel může být jenom jeden, tak se ty io funkce dají jenom spojit jedna za druhou. A teď překvapení : V IO monádě je schovaný přesně takovýhle objekt. Jenom tam ta unikátnost není zajištěná speciálním pravidlem jazyka ale omezenou sadou funkcí, ktrýma se dají IO akce kombinovat.

Citace
b/ Haskell, který na IO používá systém monád, který ale nefunguje korektně ve více vláknech, protože Monádám je to jedno, o vlákna ani o unikátnost se nestarají.
Clean (a nebo další jazyky), které na IO používají  Unique typing (nebo react, nebo cokoliv), což řeší problém ve více vláknech, protože Unique typingu to jedno není, a tak se to řeší během v jednom vláknu.
Unique typing vlákna neřeší, protože se stará jen o jeden objekt. Pokud má každé vlákno vlastní World objekt, je to unique typingu úplně putna. V tomhle jsou Haskell a Clean jako přes kopírák. Clean te "řeší" tak, že tam ty vlákna prostě zatím nikdo neimplementoval. Tohle si bohužel může dovolit jen experimentální jazyk, který skoro nikdo nepoužívá.

Citace
Monády se nestarají o unikátnost, tudíž jim vlákna nevadí, a proto vzniká problém až v dalším kole. Zatím Unique typing (jak jsem to pochopil) řeší unikátnost, tak se s vlákny musí vývojář interpretu - ne jazyka, poprat.

Ano, pokud bych spouštěl aplikaci v jednom vláknu, tak jsou na to Monády stejně dobré jako UT. Jenže z ideového hlediska mi nic nebrání, abych Monády pouštěl ve více vláknech. Sice to nebude fungovat, ale můžu. Zatímco u Unique typingu to ideově vadí.
Ideově to nevadí unique typingu. Ideově to může vadit maximálně tak někomu, kdo si plete vlastnosti UT a singletonu. Milion objektů typu Svět, pro každé vlákno jeden, je podle UT 100% správně. Pokud teda na každý bude ukazovat jediný ukazatel, ale to monády zvládnou zajistit taky.

Monády a UT jsou trochu něco jiného, ale v tomhle případě jsou jejich výsledky naprosto stejné.
Je to jen taková poznámka. Něco co mne napadlo. Koukal jsem se na unique typing a myslím že jsem ho vcelku pochopil. My nemůže zkopírovat objekt World prostě proto, že zkopírovat svět nejde, objekt World je jen reference na svět, ne samotný svět, a podle UT s objektem musí pracovat pouze jedno jediné vlákno. Kdyby jsme zkopírovali World, budou existovat dvě reference na ten skutečný svět, a tím pádem už to nebude UT, protože s objektem bude pracovat více vláken. 

Greenhorn

Re:Funkcionální programátor
« Odpověď #312 kdy: 07. 07. 2015, 18:52:14 »
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.

JSH

Re:Funkcionální programátor
« Odpověď #313 kdy: 07. 07. 2015, 19:12:41 »
Je to jen taková poznámka. Něco co mne napadlo. Koukal jsem se na unique typing a myslím že jsem ho vcelku pochopil. My nemůže zkopírovat objekt World prostě proto, že zkopírovat svět nejde, objekt World je jen reference na svět, ne samotný svět, a podle UT s objektem musí pracovat pouze jedno jediné vlákno. Kdyby jsme zkopírovali World, budou existovat dvě reference na ten skutečný svět, a tím pádem už to nebude UT, protože s objektem bude pracovat více vláken.
A tady leží ten zásadní problém. O objektu World se dá uvažovat jako o singletonu. S tím ale UT nijak nepomůže. Ten umí  zaručit že na objekt bude existovat jediná reference. Ale těch jednotlivých objektů může být neomezeně.
Pro jazyk je objekt World naprosto normální entita. Netuší že je to fake reprezentace něčeho jiného. Dá se jich vytvořit libovolné množství. Jediné co tomu brání je, že to ještě nikdo nenapsal. Není to nic za co by mohlo UT. UT řeší jen unikátnost "ukazatelů". Neřeší to, na co ty ukazatele ukazují.

JSH

Re:Funkcionální programátor
« Odpověď #314 kdy: 07. 07. 2015, 20:15:20 »
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
Tohle : http://forum.root.cz/index.php?topic=11417.msg134558#msg134558

Ano, má tam spoustu věcí správně ale taky dost zásadní chyby. Třeba to o mutable proměnných v bodu 3. Ano, Haskell je umí a Clena je neumí jen proto že je tam zatím nikdo neimplementoval. Pokud jsou v něčem soubory, tak mutable proměnné taky musí jít. Je úplně jedno, co přesně jsou ty malé kousky stavu co program mění. UT tomu nijak nebrání. Ani s referenční transparentností na tom jsou monády úplně stejně. Výraz s objektem world se nahradit návratovou hodnotou nedá, protože world v principu závisí na čase a stavu celého světa v daném čase.

Ty Lazy streams taky nejsou žádná ultimátní stříbrná kulka. Jsou blbě rozšiřitelné, s jedním streamem může pracovat jenom jedno vlákno.

Ano, obecné věci o FP tam má dobře. Akorát v těch detailech má kopec chyb. A ty detaily nám tu otloukal o hlavu s takovou vervou, že to dopadlo tímhle flamem.