Clojurians Log v2

Hvordan kunne jeg funnet ut av det, uten å ha kjennskap til Batman-serien? Rating på triologier, kanskje? (hvis det finnes slike oppslag i imdb)

Heftig artikkel! Mye å ta inn 😊

Husker at Erik Meijer forenklet hele de monadiske lovene til det noe lett flåsete, men lettfattelige "if you can call flatMap on it, then it's probably a monad"

(tror han sa dette i "Principles of Reactive Programming"-kurset som Coursera tilbydte for en ti års tid siden)

> Hvordan kunne jeg funnet ut av det, uten å ha kjennskap til Batman-serien? Rating på triologier, kanskje? (hvis det finnes slike oppslag i imdb) Tror nesten det bare er noe man må gjette? Jeg har i bakhodet at Batman-trilogien har fått gode ratings, særlig The Dark Knight. Og det er ikke så mange fulle trilogier i IMDB topp 100.

kan eventuelt høre med @larskristian.marontel og @christian767 om hvordan de tok det!

🤷‍♂️ 😊 jeg vet at de filmene har høy rating (med rette!) og at den andre er den klart beste, så det var bare pattern matching som slo til 😊

Jeg resonnerte ikke noe mer enn at det nok var en trilogi, ikke frittstående filmer, og da Lord of the Rings ikke passet, var Batman-trilogien den neste jeg kom på. 🙂

Batmen!

Bingo! 🎉

Der var det mange dårlige takes gitt

Det var litt min oppfatning også. Noen av bekymringene er at foo er sårbar for refaktorering, f.eks. hvis man flytter en funksjon til et annet namespace. Men er det ikke i filosofien til Clojure at man ikke skal bryte ting? Da tenker jeg at det inkluderer flytting av kode. (altså man skal tenke seg nøye om hvis man endrer namespaces)

Må si jeg er skuffa over nivået på diskusjonen. Jeg leser stort sett bare vikarierende argumenter for "æsj, det er litt kjedelig å skrive lange navn", og ingen gode dyptpløyende trade-offs.

Kanskje du eller Magnar kan "weigh in" i diskusjonen med argumentene dere har for? Eller har dere kanskje diskuterte dette allerede i en av bloggpostene deres? Jeg dropper gjerne en lenke til dem 🙂

Ja, skal hive meg på litt senere, er litt bissi nå 🙂

synes denne tematikken er utrolig spennende. Gøy at du løfter det opp, @gar! Min historie rundt dette, i grove trekk: 1. Lik Haskell! 2. Få smak for Clojure med dynamisk utvikling og umiddelbar feedback 3. Skriv et kaos av maps og keys, mist kontroll a. (tidligere holdt typene tak i meg, nå var de borte!) 4. Innfør namespaced keywords på alt 5. opplev friksjon — det finnes nå for mange, for lange nøkkelord! kom til konklusjonen at jeg vil ha færre navnerom på nøkkelord. Mye takket være erfaringene siden jeg startet i Mattilsynet. Subjektivt mener jeg dette er den svakeste delen av "lær deg å bruke Clojure"-reisen.

Nå har jeg ikke brukt clojure i større prosjekter, men kan lett forestille meg at verden går fort i grus når man naivt bruker keywords uten navnerom "at scale". Når du sier at du vil ha færre navnerom, @teodorlu, mener du da at du ønsker å ha et lite sett med domenespesifikke navnerom?

Domenespesifikt er supert! Men vi har attributter for andre ting enn domeneting også, altså. Mer i form av at hvis attributten allerede er velkjent, bruk den velkjente attributten. Et par eksempler på sparket fra vår kode: :serveringssted/navn — alltid av type string, hvis den er definert. Kommer originalt fra Datomic-skjemaet, og hele koden kan være trygg på at dette er nettopp navnet på et serveringssted. :nats.stream/name — navnet på en NATS-stream. Definert i et bibliotek som ligger utenfor applikasjonskoden vår. Men da tar vi det i bruk, direkte. Så vi driver ikke og finner på nye attributtnavn når vi allerede har et velkjent et! I min tidligere (naive) bruk av nøkkelord med navnerom, hadde jeg masse ::name rundt omkring. Det krever at folk skjønner akkurat hvilken informasjonsmodell som gjelder for en enklelt fil. Som ofte er fullstendig unødvendig, og heller til hinder! Hvis man i stedet for kan bestemme seg tydelig for hva et attributt betyr (feks serveringssted/navn ellert nats.stream/name), ett sted, blir det lettere for alle å lese koden overalt. Hvis Christian ser at jeg henter ut :nats.stream/name fra et map, skjønner han hva jeg prøver å gjøre. Hvis jeg henter ut et ::name fra et map, må han lære seg det lille DSL-et jeg har laget for akkurat det navnerommet jeg er i — og det er kjempedumt! — Så: • Alt blir lettere hvis man bruker attributtene som allerede er velkjent i systemet. • Det er lettere å "ta vare på" de velkjente attributtene i systemet hvis det ikke er sjukt mange av dem, og at de ikke har sjukt lange navn Jeg opplever at ::min-attributt-notasjonen dytter deg litt i retning av for mange, for lange attributtnavn. Kjapt rett fra koden jeg er i nå:

::fileset
;; => :matnyttig.page-admin/fileset

Takk for forklaringen! Kjempenyttig å ta med seg 🥰

@christian767 / @magnars — jeg hører forresten gjerne om dere er enige i det jeg skriver over om navn og navnerom på attributter (ved en passende anledning)! Det er jo ting jeg føler jeg har lært etter jeg startet å jobbe med dere, så hvis det er skivebom er det litt synd 😄

Jeg er stort sett enig 😊 Jeg har selv ikke så store kvaler med men tror jeg har brukt det mest i biblioteker. Datamodellen i appen vår har syntetiske navnerom, for det gir ikke mening å lime de til en teknisk implementasjon.

Jeg bruker :: -formen for å formidle "dette er privat til dette navnerommet" og foretrekker forøvrig navnerom på keywords som ikke har basis i namespaces i koden. 🙂

Å effektivt kunne søke etter keywords er nesten hovedårsaken til at jeg klamrer meg til LSP. Utfordringen er ikke bare hvordan keywords kan uttrykkes som literals i koden, men også oppslag og destructuring. Søker du opp bruk av keyword med LSP får du også treff på dette. Helt uvurderlig, særlig når man har namespaced keywords (som for øvrig også er uvurderlig i store kodebaser).

Før lsp "løste" vi dette ved å opte ut av litt funksjonalitet. Ikke destructure namespaced keys feks. En annen tilnærming er å søke opp namspacet på key-en du leter etter, så får du snevret ned antall filer og kan jobbe med keys der. Men eller enig med @anders - dette er en av få ting som lsp er god på.

Nyttig å vite. Det er åpenbart viktig å ha en bevisst forhold til bruken av keywords.

Det som er helt sikkert er at keywords uten navnerom fort blir "beyond repair", så alt som er viktig og går på tvers av navnerom bør ha navnerom på seg.

kondo er krutt for analyse.

$ clj-kondo --lint src --config '{:analysis {:keywords true} :output {:format :edn}}' | jet --pretty --query ':analysis :keywords'

$ clj-kondo --lint src --config '{:analysis {:keywords true} :output {:format :edn}}' > linted.edn

Wow!

Denne tråden om bruk av namespaced keywords tar litt av: https://clojurians.slack.com/archives/C03S1KBA2/p1759263727536979