Thread: https://twitter.com/gsnewmark/status/1065673744507645953

collegato, in fondo: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9

e: https://twitter.com/cemerick/status/1067111260611850240

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

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

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

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

@andrea.crotti hai un esempio?

l'Italia, probabilmente

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

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)

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

(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)

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)

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

si certo ma se stampi la lista dei pragma disponibili sono 225 pagine https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#parallel-list-comprehensions

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)

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

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

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

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

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

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

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

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.

(mi riferivo al commento di @nilrecurring)

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

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.

Si si Chad riflette totalmente anche la mia opinione

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

La firmerei

idem

giornissimo kaffeèèèèè

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? 😆) 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

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?

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

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)

È 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.

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).

>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

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.

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

mi sembra un po' una visione idealistica della community

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

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

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

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

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

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

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

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

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

non e` che c'ho avuto un trattamento speciale

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

vedo tantissimo echo-effect non giustificabile nelle lamentele recenti

E sospetto che i semi-famosi si lamentassero della seconda

(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”)

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

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

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

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

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

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

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

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

quante volte e` successo?

E.g. vedi Schema vs spec

Prepl vs unrepl

eh va be`, unrpl vs nrepl allora?

schema vs core.typed vs altri?

lein vs boot vs (defunto) cake?

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?)

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

è da sempre un problema comunicativo, IMHO

mi sono un po' perso nella vostra discussione

(tldr;)

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

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

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

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

(ok forse sono stato un po' blunt)

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 🙂

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

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

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

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

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

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

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

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

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

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)

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

Non sul fatto se usi OpenSSL o no

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

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

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 😛) . 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

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)

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

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

che c'e' abbastanza da fare comunque

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)

https://www.reddit.com/r/Clojure/comments/a0pjq9/rich_hickey_open_source_is_not_about_you/

chi sarebbe blueberry?

dragan djuric, uncomplicate

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

(per quello pensavo fosse utile)

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

thanks 😛 non sapevo

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

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

perche' ogni cambiamento diventa piu' difficile

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

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

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

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

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

(cfr: https://www.reddit.com/r/Clojure/comments/a0lalh/timothy_and_stu_on_why_its_hard_to_contribute_to/eaj0rbi/)

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

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

se qualcuno vuole sviluppare core.match, contatti david nolen

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

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

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

ah, ecco 😛

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

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

e' un retaggio del clojure della prima era?

lo si richiede

https://dev.clojure.org/display/community/Guidelines+for+Clojure+Contrib+committers

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

se rich decide che va bene, diventa una contrib lib

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

processo

ok 🙂

nient'altro

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

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

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

risposta di halgari: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9#gistcomment-2770124 🍿

🍿

in realta' e' stato molto diplomatico tim 😛

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

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

eeeeeh, non so

metafora terribile in arrivo

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

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

(e ci cadrai ancora)

pero' si metafora un po' terribile @bronsa 😄

:)

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

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

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

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

possibilmente assumendo che sarebbe stato tempo perso, certo

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

contribuire e` difficile doloroso e lento, non impossibile

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

@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.

@mdallastella hai rispecchiato il mio pensiero perfettamente 👍

>>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

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/

dove si parla di soluzioni

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

yeah...

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