Clojurians
#clojure-italy
<
2018-11-27
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

manuel07:11:42

(recap per chi come me non ha seguito in diretta, ovviamente)

justalanm07:11:25

In parte capisco la frustrazione, ma non è che altri progetti siano messi molto meglio: Python ad esempio ha perso il BDFL proprio perché Guido si era stufato di dover perdere giornate intere a discutere di cose che tanto essendo il BDFL non avrebbe approvato (non riconoscere che è praticamente la stessa cosa è da ipocriti), Linux è un altro esempio recente non ce lo vedo proprio Linus a discutere amabilmente, inoltre non scordiamoci che sotto c'è la JVM, non ho idea di come sia il processo per contribuire ad OpenJDK, ma non credo che sia tanto più semplice

manuel07:11:38

certo, ma non è che perché altri sono messi uguale o peggio del tuo progetto devi seguire la stessa strada

andrea.crotti08:11:42

Eh boh per certi versi troppa democrazia non va bene, e finisce per produrre dei mostri

nilrecurring08:11:51

@andrea.crotti hai un esempio?

manuel08:11:30

l'Italia, probabilmente

andrea.crotti08:11:01

scala per esempio, a cui hanno aggiunto qualsiasi cosa come feature nel tempo, creando un porcaio

andrea.crotti08:11:46

tale che adesso devono praticamente buttare via il compiler e ripartire da un altro, senza contare che l'upgrade da una versione all'altra e' un bagno di sangue (a differenza di Clojure)

andrea.crotti08:11:51

e per me anche Haskell per certi versi, che in ogni file tu ci debba mettere 20 pragma perche' ci sono 2000 funzionalita' del compilatore che sono disponibili ma non di default sembra un po' assurdo

andrea.crotti08:11:49

