This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-07
Channels
- # announcements (12)
- # autochrome-github (4)
- # babashka (27)
- # babashka-sci-dev (2)
- # beginners (80)
- # calva (34)
- # cider (8)
- # clj-kondo (77)
- # clojars (34)
- # clojure (50)
- # clojure-europe (35)
- # clojure-nl (4)
- # clojure-uk (5)
- # clojured (2)
- # clojurescript (26)
- # core-async (4)
- # cursive (4)
- # datahike (4)
- # datomic (40)
- # emacs (7)
- # etaoin (1)
- # fulcro (12)
- # google-cloud (143)
- # hyperfiddle (1)
- # integrant (2)
- # jobs (1)
- # malli (15)
- # membrane (17)
- # off-topic (38)
- # pathom (1)
- # reagent (4)
- # releases (2)
- # remote-jobs (2)
- # sci (1)
- # shadow-cljs (10)
- # spacemacs (7)
- # tools-deps (5)
- # vim (6)
- # xtdb (37)
Quick question. How do you deal when you need to do something both imperative and functional in one iteration of a loop? Say I am iterating over a list of dirs, I need to git pull and generate some reports that I then return as a vector.
1. (map #(do (git-pull %) (generate-report %)) dirs)
2. (do (doseq [d dirs] (git-pull d)) (map generate-report dirs)) ;; yuck, iterating twice
Why a mapv
specifically? It isn’t lazy, but other than that it doesn’t make a difference here?
my generate-report
returns a vector
a transducer is interesting, but the git pull has to happen before anything else, so I am not sure it might directly help
I think either map or mapv is fine, as long as the git pull happens in the same "scope" as the report
It does. The only reason I don’t like it is it feels odd sticking something imperative like this in a map. Just something about it feels odd 😄
prefer arguments over dynamic vars, laziness doesn't play well with that combination
Yeah, nothing dynamic. Its all within one fn call with all arguments passed in
It is more a stylistic thing. I see this a lot more with Babashka because you tend to do slightly more imperative things with it
so I was not sure what you’d choose stylistically
Thanks @U04V15CAJ - Babashka is fantastic.
As are so many of your other libraries that get so much usage!
I read the Juxt blog on it. It is a similar problem but a slightly different use case since I sort of know what I am iterating over. But thanks for reminding me
mapv
specifically because it isn't lazy - I saw it way too many times that laziness escapes scope of a function it should not.
but for more complex pipeline I'd consider a transducer.
Otherwise I don't see anything super-weird with using a "mapping" operation for side effects.
I don’t think I mind the doseq to do the side effects and map to generate the sequence, yes its not efficient but it just doesn’t matter in most cases, unless you’re literally iterating over many thousands of files (but surely git pull itself is slow enough that you won’t even notice how long the map part takes)
I have nothing complex, and I love transducers and use them all the time, but I’d not thought of the laziness call here. Will definitely consider mapv
@U7KPK060K - I know right? that’s what I thought so too initially, but after a while, not so sure about that solution
I think code should be readable first, fast second. But probably in this case I would do both in a mapv
, but I wouldn’t mind too much if I saw the doseq version
I’ve definitely made the mistake of trying to use map or for and getting caught out by the lazyness before
Which would you prefer? Is there a better alternative here?