hihi, det henger sikkert litt sammen, det er ikke noen uttalt arkitektur på hvordan ting skal henge sammen, veien blir litt til mens man går osv

poenget mitt er vel mere at re-frame ikke sier noe om arkitektur, og at re-frame sin default er “bare gjør subscribe hvor du vil”

Så basically frontend, altså.

Poenget mitt er vel at man kan ikke bare legge seg ned og dø bare fordi rammeverket/biblioteket ikke forteller deg hvordan du skal leve.

Jeg tenker at du burde se dette fra den du intervjuer sin side: 1. Er det vanskelig for meg å lære (siden jeg ikke kan det fra før) 2. Blir jeg helt akterutseilt mhp andre jobber siden det er et ukjent språk og alle vil ha utviklere med 10 års erfaring i java.

Tankegodset i Clojure vil ihvertfall være gull verdt uansett hvilket annet språk folk skal videre til. Bøker som “Data-oriented programming” (og til en viss grad “Grokking simplicity”) er bevis på det 🙂

Clojure er en Lisp som kjører på JVM-en. Det er et dynamisk typet funksjonelt språk med et veldig stabilt og positivt/støttende økosystem (lite breakage, lite drama, god hjelp). Tankegodset fra språket har influert mange mer mainstream teknologier så som Redux.

heh

Mine tanker: 1. Som du ser, er syntaksen forskjellig fra språk som Javascript og Java. Dette gir en del fordeler man ser ved bruk, men det kan se uvant ut ved første øyekast. (elefanten i rommet) 2. Clojure har svært god støtte for funksjoner og data, og de fleste problemer kan løses med funksjoner og data. 3. Clojure er laget så man kan få feedback på hvordan ting funker og om det funker svært fort (vise en REPL) Og være tydelig på forventninger. Hvis dere ikke forventer at folk kan Clojure, si det, og fortell hvordan de kan se for seg å bruke de første månedene. Om de blir kastet ut i kode selv, eller om de får hjelp.

Lykke til! Håper du får laget litt Clojure-entusiasme 😊

Man vil ikke ha jobber som krever 10 års java-erfaring 😅

stemmer, i re-frame er det fritt frem for subscriptions (aka atomer som hentes ut via navngitte “subscriptions”). Vi har vel ca. null gui-tester, usikker på hvor mye det har med re-frame å gjøre

Gitt holdningen i originalinnlegget, ville jeg tenke at det har svært lite med reframe å gjøre 😛 Dog ville jeg tro at det ikke er trivielt å skrive meningsfulle tester for reframe slik dere ikke har valgt å kode det.

@augustl har sikkert mye å si om dette! Som kanskje står i https://www.amazon.com/dp/1484290569/ allerede 😅

😄

Bøker er veldig fine hvis man har mye man ønsker å dele og skrive ned!

hvis noen tvinger deg til å bruke Spring, så kan du bruke Spring Security bare, som et bibliotek. There’s a chapter for that!

kunne faktisk nesten ha re-brandet boka til “How to survive a Kotlin project as a Clojure programmer”

Hva med navnerom på event id? Du får kanskje uansett problemet med å sende rundt props. :thinking_face:

Jeg opplever ikke det å sende props rundt som et stort problem. Hvis du har et steg som oversetter domenedata til UI-data så har du fristilt domenedataene dine fra layouten - eller i det minste isolert den i en transformasjon.

resultatkode 😬

likte returkode best, samsvarer med returverdi

Det er vel egentlig en returverdi?

Det du ser i konsollet er jo sideeffekten.

Helt analogt med (println «Great success») som har returverdi nil

exit code är ju för program som avslutas och koden som ges säger något om hur det gick när programmet avslutades

Så returkode tycker jag är mest logiskt. En exit code är också ett return value

Det er jo bare returverdien til funksjonen main?

$? er jo i så måte helt analogt med *1 i et Clojure repl?

Ja, men du har returneringsvärden för andra funktioner med, och du kallar inte dem för exit code

Og uten at jeg er villig til dø på akkurat den åsen, så mener jeg at exit code er et lite gjennomtenkt begrep

Det kommer väl egentligen ifrån C om jag minns rätt

Möjligen ifrån innan dess

