Funkcionální programátor

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Funkcionální programátor
« Odpověď #195 kdy: 02. 07. 2015, 02:00:46 »
Jenže čumila jsem pochopil tak, že i když to runtime dělá side effecty, tak nemusí ustupovat až tak daleko, že bude umožňovat i race conditions (přeci jenom, side-efect je užitečný, zatímco race conditions vůbec).
No to je zajímavá otázka - jestli by šlo nějak zabezpečit, aby jazyk předal runtimu zaručeně jenom takové instrukce, které by zaručeně nevedly k race condition. Pokud myslíš RC obecně (síť, paměť, disk, čekání na zprávy...) tak si to fakt neumím představit :)
Já mám na mysli jen ty v rámci daného runtime/programu. Obecný si taky nedovedu představit.


Třeba chytré hlavy už něco vymyslely, akorát to zas bude mít nějaké jiné neblahé praktické důsledky ;)
Vo tom nepochybuji.


Inkvizitor

Re:Funkcionální programátor
« Odpověď #196 kdy: 02. 07. 2015, 08:49:08 »
Ať nad tím dumám jak dumám, vychází mi z toho, že to právě race conditions vylučuje.
Když dumáš "uvnitř" toho jazyka, tak vylučuje - ale zároveň nemůže nijak ovlivnit okolní svět, což není moc praktické :)

čumil to napsal docela dobře: matematická funkce ti dům nepostaví. (udělá to za ni nějaký "runtime")
Jenže čumila jsem pochopil tak, že i když to runtime dělá side effecty, tak nemusí ustupovat až tak daleko, že bude umožňovat i race conditions (přeci jenom, side-efect je užitečný, zatímco race conditions vůbec). Proto uváděl další implementace řešení FP: uniqueness typing (rozumím jakžtakž), FRP (nerozumím vůbec).

No to je podle mě právě ta potíž, UT podle Čumila neumožňuje chybu souběhu jenom proto, že znemožňuje výpočet ve více vláknech, FRP se problému vyhýbá tím, že řízení výpočtu ponechává vně referenčně transparentních funkcí a Haskell to momentálně řeší IO monádou, která vrací popis akce, která má imperativní charakter a operuje ve světě, který běží v čase, je stavový a vládne v něm konkurence, do které vstupuje náš program v jednom nebo více vláknech. To je svět, který je úplně mimo dosah matematické funkce a proto snaha "smířit" reálný svět se světem čistě funkcionálním tak, jak by se Ti asi líbilo, není vůbec možné.

Co naopak podle mě možné je, je definovat konkurenční výpočet (třeba v IO monádě) tak, aby k race condition nedocházelo, ale to je problém, jehož řešení není v silách čistého FP jako takového.

Re:Funkcionální programátor
« Odpověď #197 kdy: 02. 07. 2015, 09:00:43 »
To je svět, který je úplně mimo dosah matematické funkce a proto snaha "smířit" reálný svět se světem čistě funkcionálním tak, jak by se Ti asi líbilo, není vůbec možné.
Mě včera napadlo, že možná není od věci si připomenout základ: matematická funkce není žádný "výpočet" nebo "operace". Matematická funkce je relace. Je to statická záležitost, tabulka vazeb parametry - výsledek. Matematická funkce se nedá "spustit", nemůže provést žádnou operaci, výpočet. Asi líp než u Haskellu je to vidět u Prologu, kde je program vlastně úplně statická záležitost (v tomhle popsaným smyslu), teprve inferenční engine je to, co "běží", co z programu dělá nějaký proces. A pokud chce člověk inferenční engine donutit k nějaké konkrétní posloupnosti činností, tak je to makačka na bednu, často se v tom udělá chyba a je to celkem citelný znásilňování té samotné základní (deklarativní) koncepce jazyka.

Ne že by to bylo něco, co byste nevěděli, ale když si to člověk připomene, tak se možná na tu race condition dívá trochu z jinýho úhlu :)

