fint satt ord på noe jeg også grubler mye over! Et navnerom er en liten ting som lever sitt eget liv, og som ikke trenger å passe inn i noen taksonomi. Taksonomi-design er der alt går galt, og det er umulig å få riktig (men en taksonomi prøver alltid å fremstå som den er riktig og har dermed innebygget dissonans?) Veldig det samme med Datomic, der skriver du ustrukturerte navnerom, ingen taksonomi, all struktur kommer i business-spesifikke spørringer på navnerommene dine

også kjent som “decomplecting”?

> men en taksonomi prøver alltid å fremstå som den er riktig og har dermed innebygget dissonans ➕ ➕ ➕

Godt poeng med datomic!

Problemet med en taksonomi oppstår kanskje fordi det ofte er mulig å lage flere taksonomier av en gitt mengde råstoff, men når du har valgt én så må du forholde deg til den, og du har ingen anledning til å representere de alternative taksonomiene som ville delt inn råmatrialet på en annen måte?

Kronglete formulert, og kanskje feil. Men altså: Du kan bare plassere en mengde rådata inn i ett konkret hierarki om gangen.

Å ikke bygge hierarkier inn i modellen gir deg heller muligheten til å konstruere dem når de trengs, ved bruk

ah, dette er fint. Minner om det Rich Hickey sier om aggregater, og at et bilhjul trenger å gi mening uavhengig av kontekst, og ikke bare i konteksten bil

og at aggregater skaper problemet som “jeg har en maybe sheep”

ja, det var sikkert det budskapet jeg hadde i bakhodet 😅 Usikker på om det var @U3X7174KS sin opprinnelige tanke

taksonomier er en håpløs intellektuell øvelse, men noen ganger har man flaks og får til en taksonomi som matcher problemet sitt sånn noenlunde? :thinking_face:

jo, dette gir mening! (synes nå jeg) man må liksom tenke litt mer lavnivå. Og det er gjennom å tenke litt mer lavnivå man kan samle sammen de greiene man vil ha når de trengs.

byggeklosser heller enn byggverk 🙂

så elementene i et navnerom er løsere koblet enn elementene i en taksonomi?

en taksonomi er vel per definisjon noe som forsøker å få alt inn i ett system

det er jo vanskelig å lage taksonomier. I alle fall taksonomier som ikke er feil.

Kanskje det er litt av cluet også — hvis vi bare ikke gjør det slipper vi å gjøre akkurat den feilen. Lettere å lage en ting og gi tingen et navn. Så kan vi prøve å bruke tingen sammen med de andre tingene i samme navnerom.

å totalt unngå problemer ved å gjøre ting annerledes er en rød tråd i Clojure og Datomic. Aka incidental complexity

og å påpeke for andre at noe de gjør er incidental complexity viser seg å være en rundt regnet umulig øvelse. “Du har et problem du ikke trenger å ha, som er usynlig for deg”

får lyst til å sette på “Eg ser” av Eidsvåg

Ja, dette har blitt mitt livs store mysterie

“hmm, jeg har aldri hatt problemer med at all data er muterbar i javascript” - og det er jo en korrekt virkelighetsoppfattelse, du bare merker det ikke :S

> og å påpeke for andre at noe de gjør er incidental complexity viser seg å være en rundt regnet umulig øvelse. “Du har et problem du ikke trenger å ha, som er usynlig for deg” Her tror jeg utfordringen er å tilby en alternativ måte å forstå verden på (uten taksonomier) heller enn å fjerne incidental complexity.

Når jeg lærer Clojure, lærer jeg bedre måter å gjøre ting på!

å drive andre til omvendelse med argumenter og logikk er vel ca. ikke en ting. Tror det beste man har er å stå frem som et godt eksempel på et eller annet vis

ja

“se hvor mye vi kan få gjort når vi følger disse prinsippene”

mer problemløsning, mindre vifting med armene!

og akkurat det er jo forsåvidt et slags mysterie - hvor er alle disse startupene som er milevis raskere enn andre, fordi de slipper all denne incidental complexityen? Ikke at det er eneste målestokk, men det virker på en måte som det mangler “resultater” på noe vis. Kanskje til dels fordi vi ikke måler software-teams på den måten, og til dels fordi det kanskje faktisk er kjappere å ansette 100 JavaScript-folk til å kjøre ut ting?

> og akkurat det er jo forsåvidt et slags mysterie - hvor er alle disse startupene som er milevis raskere enn andre, fordi de slipper all denne incidental complexityen? Fordi du tenker at man kanskje burde klare å levere fortere når man har jobbet litt sammen, og har eksisterende kode man kan bygge på?

usikker på hvilken metrikk man skal gå etter - men hvis Clojure faktisk fjerner incidental complexity, hvorfor er det ikke mere utbredt siden det er økonomisk/lønnsomt å slippe problemer?

men:

tja — clojure er jo ikke den eneste måten å bygge kode på heller. Når man sampler mellom alle bedrifter som finnes, tror jeg “har clojure vs har ikke clojure” drukner litt i “har teknologiteam som faktisk funker og kode man faktisk klarer å bygge videre på”

et argument jeg leste https://www.oilshell.org/blog/2022/03/backlog-arch.html, i mine ord: > det er to måter å bygge store systemer på. > den ene er med typer på alt sammen. > den andre måten er å ha en “smal midje med data” og operasjoner som bygger på den smale midjen. jeg føler liksom at jeg liker smal midje (clojure, unix) bedre. Men jeg klarer ikke avfeie at den andre metoden funker også. Windows ble jo en hakket større kommersiell suksess enn Unix.

Og midt oppi alt dukket nebbdyret opp.

the taxonomy tax 🔥

thinking in types: the tax of taxonomies