God morgen! ☀️

God morgen!

Morn!

Mornings! 😄

morn!

https://clojurians.slack.com/archives/C061XGG1W/p1663071789806169 Jeg tenker at det er veldig naturlig å ha clojure-lunsj i lunsjtider - men det utelukker slett ikke å ha en clojure-meetup på ettermiddag eller kveld!

Og morn :)

Og god morgen, ja

kjapp poll: hvor mange har erfaring med Haskell? er det lønt å sette seg litt inn i Haskell hvis man kan Clojure?

Har vært med på en workshop på Flatmap en dag. Jeg synes det var lærerikt. Og veldig lite typer 🙂

En ting, dog litt på siden, siden jeg nå nevnte flatMap, er at jeg er veldig glad i å se på talks om typede språk og deres problemer og løsninger og se hvordan man ville gjort det i Clojure og hvilke trade-offs man tar.

Jeg bare lærte nok for sudoku i Haskell, men har drevet med F# en lang tid. Jeg synes egentlig ikke det hjelper.

Scala3 talk’en på Javazone i år var i så måte en interessant talk.

Enig

jeg har alltid vært litt "redd" Haskell fordi jeg ser for meg at det er obligatorisk å ha Functors, Applicatives, Monads osv. i fingrene

og det blir for abstrakt for meg som skal kode GUI på fredag ettermiddag

Noen i en eller annen annen kanal her sa noe om at det var den største blokkeren for Haskell, at man drar fram sånne greier altfor tidlig.

Kaare Nilsen i Arktekk sa (på den heseblesende podcasten Kodeskikknemnda) at de har dummet seg ut på enkelte Scala-prosjekter ved å modellere for mye i typesystemet for tidlig, aka plassert seg feil i trade-offen korrekthet vs fleksibilitet når de ikke trengte all korrektheten

"Whether a language can solve the Expression Problem is a salient indicator of its capacity for expression" - Rich Hickey, en eller annen talk 🙂

programmeringspråket hvor utviklerene ikke trenger disiplin for å treffe riktig finnes vel ikke 😇

joda. det heter Clojure. bare ignorer den funksjonen all dataen i systemet flyter gjennom 😄

(atom) og re-frame sier hei

etter noen år med veldig mye Clojure har jeg begynt å like typer igjen en hel del faktisk. har aldri blitt fornøyd med den linja mellom korrekthet og "bare send inn dataen" selv

er på et slags gjerde selv, må jeg nok innrømme ja

vi har f.eks. en del kode som uten tvil lider kraftig under TMI (too much information) problemer, der flere typer kanskje kunne ha hjulpet

(som vel overrasket nøyaktig ingen siden jeg driver og skriver bok om Kotlin)

har ikke jobbet i et prosjekt som bruker spec i noen særlig utstrakt grad da, kanskje det fikser biffen med å få litt oversikt over forventningene til koden rundt om kring

har vært veldig på gjerdet mht. spec selv. vi hadde en her som likte det og gjerne brukte det til "alt". nå har han sluttet. kanskje det var min feil. 😛

Poenget er av man uansett tenker i typer, spørsmålet er om man koder på en slik måte at man må ha hjelp av kompilatoren for å ikke tråkke i salaten.

Og. For all del. Sist jeg koda med typer var i Java. Som ikke er verdens beste opplevelse.

ville kanskje generalisert det til "tenker i hva som er tilgjengelig og forventes her". Det er kanskje det samme som typer. Men jeg assosierer typer med navn på aggregerte ting, som fort blir ueffent synes jeg

ja for de fleste er det bare å si at klasse = type

Vi hadde jo hash’en fra helvete da jeg implementerte en handlekurv i Perl på slutten av 90 tallet.

interessant poeng. Typene er der jo alltid, på en måte? Det er vel det folk som foretrekker i sterke typer sier? Hvorfor ikke få hjelp av compileren i stedet for å ha alt i hodet osv

Fordi av og til er compileren litt for pedantisk.

I TypeScript f.eks når jeg lager meg en react component som tar noe props, bruker en av dem og sender resten videre. Da burde min komponent bare bry seg om at den ene jeg trenger er der.

i et opplyst øyeblikk fikk jeg en smart tanke om fail early vs fail late. Med sterke typer må man enkode alt ting nedover skal ha, og dermed blir det fail early. Trade off er kompleksitet i typene. I dynamisk kaster man kanskje en exception run-time langt nede i treet hvor ting faktisk skjer, derav fail late. Trade off er null hjelp compile time

