Clojurians Log v2

Dette er en moderne klassiker av en artikkel om problemene med lazyness i Clojure: https://clojure-goes-fast.com/blog/clojures-deadly-sin/

Selv bruker jeg stadig oftere into med transducers.

Yup. Lazyness er den mest irriterende funktion. Næsten lige så irriterende som indeks 1 arrays i lua.

lest den! Den har ligget i bakhodet en stund, men har slått ordnetlig fast nå. Bruker transducer-into mer og mer selv.

illustrasjonen er nydelig 😂

det gør profilering virkelig svært

Transducer all the things. 😂

Yeah, I've started getting a bad feeling when I see (->> ,,, (map ,,,) set) 😄 Why allocate the lazy-seq(s) when you want the set?

Husker en av de første gangene jeg skulle profilere koden vår. Profileren viste at all tid ble brukt i json serialisering…

Jeg har hørt flere Clojure YouTubere nevne at de ønsket at Clojure ikke var lazy ved default, men at laziness var opt-in ved behov.

Det er måske tid til, at jeg skriver en linter, der forbyder lazyness

Det som er dumt med å ikke omfavne lazyness, er at man jobber mot fibrene til Clojure. Det blir vanskeligere å lære og vanskeligere å selge inn, hvis man må si "ikke gjør det som dokumentasjonen eller intuisjonen tilsier - følg heller denne smale, litt kronglete stien - for ellers kommer satan opp av bakken og biter deg".

Samtidig er det en av de vanskeligste tingene å lære og forstå. Det var er det i alle fall for meg.

> ellers kommer satan opp av bakken og biter deg [i baken] 😂 😂 😂

Elm traff på første forsøk, liknende sequence-API, uten lazyness. Men Elm kom vel fem år etter Clojure.

En ting som har forvirra meg mange ganger er at programmet oppfører seg annerledes i REPL og når man kjører det utenfor REPL som en tjeneste, fordi REPL «tvinger ut» laziness enkelte ganger. Så jeg fikk ting til å funke slik jeg ville når jeg testa i REPL, men så oppførte det seg annerledes i produksjon (ofte uten at jeg la merke til det).

har blitt truffet av den, gitt! https://clojurians.slack.com/archives/CBJ5CGE0G/p1774452780088949

@andersmurphy noen har kanskje skrevet den linteren som forbyr lazyness: https://github.com/imrekoszo/unlazy

Nå er jeg forvirret, @teodorlu, hvorfor skriver du engelsk til @andersmurphy? 😄

sorry 😅

Lol tenkte det samme

fullstendig språkforvirret her

> Samtidig er det en av de vanskeligste tingene å lære og forstå. Det var er det i alle fall for meg Det er jeg helt enig i. Derav denne tråden! Jeg tror det er lurt å lære seg begge deler, og tradeoffs ved dem.

leser noe tekst jeg har skrevet på engelsk, og simsalabim, hodet er i M-x english-mode

Samme. Etter en måned i Japan. Guttungen går rundt og babler en salig blanding av japansk, norsk og engelsk.

Cue "Kamelåså"-referanser.

Haskell og andre «ordentlige funksjonelle språk» har vel samme kognitive problem som Clojure rundt laziness. Det er jo en «hallmark feature» av «ekte» funksjonelle språk 😅

Men kanskje det er bedre compile-time greier som holder en i hånda. Jeg kan ikke Haskell godt nok for å vite hvordan det funker der.

en liten clanker-sesjon gir at både Ocaml, Elixir og Erlang er eager.

> The reason why Clojure didn't go all lazy is that laziness is expensive. For each value with a postponed computation, the runtime has to keep track of it and remember the code to be executed and its context (local variables). A value is internally replaced with a wrapper that holds all that information, a thunk (Haskell term). Thunks often trigger additional memory allocations, occupy space in memory, and introduce indirections that slow down the program execution. Many of those inefficiencies can be alleviated by an advanced compiler like the one in Haskell. But the design of Clojure prompts for a simple, straightforward compiler, so a full-lazy approach in Clojure would likely have caused performance problems. (Fra artikkelen over)

> clanker-sesjon 😂

Ja, kjenner bedre til ML/OCaml (har lest om det i ferien), Erlang og Elixir.

Jeg var ikke ferdig med kapittel én før jeg fant første greie jeg misliker med OCaml. Ulike operators for ulike datatyper.

Typ + for ints og +. for floats, etc.

tror lazy-greia startet med https://www.cs.tufts.edu/~nr/cs257/archive/dan-friedman/cons-not-evaluate.pdf (Friedman & Wise, 1976). Det er også noen tilfeller der lazyness gir bedre ytelse enn non-lazy, særlig når filer er involvert. Haskell-folka var involvert i Miranda før Haskell, som også er default lazy (default non-strict). Miranda hadde et strict-keyword (lazy omtalt som non-strict) for opt-out. Fin liten Miranda-intro: https://www.cs.kent.ac.uk/people/staff/dat/miranda/manual/28.html

Har tenkt mye på om jeg skal bryte med Clojure og gjøre https://mino-lang.org eager ved default, for ikke å forvirre de stakkars spilldesignene som gjør enklere scripting. Men konkluderte med at jeg vil være så nær «canon» som mulig.

for øvrig, jeg synes cons bør evaluere argumentene sine, så kan vi heller tilby lazy-API-er med makroer der det trengs, for eksempel sånn future gjør det.

(future (Thread/sleep 100) "the result")

@gar men den djævel kommer og har skarpe tænder. 😂

Helt klart. Med min sparsomme prod-erfaring med clojure (har noen nattlige batch-jobber for import av data, that's it), så skjønner jeg ikke bæra når det først går galt og jeg skal prøve å finne ut av det. Og det er gjerne ifm med en lang kjede transformasjoner i en (->>)

Feilmeldingene i Clojure er helt kryptiske for meg også 😅 https://mino-lang.org/documentation/errors/ er ganske nice synes jeg. Sånn jeg ønsker meg i JVM Clojure også.

Diskusjonen om å trekke Jank sine forbedringer inn i Clojure.core har allerede startet! Husker ikke helt hvor/når, men Alex Miller er på saken 😄

Oh! Har ikke sett på Jank sine 😅 Det burde jeg nok ha gjort før jeg implementerte mino sine.

Men det som gjør mino litt unik er at det er en runtime som er designet fra bunnen av kun for Clojure. Så selve runtime bruker også samme opplegg for feilmeldinger. Dvs. man får ikke kryptiske Java-aktige feilmeldinger, selv for ting som skjer dypt inne i VM-en.

Jank kjører også uavhengig av JVM-en, men skal ikke utelukke at du har funnet på noe lurt her!

Ja, stemmer. Jank komprimerer til maskinkode via LLVM, som med C eller C++. mino kompilerer til custom bytecode og kjører i sin egen VM med JIT, som er implementert i C. Jeg vurderer å implementere MLIR og gjøre slik at mino også kan kompileres til maskinkode for både CPU og GPU (á la Mojo). Men det er ikke core use case for mino. Det språket (eller rettere sagt runtime) som ligner mest på mino er kanskje Janet eller Lua.