Clojurians Log v2

Jeg skrev en kommentar til @magnars vedr hans threading post. Han ha’kke kommentert på den, så jeg tar sjansen på å legge den her: Hey! Bra blogpost om threading. En ting som jeg synes threading hjelper veldig med er at man unngår dype call-stacks på godt og vondt. Jeg har ikke helt klart å formulere dette ordentlig, men i java er det jo ikke uvanlig å skrive kode som dette (som jeg skriver i Clojure :):

(defn d [...] )

(defn c [...]
  ...
  (d ...))

(defn b [...]
   ...
  (c ...))

(defn a [...]
  ...
  (b ...))

Dette er ofte et resultat av "extract method". Problemet her er at alt er like tett koblet som det en gang var, og det er vanskelig å leke med ting i isolasjon. Threading hjelper deg til å skrive dette på en mer funksjonell måte:

(->> a b c d)

Hei! Hvor kan jeg se posten hans? Takk!

https://www.kodemaker.no/blogg/2020-06-thread-first-and-last/

:thinking_face: :thinking_face: :thinking_face: :thinking_face: blir ikke call stacken like dyp? :thinking_face: :thinking_face:

Nei, den gjør ikke det (tror jeg)

(f (g (h (i)))) har til enhver tid bare en funksjon på stacken (sånn jeg forstår det) fordi du lar i gjøre seg ferdig før du kaller h som må få gjøre seg ferdig før du kaller g osv.

Der du kaller fra en "tail" posisjon over kunne man sikkert gjort sånn som man gjør med tco, nemlig bytte ut hele stack -framen med det som skal til for å invokere funksjonen i tail-posisjon, men det kan man jo ikke gjøre på jvm'en i allefall.

hmmm ja, det er jo et poeng, mens i den andre er det tail calls, og jvm-en har ikke tco, riktig

Nå er det egentlig ikke de dype call-stackene jeg ikke liker, men heller det at koden er "koblet" selvom vi har ekstrahert funksjonenen.

how do you even stack... For å kalle h, må du jo ha returverdien fra i på stacken

Jo, du må ha returverdien på stacken, men i det første eksemplet har du 4 stackframes kjørende. Det har du ikke i det andre eksemplet.

(tror jeg). Dette er jo langt over mitt inkompetansenivå, selvom jeg tok IN140 en gang tidlig på nittitallet.

ja, for de smarte datamaskinene være tar vel bare returverdien til i og gjør om til inputverdien til h, får man tro

på smarte EDB-måter

ordet "calling conventions" havnet i hodet mitt, er vel masse detaljer rundt akkurat hvordan de gjør det. Men de trenger jo ikke å ta vare på eventuelel input-verdier til i og andre funksjonskall som har skjedd inni i, osv

I det første eksemplet kan man ikke kalle a uten å også kalle b, c, og d (uten å bedrive mocking/redeffing

I det andre eksempet er kan man lett kalle a i isolasjon, noe som er nice mhp tester.

ah, et annet killer argument

godt poeng

Rich Hickey følte nå en disturbance in the force, as if someone understood how decomplected Clojure is

🙂

Takk!