Re:Funkcionální programátor
« Odpověď #198 kdy: 02. 07. 2015, 09:12:17 »
V Dartu to jsou ještě kovariantní generika - typový systém povolí kontravarianci, ale za běhu to spadne. Například
Jasně, už to chápu. Prostě tam není syntaxe pro specifikaci variance a přijímá se, že to případně zbuchne až v provozu :)

V tom odkazu o Dartu se to píše docela bez obalu:
Citace
We don’t consider any of these ways in current use to be suitable for a language meant to be approachable, and whose type annotations are meant to be simple, lightweight, and optional. Really very few programmers of any kind find it natural or easy to write variance annotations or wildcarding (I don’t myself).
Citace

Čili "nechceme vyděsit JavaScriptisty" ;) Chápu, ale moc velký sympatie to ve mně teda nevyvolává :)

lkm

Re:Funkcionální programátor
« Odpověď #199 kdy: 02. 07. 2015, 09:13:14 »
No to je zajímavá otázka - jestli by šlo nějak zabezpečit, aby jazyk předal runtimu zaručeně jenom takové instrukce, které by zaručeně nevedly k race condition. Pokud myslíš RC obecně (síť, paměť, disk, čekání na zprávy...) tak si to fakt neumím představit :) Třeba chytré hlavy už něco vymyslely, akorát to zas bude mít nějaké jiné neblahé praktické důsledky ;)

To si dokážu představit zcela jasně, za předpokladu runtime v jednovláknovém OS, jako třeba MS-DOS. V současných OS ne.

Mě včera napadlo, že možná není od věci si připomenout základ: matematická funkce není žádný "výpočet" nebo "operace". Matematická funkce je relace. Je to statická záležitost, tabulka vazeb parametry - výsledek.

Potom není od věci připomenout si, že celý počítač je matematická funkce CPU zapsaná v booleově algebře, provádějící miliardkrát za sekundu přechod state := CPU(state) kde state je asi 20 000 bitů. Automaticky z toho vyplývá odpověď na problematiku race condition a proč to funkcionální programování nikdy nemůže vyřešit.


Re:Funkcionální programátor
« Odpověď #200 kdy: 02. 07. 2015, 09:29:19 »
To si dokážu představit zcela jasně, za předpokladu runtime v jednovláknovém OS, jako třeba MS-DOS. V současných OS ne.
Já si to dovedu (mlhavě) představit i v současných OS - klasické řešení je provádět citlivé operace atomicky nebo zamykat. Otázka zní, jak by to šlo dobře dohromady s tím FP jako takovým, jestli takové věci jdou dělat formálně (dokazatelně) správně, jak moc by takový program šel optimalizovat... Otázky, otázky, samé otázky :)))

Potom není od věci připomenout si, že celý počítač je matematická funkce CPU zapsaná v booleově algebře, provádějící miliardkrát za sekundu přechod state := CPU(state) kde state je asi 20 000 bitů. Automaticky z toho vyplývá odpověď na problematiku race condition a proč to funkcionální programování nikdy nemůže vyřešit.
Mně tam ta automatičnost nějak nevyvstává, už proto, že takhle napsáno je to "jednovláknová" věc, kde k RC dojít nemůže :)

Klíčový na tom všem je to odlišení jazyka jako takového a úrovně běhu (sémantiky, runtimu) - a jestli když si vymyslím, že bych chtěl dosáhnout nějaké vlastnosti běhu, tak jak dobře (a korektně) se to dá "mapovat" do jazyka... Třeba silný typový systém jazyka mi garantuje, že runtime nebude hledat v paměti něco, co tam není. Třeba by nějaký podobný fígl šel použít i na ty RC...

v

