Fork me on GitHub
#clojure-uk
<
2019-10-17
>
thomas07:10:59

morning lovely people

❤️ 4
dharrigan09:10:21

Do people mostly tend to use mapv rather than doseq for eager evaluation?

rickmoynihan10:10:43

I’d use doseq where I want a nil i.e. pure effect, and an eager-like for, i.e. nested iteration… guessing you mean doall.

danielneal10:10:02

Ah I think we had a conversation about this the other day, quite a few different options depending on what you want to do

rickmoynihan10:10:18

In which case it depends I think on whether you’re being given something that might be lazy… or if you’re in control and want something eager. I’d assume the later given your question. So if you have the control and want something eager, then you’re better creating it as such with either into, a transducer, or mapv — but also consider whether the datastructure is important.

danielneal10:10:30

I’ll definitely use into, mapv and doseq quite regularly, doall less so

rickmoynihan10:10:09

yeah doall over a lazy seq that you’ve created is code you don’t need.

rickmoynihan10:10:23

better to just create what you want directly

dharrigan10:10:41

So, let's say I'm slurping a json file and creating a map, inside that map there is a key with a vector (of strings). I want to hit an API with each string, one after the other, would you invoke that API via a mapv (passing in each string) or a doseq?

danielneal10:10:22

What does the api return?

dharrigan10:10:46

a json response that I'm just echoing out to the log

danielneal10:10:21

I’d probably use doseq or run! in that case, because there are only side effects, the return value not used

rickmoynihan10:10:42

Yeah you shouldn’t use mapv to force effects

dharrigan10:10:48

kk, thank you both! 🙂

rickmoynihan10:10:11

be explicit about the effects, so doseq run! etc are much better.

danielneal10:10:14

https://clojuredocs.org/clojure.core/run%21 run! was the one I found out about the other day when we were chatting about this, I’d always used doseq before

dharrigan10:10:20

which is perferred, doseq or run! (I seem to recall, somewhere, can't remember, that run! should be the first choice...can't remember the reasons)

rickmoynihan10:10:07

use run! if you’re mapping an effectful procedure you already have over a sequence you already have (sounds like you do).

rickmoynihan10:10:43

use doseq if you’re building the effects inline.

rickmoynihan10:10:29

e.g. (run! println (range 10)) or

(doseq [i (range 10)]
  (dosomething! i ,,,)
  (dosomething-else! i)))

dharrigan10:10:03

(run! (fn [vin] (check-eligibility vin)) vins) works grand! (I'll probably use a function literal, just playing...)

dharrigan10:10:22

thanks both!

rickmoynihan10:10:22

but it’s not the end of the world if you pick either way — it’s totally fine… I’m splitting hairs somewhat. A more important distinction is picking doseq if you want for-like comprehension behaviour.

rickmoynihan10:10:46

i.e. nested iterations, :while :when :let are all useful.

dharrigan10:10:11

that's great information, I'll keep a note of that.

Wes Hall10:10:35

I don't think I have ever used run!. Somehow it is one of those core functions that I always forget even exists.

Wes Hall10:10:16

Honestly, if I found a magic lamp, I think my first wish would be to have a complete mental catalogue of the clojure core API 🙂

danielneal11:10:49

an unusual and humble request from a genie

folcon11:10:52

I’m going to echo @wesley.hall here, I don’t think I’ve ever used run! to the point where I vaguely know what it does but can’t even remember the args >_<…

rickmoynihan12:10:57

It was introduced in 1.7 without the kind of fanfare features like transducers got, so many old timers who learned core in the 1.0 days either missed it, or were stuck in their ways. And I think that meant a lot of more recent entries to the community missed it too — as a lot of tutorials etc will use doseq.

folcon11:10:51

yep that’s basically what I’d use doseq for :)…

dharrigan11:10:23

What is a bit confusing (for me at least!) is that in the run! docs, it says runs the supplied procedure, shouldn't it be runs the supplied function. I'm always thinking functions thesedays...

Wes Hall11:10:19

@danieleneal You only say that because I haven't told you my other two wishes 😛

danielneal11:10:51

ARe you planning on packaging your wishes up as a lazy sequence to get by the “you can’t wish for more wishes” rule

Wes Hall11:10:13

@dharrigan That might be a subtle nod to the fact that you don't care about / wont get the return value. "Function" implies input / output, I guess "procedure" describes a side-effect 'function'.

dharrigan11:10:03

Perhaps, although still confusing! 😉

mccraigmccraig11:10:21

@dharrigan an async viewpoint - for an api or other i/o op, and if you are using async i/o, you can do something somewhat different - and use a graph of (core.async) channels or (manifold) streams stream<op-metadata> ==> stream<promise<op-result>> ==> buffered-stream<promise<op-result>> ==> stream<op-result> and then you can use the size of the buffer to control concurrency (with backpressure)

mccraigmccraig11:10:43

in manifold terms this looks like (->> ops (s/map do-async-op-io) (s/buffer N) (s/realize-each) (s/reduce conj []))

dharrigan11:10:15

that's very handy! copied into my review-later notes! 🙂

dharrigan12:10:38

shout out to the collective wisdom - does anyone know of a linux (arch) utility that when fed a string (or some stdin), that it will display on the terminal in big bold letters (configurable) and a red line surrounding (configurable) the stdin - if you recall the guru meditation on amigas, you know what I mean 🙂

dharrigan13:10:32

I suppose cowsay does what I want

tcsavage13:10:17

toilet gets you some way as well

tcsavage13:10:33

toilet -F border will put a simple border around the text -f term will just use regular letters rather than fancy figlet fonts

tcsavage13:10:03

It doesn't really do colours unless you want a rainbow

henners13:10:03

its rainbow option does make for fabulous /etc/motd files 🙂

dharrigan13:10:24

rainbows are fine 🙂

dharrigan13:10:31

Who doesn't like a nice rainbow?

henners13:10:41

well quite

tcsavage13:10:51

They have their place. Didn't think that's what you were going for with a guru meditation though 🙂

practicalli-johnny13:10:36

There was some interest in Clojure and Graal previously, eg. compiling JVM languages to native images, fast startup time, etc. Is there still interested in London Clojurians event on Graal?

practicalli-johnny13:10:18

One of the developers at Oracle is interested in doing a talk or workshop with the Clojure community in London. What sort of things would you find interesting??

dharrigan13:10:32

Thank you Jane 🙂

3Jane13:10:42

(oh, toilet is figlet++, nvm 😄 )

practicalli-johnny13:10:59

Its interesting to see projects such as clj-kondo using Graal to help distribute to different platforms. I havent looked into the detail, but it seem to give Clojure more reach...

borkdude13:10:08

@jr0cket I would be interested in seeing that, please record if possible 🙂

8
practicalli-johnny13:10:57

@borkdude will do. Just curious, do you use GraalVM native images to help startup time for clj-kondo ? I though you might be, but not 100% sure.

borkdude13:10:19

@jr0cket I compile to native using GraalVM yes

borkdude13:10:45

got three projects doing this: clj-kondo, babashka and jet

borkdude13:10:52

there's also a #graalvm channel btw

dominicm13:10:11

@jr0cket I think the native-image stuff has been talked to death. But the multi language features seem to have been under explored imo.

dominicm13:10:28

There's a lot of cool stuff in graal, and it's way more than just native image

folcon14:10:27

@jr0cket am interested in the graal as well =)…

otfrom22:10:30

Night

😴 8