Hlavní navigace

Názory k článku Programovací jazyk Clojure 8: identity, stavy, neměnné hodnoty a referenční typy

Článek je starý, nové názory již nelze přidávat.

  • 31. 7. 2012 20:33

    ava (neregistrovaný) ---.cust.vodafone.cz

    Predem se musim priznat, ze jsem se nesoustredil 100% na obsah vsech dilu, a vubec nejsem odbornik na FP, ale jsem trochu na rozpacich z toho, ze zaroven mam pocit, ze je zde Clojure prezentovan jako pokud mozno ciste funkcionalni jazyk, a zaroven je v tomto serialu venovano obrovske mnozstvi prostoru analogiim globalnich promennych, referenci u kterych se da zmenit kam ukazuji atp.. K cemu mi je, ze reference ukazuje na immutable hodnoty, kdyz ta "immutable" hodnota muze mit jako prvek referenci, ktera se tedy zase muze menit? (pokud nelze, omlouvam se). To uz jsem se vratil zpet vicemene k Jave nebo C, kde muzu promennou mit const(final) nebo nemusim, podle toho je jakoby immutable nebo neni (prosim berte s rezervou, jde o myslenku, nikoliv o to, ze ty jazyky to umoznuji porusovat). Neni snad uhelnym kamenem funkcionalniho programovani referencni transparentnost vsech funkci? To, ze jsou "pure", tedy pro stejne vstupni parametry vzdy vrati stejnou hodnotu, nemaji stav, nekonaji zadne side-effecty? Myslel jsem, ze FP povazuje "stav" za zlo, ktere komplikuje rozvazovani nad tim, co program dela, ztezuje znovupouzitelnost funkci jako stavebnich bloku, a v pripade paralelnich programu je puvodcem observable nondeterminismu (race conditions), na ktery nadavaji svorne programatori (mam tam nekde chybu, ale kdyz to pustim v debuggeru, tak to zacne fungovat spravne) i uzivatele(obcas to spocita neco jinyho nez ma)? Je prijemne, ze se tvurci Clojure alespon pokouseji priciny nekterych problemu se stavem pojmenovat (synchronnost pristupu k hodnotam, koordinovanost), ale stale je to stav. Se stavem uz mohu programovat v podstate imperativne, stejne jako v jave, jen Clojure reference jsou o trochu chytrejsi.

    Tim samozrejme nechci tvrdit, ze Clojure nema spoustu jinych dalsich zajimavych vlastnosti. Ale dosud mi prijde, ze funkcionalni programovani je zde spise dobrovolne, se vsemi vyhodami i nevyhodami, ktere z toho plynou (to, ze zrejme nedokazu z definice funkce v Clojure poznat, jestli je pure, mi prijde jako jedna z nejvetsich nevyhod).

    Pokud jsem ve zbrklosti napsal nesmysly, omlouvam se, priste muzu byt duslednejsi :-)

  • 1. 8. 2012 18:17

    javista (neregistrovaný) ---.redhat.com

    Jak to chapu ja, tak jde o to, ze sice tvurci Clojure chapou, ze s nejakym stavem se proste musi pracovat - ona ta teorie funkcionalnich jazyku je zamerena na vypocty/vyhodnoceni a ne treba na informacni systemy ze - ale tim, ze se vlastne nepouzivaji klasicke promenne, tak se zmena stavu "izoluje" do nekolika operaci a sam programator si urci, jak to provede - bud v jednom vlaknu pres defy, v transakci pres refy nebo atomicky pres atomy (agenti jsou trosku neco jineho, i kdyz to tak mozna jen citim).

  • 1. 8. 2012 18:21

    javista (neregistrovaný) ---.redhat.com

    Ted ale nevim, co je mysleno tim "final" v Jave. To oznacuje skutecne konstantu, ale jen primitivniho datoveho typu (int/long/flo­at/char/boole­an....). V pripade objektu to znaci nemennou referenci, ovsem STAV objektu se zmenit muze:

    final List<String> finalniList = new ArrayList<Strin­g>().

    Co myslite - jde pouzit finalniList.ad­d()/remove() atd. nebo ne?

    V Clojure je to v podstate presne naopak :)

  • 4. 8. 2012 15:08

    Ladislav Thon (neregistrovaný) ---.cust.nbox.cz

    Lisp nebyl nikdy čistě funkcionální, a Clojure je jenom Lisp (i když jsou lidi, co tvrdí, že je to ten nejlepší Lisp :-) ).