Jeg fikk med meg Gosling og Alex sine talks, var dessverre i juleselskap da Bradford Cross sin talk gikk.

Jeg var vel litt uenig i noe av diskusjonen som gikk i etterkant om det å lage libs når man er en startup. Etter mitt skjønn er det en lang vei å gå fra å lage noe som funker for ditt use case til noe som er generelt brukbart, og den veien burde man kanskje ikke gå hvis man er en start up med begrenset run way. Her mener jeg det er forskjell på start up og konsulent som f.eks Kodemaker og Metosin, som vil ha nytte av samme funksjonalitet over mmfe prosjekter.

Forøvrig to, litt skuffet over måten han pitchet det de skulle gjøre -masse kul tech ML, AI, distribuerte systemer, men lite om hvilket problem de faktisk skulle løse.

Ja, jeg synes også det ville vært vanskelig å argumentere for at vi skal bruke tid og ressurser på open source i startupen jeg jobber. Eller - det kommer an på hvordan. Å bygge biblioteker fra scratch tar mye tid. Men å bidra til andres greier tror jeg er plausibelt. Ofte er det kjempenyttig å kunne snakke med de som lager tooling som alle bruker og skjønne hvordan de tenker.

Beror väl lite på scones

Scope

Bidra er åpenbart plausibelt og viktig. Mekke egne greier, ikke i min bok. I allefall ikke på det nivået ekosystemet er nå.

Jeg forventer ikke at noen som helst skal pumpe ut open source-biblioteker, men at det er kategorisk nei til å lage nye libs for en startup er jeg ikke med på 😅

Jeg har ikke så veldig mange libs på samvittigheten, men de jeg har har stort sett vokst ut av produksjonskode. Med andre ord har de først vært ferdig kode i en app, så fått litt tender love and care for å stå på egne bein

Nei, ikke kategorisk nei, men jeg oppfattet Bradford som kategorisk ja 🙂

Jeg har ikke sett hverken talken eller diskusjonen det refereres til, så mulig jeg må “check YOSELF” før jeg begynner å diskutere 😄

Ditto 🙂

Men jeg er i utgangspunktet uenig med: “Mekke egne greier, ikke i min bok”

Eller, la oss si at det står noe annet i min bok

Men @slipset, kjempegøy å høre om clj-commons! Dere gjør en viktig jobb.

Ah, men jeg tror kanskje du misforstår. Det er helt fett å mekke egne greier, men å gjøre det generelt nok for bruk for andre, da mener jeg du tar det for langt, hvis du er en startup med begrenset runway.

> Eller, la oss si at det står noe annet i min bok > Hva står det i din bok?

Eksempelvis kan man, hvis man legger godviljen til, se konturene av et web-rammeverk i vår backend. Men derfra og til å generalisere det til en slik grad at det kan tas ut som et bibliotek og være brukbart for andre - ikke noe jeg ville kunne argumentert for.

Nei, men det er stor forskjell på sånne biblioteker som jeg snakker om og “et webrammeverk” 😅

Hvis verktøyet er spisset nok, og designet sitter så er ikke steget fra “en del av vår app” til “clojars-ting” nødvendigvis så langt. Noen ganger handler det bare om å lage en egen deps.edn fil og skrive mer dokumentasjon enn du vanligvis ville gjort.

Det tar noe tid du kunne brukt på eget produkt, ja, men søren heller - hvor mye gratis kode har du bygget slottet ditt på? 🙂

https://github.com/cjohansen/m1p er et eksempel på et sånt verktøy. Dette er nesten 100% “biprodukt” av “linjearbeid” som Magnar og jeg har holdt på med.

En ting vi har hos oss som kunne ha blitt et bibliotek er en veldig tynn abstraksjon over S3 som lar deg lagre enten til S3 eller til lokalt filsystem. basically en protokoll med to implementasjoner. Men verdien av dette? Det er jo noe man koder opp på et par timer og så er det gjort og så passer det perfekt for deg heller enn at du må slåss med mine/våre feilslåtte abstraksjoner.

Jeg sier ikke at du er pliktig å open source all koden din som muligens er nyttig for andre 😄

