Knyga "Clojure Applied"

[Osvaldas Grigas]

Manęs kas nors vis paklausia, ar yra gerų pavyzdžių, kaip Clojure pritaikyti realiuose didesniuose projektuose.

Pagaliau galiu atsakyti: neseniai išleista knyga "Clojure Applied" jau susilaukė palankių atsiliepimų iš Stuart Sierra, David Nolen ir kitų iškilių vardų.

Kad nuspręstumėte, ar knyga tinkama jums, siūlau perskaityti šį nešališką, konstruktyviai kritišką review'ą: http://stuartsierra.com/2015/10/18/clojure-applied-review

Osvaldas

[Karolis Astrauka]

http://blog.cognitect.com/cognicast/2015/9/4/alex-miller-and-ben-vandgrift-cognicast-episode-086 - podcastas su knygos autoriais, nelabai idomus, bet gal pries perkant bus smagu paklausyt :)

--
Gavote šį pranešimą, nes prenumeruojate „Google“ grupę „(Clojure/LT)“.
Jei norite atšaukti šios grupės prenumeratą ir iš jos nebegauti el. laiškų, praneškite apie tai adresu clojure-lt+...@googlegroups.com.
Jei norite peržiūrėti šią diskusiją žiniatinklyje, apsilankykite https://groups.google.com/d/msgid/clojure-lt/8d236b07-e437-4f40-880a-0842f0413d40%40googlegroups.com.
Daugiau parinkčių rasite apsilankę adresu https://groups.google.com/d/optout.

[Zilvinas Kybartas]

As kolkas sugalvojau 3 :) gal kazkiek pades.

1 Su Coljure galima parasyti aisku koda, kuri bus lengva skaityti, bet taip pat galima parasyti ir labai sunkiai skaitoma koda :) Nelygu kas ji raso. Todel zmonems dirbantiems prie tokio turi rupet koks yra Clojure idiomatiskas kodas, taip pat turi galvoti apie kita zmogu kuris ta koda skatys. Galima sakyti, kad tas taikoma visom kalbom, bet as manau kad tai ypac svarbu Clojure atveju. Tikrai pamenu kai esu ziurejas i 3 eilutes gal koki pusvalandi, kol supratau ka jos daro.

2 Man nepasiseke parasyti greitos funkciojs kuri pereitu per dideli masyva ir negeitintu kiekviena bita. Butent pats traversinimas buvo labai letas. Endapinau tuom, kad tiesiog pasirasiau toki metoda Javoi

3 Multimodule projekta yra sunku valdyti. Man asmenskai atrodo per daug efforto. As bandziau tik su leiningenu, nezinau kaip su mavenu. Kita karta taip tiesiog nedarysiu, viska laikysiu viska vienam modulije tol kol atsiras poreikis dali tiesiog iskelti i kita repo.

On 2015-10-21, at 11:08, Maksim Pečorin <mpec...@gmail.com> wrote:

Aciu uz link'us!

Osvaldai, jus turit production Clojure patirties. Kol negavom knygos, turiu subjektyvu klausyma (kuris reikalauja kritiskumo mylimai kalbai :) ).

