føler jeg løste debatten om statisk/dynamisk i går, kjør gjerne flamewar her

typ, dette er vesensforskjellen som gjør at noen elsker statisk og hater dynamisk, og vice versa

Jeg så den i morges og tenkte jeg skulle skrive noe….

Men jeg var litt usikker på hva. Har siste tiden jobbet en del i React og TS og gjort meg opp noen tanker rundt i allefall hvordan man typer.

Not sure it is fail late for me. I just find modelling with maps that I build through my pipeline easier then defining a type for each substep. (`RawPerson -> PersonWithName -> PersonWithNameAndAge ->` 🙀 ). In somewhat related context, Wilker had a couple great points about the problem with types at the beginning of https://www.youtube.com/watch?v=YaHiff2vZ_o Though you have a point with it being a tradeoff between complexity and something - safety, perhaps?

@slipset sitter og setter meg inn i et JS-prosjekt her selv, og merker at det er en viss tilfredsstillelse i å type den tingen jeg skal jobbe med i typescript for å få oversikt over hva systemet kan gjøre og forventer. Men, det jeg i praksis gjør da, er jo å si at på toppnivå så må alle som jobber med denne tingen ha kunnskap om systemet som helhet. Mange greier som er optional, osv osv osv, men jeg har jo likevel innført kompleksitet som ikke var der før

føles som det er i dette skjæringspunktet her mainstream-appealen til typesystemer ligger, kanskje? Det er jo snedig å kunne kjapt se alle tingene som kan være i en ting

så føles det også som dette problemet løses med functional core, imperative shell. Når du har en imperative core, er det jo veldig super ekstra deilig å få denne oversikten. Hvis du har en functional core, så kan du jo bare kjøre funksjonen og se hva du fikk tilbake, f.eks

og så har jeg alltid tenkt på "fail early" som bra. Men det er jo krydret med imperative tanker. I en functional core har det ikke noe å si hvor du feiler

erlang, som ikke handler om annet enn å sende imperative meldinger rundt om kring, er veldig på fail early. Fail early er nødvendig i et imperativt system?

dette føles som en bloggpost som bør skrives

I Anteo planlegger vi å teste ut regimet nolan kjører på vouch; react komponenter utviklet i storybook og cljs i data laget. Setter opp boilerplate nå og er usikker på om typescript er verd den ekstra kompleksiteten.

Vi bruker rxjs sammen med react. Du kan sammenligne det med reagent atoms som betyr at du kan ha “standalone” komponenter som får data’ene sine via andre måter enn den ene store global state. Mulig dette er standard React også, det vet jeg ikke.

Basically, så har vi en connect funksjon som tar en React component og en rxjs stream og gjør at verdiene på streamen blir props til komponenten, og connect returnerer en ny React component.

Noe som vel gir deg “urene” komponenter, men som gjør at man ikke behøver å vite alt om alle på toppnivå?

@holyjak with TS, I’m not sure this is a greater problem than with spec. You can compose types with the & operator, and you can Pluck props (much like select in spec2), so you could get away with not at least naming everything you’re not intersted in.

Nå har jeg kjøpt billett til ClojureD. Blir min første clojurekonferanse. Gleder meg veldig. Noen andre som skal?

Jeg har sendt forslag til et foredrag så om det blit godtatt, blir jeg med...

Jeg tror vi blir en kontingent fra Ardoq.