Komentáře k článku

Javascriptaření: hrajte si s funkcemi!

Javascriptaření

Funkcionální programování si častěji spojujeme s Lispem, Haskellem či F# než s něčím, co by se odehrávalo na webu. A přitom funkcionální jazyk má každý webař po ruce… Ukážeme si tento opomíjený rys JavaScriptu na příkladech, které budou lispařům určitě důvěrně známé. Vítejte do světa javascriptaření!

Zpět na článek

20 komentářů k článku Javascriptaření: hrajte si s funkcemi!:

  1. juraj

    fcie ad 2

    Dúfam, že v druhej časti seriálu uvidíme použitie bind(), ešte niekto začne takéto vnáranie xy fcií do seba bežne používať :-)
    Mimochodom, vážne v kóde všade priradzujete do neinicializovaných premenných (chýba var)? Fuj.

    1. Martin MalýAutor příspěvku

      Re: fcie ad 2

      Předpokládal jsem, že čtenáři dojde, že jde o ukázku techniky, ale máte pravdu, var doplním.

  2. David Grudl

    No tedy...

    Tož tedy nevím. Článek o Coffeescriptu nazvat „JavaScriptaření“ je docela zavádějící, oba jazyky jsou naprosto jiná liga, navíc ukázky v jednotlivých jazycích jsou odlišné, ať už názvy identifikátorů (r versus result) nebo funčností (test na null ve foldl). Ukázky v JavaScriptu obsahují chyby (__split, závorka v arrsuda), názvy arrsuda a cbkrat mě už jen dorazili, smrdí to Pecinovským :-(

    Sorry za negativní koment a stručnost (čtu a píšu v mobilu), ale víš jak ;)

    1. Martin MalýAutor příspěvku

      Re: No tedy...

      r vs result je moje nedopatření, test na null chyba, to opravím, a pokud nemáš dál nic jiného než že se ti nelíbí názvy, tak jsem spokojen.

      1. Ped

        Re: No tedy...

        Uz duch samotneho clanku mi znel trochu jako „je jedno jak se to bude cist, hlavne at se pri psani neuzavorkuju k smrti“ (mne osobne se treba uzavorkovany kod na vice radku cte docela dobre, nerikam ze cofeescript verze se mi nelibi, ale bez spetky zvyku se mi cte o neco hur (co je dobre znameni, obvykle se mi nove veci ctou MNOHEM hur)) (a vubec se zavorkami mam malo problemu (jak je mozna znat uz z tohohle prispevku)).

        Rikal jsem si ze to mam asi jen takovou naladu po ranu a autor to tak nemyslel.

        Ale tahle reakce na „nelibi nazvy“ mi ukazuje ze autor nejspis nepochopil jednu ze zakladnich vlastnosti dobreho kodu, a to ze dobry kod se dobre cte, i za cenu toho ze se spatne pise. Protoze kod se pise cca. jednou, ale cte se mnohokrat.
        „arrsude“ je cechoanglikopra­sizmus ktery dela cteni kodu slozitejsim a tudiz celou ukazku shazuje minimalne o tridu dolu. A stacilo by tak malo, treba alespon „arrayeven“ nebo „arr_even“. Nebo pripadne cely nazev cesky (to se mne osobne nebude libit uplne stejne jako arrsude, ale to uz je o mych preferencich).

        1. Martin MalýAutor příspěvku

          Re: No tedy...

          Dovolte autorovi, když už se tu o něm tak hezky mluví ve třetí osobě, aby k tomu taky něco dodal: Autor s vámi souhlasí, máte pravdu, arreven je mnohem lepší, v ukázce už to je přibližně hodinu změněné, protože autor argument Davida Grudla o jménech funkcí uznal jako oprávněný a text podle něj hned opravil, jak jste si jistě všiml. Autor ale tentokrát nenapsal „Máte pravdu, děkuji za upozornění“, jako píše v podobných případech (viz tato diskuse), ale – protože se s Davidem Grudlem zná už dost dlouho a oba vědí, co si k sobě mohou dovolit a jak – použil lehce přidrzlou osobní odpověď. Tímto se také omlouvá za nepohodlí, které vám způsobil tím, že svůj vstřícný postoj ke kritice vyjádřil nejen činem, který jste ve svém rozhořčení přehlédl, ale i ironickým slovem.

          1. Ped

            Re: No tedy...

            To se pak omlouvam za trochu ostrejsi reakci, clanek jsem cetl v jeho puvodni podobe kde mi nektere nazvy trochu zvedali oboci, ale puvodne jsem to ani neminil komentovat, ale ta diskuze byla tou povestnou kapkou… :)

            1. Martin MalýAutor příspěvku

              Re: No tedy...

              Ne, to je v pořádku. Já uznal, že David má pravdu; celý tenhle zmatek vznikl kvůli tomu, že článek mám rozepsaný od prosince a „lepil“ jsem ho z několika částí a verzí, a i když jsem to několikrát procházel, aby to sedělo, tak mi stejně něco uteklo.

              Mimochodem, moje odpověď Davidovi byla „pokud nemáš dál nic jiného než že se ti nelíbí názvy, tak jsem spokojen“ – tedy jinak řečeno: jestli tam nejsou už větší chyby než blbé názvy, tak hurá! Tedy ne že to nepovažuju za chybu, ale naopak jsem rád, že tam nenašel nějaké horší. :)

    2. Martin MalýAutor příspěvku

      Re: No tedy...

      Jo a ad CoffeeScript: nešlo ani tak o to, abych popularizoval CoffeeScript nebo říkal, že tohle je budoucnost JS – to už všichni dávno vědí. ;) Použil jsem ho proto, že jsem právě u zmíněného Cawleyho na vlastní kůži zažil, jak je v té CfS syntaxi krásně na první pohled vidět, co se tam děje. Takže klidně zapomeň na CoffeeScript a ber to třeba jako „symbolický metajazyk pro popis funkcionálních srandiček“.

      Offtopic PS: Příště si ukážeme kanonický přenositelný commonlispový tracer, který atomicky nahradí funkci za její trasující wrapper a pak po skončení trasování zase zpátky přiřadí původní funkci, a to určitě nechceš vidět! :)

  3. Rum

    funkce = function() {... vs function funkce() {...

    Je nějaký rozdíl mezi funkce = function() { a function funkce() {

    1. fos4

      Re: funkce = function() {... vs function funkce() {...

      function funkce():
      vytvori funkci s nazvem „funkce“ (function declaration) a automaticky priradi do promene stejneho jmena

      funkce = function():
      priradi do promene „funkce“ annonymni funkci (function expression)

  4. BurgetR

    Umění programování

    Moc pěkný článek. Líbí se mi, že konečně někdo řeší opravdu programování jako takové. Zvlášť ve webařských kruzích už dnes není moc zvykem se zabývat tím, jestli je něco napsáno efektivně nebo dokonce pěkně. BTW – já pořád říkám, že JavaScript zůstává většinou svých současníku nedoceněn :-)

  5. paranoiq

    PHP má first-class funkce

    jen pro upřesnění. PHP má first-class funkce. funkci lze předat jako argument, lze ji vracet jako výsledek funkce. lze ji obdržet jako argument, zkonstruovat z ní jinou funkci a tuto vrátit atd.

    _____
    poznámka na později: napsat ukázku prototypové dědičnosti v PHP :P

  6. Richard Šerý

    Má to i své nevýhody

    Funkcionální programování v JavaScriptu patří k základům, které by měl umět každý, kdo s tímto jazykem přijde do styku. Na druhou stranu, v praxi není vše tak krásné, jak by se z článku mohlo zdát.

    Funkce si s sebou nese svůj kontext, což za určitých podmínek může vést ke kruhovým referencím a memory leakům. Čím více „vnořených“ funkcí, tím větší riziko hrozí, protože na větších projektech se skoro vždycky najde někdo, kdo si nedá pozor. Občas radši udělám méně úsporný zápis, než riskovat, že při příští změně tam někdo zanese kruhovou referenci.

    S funkcemi vyšších řádů často prudce klesá srozumitelnost. Každý programátor se musí vždy znovu rozhodovat, jestli raději DRY nebo srozumitelný kód. Bohužel, programátoři mají tendence volit DRY, což vede ke špagetoidnímu, často paradoxně těžko udržovatelnému kódu.

    Takže poslední věta článku je rozhodně na místě, a varování by mělo být velkým, ohnivě planoucím písmem.

    1. Steida

      Re: Má to i své nevýhody

      „Funkce si s sebou nese svůj kontext, což za určitých podmínek může vést ke kruhovým referencím a memory leakům.“

      O nic vážného nejde, všechny dnešní js frameworky deregistrují listenery. Ad kruhové referencé a memory leaky.., takový kód jistě ano:

      foo(function() {});

      Takový kód ne:

      foo(xyz.bind(so­mething.bla, this));

      Bind binduje this/that, přesto nevytváří closure otisk, to je cajk.

      1. Richard Šerý

        Re: Má to i své nevýhody

        Delegování je sice chvályhodná praktika, ale jsou situace v kterých nejde použít – například když event „nebublá“ nebo když ho zastaví někdo na vyšším elementu. Memory leaky nemůže řešit framework, to musí programátor. To je jako říct, že moderní bagry jsou tak dobré, že nepotřebují bagristu…

    2. Ales Hakl

      Re: Má to i své nevýhody

      Ony ty kruhove reference by nemeli nicemu vadit (a ciste v JS taky nicemu nevadi).

      Vadi to, ze treba v takovem Gecku ma XPCOM (C++ vrstva) a JS vlastni memory managery ktere o sobe tak uplne nevedi (a navic XPCOM pouziva jenom pocitani referenci) a kruhovou referenci ktera jde pres oboji JS GC proste nevidi. Jak to resi ostatni browsery netusim, ale cekam ze to bude povetsinou dost obdobne (jak by to bylo implementacne cele jednodussi, kdyby se pouzival GC i v tom nativnim kodu…).

  7. blizzboz

    Re: Javascriptaření: hrajte si s funkcemi!

    Vracanie funkcií a predávanie funkcií ako parametrov, vytváranie kolekcií funkcií atď, umožňuje skoro každý programovací jazyk. funkcionálne programovanie na takej úrovni ako JS umožňoval už aj starý TurboPascal.

    1. Martin MalýAutor příspěvku

      Re: Javascriptaření: hrajte si s funkcemi!

      A to by mě docela zajímalo, to už jsem nějak pozapomněl… Můžete uvést příklad takového programu, který by byl ekvivalentní, řekněme, zmíněnému with_array a byl by přeložitelný TurboPascalem 7?

Napsat komentář

Přihlásit se

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: http://www.zdrojak.cz/?p=3419