Synes det var godt beskrevet 👍 Selv om jeg ikke ser noen av disse punktene som svakheter ved Clojure i seg selv. Men heller måter det skiller seg fra andre språk som kan være utfordrende for nye.

Jeg tror også at mangelen på en stor oppside er viktig. Lissom, hvorfor skal jeg gidde å lære meg disse nye greiene?

Funksjonellt, immutable data, og REPL er store oppsider for meg. Men disse fordelene "selger" liksom ikke så bra føler jeg.

Jag känner inte till sammanhanget som frågan ställdes i, men utan det ser svaret ut att missa målet. Du svarar på vad som kan göra att någon väljer att inte ge Clojure en chans. Vilket väl kan ses som svagheter, men jag skulle tolka frågan som vad som är språkets svagheter.

Jeg tror dette er fordeler du oppdager etterhvert. Men det er ikke sånn at «wow, nå er jeg 10x» to dager etter at du begynte med Clojure. Man spiller liksom The long game.

Ja, Clojure mangler ikke oppsider, men jeg tror det ofte kan være vanskelig å beskrive dem og selge dem inn. Det er med grunnleggende/lavnivå oppsider av en annen karakter sammenlignet med andre språk.

Jag har själv svårt att svara på den frågan. Det beror på vad man ska använda det till. Feks, Embedded? Svaghet: Clojure ryms inte.

Spel? Om det är grafikintensivt kommer inte Clojure att hänga med.

Hver gang jeg har prøvd å beskrive/selge inn "REPL-driven development" har de fleste respondert med: "REPL har mange språk. Det er ikke noe nytt eller revolusjonerende." Jeg har begynt å si "interaktiv utvikling" og "connected editor" istedenfor, og da hører jeg: "Men det er en særs dårlig ide å endre på kode som kjører, etc." Når jeg viser det i VS Code med Calva derimot, da blir folk ofte sjokkert hvor smooth det er. "Seeing is believing."

Ditt svar B är intressant. Clojure fixar felen i Java. Det borde kanske säljas in hårdare på den punkten. 😃

Jag har svårt för termen REPL-driven utveckling. Det är ju jag som driver, inte REPLen. Dessutom leder det tanken snett. Jag kallar det konsekvent för interaktiv utveckling.

Punkt B var min største "gut reaction" da @U5E9UP66T fortalte meg om Clojure første gangen. "Æsj! Java. Nei, takk."

Jeg mener at sammensausingen av jvm, Java og javas std lib er veldig uheldig.

Vad betyder uheldig? 😃

Jepp! Nå i dag forstår jeg at Clojure er runtime agnostic i den forstand at det finnes varianter for mange ulike runtimes, og at JVM Clojure ikke har en direkte kobling til Java språket å gjøre, men tilbyr interop-fasiliteter for å bruke biblioteker skrevet i Java.

Uhendig = Unfortunate

> JVM Clojure ikke har noe med Java språket å gjøre Jag skulle hävda att det har enormt mycket med Java-språket att göra.

Ja, hehe. Det kom ut litt feil. Det jeg mente å si er at jeg trenger ikke å lese eller skrive Java 🙂 (Foruten exceptions og sånt.)

Jag noterar att Primeagen reagerar liknande på när Java och JVM nämns i sammanhanget Clojure. Han ser det som avtändande.

För mig är Clojure’s styrka att det gör programmering roligt för mig.

Noen ganger har jeg tenkt at Clojure fortjener sin egen runtime/VM skrevet fra scratch i f.eks. C, Rust, eller Zig, hehe. Bare for å frikoble seg helt fra den emosjonelle koblingen folk har til Java og JVM. Men objektivt sett er det antagelig ikke verdt den enorme innsatsen.

Det är som sagt lätt att svara på den frågan. Men största svaghet? Nah! Jag tror jag hör till kategorin folk som @UASETR481 varnar för, som bara ser ett rosa skimmer med Clojure.

Det eneste JVM-en mangler (så vidt jeg vet) er tail-call optimization. Derav behov for loop + recur i Clojure istedenfor at en funksjon bare kan kalle seg selv.

Clojure er på .net og 🙂

Ja, det sänker ergonomin lite. Men någon stor svaghet är det inte eftersom Clojure bidrar med så galet mycket ergonomi i övrigt?

Ja, men har du prøvd å installere og bruke ClojureCLR? Det er ikke en spesielt hyggelig eller smidig opplevelse 😅

Att Clojure är ett gästspråk är en enorm styrka. Den enskilt största styrkan tillsammans med att det är en Lisp, som gjorde att Rich Hickey ens orkade skapa språket, uppfattar jag det som.

