Morn!

Jeg setter pris på at du sløyfet "God" foran der, @msolli 😅

Morn morn!

God morgen!

God morgen!

Som dere sikkert har fått med dere så har jeg fått et skikkelig crush på Richard Feldman og hans Software Unscripted. I https://podcasts.apple.com/no/podcast/software-unscripted/id1602572955?i=1000575749611 sa de noe som fikk meg til å stusse. Så greia var at det er så fint med typer fordi da er det så mye enklere å bytte ut ting, og eksemplet her var å bytte ut f.eks et routing bibliotek i frontend’en. Vi har nylig byttet ut routing biblioteket i backend’en og jeg har et par observasjoner: 1. Å bytte fra compojure til reitit bar ikke “bare” å mekke på noen typer. Hvis det var det, hva ville da poenget vært? 2. Vi gjorde dette stegvis, ns pr ns over en periode på 6 måneder tror jeg 3. Vi visste eksakt hvor vi brukte compojure og hadde ingen overraskelser av typen, jøss, bruker vi routing biblioteket vårt der? Så det jeg lurer på er liksom om det er slik i andre kodebaser at routing biblioteket styrer med greier over alt og at det derfor er et helvete å bytte ut? Et annet eksempel fra den episoden er bytting av mysql driver. Igjen. Hos oss er dette begrenset til svært få ns’er og det er uansett ikke bare å bytte typer hvis man skulle gå fra jdbc.next til noe annet. En annen ting som slår meg er at vi i Clojure verdenen jobber med ganske spissede biblioteker som gjør en ting og den tingen gjør det bra. Det gjør at (iallefall her hos oss) skriver en del lim-kode for å få til den ergonomien vi er ute etter, noe som også medfører at vi i større grad isolerer tredjeparts kode til noen relativt få steder. Eksempel på dette er at vi har ardoq.logger som er et tynt wrapper rundt timbre nå, men som var et tynt wrapper rundt noe annet før. Det gjorde at det var, om ikke trivielt, i allefall ganske enkelt å bytte fra det vi hadde før til timbre

tenker det samme, i Kotlin-boka mi skrives alt i “Clojure style”, og funksjonene som håndterer businesslogikk får inn typer som ikke har noe med routing-biblioteket å gjøre, og returnerer en type som ikke har noe med routing-biblioteket å gjøre, nettopp for å isolere all business-logikk fra routing-bibliotek. Egentlig ikke for å bytte routing-bibliotek senere (selv om det også gjøres i boka), men mest for å enkelt kunne faktisk kalle disse funksjonene fra tester osv. Og egentlig litt for at det er fint å kunne skrive business-logikk uten å ha routing-biblioteket i hodet. Vil si at det er patternet, ikke typene, som er essensielt her

Jeg tenker ofte at det er fint å skrive kode som om noe skulle kunne byttes ut, selvom vi aldri kommer til å gjøre det. En annen greie som gir fin separation of concerns er å late som om man skriver f.eks backend’en for to ulike frontender ie, både for REST og for desktop.

Da vil man se at rest-api-laget blir ganske mye tynnere.

og at authz blir mye mindre web-avhenging.

ihvertfall hvis kostnaden er lav, i Kotlin-boka trengte jeg 80-ish linjer med lim for routing-agnostisk businesslogikk (litt ekstra i Kotlin siden man må tilfredsstille et typesystem), men et helt generelt pattern er det vel kanskje ikke. Eller bruker dere hibernate sånn at dere kan se på databasen som en objekt-graf og bare kan bytte ut mysql med postgres når dere vil? 😄

eller hvis vinningen er høy av å ikke abstrahere det bort. Som f.eks å sende en datomic-db (som er en immutable value, og et snapshot av databasen på et punkt i tid) rundt om kring i businesslogikk uten å pakke den inn i en abstraksjon

Greia der er vel at 1. snapshot’et av databasen er ikke infisert av typer 2. Hvis du velger å bytte til en annen database som ikke tilbyr et snapshot av databasen, så er du i en world av pain uansett. Basically, du har valgt å låse deg til et sett av databaser som tilbyr noe slikt. Det er muligens helt greit, men det er et valg du har tatt og et valg du bør ha tenkt nøye gjennom.

Angående "veien til Clojure", for meg var det Paul Graham sin post om Lisp og blurb paradox. Så ventet jeg dere på en praktisk Lisp til å dukke opp...