Dědičnost dnes

SB

Re:Dědičnost dnes
« Odpověď #945 kdy: 03. 02. 2017, 09:18:12 »
Pro určité vstupy to dokázat lze. Pro libovolný vstup to pro (netriviální) programy dokázat nelze.
No, a proto nepíšu obecné algoritmy pro libovolný vstup, ale konkrétní algoritmy pro konkrétní množinu dat.
Čímž se dostáváme zpět k tomu, že statickým typováním si určuju tu množinu, že jo.

Statická kontrola vstupů (a to často nekompletní) není nic, co by nešlo nahradit běhovou.


v

Re:Dědičnost dnes
« Odpověď #946 kdy: 03. 02. 2017, 09:19:58 »
Pro určité vstupy to dokázat lze. Pro libovolný vstup to pro (netriviální) programy dokázat nelze.
No, a proto nepíšu obecné algoritmy pro libovolný vstup, ale konkrétní algoritmy pro konkrétní množinu dat.
Čímž se dostáváme zpět k tomu, že statickým typováním si určuju tu množinu, že jo.

Statická kontrola vstupů (a to často nekompletní) není nic, co by nešlo nahradit běhovou.
to je roztomilé :)

JS

Re:Dědičnost dnes
« Odpověď #947 kdy: 03. 02. 2017, 09:24:13 »
Já jsem požadoval konkrétní implementaci konkrétního algoritmu, v konkrétním FP jazyku bez side efektů, která po překladu vygeneruje pro reálný HW stejně efektivní kód (stačí z hlediska asymptotické složitosti) jako implementace v imperativním jazyku.

OK. Jak uz jsem psal, FP jazyky nejsou dnes obecne efektivnejsi nez imperativni. Kompilatory k tomu smeruji (nekdy se podari i prekonat), ale neni to samozrejmost. Ale to neni duvod, proc FP (ne)pouzivat - duvod, proc FP pouzivat je v lepsim pohodli pro programatora (konkretne lepsi spravovatelnosti a znovupouzitelnosti).

V 70. a 80. letech se vedly diskuse zda kompilator dokaze napsat lepsi kod nez assemblersky programator. Nakonec k tomu doslo, a debata se vyresila. K temuz eventualne dojde i v FP, jenom to nebude hned zitra.

Citace
Zboj říkal, že to VŽDY jde, a zdůvodnňoval to plácáním nesmyslů o výpočetní síle lambda kalkulu. Já netvrdím, že to v tomto konkrétním případě nejde, jen jsem takové řešení dosud neviděl.

Ja si dokazu predstavit kompilator, ktery nejaky vicemene standardni postup prace v lambda kalkulu prevede do nahodnych pristupu do pameti.. (Muzes si treba predstavit vyvazeny binarni strom, ktery je implementovan jako pole.) Takze ano, jde to.

Re:Dědičnost dnes
« Odpověď #948 kdy: 03. 02. 2017, 09:43:14 »
Ja si dokazu predstavit kompilator, ktery nejaky vicemene standardni postup prace v lambda kalkulu prevede do nahodnych pristupu do pameti.. (Muzes si treba predstavit vyvazeny binarni strom, ktery je implementovan jako pole.) Takze ano, jde to.
Myslím, že se tady hlavně motají dohromady dvě věci: teoretická možnost výpočtu ve stejném množství kroků a praktický způsob, jak se v jednom nebo druhém případě reálně programuje a jaký je pak výkon toho kódu na reálném stroji.

Z toho teoretického pohledu (a to měl myslím zboj na mysli) je velice snadný v FP "simulovat" (na teoretické rovině) mutabilní výpočet - jestliže mutabilní výpočet je nějaká posloupnost kroků a,b,c, které nějak manipulují s pamětí, tak v imutabilním fp budu mít prostě   c(b(a(ram))) - funkce si předávají pole, které je jakoby RAM a můžou ho klidně měnit. Na teoretické rovině je tím causa finita. Dokonce k tomu můžu přidat, že na praktické rovině při tomhle přístupu ani nevzniká problém s kopírováním té struktury "ram", protože překladač ví, že se použije jenom jednou, takže ji vůbec kopírovat nemusí. Výkon je teda zjevně úplně stejný jako v ne-FP implementaci.

