Fork me on GitHub
#clojure-norway
<
2024-03-07
>
magnars07:03:20

God morning!

augustl07:03:36

god morgen!

leifericf07:03:33

Jeg ble anmodet om å ignorere Leiningen og fokusere på Deps/CLI tidlig i læringen min, men så så jeg denne meldingen fra @slipset om at han fortsatt bruker Lein. Gjør dere andre også det? Når er det lurt å velge Lein over Deps/CLI? :thinking_face:

msolli07:03:14

Leiningen er ikke enklere å bruke. Leiningen har bare mer greier innebygd.

augustl07:03:16

største beef med lein for min del er at noen deps-ting blir upraktisk, som å peke på git-repos

cjohansen07:03:58

Lein er enklere hvis du allerede kan det 😄

cjohansen07:03:10

Når skal du bruke leiningen? Hvis du allerede har bygget masse greier rundt det.

cjohansen07:03:24

Ingen grunn til å ta i bruk leiningen på et nytt prosjekt i dag IMO

☝️ 1
magnars07:03:52

Mine gamle prosjekter bruker lein, mine nye bruker deps. Jeg ser ingen stor grunn til å skrive om de gamle til deps, men har ikke noe behov for lein i nye heller. Deps er konseptuelt enklere, og har etter hvert bedre verktøystøtte, for eksempel med Lambda Island sin Launchpad.

slipset08:03:42

Jeg ville vel sagt at det er heller ingen tungtveiende grunner til å ikke ta i bruk lein på et nytt prosjekt idag. Den eneste grunnen som jeg kommer på i farten er muligheten til å avhenge av git-shas

cjohansen08:03:43

En god grunn er å ikke sette seg fast i leiningen-plugins

slipset08:03:16

Men, igjen. Dette er et område hvor jeg har omtrent 2FTG, og det er min mening at jo mindre tid jeg trenger å bruke på byggesystemer, jo bedre er det.

slipset08:03:55

Velidig fint verktøy. F*cks To Give. Hvis du føler at du har få FTG om et tema, så bør du unnlate å diskutere/mene så mye om det.

leifericf08:03:03

Two fucks to give?

slipset08:03:28

Men en konkret kritikk av deps fra min side er at med lein så kan jeg, nesten uavhengig av prosjekt skrive ting som lein test, lein compile, lein uberjar lein deploy. Med deps er det en eller annen magisk blanding av -X og whatever utvikleren for det enkelte prosjekt har bestemt seg for.

leifericf08:03:55

Det er et viktig/relevant tema for nybegynnere. Lein ble brukt i alle tutorials og bøker når jeg startet, men så ble jeg veldig forvirret når jeg fant Deps/CLI på Clojure nettsiden og ymse diskusjoner på Slack. Jeg tok "ikke bruk Lein" som god fisk og gav rådet videre til @U06KMCLBWTS og @U06K3RAJRB6 😅

slipset08:03:11

Og dette er ting jeg gjør akkurat så sjelden at jeg ikke får internalisert det.

magnars08:03:15

Å kunne bruke avhengigheter som ligger på disk med local/root, peke på en bestemt gitsha, og å dynamisk laste inn avhengigheter/env-variable med launchpad er alle gode grunner til å bruke deps på nye prosjekter, vil jeg si. Har ikke savnet lein på noe tidspunkt.

slipset08:03:03

Jeg husker mitt første Clojure prosjekt, der jeg hadde behov for å kunne kompilere Java kode i samme prosjekt. Det bare funka. Og jeg trengte en kjørbar jar. lein uberjar. Ikke ut på en eviglang søken på jakt etter depstar eller noe som kanskje eller kanskje ikke virker og hvor jeg har to, tre valg som må gjøres og som antagelig ikke har konsekvenser, men som jeg ikke vet nok til å avgjøre.

💡 1
augustl08:03:28

så det du sier er at du liker Rails bedre enn Clojure? trollface

