Programovanie a modne trendy?

[Mirek Prýmek]

Plyne z toho, že funkce pro stejné vstupní parametry dává stejné výstupy.

Ne, to z toho neplyne, to je tvoje DEFINICE pojmu "konstantní fce".

BTW, opět v Erlangu ani Scale tohle neplatí. A pokud se nemýlím, tak ani v Clojure. Ono vůbec těch jazyků, kde to platí striktně, moc není.

Lepší ilustraci toho, jak pitomé jsou generalizace ohledně FP, jsi podat nemohl

(Otázka "a co z toho plyne?" pořád zůstává, akorát už asi ani nechci slyšet odpověď, protože jediný, co tady demonstruješ, je, že i v "OOP jazyce" se dá programovat funkcionálním stylem, což není pro nikoho žádný překvápko. Je to stejný jako že i céčku se dá psát objektově. I v assembleru. I když budeš zadávat ed-em stroják, můžeš programovat funkcionálně, objektově, strukturovaně, špagetově... Myslíš, že to někoho překvapuje nebo o co go?)

[Reklama]

[n]

Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?

To je legitimní otázka. Zkus si prostudovat, jak fungují masivně paralelní processing sytémy typu Hadoop, Spark, Flink. A zkus se potom zamyslet, proč se tam většinou používají immutable data a transformace bez vedlejších efektů.

Samozřejmě existují problémy, které je výrazně efektivnější řešit in situ. Tvrdil někdo opak?

Na ten první problém použiješ funkcionálně laděný přístup, na ten druhý klasický přístup. Kde je problém?

:-D Tim (hadoop based...konkretne soucasne nejvic hbase) se zivim. Ac to zni extremne ucelove subejktivne(to je ku*va (ma/z)mrdske slovni spojeni), je to uhel pohledu. Jsou veci na hodne nizke urovni, ktere jsou nemenitelne/immutable(obecne nejsme schopni efektivne menit atom1 -> atom2(ci dokonce nizsi castice)) ... zrovna jako v nasem (makro) svete. Ale z abstraktnejsiho hlediska naopak transformace informace(dat) in situ prinasi temer absurdni(javim, trochu "plytvam extremnimi vyjadrenimi") efektivitu(vim to, protoze jsme dokazali takhle zefektivnit nas system vice nez o dva rady).
Omlouvam se za tyhle extremnni nazory/vyjadreni, umyslne to trochu prehanim, ale muj nazor je, ze cim vic/lepe dokazem abstrahovat nad immutable svet(ktery snad opravdu na nejnizsi urovni immutable je), tim efektivneji dokazem vyjadrovat myslenky/transformace objektu.

[JSH]

Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat.

Na analogii s autem to sice moc nesedí, ale dám pár příkladů.

Mám kopec vlastností, které se výjímečně, ale nepředvidatelně mění (např. parametry video streamu). Pokud je mám v immutable struktuře, tak mi stačí kontrolovat jenom ukazatel. Bez immutable dat se uifuju.

Pokud chci nějaká data číst z hodně vláken, tak jsou immutable data rozumně výkonné řešení. Zámek mutable dat si budou jednotlivá jádra vyhazovat z cache a výkon půjde do kytek.

Kopírování immutable dat je problém jen v případě, že se jima nedá předejít ještě daleko větší ztrátě výkonu.

[Mirek Prýmek]

Ac to zni extremne ucelove subejktivne, je to uhel pohledu.

Není to úhel pohledu. Z jedné strany tečou data dovnitř, z druhé ven. V MapReduce, Sparku, Flinku,... a bambilionech dalších.

Tak asi to teda vypadá, že jsou všichni pitomí a plýtvají energií zatímco by to šlo celý udělat s násobnou efektivitou

Doporučoval bych ti, abys do té implementace šel. Lidi ti utrhají ruce, když jim cluster spočítá to samý, akorát místo megawatthodiny spotřebuje tři kilowatthodiny. Tím jsem si celkem jistej

[n]

Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat.

Na analogii s autem to sice moc nesedí, ale dám pár příkladů.

Mám kopec vlastností, které se výjímečně, ale nepředvidatelně mění (např. parametry video streamu). Pokud je mám v immutable struktuře, tak mi stačí kontrolovat jenom ukazatel. Bez immutable dat se uifuju.

Pokud chci nějaká data číst z hodně vláken, tak jsou immutable data rozumně výkonné řešení. Zámek mutable dat si budou jednotlivá jádra vyhazovat z cache a výkon půjde do kytek.

Kopírování immutable dat je problém jen v případě, že se jima nedá předejít ještě daleko větší ztrátě výkonu.