Tu galetum parasyti desimt siolaikines Clojure kalbos/ekosistemos silpnu vietu (kaip darbo/modeliavimo/kodingo priemones - na, kaip irankiai meistro toolbox'e turi ribas)?

Toki sarasa neturi butu sunku parasyt - as pvz galeciau sudaryti 50 item'u sarasa Javai ar Scalai per 5 min :)

Vertinimo kriterijai gali buti bet kokie - nuo performance'o tam tikriems uzdaviniams iki long-term support'o projektu, refactoringo lengvumo, ...

--
Gavote šį pranešimą, nes prenumeruojate „Google“ grupę „(Clojure/LT)“.
Jei norite atšaukti šios grupės prenumeratą ir iš jos nebegauti el. laiškų, praneškite apie tai adresu clojure-lt+...@googlegroups.com.

Jei norite peržiūrėti šią diskusiją žiniatinklyje, apsilankykite https://groups.google.com/d/msgid/clojure-lt/e4eb969c-4fc4-4cf1-8ecf-cb41c481399a%40googlegroups.com.

[Osvaldas Grigas]

Puikus klausimas. Labai svabu kritiškai vertinti kiekvieną kalbą/technologiją, kurią naudoji.

Kadangi production'e esu naudojęs visas populiarias JVM kalbas (Java, Scala, Groovy, Clojure), manau, kad pastebėjau bent dalį kiekvienos iš jų privalumų bei trūkumų.

Kas konkrečiai užknisa Clojure, pritariu Žilvinui ir pridedu savo:

4. Kiekvienas funkcijos iškvietimas daromas per var'o lookup'ą. Tai yra kalbos dinamiškumo mechanizmas, ir vyksta labai greitai, tačiau kritinėms kodo sekcijoms gali pakišti koją. (Rich Hickey šiuo metu eksperimentuoja su feature'u, kuris galbūt leis daryti direct invocation pažymėtose funkcijose.)

5. Ne visai aišku, kada naudoti map'us, o kada defrecord'us domenui modeliuoti. Nepatinka, kad record'ai leidžia dinamiškai pridėti naujų laukų, ir netgi išimti esamus laukus - išėmus jie automagiškai tampa map'ais, kas irgi nepadeda,

6. Nėra idiomatiško būdo dokumentuoti funkcijos input'o ir output'o tipą (išskyrus destructuring'ą). Visos dinaminės kalbos turi šią problemą/feature'ą. Yra lib'ų, kurie tą sprendžia, bet tai jau ne kalbos dalis.

7. Refactoring'ą daryti sunkiau nei statinėje kalboje. Vėlgi, tai visų dinaminių kalbų problema.

8. IDE support'as ne toks geras kaip kitų kalbų. Net Groovy turi geresnį support'ą.

9. Namespace'ų deklaracija per daug sudėtinga ir (kas gali skambėti keistai) lanksti. Galėtų būti paprastesnė. I mean, load, ns, require, use, import, refer su visom jų variacijom, WTF?

10. Stack trace'ai dažnai būna tokio kriptiški, kad iš jų jokios naudos, ypač padarius kvailą klaidą kaip netinkamo tipo parametrų padavimas arba eilės tvarkos supainiojimas. Ilgainiui išmolksti nedaryti kvailų klaidų :) bet kol mokaisi, tai labai stabdo.

Na štai, turim 10. Reikėjo gerokai pasukti galvą. Su kitom JVM kalbom nebūtų taip sunku :)

Osvaldas

[Zilvinas Kybartas]

As pastebejau, kad nauji zmones ateje i Clojure, ypac is java’os linke ir toliau rasyti koda imperatyviai, tai paprastai jis atrodo taip. Labai didelis let’as ir gale funkcijos vienos iskvietimas. Tipo

(let [a1 = (kazkas)

       a2 = (kazkas a1)

       a3 = (kazkas a2)

       a4 = (kazkas a3)]

 (do-this a4))

Cia labai supaprastintas pavizdys, viskas paprastai atrodo daug sudetingiau. Bet galima izvelgti toki patterna :)

On 2015-10-21, at 12:39, Maksim Pečorin <mpec...@gmail.com> wrote:

Zilvinai, thanks. Is #1 man gime kitas offtopic klausymas - tu galetum isvardinti keleta Clojure ar jos ekosistemos "abuse" tashku :D - t.y. kur naujokas linkes abuse'inti kalbos feature'us?

Na kaip Scaloje - operatoriu overload'as, implicits, tam tikri trait'u feature'ai, ...

--
Gavote šį pranešimą, nes prenumeruojate „Google“ grupę „(Clojure/LT)“.
Jei norite atšaukti šios grupės prenumeratą ir iš jos nebegauti el. laiškų, praneškite apie tai adresu clojure-lt+...@googlegroups.com.

Jei norite peržiūrėti šią diskusiją žiniatinklyje, apsilankykite https://groups.google.com/d/msgid/clojure-lt/f3bf9e38-e613-498a-8947-048ad80539e4%40googlegroups.com.

[Vadim Platonov]

As irgi prisidesiu, nes gan daug jau laiko su Clojure praleidau. Is tikruju sunku dabar analitiskai prieit prie problemu, kai kuriuos dalykus tiesiog ismoksti vengti ir pamirsti.

pereisiu per Osvaldo ir Zilvino punktus:

1 Su Coljure galima parasyti aisku koda, kuri bus lengva skaityti, bet taip pat galima parasyti ir labai sunkiai skaitoma koda :) Nelygu kas ji raso. Todel zmonems dirbantiems prie tokio turi rupet koks yra Clojure idiomatiskas kodas, taip pat turi galvoti apie kita zmogu kuris ta koda skatys. Galima sakyti, kad tas taikoma visom kalbom, bet as manau kad tai ypac svarbu Clojure atveju. Tikrai pamenu kai esu ziurejas i 3 eilutes gal koki pusvalandi, kol supratau ka jos daro.

Tikrai taip. Bet cia universalus pastebejimas :) 

2 Man nepasiseke parasyti greitos funkciojs kuri pereitu per dideli masyva ir negeitintu kiekviena bita. Butent pats traversinimas buvo labai letas. Endapinau tuom, kad tiesiog pasirasiau toki metoda Javoi