😅 1
augustl08:03:03

(mega-trollface , er jo lov å ha ulikt level på 2FTG på business-logikken og metaen rundt som byggesystem)

slipset08:03:42

> så det du sier er at du liker Rails bedre enn Clojure? Jeg tror at det jeg sier er at jeg setter pris på å slippe å ta en haug med valg i starten av noe som helst, som er akkurat når jeg vet aller minst om det jeg skal holde på med. Dog er jeg opptatt av at når jeg har funnet ut av hva jeg holder på med, så er konsekvensen av de valgene jeg tok (eller slapp å ta) minst mulig, ie det er mulig å endre dem. Jeg husker f.eks da jeg startet at det fantes ring, noir, og sikkert noen andre greier som man kunne velge mellom når man skulle mekke en webapp. Jeg er veldig glad for at jeg nå kan velge ring.

slipset08:03:19

Og hvem bryr seg egentlig om du bruker data.json, cheshire, jasonista eller charred?

slipset08:03:23

Når du besøker en restaurant for første gang er det greit med en 3 retters set menu. Hvis du har lært deg menyen er a la carte bedre. Hvis du spiser ute en gang hvert jubelår, så er også en set menu ganske greit.

leifericf08:03:40

For kontekst: Jeg prøver å hjelpe nybegynnere, som er ferske utviklere generelt i tillegg til at de aldri har sett Clojure eller funksjonell programmering før 🙂 I det lyset er kanskje Leiningen enklere for å komme i gang og tenke på færre ting? I og med at man må gjøre flere ting "manuelt" med Deps/CLI? Deps/CLI er "simple, but not easy" sammenlignet med Leiningen, som er "more complex, but easy?" :man-shrugging:

slipset08:03:06

Det er min påstand.

leifericf08:03:08

Jeg fant noe relevant info på denne siden her også forresten: https://clojure.org/guides/faq#_deps_and_cli > The Clojure CLI is focused on a) building classpaths and b) launching clojure programs. It does not (and will not) create artifacts, deploy artifacts, etc, although they may facilitate these actions through tools and libraries.

slipset08:03:48

Jeg tror også at valget er relativt uten konsekvenser - det er relativt lett å gå fra vanilla project.clj til deps.edn.

👍 1
slipset08:03:38

Altså hvis din project.clj basically er en liste av deps, så er det trivielt (og det finnes verktøy (og er en god øvelse i Clojure)) å skrive det om til en deps.edn.

👍 1
magnars09:03:03

echo {} >> deps.edn
clojure
Værsågod, et repl!

slipset09:03:30

Ja, men jeg trenger en uberJar

slipset09:03:04

Og jeg vil kjøre testene mine.

magnars09:03:04

Du argumenterer "dette er lettere" når det egentlig er "dette er lettere for meg".

slipset09:03:50

Det er mulig. Og ikke unaturlig. Jeg er jo viktigst. I alle sammenhenger.

leifericf10:03:35

Jeg lurer på hva som er "lettest for den gjennomsnittlige nybegynneren." For mitt vedkommende var det ikke spesielt vanskelig å bruke Deps/CLI, men det innebar en del lesing og Slack for å finne ut hvordan jeg skulle få Cognitect sin test-runner til å funke og bygge en Uberjar. Det ble litt copy/paste av deps.edn fra Clojure nettsiden og noen blogger på veien. Lein har jeg faktisk kun brukt for å følge noen eksempler i artikler og bøker.

magnars10:03:18

Jeg er ikke en gjennomsnittlig nybegynner, men ettersom alt av tooling nå bygger på deps, så hadde jeg blitt ørlitt grinete hvis jeg hadde blitt introdusert for lein og måtte lære meg det først.

👍 1
magnars10:03:43

Jeg har gravd mye i den fila her og revet meg i håret opp gjennom tiden, for å si det sånn: https://gitlab.com/technomancy/leiningen/blob/master/sample.project.clj

