Fork me on GitHub
#clojure-europe
<
2020-09-21
>
kardan05:09:02

Good morning

plexus05:09:31

Good morning!

jmayaalv05:09:43

Buenos dias

orestis06:09:31

Καλημέρα

slipset06:09:49

Kalimera! God morgen!

genRaiy08:09:11

a small question of style for you... when I see the update-last from @otfrom I can grok the if and the else cos it's a snappy bit of code

(defn update-last [v f & args]
    (if (seq v)
      (conj
       (pop v)
       (apply f (peek v) args))
      v))
but I am always a little concerned with Clojure that too many forms between an if and the else can allow the else to get a bit lost and can (has been for me) the cause of silly bugs so I think this one here is definitely within bounds ... so do you feel the same and if so when would you break out the cond or something like this
(defn update-last [v f & args]
  (cond
    (seq v) (conj
              (pop v)
              (apply f (peek v) args))
    :else v))
like I say, over the top for this case but for me, 2 or three more lines of the true side of the if and I would break out the cond or do an if-not
(defn update-last [v f & args]
  (if-not (seq v)
    v
    (conj
      (pop v)
      (apply f (peek v) args))))
thoughts?

Dmytro Bunin09:09:58

Maybe (if (empty? v)....

Dmytro Bunin09:09:19

I also like to put the easy flow at the beginning

3
orestis12:09:30

Agree with the easy flow at the beggining, and with using cond when things become hairy.

otfrom13:09:21

for me if either leg of the if became too long I'd prefer to factor it into another funciton and keep the if short

otfrom13:09:32

and only use cond if there are more than 2 choices

otfrom13:09:37

1 or nil -> when

otfrom13:09:57

more than 2 -> cond

otfrom13:09:26

complex and more than 2, then possibly core.match or multimethods

otfrom13:09:15

I quite like multimethods for quite complex things, it makes each path quite clear

genRaiy13:09:13

nice rules of thumb so :thumbsup::skin-tone-3:

otfrom13:09:21

I usually write out the function all in one and then factor out the legs. Testing in a rich comment block as I go

ordnungswidrig14:09:16

I, too, love multimethods but they get in my way so easily with code reload, or when abused as a “plugin system”.

ordnungswidrig14:09:54

Maybe it’s just bad coding habits on my side. I like cond and potentially calling individually named functions which help understanding what’s going on

otfrom14:09:12

@ordnungswidrig yeah, I find that too. I usually do them b/c I know things are going to have complicated bodies or refactring a cond

otfrom14:09:42

individually named functions are good. multimethods means that I can worry slightly less about names

otfrom14:09:08

I've never really taken much advantage of them being open before, but I have worked with libraries that do like dali

plexus14:09:06

Kaocha leverages them for plugins and that works quite nicely

genRaiy14:09:29

we use them for mapping protocol messages so yeah, the openness is a delight

genRaiy20:09:15

Goodnight

❤️ 3
👍 3