Padariau proektuka ka tik - https://github.com/dm3/clojure-bench. Java while loopas sukasi ~5 kart greiciau nei greiciausia Clojure versija kuria galejau parasyt. Ne dekompiliavau, bet abejoju kad ten galima kazka dar pagerint. Kaip Pythonininkai raso performance-critical koda su C, taip Clojurininkai su Java :) 

3 Multimodule projekta yra sunku valdyti. Man asmenskai atrodo per daug efforto. As bandziau tik su leiningenu, nezinau kaip su mavenu. Kita karta taip tiesiog nedarysiu, viska laikysiu viska vienam modulije tol kol atsiras poreikis dali tiesiog iskelti i kita repo.

Taip. Kolkas Clojure neturi normalaus budo palaikyti skirtingas moduliu versijas viename projekte. Releasint skauda, manage'int versijas skauda. As irgi stengiuosi turet 1 repo = 1 projektas. 

4. Kiekvienas funkcijos iškvietimas daromas per var'o lookup'ą. Tai yra kalbos dinamiškumo mechanizmas, ir vyksta labai greitai, tačiau kritinėms kodo sekcijoms gali pakišti koją. (Rich Hickey šiuo metu eksperimentuoja su feature'u, kuris galbūt leis daryti direct invocation pažymėtose funkcijose.)

Tiesa 

5. Ne visai aišku, kada naudoti map'us, o kada defrecord'us domenui modeliuoti. Nepatinka, kad record'ai leidžia dinamiškai pridėti naujų laukų, ir netgi išimti esamus laukus - išėmus jie automagiškai tampa map'ais, kas irgi nepadeda,

6. Nėra idiomatiško būdo dokumentuoti funkcijos input'o ir output'o tipą (išskyrus destructuring'ą). Visos dinaminės kalbos turi šią problemą/feature'ą. Yra lib'ų, kurie tą sprendžia, bet tai jau ne kalbos dalis.

Kai kurios bibliotekos Clojure jau yra standartas. As jau prisitaikiau kad ~90% projektu naudoja Prismatic/Schema. Cia kaip Joda Time pries Java 8. Galima sakyti kalbos dalis :)

Problema, kad Java turi tukstancius blogu kur best practices yra aprasyti. Clojure turi pats suzvejuot.

7. Refactoring'ą daryti sunkiau nei statinėje kalboje. Vėlgi, tai visų dinaminių kalbų problema.

Is savo patirties - cia didziausia problema. Jei keiciasi interfeisai tarp komponentu ir nera 100% testu, tai lieka melstis kad kur nors vietoj Map'o nepaduodi Seq'a.

 

8. IDE support'as ne toks geras kaip kitų kalbų. Net Groovy turi geresnį support'ą.

VIM/Emacs! Rimtai, sutinku.

9. Namespace'ų deklaracija per daug sudėtinga ir (kas gali skambėti keistai) lanksti. Galėtų būti paprastesnė. I mean, load, ns, require, use, import, refer su visom jų variacijom, WTF?

Prisidedu. 

10. Stack trace'ai dažnai būna tokio kriptiški, kad iš jų jokios naudos, ypač padarius kvailą klaidą kaip netinkamo tipo parametrų padavimas arba eilės tvarkos supainiojimas. Ilgainiui išmolksti nedaryti kvailų klaidų :) bet kol mokaisi, tai labai stabdo.

Cia didziausia problema mano kolegu nuomone :)

Dar nuo saves:

11. Cyclical dependencies tarp namespace'u galetu ir kompiliuotis - kartais tenka workaroudint. 

12. type hintai array'ams - reikia rasyt stringa - WTF?
13. Core turi daug feature'u kurie yra labai marginaliai naudojami, e.g. STM, hierarchy multimetuodose - galetu buti bibliotekose

14. Developmentas pacios Clojure ganetinai letas. Kai kurie contributoriu improvementai lieka be tinkamo demesio, e.g. https://twitter.com/aphyr/status/621806683908542464

Abuse taskai:

* globalus state Var'uose

* nenaudojimas threading macros'u

* bandymas rasyti savo macrosus kur nereikia

* blogas name'ingas - daug didesne problema negu tipizuotoje kalboje

[Lech Jankovski]

Mes šitą patterną vadindavome "Letito liga" :) Simptomai — daugiau kodo `let`e negu jo bodyje, o geriausi vaistai — threading macros (->, ->>) :)

Jei norite peržiūrėti šią diskusiją žiniatinklyje, apsilankykite https://groups.google.com/d/msgid/clojure-lt/8056EB3F-6D3D-4E5C-99AB-AA553A2D74DD%40inventi.lt.

[Zilvinas Kybartas]

