ANT_39: Jo, tim usetrim to probublavani skrz svoje funkce. Ale porad budu muset vsude psat (api-function1 *conn* ...), coz je mirnej vopruz, ja bych chtel aby ten 99% pripad byl totalne painless. Zatim mi asi nejlepsi varianta prijde proste pro kazdou funkci mit dve varianty, jednu s a jednu bez explicitniho kontextu (a ta to bude brat z *conn*), coz, jestli chapu spravne defn, by nemel bejt problem...

REDGUY: Nemohl bys udelat (2), s tim, ze tech 99% si ten kontext ulozi do globalni promenne, aby ho nemuseli vsude predavat?

Mam designovej dotaz na pritomne clojuristy. Mirne zjednodusena situace: rekneme ze pisu clojure knihovnu pro komunikaci s nejakym serverem. Ta komunikace neni bezstavova, potrebuju udrzovat nejakej kontext (napriklad autorizacni cookie nebo tak neco), kterej vznika prihlasenim. A rekneme, ze v 99% procentech pripadu programy tu knihovnu budou pouzivat tak, ze se na zacatku prihlasej a celej zbytek behu budou pouzivat tenhle jeden kontext. Nicmene, v 1% bude program potrebovat se s tim serverem bavit pod vice identitama, bud soucasne ve vic threadech, nebo "soucasne" v jednom threadu ale na stridacku.

Kdybych chtel pokrejt jen tech 99%, tak je to jednoduchy. Kontext strcim do nejaky top-level var *connection* a vsechny funkce ty knihovny si ho vezmou odtamtud. Jenomze to nefunguje pro to zbyly jedno procento. Jak to nejlip idiomaticky vyresit?

(1) Proste budu mit funkci (connect username password) ktera mi vrati prislusnej kontext, kterej pak budu strkat do kazdy dalsi funkce te knihovny jako prvni parametr. Coz je strasnej voser, protoze nejen se s tim musim psat, ale musim ho postupne predavat i do vsech svejch funkci aby k nemu mely pristup, atd. A pro tech 99% programu to bude zcela zbytecna prace, protoze to bude porad to samy.

(2) Pouzit top-level var, rekneme *connection*, rict o nem ze je ^:dynamic a v pripade ze potrebuju jinej nez "globalni" kontext, obalit prislusnej kod do (binding [*connection* other-context] ...). Coz mi prislo strasne super, ale pak mi doslo, ze per-thread promene se nededi, takze kdyz bych v ramci toho "binding" zavolal rekneme "pmap" s funkci, ktera by volala moji knihovnu, cely by se to straslive rozbilo protoze thread ze kteryho volam pmap by videl jiny *connection* nez thready vytvorenej pmapem. Coz samozrejme jde resit, ale uplne vidim ty debilni chyby ktery by se blbe hledaly kdyz na to clovek zapomene.

(3) pro kazdou funkci v knihovne mit dve alternativy, jednu s connection parametrem a druhou bez (pouzivajici globalni). Co by slo jednoduse delat makrem, ale prijde mi to trochu osklivy.

Nexistuje nejaky jiny, hezci reseni ktery nevidim? Takovy ktery tech 99% resi trivialne a to zbyly jedno procento je treba i trochu psani navic, ale elegantni a funkcni?

Trocha novinek ohledně Clojurescriptu, podpoře v browseru a tak... http://www.infoq.com/interviews/nolen-clojurescript

SHAGA: Hlavní důvod je její uplatnění. Ač je Scala zajímavá, tak čas, který investuji do toho, abych byl v ní dobrý je enormní a místa, kde jí mohu uplatnit je málo. Existuje strašně málo pracovních nabídek a u nás téměř žádné. Připadá tedy v úvahu pouze použití na vlastní projekty. Pro mě jsou hlavně důležité mobilní platformy. Zkoumal jsem tedy její uplatnění na Androidu a ač to lze se speciálně upravenou Scalou a jsou lidi, kteří v ní napsali Android aplikace, tak to přináší celou řadu problémů, které prostě za to nestojí. Došel jsem tedy k závěru, že je pro mě lepší se stát lepší v jiných technologiích, které mohu uplatnit na více místech a i v zaměstnáních.

ROTTWEILER: Pro info, co tě od scaly odradilo?

Jedete někdo na gr8conf? Pokud vás zajímá GAELYK, stavte se na přednášku mého kolegy z AppSatori Vladimira. O novinkách bude jistě psát na svém twitteru @musketyr
GR8Conf Europe 2012 - GAELYK bootcamp (*)
http://gr8conf.eu/Presentations/GAELYK-bootcamp

SATAI: YC ma ted strategii financovat lidi namisto jenom projektu. Zrovna v tomhle pripade nemam duvod si myslet, ze to nemuze vyjit. Nakonec na tenhle projekt penize uz ziskali. Takze skill tam je i obchodne prezentacni :)

Tak to Light Table dopracoval do YCombinatoru. On snad nekdo mysli, ze se na tom daji i vydelat penize.

SATAI: ha, predbehnul jsi me

ROTTWEILER: Jenze Eclipse je na rozdil od IJ open source od zacatku a ne od roku 2009 :-)) IJ ma lepsi ekosystem pro vyvojare ? Opravdu ? :-DD Ono o kvalite eclipsiho plugin systemu a technologii svedci i to, ze ty eclipsi frameworky (SWT, EMF GMF, GEF, Draw2D) presahly ramec IDE a pouzivaji se masivne k vyvoji RCP aplikaci, coz pripad IJ opravdu neni.

Snad nenosim dluhy do Aten:

SICP in Clojure
http://sicpinclojure.com/
Structure and Interpretation of Computer Programs adapted for the Clojure programming language

ROTTWEILER: Lidi staveji nad Eclipse, protoze tu Eclipse je roky a ma ekosystem, ktery je sazka na jistotu. A lidi sazeji na jistotu a ne na kvalitu.

Abych to za sebe shrnul: jsem mirne skepticky, presto jsem do toho dal pomerne dost penez (v radu licence komercniho IDE). Je to sance na to rozhybat stojate vody a pokud se povede, tak mne to dokope naucit se Clojure.

SATAI: To jsem samozřejmě četl, ale tenhle model moc nefunguje. např. JetBrains mají taky jádro Intellij IDEA open-source, ale i přesto lidi staví více nad Eclipse i když je Intellij IDEA lepší.

ROTTWEILER:

Will it be open source?
I'm a firm believer in open source software and open source technologies. I can guarantee you that Light Table will be built on top of the technologies that are freely available to us today. As such, I believe it only fair that the core of Light Table be open sourced once it is launched. At some level, this is an experiment in how open source and business can mix - it will be educational for us all.