slipset10:03:50

> Jeg er ikke en gjennomsnittlig nybegynner Dagens understatement 🙂

1
👏 1
msolli10:03:50

Kanskje https://github.com/seancorfield/deps-new kan være noe for dine gjennomsnittlige nybegynnere? Tingen med "nybegynner" er at det er en tilstand man ikke er i spesielt lenge, og da trenger man fort verktøy for ikke-nybegynnere.

💡 1
slipset10:03:32

Og derfra kommer eksempler på det jeg mener er skikkelig sucky DX:

clojure -A:deps -Tnew help/doc
Er inkantasjonen du må klare å skrive inn for å få hjelp. lein help

slipset10:03:30

Og ja, jeg ville nok ha satt pris på om deps-new var et shell-script som bygde på clojure men som ga skikkelig DX, så man kunne gjort: $ deps-new help

msolli10:03:05

Det er bare en kommandolinje? 🤷 Den har flere tastetrykk fordi den har mulighet til å gjøre flere ting. Med lein kan du gjøre noen få ting, og etterpå er du stuck, eller du må skrive en plugin, eller noen andre har lagd en plugin, og du har ikke lenger en så bra "DX".

slipset10:03:09

Joa, det er bare en kommandolinje. Men det er jo brukerinterfacet. Og det er litt viktig for meg.

slipset10:03:24

brew install deps-new FTW

slipset10:03:07

Og ja, jeg kan sikkert skrive aliaser i bash/zsh og sånt, men….

msolli10:03:33

Sharp tools! 🙂

msolli10:03:47

Lein er et "blunt tool".

slipset10:03:38

Jeg tror at der velger jeg å være uenig. Men, sant skal sies, at jeg har ikke brukt så mye plugins og sånt.

slipset10:03:09

Forøvrig mener jeg at det er ingen motsetning mellom sharp tools og god DX/UX.

slipset10:03:18

Problemet er at det er vanskelig.

magnars10:03:20

Sånne rare kommandolinje-greier skriver jeg én gang inn i Makefile, og så er det ute av verden 🙂

👍 2
leifericf10:03:44

Jeg også har begynt å bruke Make eller https://book.babashka.org/#tasks til å "pakke inn/huske" rare kommandolinje-greier.

leifericf10:03:07

En fordel ved det er at alt som kan gjøres blir eksplisitt også ovenfor andre utviklere som ikke kan Clojure i det hele tatt. Og Make er preinstallert på de fleste OS-er.

augustl12:03:35

finnes det noen konvensjoner i make for ting som “kjør testene”? Eneste konvensjonen jeg vet om, er “`make` uten noe mere kjører ‘hoved-tingen’”

leifericf12:03:47

Jeg brukte denne for å lære Make: https://makefiletutorial.com/

leifericf12:03:46

Fra ett av eksemplene: > You can have multiple targets to make, i.e. make clean run test runs the clean goal, then run, and then test.

augustl12:03:03

hmm ja make clean er “vanlig”. Teknisk sett er det vel bare en task som heter clean, men den er konvensjonell nok til at du kan forvente at det er en make clean i et prosjekt som bygges med make. Men som slipset er inne på er det kanskje ikke noe lignende steg for “se en makefile, skjønne hvordan man kjører tester”

augustl12:03:31

man kan jo alltids prøve make test, men 🙂 Kanskje store makefiles er litt vanskelige å lese og? Masse implementasjonsdetaljer, hvor er de faktiske taskene, osv

👍 1
leifericf12:03:09

Ja, jeg vet ikke om det finnes noen måte å printe alle targets på? Det gjør det sikkert, jeg har bare ikke tenkt på det. Jeg pleier bare å åpne Makefile for å se hva som er inni der.

magnars12:03:35

Artig å kunne bygge ut editoren sin!

👍 1
leifericf12:03:14

Tror det funker i terminalen også, typ skriv make og deretter tab

