Clojurians Log v2

månmån

👋

Good Morning!

So, I saw the news about the new feature for clojure 11. Not sure I completely grok it

It just means you don’t need to do the apply concat hack if you need to apply a map of options to a function that was written to take kwargs

Thank you. I think I'll need to see more code examples. I'll have a look around.

as a side note, I have no idea the algorithms in play at the BBC news site, but embedding David Velez, CEO of Nubank into an article about employee burnout, doesn't seem quite right...

<https://www.bbc.co.uk/news/business-56452494>

Prior to this, if you a have a function like this:

(defn foo [arg1 & {:as kwargs}] [arg1 kwargs])

(foo 1 :a "a" :b "b")

(let [opts {:a "a" :b "b"}] 
   (apply foo 1 (apply concat opts)))

This led to kwargs being a real annoyance. Best practice was don’t use them, except for functions that are only intended to be used at a REPL; and in macros.

However, I’m still not sure this should change the best practice advice. kwargs still make calling/usage inconsistent, and it makes it hard to know when reading the code if the args are a map of opts or positional parameters etc.

For the sake of two extra characters of noise for callers, it’s pretty pointless. i.e. This: (foo 1 :a "a" :b "b") vs: (foo 1 {:a "a" :b "b"})

I see. Digesting...

So I’m glad to finally have a nicer way to apply opts in the few places that kwargs are used in functions I need to use without using the apply concat trick. But I worry fixing this may make the use of kwargs more common.

Also worth noting that this change applies to destructuring everwhere, so not just kwargs. Though I think any usecases for that are questionable, and I think you’d be better being explicit.

morning

So, basically, it shoves whatever isn't a positional parameter into a map

moin moin

Morning

kwargs do yes… They’ve been in clojure for a long time… I can’t recall which version they were introduced it was that long ago.

Morning

Having done a lot of Python recently, I tend to prefer explicit kwargs over positional params. If a fn only has 1 or 2 args then sure, but much more than that and I want them explicitly named not rely on remembering/looking up the order, especially in a weakly-typed language

I can pretty much guarantee that was a choice by someone editorial, not a machine-led decision for 'related content'

Bizarre choice then 🙂

why is it weird?

The video clip doesn' talk whatsoever about the contents of the article

it's out of place

The video clip is a short 30 second clip of him talking about how he started to form NuBank

You would have imagined that if there was a video clip, in an artricle about employee overworking, then the video would be, maybe an interview of someone talking about burnout.

i also prefer named args over many positional args - but make them a map, not kwargs - you are often going to end up building the args as a map anyway, adding things to it, taking them away to pass it on... kwargs make life awkward

is kwargs the :as .... part?

Yup I agree named arguments are better than positional arguments, once you get past 3 options. Indeed Rich has spoken about this many times in the past.

No its the & {} part

Ah, I dont think I've ever used that

& switches it to variable arity

& with a map after it roles the variable arity into a map.

In my code, I have a few positional, then my convention is the last var may be a map :

yes that’s almost always the best way to do it

well depending on whether you need those positional args in the first place

awkward when you want to give the options to a sequence consuming fn ... in which case i seem to vacillate between first and second to last place

yup that’s definitely true -> and ->> are always worth considering to. I find much of this also depends on whether you’re app or library code.

@dharrigan, what video are you referring to with the employee burnout? There is actually an algorithm nowadays, so it would be good to show someone where it has gone wrong.

Oh, I see it. Sorry, not in the thread.

:face_with_rolling_eyes: Just happens to be tagged with "banking" too. The kids they have running the editing desks these days...

Morning

Anyone got any tips for tracking down a StackOverflow? 😉

Like, I can see from what I have got that it's probably related to a lazy-seq, potentially a fn recursively calling itself, but there's a lot of code to look through here trying to find that...

We have 35 instances of & { in our codebase at work so this feature will allow us to clean up some calls. I wish it had been fixed a long time ago, so a lot of the shift from kwargs to map args would not have happened.

It’ll be interesting to see whether it causes a swing back to kwargs. I think one of the reasons for making the change now is the introduction of -X which essentially takes kwargs on the command-line but massages them into a hash map internally. This will allow you to write your exec-fns as if they were taking kwargs from the command line.

wait, didn't @mccraigmccraig have that exact bug yday?

mine was a promise-returning fn (with callbacks on a threadpool) which was recursively calling itself... it ate the world trying to create an infinite promise-chain and crashed the vm

you promise too much @mccraigmccraig!

are you actually seeing a stacktrace @carr0t?

I am seeing a stacktrace which is a long loop of the same calls, all in clojure.core. Looks like some errors with handling of a lazy-seq/concat

I have just found out about a JVM arg that prevents stacktraces being truncated though, so I'm going to try that

Oh boo, -XX:MaxJavaStackTraceDepth=-1 doesn't seem to work on OpenJDK 12. I'll try with just the max it can go to