rart (sikkert ikke, egentlig) det ikke finnes et statisk typesystem som kan "fail late" compile time, hvor man kan enkode ting nede hvor det brukes, og samtidig få det til å boble opp

jeg funderte en del på hvorfor FP ikke var "normalen" etter at jeg begynte med det (etter maaange år med Java) selv. hadde begynt å sette meg inn i "hele historien" for å finne ut hvorfor. ville kanskje lage en presentasjon av det, kanskje jeg kunne få presentere på en konferanse med noe sånt?

omtrent 3 måneder senere presenterte Richard Feldman "Why isn't Functional Programming the Norm" på ClojuTRE 2019 😄

men nå et par år senere bryr jeg meg mye mindre om dette, og funderer mer på hvordan man skal finne ut på forhånd hvor linja mellom type og data bør dras.

så da kommer det vel en presentasjon om dette på en eller annen konferanse i høst 😛

jeg tenker at typer gir deg mer sikkerhet i bytte mot å gjøre koden mer rigid. Man "låser den ned" med typer, og får noen garantier tilbake. Etter min erfaring er det ikke verdt det. På mange måter en parallell til å få mer sikkerhet ved å deployere sjeldnere. Ja, kanskje får du færre problemer, men den reduserte fleksibiliteten og hastigheten er ikke verdt det. Det er uhyre sjelden at jeg bruker noe særlig tid på å finne og fikse en feil som typer ville reddet meg fra.

feil kanskje ikke, men jeg opplever at typer kanskje også kan redde deg fra noe komplekistet og "rot" - der hvor du altså ikke hadde dem fra før. se kommentar om "too much information" tidligere. men jeg vet ikke helt.

jeg tror du får mer kompleksitet og rot når du må tvinge en uforutsett ny feature eller innsikt inn i et typekonsept som ikke passer helt, men er spikret ned i store deler av kodebasen - typer har det med å forankre tenkingen din til det som er der i dag

i tillegg kreves det ofte at du navngir ting før du er klar for å navngi dem - som også har det med å gjøre tankene rundt det du ser på mer rigid

er vel dette som er "The Expression Problem" i praksis også - hvordan får du ny data og nye typer til å sameksistere med gammel data og gamle typer. har du ikke typer, slipper du i utgangspunktet å tenke på det, men i "ren" FP syns jeg dette muterer over mot "Too Much Information" type problemer istedet

Helt enig. Flere ganger i F# har jeg lagt til en ny optional felt som bare er aktuelt ett sted, og da fått en compilation error 20+ steder. Pussig nok synes F# community at dette er bra...

er det bare Kotlin som løser det? Der brekker du ikke eksisterende kode ved å legge til en ny optional

C# også

Ja, det minner meg om kulturkrasjet jeg opplevde når jeg begynte å programmere Clojure. Jeg var helt sjokkert over nil-punning. Hvordan kunne man bare la nil-er flyte gjennom? Min dogma fortalte meg at man måtte feile tidlig. Kast exceptions ved første anledning. Det er eneste måte å være sikker på at du får feilmeldingen der den oppstår. Det jeg ikke så, selvfølgelig, var hvordan denne tilnærmingen negativt påvirket koden jeg skrev. Hvordan man blir hindret fra å gjøre funksjonelle transformasjoner av data, fordi man hele tiden må inn med side effecting assertions om parametere. nil-punningen er der av en grunn, og har mange av de samme trade-offene som resten av språket gjør.

functional core, imperative shell virker å være svaret på mye av dette og. Ved å skille "hva skal gjøres" fra "gjøre" så er det ikke så viktig hvor "hva skal gjøres" feiler

en morsom sidetanke: nil-punning for skalarer minner om hvordan collection API-et håndterer tomme lister. Det er klart du skal få mappe over en tom liste. Værsågod, her har du en tom liste tilbake.

spec hjälper mycket, men iom att det blev implementerat med macros så är det inte fullt så flexibelt som man alltid skulle önska

När jag får anledning så vill jag pröva på malli som alternativ

Klarer ikke helt å sette fingeren på hvorfor, men jeg kjenner meg svært skeptisk til å gjøre noe så gjennomgående og viktig med et tredjeparts bibliotek

