This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-09
Channels
- # aleph (1)
- # announcements (7)
- # asami (1)
- # beginners (44)
- # calva (54)
- # cherry (24)
- # cider (6)
- # clj-kondo (19)
- # cljsrn (27)
- # clojure (119)
- # clojure-europe (61)
- # clojure-gamedev (38)
- # clojure-germany (7)
- # clojure-nl (1)
- # clojure-norway (104)
- # clojure-portugal (4)
- # clojure-spec (4)
- # clojure-uk (1)
- # clojurescript (38)
- # cursive (18)
- # datomic (11)
- # emacs (9)
- # events (1)
- # fulcro (4)
- # holy-lambda (7)
- # introduce-yourself (7)
- # jobs (1)
- # malli (6)
- # off-topic (4)
- # pathom (4)
- # pedestal (16)
- # podcasts-discuss (1)
- # polylith (27)
- # portal (17)
- # releases (2)
- # shadow-cljs (46)
- # squint (1)
- # xtdb (9)
Morn! 😊
challenge: bruk elisp i stedet for Clojure på neste prosjekt. Fra https://old.reddit.com/r/emacs/comments/lly7po/do_you_use_emacs_lisp_as_a_general_purpose/gnvzisy/ Tldr: flytrafikk-data i Tyskland ble i en periode rutet via headless emacs og elisp > Some weeks later I got called to our second office, they were behind schedule and needed an extra pair of hands. We had - for reasons I don’t know - ATC workstations on microVAXen running that 4GL on VMS but they struggled with getting messaging over the network going - the 4GL was terminal oriented, did not know what a network was, but ATC messages (like airplane hand-overs from airfield to airfield or to Eurocontrol) needed to go to the local message router and from there to the site the message was destined for. We’re talking “no internet” here - all X.25 and leased lines and zero convenience. > > Well, I got to work and figured out that it was easier to make VMS talk TCP/IP than HP/UX talk DECnet, so I got that setup, and then picked the hot new tech, DCE, to do the messaging. I did C extentions for the 4GL a lot, so the VMS side was done in a couple of days. Then they told me to talk to Herr Doktor So-and-so who was responsible for the actual message router. > > In Germany, a Herr Doktor is always right (they have forgiven Moses by now for not having space on the stone tablets, but it really is the 11th Commandment). This one worked at Symbolics before so knew one programming language: Lisp. He wanted to code the message router in Lisp because of the “complex” (meh) requirements, but there was no Lisp (or no Lisp in budget) for HP/UX so he was stuck. I told him about Emacs, gave him my tape with the ports, and maybe that was a mistake ;-) > > A week later - I helped out finishing the 4GL UI in the meantime and completed the messaging protocol - he called me in, quite happy. He showed me the code - page after page of Emacs Lisp, with exactly zero comments “because Lisp is self-documenting”. I got scared, it was an air traffic control system after all, but I was no Herr Doktor so I whipped up the DCE native code for Emacs, made a hack to have it start headless in message router server mode, and we got messages to flow. I did a code hand-over, and drove back home a couple of days later. The “self-documenting” code, as far as I know, landed in production so at least for a while, all ATC message routing in Germany was done through Emacs.
Fantastisk 😂 Lurer på hvor lenge det kjørte på Emacs, og om det var noen bugs
I forbindelse med https://www.coderetreat.org sist helg delte en kollega (i annet land) en observasjon som jeg lurer på om dere er enig i. Han hadde et inntrykk av at folk (les: utviklere) i veldig mye mindre grad enn før er interessert i å styrke karrieren og faghåndverket sitt gjennom sideaktiviteter (utenom arbeidstid). De vokser og lærer bare gjennom prosjektet eller jobben sin. Deltar bare i arrangementer i arbeidstid, og investerer ikke i egen læring og faglige vekst ut over dette. Han har kommet til denne konklusjonen etter å både ha vært evangelist for betalte og ubetalte arrangement på ettermiddag/kveld/helg og som utviklingsleder lagt til rette for læringsaktiviteter (inntil N timer) i arbeidstiden som kun et forsvinnende lite mindretall gjorde bruk av. Men han tror også at pandemien har styrket denne tendensen veldig kraftig. Kort oppsummert: Er dagens fagmiljø ikke lenger opptatt av læring, vekst og deliberate practice utenom det de får (eller tvinges til) gjennom arbeidsoppgavene sine)? I hvert fall ikke i samme grad? Skyldes dette i så fall endringer som skyldes pandemien, eller er det mer en generasjonell greie? Er også veldig nysgjerrig på hvordan dette fordeler seg mellom mainstream språk/teknologi-økosystem og mere smale språk/teknologier.
Forøvrig var GDoCR fabelaktig, som alltid. De som ikke har fått delta på code retreat før, anbefales å prøve.
Hvis man kikker rundt seg og stort sett ser på jevnaldrende så stemmer det sikkert at flere av oss var mer aktive da vi var yngre ihvertfall 🙂 Eller mener han at det er en generell trend på tvers av bransjen?
kanskje fokuset flytter seg mere over på business når man blir eldre? Typ du jobber med en startup i stedet for å delta på meetups
Det er mange mulige svar på det du skriver, synes jeg. En del av meg synes det er rart at vi utviklere skal drive med kompetanseheving på fritiden. Hvor mange leger/snekkere/whatever driver og leser seg opp på nye greier på fritiden? Ligger piloter og leser manualer for nye flytyper på senga i håp om at Norwegian kjøper inn the new shiny? En annen del av meg har ingenting bortsett fra forakt for folk som passivt sitter og venter på å bli lært opp i et eller annet. React sier du? Nei, da må jeg gå på et to måneders React kurs. Tilslutt noe om oppmøte på sånne utenomjobb greier på kveldstid. Selvom mange utviklere er unge, sies det, så er det jo noen av oss som har blitt eldre uten å bytte karriere og blitt prosjektledere. Kanskje vi har andre prioriteringer (på kveldstid), kanskje vi ikke er så interesserte i the new shiny fordi vi har sett det før? Kanskje vi søker informasjon i andre fora?
Helt enig med Christian. Før barn hadde jeg tid til dette men ikke nå lenger. Man jeg ser på foredrag, prøver å lære nye lærerike ting (som Rust), driver med side-projekter osv. Men ja, deliberate practice har jeg ikke prioritert.
For min egen del var jeg nok mer opptatt av å drive med fagutvikling OG få oppmerksomhet tidligere 😅 Typ: mer aktiv på brukergrupper, foredrag, skrike ut om det hver gang jeg lagde open source greier osv. De tingene er ikke så viktig for meg lengre, så mye av innsatsen min foregår mer i det stille 🙂 For 10 år siden var også Twitter en mye mer teknologi-orientert plass (ihvertfall min boble), og jeg kan ikke se at det er noe like synlig sted som har tatt over den rollen etter at Twitter ble allemannseie og dreide over på politikk og generell sutring.
Og som @U04V5VAUN var inne på: etter å ha holdt på i 20 år så er det en del ting man har sett før, og man når metningspunktet for nye språk/rammeverk/biblioteker osv.
Relatert: Tidligere i karrieren jobbet jeg mye med å fylle opp en slags faglig grunnmur. Jeg føler jeg nå har en solid grunnmur, og er litt ferdig med å tilegne meg kunnskaper “just in case”, og har et litt mer praktisk forhold til det. Lærer meg gjerne ting som jeg får bruk for, men lar vel i større grad jobben styre hva disse tingene blir.
man kan vel også velge litt selv hvor mye man lærer på jobb. Ved å bytte oppdrag som konsulent eller bytte jobb som ansatt, eller bare ved å være på et sted hvor det skjer mye nytt, så er det jo lagt opp til at utviklere er folk som klarer å sette seg inn i ting. Jeg hade aldri rørt Kotlin når jeg havna på første Kotlin-prosjekt. Samme med Clojure, det ble bare innført uten noen tidligere erfaring (ikke JVM-erfaring en gang 😇)
Som i, jeg har funnet min stack og er relativt lite interessert i å bale med masse annet ræl.
Det er mulig. Selv liker jeg å tenke at jeg vet om noen av kjennemerkene ved en sånn stack, men det kan jo være at jeg bommer.
Feks tenker jeg at ting som ikke er bygget på immutable data ikke er verdt tiden min, for de problemene som muterbar tilstand fører med seg trenger jeg ikke å få tilbake
tror også at dere ville fått med dere en ny fet stack om det skulle dukke opp. Det var jo ikke sånn at jeg tråla internett etter den neste stacken min og kom over Simple Made Easy, den talken smeltet hjernen min helt uten innsats fra min side 🙂
Det som vel er viktig er kanskje å ha en oversikt over problemene man har, og så se etter ting som løser disse problemene. Mye “ny” tech løser problemer jeg ikke har.
det med muterbar data er rart i grunn. I typescript-land går jeg aldri på en smell der :thinking_face: Samme med React + hooks, man driver liksom ikke og muterer. Beklager elendig analyse, bare slo meg at “å nei, den ble mutert” ikke har skjedd på lenge. Kanskje jeg koder rundt det uten å merke det, av gammel vane
Det er fordi man hele tiden gjør copy on write.
[…xs]
er jo helt vanlig i Typescript/moderne js.
Så du koder imutable, men med noe performance downside.
tror det sitter i fingra å gjøre {newProp: foo, ..oldMap}
. Lurer på om React spytter ut masse warnings om du muterer også
sant, men tipper at hvis man måler den gjengse CL(JS)-app så gjør den mye copy on write og, maps og lister gjør vel det ut av boksen med mindre enn 8-ish elementer i seg
egentlig er jo persistente datastrukturer (hamt og sånt) “bare” en implementasjonsdetalj som gir deg performance.
Det interessante med immutable data er garantien som følger med, ikke akkurat hvordan runtimen gjør det i praksis
jeg har sittet i “immutable by convention”-kodebaser i javascript, og kan skrive under på at det ikke er det samme 😅
Men det er vel litt samme argument som at vi ikke gjør typefeil fordi vi er så et eller annet. Da kommer haskell folka og sier at det er jo ingen garantier.
lurer på om hooks i React har løst (“løst”) mye av dette. Man har ikke lengere en samling av tilstand på toppnivå som må koordineres, typ redux, og man kan ikke mutere hooks, bare sette nye data og rendre derfra og ned
men ja, man driver fortsatt og beskytter seg. Så det er “copy on write immutability by convention” i JS
er det mulig å se på hele tilstanden til en react-app som bruker hooks? eller bor den piecemel her og der?
aka du kunne like gjerne hatt cljs-datatyper i JS, bare at man ikke har det, og må late som med spread-operators og sånt
usikker, det finnes sikkert noen dev tools. Men idéen er vel at man har en slags hybrid OO-approach hvor nettopp poenget er at du ikke trenger å ta stilling til hele tilstanden, bare der du holder på nå
bare at det ikke er OO. Litt vanskelig å forklare hvordan hooks ender opp med å funke i praksis egentlig
Ja, man kunne jo hatt cljs datatyper i js, men det ville jo blitt merkelig. Du kunne f.eks ikke willy-nilly latt data-literals bli immutable uten å brekke en hel haug med gammal drit.
måtte vært all-in fra starten av, ja.. Men tror f.eks React støtter cljs sine data, uten noe wrapping, siden de implementerer iterators, og React bruker bare for (x of y)
under panseret (aka iterators, hvor collectionen selv sier hvordan den itereres)
rart, har gått fra å være forkjemper til all data transparant på toppnivå til hybrid-OO-hooks som “skjuler” data, uten å helt merke det
synes ikke all data på toppen er helt uten trade-offs heller da. Styrete å flytte komponenter rundt i hierarkiet f.eks, komponenter på toppen må vite om komponenter under seg og sende inn riktig data osv, det er jo en egen form for kompleksitet det og
mulig det jeg kritiserer nå er min egen programmeringsmodell, kanskje det kan løses 🙂
ofte nok i grunn, særlig i startfasen flytter ting seg rundt om kring og hit og dit, men også senere
og “nå vil jeg at også her skal vi ha filopplasting med modal popup som gjør cropping først”, men så er det styr å legge den til fordi toppnivå-staten må ta høyde for det på riktig sted osv, i stedet for å bare slenge inn en komponent som har sin egen state som er totalt uinteressant for resten av verden
aka, ikke på noe punkt er det irriterende at man ikke vet i toppnivå-tilstand om en <select>
er åpen eller ikke
synes fortsatt spørsmålet “hvilken state skal være synlig og behandles hvor” er et spørsmål som er interessant å stille, og ikke bare kategorisk slutte å tenke på og flytte på toppen
det rare med hooks er hvordan de har oppnådd at man kan ha state rundt om kring, samtidig som all dataflyten er enveis (altså bare nedover i treet, ikke oppover)
I og for seg enig i det. Og hvis man utvikler komponent-biblioteker tror jeg at local-state gir mening.
det er vel forsåvidt ikke noen hindring for å gjøre det i Clojure heller, da. Er jo bare å gjøre det 🙂
Men, og et viktig, men er at det ser ut som om vi går mot hooks all the things, og det synes jeg er skummelt. Fordi da blir React det rammeverket som du hata da det het angular, og helt umulig å migrere vekk fra når the new shiny som du virkelig vil ha kommer.
men…. den store skyggesiden er kanskje at det er trivielt å fucke det opp. Om man ikke er senior med tunga rett i munnen, ender man fort opp med useEffect
som er bugge-buggety-buglords
hmmm :thinking_face: Mentalt sidestiller jeg “react-app” med “cljs-app”. Og man kan jo ikke bare bytte ut cljs i en cljs-app heller
Nei, men det sånn at ønsket om å bytte ut ting endrer seg ulikt over tid. Så, du kan fint ønske å fortsette å kode i js selvom du ønsker deg vekk fra jquery og backbone.
Og, når du da velger teknologi, må du ta inn over deg at ønskene om å endre ting kommer i ulik hastighet. Og det lønner seg da å velge teknologier slik at du kan endre enkeltdelene ganske, vel, ganske enkelt. Loose coupling og high cohesion og alt det der.
Det er vel også derfor vi (senior/clojure) utviklere liker biblioteker framfor rammeverk. Det er enkelt å bytte ut et routing rammeverk, noe vanskeligere å bytte ut spring.
her kom jo hyper-argumentet for Clojure inn: med mindre du jobber med å dra inn sloppy dependencies, kan koden din leve evig uten at du trenger å gjøre rewrites, siden alt er så stabilt
selv React sliter jo der. Har enn så lenge gått greit å oppgradere, men det er vel bare et spørsmål om tid før vi må gjøre noe med en dependency vi har som bruker deprecated API-er i React
om ikke annet en fordel at React må funke med all den gamle koden til Facebook og, hvor de heller sikkert ikke har lyst til å rewrite all den gamle koden sin
er “ren businesslogikk” vanskeligere i GUI-kode? :thinking_face: Enig med backend, elsker å skille på “overflaten” som håndterer omverdenen, og funksjonene mine som tar imot data og returnerer data og er mest mulig ren businesslogikk
der har vel “ren” hiccup-kode en superfordel ja, godt poeng. Du kan bytte ut react med snabbdom uten å endre mere enn en håndfull linjer, kanskje ingen
da har du jo samtidig på en måte ikke “brukt” React, og implisitt sagt at det ikke er noen fordeler med React sin modell, men det kan jo absolutt hende det er verdt det og man fikk rett i fremtiden når alle ditcher React
Det interessante skillet er mellom “forretningslogikk” og “renderinglogikk”. I min verden har ikke de noe med hverandre å gjøre
Når begrepene fra domenemodellen din dukker opp i React-komponenter så har du i mine øyne en ugrei sammengrising av to verdener.
skal sies at man ofte gjør dette i react og. Typ, du har et react-komponent med hooks, som rendrer til et annet react-komponent som bare tar inn props, som du også smeller inn i storybook o.l (basically devcards)
@U0MKRS1FX jeg er uenig i at du ikke har brukt React hvis du bare kan bytte det ut med Snabbdom. React for meg er akkurat det Snabbdom tilbyr. Alle de andre greiene er ting jeg gjerne hadde klart meg uten.
Og hvis React hadde holdt seg til akkurat det, så hadde det vært ferdig og vi kunne gjort andre, morsommere ting enn å oppgradere React hele tiden.
Du får joine teamet vårt @U04V5VAUN 😄
Trodde dealen var at du skulle joine oss? Jeg har jo ikke laget det halvfungerende TS oppsettet i emacs bare for meg?
Jeg husker jeg lagde Kodemaker sin IRC-bot i Emacs Lisp. Var veldig nyttig, ettersom den kunne lene seg på IRC-klienten i Emacs.
in other news, tvingte meg selv til å sette opp REPL, tok nesten en time, får det sikkert i fingra etter hvert, REPL var nøyaktig riktig måte å iterere frem en liten funksjon som gjorde noe enkle datatransformasjoner. It’s happening
er det kotyme å la comment-blokkene man ofte ender opp med (?) ligge og slenge og sjekke dem inn og sånn?
vi har comment-blokker i bunn av hvert namespace med eksempler og nyttekode 👍
Når du har dyrket frem et stykke kode i en comment-block så kan noe bli funksjoner/produksjonskode, noe kan bli tester, og noe kan ligge igjen som interaktiv dokumentasjon. Det mest hårete kan ryddes unna,.
👌
Det er kanskje det som alle gjør. Jeg har jo ikke hatt noen etablerte clojure-kodebaser å lære av, så jeg vet liksom ikke sånt. Men jeg prøvde en gang å få litt mer reproduserbare REPL-sesjoner, og sjekket inn ALT jeg gjorde. Puttet det under dev/repl/$today.clj
. Men jeg likte det ikke noe særlig. Jeg fortsatte i alle fall ikke med det. Det ble liksom for mye styr. Og jeg kunne ikke se REPL-kode sammen med resten av kode, så jeg fant ikke greiene mine heller.
At dere gjør det i samme fil som funksjonaliteten under src og rydder opp litt (kanskje) før dere sjekker inn svarer på alle mine spørsmål! 😊
Kode i comment
kan få være litt mer surr enn produksjonskode, men det må røktes litt for å være nyttig
Dagens raritet: Vi har en clojure.core/match
som nå feiler kompilering med “file name too large”. Hadde en teori om at det er for mye kode inne i makroen - og den ser ut til å stemme 🤯
Og SÅ forbanna stor er den ikke. Det er 41 patterns som etterfølges av ett funksjonskall
> Når du har dyrket frem et stykke kode i en comment-block så kan noe bli funksjoner/produksjonskode (…) Klinger nesten som framgangsmåten i «TDD as if you meant it» (se f.eks. https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/). Liker godt et mønster som går REPL -> kommentar -> test -> funksjoner -> prod-kode