Inkvizitor

Re:Dědičnost dnes
« Odpověď #949 kdy: 03. 02. 2017, 09:54:21 »
Statická kontrola vstupů (a to často nekompletní) není nic, co by nešlo nahradit běhovou.

Všimni si, že do dynamických jazyků (třeba Python, Julia, PHP a pokud vím, chtěl by to Matz mít i v Ruby) v posledních letech intenzivně přidává podpora anotací typů. Sice to je nepovinné, ale ukazuje se, že to je výhodné. Běhová kontrola v případě složitější aplikace znamená, že se na chybu může přijít až po delší době a v nejméně vhodnou dobu. Linter problém odhalí hned.


zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Dědičnost dnes
« Odpověď #950 kdy: 03. 02. 2017, 10:04:54 »
Ja si dokazu predstavit kompilator, ktery nejaky vicemene standardni postup prace v lambda kalkulu prevede do nahodnych pristupu do pameti.. (Muzes si treba predstavit vyvazeny binarni strom, ktery je implementovan jako pole.) Takze ano, jde to.
Myslím, že se tady hlavně motají dohromady dvě věci: teoretická možnost výpočtu ve stejném množství kroků a praktický způsob, jak se v jednom nebo druhém případě reálně programuje a jaký je pak výkon toho kódu na reálném stroji.

Z toho teoretického pohledu (a to měl myslím zboj na mysli) je velice snadný v FP "simulovat" (na teoretické rovině) mutabilní výpočet - jestliže mutabilní výpočet je nějaká posloupnost kroků a,b,c, které nějak manipulují s pamětí, tak v imutabilním fp budu mít prostě   c(b(a(ram))) - funkce si předávají pole, které je jakoby RAM a můžou ho klidně měnit. Na teoretické rovině je tím causa finita. Dokonce k tomu můžu přidat, že na praktické rovině při tomhle přístupu ani nevzniká problém s kopírováním té struktury "ram", protože překladač ví, že se použije jenom jednou, takže ji vůbec kopírovat nemusí. Výkon je teda zjevně úplně stejný jako v ne-FP implementaci.
Tak nějak, byť ještě trochu obecněji. Někde na WWDC před 2-3 byl příklad "proceduralizace" FP ve Swiftu. Ale debilům to tady podrobně dohledávat nebudu a vy normální víte, vo co go ;)

v

Re:Dědičnost dnes
« Odpověď #951 kdy: 03. 02. 2017, 10:09:32 »
Statická kontrola vstupů (a to často nekompletní) není nic, co by nešlo nahradit běhovou.

Všimni si, že do dynamických jazyků (třeba Python, Julia, PHP a pokud vím, chtěl by to Matz mít i v Ruby) v posledních letech intenzivně přidává podpora anotací typů
a mezi statickýma se zatím rozmáhá inference typů :)

Inkvizitor

Re:Dědičnost dnes
« Odpověď #952 kdy: 03. 02. 2017, 10:27:54 »
Statická kontrola vstupů (a to často nekompletní) není nic, co by nešlo nahradit běhovou.

Všimni si, že do dynamických jazyků (třeba Python, Julia, PHP a pokud vím, chtěl by to Matz mít i v Ruby) v posledních letech intenzivně přidává podpora anotací typů
a mezi statickýma se zatím rozmáhá inference typů :)

No jasně. Dynamické jazyky přebírají výhody statických a naopak a imperativní jazyky přebírají funkcionální koncepty. Mně se ten trend líbí; zdá se, že po všech těch válkách dochází aspoň k částečné shodě.

balki

Re:Dědičnost dnes
« Odpověď #953 kdy: 03. 02. 2017, 12:08:07 »
Ja si dokazu predstavit kompilator, ktery nejaky vicemene standardni postup prace v lambda kalkulu prevede do nahodnych pristupu do pameti.. (Muzes si treba predstavit vyvazeny binarni strom, ktery je implementovan jako pole.) Takze ano, jde to.
Myslím, že se tady hlavně motají dohromady dvě věci: teoretická možnost výpočtu ve stejném množství kroků a praktický způsob, jak se v jednom nebo druhém případě reálně programuje a jaký je pak výkon toho kódu na reálném stroji.

