Programovanie a modne trendy?

[Kit]

Dnešním módním trendem je funkcionální programování včetně teorie kategorií. Čím méně srozumitelně podané, tím víc cool.

FP je koncepčně jednoduché, že vychází z matematiky je obecně výhoda, když člověk není totální pako i na trojčlenku.

Ano, tohle je ta obvyklá cool věta, která se říká začátečníkům, aby věděli totéž, co předtím. Nenese totiž žádnou informaci o FP.

[Reklama]

[Mirek Prýmek]

Ano, tohle je ta obvyklá cool věta, která se říká začátečníkům, aby věděli totéž, co předtím. Nenese totiž žádnou informaci o FP.

Ne, pokud člověk není pitomec, který si potřebuje honit triko, tak začátečníkům říká, že v FP:

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

...přičemž tohle ideálně platí absolutně, zatímco u reálných jazyků je to naplněno různou měrou.

Pokud je záhodno to začátečníkovi říct ještě polopatičtěji, použije se analogie s výrobní linkou: program v FP je taková továrna, ve které jsou za sebou poskládané různé stroje - do každého něco pásem jede a něco jiného z něj vypadne.

Zavadzanie FP paradigmy do imperativnych OOP jazykov mi preto pripada ako ked v cestine a slovencine silou mocou uplatnujete japonsky slovosled s prisudkom vzdy a len na konci vety.

S tím se celkem dá souhlasit - pokud se zavádí FP prvky jenom proto, aby tam byly, a nemá to žádný pořádný přínos (například proto, že ostatní rysy jazyka ten kýžený efekt zabijí), je to trochu křeč.

ale vacsina jazykoveho spolocenstva v tom nevidi benefit, ked zhruba to iste ide aj po starom so sideeffectami.

A s tímhle už se souhlasit nedá. FP prvky se nezavádí proto, že by pomocí FP šlo udělat něco, co v OOP nejde, ale proto, že FP programovací styl (!!!!) často vede ke kódu, který dokáže člověk líp pojmout, přemýšlet o něm a dělat o něm závěry ("reason about"), což je samo o sobě velký přínos např. pro spolehlivost (viz Elm vs. JS).

Dají se popsat konkrétní důvody, proč je FP v tomhle vhodnější - jeden z nich např. je, že interakce jsou ("vynuceně") lokální - z principu se nemůže stát, že někde držím nějaká data a kód na úplně druhé straně planety mi je změní pod rukama - tahle eventualita prostě neexistuje, proto s ní nemusím počítat (u OOP musím) a mám přemýšlení o poznání jednodušší.

Imutabilní data jsou podle mě (a nikomu to necpu) silnější nástroj než funkce bez sideefectů. Pokud mám jazyk se striktně imutabilními daty, tak mi to přemýšlení nad kódem dramaticky zjednodušší. Pokud mám jazyk bez sideefectů, tak mi to sice pomůže taky, ale zároveň to přinese obrovské množství problémů při řešení praktických věcí, takže ve finále musím přemýšlet zase hodně

[Aoidhghean]

Dnešním módním trendem je funkcionální programování včetně teorie kategorií. Čím méně srozumitelně podané, tím víc cool.

FP je koncepčně jednoduché, že vychází z matematiky je obecně výhoda, když člověk není totální pako i na trojčlenku.

Ano, tohle je ta obvyklá cool věta, která se říká začátečníkům, aby věděli totéž, co předtím. Nenese totiž žádnou informaci o FP.

Tak jasně, pokud někdo považuje PHP za etalon použitelného jazyka, tak výhodu FP neuvidí nikdy.

[Kiwi]

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

[Mirek Prýmek]

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

To je velice dobrá analogie. Když si totiž koupíš pořádnou matraci, tak na té "obyčejné" už se nevyspíš. Neboli, jak říká klasik: "Která jednou zkusí, už nechce jinak".

Nemám žádný důvod tě přesvědčovat, programuj si v čem a jak chceš, je to tvůj život

[Reklama]

[Aoidhghean]

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

Možná tu výhodu nevidíte, protože jste se nikdy nedostal v psaní kódu k těm oblastem, kde odlišnost FP hraje roli, což jsou typicky paralelní výpočty. Je to jako tvrdit, že obecná teorie relativity nic nepřináší, protože Newtonova koncepce funguje úplně stejně dobře. Ono to je pravda, ale jen za určitých podmínek, jak sám víte. Po překročení Rubikonu ovšem rozdíl mezi nimi bije do očí.

[v]

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

Možná tu výhodu nevidíte, protože jste se nikdy nedostal v psaní kódu k těm oblastem, kde odlišnost FP hraje roli, což jsou typicky paralelní výpočty. Je to jako tvrdit, že obecná teorie relativity nic nepřináší, protože Newtonova koncepce funguje úplně stejně dobře. Ono to je pravda, ale jen za určitých podmínek, jak sám víte. Po překročení Rubikonu ovšem rozdíl mezi nimi bije do očí.