augustl12:03:59

haha søren, skulle parere med et skjermbilde av at IntelliJ også kan liste make-tasks, men det gjør den ikke

😅 1
leifericf12:03:14

VS Code gjør det sikkert også.

magnars12:03:58

Istedenfor å vente på at noen skulle være "excited to announce" ting, så fiksa jeg det på en togtur 😅

😅 2
leifericf12:03:13

"Excited to code on the train!"

💯 1
augustl12:03:25

men, til mitt forsvar, så har jeg investert null tid i og fått helt gratis…. mangelen på makefile-støtte

😅 1
augustl12:03:38

(som ikke er gratis og koster ~ 1500 i året)

leifericf12:03:31

Tipper det finnes en IntelliJ plugin i den marketplace-greia.

augustl12:03:40

dette blir bedre og bedre - IntelliJ har støtte for makefiles, men den vises bare som en plain text

augustl12:03:17

deeeer ja

👍 1
augustl12:03:15

her en Makefile i et leiningen-prosjekt forøvrig 🙂

leifericf12:03:20

Jeg lager en target make love for hovedgreia 😅

💯 1
leifericf12:03:30

make pasta er for testing.

leifericf12:03:57

make sense er for å starte debugger 😅

🔥 1
augustl13:03:15

sikkert ikke så mye å si om byggesystemer hos Funcom, @U01PE7630AC? 😄

leifericf13:03:43

Haha! Joda. Vi har et hjemmelaget byggesystem, som jeg også brukte da jeg jobber her sist for 12 år siden. Men det er mye, mye eldre enn det, og det er skrevet i Python. Det fantes ingen CI/CD SaaS/skyløsninger da det ble bygget. Ikke Git eller GitHub heller. Det er integrert med Perforce, som er de facto standard VCS i spillbransjen.

leifericf13:03:13

Men Unreal har også sitt eget bygg/CI/CD system som heter Horde.

augustl13:03:44

opplever UE som at det var en av hovedgreiene de kom med, husker de demoa hvordan du kunne recompile C++-koden din og så bare oppdaterte live previewet av 3D-verdenen i editoren seg deretter

leifericf13:03:23

Det er nok ikke sååå smooth som i demoene, men, ja, de har noe sånt 😛

augustl13:03:52

haha det var sikkert et minimalt eksempel, ja. “Angular-patternet”, som Magnar kaller det. Fine demoer, men når du spør, så er svaret “nei nei, når vi lager ordentlige apper så gjør vi ikke sånn her”

😅 1
leifericf13:03:27