Re:Funkcionální programátor
« Odpověď #201 kdy: 02. 07. 2015, 09:41:46 »
To si dokážu představit zcela jasně, za předpokladu runtime v jednovláknovém OS, jako třeba MS-DOS. V současných OS ne.
Já si to dovedu (mlhavě) představit i v současných OS - klasické řešení je provádět citlivé operace atomicky nebo zamykat. Otázka zní, jak by to šlo dobře dohromady s tím FP jako takovým, jestli takové věci jdou dělat formálně (dokazatelně) správně, jak moc by takový program šel optimalizovat... Otázky, otázky, samé otázky :)))

Potom není od věci připomenout si, že celý počítač je matematická funkce CPU zapsaná v booleově algebře, provádějící miliardkrát za sekundu přechod state := CPU(state) kde state je asi 20 000 bitů. Automaticky z toho vyplývá odpověď na problematiku race condition a proč to funkcionální programování nikdy nemůže vyřešit.
Mně tam ta automatičnost nějak nevyvstává, už proto, že takhle napsáno je to "jednovláknová" věc, kde k RC dojít nemůže :)

Klíčový na tom všem je to odlišení jazyka jako takového a úrovně běhu (sémantiky, runtimu) - a jestli když si vymyslím, že bych chtěl dosáhnout nějaké vlastnosti běhu, tak jak dobře (a korektně) se to dá "mapovat" do jazyka... Třeba silný typový systém jazyka mi garantuje, že runtime nebude hledat v paměti něco, co tam není. Třeba by nějaký podobný fígl šel použít i na ty RC...
co třeba Software transactional memory?
v Haskellu ve formě STM monády, velmi příjemná záležitost

Re:Funkcionální programátor
« Odpověď #202 kdy: 02. 07. 2015, 09:55:48 »
co třeba Software transactional memory?
v Haskellu ve formě STM monády, velmi příjemná záležitost
To by asi mohlo být ono. V Erlangu se zas na to jde tak, že pokud je nějaký prostředek, který neumí konkurenci sám o sobě, tak se mu přiřadí řídící proces (erlangovský light proces), ostatní procesy jenom posílají zprávy a dostávají odpovědi, takže je to celý korektně serializovaný jenom díky tomu, jak probíhá štosování zpráv... Jelikož je posílání zpráv dostatečně rychlý, funguje to taky dobře. Jenže pak jsou "čisté" jenom ty procesy uvnitř, ne program jako celek, takže čumil by nad tím určitě ohrnoval nos ;)

lkm

Re:Funkcionální programátor
« Odpověď #203 kdy: 02. 07. 2015, 10:00:55 »
Já si to dovedu (mlhavě) představit i v současných OS - klasické řešení je provádět citlivé operace atomicky nebo zamykat.

User space současných OS nedovolí potřebnou úroveň atomicity a zamykání, to je jeho smysl aby to nešlo.

Mně tam ta automatičnost nějak nevyvstává, už proto, že takhle napsáno je to "jednovláknová" věc, kde k RC dojít nemůže :)
Klíčový na tom všem je to odlišení jazyka jako takového a úrovně běhu (sémantiky, runtimu) - a jestli když si vymyslím, že bych chtěl dosáhnout nějaké vlastnosti běhu, tak jak dobře (a korektně) se to dá "mapovat" do jazyka... Třeba silný typový systém jazyka mi garantuje, že runtime nebude hledat v paměti něco, co tam není. Třeba by nějaký podobný fígl šel použít i na ty RC...

Napsáno je to silně zjednodušeně, podstata je že k těm nepříjemným věcem jako RC dochází mimo vesmír celého funkcionálního cirkusu. Tudíž FP nemá možnost jak to ovlivnit nebo vyřešit.
Zjednodušeně buď budete hrát podle pravidel okolního světa a máte s FP problém, nebo si FP program spustíte v oddělené virtuální mašině kde si vytvoříte sluníčkový svět bez nebezpečných věcí a nemáte problém :)

To by asi mohlo být ono. V Erlangu se zas na to jde tak, že pokud je nějaký prostředek, který neumí konkurenci sám o sobě, tak se mu přiřadí řídící proces (erlangovský light proces), ostatní procesy jenom posílají zprávy a dostávají odpovědi, takže je to celý korektně serializovaný jenom díky tomu, jak probíhá štosování zpráv...

