Programovanie a modne trendy?

[Mirek Prýmek]

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.

[Reklama]

[Kit]

to na skutečné FP zjevně nestačí.

Z čeho je to zjevné?

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í.

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.

[Mirek Prýmek]

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.

Z toho, cos napsal, má třeba Erlang jenom výjímky a stráže, což ani jedno není nijak FP-specifické a kdyby to Erlang neměl, vůbec nic by se nestalo, jenom by se v tom některé věci psaly trochu ukecaněji.

[Kit]

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.

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.

[JSH]

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.

[Reklama]

[Mirek Prýmek]

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.

Kód: [Vybrat]

const x = muj_skvely_konstruktor(moje_jeste,lepsi,parametry)
je u mě pořád konstanta. Jestli u tebe ne, hádat se o to nebudu, je mi to jedno, jak tomu cheš říkat, OOP stylem se samými takovými objekty stejně nic nenaprogramuješ. Jenom budeš (špatně a zbytečně krkolomně) imitovat funkcionální styl.

[Kit]

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.

Z toho, cos napsal, má třeba Erlang jenom výjímky a stráže, což ani jedno není nijak FP-specifické a kdyby to Erlang neměl, vůbec nic by se nestalo, jenom by se v tom některé věci psaly trochu ukecaněji.

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 nenaprogramuji 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.

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í.

[Kit]

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.

Kód: [Vybrat]

const x = muj_skvely_konstruktor(moje_jeste,lepsi,parametry)
je u mě pořád konstanta. Jestli u tebe ne, hádat se o to nebudu, je mi to jedno, jak tomu cheš říkat, OOP stylem se samými takovými objekty stejně nic nenaprogramuješ. Jenom budeš (špatně a zbytečně krkolomně) imitovat funkcionální styl.

Funkce jsou ve FP přece také konstanty.

[Mirek Prýmek]

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 nenaprogramuji

Opakuji: 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?

Kód: [Vybrat]

defmodule Greeter do
  def hello(name) do
    "Hello, " <> name
  end
end

iex> Greeter.hello("Sean")
"Hello, Sean"

Zcela nepochopitelné! )

Prosímtě, ujasni si, jestli mluvíš o FP nebo o Haskellu. Navíc mluvit obecně o FP je samo o sobě dost vošajstlich, protože ty jazyy z téhle rodiny jsou tak odlišné, že společně pro ně neplatí skoro nic. Ani ty dvě věty, co tě tak rozlítily

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.

[Kit]

Kód: [Vybrat]

defmodule Greeter do
  def hello(name) do
    "Hello, " <> name
  end
end

iex> Greeter.hello("Sean")
"Hello, Sean"

Zcela nepochopitelné! )

Pochopitelné je hlavně to, že i v tak krátkém programu se dá udělat chyba. A co kdyby byl jen o trochu složitější, to by bylo!

[Mirek Prýmek]

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?

V Erlangu můžu kód hotreloadovat, takže při prvním zavolání fce se mi spustí nějaký kód a při druhém nějaký úplně jiný. Je pak ta fce konstanta? Já nevím. A opět: je mi to celkem jedno

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.

Sorry jako, na tenhle dadaismus už nějak nemám náladu, měj se

[n]

1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní

Zajímavé je, že jsem s proměnnými daty a s procedurami s vedlejšími efekty nikdy žádné zásadní problémy neměl ani v imperativně-procedurálním paradigmatu.
Když čtu o výhodách těchto věcí, tak mi to připomíná telefonické nabídky různých speciálních matrací a postelí, které mají tu výhodu, že člověk na nich spí jako nemluvně a ráno ho nebolej záda. Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.

Tovis, super-hrnce rulez!
Ja naopak nechapu, jak si muze rikat programator nekdo, kdo je ochoten obetovat tolik efektivity, kvuli nejake "cistote" a pouzivat immutable objekty, a zbytecne vecne nekde neco kopirovat -> kdyz vetsina funkcionalnich jazyku je vzor plytvani..
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). Ma to spoustu praktickych implikaci, ale ve zjednodusenemem svete(cimz myslim, zjednoduseny svet modelovany softwarem, kde ZATIM (nepotrebujeme/a ani neumime) modelovat vsechny detaily), si zatim muzem tuto "ochcavku" dovolit a usetri nam to spoustu prace(energie)(kterou dela kompl). Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?

[Mirek Prýmek]

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?

[Kit]

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?

Plyne z toho, že funkce pro stejné vstupní parametry dává stejné výstupy. Tedy chová se stejně jako metody v mých immutable objektech, u kterých chování nastavuji konstruktorem a pak už ten objekt neměním.

[gll]

1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní

Zajímavé je, že jsem s proměnnými daty a s procedurami s vedlejšími efekty nikdy žádné zásadní problémy neměl ani v imperativně-procedurálním paradigmatu.
Když čtu o výhodách těchto věcí, tak mi to připomíná telefonické nabídky různých speciálních matrací a postelí, které mají tu výhodu, že člověk na nich spí jako nemluvně a ráno ho nebolej záda. Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.

Tovis, super-hrnce rulez!
Ja naopak nechapu, jak si muze rikat programator nekdo, kdo je ochoten obetovat tolik efektivity, kvuli nejake "cistote" a pouzivat immutable objekty, a zbytecne vecne nekde neco kopirovat -> kdyz vetsina funkcionalnich jazyku je vzor plytvani..
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). Ma to spoustu praktickych implikaci, ale ve zjednodusenemem svete(cimz myslim, zjednoduseny svet modelovany softwarem, kde ZATIM (nepotrebujeme/a ani neumime) modelovat vsechny detaily), si zatim muzem tuto "ochcavku" dovolit a usetri nam to spoustu prace(energie)(kterou dela kompl). Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?

S tou posedlostí paradigmaty máte úplnou pravdu. Je to stejně hloupé jako posedlost mikrooptimalizacemi, zde na rootu také častá.

Nemáte pravdu s tím kopírováním. Moderní FP jazyky mají tzv. perzistentní datové struktury.