Tror det treffer litt rammeverksnerven. Det øker sjansen for at noen som kan språket godt ikke kommer til å forstå koden din. Og som andre rammeverk øker det sjansen for at du trenger å gjøre en stor og potensielt inngripende omskriving dersom biblioteket faller bort av en eller annen grunn. Kjenner dog ikke malli godt, så mulig det stiller seg annerledes.

Vannskelig å si nå, fordi community har ventet på spec 2 i mange år (oppringlig skulle den komme i 2019 tror jeg), og mange har bare begynt med malli. Men ja, ikke ideelt. Heldighvis virker malli ganske intuitivt, og ligner litt json-schema, som flere vet om.

Det spørs også hvordan man bruker den - bare legge den inn noen få steder vs. endre alle defns.

Ja, det var særlig det siste jeg tenkte på

Leste senest i går at Alex skrev at spec ikke jobbes med for tiden

Det var därför jag satsade på spec. Men de gjorde en del val som gör det svårt att använda i vissa fall. Exempelvis felmeddelande. Går inte att baka in ett felmeddelande för människor med en fail av en spec.

Macros vilket gör att jag inte kan lagra en spec eller skicka över en spec över nätverket

det er et eller annet som gir mening med at selv en dyp tenker som Rich Hickey sliter med å få til et "typesystem" for Clojure. Ikke et lett problem å løse

Virker som om interessen har dabbet av også

https://clojurians.slack.com/archives/C061XGG1W/p1663168933290589 Jeg lærte meg Haskell og Elm før jeg tok i Clojure. Jeg synes typer i solide typesystemer er et knallgodt verktøy for å sette seg ned og tenke: 1. Hvordan modellerer jeg problemet mitt skikkelig 2. Hvilke transformasjoner mellom typer trenger jeg. Det er en stund siden sist jeg har rørt Haskell. https://www.teodorheggelund.com/ er bygget på Hakyll, en statisk side-generator i Haskell. Men avhengigheter og kompilering har vært et lite herk.

Typeinformasjon er ikke like nødvendig for å få god innsikt i Clojure-kode fordi man har REPL-et å lene seg på.

Jeg skrev en liten avhandling om hvordan jeg klarer meg uten typer i Clojure på twitter for kun kort tid siden. 😊 https://twitter.com/magnars/status/1570117159652573190

Enig i punktet om at data literals hjelper på å se hva som skjer 🙂 Det er kanskje det jeg savner mest når jeg skriver i andre språk.

Spennende å lese det du skriver om Haskell! Selv hadde jeg Haskell på toppen av "vil lære"-lista i 2012, og så kom Clojure og bikket den av tronen. Det er åpenbart veldig lurt å tenke "hvordan modellerer jeg problemet mitt skikkelig" - og kanskje er typer en ålreit måte å strukturere det tankearbeidet. Det vil aldri være bortkasta å ha tenk litt gjennom det på forhånd. Samtidig er det et problem hvis du organiserer tankene dine på en måte som gjør de vonde å vende. Du kommer ikke til å treffe spikeren på hodet med en gang. Det blir noen runder her. Av erfaring så kommer det en innsikt som lyn fra klar himmel når koden er "nesten ferdig". I denne kategorien tenker jeg at spesielt tidlig navngivning er trøblete. Du må sette navn på alt mulig. Det kan være at de navnene er mer til hinder enn hjelp når det gjelder å få det fantastiske lynnedslaget.

> Selv hadde jeg Haskell på toppen av "vil lære"-lista i 2012, og så kom Clojure og bikket den av tronen. Haha -- jeg rakk selv å være ML-entusiast fra jeg først skjønte at jeg likte Haskell bedre enn Java i 2015, til jeg fikk smaken på Clojure i 2017-2018 😄

et skjermbilde fra the kingdom of nouns i Typescript-koden til VIERLIVE 😇

(som er tenkt som et innspill til at Magnar har rett i at det fort blir mange navn når man skal lage typer for ting)

Det er mange som skriver mye om haskell og flere biblioteker som tar ting litt for langt etter min mening. Man lager programmer i typesystemet som kan være nokså knotete å forstå seg på (har opplevd dette litt med Scala og). Synes https://www.simplehaskell.org gir en greit outline for å holde ting produktivt og ikke fullt så astronautete.