This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-21
Channels
- # announcements (13)
- # babashka (63)
- # babashka-sci-dev (64)
- # beginners (37)
- # biff (1)
- # calva (10)
- # cider (7)
- # clj-kondo (15)
- # cljsrn (6)
- # clojure (26)
- # clojure-dev (10)
- # clojure-europe (34)
- # clojure-france (9)
- # clojure-nl (2)
- # clojure-norway (36)
- # clojure-uk (5)
- # clojurescript (142)
- # community-development (1)
- # conjure (3)
- # datalevin (5)
- # datalog (2)
- # datomic (5)
- # events (11)
- # fulcro (40)
- # gratitude (9)
- # guix (32)
- # honeysql (10)
- # jobs (2)
- # lsp (32)
- # malli (15)
- # meander (5)
- # membrane (43)
- # missionary (3)
- # nextjournal (9)
- # off-topic (38)
- # pathom (3)
- # polylith (30)
- # portal (78)
- # programming-beginners (4)
- # quil (6)
- # re-frame (20)
- # reagent (21)
- # remote-jobs (2)
- # shadow-cljs (7)
- # tools-deps (6)
- # xtdb (23)
i listen over ting "folk som liker statiske typer blir ikke irritert over dette, folk som liker dynamisk typing blir irritert over dette" ☺️ https://twitter.com/DavidKPiano/status/1505585090314833922?s=20&t=-8B3PystIROMrqCB_4f1OQ
Jeg er på et rart sted. Jeg tror ikke jeg kunne koda frontend uten TS, men jeg tror ikke jeg hadde giddi å kode Clojure med typer.
Videre har Rich Hickey en fin slide i “Effective Programs” der han sier noe om kostnadene av (å rette opp feil). Typefeil og skrivefeil er ting som oppdages fort og er lette å fikse. Feil design er vanskelig å fikse. For “konkret” design er dyrt å fikse. Concurrency greier er vanskelig å fikse.
Han har også en passus om korrekte vs effektive programmer, der han definerer effektive programmer som programmer som løser brukerens problemer.
Vi har kjørt typescript og ClojureScript for frontend litt parallelt, men i det siste har vi kuttet ut det med TypeScript, og satser bare på ClojureScript videre.
Selv har jeg litt motsatt mening om types enn de fleste. Jeg liker types for små programmer (f.eks., C# via Linqpad er helt utrolig for scripting), men foretrekker dynamisk for større codebase, eller noe jeg skal jobbe med lenge.
Det er også kanskje en grense der static typing blir bedre igjen, men jeg tror ikke jeg har troffet den enda. Med dynamiske språk kan du få til veldig mye med lite kode. Den første versjonen av ClojureScript compiler var bare 1000 linjer, tror jeg.
Et av problemene jeg ikke helt har klart å formulere har noe med hvor langt data “reiser” og hvor mye du trenger å vite om data’ene på reisen. Og det er også godt mulig at sammensausingen av data og funksjonalitet har noe med saken å gjøre.
> Hvor langt data reiser > Tenker du på svaret på "hvem brekker hvis jeg endrer på denne typen" her? For det er noe jeg liker bedre i Haskell / Typescript / Rust / Go enn Clojure. Føler jeg kan ta meg råd til å "bomme" på typen først, og refaktorere seinere. I Clojure føler jeg meg mer låst, usikker på hvem som bruker at en key er det den er. Eller noe annet?
Ja, det er vel noe sånt jeg tenker på. I TS/React så “reiser” data’ene fra reducern’e mine over til React komponentene. Hvis denne reisen er lang, evt om det er mange mottakere av data’ene så er det jo greit med typer. Men hvis det er en kort reise som er en til en, så klarer man jo å holde ting i hodet.
Ja, vi lærte i Telia at på et større prosjekt som lever over lengre tid er det greit å kunne kommunisere formen av dataene. På et senere prosjekt der brukte jeg Spec akkurat for dette. Og med Spec 2 )om den kommer noensinne 😅 ) så blir det enda enklere å si nøyaktig hva en funksjon bryr seg om. IMO fungerte det veldig bra. (Jeg har ikke brukt spec overalt - bare på de viktigste funksjonene i pipelinen.)
vki hadde en diskusjon om dette på jobb i går, og landet på det Magnar har snakket en del om - generiske GUI-komponenter. Eller, GUI-komponenter som ikke vet noe om domenet. Det hjelper en god del på "reiseveien" til data, siden man får en slags brannmur fra staten på toppen, og så et par hakk ned med domenespesifikke greier, og så begynner man å møte på de generiske komponentene, og der slutter reisen til domene-dataene
Jeg har stort sett mislyktes med innføring av clj der 😭 To ganger har jeg overbevist et team om å velge clojure med det alltid endte opp med at teamet ble oppløst pga endret biz prioriteter. Så nå er det en mikrotjeneste, en biteliten backend, og en viktig batch job. I fremtiden blir det trolig bare mer Kotling og TypeScript og Dart.
Når jeg nå koder TS, så er typene jeg lager nesten uten unntak de samme greiene som jeg antagelig hadde gjort med spec, basically bare shape’n til props til React komponenter
Vi (jeg) koder egentlig ganske likt i TS/React som det jeg ville gjort i CLJS. Moduler som på mange måter ligner på ns’er som inneholder statiske funksjoner som tar data transformerer og lager nye data, av og til med noen sideeffekter, men (nesten) aldri tradisjonelle klasser/objekter og metoder.
Må vel innrømme at vi bruker useState for lokal state i Reactkomponentene, men det er vel (sånn fra mitt perspektiv) det.
En ting jeg tror man pleier å gjøre litt annerledes i ClojureScript vs TypeScript er å gjenbruke komponenter litt mindre. Spesielt med tailwind så er det nesten like raskt å skrive [:div.bg-gray-200.border.border-gray-300.rounded-sm ...] som det er å rekke for en container component. Det tror jeg hjelper litt med det problemet å huske hva slags properties en komponent bruker.
Vi har faktisk ikke så mange components, bare form inputs (dates, referanse autocomplete), dialoger, tooltips, osv.
Er det noen her som har prøvd Elm på front-end med Clojure på back-end? I Erlang/Elixir community var Elm en stor snakkis en periode. Men det var før Phoenix (web framework for Elixir) fikk «LiveView». Har hørt folk kalle Elm for «Haskell for web front-ends» bl.a.
Jeg har jobbet i en “Elm-sjappe”, og tror egentlig ikke jeg vil anbefale det 🤷
Jeg tenker at Elm er et skikkelig bra læringsverktøy, først og fremst. For eksempel er det mange som bruker Typescript for å føle seg trygge, men som glemmer å validere “typene” som kommer fra API-kall, som jeg vil tippe er en av de større kildene til typefeil (`undefined`)! I Elm har du ikke lov til å bruke API-data før det har blitt dekodet, og deretter må du pattern-matche og håndtere feilscenariet.
Liker også at det er et tydelig skille på rene state-oppdateringer (tenk redux), og “urene” oppdateringer (`redux-saga`). Man tvinges på en måte til å gjøre de riktige tingene, litt som man gjør i Haskell. Elm er fortsatt det eneste språket hvor jeg har vært komfortabel med å refaktorere kode med styrepils innabords.
Problemet er ikke nødvendigvis at Elm har fått lite kjærlighet i det siste, men snarere at filosofien i miljøet er litt kvelende. Plebeierne ikke får lov til å gjøre “farlige” ting, som å skrive native JS-kode for de vanskelige tingene, og man må derfor interop’e med Javascript via “porter” som kaller ut til den urene verden og sender svar tilbake. Så feks å gjenbruke en React-komponent midt i Elm-koden er det nesten bare å glemme.
Så om man feks har et designsystem basert på React-komponenter så er det enkleste å bare reimplementere de i Elm. Jeg syns barrieren blir litt for høy.
Jeg sitter med samme oppfatning som @UDB2Q0W13 og skrev så smått om det for en del år tilbake http://reimagined.io Året er nå 2022 og jeg foretrekker fortsatt Clojure(Script)? 🙂
Interessant artikel! Det var trist at det ble ikke noe av Eve...
I 2017 tror jeg. Var kjempegøy. Pakket alt i uberjar. Deploy som kopiering over remote desktop til windows-maskin som sto på et ledig kontor.
Elm har ikke fått så mye kjærlighet som jeg skulle ønske I nyere tid, jeg er ganske fornøyd med Typescript.
Av annet nytt: I min normale jobb bruker jeg utelukkende Python (kanskje litt R nå og da). Etter jeg begynte å lære Clojure, har jeg også begynt å skrive Python-kode ganske annerledes. Datastrukturer først, helt uten klasser. Bruker nå stort sett “verb-funksjoner,” og oppdaget også at Python har lambdas, map, reduce, filter, osv. Kollegaene mine tror jeg har blitt gal.
1Haha, ja! Environment- og package management er noe skikkelig herk i Python generelt, dog ikke like ille som i JavaScript. Conda har bedre dependency resolution enn pip, men ikke alle pakker finnes der. Og noen pakker finnes kun i Conda. Man kan bruke dem om hverandre, men da må man være svært forsiktig og gjøre ting i korrekt rekkefølge. Nå bruker jeg https://python-poetry.org til environment- og package management. Det ligner litt på en hybrid av tools.deps, Leiningen og Boot.
Mere kritikk av React Hooks: https://news.ycombinator.com/item?id=30753127
Jeg har jobbet i en “Elm-sjappe”, og tror egentlig ikke jeg vil anbefale det 🤷
Jeg tenker at Elm er et skikkelig bra læringsverktøy, først og fremst. For eksempel er det mange som bruker Typescript for å føle seg trygge, men som glemmer å validere “typene” som kommer fra API-kall, som jeg vil tippe er en av de større kildene til typefeil (`undefined`)! I Elm har du ikke lov til å bruke API-data før det har blitt dekodet, og deretter må du pattern-matche og håndtere feilscenariet.
Liker også at det er et tydelig skille på rene state-oppdateringer (tenk redux), og “urene” oppdateringer (`redux-saga`). Man tvinges på en måte til å gjøre de riktige tingene, litt som man gjør i Haskell. Elm er fortsatt det eneste språket hvor jeg har vært komfortabel med å refaktorere kode med styrepils innabords.
Problemet er ikke nødvendigvis at Elm har fått lite kjærlighet i det siste, men snarere at filosofien i miljøet er litt kvelende. Plebeierne ikke får lov til å gjøre “farlige” ting, som å skrive native JS-kode for de vanskelige tingene, og man må derfor interop’e med Javascript via “porter” som kaller ut til den urene verden og sender svar tilbake. Så feks å gjenbruke en React-komponent midt i Elm-koden er det nesten bare å glemme.
Så om man feks har et designsystem basert på React-komponenter så er det enkleste å bare reimplementere de i Elm. Jeg syns barrieren blir litt for høy.
Ja, vi lærte i Telia at på et større prosjekt som lever over lengre tid er det greit å kunne kommunisere formen av dataene. På et senere prosjekt der brukte jeg Spec akkurat for dette. Og med Spec 2 )om den kommer noensinne 😅 ) så blir det enda enklere å si nøyaktig hva en funksjon bryr seg om. IMO fungerte det veldig bra. (Jeg har ikke brukt spec overalt - bare på de viktigste funksjonene i pipelinen.)