Clojure-CLR är bara en minut bort från din editor, @U01PE7630AC: https://github.com/PEZ/clojure-clr-starter

Babashka var en stor øyeåpner for meg. Det er mye enklere (men fortsatt ikke enkelt) å selge inn Babashka enn JVM Clojure er min opplevelse. Det er bare å finne et stort Bash script eller en stygg Makefile og erstatten det, så er folk solgt.

Nice, den hadde jeg ikke sett før, @U0ETXRFEW! Takk for info.

YAMLScript kan man se som ytterligare ett Babashka. En skillnad är att folk inte kommer behöva ändra speciellt mycket vanor. Bara skriva lite kod i sin YAML-fil och plötsligt är de Clojure-kodare.

Største ulempe? Jeg vil si at gode feilmeldinger fortsatt er mangelvare. Litt mer generelt kan man si at den største svakheten til Clojure kanskje er at det er for komfortabelt med å være til for de som allerede har skjønt greia. Altså: i liten grad tilrettelagt for nye folk.

Et eksempel er de nevnte feilmeldingene: Jeg er kjent nok med dem til at de ikke er til hinder for meg lenger - jeg reagerer ikke engang på dem. Men jeg legger merke til dem når jeg viser frem ting til folk som ikke kan Clojure godt enda. Da kjenner jeg skammen melde seg. "Joda, så, denne rælete skjermen med tekst betyr egentlig at du glemte et kolon her"

Den største svakheten med Clojure på JVM for meg personlig er kanskje at det er en litt tung platform - lang oppstartstid, relativt høye nedre krav til maskinkraft for å kjøre. Blir alltid litt misunnelig når jeg ser folk komme trekkende med sine bittesmå standalone Go binaries som starter opp på null komma svisj. Her er det dog håp i ting som Babashka på sikt kanskje.

En Clojure for Go hadde vært kult.

men hva skulle man kalt en Clojure for go?

Gojure

Enig! Det hadde vært awesome. Babashka/GraamVM løser en del av lang oppstartstidsgreiene da.

Cloggo

Med en tresko som logo.

Cloggo er den tilbakestående broren til muskelbunten Gojure

Eller bare Clog

Golc

Clog er litt koselig, men har litt uheldige konnotasjoner kanskje?

Go++

Haha! Clog finnes allerede, og det er en Lisp-greie: https://rabbibotton.github.io/clog/clog-manual.html#CLOG:@CLOG-MANUAL%20MGL-PAX:SECTION

Det største problemet med nye prosjekter er å navngi dem

Vet ikke hvor mange prosjekter jeg har mistet interessen for etter mkdir ...

Oheldig igen!

that blank stare into space mens man venter på inspirasjon…

Jag brukar tappa intresset efter att jag köpt domänen.

"I kveld skal jeg stunte ut denne idéen!" mkdir ... 2 timer senere: "Fuck it, er det noe bra på tv?"

“Det vore kul med något som gör det här!” Testa tjugo olika varianter på http://nameisp.com “Fuck it, någon (antagligen @U01PE7630AC) sa något i Slacken.”

Jeg eier domenet http://parens.no som skulle bli mitt AS-selskap av og for utviklere, delvis for å skape min egen Clojure-jobb 😅

Drømmen lever så lenge jeg betaler for domenet, haha

I så fall lever många av mina drömmar. 😃

En annen "killer feature" av Clojure: > "Clojure will help you scale your product without scaling your headcount." Source: https://flexiana.com/2023/01/heres-why-startups-should-develop-in-clojure-in-2023

Fravær av rammeverk er en slags blessing/curse tenker jeg. Jeg har jo sittet litt i fritiden og sysslet med et slags “template” for en web-server som inneholder en kombinasjon av biblioteker jeg liker å bruke for webutvikling. Men Clojure-miljøet har liksom ikke forenet seg rundt rammeverk på lik linje som Java-miljøet har samlet seg rundt Spring, og det er mye fleksibilitet i hvordan man vil løse problemer. Så da er man kanskje mindre samlet om en arkitekturstil da. Jeg syns det er litt digg, men kan nok tenke meg at det er utfordrende mtp stor omslutning rundt språket og miljøet. Jeg beskrev vel egentlig “Curse of Lisp” nå 🙈 Angående at folk er forutinntatt mot JVM så syns jeg det er interessant. JVMen har jo egenskaper som Clojure utnytter for å endre kjørende applikasjoner og lignende, men verden rundt oss virker nå å være mer rigget rundt at man skal rekompilere og redeploye hyppig (actions, kubernetes, flere podder, etc). Så på en side er oppstartstid og slikt sett på som et problem, men et kompilert program som ikke kan endres dynamisk er liksom ikke en styrke. Husker fortsatt at @U04V5VAUN måtte redde systemet fra en feil jeg hadde gjort hvor han koblet på REPL i tre podder(?) og reevaluerte en funksjon i produksjon mens kodefiksen lå og kvernet i deploy-pipelinen. Det er en veldig kul ting å kunne gjøre, men det er ikke en egenskap mange andre språk har, så kanskje det er derfor det føles litt som at alt av deployment og slikt virker designet for å gå i beina på akkurat den egenskapen?

