This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-24
Channels
- # beginners (17)
- # calva (29)
- # clojure-europe (37)
- # clojure-germany (11)
- # clojure-norway (24)
- # datalevin (11)
- # datascript (2)
- # fulcro (13)
- # hoplon (8)
- # humbleui (7)
- # hyperfiddle (6)
- # keechma (2)
- # malli (5)
- # nextjournal (4)
- # off-topic (10)
- # polylith (12)
- # releases (1)
- # shadow-cljs (13)
- # squint (106)
- # yamlscript (1)
Jeg så The Value of Values i går og der sier Rich Hickey at vi ikke trenger å bruke PLOP (som han kaller det) lengre, og nevner at vi utviklere er vant med versjonskontroll på så mye og å logge diverse events. Mitt spørsmål er da rundt databaser. Mener han da at det skal/burde være en form for versjons historikk i databaser, så alle verdiene faktisk kan være verdier og ikke objekter (places)? OG er det noe sånt i f.eks. Datomic?

Han sier jo det med at hvis én skifter epost, så er det jo fortsatt riktig at han hadde en annen epost i går enn i dag. Så da må man vel legge til en tidsplassering til verdiene så fakta blir bevart, eller i hvert fall en versjonshistorikk som vi har i git
Stemmer, Datomic løser nøyaktig dette problemet. Datomic er immutable, så hver gang du "sletter" eller "skriver over" data så lager du kun ny data. Det gamle er alltid tilgjengelig for deg når du trenger det. Datomic er amazing 😄
Men det ligger vel i en annen referanse da. Du (eller Hickey) nevnte at Datomic har 3 refs. Hva er de 3 refs? Den ene er vel de faktiske nåværende data. Den andre er da "versjonshistorikken". Hva er den tredje? Eller er det ikke riktig forstått? 🙂
En "ref" i denne sammenhengen er noe som kan muteres, feks et atom. Det handler mer om at man skiller på "computations" og "actions" (ref grokking simplicity). Så selv i et komplisert system som en database kan man skrive stort sett funksjonell kode og ha de tingene som endrer seg på få plasser.
En ref/reference peker på noe, i kontrast til en value, som alltid vil være det samme.
Okay, skjønner, men hva er de 3 refsene da? Det er vel heller ikke datastrukturen (id <data>, key <data>, value <data|ref>)
Nei, akkurat hva de er vet jeg ikke. Det er et eksempel fra implementasjonen til Datomic, ikke hvordan den fungerer.
Jeg prøver her å oversette ‘rund forvirret’ til svensk, men jeg tror ikke man kan konstruere noe så pent med våre ord. 😊
@mathias.iversen487 kort fortalt så legger Datomic til to faktum: • en retraction av den gamle verdien (altså et nytt faktum som forteller at den gamle e-posten ikke lenger gjelder) • en addition av den nye verdien Så vil query og entitets-APIet nærmest gi deg et "materialised view" hvor disse tingene er hensyntatt, så du selv slipper å tenke på det, men kan alltid gå tilbake og se på hele historikken ved å se på hele settet med slike faktum.
Det er også derfor vi i Datomic kan gjøre db/as-of
med en instant, og få se nøyaktig hvordan databasen så ut på det tidspunktet (eksempelvis i det øyeblikk vi fikk en exception). Det er bare et filter over settet med faktum.
WebGPU kommer til å bli stort, folkens! Et generelt grensesnitt for 2D- og 3D-grafikk bygget som et lag over Vulkan (arvtageren til OpenGL), Direct3D (Microsoft), og Metal (Apple). Hvorfor forteller jeg dere om dette? Jo, fordi WebGPU funker i nettleseren (det er arvtageren til WebGL) og det har et JavaScript API, som antagelig også funker via ClojureScript. Vi har dermed tilgang til GPU-er via WebGPU, som er enda enklere og raskere enn WebGL. Det er fortsatt early days, men det ser svært lovende ut!

Jeg dumper noen av mine notater her for de som er interessert:
https://youtu.be/oIur9NATg-I?si=gTapLplkHUkTdSeV oppsummerte historien bak alle graphics APIs og hvordan de relaterer til Vulkan og WebGPU. Den var nyttig for meg som lå tolv år bak på utviklingen 😅 Og https://youtu.be/YinfynTz77s?si=PslHdppnOeQ53aM5 mer spesifikt, samt generelle graphics-konsepter.
WebGPU er enklere å bruke (og er ikke kun for web; dårlig navn). Men sånn jeg forstår det oppnår man ikke mer enn 80-90% av ytelsen til native graphics via Direct3D og OpenGL (via Vulkan). Men ytelsen til WebGPU kan være god nok til de fleste formål, også spill som ikke må være hyperrealistiske.
Vulkan er mer low-level og kalles et "GPU API," i motsetning til OpenGL som kalles et "Graphics API." https://docs.vulkan.org/guide/latest/what_is_vulkan.html#_vulkan_and_opengl gav en ganske fin sammenligning.
https://webgpu.github.io/webgpu-samples/?sample=helloTriangle kan du se flere eksempler på WebGPU. Eksempelet helloTriangle
er på 50-60 linjer kode. Jeg tror det kun funker i Chrome og kanskje Firefox enn så lenge. Safari-støtte for WebGPU er bare i https://developer.apple.com/safari/technology-preview/ enn så lenge.
Det finnes også WebGPU "native" implementasjoner for C++ (og andre språk). For C++ er de to store https://dawn.googlesource.com/dawn (laget av Google) og https://github.com/gfx-rs/wgpu-native (skrevet i Rust, men kan brukes av C++). Disse brukes som et bibliotek fra C++. Jeg fant også https://eliemichel.github.io/LearnWebGPU/index.html som viser hvordan man bruker begge de klientene fra C++.
Og Google har laget https://codelabs.developers.google.com/your-first-webgpu-app#0 på hvordan man lager Conway's Game of Life med WebGPU 🙂

Nå sitter jeg og tenker på #quil, som i dag er bygget på https://processing.org. Processing bruker OpenGL (men vil kanskje bytte til Vulcan eller WebGPU etter hvert?). Quil har en del rendering-relaterte issues. Det hadde vært veldig kult med et frittstående Clojure-orientert bibliotek for å tegne 2D- og 3D-grafikk, og jeg tror WebGPU kunne vært fantastisk til noe sånt. Typ noe à la Replicant, men for GPU-akselerert grafikk. Jeg slenger det på "haugen med løse idéer som sannsynligvis aldri blir noe av, men som det var veldig gøy å tenke på" 😅
MDN gav også mye fin informasjon, @U01PE7630AC: https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API