Tai as net neabejojiau, kad toks budas yra kur galima parasyti taip kad performiintu, gaila taves tada nebuvo ;) . Tiesigo lyginant su java pvz, sitas budas nera immediate obvious. Zmogus turi tikrai gerai ismanyti clojure, kad taip padaryt kaip tavo pavizdyje.

[Osvaldas Grigas]

Na, tiesiog Rich Hickey kaip kalbos autorius ir pagrindinis contributor'ius pasilieka teisę priimti, atmesti arba pakeisti kiekvieną kalbos pakeitimą. Taip veikia kai kurie OSS projektai. Čia turiu kelis pastebėjimus:

a) Demokratija veikia ne visose srityse. Pvz. programavimo kalbos dizaine geriau turėti vieną asmenį (ar įmonę, šiuo atveju Cognitec) su aiškia vizija, kuris priimtų sprendimus. Scala ir Groovy yra pavyzdžiai kalbų, kurios praeityje per daug lengvai accept'ino daug naujų feature'ų, su kuriais dabar visi turi gyventi.

b) Pati kalba yra tik mažytė dalelė Clojure ekosistemos, o lib'ams ppr. taikomas atviresnis open source contributor'ių modelis.

c) Kadangi Clojure kalba tokia extensible, jei tau kažko tikrai trūksta, pasirašyti atitinkamą macros'ą užims daugiausiai kelias kodo eilutes.

Osvaldas

2015-10-21 16:05 GMT+03:00 Maksim Pečorin <mpec...@gmail.com>:

Guys, aciu uz nuomones

(cia kaip auksas - dalykai apie kuriuos retai rasho knyguose kai technologija tik igauna pagreiti :) - gal tik blog'ose galima rasti info gauta per praktikos skausma :) )

gime dar vienas klausymas - is duoto twitter link'o supratau, kad Clojure kaip kalbos vystimo procesas vyksta ne per kazkoki expertu/community board'a, o yra vieno "diktatoriaus" rankuose? :D - ar tai tiesa, kokias zinote detales, gal kokie ateites planai?

--
Gavote šį pranešimą, nes prenumeruojate „Google“ grupę „(Clojure/LT)“.
Jei norite atšaukti šios grupės prenumeratą ir iš jos nebegauti el. laiškų, praneškite apie tai adresu clojure-lt+...@googlegroups.com.

Jei norite peržiūrėti šią diskusiją žiniatinklyje, apsilankykite https://groups.google.com/d/msgid/clojure-lt/c4a61750-e12c-4b98-bf6d-664ea02385ba%40googlegroups.com.

[Vadim Platonov]

Tai as net neabejojiau, kad toks budas yra kur galima parasyti taip kad performiintu, gaila taves tada nebuvo ;) . Tiesigo lyginant su java pvz, sitas budas nera immediate obvious. Zmogus turi tikrai gerai ismanyti clojure, kad taip padaryt kaip tavo pavizdyje.

Turejau omenyje kad pasiekti raw Java greiti su Clojure be sansu, t.y. ten nebuvo paneigimas :)

Del macrosu, case in point: https://github.com/boxed/defk. Kokia tikimybe kad zmogus pries tai Pythonu rase ? :)

Tokiu dalyku i didele kodo baze geriau neisileist.

gime dar vienas klausymas - is duoto twitter link'o supratau, kad Clojure kaip kalbos vystimo procesas vyksta ne per kazkoki expertu/community board'a, o yra vieno "diktatoriaus" rankuose? :D - ar tai tiesa, kokias zinote detales, gal kokie ateites planai?

Tai yra gerai - kalba yra vientisa, featurai atsiranda jei visapusiskai pasverti, nera breaking pasikeitimu ir nuolatiniu redesignu.

Tai yra blogai - aktyvus kontributoriai palieka kalba nes negali nieko itakoti, didesnese sistemose atsiranda runtime'o forkai su private patchais. Reikia pastebeti, kad Clojure tai yra problematiska tik performance atzvilgiu, beveik visus imanomus feature'us galima parasyt su macrosais ir custom readeriais.

Mano manymu - labiau gerai, nei blogai.

[Osvaldas Grigas]

"With this change, clojure.core itself is compiled with direct linking and therefore
 other namespaces cannot redefine core fns and have those redefinitions seen by core code"


O gaila, dabar nebegalėsiu daryti (in-ns 'clojure.core) (def + -) ir stebėti, kaip išsikreipia kolegų veidai.

On Monday, January 25, 2016 at 8:00:49 PM UTC+2, Maksim Pečorin wrote:

Nauja Clojure 1.8 versija, implementuoja "direct linking" compiler'io opimizacija, kuria minejo Osvaldas kalbedamas apie tarpini var'a per kuri dinamiskai kvieciamos funkcijos. Placiau cia: https://github.com/clojure/clojure/blob/master/changes.md