Fork me on GitHub
#clojure-norway
<
2020-06-20
>
slipset10:06:12

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 ...))

Jakub Holý (HolyJak)18:06:44

Hei! Hvor kan jeg se posten hans? Takk!

magnars09:12:46

Ikke meninga å være dust og ikke svare. Denne dukket ikke opp for meg før Clojurians fikk seg Slack-historikk. 🙂

slipset10:06:41

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)
Sånn ca.

augustl19:06:25

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

slipset19:06:25

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

slipset19:06:49

(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.

slipset19:06:18

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.

augustl19:06:02

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

slipset19:06:54

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

augustl19:06:04

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

slipset19:06:03

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.

slipset19:06:34

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

augustl19:06:41

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

augustl19:06:44

på smarte EDB-måter

augustl19:06:30

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

slipset19:06:33

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

☝️ 3
slipset19:06:55

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

augustl19:06:22

ah, et annet killer argument

augustl19:06:25

godt poeng

augustl19:06:46

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

😄 3