Fork me on GitHub

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.


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

(defn foo [arg1 & {:as kwargs}] [arg1 kwargs])
You’d could use it like this:
(foo 1 :a "a" :b "b")
However the problem is if you have those args :a "a" :b "b" in a map, you’d have to have to call it more like this:
(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.


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


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.


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


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.


Yeah I suspected that might be a motivating reason behind the change too


@U06HHF230 Apparently not: I asked Alex and he said it wasn’t — it’s more a case of this is how they felt it should have been done in the first place 🙂


I saw he’d made a similar comment on reddit (about this is how they always should have been); can’t remember if I wondered that before or after reading it… either way interesting to hear it’s just coincidence. :thumbsup:


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


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.

Eamonn Sullivan13:03:19

@U11EL3P9U, 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.

Eamonn Sullivan13:03:06

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

Eamonn Sullivan13:03:23

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


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


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!

picard-facepalm 3

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