nemám rád analogie a ty zatím uvedené mi přijdou fakt blbé, zkuste třeba původní a moderní formulaci maxwellových rovnic

[Aoidhghean]

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

Možná tu výhodu nevidíte, protože jste se nikdy nedostal v psaní kódu k těm oblastem, kde odlišnost FP hraje roli, což jsou typicky paralelní výpočty. Je to jako tvrdit, že obecná teorie relativity nic nepřináší, protože Newtonova koncepce funguje úplně stejně dobře. Ono to je pravda, ale jen za určitých podmínek, jak sám víte. Po překročení Rubikonu ovšem rozdíl mezi nimi bije do očí.

nemám rád analogie a ty zatím uvedené mi přijdou fakt blbé, zkuste třeba původní a moderní formulaci maxwellových rovnic

Ono i pochopení analogie vyžaduje určitou úroveň znalostí v dané oblasti. Někomu analogie pomůže, a pokud to nedocvakne, doporučuju mlčet.

[v]

Ono i pochopení analogie vyžaduje určitou úroveň znalostí v dané oblasti. Někomu analogie pomůže, a pokud to nedocvakne, doporučuju mlčet.

tak ta vaše:
ve funkcionálním jazyce i v imperativním lze implementovat stejný program, pro stejné vstupy vyprodukují stejné výstupy (bo jsou to typicky turingovsky ekvivalentní jazyky a takové ty věci), ale co modeluje obecná relativita nelze postihnout newtonovým modelem

[Aoidhghean]

ve funkcionálním jazyce i v imperativním lze implementovat stejný program, pro stejné vstupy vyprodukují stejné výstupy (bo jsou to typicky turingovsky ekvivalentní jazyky a takové ty věci), ale co modeluje obecná relativita nelze postihnout newtonovým modelem

  Jenže ten turingovský základ odpovídá matematickému základu, jenž je stejný pro všechny teorie. V programování sice v Javě a spol. můžu implementovat cokoliv vyčíslitelného, ovšem stěžejní je to, že méně elegantně, protože má například slabý typový systém. To samé v Haskellu bude kratší a čitelnější, protože některé věci lze explicitně vyjádřit. Nicméně asi stačí zůstat u toho snadnějšího “reasoning about”, protože to je z praxe a tedy snáze uchopitelné.

FP je v současnosti typický buzzword, což některé popuzuje, jenže v této fázi bylo i OOP. Každý nechť si přebere, je-li FP pro něj.

[Mirek Prýmek]

ale co modeluje obecná relativita nelze postihnout newtonovým modelem

No 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).

Šermování turingovskou kompletností je sice hezký, ale je to klasický "v teorii je to pravda, v praxi ne", sloužící jenom k tomu, aby někdo někoho mlátil Turingem po hlavě. C++ templaty jsou údajně taky Turingovsky kompletní (údajně "náhodou", "omylem") a přesto by asi nikdo nebyl schopný v nich napsat třeba Windows nebo Word. Teoreticky to jde, prakticky je to nerealizovatelné, protože to prostě žádný smrtelník nedá.

Takže zpátky k tématu: kdekoli-kdykoli-kýmkoli-měnitelná data by v jakémkoli větším systému žádný smrtelník nedal, proto se vytváří různé bariéry (moduly, subsystémy apod.), které komunikují pomocí nějakého API. A na téhle úrovni je to co? No přece úplně to samý jako erlangovské procesy, které komunikují pomocí zpráv. Aha? Takže i v "normálním", "ne-FP" programování se používá přesně ten samý princip, akorát na jiné úrovni, v jiném měřítku. Čili machrování "nikdy jsem to nepotřeboval" je poněkud mimo mísu. Potřeboval. Akorát jsem o tom nevěděl

[Kiwi]

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

To je velice dobrá analogie. Když si totiž koupíš pořádnou matraci, tak na té "obyčejné" už se nevyspíš. Neboli, jak říká klasik: "Která jednou zkusí, už nechce jinak".

Nemám žádný důvod tě přesvědčovat, programuj si v čem a jak chceš, je to tvůj život

Tak ještě od školních let se orientuji v LISPu a mám ho dost rád, vlastně jsem se ho učil na svém vlastním překladači (IMHO skvělý námět pro různé semestrální projekty, protože je celkem jednoduchý a člověk si procvičí vedle LISPu i další věci).
Spolupracoval jsem nedávno na jednom projektu v Elixiru, ale např. pro embedded věci, což je má doména, je nechutně náročný a tedy naprosto nevhodný. A i tak pozoruji, že to funkcionální paradigma není lidem úplně přirozené, 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. Jenže to funkcionální paradigma navíc není úplně přirozené ani tomu železu, na němž má takový program běžet, takže program sice vypadá elegantně, ale jeho efektivita bývá dost mizerná.
Už jsem v životě zažil OOP hype, FP hype, ale stále mám pocit, že klasické strukturované paradigma je nejlepší kompromis mezi stravitelností pro člověka a pro počítač.