Men så skjønner jeg jo at et system som kan endres mens det kjører over tid vil føre til at man mister oversikt over hva som “ligger ute”. Men det føles som noe man kanskje kunne løst i stedet for å gå i motsatt retning (kompiler, rullerende redeploy…)

> Husker fortsatt at @U04V5VAUN måtte redde systemet fra en feil jeg hadde gjort hvor han koblet på REPL i tre podder(?) og reevaluerte en funksjon i produksjon mens kodefiksen lå og kvernet i deploy-pipelinen. Det er en veldig kul ting å kunne gjøre, men det er ikke en egenskap mange andre språk har [...] Erlang er et av de få språkene (kanskje det eneste?) som har enda bedre hot code reloading/monky patching enn Clojure. Men kulturen er "ikke bruk dette med mindre du absolutt må eller ikke har råd til noe nedetid."

https://stackoverflow.com/a/6244328 kommer jeg tilbake til nå og i blant. Erlang og Clojure har ganske mye til felles, men har på en måte tatt to nesten motsatte tilnærminger til concurrency. Begger er dynamiske funksjonelle språk, og kanskje de eneste i sin kategori som fortsatt blir brukt i produksjon i noen særlig skala.

Erlang er på en måte råbra på distribusjon og concurrency over nettverket/distribuert til hundrevis eller tusenvis av fysiske maskiner, den biten core.async ikke har (enda).

Jeg syns det blir spennende å se hva som lander mtp virtual threads. Har testet virtuoso og tapestry, og begge føles ganske gode å bruke. Erlang/BEAM har en mer granulert garbare collector som ikke stopper hele verden, men JVMen har kanskje så bra ytelse at det ikke spiller så stor rolle

Ja, og måten BEAM gjør "rasjonert compute" på via "ticks" på er nokså unikt. Alle Erlang prosesser (det kan være flere millioner av dem) får like mye tid til å gjøre jobben sin, nesten som time share. Det gjør at latency blir spredt ut i systemet, og ikke lokalisert til en del av systemet.

Jeg kan anbefale alle å lese https://pragprog.com/titles/jaerlang2/programming-erlang-2nd-edition/. Det er en råbra bok og en øyeåpner selv om man ikke har planer om å bruke Erlang. Folk som liker Clojure vil finne mye interessant der.

Den doble t-en da 😅

Skal det ikke være det? :thinking_face:

Jo! Det må jo det. Det er bare jeg som sliter med tanken av å ha et domene med ett ord som slutter med samme bokstav som neste ord begynner med 😅 Den irrasjonelle OCD-en kicker inn.

Underlig kombo, for å si det mildt

Jag glömde helt bort Joker av någon anledning. Vad är underligt med kombon?

Joker ser ut til å være en "konkurrent" av SCI og deler av clj-kondo, skrevet i Go?

Jeg vil påstå at med babashka, så er joker, lumo og planck døde.

Joker kompilerer vel direkte til maskinkode og eksekveres ikke i en VM? Det gjør Go i alle fall, så vidt jeg forstår. Og noen andre Clojure dialekter, som f.eks. jank, kompilerer (snart) direkte til LLVM IR, og derifra til maskinkode. Så de kan vel teoretisk sett være raskere enda enn Babashka, som kjører på GraalVM. :man-shrugging:

Jo, men who cares lissom :) lumo/planck/joker ble jo alle brukt til scripts, ikke til å implementere spillmotorer eller HFT.

Den stora prestandaskillnaden kommer nog inte från native vs vm. Det är snarare compiled vs interpreted.

Dvs jag förväntar mig större skillnad i prestanda mellan Clojure och Babashka än mellan Joker och Clojure.

Det som er litt kult med BEAM (VM-en til Erlang/OTP) er at dens styrker utfyller/komplementerer JVM-en på en måte. BEAM er designet for ekstrem distribusjon, concurrency og fault-tolerance på tvers av hundrevis eller tusenvis av maskiner, uten at utvikleren må tenke på det. Hvis man kan targete JVM og BEAM, så kan man bygge praktisk talt hva som helst, bortsett fra kanskje low-level 3D grafikkgreier og sånt.

Det skulle vara intressant att se vad man kan göra med Guardrails+clj-kondo i kombo.

Ja, enig.