Z toho teoretického pohledu (a to měl myslím zboj na mysli) je velice snadný v FP "simulovat" (na teoretické rovině) mutabilní výpočet - jestliže mutabilní výpočet je nějaká posloupnost kroků a,b,c, které nějak manipulují s pamětí, tak v imutabilním fp budu mít prostě   c(b(a(ram))) - funkce si předávají pole, které je jakoby RAM a můžou ho klidně měnit. Na teoretické rovině je tím causa finita. Dokonce k tomu můžu přidat, že na praktické rovině při tomhle přístupu ani nevzniká problém s kopírováním té struktury "ram", protože překladač ví, že se použije jenom jednou, takže ji vůbec kopírovat nemusí. Výkon je teda zjevně úplně stejný jako v ne-FP implementaci.
Tak nějak, byť ještě trochu obecněji. Někde na WWDC před 2-3 byl příklad "proceduralizace" FP ve Swiftu. Ale debilům to tady podrobně dohledávat nebudu a vy normální víte, vo co go ;)

Vieme, to je nieco Entscheidungsproblem. Lepsie je sa vyhovorit na google, nez davat zdroje "hlupakom".

gll

Re:Dědičnost dnes
« Odpověď #954 kdy: 03. 02. 2017, 12:12:21 »
Ja si dokazu predstavit kompilator, ktery nejaky vicemene standardni postup prace v lambda kalkulu prevede do nahodnych pristupu do pameti.. (Muzes si treba predstavit vyvazeny binarni strom, ktery je implementovan jako pole.) Takze ano, jde to.

Není k tomu důvod. Můžete používat jako stavební bloky knihovny, které jsou implementovány imperativně. Ve většině případů stačí použít mutabilitu jen pro naplnění datové struktury a potom s ní pracovat jako s immutabilní.

JS

Re:Dědičnost dnes
« Odpověď #955 kdy: 03. 02. 2017, 17:59:09 »
Není k tomu důvod. Můžete používat jako stavební bloky knihovny, které jsou implementovány imperativně. Ve většině případů stačí použít mutabilitu jen pro naplnění datové struktury a potom s ní pracovat jako s immutabilní.

A co ti tady asi uz 10 lidi prede mnou napsalo?  ;D Ty jsi trval na tom, ze to musi byt funkcionalni "all the way down".

JS

Re:Dědičnost dnes
« Odpověď #956 kdy: 03. 02. 2017, 18:04:15 »
Statická kontrola vstupů (a to často nekompletní) není nic, co by nešlo nahradit běhovou.

Tohle je asi tak na urovni tvrzeni: Algebra neni nic, co by se nedalo nahradit kalkulackou.

No, pokud chces zustat na urovni zakladni skoly, tak asi neni, no.

gll

Re:Dědičnost dnes
« Odpověď #957 kdy: 03. 02. 2017, 19:49:39 »
Není k tomu důvod. Můžete používat jako stavební bloky knihovny, které jsou implementovány imperativně. Ve většině případů stačí použít mutabilitu jen pro naplnění datové struktury a potom s ní pracovat jako s immutabilní.

A co ti tady asi uz 10 lidi prede mnou napsalo?  ;D Ty jsi trval na tom, ze to musi byt funkcionalni "all the way down".

oni tvrdí, že mé programy budou stejně rychlé i když ty mutable části nepoužiji.

Re:Dědičnost dnes
« Odpověď #958 kdy: 03. 02. 2017, 19:52:34 »
oni tvrdí, že mé programy budou stejně rychlé i když ty mutable části nepoužiji.
To je fakt marný...

Můžeš mi nějak polopaticky vysvětlit, z jakého důvodu potřebuješ tak zarputile dokazovat, že FP je pomalejší?

(a pak že jí mám nějaké "náboženství", ufff...)

rejpal rejpal rejpal

Re:Dědičnost dnes
« Odpověď #959 kdy: 03. 02. 2017, 20:18:12 »
Jednu dobu tu někteří tvrdili, že scheme je rychlejší než C. https://justindomke.wordpress.com/2009/02/23/the-stalin-compiler/