Clojurians Log v2

Tror det er forskjell mellom å utvikle spill og annen programvare. I Clojure har vi innebygd datastrukturer vi bruker hele tiden. MEN de bruker mye minne fordi de kan inneholde hva enn du putter inn dit. For å minske minnebruken alt hva du kan, som man vil når man programmerer spill, må du ha typer. Men ellers enig i dine andre poenger. Tenker mye av det handler om forskjellige økosystemer. Spillutvikling vs programvare.

Har ikke interaktiv programmering samme problemer som inkrementelle compiles da? Aner ikke hvor mange ganger jeg har glemt å fjerne en referanse til en funksjon som jeg har fjernet, og så krasjer CI etter en push. Og motsatt greie når jeg bruker Reitit: Siden funksjoner direkte referert i en datastruktur må jeg også rekompilere et annet navnerom eller bruke #' for å midlertidig fikse problemet (som jeg glemmer å fjerne senere.. men heldigvis ikke committer)

Det er jo ikke store problemer, og til en viss grad føler jeg det er en læringsgreie. Men det er jo fremdeles problemer og feil man helst skulle unngått.

> For å minske minnebruken alt hva du kan, som man vil når man programmerer spill, må du ha typer. Ja og nei! Vi har struct of (typed)arrays med https://github.com/cnuernber/dtype-next. Chris har plenty av Clojure-programmer som slår C++-benchmarks. For mer info, anbefaler jeg min eneste opptreden som podcast-vert: https://www.youtube.com/watch?v=zYNlZXTV14E

> Har ikke interaktiv programmering samme problemer som inkrementelle compiles da? Joa, problemet er ikke borte, men vi kan i alle fall jobbe på en bit av systemet "under en var". Så lenge vi kan redefinere en var, kan vi jobbe interaktivt. Men da må vi jobbe litt fokusert interaktivt.

spillmotorer gjør typisk 1. for hver frame, a. gjør fysikk b. gjør grafikk I Clojure ville jeg nok lagt opp til en var-deref hver frame. Det er ikke vits i å oppdatere det som skjer inni en frame-render, det vil bare gi visuelle artifacts. Litt som at vi med ring-kompatible http-servere typisk bruker en var som http-handler. Reitit fikk støtte for å ha handlers som vars i en ganske ny versjon (0.8 eller noe tror jeg).

> ML og Lisp er bare akademisk fordi det er noen på C++-komitéen som oppfører seg akademisk og ikke pragmatisk Denne var litt rar. Er ikke LISP nærmest definisjonen på pragmatisme? Kanskje ikke på språk-nivå, men definitivt i runtime. Remote-repl og endring av kjørende system i reaksjon til omstendighetene må være et greit vitne til det?

Clojure og common lisp er ubestridelig pragmatiske! Men Common Lisp bærer vel mye preg av at det var veldig pragmatisk i 84 (eller når det ble laget), og tok med alt som var "nice" fra datidens Lisp-dialekter. Resultatet ble et stort API. @hypirion kan dette bedre enn meg. Andre dialekter som Scheme og Guile er sterkt idealistiske/prinsipielle, og er mindre interessert i pragmatisme. Scheme (både MIT-Scheme og Racket) ble laget på universiteter for undervisning og forskning, og gir faen i HTTP-servere og sånn. Men jo, den er kjemperar! Men de sitter jo og prater. Og vertene er … pratmakere som heller vil ha klare meninger enn å ha rett / være nyansert 😅 Og jeg blir litt sinna når folk som visstnok skal være ekspertene sprer feilinformasjon! Særlig når det de slenger dritt på hadde vært et nyttig innspill til diskusjonen de faktisk prøver å ha.

Common LISP er litt som C++ i at den har blitt laget av en komité og har støvsugd en haug med idéer inn litt ukritisk: Se på https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node1.html for hele greia. Jeg føler liksom ikke at Common Lisp Object System (CLOS) er nødvendig i språket f.eks., det er egentlig "bare" en haug med makroer. Samme for loop -greia, liker den like "dårlig" som for i Clojure. Har litt mye rar syntaktisk sukker som man egentlig ikke trenger (?) Føler ikke at dette er et symptom på at komitéen er akademisk da.

Men jeg føler jo det er litt bomskudd fordi hverken Common LISP eller en rå Scheme er det folk bruker i praksis. Man går for Clojure eller Racket, kanskje Guile, i disse dager.

Takk for opplysningene, her lærte jeg masse 🥰 Bare nysgjerrig: hva ville vært en bedre/enklere løsning enn for til kombinatoriske problemer?

clojure.math.combinatorics? Det er primært :when og :let jeg ikke liker med for, om du skal ta det kartesiske produktet er det helt ok tenker jeg.

Jeg blander begreper. Det var produkt jeg mente. Har ikke noe forhold til :when og :let, men kan skjønne at de gjør ting unødvendig komplisert.

Utrolig fin blogg! Og trivelig innlegg 🙂 Likte font, tekst og farger veldig godt. Behagelig.

Tusen takk, så hyggelig! ☺️

Kjempekult at du skriver på norsk 🥰 og hjertelig takk for skryt 😊

Veldig artig å lese!

Koselig 🤗 Velkommen til den norske Clojure-bloggosfæren! 😅

Haha, takk! Var mye gøyere å skrive på norsk enn på engelsk også

Og angående fonter @teodorlu, jeg brukte denne til å finne en pen font-regel som ikke krever noe nedlasting for de fleste klienter: https://modernfontstacks.com

Visdom og empati i den teksten der! Fint å ta oppgjør med den typen begreper.

Helt enig! Jeg kategoriserer "brukerfeil" som ux-bugs 😊

@msolli 🥺🙏 ?

🥹

Tirsdag 3. mars tenker jeg.

Jeg liker "Duplicate event"-funksjonen på Meetup! 😃

Thank you, ser.