Mno.. je treba si uvedomit, ze velmi velmi malokdy potrebujete pristupovat ke stejnym datum paralelne. Typicke multi-threadove/procesni .. proste paralelni zpracovani dat je zaprve pouze cteni dat(kde zamky nejsou potreba) a i kdyby ne, tak se rozdeluji data na casti, ktere se mohou zpracovavat paralelne(konkurencne?) ale nezasahuji do sebe navzajem. Proste polopate mate velkou mnozinu dat-> rozdelite ji na casti a ruzne procesy zpracovavaji ruzne casti dat a opravdu si nelezou do zeli.
Kdyz potrebujete zpracovavat terabyty/petabyty dat, tak opravdu se vam nestava, ze modifikujete stejna data a potrebujete nejake zamky na toto(ani to neni mozne, ty data proste nejsou k dispozici na jednom zeleze)... hlavni ukol je rozdelit data tak, aby mohla byt zpracovavana soucasne vedle sebe.

[Reklama]

[n]

Ac to zni extremne ucelove subejktivne, je to uhel pohledu.

Není to úhel pohledu. Z jedné strany tečou data dovnitř, z druhé ven. V MapReduce, Sparku, Flinku,... a bambilionech dalších.

Tak asi to teda vypadá, že jsou všichni pitomí a plýtvají energií zatímco by to šlo celý udělat s násobnou efektivitou

Doporučoval bych ti, abys do té implementace šel. Lidi ti utrhají ruce, když jim cluster spočítá to samý, akorát místo megawatthodiny spotřebuje tři kilowatthodiny. Tím jsem si celkem jistej

Narazis na vic veci naraz, streamove zpracovani vs zpracovavani velkych dat. Oboje ma sve specififka a pozadavky na ne nejsou zamenitelne.

[Mirek Prýmek]

proste paralelni zpracovani dat je zaprve pouze cteni dat(kde zamky nejsou potreba)

To přece obecně není pravda. Platí to jenom v případě, že mi ta vstupní data nemůže někdo mezi tím přepsat (takže bych jedním vláknem zpracovával generaci 1 a druhým generaci 2 a reducem pak sčítal hrušky s jabkama). Pokud tohle nechci dopustit, tak musím mít buď read lock, nebo imutabilní data.

a i kdyby ne, tak se rozdeluji data na casti, ktere se mohou zpracovavat paralelne(konkurencne?) ale nezasahuji do sebe navzajem. Proste polopate mate velkou mnozinu dat

Aneb o koze a o voze... Pokud mám takové množství dat, že je zpracovávám sto stroji a nejsou mezi nimi žádné vazby, tak samozřejmě funkcionální přístup uvnitř toho jednoho stroje nic nepřinese. Ale to je snad každýmu jasný a o tomhle scénáři vůbec není řeč, ne?

Narazis na vic veci naraz, streamove zpracovani vs zpracovavani velkych dat. Oboje ma sve specififka a pozadavky na ne nejsou zamenitelne.

Ne. Mluvím o tom, že funkcionální přístup "masomlejnek je když mi jde dovnitř maso a ven mletý maso" se prosazuje v čímdál větším množství oblastí. Protože prostě má určité výhody. A zase jiné nevýhody. Nikdo tady snad nikdy netvrdil, že FP je dobrý vždycky, všude, na všechno a se sovětským svazem na věčné časy, ne?

Jediný, co tady děláme, je vyvracení obvyklých výhrad proti FP, které pramení z neznalosti nebo overgeneralizace.

[Kit]

(Otázka "a co z toho plyne?" pořád zůstává, akorát už asi ani nechci slyšet odpověď, protože jediný, co tady demonstruješ, je, že i v "OOP jazyce" se dá programovat funkcionálním stylem, což není pro nikoho žádný překvápko. Je to stejný jako že i céčku se dá psát objektově. I v assembleru. I když budeš zadávat ed-em stroják, můžeš programovat funkcionálně, objektově, strukturovaně, špagetově... Myslíš, že to někoho překvapuje nebo o co go?)

Takže jsme se shodli na tom, že i v objektových jazycích lze programovat funkcionálně. Nemám tedy důvod přecházet na nějaký funkcionální jazyk, neboť by pro mne nepředstavoval žádnou přidanou hodnotu. Vše potřebné najdu i v objektových jazycích.

Jen se stále divím, jak tě to překvapuje. Nebo snad ne?

[Kit]

Je zajímavé, jak je v módě FP, ale když se zmíním o tom, že používám XSLT, tak se mi blbí začnou smát.

