REDGUY: Osobně bych volil přístup 1. Není to takovej "voser", jak se zdá na první pohled a má to několik výhod: a) je to jednoduchý b) management toho kontextu není v režii knihovny, ale volající aplikace, což může být důležitý c) je to nejvýkonnější řešení d) dobře se to testuje (viz např. ring).

^dynamic pro tyhle účely vypadá lákavě, ale má hromadu "drobných" problémů. Některé zmiňuješ, další čekají za rohem.

řešení 3 vede k tomu, že budeš pálit čas vymýšlením, jak se zbavit duplikace kódu a udržovat všechno (včetně oprav a refaktoringu) aktuální

Pro vysvětlení od povolanějšího můžu doporučit k přečtení tohle (vč. komentářů):

On the Perils of Dynamic Scope | Digital Digressions by Stuart Sierra
http://stuartsierra.com/2013/03/29/perils-of-dynamic-scope

Všecky varianty se tam v zásadě probírají...

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.

ESORIMMER: Eclipse byl a je open-source. Kdyby Light Table byl open-source, tak věřím, že dojde dále.


SATAI: Pochybuji, že všichni ty, co dali příspěvek jsou LISPaři. Plus to má být i pro Javascript a pokud bude 300k, tak i Python.

Já si prostě myslím, že daný kapitál mu nebude stačit na to, aby to dotáhl na něco použitelného. Udělá pěknou hračku, ale nic, co by se dalo používat a nahradilo třeba WebStorm, který je pro Javascript od JetBrains. Možná po několika letech vývoje nebo s daleko větším týmem. Maximálně to osloví ty, kteří dnes nepoužívají IDE, ale textové editory rozšířené o pluginy.

ROTTWEILER: Jejich podstatna vyhoda je, ze nedelaji IDE pro Javu, ale pro LISP.