This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-08-16
Channels
- # announcements (25)
- # babashka (15)
- # beginners (14)
- # calva (60)
- # circleci (1)
- # clerk (1)
- # clj-kondo (13)
- # cljdoc (7)
- # clojure (45)
- # clojure-austin (1)
- # clojure-bay-area (1)
- # clojure-brasil (4)
- # clojure-dev (9)
- # clojure-europe (24)
- # clojure-norway (105)
- # clojure-uk (2)
- # clojurescript (6)
- # conjure (1)
- # core-typed (4)
- # cursive (4)
- # datalevin (1)
- # datomic (25)
- # emacs (31)
- # fulcro (3)
- # humbleui (10)
- # hyperfiddle (19)
- # jobs (2)
- # luminus (3)
- # malli (13)
- # nbb (5)
- # off-topic (16)
- # polylith (2)
- # portal (7)
- # releases (2)
- # shadow-cljs (5)
- # sql (8)
Jeg var (og er vel fortsatt) helt ny til Clojure og har kun Slack-miljøet å støtte meg på. Dog har jeg erfaring med en god del andre programmeringsspråk (inkludert Common Lisp) fra tidligere (som også kan være en ulempe noen ganger). Jeg må innrømme at Clojure føles vanskeligere å lære enn en del andre språk uten at jeg har reflektert spesielt dypt over årsakene til det enda. Ironisk nok tror jeg det er fordi Clojure er så simpelt i den forstand at det er svært lite syntaks og andre "støttehjul." En forståelse for teoretiske, konseptuelle og idiomatiske konsepter som ikke direkte synes i selve språket er viktigere enn i andre språk som er mer rigide og påtvinger slike ting med spesielle syntaktiske konstrukter, biblioteker og frameworks i større grad.
Uten bøker, talks på YouTube, podkaster og hjelp her på Slack hadde det tatt mye mer tid å lære seg ting helt på egenhand. Det å ha en eller flere mentorer er helt uvurderlig selv om det kun er via Slack og andre digitale kanaler.
@leif.eric.fredheim, er det noen bøker du har likt spesielt godt?
Living Clojure, Getting Clojure, Elements of Clojure og Clojure Applied. Nå har jeg ikke lest alle sammen perm-til-perm, men litt stykkevis og delt og om hverandre. Jeg liker måten de bøkene er skrevet på og at de legger fokuset på hvordan en bør "tenke om- og i Clojure og funksjonell programmering mer generelt" i tillegg til å lære bort selve språket.
Jeg har lest Getting Clojure og Elements of Clojure selv - synes de har hjulpet veldig godt på tankesett for min egen del. Kanskje jeg må sjekke ut LC og CA også 😊
En praktisk ting som er litt dumt: Flere av bøkene ble skrevet før deps/CLI og bruker fortsatt Leiningen til eksempler. Helt i starten ble jeg ganske forvirret av det, og eksempelkode som ikke fungerte.
"Living Clojure" er den beste nybegynnerboka synes jeg. Den gikk ikke for raskt frem. Den aller første boka jeg prøvde meg på var "Clojure for the Brave and True," og det var et merkbart hopp hvor den plutselig ble for avansert for meg, og jeg falt av lasset.
Men hvis du allerede har lest "Getting Clojure" og "Elements of Clojure," og har en del hands-on erfaring med Clojure nå, så tror jeg kanskje "Living Clojure" blir litt for basic for deg.
Jeg var også gjennom "Clojure for the Brave and True" (det var da ting begynte å gi mening) og "Programming Clojure". Merker at jeg fremdeles liker å lese litt i de bøkene jeg har - men det blir mer "lurer på hva de sier om protocols" enn "nå skal jeg lese boka fra A til Å".
Ja, det er sånn jeg bruker dem også. Jeg har kjøpt alle bøker relatert til Clojure som var å oppdrive, delvis for å støtte forfatterne og Clojure-miljøet, men også for å kunne bruke bøkene som oppslagsverk på teamer ved behov, fordi det er færre blog posts og sånt sammenlignet med andre språk. Pluss at jeg foretrekker å lære fra bøker generelt, fordi det er lagt utrolig mye tid og innsats i å samle, strukturere og presentere temaene på en god måte.
Ja - jeg synes også jeg får mye mer ut av åtte timer med en bok enn åtte timer å søke rundt etter artikler og meninger på Internett :)
Jeg har gått å tenkt på en idé om å samle alt Clojure-relatert materiell på én nettside. Typ artikler, blog posts, YouTube videoer (transkribert), bøker, podkasts, etc. En slags "meta link hub" hvor en kan legge inn, kategorisere og tagge media med metadata, og kanskje litt community stuff hvor en kan stemme på innhold som er bra, legge inn kommentarer, linke til annet relevant innhold, etc. For å gjøre det enklere for folk å finne bra ting.
Jeg har tenkt litt det samme! Feks starte med alle lenkene på https://clojure.org/news/news og finne en måte å tagge / lage spillelister. Jeg prøvde litt en dag, men ble sittende fast i parsing av html og XML.
Japp! Det kunne etterhvert blitt til "Hacker News/Reddit/Medium/Stack Overflow," men kun for Clojure. "The one and only place for Clojure content."
Jepp! Og linke ting sammen. Så f.eks. hvis du har sett på en video om ett spesifikt tema, dukker det opp andre blog posts, podkasts, etc. om samme tema. Da må man linke ting sammen på en smart måte. Det kan hende en kan bruke en deep learning modell for å gjøre det, ellers blir det kanskje for mye manuelt arbeid. Eller så må man crowdsource det, sånn at hvem som helst kan sende inn nytt innhold, kategorisere, tagge, etc. litt à la Stack Overflow men for innhold istedenfor Q&A.
(takk igjen til @marius.enerly for å påpeke at jeg var alt for uforsiktig med skyte-fra-hofta-språk om nybegynnerne 🙌, alle er velkomne!)
Jeg synes ikke du var for uforsiktig, @augustl — Så på det som humor. Men jeg kan selvsagt ikke prate for andre enn meg selv 😅 Nå er jeg kanskje mindre hårsår og vanskeligere å fornærme enn de fleste.
Jeg har også (i mitt stille sinn) tenkt at Clojure er litt vanskelig å komme i gang med. Mye taus kunnskap, mye implisitt kunnskap. Jeg prøvde i 2014, skjønte ingenting. Prøvde igjen i 2016, og begynte ballen å rulle; det var først da jeg fikk til å jobbe med en REPL.
Selv synes jeg Clojure var ganske greit å lære seg, men brukte mye tid på å forstå hvordan jeg skulle bruke det på en fornuftig måte i en applikasjon. Bakgrunnen fra java/kotlin/go kom på mange måter i veien for dette eller måtte av-læres. REPL tok det f.eks lang tid før jeg tok i bruk på en effektiv måte.
jeg hadde masse sterke meninger når jeg kom inn i Clojure, som matchet ganske så 1:1 med hvordan Clojure er skrudd sammen, så jeg følte vel mest at jeg var kommet “hjem” 😄 Husker også at jeg stod skikkelig på barrikadene for å ikke ha noe “globals”, når vi startet med Clojure i 2011 eller når det var, så var det f.eks vanlig å bruke dynamic bindings en del til ting som config osv, i stedet for å bare sende inn argumenter til funksjoner
I boka "The Design of Everyday Things" (en fantastisk bok!) skriver Don Norman om "affordances" og "signaling," og "requiring knowledge in the head" vs. "putting knowledge in the world." Jeg har ofte tenkt at Clojure avhenger mer av "knowledge in the head" enn andre språk. Ikke hva gjelder selve syntaksen (Clojure har jo nesten ingen syntaks), men hvordan ting kan (bør) gjøres på rent konseptuelt og mekanisk. Andre språk som har mer spesifikk syntaks og rammeverk kommuniserer tydeligere hva en kan gjøre og hvordan en kan (bør) gjøre de tingene—En kan observere det i selve koden, i.e., "knowledge in the world." Men… Når man tenker seg om… Så er det ofte mer "magi" som er "skjult under teppet" i andre språk. Clojure er mer direkte og mer fleksibelt (har flere "affordances"). Noen ganger tenker jeg på Clojure som et strengeinstrument, fiolin, chello eller gitar: en har en mye større grad av frihet og måter å uttrykke seg på med plassering av fingre, glissando, vibrato, hammer-on, pull-off, pizzicato, etc. Andre språk er mer som piano hvor tagenter enten er trykket ned eller ikke. En har færre dimensjoner å utfolde seg på. Jeg spiller selv gitar og piano (ganske dårlig vel å merke!), og synes begge instrumentene er nydelige, men gitar var helt klart vanskeligere å lære. Strengeinstrumenter uten bånd, som fiolin og cello, er enda vanskeligere å lære fordi de er mer "åpne" og notene ligger ikke rett fremfor ens øyne. Men en kunne også sagt at strengeinstrumenter har potensiale for flere "bivirkninger" enn f.eks. piano, så analogien er nokså tynn.
Når jeg tenker meg er det kanskje mer riktig å si at Clojure er som et piano, fordi det rent mekaniske er betydelig enklere enn i mange andre språk. Man kan se alt som skjer i koden rett fremfor seg, på samme måte som man kan se alle notene rett fremfor seg på et piano. Ingenting er skjult sånn sett. Men når det kommer til hva en kan gjøre og hvordan det kan gjøres, så er Clojure mer som et strengeinstrument, fordi åpenheten og fleksibiliteten er enorm. :man-shrugging: Kanskje en veldig dårlig analogi dette 😅
her går du i Hickey sine fotspor 😄 https://www.youtube.com/watch?v=MCZ3YgeEUPg
Hahaha, det var jeg ikke klar over 😂 Eller kanskje jeg har sett den talken for noen år siden, så har underbevisstheten min jobbet på spreng.
Det finnes et lignende problem innen billedkunsten også: Når en skal male noe, er det ofte enklere hvis man velger seg et sett med begrensninger først. Det kan være både motiv og medium. For eksempel, "jeg skal male et naturlandskap med fjell i bakgrunnen, en elv og et rådyr på et jorde, og jeg skal bruke oljemaling, og kun disse fem fargene." Hvis man starter helt uten begrensninger er det mye vanskeligere. Det samme når en skal skrive en roman: Det blir enklere hvis man velger seg en sjanger og setter noen rammer først.
Med Clojure så har man færre slike begrensninger og rammer satt for seg. Derfor oppleves det som vanskeligere. Så man må lære seg å sette sine egne begrensninger og rammer som gir mening for problemet og konteksten man forsøker å takle.
Clojure gjør det enklere (men det er fortsatt vanskelig) å endre på disse begrensningene og rammene senere når det viser seg at en gjorde noe dumt. Når man går gjennom dører er man ikke alltid nødt for å stenge dem bak seg.
Dagens spesifikke kode-spørsmål. Har du brukt protocols i det siste? Til hva? Motivasjon: jeg innbiller meg at det er bra å kunne, men bruker det sjelden i praksis. Rich snakker om "open systems" - og at han heller vil ha dispatch via feks protocols enn pattern matching eller conditionals.
Sist jag brukade det var för att dölja implementationsdetaljer kring Sound API i HTML5 och Cordova
Var mest bara positivt med det. Kunde också implementera en fake implementation som fungerade jättebra i testing och utveckling som inte involverade att spela in ljud (dvs testa resten av logiken)
Jeg har aldri brukt protocols, men har kategorisert det som "noe à la et interface i C#" (som kanskje er veldig naivt og feil).
Er det ikke mest aktuelt å bruke protocols når man bruker deftype og klasser (`extend` og Java interop greier)?
jeg har protocols sammen med macros som en språk-feature som er nyttig for de som lager libraries, ikke for businesslogikk
lurer på om jeg bare har sett protocols brukt internt i libraries og, til å støtte N ulike implementasjoner av noe interne greier. Man kommer som regel langt med funksjoner 😄
har en magefølelse av at f.eks Optimus kunne brukt protokoller til noe? (Optimus bruker det ikke.) Men føler ikke den mangler det heller
Personlig liker jeg hvordan sequence-abstraksjonen fungerer i clojure kjempegodt. Den tror jeg bruker Interfaces og ikke protocols, mener at protocols kom i en senere clojure-versjon. Men det er et så godt eksempel på "en datatype, 100 funksjoner" (https://www.cs.yale.edu/homes/perlis-alan/quotes.html)
Jeg ser at borkdude bruker defprotocol i en del av sine libs i alle fall (https://github.com/search?q=owner%3Aborkdude+defprotocol+language%3AClojure+path%3A%2F%5Esrc%5C%2F%2F&type=code).
Haha, "hva er idiomatisk?" "la oss se hva borkdude gjør via kodesøk på Github". Kjempelurt! 😄😄
En av mine største clojure-blundere var å bruke multimethods et sted de ikke var nødvendige. Ble bare surr.
hmm er noen artige eksempler der ja, f.eks hvis du har din egen datatype/ting som du har lyst til at skal kunne dereffes, da kan du implementere protokollen i clojure for derefs
jeg er veldig glad i multimetoder! Men bruker dem ikke sååå ofte i app-kode i grunnen
stedet jeg har brukt dem mest var når jeg laget min egen teksteditor, og da er det jo mye datatyper og oppførsel og greier som skal håndteres
en teksteditor er jo faktisk nærmere bibliotekskode enn applikasjonskode, siden den blir en frittstående modul med masse “interfaces” for å jobbe med den osv
> we need to go deeper
>
Jeg nominerer emmy.util.def/defgeneric.
"for å lage dette biblioteket, holder det ikke med eksisterende verktøy for dispatch. Vi må finne på vår egen"
Resultatet synes jeg er knallbra å bruke, men det er vanskelig å forstå hvordan biblioteket henger sammen.
https://github.com/mentat-collective/emmy/blob/e16b5692b04972f0bc9ea6d07f7ead41edccc066/src/emmy/util/def.cljc#L51
> Egen teksteditor > Kult! Kan forstå at det gir mening her, ja. Jeg tror det ofte er lurt å bruke "den minst kraftige abstraksjonen som trengs" når man løser et problem. I applikasjonskode trenger man mindre kraftige abstraksjoner enn i bibliotektskode (min påstand).
Generativ testing er jeg kjempefan av. Jeg bare savner å jobbe med problemer der jeg faktisk kan forsvare å bruke det.
nei, men ble sittende å tenke på nå at det hadde vært et morsomt prosjekt å open source
og som et potensielt interessant eksempel i litt mindre skala for de som lurer på hvordan google docs og vscode funker
> og som et potensielt interessant eksempel i litt mindre skala for de som lurer på hvordan google docs og vscode funker > Ja, ikke sant. Jeg ser mye verdi i å ha ting open source så man kan referere til det, ikke nødvendigvis fordi man mener at andre bør bruke det.
og en måte å få litt mere verdi av disse 6mnd jeg holdt på med prosjektet “lag CMS-produkt fra bunnen av” som enn så lenge ikke har blitt et produkt noen kan bruke 😄
"What Would Borkdude Do?" bruker jeg flittig, haha 😂 Søker ofte på hans GitHub-konto etter eksempler.
Motivasjon for protokoller: https://clojure.org/reference/protocols Protokoller definerer en abstraksjon som kan implementeres på flere måter. Så, “litt som et interface i Java eller C#” altså, men se dokumentet over for forskjeller (forbedringer).
I https://github.com/msolli/proletarian/blob/main/src/proletarian/protocols.clj har jeg to protokoller, hvorav den ene kanskje er unødvendig (QueueWorker), fordi den ikke har (og neppe kommer til å få) mer enn én implementasjon. Men Serializer er nyttig - brukeren av bibloteket kan komme med sin egen serialiserer, og biblioteket vil bruke den.
I C# bruker vi ofte et interface for å sørge for at alle metodene til en klasse er dekket av tester. Klassen og test-klassen implementerer samme interface. Da kompilerer ikke koden hvis man har glemt å implementere noe i test-klassen. Flere biblioteker for tester lener seg på den måten å gjøre ting på.
Mange måter å gjøre polymorfisme på! Kan anbefale denne lille boka, som katalogiserer de ulike måtene: https://leanpub.com/clojurepolymorphism
Jaaa, takk! Det er jo egentlig polymorfisme vi snakker om her, protocols er jo bare et verktøy for å gjøre det.
Hvis du har et knippe med funksjoner som “jobber sammen”, og som abstraherer “noe”, så er protokoller en fin måte å pakke dem sammen på og formalisere det hele. Det blir litt “løsere” med “bare” funksjoner.
> Hvis du har et knippe med funksjoner som “jobber sammen”, og som abstraherer “noe”, så er protokoller en fin måte å pakke dem sammen på og formalisere det hele. Det blir litt “løsere” med “bare” funksjoner. > Er det lov å be om et eksempel?
(defprotocol IAudio
(start-recording [this])
(stop-recording [this])
(cancel-recording [this])
(recording? [this]))
(defprotocol IRecording
(save-recording! [this data]))> Jag gillar protokoll när jag håller på med I/O Jeg mener å huske å ha lest noe liknende fra James Reeves (hiccup, integrant, duct). Lurer på om det kom fra Duct-dokumentasjonen.
Lite osäker på frågan, men om du undrar över om jag tagit det ifrån James Reeves så är svaret nej. Det är påkommet efter mycket svett och tårar när jag skrev reverie (CMS i Clojure jag skrev för en massa år sedan). När jag började skriva det så hade jag inga protokoll och skrev om allt för att använda protokoll. Allt blev mycket bättre med protokoll i det projektet och det löste rätt så många problem jag hade i första iterationen
> Lite osäker på frågan Ja, det var mest en observasjon fra min side. Tror jeg leste det på #C5K1SHR6X. Jeg skjønte ikke helt hvorfor han argumenterte for det den gangen. Men etter å ha sett på artiklene dine og lest svar fra andre, forstår jeg bedre hvorfor dette er lurt!!
ja kanskje særlig om "tingen" egentlig er et lite sett med ting som alltid gir mening at er samlet, altså protokoller med mere enn én funksjon
> Er det lov å be om et eksempel? Serializer (se ovenfor)! 🙂 encode/decode fungerer fint sammen. Det kunne vært løst med “bare funksjoner”: Send inn en encode-funksjon og en decode-funksjon, og så kaller biblioteket dem. Men her sender du i stedet inn “noe” som implementer protokollen med de to funksjonene.
Om du har bibliotek som jobber med generelle datastrukturer / objekter er protokoller særlig nyttig for kunne tilby extensionpoints uten at callsite må forholde seg til mapping mellom "type" og "funksjon". Ett eksempel er jo naturligvis clojure.core (som Rich Hickey har uttrykt å angre på at ikke større deler var bygget på protokoller). Eksempel fra eget repository er https://github.com/duckyuck/minoro#extensibility
En annen styrke til protokoller (over interfaces) er at du kan implementere protocols på klasser/objekter uten å endre implementasjonen (kildekoden) av de.
Ikke nødvendigvis så veldig relevant for styrkene til protokoller, men jeg starten en gang i tiden et (litt for ambisiøst) prosjekt for å reimplementere java.time i ren Clojure/Clojurescript (100% API kompatibilitet var målet). Hele API'et er da basert på protokoller som speilet interfacene i java.time. https://github.com/duckyuck/jiffy/tree/master/src/jiffy/protocols
Noe av det fineste i det prosjektet der var for øvrig testdekningen som var 100% automagisk drevet av generative tester som sjekket paritet av implementasjonen opp mot java.time sin implementasjon. Endte opp med å finne en bug i java.time underveis 😅
@anders , hvis du har tid og lyst—Send meg gjerne en liten melding med tittel på meetup, en kort beskrivelse og en dato som passer for deg, så kan jeg ordne med det praktiske og meetup nettsiden, etc.
@leif.eric.fredheim will do 👍