V Erlangu se proto nevedou diskuze, všichni vidí jak se věci mají ;)

Re:Funkcionální programátor
« Odpověď #204 kdy: 02. 07. 2015, 10:28:36 »
V Erlangu se proto nevedou diskuze, všichni vidí jak se věci mají ;)
No ale ten erlangovský přístup je právě příkladem, jak se dá dosáhnout atomicity*, takže je to v rozporu s tím, co píšeš výš.

* samozřejmě ne takové té superkorektní jako u databází - s rollbackem apod., ale to neva

lkm

Re:Funkcionální programátor
« Odpověď #205 kdy: 02. 07. 2015, 11:23:50 »
No ale ten erlangovský přístup je právě příkladem, jak se dá dosáhnout atomicity

Cíle se dosáhnout dá, ale ne s prostředky jazyka. Nepěkné nepohodlné věci se vystrčí ven z jazyka a komunikuje se s nimi přes nějaké rozhraní. Mají to tak všude, i v C/C++, i v C#, i v Javě, i v Erlangu. Rozdíl je jen v tom kdo si to již přiznal a kdo dosud ne :)

Re:Funkcionální programátor
« Odpověď #206 kdy: 02. 07. 2015, 11:29:53 »
Cíle se dosáhnout dá, ale ne s prostředky jazyka. Nepěkné nepohodlné věci se vystrčí ven z jazyka a komunikuje se s nimi přes nějaké rozhraní.
Jenze mezi tou "vystrcenou veci" a jazykem muze byt nejake mapovani, stejne jako u toho silneho typovani. Typovani je vlastne jenom ciste abstraktni vec a presto mi zarucuje nejake zalezitosti "vne jazyka".

Rozdíl je jen v tom kdo si to již přiznal a kdo dosud ne :)
Tak ja myslim, ze jsme tady o tom vsichni mluvili otevrene, ze Haskell vytvori nejaky predpis, ktery uz se provadi vlastne mimo samotny jazyk. Nevsiml jsem si, ze by to tady nekdo zastiral nebo nechapal.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Funkcionální programátor
« Odpověď #207 kdy: 02. 07. 2015, 13:57:13 »
Napsáno je to silně zjednodušeně, podstata je že k těm nepříjemným věcem jako RC dochází mimo vesmír celého funkcionálního cirkusu. Tudíž FP nemá možnost jak to ovlivnit nebo vyřešit.
Zjednodušeně buď budete hrát podle pravidel okolního světa a máte s FP problém, nebo si FP program spustíte v oddělené virtuální mašině kde si vytvoříte sluníčkový svět bez nebezpečných věcí a nemáte problém :)
Nevím, zda si všichni tak docela uvědomují, že vlastně všechny známé FP jazyky mají problém i s tím vlastním sluníčkovým světem. Jak jsme si tu dokázali v předchozích příspěvcích. To jen takovej malej rejp.

lkm

Re:Funkcionální programátor
« Odpověď #208 kdy: 02. 07. 2015, 14:10:50 »
Typovani je vlastne jenom ciste abstraktni vec a presto mi zarucuje nejake zalezitosti "vne jazyka".

Teoreticky asi ano, prakticky se obávám že ne ;)

JSH

Re:Funkcionální programátor
« Odpověď #209 kdy: 02. 07. 2015, 15:26:01 »
Nevím, zda si všichni tak docela uvědomují, že vlastně všechny známé FP jazyky mají problém i s tím vlastním sluníčkovým světem. Jak jsme si tu dokázali v předchozích příspěvcích. To jen takovej malej rejp.
Já osobně si ty omezení dobře uvědomuju. Neflamil jsem tu proto, že bych monády považoval za něco neprůstřelného. Jen mi vadilo, že nám tu čumil otloukal o hlavu, jaké elegantní řešení my tupci přehlížíme. A přítom jím navrhované věci trpí +-úplně tím stejným.