Jeg vet du ikke sier det 🙂

Jeg er enig i at sånne små abstraksjoner ofte er best når de er lokale og i din hule hånd

Vi har også “et webrammeverk”, men det som er så fint med det er at det er relativt håndsydd til akkurat våre constraints

Det ville mistet mye av piffen sin om du skulle generalisere det

hvorfor ha 200 linjer med sin egen rammeverk-kode når man kan ha 200 000 (0) linjer kode med noen andres rammeverk-kode som støtter mange flere use caser?

Forøvrig. i https://podcasts.apple.com/no/podcast/software-unscripted/id1602572955?i=1000576106264 episoden av Software Unscripted diskuterer Richard Feldman hvordan han skulle ønske at editoren hans virket. Han beskriver i realiteten paredit. Jeg gjør meg et par tanker: 1. Paredit er helt klart en av Clojures super-powers som det kanskje ikke snakkes så mye om. Jeg tror kanskje det er viktigere for meg enn immutability. 2. Mange sliter med parentesene når de begynner med Clojure. For meg er det omvendt nettopp pga paredit 3. Mange bruker ikke den halve dagen det kreves for å lære seg paredit. Feldman sier i episoden at en av grunnene til at han valgte vim var en kollega som sa noe sånt som det du bruker en uke på å lære deg i vim får du tilbake til de grader. Dette gjelder i aller høyeste grad for paredit. 4. Fordi jeg ikke har et fungerende paredit oppsett for typscript er det such a pain å progge i det.

tenk det, “det tar en halv dag hvor du ikke er produktiv for å komme i gang” er en for stor bøyg for at folk tar i bruk Clojure? Virker nesten litt sånn

https://www.youtube.com/watch?v=xNMgc26tGNk snakker litt om det. Basically. Mange utforsker tech på fritida. Det betyr at en teknologi/et språk har en lørdag formiddag til å vise at det er verdt å leke videre med.

verden trenger en kurs-institusjon som er veletablert og anerkjent hvor du lærer ting du ikke trodde du trengte å lære, på dogmatisk vis, som du kan gjøre i arbeidstiden. “Ah, du har ikke tatt SuperKurs 9000, da skjønner jeg at du føler deg litt utenfor, ja”. I stedet for å sende alle på Kotlin-kurs fordi “det er den neste store JVM-teknologien”

Og siden du er her @augustl. Et av spørsmålene jeg ikke fikk formulert og stilt til Alex Miller var rundt Kotlin. Kotlin er et språk jeg har avskrevet som et litt anderledes Java, og som sådan bringer lite verdi. Har liksom ikke inntrykk av at det bringer deg noe særlig videre. Likevel er det “sånne” språk den jevne utvikler blir eksaltert over, og ikke Clojure eller Elm eller andre som som utfordrer tankesettet ditt.

Så basically, jeg har lissom mista litt trua på den jevne utvikler.

Kotlin har samme egenskap som Typescript, det er “nært nok” det du allerede kan (Java/JavaScript)

pluss at du finner masse ferdig pakka tooling der ute som er litt mindre mikkmakk å sette opp enn å skjønne hvordan du konfigurerer figwheel selv fra bunnen av. F.eks next.js

Så du slipper å bruke den halve dagen på å spare et hav av tid down the road.

kvaliteten på feilmeldinger og feedback loops når du gjør noe helt feil i next.js er milevis foran Clojure, hvor du har verdens beste feedback loop når alt er satt opp riktig, men kan møte veggen helt når figwheel ikke starter opp engang

haha jepp, er egentlig samme mønster der og ja

hva var det som gjorde at vi plukka det opp? For meg var det kanskje en blanding av at jeg var “desperat” nok etter å løse alle problemene jeg mener JS og status quo hadde, pluss at Simple Made Easy traff rett i hjerterota

🎯 Akkurat det samme for meg, @augustl

men hvis mindsettet ditt er “jeg vil bare få ting kjapt ut i prod” så ser man kanskje ikke poenget med “de derre knotete Clojure-greiene”

Jeg så Bodil Stokke kode det jeg på den tiden ville brukt 1000 linjer på å få til i Java på 100 linjer Clojure.

