Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: schwejk 22. 07. 2017, 19:14:44
-
Může mi někdo vysvětlit, proč se do normálních OO jazyků cpe FP? Proč se C++ a Rust a Swift sviní něčím jako flatMap apod.? Pak kolekce jsou hodnotové typy místo normálních tříd a celé OOP jde do kytek...
-
IMHO:
Protože OOP nefunguje tak, jak evangelisti slibovali = nepomáhá tolik, jak mělo, je extrémně náročné do toho proniknout, vyžaduje to velkou míru disciplíny, ...
Zatímco FP vypadá, že by mohlo fungovat líp = dá se v něm snadněji psát čitelný kód, hůře se v něm prasí, většinou to sklouzává na to, že to buď napíšeš relativně čitelně, nebo to nenapíšeš vůbec, větší míra znovupoužitelnosti oproti OOP, plus to má další více či méně teoretické výhody.
A nejdůležitější důvod vůbec: je po tom poptávka.
-
+1
plus to má další více či méně teoretické výhody.
Jeste bych doplnil, ze moznost "zadarmo" psat kod pripraveny pro paralelni zpracovani je IMO velke plus. To se v popularnich implementacich OOP jaksi nenosi. Dalsi vyhoda je, ze psani testu pro FP kod je velmi jednoduche - zadne mocky a jine berlicky, proste mam vstup (parametry funkce) a vystup (jedna hodnota, ktera bude vzdy zaviset pouze na vstupu a ne na cemkoliv ve svete).
-
Objekty se skládají z dat a metod. Metody lze chápat jako specializované funkce. Rád používám immutable objekty a to už je jen krůček k FP. Výhody FP zde již byly uvedeny, mně vyhovuje hlavně ta dobrá testovatelnost.
Funkcionální prvky v OOP nevadí, pokud se to s nimi nepřežene.
-
Pak kolekce jsou hodnotové typy místo normálních tříd a celé OOP jde do kytek...
Na to jsi přišel jak?
-
+1
plus to má další více či méně teoretické výhody.
Jeste bych doplnil, ze moznost "zadarmo" psat kod pripraveny pro paralelni zpracovani je IMO velke plus. To se v popularnich implementacich OOP jaksi nenosi. Dalsi vyhoda je, ze psani testu pro FP kod je velmi jednoduche - zadne mocky a jine berlicky, proste mam vstup (parametry funkce) a vystup (jedna hodnota, ktera bude vzdy zaviset pouze na vstupu a ne na cemkoliv ve svete).
Nejen paralelní zpracování, ale lepší optimalizace obecně díky imutabilitě. Záleží na překladači, Haskell třeba optimalizuje jako divý (hlavně kód bez rekurze, ale té se dá snadno zbavit).
-
Až bude FP mainstream bude se v něm prasit více než v OOP.
-
Až bude FP mainstream bude se v něm prasit více než v OOP.
V FP to jde ale o dost hůře. Je fakt, že Češi jsou vynalézaví, tak to asi dají...
-
FP nebude nikdy mainstream, protože to už budeme v postalgoritmické době, algoritmy nebudou synteticky vytvářené, ale vytrénované a explicitně neznámé :-)))
-
Až bude FP mainstream bude se v něm prasit více než v OOP.
V FP to jde ale o dost hůře. Je fakt, že Češi jsou vynalézaví, tak to asi dají...
No právě, že to jde hůře, proto bude potřeba více prasit. V živém systému bude několik větví dělajících to samé, jak se budou připisovat nové funkce místo toho, aby se využívala a upravovala existující funkčnost, každý kdo bude něco upravovat, založí svou novou větev.
-
... Pak kolekce jsou hodnotové typy místo normálních tříd a celé OOP jde do kytek...
Srovnávání kolekcí s třídami mi připadá jako srovnávání košíku jablek s projektem buldozeru...
-
Ten dotaz měl znít asi jinak. Proč jsou v "normálních" OO programovacích jazycích (C++ a Rust a Swift, Java, ...) vůbec nějaké hodnotové typy, proč tam nejsou prostě jen objekty?
-
Ten dotaz měl znít asi jinak. Proč jsou v "normálních" OO programovacích jazycích (C++ a Rust a Swift, Java, ...) vůbec nějaké hodnotové typy, proč tam nejsou prostě jen objekty?
Z mentální setrvačnosti. Smalltalk žádné hodnotové typy nemá.
-
Ten dotaz měl znít asi jinak. Proč jsou v "normálních" OO programovacích jazycích (C++ a Rust a Swift, Java, ...) vůbec nějaké hodnotové typy, proč tam nejsou prostě jen objekty?
Protoze by to bylo pomale a zabiralo hodne pameti. Treba pole objektu - kazdy objekt v nem ma pointer, ktery na nej ukazuje. Navic je problem s cache.
-
Ten dotaz měl znít asi jinak. Proč jsou v "normálních" OO programovacích jazycích (C++ a Rust a Swift, Java, ...) vůbec nějaké hodnotové typy, proč tam nejsou prostě jen objekty?
Protoze by to bylo pomale a zabiralo hodne pameti. Treba pole objektu - kazdy objekt v nem ma pointer, ktery na nej ukazuje. Navic je problem s cache.
To může automaticky vyřešit překladač.
-
Ten dotaz měl znít asi jinak. Proč jsou v "normálních" OO programovacích jazycích (C++ a Rust a Swift, Java, ...) vůbec nějaké hodnotové typy, proč tam nejsou prostě jen objekty?
Jen aby se to zase nezvrhlo, tak: Rust neni OO jazyk v tom vyznamu, jak ho zname z C++ nebo z Javy
-
Protoze by to bylo pomale a zabiralo hodne pameti. Treba pole objektu - kazdy objekt v nem ma pointer, ktery na nej ukazuje. Navic je problem s cache.
nemuselo. treba numpy pole je z hlediska pythonu jen jeden objekt.
-
Ten dotaz měl znít asi jinak. Proč jsou v "normálních" OO programovacích jazycích (C++ a Rust a Swift, Java, ...) vůbec nějaké hodnotové typy, proč tam nejsou prostě jen objekty?
Protoze by to bylo pomale a zabiralo hodne pameti. Treba pole objektu - kazdy objekt v nem ma pointer, ktery na nej ukazuje. Navic je problem s cache.
Nevidím důvod, proč by pole (nebo spíš kolekce) objektů mělo být pomalé. Když jsou operace pro práci s objekty uvnitř těch objektů, tak je to docela svižné.
-
Proč jsou v "normálních" OO programovacích jazycích (C++ a Rust a Swift, Java, ...) vůbec nějaké hodnotové typy, proč tam nejsou prostě jen objekty?
Protoze by to bylo pomale a zabiralo hodne pameti. Treba pole objektu - kazdy objekt v nem ma pointer, ktery na nej ukazuje. Navic je problem s cache.
To je sice pravda, ale s původním dotazem ohledně FP to nijak nesouvisí.
-
To je zajímavé, o čem je tedy vlastně původní dotaz?
1) tazateli vadí, že mu funkcionální přístup v některých OO programovacích jazycích bere objekty, a tedy zmiňované jazyky nejsou dostatečně objektové (tzn. dotaz je obecný)?
2) tazateli vadí konkrétní funkce např. flatMap, která mu v nějakém případě vrací hodnotové typy místo objektů?
Mně tedy příjde, že je to dotaz trochu více o OOP, než o funkcionálním programování...
-
V živém systému bude několik větví dělajících to samé, jak se budou připisovat nové funkce místo toho, aby se využívala a upravovala existující funkčnost, každý kdo bude něco upravovat, založí svou novou větev.
Pokud by tohle vylezlo po některých vývojářích, tak by to bylo úplně fantastické.
-
Protoze by to bylo pomale a zabiralo hodne pameti. Treba pole objektu - kazdy objekt v nem ma pointer, ktery na nej ukazuje. Navic je problem s cache.
nemuselo. treba numpy pole je z hlediska pythonu jen jeden objekt.
Tak trochu jsem predpokladal, ze dotaz byl hlavne na to, jak veci dela Java - treba C# ma hodnotove typy, ktere se chovaji (z hlediska programatora) jako objekty (v Jave).
A ano, ma to smysl, protoze ackoli teoreticky by prekladace mohly automaticky prelozit "objekty" (v tomto kontextu typy predavane a ukladane odkazem) na hodnotove typy (tedy typy predavane a ukladane primo), pochybuji, ze technologie prekladacu je natolik vyspela, aby se to zvladlo vsude, kde to ma smysl delat. Mozna za nejakych 30 let..
(Kdyz jsme tak u toho - nemam moc rad, kdyz se FP "prodava" s tim, ze pomuze paralelismu - ve skutecnosti to prekladace funkcionalnich jazyku zatim moc neumi, a je to trochu zavadejici argument, ktery muze vzbudit prehnana ocekavani. Mam FP rad, ale IMHO hlavni duvod je vyssi abstrakce a lepsi vysledna citelnost, nicmene technologie prekladacu jeste nedosahla dostatecne urovne, aby tohle dostatecne vykompenzovala.)
Navic je to uzitecne pro interoperabilitu - jeden z duvodu proc .NET zavedl hodnotove typy (treba struct) je jiste v tom, ze chteli mit moznost volat z .NET nativni knihovny, ktere obcas ocekavaji strukturu nebo pole struktur jako parametr. V Jave je tohle (pokud se nepletu) trochu problem.
-
(Kdyz jsme tak u toho - nemam moc rad, kdyz se FP "prodava" s tim, ze pomuze paralelismu - ve skutecnosti to prekladace funkcionalnich jazyku zatim moc neumi, a je to trochu zavadejici argument, ktery muze vzbudit prehnana ocekavani. Mam FP rad, ale IMHO hlavni duvod je vyssi abstrakce a lepsi vysledna citelnost, nicmene technologie prekladacu jeste nedosahla dostatecne urovne, aby tohle dostatecne vykompenzovala.)
Pokud se bavime o FP namixovane s OOP, tak treba ve Scale to bylo o pouhem pridani volani par do chainu (priklad z doc list.par.map(_ + 42)). Pripadne pouzivani knihovny jako Akka - pokud mate stavajici kod FP, tak IMO nebude obtizne to preklopit do Akka a ziskat tak skoro zadarmo paralelni zpracovani. Nebo mate na mysli nejake implicitni paralelni zpracovani, ktere na zaklade neceho pouzije prekladac/runtime?
(Jinak za me by stacila i jen ta vyssi abstrakce, ale moznost jednoduse paralelizovat stavajici FP kod neni take k zahozeni.)
-
Pretoze je to prijemne a je pre tom dopyt. Dopyt po tom je preto, ze vela veci sa da funkcionalnym programovanim riesit kratsie, cistejsie a elegantnejsie. Klasickym prikladom su navrhove vzory v OOP (GoF) z ktorych vacsina je v podstate len dosledkom chybajucich vlastnosti niektorych OO jazykov.
-
Protoze by to bylo pomale a zabiralo hodne pameti. Treba pole objektu - kazdy objekt v nem ma pointer, ktery na nej ukazuje. Navic je problem s cache.
nemuselo. treba numpy pole je z hlediska pythonu jen jeden objekt.
Mam FP rad, ale IMHO hlavni duvod je vyssi abstrakce a lepsi vysledna citelnost
Vyšší abstrakce je sice velká výhoda, ale pro většinu vývojářů to může být problém. 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? Účinné nasazení FP by vyžadovalo přeučení, a to se se starým psem (neřkuli volem) dělá těžko.
-
Protoze by to bylo pomale a zabiralo hodne pameti. Treba pole objektu - kazdy objekt v nem ma pointer, ktery na nej ukazuje. Navic je problem s cache.
nemuselo. treba numpy pole je z hlediska pythonu jen jeden objekt.
nicmene technologie prekladacu jeste nedosahla dostatecne urovne, aby tohle dostatecne vykompenzovala.
Jak co, Haskell třeba optimalizuje hodně chytře a rozhodí ho až rekurze, proto jsou ostatně v jeho knihovnách všude fixpointy. Problém je občas v tom, že překladači se musí holt trochu pomoci, čili vývojář musí vědět jak, což předpokládá hlubší znalosti principů FP.
-
Pretoze je to prijemne a je pre tom dopyt. Dopyt po tom je preto, ze vela veci sa da funkcionalnym programovanim riesit kratsie, cistejsie a elegantnejsie. Klasickym prikladom su navrhove vzory v OOP (GoF) z ktorych vacsina je v podstate len dosledkom chybajucich vlastnosti niektorych OO jazykov.
Návrhové vzory budou brzy i v FP, je dobré vždy se omezit jen na určitý výsek možností dané technologie a z té vytvořit všem srozumitelný jazyk a to jsou návrhové vzory. Nejsou prostředkem k řešení problému, ale prostředkem ke komunikaci mezi tvůrcem a údržbářem sw.
Požadavek snadné modifikovatelnosti programu nevyplývá ze samotné funkce programu a řešení daného problému, ale z požadavku následné údržby programu a předpokladu, že funkce programu se bude v čase měnit, protože se bude měnit realita či její poznání.
-
Návrhové vzory budou brzy i v FP, je dobré vždy se omezit jen na určitý výsek možností dané technologie a z té vytvořit všem srozumitelný jazyk a to jsou návrhové vzory. Nejsou prostředkem k řešení problému, ale prostředkem ke komunikaci mezi tvůrcem a údržbářem sw.
Návrhové vzory ve FP už jsou. Jen se jim tak neříká, protože žádný GoF dosud neprovedl jejich standardizaci.
Ano, návrhové vzory slouží hlavně pro komunikaci mezi lidmi. Implementace je v každém jazyce jiná. Někdy je implementován na jednom řádku, jindy tentýž vzor zabere stovky řádek.
-
Pretoze je to prijemne a je pre tom dopyt. Dopyt po tom je preto, ze vela veci sa da funkcionalnym programovanim riesit kratsie, cistejsie a elegantnejsie. Klasickym prikladom su navrhove vzory v OOP (GoF) z ktorych vacsina je v podstate len dosledkom chybajucich vlastnosti niektorych OO jazykov.
Návrhové vzory budou brzy i v FP
Vždy když si někdo myslí, že v FP objevil návrhový vzor, je to bez výjimky něco z teorie kategorií. Stačilo by sepsat něco o KT pro nadané vývojáře a máme "GoF".
-
... tahle diskuse je plna vzoru - doufam ze se nedaji prevadet ...
-
Pretoze je to prijemne a je pre tom dopyt. Dopyt po tom je preto, ze vela veci sa da funkcionalnym programovanim riesit kratsie, cistejsie a elegantnejsie. Klasickym prikladom su navrhove vzory v OOP (GoF) z ktorych vacsina je v podstate len dosledkom chybajucich vlastnosti niektorych OO jazykov.
Návrhové vzory budou brzy i v FP
Vždy když si někdo myslí, že v FP objevil návrhový vzor, je to bez výjimky něco z teorie kategorií. Stačilo by sepsat něco o KT pro nadané vývojáře a máme "GoF".
A to je hlavní výhoda FP. Ale FP už přichází pozdě, do mainstreamu se nedostane, vstupujeme do postalgoritmické doby, kdy věci budou fungovat, aniž bychom věděli proč.
Překladače programových jazyků se dají používat i když nevíte jak fungují. Explicitní algoritmická znalost není potřebná. Tento stav v IT není ničím novým.
-
Jedním z důvodů postalgoritmické doby bude informační válka mezi mocnostmi, která právě probíhá. Francie, Rusko a Německo plánují vytvořit divize pro informační boj každý z nich o cca 10 000 mužů. V Německu už zahájili nábor do těchto jednotek, Rusové je už mají.
Natrénovaný stroj se hůře hackuje, protože zásah do natrénování se snadněji prozradí, buď je neúčinný a nebo funkce zkolabuje a tím je prozrazen, kdežto algoritmus upravíte snadno, aby dělal to co chcete vy a nikdo si toho nevšiml a to je vhodný stav pro informační válku.
-
Návrhové vzory budou brzy i v FP
No, vzory jsou všude a ve všem, o tom žádná. Ale třeba GoF OOP zrovna moc neprospělo. Jen se vyrojilo spousta vývojářů majících nabušených tyhlencty vzory a cpající je všude bez rozmyslu a konceptu.
Mám před očima jednoho kolegu, který (určitě v dobré víře) začal kůli formulářům přepisovat komplet HTML tagy do PHP, protože přece vzor Builder. Že by se to dalo i jinak a lépe, na to neměl čas řešit. Vzory zná, tak o čem chci diskutovat.
Dělám si naděje, že FP bude toho, alespoň trochu ušetřeno.
-
Návrhové vzory budou brzy i v FP
No, vzory jsou všude a ve všem, o tom žádná. Ale třeba GoF OOP zrovna moc neprospělo. Jen se vyrojilo spousta vývojářů majících nabušených tyhlencty vzory a cpající je všude bez rozmyslu a konceptu.
Aneb opět cargo cult programming
-
Jedním z důvodů postalgoritmické doby bude informační válka mezi mocnostmi, která právě probíhá. Francie, Rusko a Německo plánují vytvořit divize pro informační boj každý z nich o cca 10 000 mužů. V Německu už zahájili nábor do těchto jednotek, Rusové ...
Co ty zobeš?
-
Jedním z důvodů postalgoritmické doby bude informační válka mezi mocnostmi, která právě probíhá. Francie, Rusko a Německo plánují vytvořit divize pro informační boj každý z nich o cca 10 000 mužů. V Německu už zahájili nábor do těchto jednotek, Rusové ...
Co ty zobeš?
Informace.
http://www.denik.cz/z_domova/v-olomouci-bude-sidlit-specialni-komado-armady-nabor-zacina-20150515-sci4.html
http://www.armadninoviny.cz/rusko-vytvoreni-zvlastni-vojenske-jednotky-pro-informacni-operace.html
https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=12&ved=0ahUKEwj0nsPmoqDVAhWDsxQKHXpbCVo4ChAWCCowAQ&url=https%3A%2F%2Fis.cuni.cz%2Fwebapps%2Fzzp%2Fdownload%2F120064961&usg=AFQjCNHkqNYcxySVm-OQYJiFi7oWJ6Cagw
To jen z českých zdrojů ...
-
Jedním z důvodů postalgoritmické doby bude informační válka mezi mocnostmi, která právě probíhá. Francie, Rusko a Německo plánují vytvořit divize pro informační boj každý z nich o cca 10 000 mužů. V Německu už zahájili nábor do těchto jednotek, Rusové ...
Co ty zobeš?
Informace.
http://www.denik.cz/z_domova/v-olomouci-bude-sidlit-specialni-komado-armady-nabor-zacina-20150515-sci4.html
http://www.armadninoviny.cz/rusko-vytvoreni-zvlastni-vojenske-jednotky-pro-informacni-operace.html
https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=12&ved=0ahUKEwj0nsPmoqDVAhWDsxQKHXpbCVo4ChAWCCowAQ&url=https%3A%2F%2Fis.cuni.cz%2Fwebapps%2Fzzp%2Fdownload%2F120064961&usg=AFQjCNHkqNYcxySVm-OQYJiFi7oWJ6Cagw
To jen z českých zdrojů ...
Říkám jim - neber ty informace, neber ty informace, neber ty informace nebo se z toho zblázníš! A je to marný, je to marný... Je to marný!
-
Jedním z důvodů postalgoritmické doby bude informační válka mezi mocnostmi, která právě probíhá. Francie, Rusko a Německo plánují vytvořit divize pro informační boj každý z nich o cca 10 000 mužů. V Německu už zahájili nábor do těchto jednotek, Rusové ...
Co ty zobeš?
Informace.
http://www.denik.cz/z_domova/v-olomouci-bude-sidlit-specialni-komado-armady-nabor-zacina-20150515-sci4.html
http://www.armadninoviny.cz/rusko-vytvoreni-zvlastni-vojenske-jednotky-pro-informacni-operace.html
https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=12&ved=0ahUKEwj0nsPmoqDVAhWDsxQKHXpbCVo4ChAWCCowAQ&url=https%3A%2F%2Fis.cuni.cz%2Fwebapps%2Fzzp%2Fdownload%2F120064961&usg=AFQjCNHkqNYcxySVm-OQYJiFi7oWJ6Cagw
To jen z českých zdrojů ...
Říkám jim - neber ty informace, neber ty informace, neber ty informace nebo se z toho zblázníš! A je to marný, je to marný... Je to marný!
No informační válka nyní v posledních hodinách probíhá v Polsku. Je tam proti Polsku na internetu. Je používána metoda astroturfingu. https://cs.wikipedia.org/wiki/Astroturfing
Antipolská propaganda je patrná i v našich médiích. Proč asi. Čeho se kdo bojí? Na co je české veřejné mínění takto připravováno?
Další informace zde https://www.youtube.com/watch?v=vzhYj3Qj-PI
-
Jen připomínám právní stát je antidemokratický pojem pocházející z byzantské civilizace, která nadřazuje právo nad realitu, vůli byrokracie nad vůli občanů. Na rozdíl od latinské civilizace, kde prvotní není stanovené právo, ale etika.
Právní stát umožnil zavedení Norimberských zákonů do německého právního řádu a holocaust. Není to nic překvapivého, protože Německo má byzantský civilizační základ.
-
Návrhové vzory budou brzy i v FP
No, vzory jsou všude a ve všem, o tom žádná. Ale třeba GoF OOP zrovna moc neprospělo. Jen se vyrojilo spousta vývojářů majících nabušených tyhlencty vzory a cpající je všude bez rozmyslu a konceptu.
Aneb opět cargo cult programming
Nejvíc se kargo kult projevuje při používání frameworků. Když framework něco neumí, tak se čeká, až to bude umět.
Návrhové vzory jsou užitečné, pokud s nimi vývojář umí pracovat. Cpát třeba Singleton do míst, kam nepatří, je bohužel v módě. Když vidím chybně použitý Fly Weight, tak se z toho také docela osypávám.
-
Vždy když si někdo myslí, že v FP objevil návrhový vzor, je to bez výjimky něco z teorie kategorií. Stačilo by sepsat něco o KT pro nadané vývojáře a máme "GoF".
No a není to prostě jenom tak, že to jsou "vzory" prostě popsané matematicky, místo zoufalého opisu v "přirozeném" jazyce? Alespoň mně to tak přijde - celá myšlenka vzorů je vlastně analogická myšlence kategorií.
A to je, mimochodem, dobrý argument pro FP - protože všichni vidíme jak to s tím pokusem o nalezení vzorů mimo FP dopadlo. Ostatně, ani OOP nelze považovat za opravdu úspěšný experiment (z hlediska původních očekávání).
-
Vždy když si někdo myslí, že v FP objevil návrhový vzor, je to bez výjimky něco z teorie kategorií. Stačilo by sepsat něco o KT pro nadané vývojáře a máme "GoF".
No a není to prostě jenom tak, že to jsou "vzory" prostě popsané matematicky, místo zoufalého opisu v "přirozeném" jazyce? Alespoň mně to tak přijde - celá myšlenka vzorů je vlastně analogická myšlence kategorií.
A to je, mimochodem, dobrý argument pro FP - protože všichni vidíme jak to s tím pokusem o nalezení vzorů mimo FP dopadlo. Ostatně, ani OOP nelze považovat za opravdu úspěšný experiment (z hlediska původních očekávání).
Jak to dopadlo "s tím pokusem o nalezení vzorů mimo FP"? Vzory tady máme, jen se je mnozí vývojáři nenaučili správně používat. Podobně i ve FP mnozí vývojáři nezvládají KT, natož aby to uměli vysvětlit. Tato paradigmata si tedy nemají dohromady co vyčítat.
Pokud jsou návrhové vzory odvozeny z KT, jedná se o úspěšný experiment OOP.
-
Vždy když si někdo myslí, že v FP objevil návrhový vzor, je to bez výjimky něco z teorie kategorií. Stačilo by sepsat něco o KT pro nadané vývojáře a máme "GoF".
No a není to prostě jenom tak, že to jsou "vzory" prostě popsané matematicky, místo zoufalého opisu v "přirozeném" jazyce? Alespoň mně to tak přijde - celá myšlenka vzorů je vlastně analogická myšlence kategorií.
A to je, mimochodem, dobrý argument pro FP - protože všichni vidíme jak to s tím pokusem o nalezení vzorů mimo FP dopadlo. Ostatně, ani OOP nelze považovat za opravdu úspěšný experiment (z hlediska původních očekávání).
Jak to dopadlo "s tím pokusem o nalezení vzorů mimo FP"? Vzory tady máme, jen se je mnozí vývojáři nenaučili správně používat.
Ano, tak to dopadlo. Plus: kolik lidí si myslí že se mají návrhové vzory naučit aby je pak používali? Kolik lidí je považuje za nějakou formu "knihovny"? Už jenom to že se o tom vedou nějaké diskuse a polemiky je prostě fail u konceptu, který měl za cíl zlepšit mezilidskou komunikaci.
Podobně i ve FP mnozí vývojáři nezvládají KT, natož aby to uměli vysvětlit. Tato paradigmata si tedy nemají dohromady co vyčítat.
Myslím že to ještě nedokážeme říct. Sám si myslí že až bude FP mainstream, že to dopadne podobně tristně - ale to je jen jen můj osobní cynický pocit. Třeba to dopadne lépe :-)
Pokud jsou návrhové vzory odvozeny z KT, jedná se o úspěšný experiment OOP.
Tak tuhle větu bohužel nechápu. Jednak návrhové vzory rozhodně z KT odvozené nejsou, jednak nevidím tu spojitost jak by to validovalo výsledky široké adopce OOP.
-
Vždy když si někdo myslí, že v FP objevil návrhový vzor, je to bez výjimky něco z teorie kategorií. Stačilo by sepsat něco o KT pro nadané vývojáře a máme "GoF".
No a není to prostě jenom tak, že to jsou "vzory" prostě popsané matematicky, místo zoufalého opisu v "přirozeném" jazyce?
Jo, je to tak a je to tak dobře.
-
No, vzory jsou všude a ve všem, o tom žádná. Ale třeba GoF OOP zrovna moc neprospělo. Jen se vyrojilo spousta vývojářů majících nabušených tyhlencty vzory a cpající je všude bez rozmyslu a konceptu...
To jsem ještě nezažil. Zažil jsem opak, a to, že dotyční o vzorech buďto neslyšeli, nebo je považovali za akademickou kratochvíli, každopádně problémy řešili vynalézáním hranatého kola.
-
No, vzory jsou všude a ve všem, o tom žádná. Ale třeba GoF OOP zrovna moc neprospělo. Jen se vyrojilo spousta vývojářů majících nabušených tyhlencty vzory a cpající je všude bez rozmyslu a konceptu...
To jsem ještě nezažil. Zažil jsem opak, a to, že dotyční o vzorech buďto neslyšeli, nebo je považovali za akademickou kratochvíli, každopádně problémy řešili vynalézáním hranatého kola.
Návrhové vzory jsou naopak "kratochvílí" neakademiků, potažmo lopat. Perfektně to ve svých pracech vystihl Knuth.
-
Myslím že to ještě nedokážeme říct. Sám si myslí že až bude FP mainstream, že to dopadne podobně tristně - ale to je jen jen můj osobní cynický pocit. Třeba to dopadne lépe :-)
Samozřejmě, že to dopadne podobně. Problém totiž nespočívá v oněch paradigmatech, ale uživatelích.
-
... kolik lidí si myslí že se mají návrhové vzory naučit aby je pak používali? Kolik lidí je považuje za nějakou formu "knihovny"? Už jenom to že se o tom vedou nějaké diskuse a polemiky je prostě fail u konceptu, který měl za cíl zlepšit mezilidskou komunikaci.
Zpočátku jsem návrhové vzory odmítal právě proto, že mi byly prezentovány jako nějaká forma knihoven. Teprve později jsem samostudiem zjistil, že nejsou ničím, co by nám mělo házet klacky pod nohy, ale jsou myšlenkovou pomůckou, jak realizovat určité typy podúloh. Důležité jsou z tohoto pohledu i antivzory, které ukazují na nesprávné implementace.
-
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.
Problém je občas v tom, že překladači se musí holt trochu pomoci, čili vývojář musí vědět jak
V davnych casech, rikejme jim treba osmdesata nebo devadesata leta, byla spousta frajeru, kteri machrovali s tim, jak se co ma psat, aby prekladac vygeneroval nejrychlejsi kod. Pokud nekdo do programu napsal i++, hned byl tercem jejich posmechu, protoze kazdy vi, ze ++i je rychlejsi. Kdo pouzil nasobeni dvema byl za blbce, protoze prece bitovy posun je rychlejsi. Tohle byl hrozny mor, protoze misto toho, aby programator psal, CO se ma udelat, tak musi resit JAK se to ma udelat a kod byl neskutecna prasarna. Myslel jsem, ze tento druh odborniku uz davno vymrel, ale asi jich par jeste nekde preziva.
-
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.
-
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?
-
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.
-
Tohle byl hrozny mor, protoze misto toho, aby programator psal, CO se ma udelat, tak musi resit JAK se to ma udelat a kod byl neskutecna prasarna. Myslel jsem, ze tento druh odborniku uz davno vymrel, ale asi jich par jeste nekde preziva.
Nejen přežívá.
Jakej je to problém vysvětlit, že:
/** Vrátí součet dvou čísel
* @param Int a
* @param Int b
* @return Int
*/
Int sum(Int: a, Int b) {}
prostě není vůbec k ničemu dobrý. A tímhle:
/** Vezme první číslo a sečte ho s druhým
* @param Int firstNumeric
* @param Int secondNumeric
* @return Int
*/
Int sumTwoNumeric(Int: firstNumeric, Int secondNumeric) {}
to nevylepší.
-
/** Vrátí součet dvou čísel
* @param Int a
* @param Int b
* @return Int
*/
Int sum(Int: a, Int b) {}
Taková zvěrstva někdo skutečně píše?
-
To je hodně přiblblá analogie hodná trola.
Tvuj argument je snad jeste hloupejsi nez vykriky Ivana Noveho. Ze o necem existuje kniha, opravdu nic nedoklada.
-
To je hodně přiblblá analogie hodná trola.
Tvuj argument je snad jeste hloupejsi nez vykriky Ivana Noveho. Ze o necem existuje kniha, opravdu nic nedoklada.
To nepochybne. Na BookDepository si muze najit knihu o ledacems...
Ja osobne myslim, ze vic teorie se, jak uz to byva, hodi, ale obrovska cast praktickeho dopadu si u FP vystaci s naprostymi zaklady.
-
To je hodně přiblblá analogie hodná trola.
Tvuj argument je snad jeste hloupejsi nez vykriky Ivana Noveho. Ze o necem existuje kniha, opravdu nic nedoklada.
To nepochybne. Na BookDepository si muze najit knihu o ledacems...
Ja osobne myslim, ze vic teorie se, jak uz to byva, hodi, ale obrovska cast praktickeho dopadu si u FP vystaci s naprostymi zaklady.
no něco to určitě dokládá
-
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.
-
Že nechápeš souvislosti neznamená, že neexistují, jen že takové knihy nejsou pro tupé lopaty.
Kde nejsou argumenty, nastupuji urazky. Myslel jsem, ze frajer jako ty ma na vic.
Schvalne jsem ted sahl do policky pro tri nahodne vybrane knizky o funkcionalnim programovani On Lisp, PAIP a Compiling with Continuations, abych se podival, kolikrat se tam zminuje teorie kategorii. Cislo ti radsi ani nebudu rikat, mohl by se ti zhroutit cely tvuj svet.
-
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?
Křesťanství je v manželství velice důležité, proto je taky u nás 50% rozvodů.
-
Křesťanství je v manželství velice důležité, proto je taky u nás 50% rozvodů.
To si nevybereš, zbývajících 50 % manželství končí smrtí.
-
Křesťanství je v manželství velice důležité, proto je taky u nás 50% rozvodů.
To si nevybereš, zbývajících 50 % manželství končí smrtí.
Po šedesáti letech společné cesty.
-
Křesťanství je v manželství velice důležité, proto je taky u nás 50% rozvodů.
Hele, já sice s tebou (v tomhle a pokud jsem tě dobře pochopil) naprosto souhlasím, jenže byť je to velice důležité a užitečné téma, a člověk toho může bejt plnej... tak s Funkcionálním programováním to fakt nesouvisí. Nedělej prosímtě křesťanství medvědí službu, a necpi to sem.
-
[Schvalne jsem ted sahl do policky pro tri nahodne vybrane knizky o funkcionalnim programovani On Lisp, PAIP a Compiling with Continuations, abych se podival, kolikrat se tam zminuje teorie kategorii. Cislo ti radsi ani nebudu rikat, mohl by se ti zhroutit cely tvuj svet.
Teorie kategorií je jako bible pro funkcionální programátory. Málokdo jí rozumí, ale všichni ji prezentují jako dar z nebes.
-
Že nechápeš souvislosti neznamená, že neexistují, jen že takové knihy nejsou pro tupé lopaty.
Kde nejsou argumenty, nastupuji urazky. Myslel jsem, ze frajer jako ty ma na vic.
Schvalne jsem ted sahl do policky pro tri nahodne vybrane knizky o funkcionalnim programovani On Lisp, PAIP a Compiling with Continuations, abych se podival, kolikrat se tam zminuje teorie kategorii. Cislo ti radsi ani nebudu rikat, mohl by se ti zhroutit cely tvuj svet.
(někdy uetoyo)
:D ... +1
FP je pro blbce ... třeba jako já ... konečně to po mě někdo přečte a funguje to. Vůbec nevím, kde ten pan zboj chodí na ty rozumy, že FP je něco pro kouzelníky. (BTW Milewskiho čtu, ale pro praktické věci doporučím číst fsharpforfunandprofit)
-
Křesťanství je v manželství velice důležité, proto je taky u nás 50% rozvodů.
prosim?
-
Křesťanství je v manželství velice důležité, proto je taky u nás 50% rozvodů.
prosim?
Je velmi důležité, proč myslíte, že dřívější generace vydržely spolu až do smrti. Protože měli pro společný život i mravní základ daný křesťanstvím, tedy Biblí, což dnes mnoha lidem chybí a jdou jen za vlastní slastí, jsou de facto demoralizovaní. A jsou demoralizovaní cíleně, neomarxistickou propagandou, že cílem každého lidského života je vlastní štěstí a vlastním štěstím lze omluvit cokoliv. Podobně argumentovali komunisti za normalizace, když lámali charaktery lidí.
-
Je velmi důležité, proč myslíte, že dřívější generace vydržely spolu až do smrti. Protože měli pro společný život i mravní základ daný křesťanstvím, tedy Biblí, což dnes mnoha lidem chybí a jdou jen za vlastní slastí, jsou de facto demoralizovaní. A jsou demoralizovaní cíleně, neomarxistickou propagandou, že cílem každého lidského života je vlastní štěstí a vlastním štěstím lze omluvit cokoliv. Podobně argumentovali komunisti za normalizace, když lámali charaktery lidí.
Snažíš se vlámat do otevřených dveří. Většina z nás s tebou souhlasí, jen o tom nechtějí tady polemizovat. A pak je tu pár jedinců, kteří s tebou nesouhlasí a budou tě neustále trolit.
Funkcionální programování jsem si zatím vyzkoušel v Lispu a Haskellu. V PHP je FP sice omezené, ale na většinu úloh mi to stačí. Co třeba tabulkové kalkulátory? Považujete vyplňování kolonek za FP?
-
dobrá kniha o FP bez akedemického bullshitu je Higher Order Perl
http://hop.perl.plover.com/book/pdf/HigherOrderPerl.pdf
-
Snažíš se vlámat do otevřených dveří. Většina z nás s tebou souhlasí, jen o tom nechtějí tady polemizovat.
Máš nějaký konkrétní data která by to potvrzovala, nebo jsi jen samozvaný mluvčí "většiny"? Předpokládám že (minimálně v případě biblického fanclubu) platí B, takže si to prosím nech od cesty.
Funkcionální programování jsem si zatím vyzkoušel v Lispu a Haskellu. V PHP je FP sice omezené, ale na většinu úloh mi to stačí. Co třeba tabulkové kalkulátory? Považujete vyplňování kolonek za FP?
To je dobrá připomínka - mnoho programátorů nemá tušení o tom co to FP vůbec je. Je to vidět v případě Javy, kde někteří začali místo metod deklarovat statické fieldy typu Function (s lambdou), všechny if/else přepsali na Optional.ofNull.elseGet a myslí si že programují funkcionálně.
Zjednodušená verze pro "dělníky" (akademici snad omluví): používání funkcí není funkcionální programování; to začíná až tehdy, když se funkce předávají jako argumenty a vrací jako návratové hodnoty.
Tabulkový kalkulátor tedy rozhodně FP není, ani náhodou (dokonce to IMHO ani není možné, ale nejsem expert).
-
Zjednodušená verze pro "dělníky" (akademici snad omluví): používání funkcí není funkcionální programování; to začíná až tehdy, když se funkce předávají jako argumenty a vrací jako návratové hodnoty.
Tohle zjednodušení "pro dělníky" vypadá velmi srozmitelně.
Zkusím to parafrázovat na OOP: Používání objektů není objektovým programováním; to začíná až tehdy, když se objekty předávají jako argumenty a vrací jako návratové hodnoty.
-
Funkcionální programování jsem si zatím vyzkoušel v Lispu a Haskellu. V PHP je FP sice omezené, ale na většinu úloh mi to stačí. Co třeba tabulkové kalkulátory? Považujete vyplňování kolonek za FP?
To je dobrá připomínka - mnoho programátorů nemá tušení o tom co to FP vůbec je. Je to vidět v případě Javy, kde někteří začali místo metod deklarovat statické fieldy typu Function (s lambdou), všechny if/else přepsali na Optional.ofNull.elseGet a myslí si že programují funkcionálně.
Zjednodušená verze pro "dělníky" (akademici snad omluví): používání funkcí není funkcionální programování; to začíná až tehdy, když se funkce předávají jako argumenty a vrací jako návratové hodnoty.
Tabulkový kalkulátor tedy rozhodně FP není, ani náhodou (dokonce to IMHO ani není možné, ale nejsem expert).
(matematici prominou)
IMHO je funkcionální programování pojmenované podle matematické funkce, což je zařízení, které transformuje jednu hodnotu na hodnotu novou, přičemž stejná vstupní hodnota je vždy transformována na stejnou výstupní, překladač by třeba transformoval řetězec na seznam instrukcí (compile :: String -> [Z80Instruction]) a tímto pohledem by se spreadsheet mohl jevit jako nástroj pro funkcionální programování
-
Funkcionální programování jsem si zatím vyzkoušel v Lispu a Haskellu. V PHP je FP sice omezené, ale na většinu úloh mi to stačí. Co třeba tabulkové kalkulátory? Považujete vyplňování kolonek za FP?
To je dobrá připomínka - mnoho programátorů nemá tušení o tom co to FP vůbec je. Je to vidět v případě Javy, kde někteří začali místo metod deklarovat statické fieldy typu Function (s lambdou), všechny if/else přepsali na Optional.ofNull.elseGet a myslí si že programují funkcionálně.
Zjednodušená verze pro "dělníky" (akademici snad omluví): používání funkcí není funkcionální programování; to začíná až tehdy, když se funkce předávají jako argumenty a vrací jako návratové hodnoty.
Tabulkový kalkulátor tedy rozhodně FP není, ani náhodou (dokonce to IMHO ani není možné, ale nejsem expert).
(matematici prominou)
IMHO je funkcionální programování pojmenované podle matematické funkce, což je zařízení, které transformuje jednu hodnotu na hodnotu novou, přičemž stejná vstupní hodnota je vždy transformována na stejnou výstupní, překladač by třeba transformoval řetězec na seznam instrukcí (compile :: String -> [Z80Instruction]) a tímto pohledem by se spreadsheet mohl jevit jako nástroj pro funkcionální programování
Taky bych rekl, ze hlavni vlastnosti FP je pouzivani funkci v matematickem smyslu, nikoli pouzivani funkci vyssiho radu; to druhe ma ostatne i OOP (delegaty a dalsi vzory) a klasicke strukturovane programovani (odkaz na funkci).
-
Taky bych rekl, ze hlavni vlastnosti FP je pouzivani funkci v matematickem smyslu, nikoli pouzivani funkci vyssiho radu; to druhe ma ostatne i OOP (delegaty a dalsi vzory) a klasicke strukturovane programovani (odkaz na funkci).
dost důležité jsou lexikální uzávěry a lambda funkce. V čistě imperativních jazycích jako c jen obtížně implementujete líné vyhodnocování, nekonečné posloupnost apod.
-
Taky bych rekl, ze hlavni vlastnosti FP je pouzivani funkci v matematickem smyslu, nikoli pouzivani funkci vyssiho radu; to druhe ma ostatne i OOP (delegaty a dalsi vzory) a klasicke strukturovane programovani (odkaz na funkci).
Právě že klasické procedurální, strukturované programování odpovídá té definici "používání funkcí" (stačí jen nepoužívat vedlejší efekty), ale funkce vyššího řádu tam naopak nevyskytuje (odkaz na funkci je hezký jako callback, ale velmi těžko se transformuje a skládá). Objekty samozřejmě umožňují implementovat totéž co funkce vyššího řádu, ale člověk musí zapomenout na ten základní koncept že OOP = modelování reálných entit (troufám si říci, že tohle napáchalo škody srovnatelné s NULL a Excelem).
Ono to samozřejmě spolu souvisí - pokud se budu snažit programovat procedurálně bez vedlejších efektů, tak velmi brzo narazím na to že se mi neustále opakuje podobný kód. Tradičním řešením je (když pominu "copy&paste") generátor kódu, pak se do módy dostalo imperativní OOP.
PS: Koukám - lexikální uzávěry a lambda funkce... no to jsou určitě užitečné věci, ale dá se obejít i bez nich.
-
PS: Koukám - lexikální uzávěry a lambda funkce... no to jsou určitě užitečné věci, ale dá se obejít i bez nich.
lexikální uzávěry mohou nahradit mutabilitu. Nekonečnou sekvenci můžete implementovat objektem držícím stav, nebo vracením lambda funkcí.
-
PS: Koukám - lexikální uzávěry a lambda funkce... no to jsou určitě užitečné věci, ale dá se obejít i bez nich.
lexikální uzávěry mohou nahradit mutabilitu. Nekonečnou sekvenci můžete implementovat objektem držícím stav, nebo vracením lambda funkcí.
Obojí se dá velmi snadno implementovat i v OO jazycích a používám to zcela běžně.
Často je výhodné dělat objekty immutable, lépe se s nimi pracuje.
-
Obojí se dá velmi snadno implementovat i v OO jazycích a používám to zcela běžně.
Často je výhodné dělat objekty immutable, lépe se s nimi pracuje.
ano, můžete si implementovat něco jako uzávěr ručně.
-
[Schvalne jsem ted sahl do policky pro tri nahodne vybrane knizky o funkcionalnim programovani On Lisp, PAIP a Compiling with Continuations, abych se podival, kolikrat se tam zminuje teorie kategorii. Cislo ti radsi ani nebudu rikat, mohl by se ti zhroutit cely tvuj svet.
Teorie kategorií je jako bible pro funkcionální programátory. Málokdo jí rozumí, ale všichni ji prezentují jako dar z nebes.
Důležitá je ovšem ta hrstka, která tomu opravdu rozumí (a posouvá obor dál).
-
Taky bych rekl, ze hlavni vlastnosti FP je pouzivani funkci v matematickem smyslu, nikoli pouzivani funkci vyssiho radu; to druhe ma ostatne i OOP (delegaty a dalsi vzory) a klasicke strukturovane programovani (odkaz na funkci).
dost důležité jsou lexikální uzávěry a lambda funkce. V čistě imperativních jazycích jako c jen obtížně implementujete líné vyhodnocování, nekonečné posloupnost apod.
V OOP jsou nahrazeny objekty, takže zas tak nepostradatelné nejsou.