Perforce suger også synes jeg personlig, men det finnes ikke så mange andre VCS systemer som er "non-coder friendly" og som har god støtte for store mengder binære assets (3D modeller, teksturer, animasjoner, lydfiler, etc.) Jeg tror det er derfor Perforce med sitt visuelle GUI har blitt de facto standarden i denne bransjen og ikke (Git. https://git-lfs.com finnes, men det er ikke spesielt brukervennlig for kunstnere, grafikkere, komponister, etc.)

cjohansen14:03:19

Praktisk med ymse måter å liste make tasks på, men det er virkelig ikke vanskelig å se hvilke som finnes ved å se på Makefile-en. Alt som står helt i venstremargen med en indentert linje under seg er en task 🤷

👍 2
cjohansen14:03:49

Ikke et argument mot editorstøtte, jeg har selv stor glede av @U07FCNURX sin Emacs-Make-sak, men det er ikke veldig vanskelig å lese en saklig Makefile

cjohansen14:03:18

Alt kan selvfølgelig gjøres på dustete vis, så noen klarer helt sikkert å rote opp en Makefile som er umulig å lese, derav "saklig" over 😅

cjohansen14:03:03

Jeg er forøvrig delvis enig i @slipset sitt poeng om at enkelte ting er uttrykt unødvendig obskurt i tools.deps. Men jeg syns fordelene langt veier opp for litt rufsete CLI-design.

cjohansen14:03:40

Og så vil jeg skyte inn at selvom det er nyttig at "lein test" "bare funker" så kommer det absolutt med en pris. Det er ikke så lett å resonnere seg frem til akkurat hva det er som skjer når du gjør det. Det er ikke noe problem når det funker som det skal, men ganske ræva når det ikke gjør det. Da jeg brukte leiningen følte jeg jevnlig at jeg ikke hadde kontroll på hva som skjedde - hvilke profiler er aktive nå, osv. Den største fordelen for meg da jeg bytta til tools.deps var følelsen av å forstå alt som foregikk. Det er noe "clever merging" i den også, men mye mindre. Og det at den ikke har plugins som kan lene seg på det systemet gjør at det er begrensa hvor magisk det blir. I tillegg har det kommet masse nydelige tillegg, local deps, git deps, launchpad osv.

👍 2
slipset09:03:08

Jeg må skrive en liten rant om typescript og type inference. Type inference er bra helt til det ikke er det. Det er fint å kunne skrive:

const foo = (x:number) => "bla";
og slippe å fortelle kompilatoren at, jada, denne funksjonen returnerer en streng. Men, hvis jeg nå skulle finne på å kløne det til litt:
const foo = (x:number) =>  (x > 3) ? "bla": 9;
Så har jo denne funksjonen automagisk endret returtype, men det er jo helt fint, fordi type inference fersker at nå returnerer denne funksjonen string | number . Problemet er at feilen min blir markert på alle call-sites som tidligere antok at foo returnerte string men at den nå returnerer string | number. Så derfor begynner jeg å bli av den oppfatning at det hadde vært gunstig å være flinkere til å skrive ut returtypen til funksjoner, slik at dette ville vært:
const foo (x:number):string => "bla";
og da ville kløninga mi blitt rapportert på riktig sted. Tangensielt. Ved at vi ikke har for vane å skrive ut returtypen til funksjonene våre, ender vi fort opp med litt rare returtyper: Bildet under er en faktisk inferert type hos oss. Hvis vi hadde tvunget folk til å skrive ut typen, tror jeg ikke dette hadde vært førstevalget. Det man egentlig vil ha er en Promise<Error | GoodResult> men måten funksjonen er skrevet på har kløna det skikkelig til.

augustl09:03:02

vet ikke om man har linter-regler for det, men ser at mange (særlig store) organisasjoner har regler på at du alltid må være eksplisitt med typene, uten unntak

slipset09:03:44

Det er en tanke, men jeg er også var regler uten unntak, og typer for sånne veldig generiske funksjoner gir meg lite.

augustl09:03:34

hørte et smart menneske si dette her om dagen: “Regler løser ingen problemer, det er bare noe å falle tilbake på når man er uenig”

augustl09:03:48

og det mappet vel på ca. alle tankene jeg har om typer vs dynamisk

🎯 1
teodorlu12:03:31

God morgen 🙂

cjohansen12:03:09

Si hei til @mathias.iversen487, kollega i Mattilsynet som lærer seg Clojure 👋 🥳

👋 13
🎉 1
boosja12:03:46

Hei hei 😄

magnars13:03:59

Hei og hå! 😄

teodorlu13:03:00

Velkommen til #C061XGG1W, @mathias.iversen487! 🎉

Olav13:03:03

Velkommen!

odinodin13:03:28

Velkommen! Å få lære Clojure av Magnar og Christian, da er du i trygge hender 👏

2
💯 3
✔️ 1
slipset13:03:24

Velkommen!

leifericf19:03:30

Jeg snublet over https://blog.datomic.com/2017/01/the-ten-rules-of-schema-growth.html via https://biffweb.com/p/xtdb-compared-to-other-databases/ i dag, når jeg prøvde å lære mer om liketene og forskjellene mellom XTDB og Datomic. Interessant lesing!

👌 2
👍 1