jeg tenkte jeg skulle kverulere litt. Så:

(defn christian* "* - kun heltall!" [x n]
  (let [x (bigint x)
        n (bigint n)]
    (reduce + (repeat n x))))

(defn christian** "^ (**) - kun heltall!" [x a]
  (let [x (bigint x)
        a (bigint a)]
    (reduce christian* (repeat (bigint a) x))))

(let [n 300]
  (time
   (christian** n n)))

"Elapsed time: 13.098704 msecs"

😄

var visst ikke så lett å framprovosere dårlig ytelse som jeg trodde.

haha

https://youtu.be/Tq7r97G4b7Y?t=663 Tror det er dette han snakker om

Nå skal det sies at jobben min er å prøve å forstå hva Assum snakker om, så vi kan høre fra han om jeg har faktisk klart det denne gangen 😂

😁 Men det er ofte lettere å få noe forklart fra en annen person som også lærer det samme -- enn direkte fra kilden 🙂 Jeg tror i alle fall veldig mye læringsmateriell blir laget på denne måten.

Dette synes jeg er et veldig godt poeng

Jeg rakk ikke helt å skrive ferdig 🙂

aah, det forklarer saken 🙂 Hverdag, ass.

Så her er kanskje tanken at man kunne gjøre noe a la:

(defn add-somehting-better [thing]
  (add' xs thing))
(defn commit! []
  (emit :things-added (since-last-commit xs)))

(doseq [t (range 10000)]
  (add-something-better t))
(commit!)

og det å kjøre commit! 10000 ganger er en "åpenbart idiotisk ting"?

ref rich hickey "fast interfaces operate with batches"? (mener jeg har hørt det fra en talk et sted, men husker ikke hvilken, kanskje noe datomic)

Problemet med hva som er smart og hva som er idiotisk avhenger jo hvor en selv er på skalaen 🙂

Å kjøre commit! 10000 ganger frarøver i allefall mottageren muligheten til å gjøre noe som helst smart.

“Fast interfaces operate with batches” - interessant! Tror ikke jeg har hørt det før, men jeg har internalisert at det ofte er lurt å tenke på “batch-caset” først, og så håndtere “jeg har bare én ting”-caset som en collection med en ting i.

Jeg tenker feks på at datomic.api/transact tar en liste av transaksjoner https://github.com/kristianmandrup/datascript-tutorial/blob/master/datascript.md

Et annet sted hvor dette appliserer er på api design. Man har en skala på hvor chatty et api er, altså er det mange små requester eller er det færre store requester. Mange små requester gir ikke api’et samme mulighet til å forstå klientens intensjon, og dermed er det vanskeligere for api’et å foreta optimaliseringer.

Man kan tenke seg:

GET /api/all-foos
GET /api/all-bars
GET /api/all-bazes

GET /api/initial-data-load

Hva tenker dere om JSON+REST vs graphql vs EQL i Ardoq? Er det en norm? Feks GraphQL har jo litt "du kan be om mye i batch hvis du vil" innebygget.

Vi er fortsatt der at vi gjør det GraphQL var ment å løse, nemlig lager en gjeng med ad-hoc endepunkter som sikkert kunne vært uttrykt som et query.

Man ser jo at hey, et endepunkt /api/q er en fin ide på papiret, men man ender opp med /api/q?templateQueryId=8 fordi det er enklere hvis man vet noe om hva som spørres etter.

Det er litt som over, i et generelt query er det vanskelig å forstå kallerens intensjon, men hvis man har spesifike, navngitte queries er det lettere. Men man kan få en eksplosjon av navn 🤷

Jeg synes API-design er vanskelig.

No shit

Og det er vanskeligere når du designer et åpent api som alle kan bruke.

Er "SSE" server sent events? https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

jepp

Stemmer. På den måten får klienten dataene så fort serveren har dem klare, istedenfor å få alt samtidig, som ville innebære å vente på det tregeste datapunktet.

Ja, veldig fornøyd med den løsningen

Stemmer - tenkte først at dere snakket om ZombieCLJ. For det er vel websockets. Men dere må kanskje kode litt "jobb-greier" dere også - ikke bare kosekoding 😄

Det stemmer 😅