Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
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.
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.
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 datAneb 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?
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.
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".
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ů.
Funkce jsou ve FP přece také konstanty.No a to jsme přesně u těch pitomých generalizací. Co má znamenat, že "funkce je konstanta"? A co z toho má plynout?
Pochopitelné je hlavně to, že i v tak krátkém programu se dá udělat chyba....zatímco v ne-FP programu se chyba udělat nedá. Potvrzuje NaN programátorů z "5"ti.
Pointa je v tom, že kdybych se držel jen těch dvou zmíněných bodů a nevyužíval doplňujících featur, tak nic kloudného nenaprogramujiOpakuji: Erlang z těch "doplňujících featur" má dvě - nepodstatné, které sílu jazyka výrazně nemění.
a ani nemám šanci pochopit, co napsal jiný programátor. Navíc syntaxe, která je velmi odlišná od strukturovaných jazyků, to chápání cizího programu ještě zhoršuje.Fakt?
defmodule Greeter do
def hello(name) do
"Hello, " <> name
end
end
iex> Greeter.hello("Sean")
"Hello, Sean"
)Tím chci sdělit, že znalost matematiky pro úspěšné programování ve fukcionálních jazycích je podmínkou nutnou, nikoli však postačující.Není o nic nutnější než u C nebo Pythonu.
V tom se mýlíš. Do konstruktoru takového konstantního objektu můžeš injektovat různé závislosti a jako celek se to pak chová funkcionálně podle toho, jak to celé sestavíš. Výstup je pak funkcí vstupu.Konstanta je od toho, že je konstantní, tj. po dobu svého života se nemění. A je úplně jedno, jak ji vytvořím.
const x = muj_skvely_konstruktor(moje_jeste,lepsi,parametry)
Například v tom není ani zmínka o monádách, výjimkách, namespacech, curryfikaci, strážích a dalších vymoženostech, kterými funkcionální jazyky oplývají.A co má být? Různé jazyky mají různé featury. Pořád nějak nechápu pointu.
Jsem rád že se mnou souhlasíš, ale mnoho vývojářů se tím vůbec neřídí a naopak tvrdí, že takový objekt nedává smysl.No je to prostě konstanta, čili nic světoborného. OOP stylem pomocí samých konstant nic rozumně nenaprogramuješ. FP stylem ano. V tom je ten rozdíl.
Imutabilní data se dají bez problémů používat i v OOPCož všichni víme a nikdo netvrdil opak, takže úplně nedává smysl to konstatovat
to na skutečné FP zjevně nestačí.Z čeho je to zjevné?
ale když je název funkce na půl řádku, tak je to prostě opruz. Kdo má takovou hatmatilku číst?Vůbec nevím, co myslíš. Jaké názvy na půl řádku? Proč? Kde?
Spolupracoval jsem nedávno na jednom projektu v ElixiruSkvěle!
V ČR?, ale např. pro embedded věci, což je má doména, je nechutně náročný a tedy naprosto nevhodný.Na takové použití nikdy nebyl zamýšlen, takže to je jako konstatovat, že kancelářský papír se nehodí na šití balónů
A i tak pozoruji, že to funkcionální paradigma není lidem úplně přirozenéJá bych nemluvil o "paradigmatu", ale o konkrétním jazyku. Pod "FP paradigma" si může představit kdo chce co chce a důsledky můžou být jakékoliv. Bavit se dá o konkrétních příkladech, proč třeba někomu nevyhovoval Elixir pro nějaké konkrétní použití. Pak to je smysluplná debata a dá se dojít ke konsensu (jako třeba u těch embedded/constrained zařízení, kde mezi náma není sporu).
, skoro bych řekl, že tak jak většina lidí (bohužel dnes i většina těch počítačových) válčí s matematikou, tak válčí i s FP.Já třeba osobně v FP nevidím tolik matematiku, jako spíš (matematickou) logiku nebo klidně i (jazykovědnou) sémantiku - u každého kusu kódu se ptám otázky typu "co je jeho účelem?", "co zná?", "co potřebuje znát?" apod.
Jenže to funkcionální paradigma navíc není úplně přirozené ani tomu železuTo je nezpochybnitelná pravda. Na to bych ti řekl, že se nechci přizpůsobovat tomu, jak myslí stroj, chci, aby stroj pochopil, jak myslím já
(neber pls doslovně - já mám taky nějakou zkušenost s embedded a přímočarost a lowlevelovitost Cčka umím taky ocenit a užít si, ne že ne)
ale co modeluje obecná relativita nelze postihnout newtonovým modelemNo ale je potřeba si uvědomit jednu věc: kdekoli-kdykoli-kýmkoli-měnitelná data jsou takový problém, že se typicky v globálním měřítku ani v ne-FP programech nepoužívají, protože to je prostě neúnosné (~ nelze postihnout Newtonovým modelem).
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.