Man kunne lett ha tenkt seg et program fakultet som

$ fakultet 3
$ $?
6
$

Och C är ju lite löst definerat 😉

https://en.m.wikipedia.org/wiki/Exit_status

Är väl den vi pratar om?

Det er jo ingen standard for hva returverdier fra program betyr, annet enn at 0 som regel betyr at ting gikk bra.

Det är upp till var program att definera det

Är i princip ett binärprotokoll

Jepp.

Poenget mitt er vel at jeg synes at exit code er en beskrivelse av hvordan man bruker denne verdien idag, men at det generelt er en returverdi fra programmet som idag konvensjonelt brukes til å flagge om ting gikk bra eller ei, men som kunne blitt brukt til andre ting hvis man ønsket det.

Det store problemet med dagens konvensjon er at det er kun en verdi som signaliserer at ting gikk bra, men det er 2^32 eller no verdier man kan bruke for å signalisere at noe gikk til helvete.

Enig i det, men jag skulle nog sagt också istället för egentligen, då det låter som att du menar att det är en motsättning i att det är båda

Nei, ikke motsetning, men heller for snevert.

Har du något alternativ i åtanke? Nyfiken 🙂

Nei :)

Eller jo.

Hvis du tenkte deg at shell’et (altså replet til os’et) oppførte seg som et Clojure repl, så ville jo :

> ls .

Jeg ser at det ligger en haug med djevler i detaljene her.

@slipset ser argumentet! Alikevel - feks matte-programmene dc, bc og expr bruker alle stdout til å skrive svaret, i stedet for returkoder. Jeg vil argumentere for at konvensjonen er å returnere på stdout, som sikkert har praktiske årsaker (typen til exit code er int, som er litt begrensende). Når du ser på C-funksjoner (`int main...`) blir det jo derimot veldig som du sier.

Egentlig et interessant spørsmål om dette er en designsvakhet i skallene vi bruker - og om alt hadde vært bedre med funksjoner og returverdier. Jeg klarer ikke si ja eller nei på den, blir mye å se for seg. Kanskje noe ala Content-Type for å si om man vil ha data eller om man vil ha en menneskelesbar variant. Da er man kanskje fort i powershell-land.

Jeg skriver om til "returkode" for nå. 🙏 Takk for innspill! Det hjalp.

(tror ikke jeg skal lage et nytt skall som gjør dette korrekt i dag 😅)

"REPL-et til OS-et", det var fint @slipset 😊

Styrkene til dagens «Vi kommuniserer via tekst på stdout og stdin via pipes» er vel godt beskrevet i litteraturen.

Husk at | i Shell ender opp i systemkallet pipe som tar to file descriptorer om jeg ikke husker helt feil.

👍

Termineringskode? Termineringsreturverdi? 😅

Jeg synes alt det blir feil fordi det blir magisk. Det er ikke magi. Det er en int som returneres fra et program. Det er konvensjonene rundt det som gjør at det blir magisk eller vanskelig.

Lag fakultet programmet som returnerer resultatet via returverdien formå illustrere poenget. Og så kan man fortelle om konvensjonene og hvorfor det heter noe med kode og ikke verdi.

Og grunnen til at det heter noe med kode og ikke verdi er fordi man må dekode verdien for at den skal gi mening.

At echo returnerer 0 etter at den har klart å skrive noe gir egentlig ingen mening uten konvensjoner eller kunnskap om hvordan det skal dekodes.

Sånn oppi hodet mitt har returverdi og exit code vært to helt forskjellige konsepter i alt for lang tid, men når jeg endelig forstår at det egentlig er det samme er det en ting mindre å huske på, og verden blir litt enklere for meg.

Det blir morro når du ser på programmer som https://www.man7.org/linux/man-pages/man1/test.1.html og https://man7.org/linux/man-pages/man1/grep.1.html#EXIT_STATUS. Når man snakker om grep, så kan man argumentere for at den «gjør for mye» siden den vet hvordan man skal forholde seg til både filer, fildescriptorer og greier. Man kan si at grep er easy, men ikke simple. Simple ville vært et program som gitt en streng med tekst og en regex ville returnert om teksten matchet eller ikke.

👍

noen må ta grep!