qualcuno ha gia’ letto http://nathanmarz.com/blog/clojures-missing-piece.html? impressioni?

L'ho appena letto

non sono minimamente d'accordo con molti dei "grandoise claim" che nathan fa

specter e` una libreria molto utile in certi use-case, che tuttavia non sono d'accordo siano cosi` comuni come lui cerca di far passare

e` certamente abbastanza generica e molto ottimizzata

ma non e` minimamente una cosa nuova o un missing piece, librerie che fanno la stessa cosa esistono da molto tempo e in molti altri linguaggi

vedi le varie astrazioni di lenses/zippers e astrazioni simili

IMHO lui sta cercando rilevanza e riconoscimento: se la sua libreria viene inclusa nel core non ci sarà un'altra libreria che tra 5 arriva e fa la stessa cosa ma va più di moda

non verra` mai inclusa in core

sono estremamente confuso dal fatto che sia sorpreso dal rifiuto

Perché sei confuso?

perche` la pretesa di avere specter in core, vs avere ring in core, per esempio?

Quando ho scritto core intendevo contrib, sry

(tralasciando il fatto che il codestyle e le varie ottimizzazioni nel codebase di specter sono questionabili)

@nilrecurring ah, nessuno gli ha detto "no" a inculudere specter in contrib

lui chiedeva di includerlo in clojure itself

(Si la sintassi è in effetti un po' strana)

as in, clojure.jar

Sono d'accordo che è un po' troppo

Ho anch’io seguito l’evoluzione di specter senza usarlo (visto presentazioni etc) e pensavo che fosse una lib con parecchio valore aggiunto per quei casi in cui uno deve fare i conti con uber-nested data structures. Ma faccio fatica a capire perche’ dovrebbe essere in core

trovo particolarmente fastidioso le false equivalenze che presenta per dimostrare quanto superiore sia specter a "vanilla clojure"

me lo sto leggendo...

il primo esempio richiede "esoteric knowledge of the internals of Clojure”… (reduce-kv (fn [r k v] (assoc r (keyword (str *ns*) (name k)) v)) {} m)

ammettendo che sia anche vero… e’ premature optimization nel 90% dei casi

^

sia chiaro, una libreria che ottimizza update/navigation di default non e` niente male

ma e` semplicemente falso il claim che quelle ottimizzazioni siano spesso necessarie

o che quel tipo di nested data structure traversal/update sia "fondamentale" per come clojure viene utilizzato

agree agree

l’avesse presa in maniera diversa forse avrebbe ottenuto risultati migliori, tipo contribuire a “core” le patch per le pecche piu’ evidenti (se esistono…) Peccato per Nathan perche’ fino ad ora mi sembrava particolarmente pragmatico ed intelligente

ah ma niente da ridire eh

specter e` incredibilmente pragmatica come libreria

l'unico problema che ho con quel blog posto e le interazioni che nathan ha avuto con la ml di clojrue a riguardo e` la pretesa di aver "scoperto qualcosa di fondamentale" e che "sia indispensabile per ogni programmatore clojure"

95% dei casi, non ho alcun interesse in quei 10ms che specter mi farebber risparmiare

95% dei casi, non ho alcun interesse in scrivere una funzione che agisca su sorted maps

anyway, attendo risposta sulla ML 🙂

95% dei casi, non ho deeply nested DS da aggiornare/traversare

@reborg la risposta di Alex Miller c'e` stata ed e` stata "no interest."

al “missing piece” che per ora ha zero answers

ah k

che se rimanesse tale sarebbe probabilmente una risposta eloquente 🙂

io dal basso della mia esperienza in clojure, quando mi capita di navigare o trasformare strutture dati highly-nested, mi viene prima di tutto il dubbio di aver creato la struttura dati in modo sbagliato... prima di cercare un modo efficiente di usarla