kanskje noen må lage et Clojure-rammeverk som ikke er et rammeverk. Litt som “expo” i React Native, auto-generert magi som du kan “ejecte” fra når du vil ta kontrollen selv

@slipset interessant, det der. Jeg har opplevd å se Simple Made Easy sammen med folk, hvor noen tok foredraget som personlig kritikk mot deres egne valg. Lett å si “ha ha, kognitiv dissonanse” fra utsiden, men det virket jo veldig sånn

veldig skummelt å tenke sånn da, “jeg er sånn smarting som klarer å se forbi mine egne biaser”, er ikke det jeg mener heller. Var kanskje mere at jeg aldri egentlig var en forkjemper for OO og muterbare GUI-strukturer så da var det mindre mental motstand på å bytte paradigme

> Det betyr at en teknologi/et språk har en lørdag formiddag til å vise at det er verdt å leke videre med. 😬 😂 😭

It’s sad because it’s true

Clojurians har visst ikke den nevenyttige “lolsob” emojien

Men veldig enig angående paredit @slipset! Da jeg sist var på et JS-prosjekt var det paredit jeg mest aktivt savna. Å redigere tekst som har en tydelig definert syntaks karakter for karakter oppleves utrolig knotete når man har blitt venn med paredit

“Jeg bare klipper bort noen karakterer her jeg, så er ikke koden min engang syntaktisk riktig” - hvem ønsker seg det?

interessant nok har f.eks IntelliJ masse paredit-aktige funksjoner innebygget som jeg bruker hele tiden i andre språk. Du har tastatur-snarveier for å markere/selecte tekst strukturelt innover og utover fra cursor

Apropos parediet: Noen som har noen gode måter å bruke evil mode og paredit på? Fungerte mye bedre før jeg bytta til evil, nå har jeg ikke fått satt det opp riktig, må f. eks trykke esc hver gang etter jeg har flyttet ) et hakk fremover for å få flyttet det et hakk til. (bruker practicalli sin spacemacs config)

Ang. Kotlin kan jeg bare gi et take fra meg selv som relativt fersk utvikler: Gjør statisk typing mye mer komfortabelt å jobbe med enn Java, Mye fint syntaktisk sukker, og fungerer silkemykt sammen med IntelliJ. Videre tror jeg mange organisasjoner er avhengige av å bruke språk som gjør det lettere å ikke skrive kode det er umulig å forstå seg på. Det er jo gamle deilig at funksjoner er dokumentert med hva de tar som input som default også, mens i Clojure må man enten håpe at hen før deg har brukt tid på doc-string eller gjort noe type spec(her er jeg litt blank). Tror også de fleste alltid kommer til å foretrekke easy foran simple. Dette ble litt rambling, men forsøker å forklare populariteten til Kotlin vs. Clojure fra en mannen-i-gata utviklers synspunkt.

og god morgen:smiley:😃

virker for meg som at rævva kode er mye mere lettlest med statiske typer, og det er jo mye rævva kode der ute. Men fint laget Clojure-kode gir deg en enda kjappere og mere korrekt feedback-loop enn et typesystem

jeg har brukt dette bildet for å snakke om læring i det siste. Man kan kjøre rundt og rundt i havet og gjøre det samme man har gjort før (venstre). Det som er lett/easy/nært. Eller man kan prøve nye ting (høyre). Men nye ting er skummelt! Og man vet ikke helt om det er nyttig en gang. Så det gjelder å ikke ta seg for mye vann over hodet. Ikke angripe alle dragene samtidig. Clojure er veldig forskjellig fra andre ting. Det er veldig mye nytt på en gang. Det er så mye nytt at man ikke klarer å gi et godt inntrykk på det "én formiddag"-vinduet som Christian Erik beskriver over. Jeg har tro på "show, don't tell". Ved feks å lage screencasts som viser hvordan det er i praktisk bruk. Eller rigge opp mob/ensamble-programmering. Så kan man se hvordan det faktisk brukes i praksis. Og kanskje bli nysgjerrig nok til at man gidder å investere mer enn en formiddag på å lære nye ting.