No tak pokud chci programovat funkcionálně v něčem plném špičatých závorek, co je proslulé naprostou nečitelností, tak stejně preferuju C++ šablony. Pokud se s FP často setkáváš právě v podobě XSLT, tak opravdu rozumím tvé averzi.

Jaké averzi? XSLT je pro mne krásně čitelné, dobře se mi to píše a je to i rychlé. Naopak mám averzi vůči Smarty, Twigu a podobným zmetkům, které svádí ke strkání business logiky do šablon.

[Mirek Prýmek]

Takže jsme se shodli na tom, že i v objektových jazycích lze programovat funkcionálně.

Jistě. I v assembleru. A BASICu. Nenapadlo by mě, že by o tom mohl někdo pochybovat.

Nemám tedy důvod přecházet na nějaký funkcionální jazyk, neboť by pro mne nepředstavoval žádnou přidanou hodnotu.

To z předchozího neplyne.

Konzervu můžu otevírat šroubovákem. Nemám tedy důvod přecházet na otvírák. Q.E.D.

Konktrétně jde o to, že funkcionální jazyk typicky nějaké vlastnosti vynucuje. Tj. jsi nějak omezen, něco nemůžeš. A pokud něco nemůžeš, máš nějakou informaci o tom, že se něco z principu nemůže stát a tedy že neco platí. Čili zkráceně: v důsledku omezení máš víc informací, víc jistoty.

Pokud programuješ FP stylem v jazyce, který žádné FP vlastnosti nevynucuje, žádnou jistotu nemáš. Máš jenom starou dobrou nejistotu.

Už jsem to tady psal víckrát: Erlang vynucuje imutabilní data => máš jistotu, že jakékoliv odkazy (reference) v jakékoliv datové struktuře vedou jenom směrem "dozadu" (ke starším datům) a i od nich dál jenom stejným směrem. Pokud máš imutabilní objekt v jiném jazyce, může obsahovat odkaz na mutabilní data => jistotu nemáš.

[Kit]

Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat.

V reálném světě auto zavezu do lakovny a vyjedu s přebarveným autem.

Kód [Vybrat] Rozbalit

lakovna <původní_auto >přebarvené_auto

[Mirek Prýmek]

V reálném světě auto zavezu do lakovny a vyjedu s přebarveným autem.

Silně NEdoporučuju používat analogie z reálného světa. Ještě jsem nikde nepotkal referenci na auto. Nikdy se mi nepodařilo autem odjet do práce a zároveň dát referenci manželce, aby vyzvedla děcka ze školy.

[Pako]

V reálném světě auto zavezu do lakovny a vyjedu s přebarveným autem.

Silně NEdoporučuju používat analogie z reálného světa. Ještě jsem nikde nepotkal referenci na auto. Nikdy se mi nepodařilo autem odjet do práce a zároveň dát referenci manželce, aby vyzvedla děcka ze školy.

A to máte jenom z toho že se doma nebavíte objektovým ale funcionálním jazykem sakra přece!

[Mirek Prýmek]

A to máte jenom z toho že se doma nebavíte objektovým ale funcionálním jazykem sakra přece!

Kdybysme žili v objektovém světě, tak pojedu po dálnici a z ničehožnic to napálím do svodidel, protože manželka zatočila ke škole a zapomněli jsme dát zámek na volant

[andy]

Ale ted skoro vazne. Cele "funkcionalni paradigma" stoji na "immutable objektech"(pisu to uvozovkach, aby mi tady nekdo nevycital detaily) a cely immutable svet do extremu dovedeny je dost neefektivni. Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat. Jeste lepsi a uplne nejefektivnejsi by bylo,kdybychom umeli barvu zmenit(coz neumime).

Záleží na struktuře. V FP jazycích lidé rádi používají stromy, v imperativních hash tabulky. Změna prvku ve stromu má logaritmickou space-složitost - tzn. vyrobíte akorát novou "cestu" k prvku, všechno ukazuje na staré struktury. Není to tak efektivní jako imperativní (kde se změní jeden prvek), ale ani to není tak hrozné.

Jenomže pak třeba přijde něco jako potřeba provést nějaké undo - a v FP najednou máte k dispozici naprosto bez problémů historii změn a to v celkem kompaktní podobě, zatímco v imperativním to začne být docela zajímavý oříšek, pokud nechcete při každé změně dělat plnou kopii původní struktury...

Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?

That's the tradeoff... někdy (docela často) jsou tím vzácnějším zdrojem programátoři... a já osobně jsem hodně líný a dělám spoustu chyb, takže čím víc toho po mně počítač je schopen zkotrolovat, tím jsem šťastnější...