Možná tu výhodu nevidíte, protože jste se nikdy nedostal v psaní kódu k těm oblastem, kde odlišnost FP hraje roli, což jsou typicky paralelní výpočty. Je to jako tvrdit, že obecná teorie relativity nic nepřináší, protože Newtonova koncepce funguje úplně stejně dobře. Ono to je pravda, ale jen za určitých podmínek, jak sám víte. Po překročení Rubikonu ovšem rozdíl mezi nimi bije do očí.

No, pokud budu provádět výpočty nerelativistických jevů, tak je opravdu hloupost nasazovat na to nástroje TR. Ona to může být hloupost i tehdy, pokud relativistické jevy roli izolovaně hrají - viz např. elektromagnetismus.
K paralelním výpočtům jsem se dostal naposledy na VŠ při řešení PDE. Dělali jsme to tenkrát ve Fortranu 90 a popravdě, při vědomí, jak výpočetně neefektivní FP jazyky jsou, by mě asi nenapadlo je k těmto účelům použít. Čekat na výsledek týden nebo měsíc je přeci jen rozdíl.  I v tom Fortranu se tehdy špekulovalo nad tím, jak ty matice vůbec organizovat, aby se narvaly do paměti jednotlivých jednotek a minimalizovala potřeba rozsáhlých datových přesunů uvnitř nebo dokonce mezi jednotkami. Docela se obávám, že funkcionální jazyk by mi z tohoto hlediska naházel do cesty tolik klacků, že by se z toho na daném HW stal neřešitelný problém.

[v]

... pozoruji, že to funkcionální paradigma není lidem úplně přirozené, 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. Jenže to funkcionální paradigma navíc není úplně přirozené ani tomu železu, na němž má takový program běžet, takže program sice vypadá elegantně, ale jeho efektivita bývá dost mizerná.

železu, některým lidem a řešeným problémům přirozené není, ale pokud se sejde vhodný problém a vhodní lidi tak je to pecka (z mé zkušenosti jde o haskell s jeho výborným typovým systémem, monádama a pattern matching-em, a příkladem problémů překladače a komunikační protokoly (když to není hard rt))

[Mirek Prýmek]

Spolupracoval jsem nedávno na jednom projektu v Elixiru

Skvě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).

A za druhé bych se taky podíval na to, komu to nevyhovuje. Jestli někdo deset let programoval OOP, tak má samozřejmě OOP modelování zažrané do mozku a FP modelování buď neumí vůbec, nebo je to pro něj bolehlav. To ale není vlastnost FP modelování, to je vlastnost toho člověka.

Mně osobně například přijde daleko přirozenější uvažovat nad tím, že když do mlínku na maso vrazím maso, tak z něj vypadne mletý maso, než uvažovat nad tím, jestli obecný čtverec je víc obecný pojem než obecný obdélník nebo naopak

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

Že je FP založené na matematice je taková polopravda - striktně vzato je to pravda a je to dobře, protože chytré hlavy pak můžou o FP programu (nebo jazyku) leccos zajímavého dokázat. Ale mně jako uživateli to může být celkem putna. Opravdu málo kdo (!) je v matice na takové úrovni, aby ty matematické kořeny FP dokázal opravdu ocenit a využít (!). My ostatní Běžní Frantové Programátoři si užíváme úplně jiné věci (jako třeba tu zmíněnou paralelizovatelnost nebo přímočarost kódu).

Jenže to funkcionální paradigma navíc není úplně přirozené ani tomu železu

To 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)

[Aoidhghean]

No, pokud budu provádět výpočty nerelativistických jevů, tak je opravdu hloupost nasazovat na to nástroje TR. [...]
K paralelním výpočtům jsem se dostal naposledy na VŠ při řešení PDE. Dělali jsme to tenkrát ve Fortranu 90 a popravdě, při vědomí, jak výpočetně neefektivní FP jazyky jsou, by mě asi nenapadlo je k těmto účelům použít. Čekat na výsledek týden nebo měsíc je přeci jen rozdíl.  I v tom Fortranu se tehdy špekulovalo nad tím, jak ty matice vůbec organizovat, aby se narvaly do paměti jednotlivých jednotek a minimalizovala potřeba rozsáhlých datových přesunů uvnitř nebo dokonce mezi jednotkami. Docela se obávám, že funkcionální jazyk by mi z tohoto hlediska naházel do cesty tolik klacků, že by se z toho na daném HW stal neřešitelný problém.

Přesně, a zrovna tak je hloupost nenasadit nástroje TR, když o rel. jevy jde. Jde-li například o masivní paralelismus s komplikovanými daty, je FP spásou z nebes.

Výkon je záležitost implementace, ne paradigmatu. V FP už vývoj dost pokročil a efektivitou se blíží běžným OO jazykům. Navíc nic mi nebrání jít cestou Pythonu a využít optimalizované knihovny s funkcionálním API pod glue kódem třeba v Haskellu.