(quello e' anche perche' Haskell e' piu' un linguaggio accademico probabilmente, ma in generale con una guida piu' decisa secondo me cose del genere non possono succedere)

nilrecurring09:11:50

Il motivo dei pragma è diverso: sono cose implementate da GHC ma non sono (ancora) nello standard (principalmente perchè non lo puoi standardizzare con un “fallo come lo fa GHC”, perchè dipende da internals varie, quindi c’è un intero gruppo di lavoro che pensa a come standardizzare ste cose). Poichè GHC è de facto l’implementazione principale, tutti sono OK con i pragma (nota: i pragma si possono avere project-wide così che appunto non ne hai 20 in ogni file)

nilrecurring09:11:38

Non so la storia di scala, ma mi sembra che in Rust la cosa stia andando parecchio bene con le RFCs

andrea.crotti09:11:07

e siccome per certi versi modificano il linguaggio, ti trovi ad avere un numero spropositato di varianti di Haskell/GHC (che penso sia l'unico compilatore usato comunque)

andrea.crotti09:11:21

e si non dico che non sia possibile migliorare la situazione, e anche Clojurescript sta facendo molto bene da quel punto di vista

andrea.crotti09:11:59

pero' secondo me avere un linguaggio stabile,elegante, consistente e allo stesso tempo community driven e' come il proverbio della botte piena e la moglie ubriaca

nilrecurring09:11:06

Non sono d’accordo, penso sia totalmente fattibile (non vedo perchè non dovrebbe esserlo più che altro). Ovviamente ci saranno dei casi in cui la cosa va male (scala?), ma è normale perchè ci sono tanti fattori coinvolti

nilrecurring09:11:26

Le estensioni che usi in pratica sono forse 40, e la maggior parte sono cose di cui senti il bisogno (principalmente zucchero), quindi pensalo come importare una libreria di macro in clojure

manuel09:11:56

pur'io non capisco perché non è possibile la via di mezzo.

nilrecurring09:11:24

Certo, è difficile (perchè il problema della responsabilità distribuita è difficile), ma se hai delle persone ragionevoli coinvolte non vedo il problema

andrea.crotti09:11:13

ci vogliono delle persone che ci spendono il 120% del loro tempo per gestire una community cosi grossa, cosa che Rich non ha nessuna intenzione di fare ad esempio

manuel09:11:16

sì, sono d'accordo. È controproducente una leadership poco aperta nel senso che l'atteggiamento che tiene finisce per riflettersi inevitabilmente sulla community. E finisce che abbiamo chi ha il santino di Hickey nel taschino e chi non trova spazio per contribuire in maniera sana.

manuel09:11:34

(mi riferivo al commento di @nilrecurring)

manuel09:11:24

Ed è controproducente perché scoraggia dall'intervenire, chiudendo il cerchio sempre più stretto.

manuel09:11:25

In generale, mi sembra che il nocciolo della questione l'abbia centrato bene Chas Emerick in quel thread su twitter postato più sopra. O almeno, io condivido i suoi punti.

nilrecurring09:11:41

Si si Chad riflette totalmente anche la mia opinione

nilrecurring09:11:58

Se avessi qualcosa di più in gioco (e.g. penso a Metosin che fanno un lavorone e hanno un sacco di progetti clojure) metterei su una “open letter to Cognitect” da far firmare alla gente

andrea.imparato10:11:23

giornissimo kaffeèèèèè

justalanm10:11:44

Perché la "via di mezzo" purtroppo non vuol dire niente, per farlo bisogna definire una struttura e quando definisci una cosa di questo tipo stai a tutti gli effetti creando un'istituzione complessa che consuma risorse di per sé e trasforma la discussione in gestione politica (si vede che sono uno scienziato politico di formazione? :laughing:) Non è detto che questo sia male di per sé, ma potrebbe tranquillamente non avere senso a seconda degli obiettivi e delle dimensioni della comunità, che fra l'altro mi sembra anche un po' quello che esprimono i Cognitect senza essere in grado di esprimersi in questi termini

manuel10:11:03

di base, però, ogni scelta è politica in fondo. E la scelta di gestire Clojure in questo modo è una precisa scelta politica di Hickey e Cognitec. Intendo dire, l'istituzione complessa di cui parli consuma risorse, certo, ma se porta a un generale miglioramento della community e del linguaggio, perché non prenderla in considerazione? Mancanza di tempo? E la mancanza di tempo, se questa è, non è un problema che negli anni (perché è anni che si parla di queste cose) si poteva cercare di arginare?

manuel10:11:34

la distribuzione di responsabilità a cui faceva riferimento @nilrecurring questo è. Richiede investimento di tempo e gente, ma dubito non porti alcun beneficio.

nilrecurring10:11:29

Ci tengo a far notare che ci sono diversi gradi di “apertura alla community”: - closed source - “open source” ma sviluppo a torre d’avorio (la situazione attuale di Clojure) - “open source” e torre d’avorio + condizioni decenti per community contributors (i.e. triaging veloce, etc) - OSS e sviluppo da parte di un core team (i.e. BFDL), con processo trasparente, dove la community ha un input (sostanzialmente Linux, Python, e quello che chi si lamenta vorrebbe in Clojure) - OSS, con core team fluido e community driven (RFCs, sostanzialmente Rust e quasi Haskell)

manuel10:11:03

È anche un discorso di attitudine verso la questione, e queste parole di Hickey sono terribili francamente:

The time to re-examine preconceptions about open source is right now. Morale erosion amongst creators is a real thing. Your preconceptions and how you act upon them are your responsibility and yours alone. I am not going to answer for them or to them.
Di nuovo, Emerick ha ragione.

mdallastella10:11:22

Dico la mia in breve: personalmente non ho mi sono mai trovato davanti ad un problema bloccante tale per cui necessitava una qualche patch al core di Clojure né finora ho sentito la necessità di qualche feature annunciata ma non integrata per i motivi cui sopra. Tuttavia mi piacerebbe una soluzione più trasparente, perché che che ne dica Rich, ci sono aziende là fuori (come la mia) che si basano quasi esclusivamente su Clojure. Questo ovviamente non dà il diritto di parola nei confronti dello sviluppo del core, ma sicuramente impensierisce chi lo usa. Rich giustamente dice che è un regalo alla community, ma regalare non significa non avere responsabilità (vedi anche il caso recente della libreria event-stream).

bronsa10:11:54

>ma regalare non significa non avere responsabilità che piaccia o no, lo significa se la licenza sotto cui regali il tuo software include >>>THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

mdallastella11:11:34

Se la community si lamenta è perché ha voglia di contribuire, non perché abbia voglia di rompere le balle. Istituire una committee di volontari scelti da Rich mi sembra fattibile.

mdallastella11:11:29

Voglio dire, esistono esempi là fuori che funzionano per altri linguaggi

andrea.crotti11:11:03

mi sembra un po' una visione idealistica della community

andrea.crotti11:11:25

per 1 persona che ha voglia/tempo e capacita' di contribuire ce ne sono magari 9 che rompono solo le balle

andrea.crotti11:11:07

magari non e' troppo il caso della community Clojure ma in generale la maggior parte del lavoro di qualsiasi progetto OSS medio grosso e' triaging

bronsa11:11:43

onestamente, una buona parte della gente "high-profile" che si sta lamentando non e` che abbia mai contribuito un granche` a clojure stesso eh

andrea.crotti11:11:28

infatti, e' normale che ci sia gente che si lamenta a priori

bronsa11:11:35

zach per dire ha due ticket a suo nome, una patch sola

andrea.crotti11:11:50

giusto per rompere i maroni, magari se fosse stato completamente open non avrebbero mai contribuito comunque

bronsa11:11:06

i problemi ci sono e la frustrazione ce l'ho pure io

bronsa11:11:19

ma sono sorpreso da certe affermazioni che fanno certe persone che godono di uno stato di "semi-famoso"

bronsa11:11:19

sara` pure una rottura di coglioni contribuire a clojure ma 40 commit io ce li ho

bronsa11:11:26

non e` che c'ho avuto un trattamento speciale

nilrecurring11:11:12

Ci sono due problemi distinti: uno è la possibilità di contribuire al core, l’altro è la trasparenza della roadmap

bronsa11:11:24

vedo tantissimo echo-effect non giustificabile nelle lamentele recenti

nilrecurring11:11:32

E sospetto che i semi-famosi si lamentassero della seconda

nilrecurring11:11:13

(io ho dei problemi solo con la seconda, non avendo nessun interesse a contribuire al core. Anche se i due aspetti si sovrappongono quando si parla di “influenzare lo sviluppo”)

bronsa11:11:19

che non fa altro che abbassare le lamentele "giustificabili" alla pari di sti rant

bronsa11:11:22

beh, riguardo alla trasparenza sulla road-map di clojure stesso, https://dev.clojure.org/dashboard.action e` usato

bronsa11:11:39

quello che manca e` la trasparenza su "a cosa sta lavorando rich, che non sia clojure stesso"

bronsa11:11:02

i.e. la trasparenza nel dire "sto lavorando a spec"/"sto lavorando a tools.cli" etc

bronsa11:11:29

e li` per me e` solo un problema di percezione

bronsa11:11:43

i.e. non dicendo su che librerie nuove stanno lavorando, la percezione e` che non ci stiano lavorando

nilrecurring11:11:47

È molto importante anche per il coordinamento: se la community sapesse che stanno lavorando su determinate cose allora il focus potrebbe andare su qualcos’altro

nilrecurring11:11:38

Perchè la situazione che vuoi evitare è che ci siano due concorrenti per la stessa funzionalità, uno dei quali è “benedetto”

bronsa11:11:36

quante volte e` successo?

nilrecurring11:11:37

E.g. vedi Schema vs spec

nilrecurring11:11:09

Prepl vs unrepl

bronsa11:11:13

eh va be`, unrpl vs nrepl allora?

bronsa11:11:45

schema vs core.typed vs altri?

bronsa11:11:54

lein vs boot vs (defunto) cake?

nilrecurring11:11:49

Lì si aumenta la competizione che va bene, ma nel momento in cui hai un “blessed” la competizione la abbatti (e.g. quanti usano un core alternativo?)

nilrecurring11:11:08

Ma come hai detto tu è solo ed esclusivamente un problema comunicativo

manuel11:11:29

è da sempre un problema comunicativo, IMHO

helios11:11:22

mi sono un po' perso nella vostra discussione

helios11:11:51

ho idea di una cosa della comunita' clojure: a volte non viene capito che questo e' un progetto di rich hickey. E basta

helios11:11:16

lui fa quello che gliene frega a lui, non e' un progetto comunitario, purtroppo

helios11:11:37

e mi danno un gran danno le persone che lo adorano, e questo cargo-cult

helios11:11:57

e chi non capisce che comunque le feature che fa, sono quello che a lui interessa e/o che puo' fare andare meglio il suo business

helios11:11:51

(ok forse sono stato un po' blunt)

nilrecurring11:11:54

E tutto questo va bene, ma poichè c’è gente il cui pane dipende da lui sarebbe il minimo che facesse broadcast di quello su cui sta lavorando :slightly_smiling_face:

helios11:11:20

si si sono d'accordissimo. Sparire per mesi e scendere con "ecco spec" come se fosse un dono Divino

helios11:11:42

e tutti quanti a usare spec come se non ci fosse un domani e si andasse all'inferno per dubitarne l'utilita' :stuck_out_tongue:

helios11:11:16

vedo molto bene "clojurists together" e clj-commons, vediamo se prende piede

helios11:11:30

comunque io non ho mai partecipato a niente sul clojure core perche' ho il feeling (ed e' un feeling) che verro' dismissed molto velocemente

helios11:11:48

e che non ne vale la candela :disappointed: e questo non fa benissimo alla community

andrea.crotti11:11:47

dire che il pane dei clojure devs dipende da Rich mi pare un tantino esagerato

andrea.crotti11:11:28

se anche dall'oggi al domani Clojure . non esistesse piu' (cosa direi molto improbabile) i vari clojure devs troverrano sicuramente altro pane :wink:

andrea.crotti11:11:09

ed e' comunque un problema di qualsiasi tool/progetto open source che usiamo

andrea.crotti11:11:24

la gente dipende molto di piu' da OpenSSL che da Clojure ad esempio

andrea.crotti11:11:06

e non e' che ci stiamo sempre a preoccupare di come tutti le community dei 1000 progetti open source da cui dipendiamo sono gestite (o se ci sono del tutto)

nilrecurring11:11:18

Quando cerchi un lavoro o un progetto i requirements di solito sono su 1. anni di esperienza e 2. linguaggi

nilrecurring11:11:46

Non sul fatto se usi OpenSSL o no

andrea.crotti11:11:48

mah dai la gran maggioranza dei Clojure devs viene da altri linguaggi

andrea.crotti11:11:40

il problema magari e' che non si vuole tornare a lavorare con altri linguaggi, ma dire che non si trova lavoro e' un po' ridicolo per me

helios11:11:50

ni, nel senso che non si sta parlando che clojure scomparira' e nessuno puo' piu' programmare in clojure. Anzi, se domani Rich venisse colpito da un bus non e' che non puoi fare piu' lein new project-name o continuare a fare tutto quello che facciamo oggi. Magari nessuna nuova "feature" viene sviluppata (facciamo come TeX in cui ogni bug diventa feature alla morte di Knuth :stuck_out_tongue:) . Pero' in un certo senso la mia livelihood dipende anche dalle scelte di Rich: ora da freelancer mi tocca per forza sposare clojure.spec e deps.edn perche' tutti quanti lo adottano immediatamente.. ma questo non e' un problema di rich, piu' della community

helios12:11:23

E una cosa che mi e' sempre piaciuta in clojure (e qualcuno ha menzionato nelle discussioni su reddit) e' che clojure e' fantastico per quanto e' "library-friendly". E' bello modulare in tante cose e se non ti piace puoi decidere di non usare una libreria, o farne un'altra. Quindi il problema non e' tanto nel linguaggio stesso o su come e' costruito (altri linguaggi fanno scelte meno backwards compatible ed e' un bel problema)

helios12:11:06

e' piu' un problema di comunicazione: non si sa esattamente quale sia la vision, e frasi del genere if it doesn’t matter to Rich, it won’t get in, pur essendo tecnicamente vere non fanno venire una gran voglia di coinvolgersi nello sviluppo del linguaggio

andrea.crotti12:11:02

eh boh appunto per come e' library friendly c'e' talmente tanto lavoro interessante da fare su libraries e tools

andrea.crotti12:11:23

che c'e' abbastanza da fare comunque

helios12:11:43

queste sono le discussioni su reddit: https://www.reddit.com/r/Clojure/comments/a0lalh/timothy_and_stu_on_why_its_hard_to_contribute_to/ (partecipano anche @yogthos @alexmiller e @blueberry)

bronsa12:11:39

chi sarebbe blueberry?

helios12:11:51

dragan djuric, uncomplicate

helios12:11:05

citato come esempio, visto che in un certo senso ha rimpiazzato core.matrix

helios12:11:09

(per quello pensavo fosse utile)

bronsa12:11:59

FWIW core.matrix non ha mai fatto parte di clojure contrib, nonostante il nome e il namespace segment

helios12:11:54

thanks :stuck_out_tongue: non sapevo

andrea.crotti12:11:08

e' sicuramente un peccato che librerie in core typo core.async non siano tenute meglio

andrea.crotti12:11:31

ma questo e' problema di tutti i linguaggi, anche in Python quando qualcosa arrivava in core era praticamente morto

andrea.crotti12:11:41

perche' ogni cambiamento diventa piu' difficile

andrea.crotti12:11:27

nel caso di Clojure il problema e' infinitamente piu' semplice visto che non ci sono cosi tante librerie in Core come in Python per esempio

andrea.crotti12:11:17

ma tante librerire progetti muoiono tutti i giorno anche se non in core

justalanm12:11:50

Sono perfettamente d'accordo, era proprio quello che intendevo con gli esempi più in alto, ovvero che anche tante "vie di mezzo" già citate in realtà molto spesso si traducono in: se Linus o Guido o Rich o chi per loro pensano che una cosa sia sbagliata o inutile o controproducente non verrà presa in considerazione, punto. Il dire che sono modelli alternativi perché distribuiscono un po' di "zucchero" lasciando fixare alcuni bug o aggiungere microfeature alla community è ipocrita. Tanto alla ciccia ci penserà qualcun altro comunque

justalanm12:11:35

Poi sicuramente la comunicazione non è mai stata molto il loro forte e potrebbero tranquillamente abbassare i toni e provare a dare un po' più di "zucchero" in giro anche loro, ma il resto rimane comunque lo stesso a mio avviso

helios13:11:23

o anche delegare piu' attivamente altre lib nella core che non sono piu' considerate core (core.match per esempio, menzionato nella discussione su reddit)?

bronsa13:11:25

mi sa che qua per le contrib lib c'e` un po' di confusione

bronsa13:11:41

le contrib lib tipo core.match non fanno parte del set di liberie controllate da cognitect

bronsa13:11:58

se qualcuno vuole sviluppare core.match, contatti david nolen

bronsa13:11:10

come se qualcuno volesse tools.analyzer, basta parlare con me

bronsa13:11:31

le contrib lib in "mano" a cognitect sono core.async tools.deps & co

bronsa13:11:54

il resto sono librerie normalissime con developer indipendenti, solo sotto la clojure org

helios13:11:04

ah, ecco :stuck_out_tongue:

helios13:11:29

@bronsa a me e' ancora non chiarissima la distinzione: non voglio burocratizzare niente ma come si decide se qualcosa entra nella clojure org?

helios13:11:48

io onestamente finora stavo associando core.X => deciso da cognitect (e rich)

helios13:11:04

e' un retaggio del clojure della prima era?

bronsa13:11:12

lo si richiede

bronsa13:11:47

se stai sviluppando una libreria e vuoi farla diventare contrib, basta chiedere nella ML di clojure-dev

bronsa13:11:02

se rich decide che va bene, diventa una contrib lib

helios13:11:07

si ma che differenza c'e' fra contrib e non contrib?

helios13:11:21

ok :slightly_smiling_face:

bronsa13:11:22

nient'altro

bronsa13:11:41

il fatto che una libreria stia in contrib non vuol dire che sia blessed o altro

bronsa13:11:04

personalmente le mie liberie stanno in contrib perche` sono dipendenze di altre liberie contrib (core.async, clojurescript), e quindi burocraticamente devono esserlo

helios13:11:15

ah, ecco. Non avevo mai approfondito questa distinzione. Thanks!

helios13:11:47

in realta' e' stato molto diplomatico tim :stuck_out_tongue:

reborg13:11:36

Siamo al punto in cui ci si vergogna di essersi presi Clojure un po’ troppo a cuore e non aver mantenuto un certo distacco.

reborg13:11:16

(parlo sempre del punto di vista del committer, non del pubblico in generale)

bronsa13:11:16

eeeeeh, non so

bronsa13:11:20

metafora terribile in arrivo

bronsa13:11:52

se ti innamori di una ragazza e non contraccambia, troveresti razionale/corretto prendersela con la ragazza?

helios13:11:20

no infatti la prossima volta ti prometterai di non caderci piu'

helios13:11:23

(e ci cadrai ancora)

helios13:11:48

pero' si metafora un po' terribile @bronsa :smile:

bronsa13:11:20

che poi voglio bene a tim e tutto, ma pure lui ha 0 patch su jira per clojure eh

bronsa13:11:40

fatico un po' a capire certe persone esattamente di cosa si stanno lamentando, in pratica

reborg13:11:07

parla di semantica di chiusura di channel in core.async, immagino abbia tentato di dire la sua

bronsa13:11:08

eh ho capito ma non ha mai effettivamente messo in atto proposte/patch concrete

bronsa13:11:18

possibilmente assumendo che sarebbe stato tempo perso, certo

bronsa13:11:48

ma quella e` un'assunzione fatta, non necessariamente la realta`

bronsa13:11:04

contribuire e` difficile doloroso e lento, non impossibile

reborg13:11:45

Comunque se Clojure vuole rimanere zittella e non sposarsi… non c’e’ problema. Si rischia di diventare un po’ meschini ecco tutto :slightly_smiling_face:

mdallastella14:11:05

@bronsa non c'è una diretta correlazione tra patch e "amore per il linguaggio", imho. A me Clojure piace ma non credo sarei in grado di controbuire al core. Ciò detto, mi farebbe piacere che chi ha la capacità/tempo di farlo lo possa fare. La chiusura attuale può portare a scoraggiare contributor, magari anche molto validi, a contribuire appunto.

helios15:11:08

@mdallastella hai rispecchiato il mio pensiero perfettamente :+1:

bronsa15:11:42

>>Ciò detto, mi farebbe piacere che chi ha la capacità/tempo di farlo lo possa fare. e lo puo` fare, accettando che ci vorra` pazienza >>La chiusura attuale può portare a scoraggiare contributor, magari anche molto validi, a contribuire morto un papa se ne fa un'altro eh, di gente che ha ragequittato si parla di meno di una dozzina

richiardiandrea17:11:59

La butto qui la mia, tra amici Italiani, che boh non penso sia chissa' che: a parte il melodramma c'e' sicuramente qualcosa da limare per fare in modo che si possa migliorare - migliorare le cose e' sempre positivo no? Ho scritto anche su Reddit che mi sembra impossibile che tra persone civili al giorno d'oggi nessuno voglia anche solo considerare compromessi. Questa e' la cosa che mi sconvolge di tutti i thread. Solo poche pose persone hanno cercato di proporre alternative e l'hanno presa molto su personale... Il thread che mi e' piaciuto di piu' e' stato: https://www.reddit.com/r/Clojure/comments/a0lalh/timothy_and_stu_on_why_its_hard_to_contribute_to/eaipxg2/

richiardiandrea17:11:15

dove si parla di soluzioni

nilrecurring17:11:03

Concordo, anche il mio thread preferito :+1: Mi sembra che infatti sia l’unico minimamente costruttivo

lucio23:11:02

Qualcuno ha esperienza nell’usare clojurescript per mobile apps??