Malli betegner seg selv som en “well matured alpha”, så de har alibi for å gjøre breaking changes sånn sett. Forøvrig ser de siste endringene ut til å hovedsaklig være “minor breaking”, så jeg klarer ikke helt å irritere meg over det gitt at alternativet var å halte videre med kode som har forvirrende oppførsel (feks https://github.com/metosin/malli/pull/942) At de dropper støtten for 1.10 syns jeg derimot er rart ettersom det kun ser ut til å være fordi man begynte å bruke random-uuid 😅 🙈 Når det er sagt så får jeg bare gjenta det jeg sa i en annen tråd; https://clojurians.slack.com/archives/C061XGG1W/p1695382274382419. Syns clojure.spec er mye mindre ergonomisk å bruke.

ser ut som alle ønsker om å få noe som ligner på sterk typing fører til brekking av bakoverkompabilitet 😂 Med unntak av Kotlin? Scala driver vel og brekker stadig vekk

Noen av disse minor breaking-endringene foretrekker jeg nok dersom alternativet bare er å fikse merkelig oppførsel med https://github.com/clojure/clojure/commit/ade22645ba5dbf4c0d8115b19938af96d6fb4cd5. Men det er jo mer tilgivelig å gjøre endringen og akseptere litt bakoverknekk for et bibliotek som er i alpha enn det er i et språk som fungerer som grunnlaget for et økosystem. Vet ikke helt om koblingen til sterk typing er riktig her, men det har nok litt med at når man driver med datavalidering og typing så treffer man på ganske mange problemstillinger som man normalt slipper å ta stilling til? Som @U04V5VAUN nevner med at malli er ikke-trivielt så er nok også litt av problemet for malli at det favner ganske mye, så det blir også ganske stor bug-overflate 😅 Ikke bare driver man med schema-validering, men man genererer swagger, eksporterer til plantuml, har schema-inference, tre syntakser osv. Det er mye her jeg ikke bruker i det daglige. Kjernen kunne kanskje blitt slanket litt?

Jeg syns hele poenget med "alpha" forsvinner når det har gått 3 år siden "first stable release" og brukermassen er ikke-triviell

Folk får ta sine egne valg, jeg holder meg unna

liker teknikken til nextjs og forsåvidt også Kotlin, ting som slippes som ikke er ansett som stabilt får knotete navn, typ unstable_cache osv

Er ikke uenig i at alpha blir litt meningsløst etter x antall år 😅

Har på følelsen at “alpha” brukes som et frikort for å utsette å slå fast at API-et er stabilt. Kanskje fordi man ikke har brukt hengekøya godt nok. Er skyldig i dette selv med Proletarian, som er alpha på tredje året nå. 😅 Det er en avveining der: skal jeg utsette brukerne mine for brekking (en liten håndfull ganger, kanskje), eller skal jeg utsette dem for et suboptimalt API for all framtid? Noe av greia med åpen kildekode er jo å få tilbakemeldinger og gjøre forbedringer.

> Har på følelsen at “alpha” brukes som et frikort for å utsette å slå fast at API-et er stabilt. 🎯

Jeg tror du presenterer en delvis falsk dikotomi @U06BEJGKD. Du må ikke ha et suboptimalt API for all framtid - du kan fortsatt legge til nye, bedre funksjoner og abstraksjoner. Bare slutt å fikle med de du allerede har gitt folk.

Det er ikke en dikotomi, men et spektrum med flere dimensjoner. Her er noen av tingene jeg ville tatt hensyn til hvis jeg vurderte å brekke noe jeg hadde publisert: • Er det mange eller få brukere av tingen jeg ønsker å brekke? • Er det en grunnleggende ting som er feil, eller en mer overfladisk ting? • Vil endringen gjøre meg (og andre) i stand til lage bedre abstraksjoner seinere? Jeg vet ikke, har ikke vært i denne situasjonen selv, men kan forestille meg situasjoner hvor det ikke er lett å si hva som er riktig. Selvsagt, som alle andre i Clojure, setter jeg pris på at stabile API-er er en verdi man setter høyt hos oss. Hvis man er tvil bør man la være å brekke noe.

I tilfellet Malli ville følt på, hvis jeg var forfatteren av biblioteket, et større og større press om å ikke brekke noe, all den tiden biblioteket tas mer og mer i bruk. Det er afferensen som kommer og tar vekk mulighetene dine for å gjøre endringer.

Ingen regel uten unntak. Akkurat her tenker jeg at malli er i godt selskap. Clojure kommer med spec1 i clojure.spec.alpha, som også brukes internt i core: => (let [nada]) Syntax error macroexpanding clojure.core/let. [nada] - failed: even-number-of-forms? at: [:bindings] spec: :clojure.core.specs.alpha/bindings > So I know people are wondering: oh, where is spec? When is it going to be finished, or whatever? It is going to be finished when I figure this out. Og så er det vel mer eller mindre annonserthttp://bl.ai Maybe, Not? at det hammockes med breaking changes som en eller annen gang kanskje utdeles i spec2. Den jobbes det innimellom med i clojure.alpha.spec(!), riktignok en stund siste oppdatering. For innebygget spec kan man som core bruke den gamle alpha-versjonen som man vet har designutfordringer og (kanskje) skal erstattes med noe annet. Eller kombinere med malli i mellomtiden, da med buy-in på at de (også) fremdeles er mature alpha og ikke har stabilisert API-et sitt ennå. Så kjører jeg 1.12.0-alpha4 og ikke “Clojure 2018” (1.10:) Stabiliteten i core virker også andre veien: Det er ganske trygt å oppgradere! Et annet nylig eksempel: structured concurrency i JDK. Har vært i incubator og preview over flere versjoner, og endrer noen typer mellom 20 og 21 etter at man har fått enda bedre innsikt. Jeg er helt med på growth > breakage, og liker samtidig det pragmatiske når man er i preview/alpha. Både core og JDK har stabilitet som kjerneverdi, men selv der trenger man å prøve ut nye ting. Noen her som bruker pathom_3_, også i alpha?

Når det gjelder den JDK-endringen så syns jeg de er gode på å skille tydelig mellom hva som er eksperimentelt og hva som er ferdig/produksjonsklart.

Og ja, Clojure bomma åpenbart litt med spec.

Liker også at det ikke er noe ekstra avhengigheter! 👏 Og at Celsius/Fahrenheit ble holdt utenfor. Husker en morsom øvelse med måleenheter i en objektorientert workshop, hvor deltakerne ble “lurt” til å prøve og implementere plus for C° og F° og lærte seg at det ikke er så lett 😅

Ja, ble først lurt selv 😅 Begynte å skrive om hele greien da jeg innså at det ikke funket for F°og C° . Men så tenkte jeg heldigvis grundigere over det